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

[TheTrumpeter]

Kann ich mal probieren, aber ich glaube nicht, dass ein morgendlicher Neustart die sporadischen Neustarts tagsüber verhindert.
Mittlerweile glaube ich immer mehr, dass es irgendwie mit dem Fritz.Repeater, an dem das Teil eingebucht ist, zusammenhängt.

[der2of6]

Sporadische Neustarts kann ich mit der 0.4.25 nicht mehr nachvollziehen.
Bei mir läuft er tageweise ohne Reboot durch.

Die letzen Neustarts waren bei mir manuelle, da die MQTT Verbindung abgerissen ist.

Hab allerdings nur eine Zentrale Fritzbox und kein Repeater.

[TheTrumpeter]

Sporadische Neustarts kann ich mit der 0.4.25 nicht mehr nachvollziehen.

Hm... ich bin noch auf der 0.4.17. Habe zuletzt 0.4.19 oder 0.4.20 probiert, die haben sich gar nicht ins WLAN eingebucht bzw. aber auch keinen Accesspoint geöffnet. Vielleicht probier' ich mal wieder ein Update. Abgesehen von den Reboots läuft die 0.4.17 problemlos.

Bei mir läuft er tageweise ohne Reboot durch.

Tja, habe auch schon Laufzeiten über 2 Tagen gesehen, dann wieder nur ein paar Stunden.
Zuletzt war vor dem Reboot schon die HS110, die auch die PV-Leistung misst und auch an dem Repeater hängt, 1-2h ohne WLAN-Verbindung. Als diese Steckdose dann wieder "kam", hat auch die DTU rebootet.

Die letzen Neustarts waren bei mir manuelle, da die MQTT Verbindung abgerissen ist.

Ich nutze MQTT nicht, daher kann ich dazu nix sagen. Ich lese die Werte einfach per HTTPMOD aus.

[HeikoE]

Bei mir läuft die V0.4.22 seit fast einer Woche fehlerfrei. Auch die Wiederverbindung von MQTT nach Wlan-Abschaltung klappt damit fehlerfrei.
Den automatischen reboot habe ich wieder deaktiviert.

[kask]

Das MQTT Problem wurde gefixt im git vor wenigen Tagen.
Hat aber leider immer noch die version 4.25

Aber wie macht ihr das mit der readingslist? Wenn mehrere Panels oder WR's dranhängen überschreibt der ja einfach die Werte immer, da diese ja gleich heissen.
Habt ihr die alle angepasst oder wie gelöst?

[der2of6]

Ich habe es in der readingList manuell überschrieben.

Code Auswählen Erweitern



AHOY_DTU:Wechselrichter/HM1/ch1/U_DC:.*U_DC1
[....]
AHOY_DTU:Wechselrichter/HM1/ch2/U_DC:.*U_DC2


[kask]

Das hatte ich fast befürchtet das es alle so gemacht haben, mich eingeschlossen.
Vieleicht bastellt ja mal einer ein Modul für das Teil.
Ich kann schlechter Perl wie Fische fliegen. Also bin ich raus
Aber das/der/die Gateway/Dongle/Moped oder wie auch immer ihr das nennen mögt  funktioniert ja tadellos.

[TheTrumpeter]

Aber wie macht ihr das mit der readingslist? Wenn mehrere Panels oder WR's dranhängen überschreibt der ja einfach die Werte immer, da diese ja gleich heissen.
Habt ihr die alle angepasst oder wie gelöst?

Ich hole die Daten via HTTPMOD und habe das Problem daher nicht.
Verstehe aber nicht wieso das Problem überhaupt existiert. Wenn Du bei den Einstellungen jedem Wechselrichter bzw. Modul einen eigenen Namen gibst, würde ich erwarten, dass die Werte in MQTT auch unterschiedliche Namen haben.

[Beta-User]

Sobald das mit dem MI-600 auch (bei mir) klappt, gibt's eventuell einen attrTemplate-Satz dazu. Aber insgesamt sollte das auch kein Hexenwerk sein, das händisch einzurichten.

Leider bekomme ich bis dato keine Daten von dem Ding (via ESP8266+nRFL01+ und
AHOY-DTU in Version 0.4.26), wenn ich das im Mikrocontroller.net-Thread richtig verstanden habe, ist das noch nicht ganz soweit.

Wenn, dann würde ich das wieder in ein "MCU"-Basis-/Verteil-Device aufsplitten, das dann die einzelnen Wechselrichter je in ein Device weiterleitet, das dann wieder 1, 2 oder 4 (?) Kanäle für die Leistungsdaten je MPPT-Tracker hat, oder?

[TheTrumpeter]

Wenn, dann würde ich das wieder in ein "MCU"-Basis-/Verteil-Device aufsplitten, das dann die einzelnen Wechselrichter je in ein Device weiterleitet, das dann wieder 1, 2 oder 4 (?) Kanäle für die Leistungsdaten je MPPT-Tracker hat, oder?

Ich sehe den Vorteil von mehreren Devices noch nicht. Würde es nicht einfacher sein die Namen der Readings einfach aus den Einstellungen der DTU zu generieren?
Also einfach das, was die Leute als Bezeichnung für ihre WR/Module eintragen, als Präfix vor die Namen der Readings zu setzen?
Aus U_DC wird dann z.B. "WR1_Modul1_U_DC", "WR1_Modul2_U-DC", "WR2_Modul1_U-DC" usw.

[Beta-User]

Ich sehe den Vorteil von mehreren Devices noch nicht. Würde es nicht einfacher sein die Namen der Readings einfach aus den Einstellungen der DTU zu generieren?
Also einfach das, was die Leute als Bezeichnung für ihre WR/Module eintragen, als Präfix vor die Namen der Readings zu setzen?
Aus U_DC wird dann z.B. "WR1_Modul1_U_DC", "WR1_Modul2_U-DC", "WR2_Modul1_U-DC" usw.

Wie gesagt: ich habe  noch keinen wirklichen Eindruck von dem, was der AHOY-ESP wie sendet. Prinzipiell  (ganz ohne dass das was mit dieser konkreten Sache hier beschränkt wäre) sehe ich "individualisierte Readingnamen" sehr skeptisch: Da muss dann jeder in FHEM wieder seine individuelle Visualisierung draus generieren, Code zur Weiterverarbeitung zu teilen ist schwieriger etc. pp.
Mehrere Devices dagegen kann man untereinander gruppieren (in FHEMWEB) bzw. ggf. mit mehr oder weniger gleichen Einstellungen nebeneinander (afaik: FTUI), um dann optisch auf einen Blick zu erfassen, was "Sache ist".
Und wenn man Geräte "an" und "aus" schalten will/muss bzw. irgendwelche "pct"-Einstellungen vornehmen (offgrid-Nutzung), tut man sich wesentlich leichter, wenn jedes angesprochene Endgerät (=> WR) als separates FHEM-Device angesprochen werden kann.

Falls jemand hier mitliest, der an der firmware mitentwickelt: Wenn man "zusammengehörende" Infos in JSON verpackt und sendet, ist das für FHEM weniger Last (pro JSON eine Event-Loop, sonst allgemein: pro empfangenem Topic).

Falls jemand bessere Ideen hat: Es wäre auch kein Problem, zwei unterschiedliche Vorgehensweisen mit aufzunehmen, es gibt ja z.B. auch für mehrkanalige Tasmota-Devices die Varianten "unified" und "split". An denen wird es vielleicht auch etwas einfacher nachzuvollziehen, wie das obige gemeint ist; ich sehe dann nur schon das Problem, dass es mehr Fragen der User generiert, was denn nun sinnvollerweise genommen werden sollte....

Ansonsten könnte ich auch vorab schon "spielen", wenn jemand ein (aktuelles) RAW-listing hier einstellen würde (falls bereits teilweise JSON übertragen wird wäre zusätzlich je mind. ein JSON-Payload hilfreich, samt der Info, zu welchem Topic er jeweils gehört).

[olde]

Ich hole die Daten via HTTPMOD und habe das Problem daher nicht.
Verstehe aber nicht wieso das Problem überhaupt existiert. Wenn Du bei den Einstellungen jedem Wechselrichter bzw. Modul einen eigenen Namen gibst, würde ich erwarten, dass die Werte in MQTT auch unterschiedliche Namen haben.

Einen ESP8266+nRFL01+ hab ich mir jetzt auch mal zusammengebastelt. Die Version 0.4.25 läuft bei mir auch ganz stabil.
Weil bei mir kein MQTT Server läuft, habe ich jetzt auch versucht die Daten via HTTPMOD in FHEM zu holen. Leider bekomme ich es nicht hin.
Kannst du bitte mal posten wie du das eingerichtet hast?
Besten Dank

[Beta-User]

Weil bei mir kein MQTT Server läuft, habe ich jetzt auch versucht die Daten via HTTPMOD in FHEM zu holen. Leider bekomme ich es nicht hin.

Vermutlich ist es einfacher, einen MQTT2_SERVER zu aktivieren, als es mit HTTPMOD zu versuchen...:
https://wiki.fhem.de/wiki/MQTT#Schnellstart_f.C3.BCr_Ungeduldige

[olde]

Das ging ja einfach. Läuft soweit, danke für den Tipp 

[TheTrumpeter]

Einen ESP8266+nRFL01+ hab ich mir jetzt auch mal zusammengebastelt. Die Version 0.4.25 läuft bei mir auch ganz stabil.
Weil bei mir kein MQTT Server läuft, habe ich jetzt auch versucht die Daten via HTTPMOD in FHEM zu holen. Leider bekomme ich es nicht hin.
Kannst du bitte mal posten wie du das eingerichtet hast?
Besten Dank

Der Trick ist, dass Du die Seite "/livedata" parsen musst.