Forum: Mikrocontroller und Digitale Elektronik Reverse engineering Autoaid / EN-Plus AC011K-AE-25 Wallbox mit ESP32

Die original Firmware auslesen und via serieller Schnittstelle die 
Ausgaben mitlesen ist übrigens kein Problem.

1

reading partition table...

2

entry 0:

3

  label      : nvs

4

  offset     : 0x9000

5

  length     : 16384

6

  type       : 1 [DATA]

7

  sub type   : 2 [WIFI]

8

9

entry 1:

10

  label      : otadata

11

  offset     : 0xd000

12

  length     : 8192

13

  type       : 1 [DATA]

14

  sub type   : 0 [OTA]

15

16

entry 2:

17

  label      : phy_init

18

  offset     : 0xf000

19

  length     : 4096

20

  type       : 1 [DATA]

21

  sub type   : 1 [RF]

22

23

entry 3:

24

  label      : ota_0

25

  offset     : 0x10000

26

  length     : 2621440

27

  type       : 0 [APP]

28

  sub type   : 16 [ota_0]

29

30

entry 4:

31

  label      : ota_1

32

  offset     : 0x290000

33

  length     : 2621440

34

  type       : 0 [APP]

35

  sub type   : 17 [ota_1]

36

37

entry 5:

38

  label      : storage

39

  offset     : 0x510000

40

  length     : 3043328

41

  type       : 1 [DATA]

42

  sub type   : 129 [unknown]

43

44

Done

Interessante Bilder!

Die mit M48 beschrifteten weißen Klötze sind offensichtlich die Schütze. 
Schön, dass es vier einzelne Relais sind. Das würde bei 
PV-Überschussladung auch ermöglichen, nur eine Phase durchzuschalten, 
was die Effektivität erhöht. Bei dem kleineren schwarzen Kästchen 
darüber dachte ich zuerst an ein Vorschaltrelais mit Netzspannung, aber 
die Schütze sind normale finder-Relais mit 12V Ankerspanung für 
16A/250V.

Sind die drei schwarzen Würfel unterhalb der Schütze Stromsensoren oder 
Entstörglieder?

Die ICs 5 und 8 habe ich als 5532 identifiziert, also 
Dual-Operationsverstärker. Hat sicher was mit der Leistungsmessung zu 
tun.
IC 3 ist ein 24256 EEPROM.
Die Beschriftung von IC10 ist sehr schlecht zu erkennen. Irgendwas von 
NXE: BFE... D814 oder so.

Ulkig finde ich, dass eine SD-Karte vorhanden ist. Was speichern die 
denn da?

Oh, ich hatte schon gedacht das sich dafür keiner interessiert.
Da freu ich mich nun um so mehr über die Antworten.

1

1. ESP32          --  Hauptprozessor - WiFi, BLE, SDCARD...

2

2. GD32F103       --  ARM M3 - mit der RFID Platine verbunden, PWM für die CP Leitung?

3

3. 24256E S99028  --  EEPROM Serial 256-Kb I2C

4

4.

5

5. 5532           --  Dual Low-Noise Operational Amplifiers

6

6.

7

7.

8

8. 5532           --  Dual Low-Noise Operational Amplifiers

9

9.

10

10. NXP A1040/c BFE D814  --  High-Speed CAN Transceiver ISO 11898

11

11.

12

Auf der RFID Platine:

13

12. FM17520       -- RFID IC

14

13. (STM)32F0     -- nicht sicher identifiziert

1

4x M48            --  finder-Relais mit 12V Ankerspanung für 16A/250V

2

3x CT-082D-1.0    --  PDU Current Transformer Current Transformer - Strommessung

Die SD-Karte hab ich reingesteckt. Die ist FAT32 formatiert und die 
Originalfirmware speichert dort Logfiles (identisch zur seriellen 
Ausgabe des ESP32). Ausserdem kann meiner Ansicht die Box mit Hilfe der 
SD-Karte und einer speziellen Konfigurationsdatei darauf auch 
konfiguriert werden. Das Format der Datei ist mir aber leider nicht 
bekannt.

Das kleinere schwarze Kästchen neben der grünen Buchse ist nur sehr 
schwer zu identifizieren. Die Schrift kann man nicht lesen weil es zu 
dicht an den Relais ist. Ich hab zwar noch ein Foto angehängt, hab aber 
nicht viel Hoffnung das das hilft.

@JR, Wie kann ich dich erreichen? Schreibst du mir mal ne mail an 
bs-mc@netgaroo punkt com?

Ein CE Zeichen ist drauf. Und unter Zertifizierungsstandard steht in der 
Bedienungsanleitung: EN/IEC 61851-1: 2017, EN/IEC 61851-21-2: 2018.

Wieviel das aussagt, keine Ahnung.

Siehst du auf den Bildern Mängel?
Lass uns bitte an deinem Wissen teilhaben.

ElektroFH schrieb:
> Puohh, diese China Ding ist VDE, IEC und CE zugelassen?

Warum nicht? Wer dafür bezahlt, bekommt aus China durchaus ordentliche 
Ware.

Nahezu alle Schaltnetzteile der Welt kommen inzwischen aus China. Die 
Mehrzahl davon hat ganz legal CE und 60950 und hält das tatsächlich auch 
nach Jahren noch ein.

Also der grüne Steckkontakt (E) ist sicher nicht der RS485-Anschluss. 
Sieht eher aus wie ein Schalt-Ausgang über das schwarze Relais mit 
Widerstand R18 in Reihe.
Bei der RS485 tippe ich auf Connector K, weil der mit B A beschriftet 
ist.

Wenn IC 10 ein A1040 ist, dann führt Connector J den CAN-Bus-Anschluss 
raus - wozu auch immer man den braucht.

G ist für das Flashen des GD32F103. Siehe auch 
https://j2n.nl/blog/anchor-cms/index.php/posts/programming-gd32f103-chips-on-linux. 
Ist H sein serieller Port?

I und oberhalb von G sind Jumper.

F könnte ein Deaktivierungseingang sein für Schlüsselschalter oder so. 
Ist aber nur eine Vermutung.

Birger, kannst du die Rückseite der Platine nochmal schärfer 
fotografieren? Mich würde interessieren, wie genau die Beschriftung auf 
dem IC U1 ist.

> Birger, kannst du die Rückseite der Platine nochmal schärfer
> fotografieren? Mich würde interessieren, wie genau die Beschriftung auf
> dem IC U1 ist.
OK, hab noch weitere Bilder gemacht. Wieder hier:
https://mail.netgaroo.com/img/AC011K-AE-25/.

> Wenn IC 10 ein A1040 ist, dann führt Connector J den CAN-Bus-Anschluss
> raus - wozu auch immer man den braucht.
https://mail.netgaroo.com/img/AC011K-AE-25/IC10%203.png

> Mit einer etwas verunglückten Beschriftung:
> JTCK = SWDCLK?
> JTMS = SWDIO?
Könnte die Bezeichnung nicht auch auf JTAG hinweisen?

> Ist der ARM Chip auf der RFID Platine ein stm32f032f4 in TSSOP20?
https://mail.netgaroo.com/img/AC011K-AE-25/RFID%20U1%20a.png

Damit sind vielleicht schon alle wesentlichen ICs benannt.

Ich denke übrigens, dass man den GD32F103 mit großer Wahrscheinlichkeit 
mittels des ESP32 lesen und schreiben (flashen) kann und somit die 
Anschlüsse G und H wahrscheinlich nicht gebraucht werden. Das wäre 
meiner Ansicht sowieso der eleganteste Ansatz.

1

A. DC Fehlerstrom Sensor

2

B. LED Leiste und RF Card Reader Anschluß

3

C. SD-Card Reader

4

D. ESP32 - Serial Anschluß

5

E. Schalt-Ausgang über das schwarze Relais mit Widerstand R18 in Reihe?

6

F. Deaktivierungseingang für Schlüsselschalter?

7

G. JTCK = SWDCLK? JTMS = SWDIO?

8

H. serieller Port von 2 (GD32F103)? 

9

I. Jumper

10

J. CAN-Bus-Anschluss?

11

K. RS485 Anschluß (Bezeichnung A B)?

1

1. ESP32          --  Hauptprozessor - WiFi, BLE, SDCARD...

2

2. GD32F103       --  ARM M3 - mit der RFID Platine verbunden, PWM für die CP Leitung

3

3. 24256E S99028  --  EEPROM Serial 256-Kb I2C

4

4.

5

5. 5532           --  Dual Low-Noise Operational Amplifiers

6

6.

7

7.

8

8. 5532           --  Dual Low-Noise Operational Amplifiers

9

9.

10

10. NXP A1040/c BFE D814  --  High-Speed CAN Transceiver ISO 11898

11

11.

12

Auf der RFID Platine:

13

U1. (STM)32F0     -- nicht sicher identifiziert

14

U2. FM17520       -- RFID IC

1

4x M48            --  finder-Relais mit 12V Ankerspanung für 16A/250V

2

3x CT-082D-1.0    --  PDU Current Transformer Current Transformer - Strommessung

Volltreffer: Der Chip auf der Rückseite ist ein RS-485 Transceiver 
VP3082. Damit ist der Zweck von Connector K bestätigt.
Die Fotos sind perfekt!

Kann gut sein, dass einer der Operational Amplifiers für die 
Kommunikation mit dem Auto genutzt wird. Die Grundschaltung ist hier 
ganz gut erklärt: 
https://hackaday.io/project/166859-prism/log/166672-first-prototype-and-test-hardware. 
Ist in der China-Box wahrscheinlich ähnlich implementiert.
Da steht auch, dass Tesla CAN für die Kommunikation über den Ladestecker 
bei High Speed DC Charging nutzt. Aber das kann die Box ja sowieso 
nicht. Hat wahrscheinlich nichts mit dem CAN-Port hier zu tun.

Es sind noch ein paar NTCs auf der Platine verteilt, z.B. NTC5 an der 
oberen Stirnseite vom Relais für Phase 1 und NTC4 ganz unten auf der 
Platinenrückseite nahe der Schraubkontakte. Andere habe ich noch nicht 
gefunden. Damit kann man Temperaturen messen.

Sieht bisher alles nicht nach magischer Kunst aus. Welche ARM-Pins für 
welche Funktion zuständig sind, lässt sich bestimmt rausfinden. Wichtig 
zu testen wäre noch, ob sich der Flash-Inhalt der Chips auslesen lässt. 
Dann könnte man die Box jederzeit wieder auf Werkszustand zurück setzen.

Da ist aber noch ein wichtiges Bauteil, das ich ungern ignorieren würde: 
Der Ringkern-Sensor für die DC-Fehlerstromerkennung. Er umschließt L1, 
L2, L3 und N und hängt vierpolig an Connector A. Die Dinger gibt es mit 
integrierter Elektronik, den Ansteuer- und Auswertungsjob dürfte aber 
hier die Hauptplatine erledigen. Etwas zur Theorie steht in 
https://hackaday.io/project/166859-prism/log/168847-rcm-direct-current-sensing-how-its-done. 
Kein Wunder, dass man da einen schnellen Prozessor braucht. Und am Ende 
teure Messgeräte zum Testen.
Für OpenEVSE wurde das auch schon diskutiert: 
https://community.openenergymonitor.org/t/openevse-and-wiring-regs-changes-722-531-2-101/10959.

@ARMageddon: Ja, JTCK und JTMS gehören zu JTAG. Weil es aber nur zwei 
Signalpins sind, ist es wohl SWJ. Und das geht dann auch mit dem "mini 
ST-LINK V2". Siehe https://wiki.cuvoodoo.info/doku.php?id=jtag. (Der 
GD32F103 ist ein verbesserter STM32-Clone.)

Hier sind Tipps zum Auslesen: 
Beitrag "Mikrocontroller auslesen".
@Birger: Was hast du für deinen Ausleseversuch verwendet?

> @Birger: Was hast du für deinen Ausleseversuch verwendet?
Ich hatte (erfolglos) ganz naiv versucht mit einem FTDI - TTL Adapter an 
CN10 was zu sehen. Der leistet ja beim ESP32 an CN18 gute Dienste.

Aber ich hab mir jetzt mal einen ST-LINK V2 bestellt.

Vielen Dank für deine Hilfe!

Uwe G. schrieb:
> Ist H sein serieller Port?
Ich hab inzwischen auf H auch erfolgreich die serielle Schnittstelle 
verbunden.
Da gibts mit 9600 Baud eine Shell zum ARM M3.

1

# ls

2

#support cmd:

3

#-> debugon

4

#-> debugoff

5

#-> setsn

6

#-> getsn

7

#-> setdevtype

8

#-> getdevtype

9

#-> setmode

10

#-> getmode

11

#-> setcardid

12

#-> clrcardid

13

#-> ver

14

#-> memuse

15

#-> reboot

16

#-> tmrlist

17

#-> setrtc

18

#-> getrtc

19

#-> clrrunpara

20

#-> clrsyspara

21

#-> clrrate

22

#-> cardsn

23

#-> factory

24

#-> eepromerase

25

#-> cpvolt

26

#-> chgsts

27

#-> chginfo

28

#-> meterinfo

29

#-> logbuild

30

#-> logopen

31

#-> logclose

32

#-> logformat

33

#-> loglist

34

#-> logadd

35

#-> logdel

36

#-> logget

37

#-> logerase

38

#-> faultId

39

#-> setfault

40

#-> clrfault

41

#-> setwarn

42

#-> clrwarn

43

#-> update

44

#-> unlock

45

#-> lock

46

#-> meterno

47

#-> tmrtest

48

#-> ca

49

#-> cb

50

#-> ob

51

#-> pwm

52

#-> uart

Eine Shell. Na sieh mal an!
@Birger: Hast du auch mal an der UART-Schnittstelle zur RFID-Platine 
mitgehört. Da sollte die Kennung der RFID-Karte rüber kommen, wenn man 
eine dran hält.
Sind die vier LEDs einfach über die Transistoren und die Widerstände 
parallel angeschlossen oder versteckt sich hinter der weißen Blende noch 
was? Ich nehme an, die können grün oder rot leuchten.

Kann es sein, dass der ESP32 über seinen seriellen Port mit dem GD32F103 
kommuniziert?

Der ST-LINK V2 ist inzwischen da.
Die 512k Bytes von bank0 zu lesen klappt nicht (so wie ich das versucht 
hab).

1

# openocd --file interface/stlink.cfg --file target/stm32f1x.cfg

2

Open On-Chip Debugger 0.11.0

3

Licensed under GNU GPL v2

4

For bug reports, read

5

        http://openocd.org/doc/doxygen/bugs.html

6

Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.

7

Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD

8

Info : Listening on port 6666 for tcl connections

9

Info : Listening on port 4444 for telnet connections

10

Info : clock speed 1000 kHz

11

Info : STLINK V2J17S4 (API v2) VID:PID 0483:3748

12

Info : Target voltage: 3.232361

13

Info : stm32f1x.cpu: hardware has 6 breakpoints, 4 watchpoints

14

Info : starting gdb server for stm32f1x.cpu on 3333

15

Info : Listening on port 3333 for gdb connections

16

Info : accepting 'telnet' connection on tcp/4444

17

target halted due to debug-request, current mode: Thread

18

xPSR: 0x01000000 pc: 0x0800251c msp: 0x20001668

19

Info : device id = 0x13090414

20

Info : flash size = 512kbytes

1

# telnet localhost 4444

2

Trying 127.0.0.1...

3

Connected to localhost.

4

Escape character is '^]'.

5

Open On-Chip Debugger

6

> init

7

> reset init

8

target halted due to debug-request, current mode: Thread

9

xPSR: 0x01000000 pc: 0x0800251c msp: 0x20001668

10

> flash list

11

{name stm32f1x base 134217728 size 0 bus_width 0 chip_width 0}

12

> flash read_bank 0 bank0.bin

13

device id = 0x13090414

14

flash size = 512kbytes

15

error reading to flash at address 0x08000000 at offset 0x00000000

16

Read error

Weniger geht, aber bei 263171 Bytes ist Schluß. Ich weiß nicht so recht 
wie das zu deuten ist.

1

➜  ~ openocd --file interface/stlink.cfg --file target/stm32f1x.cfg -c "init" -c "reset init" -c "flash read_bank 0 firmware.bin 0 0x40403" -c "exit"

2

Open On-Chip Debugger 0.11.0

3

Licensed under GNU GPL v2

4

For bug reports, read

5

        http://openocd.org/doc/doxygen/bugs.html

6

Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.

7

Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD

8

Info : clock speed 1000 kHz

9

Info : STLINK V2J17S4 (API v2) VID:PID 0483:3748

10

Info : Target voltage: 3.243588

11

Info : stm32f1x.cpu: hardware has 6 breakpoints, 4 watchpoints

12

Info : starting gdb server for stm32f1x.cpu on 3333

13

Info : Listening on port 3333 for gdb connections

14

target halted due to debug-request, current mode: Thread

15

xPSR: 0x01000000 pc: 0x0800251c msp: 0x20001668

16

Info : device id = 0x13090414

17

Info : flash size = 512kbytes

18

wrote 263171 bytes to file firmware.bin from flash bank 0 at offset 0x00000000 in 5.667848s (45.344 KiB/s)

19

20

➜  ~ openocd --file interface/stlink.cfg --file target/stm32f1x.cfg -c "init" -c "reset init" -c "flash read_bank 0 firmware.bin 0 0x40404" -c "exit"

21

Open On-Chip Debugger 0.11.0

22

Licensed under GNU GPL v2

23

For bug reports, read

24

        http://openocd.org/doc/doxygen/bugs.html

25

Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.

26

Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD

27

Info : clock speed 1000 kHz

28

Info : STLINK V2J17S4 (API v2) VID:PID 0483:3748

29

Info : Target voltage: 3.240399

30

Info : stm32f1x.cpu: hardware has 6 breakpoints, 4 watchpoints

31

Info : starting gdb server for stm32f1x.cpu on 3333

32

Info : Listening on port 3333 for gdb connections

33

target halted due to debug-request, current mode: Thread

34

xPSR: 0x01000000 pc: 0x0800251c msp: 0x20001668

35

Info : device id = 0x13090414

36

Info : flash size = 512kbytes

37

Error: error reading to flash at address 0x08000000 at offset 0x00000000

38

Error: Read error

Uwe G. schrieb:
> @Birger: Hast du auch mal an der UART-Schnittstelle zur RFID-Platine
> mitgehört. Da sollte die Kennung der RFID-Karte rüber kommen, wenn man
> eine dran hält.
Noch nicht.

> Sind die vier LEDs einfach über die Transistoren und die Widerstände
> parallel angeschlossen oder versteckt sich hinter der weißen Blende noch
> was?
Die Blende würde ich Diffusor nennen. Die ist nur für die Schönheit da.

> Ich nehme an, die können grün oder rot leuchten.
Grün, gelb und rot.

> Kann es sein, dass der ESP32 über seinen seriellen Port mit dem GD32F103
> kommuniziert?
Sehr wahrscheinlich seriell, allerdings glaub ich nicht über den Port D 
/ CN18.

@Reversengineer: Die Schaltungsanalyse machen wir ja gerade. Trotzdem 
wäre der Binärcode wichtig, um ihn notfalls jederzeit zurück spielen zu 
können.
Das Video ist sehr anschaulich. Interessant für uns sind eher die 
zweiten 20 Minuten.

Der Vollständigkeit halber:
IC 11 (PH1) ist ein Optokoppler (Typ 817). Zur Notabschaltung? Der 
Transistor ist auf der Hochspannungsseite.
6 und 7 (Q10, Q2) müssten die Transistoren zum Schalten der Relais sein 
(jeweils N/L1 und L2/L3 zusammen?) D9, D11, D20 und D41 wären dann die 
Freilaufdioden.
4 ist der Oszillator für den GD32F103 (8.000 MHz).
Beim schwarzen Relais ist R81 im Schaltkreis, nicht R18. Sorry für den 
Zahlendreher.
Auf der Platinenrückseite ist unter den Relais acht mal das gleiche 
RC-Netzwerk. Damit werden die Spannungen an den "Schütz"-Kontakten 
abgegriffen (über R174, R47, R159, R40, R154, R90, R180 und R57). 
Wahrscheinlich zur Leistungsmessung und zur Erkennung von fehlenden 
Spannungen und hängenden Schalkontakten.

@Birger:
Ist die Ausgabe vom ST-Link Tool? 
http://www.st.com/web/en/catalog/tools/PF258168
Das hat eine grafische Oberfläche und du kannst einstellen, wie viele 
Daten und von welcher Adresse es lesen soll.

Wenn ich die Fotos richtig deute, haben wir hier einen GD32F103RET6 
(LQFP Package, 64 Pins). Der hat laut Datenblatt seinen Boot Loader bei 
0x1FFF B000 - 0x1FFF F7FF (18 kbytes) und sein Main Flash bei 0x0800 
0000 - 0x0807 FFFF (512 kbytes).

Mit Hilfe von Uwe ist es inzwischen auch gelungen den GD32F103RET6 
komplett auszulesen.

Vielen Dank!

Wir haben also die Firmware binaries vom ESP32 und vom GD32F103.

Somit ist die Wahrscheinlichkeit groß, die Wallbox wieder in den 
Originalzustand zurücksetzen zu können wenn das mit der open source 
Firmware nicht klappt.

Die aktualisierte Komponentenliste:

1

A. DC Fehlerstrom Sensor

2

B. LED Leiste und RF Card Reader Anschluß

3

C. SD-Card Reader

4

D. ESP32 - Serial Anschluß

5

E. Schalt-Ausgang über das schwarze Relais mit Widerstand R81 in Reihe

6

F. Deaktivierungseingang für Schlüsselschalter?

7

G. JTAG/SWD von 2 (GD32F103)

8

H. serieller Port von 2 (GD32F103) 

9

I. Jumper am ESP32

10

J. CAN-Bus-Anschluss

11

K. RS485 Anschluß (Bezeichnung A B)

1

1. ESP32          --  Hauptprozessor - WiFi, BLE, SDCARD...

2

2. GD32F103RET6   --  ARM M3 - PWM für die CP Leitung

3

3. 24256E S99028  --  EEPROM Serial 256-Kb I2C

4

4. Oszillator     --  für den GD32F103 (8.000 MHz)

5

5. 5532           --  Dual Low-Noise Operational Amplifiers

6

6. Transistor     --  zum Schalten der Relais (N/L1)

7

7. Transistor     --  zum Schalten der Relais (L2/L3)

8

8. 5532           --  Dual Low-Noise Operational Amplifiers

9

9.

10

10. NXP A1040/c BFE D814  --  High-Speed CAN Transceiver ISO 11898

11

11. 817           --  Optokoppler - evtl. Notabschaltung?

12

Auf der RFID Platine:

13

12. FM17520       --  RFID IC

14

13. (STM)32F0     --  nicht sicher identifiziert

1

4x M48            --  finder-Relais mit 12V Ankerspanung für 16A/250V

2

3x CT-082D-1.0    --  PDU Current Transformer Current Transformer - Strommessung

Inzwischen habe ich Birgers Hardware intensiv analysiert.

Am ESP32 sind die beiden Taster und LEDs auf der Platine angeschlossen. 
Außerdem der Jumper CN6, die RS485-Schnittstelle und der Kartenleser. 
Die Programmierschnittstelle (RXD, TXD, GOIO0) sind auf CN18 zugänglich.
Die genaue Beschaltung habe ich als Bild angehängt.

Am GD32 hängt die RFID-Platine (über UART4 und PB12/PB13 für die 
Front-LEDs), das EEPROM über I2C, das CAN-Interface und der Jumper CN7 
über PC8. Der weiße Steckverbinder CN3 (Connector F) geht an GND und 
VBAT, hat also mit der Stromversorgung der Echtzeituhr zu tun. DUG_RX 
und DUG_TX hängen über Widerstände an USART0, JTCK und JTMS direkt am 
Chip.
Die weißen Relais sind alle parallel geschaltet. Also nix mit auf 
einphasig einschränken.

Es muss noch eine Verbindung vom ESP32 zum GD32 geben. Leider habe ich 
da keine Spur von entdeckt. Eigentlich hatte ich erwartet, dass der 
ESP32 die JTCK/JTMS-Pins steuern kann. Im GD-Datenblatt steht "The boot 
loader is located in the internal boot ROM memory (system memory). It is 
used to reprogram the Flash memory by using USART0 (PA9 and PA10)." Aber 
auch dort finde ich keine Verbindung.

Ein Rätsel! Über Telepathie wird es wohl nicht laufen.

Birger S. schrieb:
>> Ist H sein serieller Port?
> Da gibts mit 9600 Baud eine Shell zum ARM M3.

Nach dem Firmwareupdate auf V3.2.517 BuildTime:2021/05/21 17:03:36 ist 
die Shell erstmal weg.
Also zumindest ist sie nicht mehr automatisch aktiv und ich hab sie noch 
nicht wiedergefunden.

Die Verbindung zwischen dem GD und dem ESP haben wir aber inzwischen 
gefunden und können da lauschen.

So, das Reverse Engineering war Erfolgreich.
Die erste Ladung und das Umstellen der Ladeleistung ist gelungen.
Wir könnten noch Hilfe beim C++ Code gebrauchen damit das nicht so 
stümperhaft aussieht als wenn ich das gemacht hab. ;-)

Die Kommunikation mit der EVSE (die Software auf dem GD Chip) erfolgt 
seriell und die Kommandos sollen hier Verarbeitet werden: 
https://github.com/bs-github/warp-charger/blob/master/software/modules/backend/enplus/enplus.cpp

Wer mir helfen mag meldet sich bitte.

Was habt ihr denn eigentlich damit vor? Ist das der neue Hype wie damals 
MP3-Player?

Man kann aber in der Ladestationsverwaltung eine neue Ladestation 
hinzufügen. Die App erkennt dann, dass es sich um eine vorhandene 
Seriennummer handelt und fragt die WLAN-Zugangsdaten neu ab. 
Telefonnummer ist nicht nötig.

Manchmal zeigt die App einen falschen Status an. Dann hilft ein Neustart 
der App.

Einmal haben sich Wallbox und Auto gar nicht mehr verstanden. Erst 
nachdem ich das Original-Schuko-Ladekabel angesteckt hatte konnte ich 
damit normal laden. Anschließend ging es auch wieder mit der Wallbox.

Die wesentlichen Meilensteine sind erreicht.

Die Kommunikation zwischen dem ESP32 und dem GD Chip ist soweit bekannt, 
das die Möglichkeiten welche die Box im Originalzustand bietet mit der 
Open Source Firmware ebenfalls möglich sind.

Es ist zwar noch nicht alles sauber umgesetzt, aber das reverse 
engineering ist in wesentlichen Teilen abgeschlossen.

Status Update:

* Lade- start/stop funktioniert
* Einstellen der Ladestromstärke funktioniert (allerdings nur 
Stufenweise)
* RFID wird erkannt (aber noch nicht beachtet)
* Ladedaten (Stromverbrauch) werden erkannt (sind aber noch nicht im 
Frontend oder MQTT zu sehen)
* flashen der Firmware für den Ladecontroller (GD Chip) direkt vom ESP32 
aus funktioniert (das war sehr wichtig um auch ohne die 
Herstellerfirmware Updates des Ladecontrollers durchführen zu können)


Durch die TinkerForge Software Basis haben wir die folgenden Vorteile 
gegenüber dem Original.

* Web Interface
* Eigener AccessPoint
* RFID local
* MQTT Schnittstelle (für externe Steuerung und Monitoring)
* Lastmanagement


Das Projekt ist umgezogen, um der Entwicklung der TinkerForge Software 
zu folgen.

Die neue Open Source Firmware für die Autoaid Wallbox findet sich auf 
github 
https://github.com/bs-github/esp32-firmware/tree/warp_on_other_hardware

Das Projekt sucht immer noch weitere Mitstreiter!
(C++ oder TypeScript Kenntnisse von Vorteil)

Wir haben auch eine Autoaid Intelligent Wallbox günstig abzugeben 
(natürlich auf Wunsch mit der neuen Firmware).

Was sind das für Bauteile links unten bei den Stromanschlüssen?
Ich meine die Gelben und Blauen? Varistoren? VDR?
Und was ist der Grüne links neben dem Grauen (C?)?

Von zweien kann ich dir die Bezeichnungen gleich sagen.

gelb: 14N561K
gross blau: Y1472M

Für die anderen müsste ich die Platine erst ausbauen.

Das grüne Teil links neben dem grauen Kondensator ist einer von mehreren 
NTCs zum Erfassen der Temperaturen. Die anderen Teile sind soweit ich 
das sehe zur Entsorgung von Spannungsspitzen auf den Leitungen.

Birger S. schrieb:
> Von zweien kann ich dir die Bezeichnungen gleich sagen.
>
> gelb: 14N561K
> gross blau: Y1472M
>
> Für die anderen müsste ich die Platine erst ausbauen.

Sind die Kondensatoren mit dem Netz verbunden? Wie ist da die 
Verschaltung?
Im Nachbarpost wird gerade über so eine Eingangsschaltung gesprochen

1st BETA RELEASE

Dokumentation: https://github.com/bs-github/esp32-firmware/wiki

Firmware 1.2.99 BETA: 
https://github.com/bs-github/esp32-firmware/releases/tag/warp8enplus-1.2.99

* Lade- start/stop funktioniert
* Einstellen der Ladestromstärke funktioniert
* RFID wird erkannt (aber noch nicht beachtet)
* Ladedaten (Stromverbrauch) werden erkannt und erscheinen im Log (sind 
aber noch nicht im Frontend oder MQTT zu sehen)

Wir haben immer noch eine Autoaid Intelligent Wallbox abzugeben 
(natürlich auf Wunsch mit der neuen Firmware).

Es gibt anscheinend zwei Platinenversionen

Hallo Birger,
lebt dieses Projekt noch?
Die mit den Files auf github scheint sich mit der aktuellen Version von 
Platformio in VS Code unter Windows ein build für den ESP32 nicht mehr 
möglich zu sein.

Danke und Grüße
Constanze

update: build unter Ubuntu 20 hat funktioniert.

Findet hier noch ein Austausch Entwickler/Projektinteressierte statt 
bzw. werden Fortschritte geteilt?

> lebt dieses Projekt noch?
Ja. Der (bisher unveröffentlichte) Port der Version 2.0.8 von 
TinkerForge ist auf der Autoaid box zwar noch sehr fehlerhaft, aber es 
wird daran gearbeitet die Features zum laufen zu bringen.

Wir sind nach wie vor an Hilfe interessiert. Inzwischen hat sich der 
Bedarf von der Hardwareseite hin zur Software verschoben.
Wer mitmachen möchte meldet sich bitte :-).

> Die mit den Files auf github scheint sich mit der aktuellen Version von
> Platformio in VS Code unter Windows ein build für den ESP32 nicht mehr
> möglich zu sein.
Windows als Entwicklerplatform haben wir nie getestet. OSX und Linux 
sollte aber gehen.

> Findet hier noch ein Austausch Entwickler/Projektinteressierte statt
> bzw. werden Fortschritte geteilt?
Eigentlich keine Zwischenstände, aber wenn was Vorzeigbares da ist, 
werde ich das auch hier melden.

Hallo Birger,

danke für Deine Rückmeldung.
Würde gerne Unterstützen, insbesondere da ich seit dieser Woche 
ebenfalls Besitzer eines solchen China Krachers (Hauptplatine V4), 
allerdings halten sich meine Programmierkenntnisse sehr in Grenzen.

Mich interessiert neben der Datenschutzschiene (wie kann die Box 
betrieben werden ohne nach Hause zu telefonieren?), in erster Linie die 
Anbindung an eine lokale Steuerung. Also eigener OCPP-Server, Modbus, 
EVCC, PV-Überschussladen etc..
Daher auch meine Frage bzgl. Austausch, da ich den Eindruck gewonnen 
hatte, dass bisher kein Fokus darauf liegt. Ist das für Euch kein Thema 
oder wie könnte eine Roadmap in Deinen Augen ausschauen?

> Mich interessiert neben der Datenschutzschiene (wie kann die Box
> betrieben werden ohne nach Hause zu telefonieren?)
Mit der open source firmware telefoniert natürlich nix mehr nach Hause.

> in erster Linie die Anbindung an eine lokale Steuerung.
> Also eigener OCPP-Server, Modbus, EVCC, PV-Überschussladen etc..
Die Features haben wir weil TinkerForge die implementiert hat. MQTT ist 
das Stichwort.

https://www.warp-charger.com/evcc.html

Allerdings gibt es da Hardware- (keine Phasenumschaltung möglich) und 
Softwarebeschränkungen (die Steuersoftware vom GD Chip kann nur 
Stufenweise die Leistung regeln - die haben wir ja nicht angefasst) bei 
den EN+ Boxen.

> Daher auch meine Frage bzgl. Austausch, da ich den Eindruck gewonnen
> hatte, dass bisher kein Fokus darauf liegt. Ist das für Euch kein Thema
> oder wie könnte eine Roadmap in Deinen Augen ausschauen?

Das ist ganz klar auch im Fokus, denn sonst wäre ja auch Lastmanagement 
nicht möglich.

Und mit einer Roadmap bin ich sehr vorsichtig, weil ist ja letztlich ein 
Hobby.

Ich habe es heute geschafft, die EN+ mit meinem eigenen OCPP-Server zu 
verbinden. Jetzt bleibt alles im Haus. Habe in dem Prozess das Teil 
allerdings bestimmt 6x gebricked und musste die ESP32-FW jeweils neu 
einspielen. Das Teil läuft jetzt seit gut 8h hier zusammen mit einem 
lokalen SteVe-Server, den ich auf einem Raspberry Pi4 laufen habe.
Verwaltung der RF-ID Karten funktioniert ebenfalls. Jetzt muss ich mich 
noch um die charge-profils kümmern, damit ich Lastverteilung testen 
kann.

Constanze H. schrieb:
> Ich habe es heute geschafft, die EN+ mit meinem eigenen OCPP-Server zu
> verbinden.
> Das Teil läuft jetzt seit gut 8h hier zusammen mit einem
> lokalen SteVe-Server, den ich auf einem Raspberry Pi4 laufen habe.
> Verwaltung der RF-ID Karten funktioniert ebenfalls. Jetzt muss ich mich
> noch um die charge-profils kümmern, damit ich Lastverteilung testen
> kann.

Das ist ja sehr spannend. Ich geh mal davon aus, dass du dafür die 
original Firmware nutzt. Welche Versionen (GD und ESP)?

Würde mich sehr interessieren wie du das genau gemacht hast.
Ein bisschen Doku zum nachmachen wäre sehr cool.

Ansonsten wären auch Logs von der Kommunikation bei der RFID Karten 
Verwaltung sehr gut. Einfach mal ne SDCARD reinstecken.

Birger S. schrieb:
> Constanze H. schrieb:
>> Ich habe es heute geschafft, die EN+ mit meinem eigenen OCPP-Server zu
>> verbinden.
>> Das Teil läuft jetzt seit gut 8h hier zusammen mit einem
>> lokalen SteVe-Server, den ich auf einem Raspberry Pi4 laufen habe.
>> Verwaltung der RF-ID Karten funktioniert ebenfalls. Jetzt muss ich mich
>> noch um die charge-profils kümmern, damit ich Lastverteilung testen
>> kann.
>
> Das ist ja sehr spannend. Ich geh mal davon aus, dass du dafür die
> original Firmware nutzt. Welche Versionen (GD und ESP)?
>
> Würde mich sehr interessieren wie du das genau gemacht hast.
> Ein bisschen Doku zum nachmachen wäre sehr cool.
>
> Ansonsten wären auch Logs von der Kommunikation bei der RFID Karten
> Verwaltung sehr gut. Einfach mal ne SDCARD reinstecken.

Hi Birger,
ich habe das auf goingelectric beschrieben. Original FW im GD und ESP32.
Die RFID werden von SteVe verwaltet und freigeben, genau wie bei EN+. 
D.h. eintragen der Karten-ID in SteVe mit Gültigkeitsdauer und 
Transaktionen, der pusht das dann an die WB.
Aber openFW mit 2.x kling auch super spannend, würde ich auch gerne 
mitmachen.

Ich habe ein Prerelease von der V2.0.8 gemacht.

https://github.com/bs-github/esp32-firmware/releases/tag/warpAC011K-2.0.8

Uwe und ich haben das ausprobiert und keine gravierenden Fehler mehr 
gesehen.

Ich würde mich über feedback freuen.

Du kannst ja auch ins OpenSource Lager wechseln (siehe oben). ;-)

Ich möchte bis Anfang Februar auch ein Beta Release der V2.0.11 fertig 
haben.

Hallo,

gibt es jemanden, der die Firmware für mich flashen würde?

Danke

Hallo

Es gibt anscheinend 2 Git für das Projekt

https://github.com/bs-github/esp32-firmware/wiki

hier ist der FW stand bis Dec 2022 aufgelistet

und

https://github.com/warp-more-hardware/esp32-firmware/wiki

auf der hier ist aber keine Firmware zu finden

https://github.com/warp-more-hardware/esp32-firmware/releases

Gruß Michael

Hallo Michael

Michael W. schrieb:
> Es gibt anscheinend 2 Git für das Projekt
> https://github.com/bs-github/esp32-firmware/wiki
> hier ist der FW stand bis Dec 2022 aufgelistet
Von meinem privaten GitHub account dort, sind wir zum Jahreswechsel zu 
warp-more-hardware umgezogen.
Das hab ich jetzt auch im privaten Repo vermerkt und das Repo 
archiviert.

> und https://github.com/warp-more-hardware/esp32-firmware/wiki
> auf der hier ist aber keine Firmware zu finden
> https://github.com/warp-more-hardware/esp32-firmware/releases

Stimmt, bisher haben wir die neue Version noch nicht veröffentlicht.
Und die alten Releases auch nicht rübergezogen, siehe:
https://github.com/warp-more-hardware/esp32-firmware/issues/10 und
https://github.com/warp-more-hardware/esp32-firmware/issues/48

Ich arbeite aber am vermutlich letzten Schritt vor dem Release:
https://github.com/warp-more-hardware/esp32-firmware/pull/49

Das ist dann zwar immer noch nicht 100% Fehlerfrei (z.B. 
https://github.com/warp-more-hardware/esp32-firmware/issues/50), aber 
imho schon auf einem beeindruckenden Stand.

Noch ein wenig Geduld ;-)

Hallo

Alles klar, danke für die Info, eilt nicht war nur verwirrt😵‍💫😵‍💫😁

👍

Gruß
Michael

Ich habe mich entschieden das Release der warp-more-hardware V2.0.12 zu 
machen.
https://github.com/warp-more-hardware/esp32-firmware/releases/tag/warpAC011K-2.0.12

Ganz viel Doku gibts auch!
https://github.com/warp-more-hardware/esp32-firmware/wiki

Das Release basiert auf der Tinkerforge v2.0.11, hat aber spätere 
bugfixes (daher 2.0.12). Der letzte Abgleich ist von vor dem 2.1.0 
Release von Tinkerforge.

Das entscheidende Feature war die Möglichkeit nun auch die Firmware vom 
GD-Chip over the air zu flashen. Damit können alle mit der von uns 
getesteten GD-Firmware arbeiten.
Aber kümmert euch vorher ums Backup!
https://github.com/warp-more-hardware/esp32-firmware/wiki#firmware-backup

Wer helfen möchte, kann auch gerne noch Beispiele für funktionierende 
Konfigurationen beitragen.
Am besten auch dazu ein issue aufmachen und dort gerne schon mit dem 
Dokumentieren anfangen.
https://github.com/warp-more-hardware/esp32-firmware/issues

Oder ihr könnt das Projekt bei github mit einem Stern versehen. Es hat 
nach dem Umzug bisher nur zwei Sternchen :-(.

Und wenn ihr über Probleme stolpert, bitte ich euch bei 
Fehlerbeschreibungen immer auch ein Debug Log zu speichern (ohne das ist 
eine Fehlersuche soooo viel schwerer) und ein Issue auf github 
aufzumachen.
https://github.com/warp-more-hardware/esp32-firmware/issues

Hello

Thank you for your effort.
I have this box - PowerFed Home 11kw-1 - AC11000-AE-25

I think MAYBE is a newer version.

I don't see any SD card slot!

I can only control it via the mobile app - ChargeIn.
I did not find any OCCP settings in the app.

Please see the pictures.
I'll try to make a backup for the GD-Chip and ESP32 firmware.
I've ordered an ST-Link V2 Mini STM32 USB programming stick.

Later Edit.
I've read the wiki, I'll get to work!
The MicroSD is on the back ;)
Fat32?
32Gb?