UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[Homer 0]

Hat wirklich noch keiner die direkte Anbindung des Sun2000 über den Modbus-Adapter hinbekommen? Ich scheitere offensichtlich an der gleichen Stelle:

2022-11-01 17:42:27.677 - info: host.raspberrypi4 instance system.adapter.modbus.1 started with pid 17214
2022-11-01 17:42:28.908 - debug: modbus.1 (17214) Redis Objects: Use Redis connection: 127.0.0.1:9001
2022-11-01 17:42:28.950 - debug: modbus.1 (17214) Objects client ready ... initialize now
2022-11-01 17:42:28.953 - debug: modbus.1 (17214) Objects create System PubSub Client
2022-11-01 17:42:28.954 - debug: modbus.1 (17214) Objects create User PubSub Client
2022-11-01 17:42:28.987 - debug: modbus.1 (17214) Objects client initialize lua scripts
2022-11-01 17:42:29.009 - debug: modbus.1 (17214) Objects connected to redis: 127.0.0.1:9001
2022-11-01 17:42:29.036 - debug: modbus.1 (17214) Redis States: Use Redis connection: 127.0.0.1:9000
2022-11-01 17:42:29.050 - debug: modbus.1 (17214) States create System PubSub Client
2022-11-01 17:42:29.052 - debug: modbus.1 (17214) States create User PubSub Client
2022-11-01 17:42:29.074 - debug: modbus.1 (17214) States connected to redis: 127.0.0.1:9000
2022-11-01 17:42:29.161 - debug: modbus.1 (17214) Plugin sentry Initialize Plugin (enabled=true)
2022-11-01 17:42:29.621 - info: modbus.1 (17214) starting. Version 5.0.4 in /opt/iobroker/node_modules/iobroker.modbus, node: v16.17.0, js-controller: 4.0.23
2022-11-01 17:42:29.800 - debug: modbus.1 (17214) Initialize Objects for disInputs: []
2022-11-01 17:42:29.801 - debug: modbus.1 (17214) Initialize Objects for coils: []
2022-11-01 17:42:29.802 - debug: modbus.1 (17214) Initialize Objects for inputRegs: []
2022-11-01 17:42:29.803 - debug: modbus.1 (17214) Initialize Objects for holdingRegs: [{"_address":37101,"name":"","description":"","unit":"","type":"uint32le","len":2,"factor":1,"offset":0,"formula":"","role":"level","room":"","poll":true,"wp":"","cw":"","isScale":"","deviceId":1,"address":37101,"id":"holdingRegisters.37101"},{"_address":37107,"name":"","description":"","unit":"","type":"int32le","len":2,"factor":1,"offset":0,"formula":"","role":"level","room":"","poll":true,"wp":"","cw":"","isScale":"","deviceId":1,"address":37107,"id":"holdingRegisters.37107"},{"_address":37113,"name":"","description":"","unit":"","type":"uint32le","len":2,"factor":1,"offset":0,"formula":"","role":"level","room":"","poll":true,"wp":"","cw":"","isScale":"","deviceId":1,"address":37113,"id":"holdingRegisters.37113"},{"_address":40572,"name":"","description":"","unit":"","type":"int16le","len":1,"factor":1,"offset":0,"formula":"","role":"level","room":"","poll":true,"wp":"","cw":"","isScale":"","address":40572,"deviceId":1,"id":"holdingRegisters.40572"},{"_address":40573,"name":"","description":"","unit":"","type":"int16be","len":1,"factor":1,"offset":0,"formula":"","role":"level","room":"","poll":true,"wp":"","cw":"","isScale":"","address":40573,"deviceId":1,"id":"holdingRegisters.40573"},{"_address":40574,"name":"","description":"","unit":"","type":"int16be","len":1,"factor":1,"offset":0,"formula":"","role":"level","room":"","poll":true,"wp":"","cw":"","isScale":"","address":40574,"deviceId":1,"id":"holdingRegisters.40574"}]
2022-11-01 17:42:29.804 - debug: modbus.1 (17214) Add holdingRegisters.37101: {"_id":"holdingRegisters.37101","type":"state","common":{"name":"","role":"level","type":"number","read":true,"write":true,"def":0,"unit":""},"native":{"regType":"holdingRegs","address":37101,"deviceId":1,"type":"uint32le","len":2,"offset":0,"factor":1,"poll":true}}
2022-11-01 17:42:29.805 - debug: modbus.1 (17214) Add holdingRegisters.37107: {"_id":"holdingRegisters.37107","type":"state","common":{"name":"","role":"level","type":"number","read":true,"write":true,"def":0,"unit":""},"native":{"regType":"holdingRegs","address":37107,"deviceId":1,"type":"int32le","len":2,"offset":0,"factor":1,"poll":true}}
2022-11-01 17:42:29.805 - debug: modbus.1 (17214) Add holdingRegisters.37113: {"_id":"holdingRegisters.37113","type":"state","common":{"name":"","role":"level","type":"number","read":true,"write":true,"def":0,"unit":""},"native":{"regType":"holdingRegs","address":37113,"deviceId":1,"type":"uint32le","len":2,"offset":0,"factor":1,"poll":true}}
2022-11-01 17:42:29.806 - debug: modbus.1 (17214) Add holdingRegisters.40572: {"_id":"holdingRegisters.40572","type":"state","common":{"name":"","role":"level","type":"number","read":true,"write":true,"def":0,"unit":""},"native":{"regType":"holdingRegs","address":40572,"deviceId":1,"type":"int16le","len":1,"offset":0,"factor":1,"poll":true}}
2022-11-01 17:42:29.807 - debug: modbus.1 (17214) Add holdingRegisters.40573: {"_id":"holdingRegisters.40573","type":"state","common":{"name":"","role":"level","type":"number","read":true,"write":true,"def":0,"unit":""},"native":{"regType":"holdingRegs","address":40573,"deviceId":1,"type":"int16be","len":1,"offset":0,"factor":1,"poll":true}}
2022-11-01 17:42:29.808 - debug: modbus.1 (17214) Add holdingRegisters.40574: {"_id":"holdingRegisters.40574","type":"state","common":{"name":"","role":"level","type":"number","read":true,"write":true,"def":0,"unit":""},"native":{"regType":"holdingRegs","address":40574,"deviceId":1,"type":"int16be","len":1,"offset":0,"factor":1,"poll":true}}
2022-11-01 17:42:30.140 - info: modbus.1 (17214) Connected to slave 192.168.2.184
2022-11-01 17:42:30.141 - debug: modbus.1 (17214) [DevID_1] Poll start ---------------------
2022-11-01 17:42:30.143 - debug: modbus.1 (17214) Initialization of scale factors done!
2022-11-01 17:42:30.144 - debug: modbus.1 (17214) [DevID_1/holdingRegs] Poll address 37101 - 14 registers
2022-11-01 17:42:30.650 - warn: modbus.1 (17214) Error: undefined
2022-11-01 17:42:30.651 - error: modbus.1 (17214) Request timed out.
2022-11-01 17:42:30.652 - error: modbus.1 (17214) Client in error state.
2022-11-01 17:42:30.653 - warn: modbus.1 (17214) Poll error count: 1 code: {"err":"timeout","timeout":500}
2022-11-01 17:42:30.655 - debug: modbus.1 (17214) Socket closed with error
2022-11-01 17:42:30.656 - debug: modbus.1 (17214) Clearing timeout of the current request.
2022-11-01 17:42:30.657 - debug: modbus.1 (17214) Cleaning up request fifo.
2022-11-01 17:42:31.653 - debug: modbus.1 (17214) Closing client on purpose.
2022-11-01 17:42:31.654 - info: modbus.1 (17214) Disconnected from slave 192.168.2.184

Das muss ja am Modbus-Adapter liegen, da die Abfrage mit anderen Modbus-Tools funktioniert.
Jemand ne Idee?

[badsnoopy667]

@homer-0
Möchtest Du dafür vielleicht einen eigenen Thread aufmachen? Sonst wird das hier noch unübersichtlicher. Mit node-red geht es ja.

[Homer 0]

Ja sorry.
Habs hierhin gepackt:
https://forum.iobroker.net/topic/48138/iobroker-huawei-sun2000-modus-adapter-keine-daten/38?_=1667374096982

[lub104]

Hallo Leute, ich habe das System am laufen inklusive Grafana, ich habe aber noch ein Verständnis Problem zum Tagesgesamtertrag.
Der Wert Daily Energy Yield zeigt mir nicht den Gesamten Ertrag, ist es richtig das was in den Akku gespeist wird, wird nicht mit gerechnet?
Wenn meine Vermutung richtig ist kann man die zwei Werte im Flow zusammen rechnen.
Gruß Andy

[Heinzileilei]

@lub104 Hi Wie bekommst du die Daten in den Iobroker ? Hab alles nach Anleitung gemacht aber bekomme keine Verbindung ? Mit ModPV auf windows bekomme ich aber Daten. Danke Lg ( Vielleicht könntest du deinen Flow teilen )

[mickym]

@heinzileilei Wenn Du die Daten in Deinem Flow hast, dann schreibst Du halt die Daten über die iobroker-out NOde in den iobroker.

[Heinzileilei]

@mickym

Danke für deine Unterstüzung leider bekomme ich keine Daten herrein.

[mickym]

@heinzileilei Ok - dann kann ich leider auch nicht helfen, da ich die HW nicht habe. Dachte Du bekommst die Daten in NodeRed und hast nur Probleme, die in den iobroker zu schreiben, aber Du bekommst ja die Daten nicht in NodeRed.

Also tut mir leid, dass ich nicht helfen kann.

[Heinzileilei]

@mickym flow.txt So aber Jetzt Danke für deine Hilfe. Hab den Originalen Flow in Visual Studio bearbeitet und Überall wo "unit_id": "2", gestanden ist auf "unit_id": "1", umgeschrieben da bei meiner Anlage "unit_id": "1", stimmt. Und jetzt bekomme ich die Daten in Node red und auch in den IoBroker. Wär fast verzweifelt ;) Anbei hab ich für alle die nur eine Anlage besitzen und sie laut Fusion Solar as Unit Id 1 gestellt ist den Flow angehängt der bei allen klappen sollte ( Bitte Ipadresse ändern bei mir ist 192.168.1.61 ) Lg

[badsnoopy667]

@heinzileilei
Ja, daran liegts. Mein WR war direkt am Anfang mal defekt und wurde getauscht. Deshalb hat er die ID: 2 bekommen. Aber normalerweise sollte da überall die ID 1 eingetragen sein. Ich habe den Hinweis, dass das zu ändern ist oben in der Anleitung ergänzt!

[Heinzileilei]

@badsnoopy667 Ja das habe ich leider nur beim Stick geändert ;) Hast du ne info ob du in deinem Flow die Möglichkeit hast beide Stings eparat auszuwerten ( Ost/West) . Danke Dir Lg

[badsnoopy667]

@heinzileilei
Importier mal den Flow von @ple, der hat mehrere Strings separat ausgewertet:

Klick mich

[ahessling]

Hallo zusammen,

mal eine vielleicht blöde Frage, aber ist es tatsächlich so gewollt, dass der SDongle sich inkl. Modbus TCP Interface tatsächlich bei Dunkelheit verabschiedet und erst am nächsten Tag bei Lichteinfall wieder zurückmeldet? Ich habe einen Huawei sun2000-8ktl-m1 ohne Speicher, dann scheint der Wechselrichter in den Standby zu gehen bei Dunkelheit. Da ich gerne Daten aufzeichne und visualisiere, fände ich es eigentlich schade, wenn dies nur tagsüber ginge. Auch so Daten wie Netzspannung, Frequenz sind ja u.U. nicht uninteressant. Oder wenn ich halt mit dem Modbus TCP Interface spielen will und es schon dunkel ist, habe ich auch schlechte Karten. ;-)

Kann man da evtl. irgendwo eine Einstellung tätigen, um den Dongle ständig online zu halten?

Danke und Grüße
André

[Chris M]

@asmm hast du hier mittlerweile eine Antwort?

ich möchte einfach nur den Wert, wieviel W mein Haus gerade verbraucht.
Das Register 37500 mit unit-id 100 vom Dongle scheint dieser Wert zu sein, is aber absolut nicht in Echtzeit.

@all gibt es irgend ein Register was mir diesen Wert zurück liefert?

[badsnoopy667]

@chris-m said in [HowTo] Huawei SUN2000 WR Modbus mit node-red (read + write):

@all gibt es irgend ein Register was mir diesen Wert zurück liefert?

Nein, das Register gibt es nicht. Aber Du kannst den Eigenverbrauch einfach berechnen indem Du "Active Power Inverter" Minus "Active Power Meter" rechnest. Also Eigenverbrauch = Erzeugung - Einspeisung. Bei Netzbezug ist die Einspeisung negativ, daher gilt dieselbe Formel auch für Netzbezug.

Das geht aber nicht so ohne weiteres, da die beiden Werte vom Wechselrichter/Dongle nicht genau gleichzeitig gesendet werden. Daher gibt es zwischen den Werten einen Zeitverzug von 1-2 Sekunden. Das macht dummerweise einen riesen Unterschied für den Fall, das sich die Sonneneinstrahlung stark ändert.
Lösung: Man summiert die Erzeugung und die Einspeisung ein paar Sekunden lang auf (z.B. 20 Sekunden lang) und bildet dann den Mittelwert. Das geht mit Listen. Die beiden Mittelwerte kann man dann voneinander abziehen.
Ich hänge mal meinen Blockly-Export dafür hier rein, aber Achtung, das ist ziemlich unübersichtlich weil es "gewachsen" ist. Heute würde ich das bestimmt sauberer aufschreiben.

Blockly_Huawei_Eigenverbrauch_etc.txt

[Holgus]

Danke für die Anleitung! Habe auf Anhieb die Kommunikation aufbauen können.
Trotz plausibler Daten erhalte ich folgenden Fehler:
"[warn] [modbus-client:WLAN-FE] Client -> fsm broken state after failed Get More About It By Logging TCP@192.168.2.87:502 default Unit-Id: 1"
Da ich minütlich abfrage, sehe ich diesen auch entsprechend oft. Wie kann ich das beheben?

Dann würde ich gerne die "realtime" Lade und entladewerte der Batterie haben wollen. In dem www.fusionsolar web interface kann man diese sehen. Wenn ich das richtig sehe, stehen die in dem Beispiel nicht zur Verfügung, nur die Battery_Total_Charge/Discharge. Kann man die zusätzlich noch abfragen und wenn ja wo oder wie muss ich die einrichten?
DANKE!

[badsnoopy667]

@holgus
Meinst Du diese beiden Werte "Ladeenergie heute" und "Entladeenergie heute" aus der App? Dafür gibt es mMn keinen Datenpunkt. Ich hab auch bisher nicht wirklich verstanden, was die überhaupt bedeuten sollen.
Aber man kann ja den Ladezustand in % auslesen. Damit kann man sich die beiden Werte ja halbwegs selber zusammenbasteln. Und die aktuelle Lade- und Entladeleistung in W wird ja auch ausgegeben.

[Holgus]

@badsnoopy667
Sorry, ich glaube ich habe gefunden was ich suchte: 0_userdata.0.Huawei.Battery.Battery_Power
Ich gehe davon aus , dass das dieser Wert ist:

Dann bleibt jetzt nur noch die Frage nach diesem Fehler:
fsm broken state after failed Get More About It By Logging TCP@192.168.2.87:502 default Unit-Id: 1"
Was läuft da schief?

[badsnoopy667]

@holgus
Ach der Fehler... Der kommt bei mir auch ab und zu mal. Ist ja nur eine Warnung. Einfach ignorieren, klappt trotzdem. 😁
Ja, das ist dein gesuchter Wert.

[joschipp]

Ich hab für meine Anwendung eine schnelle Abfrage einiger Register benötigt, und die restlichen werden seltener benötigt. Das hab ich jetzt folgendermaßen realisiert (basierend auf Vorschlägen weiter oben - vielen Dank dafür):

Count 3 ist ein Zähler, der 3 Ausgänge durchtaktet, der 1. Ausgang triggert die Abfrage vom Meter.Active_Power, den Wert will ich häufig aktualisiert haben. Sobald die Daten empfangen wurden, geht die Meldung über den Link zurück an die Trigger - Funktion. Die triggert den Count 3, und der zählt weiter auf den 2. Ausgang und triggert die Abfrage vom Inverter.Active_Power (brauch ich auch häufig).
Der 3. Ausgang triggert dann einen Zähler mit 25 Ausgängen:

Hier wird die Abfrage der restlichen 25 Register, die ich nicht häufig brauche, getriggert.
Die Trigger Funktion hat auch noch eine Timeout - Überprüfung, wenn mal keine Antwort kommen sollte, dann wird nach 5 Sekunden getriggert.
Damit werden jetzt die beiden wichtigen Register alle 1-2 Sekunden aktualisiert und der Rest langsamer.
Mit dieser Lösung hab ich sicher gestellt, das eine Abfrage erst bzw. sofort nach dem Empfang der vorigen Abfrage erfolgt, somit hat man die max. Geschwindigkeit und keinen Datenverlust.

flows.json

PS: das Problem mit den fehlenden Datenpunkten und das manuelle Anlegen (siehe weiter oben) kann man sich sparen, wenn man in der Node-Red Instanz "Erstellung von Fremd-Objekten" zulässt

mfg