Neuigkeiten:

Am Sonntag den 8.12.2024 kann es ab ca. 8:00 Uhr zu kurzzeitigen Einschränkungen / Ausfällen bei den Diensten des FHEM Vereines kommen.
Die Server müssen mal gewartet und dabei neu gestartet werden ;)

Hauptmenü

Wechselrichter Hoymiles HM-600 mit FHEM verbinden anstelle mit WLAN Stick DTU-W1

Begonnen von josburg, 25 Mai 2021, 18:03:41

Vorheriges Thema - Nächstes Thema

GeZi3560

Danke für die Antwort.
Mann muss einfach nur Geduld haben un ein paar Stunden warten.
Dann funktioniert es.
Raspberry Pi 4 4GB, MariaDB,2 Cul V3 868 ,1 Cul V3, 433, Zwave-USB, Conbee2, DeConz, MAX WT und Ventile,HM, Somfy, Fibaro, Shellys, Tradfri, Lidl Zigbee

Beta-User

Zitat von: Beta-User am 31 März 2023, 11:09:34Falls jemand Zeit und Lust hat, devStateIcon-Code (für die DTU und/oder die Inverter) beizusteuern: feel free!

Was die Inverter angeht: Mir würde vorschweben, "pah-color" zu nutzen, um die einzelnen Panels anzuzeigen und auf Basis der Irridation zu färben, dazu die aktuelle Gesamtleistung, den heutigen Ertrag und den "allgemeinen Status", also offline, erreichbar oder in Produktion (rot/orange/grün).
Habe gestern was in diese Richtung eingeckeckt, falls jemand testen will...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

GeZi3560

Irgendwas stimmt da noch nicht, siehe Bilder.
Oder hab ich ein Konfig oder  Verständnissproblem?
Raspberry Pi 4 4GB, MariaDB,2 Cul V3 868 ,1 Cul V3, 433, Zwave-USB, Conbee2, DeConz, MAX WT und Ventile,HM, Somfy, Fibaro, Shellys, Tradfri, Lidl Zigbee

Beta-User

Wurde nach der Anzahl Channels gefragt? Auf die Schnelle wirkt das so, als würed das als single behandelt.

Ein (raw-) list würde evtl. mehr zeigen, falls es das nicht war....
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

GeZi3560

Bingo, das war es.  Nur ein Channel ausgewählt ich Depp.
Hab ich wohl falsch geklickt.
Danke
Raspberry Pi 4 4GB, MariaDB,2 Cul V3 868 ,1 Cul V3, 433, Zwave-USB, Conbee2, DeConz, MAX WT und Ventile,HM, Somfy, Fibaro, Shellys, Tradfri, Lidl Zigbee

schwatter

Frage,

ich denke über einen Herstellerwechsel nach. Deye zu Hoymiles. 3 gegen 3. Kann die OpenDTU mehr als einen Wechselrichter verwalten?

Gruß schwatter

Beta-User

Sowohl OpenDTU wie AhoyDTU können mehrere Inverter (default 10 oder so).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

TomLee

Meiner bisherigen Erkenntnis nach (das sind jetzt 5 Tage Erfahrung) bekommt die Ahoy-DTU (0.6.9) Probleme zu pollen umso größer das gewählte Intervall eingestellt wird.
Nehm ich 30 oder 60 Sekunden, ist die Kommunikation mit dem Inverter immer ausnahmslos OK, wähl ich 240 oder 300 Sekunden fangen die Probleme an und die Kommunikation "hängt" ab und an.

Ich frage auch deshalb da ich heute einen 100μF Kondensator eingelötet hab und sich am Verhalten nichts geändert hat (bisher war das mein Milight-Gatway und da war ein 2,4μF verbaut weil ich damals keinen 100er da hatte)

Kann diesbezüglich wer was sagen oder verlinken was ich genau zu lesen habe das ich diesbezüglich die Zusammenhänge besser verstehe ?

Beta-User

Glaube nicht, dass der Effekt irgendwo sauber dokumentiert ist. Meine Theorie:
Die Hoymiles-WR synchronisieren sich mit dem "Takt", den die/eine DTU vorgibt, und lauschen eben _vorwiegend_ auf dem Kanal, der sich als nächstes aus diesem Takt ergibt.

Zumindest für die "alten MI" waren das bei der originalen DTU eher Anfragen im 200ms-Sekunden-Takt, die dann eben auf die vorhandenen Inverter verteilt wurden... Zum Syncen braucht es anscheinend nicht Anfragen an einen speziellen Inverter, solange die alle vom "zentralen Anfrager" kommen (i.d.R. eben eine DTU).
Kommt "zu lange" nichts, fallen die Inverter afaik wieder in einen "chaotischen" Lauschzustand zurück, in dem sie eher schlechter hören als bei geringfügigen Abweichungen vom erwarteten Takt.

Ahoy und afaik auch OpenDTU senden zwar deutlich seltener Anfragen als eine originale DTU, aber es scheint hilfreich zu sein, wenn die nicht zu selten sind. Wer also Probleme hat, sollte ÖFTER anfragen (und eben dafür sorgen, dass ausreichend Power zum Senden da ist).
Nach meinen Erfahrungen ist 5 Sekunden ausreichend, wobei das in meinem setup (7 Inverter) trotzdem zu lange ist, bis alle Daten einmal rundrum aktualisiert werden. Daher fahre ich grade mit 2 Sekunden.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

TomLee

Darf man erfahren wie dein Ansatz ist diese (teilweise auch unnötigen) Massen von Events zu handeln, wenn du einen 5 Sekunden Intervall verwendest oder nutzt du kein MQTT und frägst nur die relevanten Werte regelmäßig ab ?

Ich hab seit heute Mittag das erste Mal 120 eingestellt und es kam laut Log seitdem nicht einmal ein Inverter #0: Hoymiles_600_1 (v0) is available but no data was received until nowund das mit Power Level LOW, ich hab ja aber auch nur einen Wechselrichter.

Mit 240 oder 300 kommt die Meldung regelmäßig, es wird gefühlt mit der Zeit besser aber mMn. zu oft.

Beta-User

Na ja, im Moment lebe ich noch mit der "Fülle" an Events, die via MQTT so kommt - geloggt wird sowieso "schon immer" eigentlich nur das, was die "zentrale Messdose" ermittelt (aktuell ein 3-phasiger ZigBee-Aktor für die Hutschiene)...

"Irgendwann mal" wollte ich mich mal dann mit der JSON-Variante beschäftigen und ggf. damit eine taugliche eocr-Variante für myUtils bauen (falls nicht jemand schneller ist...). Wird eher noch Monate dauern, bis ich dazu kommen werde (und Lust habe). Bis dahin kann ich erst mal damit leben, dass meine regelmäßigen Blicke auf das aktuelle Gesamtbild keine Probleme aufzeigen - aber dafür deutlich bestätigen, dass meine Wechselrichter-Wahl für diesen "konkreten Anwendungsfall" (unser Hausdach) genau richtig gewesen zu sein scheint 8) .
(Über den Tag weg gibt es praktisch immer (mind.) irgendein Panel, das die anderen auf dieser Seite "ausbremsen" könnte, da (teil-) beschattet. Insgesamt ist die Ausbeute aber (teils deutlich!) besser wie erhofft...).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

masterpete23

Zitat von: Beta-User am 29 Mai 2023, 17:34:32(aktuell ein 3-phasiger ZigBee-Aktor für die Hutschiene)...

Kurze Zwischenfrage: Welcher ist das?

Beta-User

Zitat von: masterpete23 am 31 Mai 2023, 10:12:22
Zitat von: Beta-User am 29 Mai 2023, 17:34:32(aktuell ein 3-phasiger ZigBee-Aktor für die Hutschiene)...

Kurze Zwischenfrage: Welcher ist das?
Gibt wohl bei Ali unterschiedlich gelabelte Varianten. deconz wirft "_TZE200_hkdl5fmv" als Bezeichnung aus.
Meiner hat noch den Schutzschalter integriert, und bisher klappt das noch nicht mit dem auslesen des/der power-Werte. Für die kumulierte Wh-Ausgabe muss man eine ddf bereitstellen.

Wenn' s mal fertig ist, schreibe ich dann mal mehr dazu...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

FSausF

#238
Hallo, Freunde der Sonne,
habt Ihr hier im Thread vielleicht eine Idee, wie man dem HM-800 per OpenDTU das Limit setzt?
Ausgelesen kriege ich alles über ein MQTT-Device mit Template hoymiles_bridge.
Es wird auch brav ein frisches MQTT-Device für den angeschlossenen Inverter angelegt.
Auf beiden kreige ich Readings im 5-Sekunden-Takt, wie es sein soll.
Aber:
1.) Was sollte das Inverter-Device dann für ein Template haben?
2.) Was muß in die SetList, damit ich da einen Wert gesetzt kriege? (Die Topics müßten diese hier sein: https://github.com/tbnobody/OpenDTU/blob/master/docs/MQTT_Topics.md).
Ideen?

EDIT: Zwischenzeitlich hab' ich's raus, schreib' aber für die Nachwelt kurz hier auf, wie das mit OpenDTU geht:
1.) fhem muss mqtt sprechen. Das muss man einrichten.
2.) OpenDTU muss mqtt sprechen. Das muss man dort einrichten, ist aber über das WebGUI dort ein Quickie.
3.) fhem empfängt dann den mqtt-Stream und legt per autocreate ein Device an.
4.) Diesem Device muss man - ggf. nach Update und Neustert fhem - das Template "hoymiles_opendtu_hub_bridge" zuweisen und ein wenig warten.
5.) fhem kanalisiert dann den mqtt-Stream und legt per autocreate ein weiteres Device an.
6.) Diesem Device muss man - geht nur, wenn 4 gemacht ist - das Template "hoymiles_opendtu_microinverter" zuweisen und wieder ein wenig warten.
Ergebnis: Der Wechselrichter sendet an das unter 6 gesehene Device und lässt sich darüber auch steuern!

fhem rockt mal wieder "out of the box". Chapeau!

Jochen_M

Hi FSausF, Dank dir für die Zusammenfassung.

ab wann ist den das AttrTemplate "hoymiles_opendtu_microinverter" (unter 6 bei Dir angesprochen) vorhanden. Habe bei mir nachgesehen und das ist das Template noch nicht da.

Grüße aus Hessen
Der Jochen