SOLAX: tasmota oder ESPHome auf ESP8266 und ESP32 flashen

@saugnapf Die Zeilen mit "#" musst du nicht ändern, das Zeichen "#" bedeutet das die Zeile auskommentiert ist.

# sind auskementierte Zeilen (esp32 und 2866 nutzen die selbe yaml,
Standard ist esp32 aktiv (weil ich es als 2. compliert hatte),
das was mit ## 8266 markiert ist war für das 2866 bin aktiv.

Es gibt ein Grund gpio1 nicht zu verwenden, beim booten gehen die ESPs da auch Texte raus, das könnte bei eigen zuhören zu unerwarteten Zuständen führen.
Im Zweifel lieber vermeiden, die Gefahr ist gering aber nicht null.
https://github.com/syssi/esphome-jk-bms/issues/28

Veröffentlicht von: @und-mehr

↑

beim booten gehen die ESPs da auch Texte raus,

Bei mir hat nur GIO1 und 3 mit RS485 Adapter funktioniert beim 8266.

Oder einen ESP32 verwenden der hat 3 Serielle Schnittstellen

Veröffentlicht von: @und-mehr

↑

https://github.com/user0x01/venus-mqtt-pvinverter

Beispielkonfig esphome:
https://github.com/user0x01/venus-mqtt-pvinverter/blob/main/pvinverters/esphome_example_soyosourcewifi.yaml

Key ist der Schlüssel um mehrere Instanzen von PV Invertern auseinanderzuhalten

venus_update steckt hier im Sensor temperature,
habe nachgesehen welches der letzte Sensor ist der refresh wird.
Eigentlich bräuchte man dafür einen extra event, aber da ne extra branch aufzumachen war mir zu aufwändig

 

Sehr cool ! Danke

Dank eurer Hilfe habe ich nun schon deutlich mehr Durchblick! Super, vielen Dank!

Inzwischen habe ich wohl alle Varianten durchprobiert, also GPIO1/3, GPIO4/5, mit und ohne logging.

Das Ergebnis ist immer gleich: TX blinkt, RX bleibt aus.

Kann das ganze nun nochmal mit dem zweiten ESP32 versuchen, aber ich vermute eher, dass ich den Fehler beim SOLAX suchen muss.

Es wird wohl einfach daran liegen, dass der nicht antwortet. Einstellen kann ich da eigentlich nur modbus_rtu auf aktiviert, und eine modbus adresse.

Die modbus-adresse ist voreingestellt auf 1 gesetzt.

Gibt es dazu andere Vorschläge oder Ideen?

Oder muss ich hier "modbus0 durch modbus1 ersetzen?

uart:
id: uart0
baud_rate: 9600
tx_pin: ${tx_pin}
rx_pin: ${rx_pin}

solax_modbus:
- id: modbus0
uart_id: uart0
# flow_control_pin: GPIO0

solax_x1_mini:
solax_modbus_id: modbus0
update_interval: 1s

Nein, das yaml von Syssi sollte gehen, ich hab da nichts verbessert, außer wifi rausgestochen und web server dazugefügt.

Wenn du mal ein Log davon hast dann poste es hier:
https://github.com/syssi/esphome-solax-x1-mini/issues
Stell den Solax auf Senden und gucket ob im Log was ankommt

Er hat die Komponente geschrieben und weiß am besten was im Log zu sehen sein muss und was nicht.

Moin,

das ist genau ein Teil meines geplanten Settings, Solax X1, Soyosource und Huawei R4850G2 über MQTT (ESPHome) als Gerät am dbus anmelden.
Ich habe zwar einen X1 Boost, aber vom Stecker bis zum Protokoll scheint alles identisch zu sein.

@saugnapf

Ich komme leider erst frühestens am Wochenende dazu es selber zu testen. Bei dem was ich bis jetzt gelesen habe, würde ich den Fehler aber im Aufbau und in den Einstellungen im Solax suchen. Hast du die Baudrate noch einmal auf 9600 überprüft? Wenn ich es richtig verstanden habe, dürfte die Adresse bislang keine Rolle spielen.

Veröffentlicht von: @saugnapf

↑

Der Anschluss am SOLAX sollte passen, ist ein RJ45-Stecker, bei dem laut Handbuch die pins 3, 4, 5 belegt werden sollen.

-- attachment is not available --

Hast du dir den Stecker nochmal angesehen? Sind das wirklich die Pins 3,4 und 5?

Hier steht was von 4,5 und 7.

https://github.com/syssi/esphome-solax-x1-mini#x1-mini-rj45-connector

Ja, ist wahrscheinlich eine gute Idee. Sonst würde ich mal im PV-Forum anfragen, wie man den Solax X1 zum sprechen bringt.

Upps, das war die Antwort auf und-mehr.

Hi @nadors 

habe auch den X1 boost, also nicht den mini. 

Einstellungen zur Baudrate habe ich eigentlich nur hier gefunden:

uart:
  id: uart0
  baud_rate: 9600
  tx_pin: ${tx_pin}
  rx_pin: ${rx_pin}

Gehe mal davon aus, dass das die richtige Einstellung ist. Die 9600 stehen auch so im Communication Protocol.

Was den Stecker betrifft: pin 4 und 5 sind die beiden mittleren, die sind wichtig, weil A+ und B-. GND braucht man nach meinen Erkenntnissen nicht unbedingt, und es ist vermutlich egal, ob du da Pin 3 oder Pin 7 nimmst... sind beide GND.

Hätte da noch zwei Fragen, die mir unter den pins brennen:

1.- gibt es ein tool, mit dem man eine firmware.bin aus einem (beliebigen) ESP-chip rausholen, bzw. sichern kann?

Also etwa so wie beim firmware-backkup mit dem tasmotizer?

2.- wie oder mit welchem tool kann man eine .bin Datei wieder entpacken, ggf. bearbeiten, und wieder compilieren?

Hintergrund: es gibt ja einen USB-Stick für den SOLAX X1. Der heißt z.B. Solax | Pocket WIFI-Interface V3.0

Der bekommt eigentlich alle Daten vom WR, um sie in die SOLAX-Cloud zu senden. Wenn man den aufmacht, kommt -oh Wunder- ein ESP32 zum Vorschein.

Das Teil würde ich gerne passend flashen, so dass die Daten nicht in der Cloud, sondern lokal hier in meinem Netz landen. Man muss ja das Rad nicht immer zweimal erfinden...

Leider wird kein serial-port verfügbar gemacht, wenn ich den Stick an mein Laptop anstecke. Insofern habe ich erstmal keinen Zugriff auf die firmware, kann da auch nichts draufschreiben.

Auf der Rückseite, versteckt unter der erweiterten WIFI-Antenne, gibt es ein paar Pins:

Könnte man den Chip direkt ansprechen und programmieren?

Wenn man hier ein paar Drähtchen anlötet, und die mit einem RS485 USB-to-serial Adapter verbindet?

Oder könnte man hier einen ESP32 dranhängen, der die Daten dann vom Pocket-WIFI in's Heimnetz bringt?

Ich denke schon das du den auslesen kannst.

Nur wird das Ergebnis nicht dem entsprechen was du erwartest. Du bekommst da keinen schön formatierten Quellcode raus. Wenn du das vor hast musst du dich gut in C / C++ und Assembler auskennen um aus dem Binary auf den Quellcode schliessen zu können.

Von esprssif gibt es ein Python-Script mit dem du das Binary bzw. den Flash auslesen kannst, dass kannst du dann in Assembler konvertieren.

Um das Problem mal einzugrenzen hätte ich folgende Vorschläge:

• Bitte poste mal deine komplette yaml.
• Kannst du mal das Log vom ESPHome posten?
• Verwendest du eine ESP8266 oder einen ESP32?
• Verkabelung prüfen (hast du wahrscheinlich schon 100x gemacht) und am Besten durch messen. GRD hab ich auch nicht angeschlossen. Kannst du aber mal probieren.
• Hast du noch einen weiteren ESP mit dem du mal testen kannst? Mach mal sind die Teile einfach kaputt.
• Gibt es eine Möglichkeit mit der du den Modbus-Port vom SOLAX testen kannst?
• Hast du noch eine weiter RS485 Adapter-Platine die du probieren kannst?

Hier noch der Link zum Flash-Download Tool: https://www.espressif.com/en/support/download/other-tools

Hier eine Anleitung zum reverse engineering: https://olof-astrand.medium.com/reverse-engineering-of-esp32-flash-dumps-with-ghidra-or-ida-pro-8c7c58871e68

Und hier noch der Link zum espressif bootloader (esptool.py) https://github.com/espressif/esptool

Also im Log sieht man das die Discovery Broadcast Nachricht geschickt wird:

TX -> AA.55.01.00.00.00.10.00.00.01.10 (11)

Es kommt aber keine Antwort dazu zurück.

Hier https://github.com/syssi/esphome-solax-x1-mini#discovery das Beispiel vom erfolgreichen Discovery.

Deine Konfiguration sieht gut aus für einen ESP32.

Das RS485 Board hast du ja bestimmt auch korrekt mit dem ESP verbunden...

• RX -> GPIO 16
• TX -> GPIO 17
• GND -> GND
• VCC -> 3,3V

und

• A+ -> 4
• B- -> 5

Am ESP32 liegt es jetzt wahrscheinlich nicht, sondern an der RS485 Kommunikation.

Der SOLAX muss auf das Discovery antworten.

Ja, das müsste alles richtig angeschlossen sein.

GPIO16 und 17 habe ich mal mit RX/TX und mal mit TX/RX belegt.

Denke, richtig ist es, wenn die TX LED blinkt wenn das board eine Anfrage sendet.