Hallo zusammen, ich habe hier einen D1 Mini ESP32 (ESP32-WROOM-32), den ich gerne mit tasmota flashen möchte.
Leider komme ich damit trotz stundenlanger Suche überhaupt nicht weiter, tasmotizer meldet "Invalid head of packet (0x46)", beim online flash-tool kommt eine andere Fehlermeldung (konnte nicht initialisiert werden...), flash_download_tool_3.9.4 startet nicht... usw.
Bin so langsam am durchdrehen, es muss doch irgendwo eine einfache Anleitung geben, wie dabei per Win10-Laptop vorzugehen ist.
Kann mir hierbei jemand auf die Sprünge helfen?
6x 300Wp = 1.8kWp an 3x EVT560 MicroInverter - MultiPlus-II GX mit 4x PylonTech US2000 (je 2,4kWh)
Hier klicken, wenn du Kollegen in deiner Umgebung finden möchtest.
OK, anscheinend nicht.
Der ESP32 ist eigentlich dazu gedacht, eine Datenverbindung vom SOLAX WR zu meinem MP2 herzustellen.
@und-mehr hatte mal gemeint, das sei relativ simpel ich habe es mit seiner Unterstützung versucht, wir haben es nicht hinbekommen.
Mit breakout-board (RS485) und tasmota auf einem ESP8266 kamen keine Daten.
Tasmota auf den o.a. ESP32 Chip zu flashen hat nicht geklappt.
Für ESP-Home bekomme ich keine vernünftige .bin firmware zu Stande, mit der ich den Chip programmieren könnte... und habe auch keine Ahnung, zu welchem Ziel das führen würde.
Hat denn überhaupt schon jemand eine Datenübertragung von z.B. SOLAX-X1 zum MP2 bzw. Cerbo hinbekommen?
6x 300Wp = 1.8kWp an 3x EVT560 MicroInverter - MultiPlus-II GX mit 4x PylonTech US2000 (je 2,4kWh)
Hier klicken, wenn du Kollegen in deiner Umgebung finden möchtest.
Ist dein USB Kabel defekt?
"Geht nitt" ist genauso keine Fehlerbeschreibung wie "ich mach alles richtig"...
Beschreib, was genau du tust und was genau nicht funktioniert.
bekommst du was anders drauf?
womit verbindest dich drauf, wird com-port aktiv, blinken die LEDs?
Single core SoCs do not work with standard binaries, for those use only
tasmota32solo1.binor compile your own binary using the tasmota32solo1 environment.
Sollten in diesem Beitrag links zu anderen Webseiten enthalten sein, bitte ich das raumgreifende Design zu entschuldigen. Das war nicht beabsichtigt.
Hallo zusammen, danke für eure Antworten!
@jay Nein, mein USB-Kabel kann da nix dafür, das Problem bin schon ICH. Bin komplett neu in der Materie, hab mal ein, zwei WIFI-Steckdosen geflasht, aber ansonsten bin ich ziemlich blank. Mit @und-mehr 's Hilfe habe ich ein paar erste Schritte geschafft... vielen Dank dafür!
Ich würde das alles gern ein wenig besser verstehen, und bin für jeden Tipp dankbar. Hab nun schon viele Stunden mit Einlesen und trial-and-error befasst, ganze Nächte damit zugebracht, alle möglichen (anscheinend erforderliche) Programme installiert... usw. aber das ist ganz schön viel auf einmal, wenn man damit noch nicht viel zu tun hatte.
@jarek, zuerst hab ich auf den ESP32 gar nichts draufgebracht... hatte das mit dem tasmotizer versucht. Com-Port passt, den fehlenden Win-Treiber habe ich nachinstalliert.
und mehr, du bist ein Held! Mit tasmota32solo1.bin hat es geklappt, den ESP32 in Betrieb zu nehmen. Woher weißt du das, wo finde ich sowas, hast du 'nen link, wo das steht? Vielleicht komme ich nächstes mal selber drauf.
Fehler 1: falsche firmware
Fehler 2: mit tasmotizer scheint das bei dem board nicht zu klappen... "Invalid head of packet (0x46)" Warum auch immer.
Was habe ich bisher gemacht:
SOLAX-X1 an Hailege TTL to RS485 485 to Serial UART Level Reciprocal Hardware Automatic Flow Control UART to RS485 Converter RS485 to TTL
ESP8266-12F WLAN Module AZDelivery D1 Mini NodeMcu mit ESP8266-12F WLAN Module CH340G Lua kompatibel mit Arduino
mit tasmota geflasht und verbunden.
Tasmota-development als .zip runtergeladen, ein paar Zeilen für SOLAX eingebaut, mit VisualStudioCode neu kompiliert, geflasht.
Alles funktioniert, nur vom SOLAX kommen keine Daten.
txd blinkt im 5-Sekunden Takt, rxd bleibt aus. Wenn ich rx und tx tausche, ist es entsprechend umgekehrt. Wenn ich das richtig verstehe, sendet der ESP8266 Anfragen, bekommt aber keine Antwort.
Der Anschluss am SOLAX sollte passen, ist ein RJ45-Stecker, bei dem laut Handbuch die pins 3, 4, 5 belegt werden sollen.
Im Grunde habe ich das gleiche dann nochmal mit einem anderen BreakOut-Board und einem anderen WLAN-Modul versucht.
SOLAX-X1 an DollaTek RS485A TTL Modul SP3485 RS485 Kommunikationsmodul Breakout Board
ESP32 D1 Mini NodeMCU WiFi Modul + Bluetooth Internet Entwicklungsboard kompatibel mit Arduino
Und eigentlich bekomme ich damit -nachdem es heute gelungen ist, den ESP32 D1 Mini mit tasmota zu flashen- das gleiche Ergebnis:
Alles funktioniert, nur vom SOLAX kommen keine Daten.
Vielleicht hat jemand noch eine Idee dazu?
PS: beim SOLAX gibt es ein paar Einstellungen, die mir interessant erscheinen:
ExportControl bezieht sich vermutlich nur auf den Anschluss eines Zählers. Auswahl: "meter", "CT", "disable". Habe alle durchprobiert, würde das auf "disable" lassen. "meter" bedeutet wohl, dass ein geeigneter SmartMeter abgefragt wird, "CT" würde ich als current-transformer interpretieren.
Wenn ich auf "meter" umstelle, beginnt die tx-LED hektisch zu blinken, der SOLAX fragt nach Daten, bekommt aber keine, weil kein SmartMeter angeschlossen ist. Dann kommt ein Fehler, und der SOLAX schaltet ab. In diesem Zusammenhang wurde sogar schon einmal die Serien-Nummer des SOLAX an den ESP32 übertragen.
Modbus RTU enable habe ich auf "enable" gestellt. Modbus adress steht auf 1.
6x 300Wp = 1.8kWp an 3x EVT560 MicroInverter - MultiPlus-II GX mit 4x PylonTech US2000 (je 2,4kWh)
Hier klicken, wenn du Kollegen in deiner Umgebung finden möchtest.
Ich habe keinen Solax aber einen Sun2000 von Huawei. Den habe ich mit ESPHome ausgelesen. Welchen Modbustreiber verwendest du?
Zum Auslesen musst du ja die Register vom Solax kennen und die baud rate muss stimmen.
EspHome finde ich genial da es dir eine Custom Firmware baut und OTA Updates ermöglicht.
Noch ne Frage. Wie möchtest du die Daten in den Cerbro rein bekommen? Auch per Modbus?
Welchen Serialport hast du verwendet? Der erste Port ist IdR von der Seriellen Konsole belegt, wenigstens bei ESPHome. Nutz mal den zweiten oder noch besser schalt das logging ab. So hat es bei mir geklappt.
Wenn du möchtest kann ich dir mal mein yaml geben 😉
Wie gesagt: bin völliger Anfänger, deswegen erhoffe ich mir hier mehr Antworten, als Fragen... 😉
Welchen Modbustreiber verwendest du?
Keine Ahnung, wo kann ich das sehen?
BaudRate sollte mit 9600 passen... ansonsten: wo stelle ich das ein?
Mit EspHome hab ich mich schon stunden- und nächtelang beschäftigt, ohne je einen grünen Zweig zu finden.
Noch ne Frage. Wie möchtest du die Daten in den Cerbro rein bekommen? Auch per Modbus?
Keine Ahnung... wie macht man das?
Damit steht und fällt natürlich mein ganzes Vorhaben. Das wäre ja das Ziel: die Daten dem Cerbo zur Verfügung zu stellen.
Welchen Serialport hast du verwendet? Der erste Port ist IdR von der Seriellen Konsole belegt, wenigstens bei ESPHome. Nutz mal den zweiten oder noch besser schalt das logging ab. So hat es bei mir geklappt.
Klingt interessant, sagt mir aber gar nichts.
6x 300Wp = 1.8kWp an 3x EVT560 MicroInverter - MultiPlus-II GX mit 4x PylonTech US2000 (je 2,4kWh)
Hier klicken, wenn du Kollegen in deiner Umgebung finden möchtest.
Also zu Solax und Tasmota habe ich das hier https://tasmota.github.io/docs/SolaX-X1/ gefunden. Ich denke das kennst du schon. Da der Treiber nicht im pre-compiled Binary enthalten ist musst du Tasmota selber kompilieren.
Ich kenne mich mit Tasmato leider nicht gut aus und kann dir daher keine Anleitung liefern wie du das machen kannst.
Zur Integration in Venus OS.
Du kannst die Daten via MQTT übertragen. Dazu musst du aber die von Victron verwendeten MQTT Adressen / URLs verwenden.
Die Daten werden dann von MQTT in DBus Adressen umgewandelt. Das macht der Cerebro dann wenn der MQTT Server läuft.
Hier https://github.com/victronenergy/venus/wiki/dbus findest du eine Liste von Services die Victron via DBUS bereit stellt
und hier https://github.com/victronenergy/dbus-mqtt eine Beschreibung wie MQTT bei Victron funktioniert.
Ich habe den MQTT Explorer verwendet um mir die Daten anzusehen die auf dem Mosquitto zur Verfügung stehen:
Folgendes musst du also machen:
1) Eigene Firmware für Tasmota bauen damit der Solax Treiber drin ist
2) Die Daten aus dem Solax Treiber auf die korrekten MQTT Adressen mappen
3) Im Cerebro MQTT aktivieren
Ich habe übrigens die Daten vom SUN2000 nur in Home Assistant drin und nicht im Venus OS. Für die Laderegelung verwende ich noch ein EM24.
Ich bin noch über das Projekt hier: https://github.com/fabian-lauer/dbus-solax-x1-pvinverter gestolpert.
Da werden die Daten aus der Solax Cloud geholt. Wär jetzt auch nicht mein Favorit aber wenn du den Cloud Zugang schon hast ...
Für ESP-Home bekomme ich keine vernünftige .bin firmware zu Stande, mit der ich den Chip programmieren könnte... und habe auch keine Ahnung, zu welchem Ziel das führen würde.
Ich gucke heute Abend mal ob ich ne Firmaware für den Solax mit ESPHome compiliert bekomme.
Das Ziel ESPHome,
- die Solaximplementation ist von Syssi, der Hilft sehr gern und schnell, ich weiß aber nicht ober selbst auch einen Solax hat.
- Esphome ist nicht so unflexibel wir Tasmota, die ganzen Rules und Setoptions fallen weg weil man die Logik dort selbst kontrolliert.
Mit Tasmota kenne ich mich nicht mehr aus, ich nutze das eigentlich nur noch als Zigbee-MQTT Gateway und für Rollos, da müsste ich mich einlesen um damit das selbe machen zu können was esphome kann ohne was lesen zu müssen.
Woher weißt du das, wo finde ich sowas, hast du 'nen link, wo das steht? Vielleicht komme ich nächstes mal selber drauf.
Mit Google Tasmota ESP32 hatte ich den Treffer gleich im ersten Link.
https://tasmota.github.io/docs/ESP32/#flashing
Das hier währe sicher auch gegangen wenn da ein normaler ESP32 drauf ist, hatte aber gestern wenig Zeit. Mir war nur klar das du das falsche bin benutzt.
Uncomment the tasmota32xxx build you want to compile in
platformio_override.ini. For example, uncommenting tasmota32 will buildtasmota32.binon the next Build task in Platformio.
Sollten in diesem Beitrag links zu anderen Webseiten enthalten sein, bitte ich das raumgreifende Design zu entschuldigen. Das war nicht beabsichtigt.
Ok, wenn es Richtung ESPHome geht: Da kannst du die MQTT konfiguration direkt in der yaml-Datei machen. Der Treiber von Syssi kann ja den Modbus-Part schon. Jetzt musst du die Signal die via Modbus kommen noch mit MQTT veröffentlichen. Das geht über eine Konfiguration in der yaml-Datei.
Die Pfade kannst du dir oben aus dem Cloud Projekt von Fabian Lauer raus kopieren:
paths={
'/Ac/Energy/Forward': {'initial': 0, 'textformat': _kwh},
'/Ac/Power': {'initial': 0, 'textformat': _w},
'/Ac/Current': {'initial': 0, 'textformat': _a},
'/Ac/Voltage': {'initial': 0, 'textformat': _v},
'/Ac/[*Phase*]/Voltage': {'initial': 0, 'textformat': _v},
'/Ac/[*Phase*]/Current': {'initial': 0, 'textformat': _a},
'/Ac/[*Phase*]/Power': {'initial': 0, 'textformat': _w},
'/Ac/[*Phase*]/Energy/Forward': {'initial': 0, 'textformat': _kwh},
})
Es klemmt nur weil der Solax nicht antwortet.
Für gx hab ich ne MQTT gefütterte universelle Anbindung für 1phasige WR (das ist "relativ simple").
Sollten in diesem Beitrag links zu anderen Webseiten enthalten sein, bitte ich das raumgreifende Design zu entschuldigen. Das war nicht beabsichtigt.
Es klemmt nur weil der Solax nicht antwortet.
Für gx hab ich ne MQTT gefütterte universelle Anbindung für 1phasige WR (das ist "relativ simple").
Könntest du die bitte mal einstellen? Dann kann ich den SUN2000 ggf. noch in das Victron Universum integrieren 
Warum der Solax nicht antwortetet ist aus der Ferne schwierig zu beantworten.
Folgend Punkte könntet ihr prüfen:
- Serial Port auf dem ESP ggf. durch logger belegt?
- Baudrate korrekt (würde ich mal auf 9600 setzen)?
- Modbus RTU im Solax eingeschaltet (der SUN2000 hat zwei Modbus-Ports, ggf. ist das beim Solax auch so, da dann den korrekten Port nehmen)?
- Mal mit einer Modbus-Adresse (z.B. Serialnummer) probieren ob wenigstens ein Telegramm kommt?
- Korrekte Unit-Number im Modbus konfiguriert (bei dir war das ja die 1)?
- Ich musste A+ auf A+ und B- auf B- klemmen (hab das gleiche RS485 Module wie du)
Bei ESP-Home dann in die Logs schauen. Wenn das Serial-Logging abgeschaltet ist kannst du die Logs mit esphome logs <deine.yaml> abrufen.
Hier mal ein Schnipsel mit meiner Modbus-Konfiguration für den Sun2000
substitutions:
device_name: "huwaei-sun2000-3680"
esphome:
name: ${device_name}
esp8266:
board: d1_mini
# Enable logging
logger:
baud_rate: 0 # disable serial logger
# hardware_uart: UART0_SWAP
api: !include _api.yaml
ota: !include _ota.yaml
wifi: !include _wifi.yaml
switch:
- platform: restart
name: "Restart"
uart:
baud_rate: 9600
data_bits: 8
id: mod_bus
parity: NONE
rx_buffer_size: 1024
rx_pin: GPIO03
stop_bits: 1
tx_pin: GPIO01
modbus:
id: modbus1
modbus_controller:
- id: huawei_inverter
address: 150
modbus_id: modbus1
setup_priority: -10
command_throttle: 750ms
update_interval: 15s
text_sensor:
# Range 30000 - 30035
- name: "Huawei inverter model"
icon: "mdi:information"
platform: modbus_controller
modbus_controller_id: huawei_inverter
register_type: holding
address: 30000
register_count: 15
response_size: 30
skip_updates: 100
- name: "Huawei inverter SN"
icon: "mdi:information"
platform: modbus_controller
modbus_controller_id: huawei_inverter
register_type: holding
address: 30015
register_count: 10
response_size: 20
skip_updates: 100
# Inverter status string
- name: "Huawei inverter status"
platform: template
id: inverter_status_string
icon: "mdi:information"
sensor:
- name: "Huawei inverter device status code"
icon: "mdi:information"
platform: modbus_controller
modbus_controller_id: huawei_inverter
register_type: holding
address: 32089
value_type: U_WORD
on_value:
- text_sensor.template.publish:
id: inverter_status_string
state: !lambda |-
int code = (int)x;
switch (code) {
case 0x0000:
return {"Standby: initializing"};
case 0x0001:
return {"Standby: detecting insulation resistance"};
case 0x0002:
return {"Standby: detecting irradiation"};
case 0x0003:
return {"Standby: grid detecting"};
case 0x0100:
return {"Starting"};
case 0x0200:
return {"On-grid (Off-grid mode: running)"};
case 0x0201:
return {"Grid connection: power limited (Off-grid mode: running: power limited)"};
case 0x0202:
return {"Grid connection: self-derating (Off-grid mode: running: self-derating"};
case 0x0203:
return {"Off-grid Running"};
case 0x0300:
return {"Shutdown: fault"};
case 0x0301:
return {"Shutdown: command"};
case 0x0302:
return {"Shutdown: OVGR"};
case 0x0303:
return {"Shutdown: communication disconnected"};
case 0x0304:
return {"Shutdown: power limited"};
case 0x0305:
return {"Shutdown: manual startup required"};
case 0x0306:
return {"Shutdown: DC switches disconnected"};
case 0x0307:
return {"Shutdown: rapid cutoff"};
case 0x0308:
return {"Shutdown: input underpower"};
case 0x0401:
return {"Grid scheduling: cosφ-P curve"};
case 0x0402:
return {"Grid scheduling: Q-U curve"};
case 0x0403:
return {"Grid scheduling: PF-U curve"};
case 0x0404:
return {"Grid scheduling: dry contact"};
case 0x0405:
return {"Grid scheduling: Q-P curve"};
case 0x0500:
return {"Spot-check ready"};
case 0x0501:
return {"Spot-checking"};
case 0x0600:
return {"Inspecting"};
case 0x0700:
return {"AFCI self check"};
case 0x0800:
return {"I-V scanning"};
case 0x0900:
return {"DC input detection"};
case 0x0A00:
return {"Running: off-grid charging"};
case 0xA000:
return {"Standby: no irradiation"};
default:
return {"Unknown state code"};
}
...