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

[FSausF]

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

Hallo Sonnenfreund,
damit das Ganze klappt, muß man natürlich - wie immer - erst Mal fhem updaten und neu starten.
Dadurch werden die aktuellen MQTT-Templates ins System gespült.
Dann muß man dieses Bridge-Device für den Hoymiles einrichten.
Denn das ist - so steht es in dem anderen Template - Voraussetzung.
Wenn das Bridge-Device nicht da ist, wird das andere Template in der Auswahl nicht angezeigt.
Es muß auch das richtige Bridge-Device sein. Hoymiles-Bridge ist das falsche, das mit "OpenDTU" im Namen ist das richtige.
...und dann hat das bei mir funktioniert...

[Bracew]

Hallo,

seit wenigen Tagen habe ich ein Balkonkraftwerk mit Hoymiles HM-800 und OpenDTU auf einem ESP32. FHEM läuft schon seit vielen Jahren bei mir auf einem RasPi.
Ich habe hier in den vorangegangenen Seiten (uff, 17 Seiten bei mir) gelesen, dass eine Visualisierung und Datenspeicherung via MQTT über Autocreate eingerichtet werden kann.

Eine vollständige Definition habe ich in den vielen Seiten zu vor leider nicht gesehen. Nichts desto trotz würde ich gerne bevor ich daran gehe mal eine vollständige Definition für diese oder eine ähnliche Konstellation sehen.

Im Netz gibt es auch Ansätze mit influxdb und grafana. Ich weiß noch nicht für was ich mich begeistern soll.

Ich würde mich freuen, wenn mal jemand seinen vollständigen Auszug für FHEM aus der fhem.cfg hier posten würde und auch ein Bildschirmhardcopy, wie das dann aussieht.

Vielen Dank Euch!

[Beta-User]

...aber attrTemplate sagt dir was....?

(Ist für OpenDTU wohl verbesserungsfähig, aber auch vorhanden.)

[Bracew]

Ja, attrTemplate sagt mir was. Mit attrTemplate und über das Protokoll MQTT habe ich meine Tasmota-Sonoff und Tasmota-Shelly eingebunden.

Ich würde mich dennoch freuen, wenn jemand seinen vollständigen Definitionsauszug für die OpenDTU Einbindung in FHEM aus der fhem.cfg hier posten würde und auch ein Bildschirmhardcopy, wie das dann aussieht.

[Beta-User]

...was ich dazu bisher hier gesehen habe basiert auf den betreffenden attrTemplate zu OpenDTU (bzw. die wurden daraus entwickelt).

Also: wie findest du das, was man damit in FHEM erhält bzw. welche Hinderungsgründe sprechen dagegen, diesen Weg selbst zu testen?!?

[Bracew]

Hallo Beta-User,

die Erklärung ist:

Eine vollständige Definition habe ich in den vielen Seiten zu vor leider nicht gesehen. Nichts desto trotz würde ich gerne bevor ich daran gehe mal eine vollständige Definition für diese oder eine ähnliche Konstellation sehen.

Im Netz gibt es auch Ansätze mit influxdb und grafana. Ich weiß noch nicht für was ich mich begeistern soll.

Aber, manchmal wäre es einfacher, nicht alles hinterfragt zu bekommen und nicht alles begründen zu müssen.

Es ist einfach eine Bitte. Ich möchte niemanden zwingen und es muss niemand über meine Gründe spekulieren. Einfach so! Einfach aus lauter Freundlichkeit meiner Bitte zu entsprechen.

[Beta-User]

Dann begründe nicht, sondern TESTE.

Dann bekommst du nämlich ziemlich genau das, nach was du gefragt hattest und kannst den Screenshot selber machen, falls du ihn dann noch benötigst....

[Bracew]

Also gut, habe ich gemacht.
Kommt aber nur folgendes bei raus:

Du darfst diesen Dateianhang nicht ansehen.

Gibt es keine Visualisierung?

[Bracew]

Hallo an Alle,

ich möchte nochmals nachfragen, ob nicht jemand seinen vollständigen Definitionsauszug für die OpenDTU Einbindung in FHEM aus der fhem.cfg hier posten würde oder per PN mir sendet und teilt. Auch ein Bildschirmhardcopy, wie das dann aussieht, wäre toll.

Irgendwie komme ich sonst nicht weiter.

Liebe Grüße Bracew

[Maista]

Also gut, habe ich gemacht.
Kommt aber nur folgendes bei raus:

Du darfst diesen Dateianhang nicht ansehen.

Gibt es keine Visualisierung?

Hallo Bracew,
Ich nutze Ahoy. Kann dir bezüglich openDTU nix zeigen.

Wir soll man die Frage nach der Visualisierung Verstehen?

Meinst du eine Grafik des Ertrages oder des MQTT-Device?

Gruß Gerd

[Bracew]

Hallo Gerd,

Ich nutze Ahoy. Kann dir bezüglich openDTU nix zeigen.

Auch mit Ahoy vermute ich, wirst Du die Daten Deines Wechselrichter per MQTT empfangen und in FHEM als Grafik darstellen.

Wir soll man die Frage nach der Visualisierung Verstehen?

Ich würde gerne die per MQTT empfangenen Daten innerhalb FHEM so aufbereitet sehen, dass ich grafische Auswertungen, zum Beispiel der Erträge der letzten Tage (oder Stunden, oder Wochen, oder, oder, oder) sehe.

Meinst du eine Grafik des Ertrages oder des MQTT-Device?

Ich meine zum Beispiel den Ertrag. Was kann ich bei MQTT-Device sehen? Oder was hast Du bzw. andere bereits ansonsten visualisiert?
Deshalb meine Frage nach dem Bildschirmhardcopy, dort würde ich sehen, was mich daraus interessiert und im fhem.cfg wie ich es sinngemäß bei mir umsetzen könnte. Ich weiß halt nicht was man könnte und auch nicht wie.

Wie gesagt, OpenDTU läuft bei mir und FHEM speicht in den Logfiles die ankommenden MQTT Daten. Was davon und wie kann ich diese auswerten und grafisch darstellen?

[kpwg]

Wie gesagt, OpenDTU läuft bei mir und FHEM speicht in den Logfiles die ankommenden MQTT Daten. Was davon und wie kann ich diese auswerten und grafisch darstellen?

Das entscheidest Du selbst, wie/wo/was Du sehen möchtest. Wir sind hier bei den Grundlagen, das hat mit MQTT und openDTU nichts mehr zu tun. Wenn ich was Neues einbinde, schaue ich mir das gerne bei eigenen bereits funktionierenden Geräten oder hier im Forum ab. Dazu habe ich eine gewisse Herangehensweise entwickelt:

- welche Daten kommen überhaupt rein, was davon will ich sehen und nutzen (eventOnChangeReading, eventOnUpdateReading, diverse Filtermöglichkeiten)
- was davon möchte ich loggen, wie genau/häufig benötige ich die Daten (Logfile erstellen, userreading mit allen Daten in einer Zeile, filelog-event-min-interval setzen)
- ist das Gerät bidiektional, muss ich was schalten, steuern, regeln (setlist, webcmd, readingsProxy usw. erstellen)
- "hübsch machen", d.h. stateFormat mit den gewünschten Daten füttern und verständlich darstellen, Symbole bei Bedarf ergänzen, alias, room, group, ...

Hat man das alles gemacht, entsteht ein ansehnliches Gerät, welches das System wenig belastet, alle Nötige zeigt und so aussieht, wie ich möchte (oder besser gesagt: Wie meine nicht vorhandenen Programmierkenntnisse es zulassen ). Zu openDTU kam ich, da konnte man weder die Leistung steuern, noch gab es hier ein Template, zu der Zeit war ahoj instabil und nur auf dem ESP8266 verfügbar. Die Entscheidung für das modernere Design, ESP32 und die Stabilität war dann entsprechend getroffen. Mein Code wäre aufgrund der anderen Struktur hier nur bedingt anwendbar, 1:1 schon gar nicht.

Aussehen tut es aktuell so:
Du darfst diesen Dateianhang nicht ansehen.
Die Steuerung erfolgt mit zwei readingsProxy, loggen tu ich vom Inverter lediglich die Leistung und den Totalverbrauch, daraus lässt sich mit statistics alles ableiten. Das "Auto-Limit" ist inaktiv, damit hatte ich mal was getestet. Dahinter verbirgt sich direkt ein doIF, um Anzeige und Schaltelemente erweitert.

Dir jetzt einfach den Code dazu hier "abzuladen" halte ich für wenig erfolgreich, wenn meine Intention dahinter fehlt. Ich stelle es bei Gelegenheit trotzdem vor- manche Dinge sind relativ einfach, hab ich im Nachhinein bemerkt 

Viele Grüße,

Ricardo

[Bracew]

Hallo Ricardo,

danke für Deine Antwort.

Wir sind hier bei den Grundlagen

Falls ich mich hier am falschen Thread angehängt habe, bitte ich um einen Hinweis. Ich würde dann ggf. einen neuen eröffnen.

Wenn ich was Neues einbinde, schaue ich mir das gerne bei eigenen bereits funktionierenden Geräten oder hier im Forum ab.

Ja, das ist genau das, was ich auch machen wollte! Ich suche Beispiele als Bild und Code, denen ich folgen kann und welche ich auf meine Situation anpassen kann.

Deshalb

Deshalb meine Frage nach dem Bildschirmhardcopy, dort würde ich sehen, was mich daraus interessiert und im fhem.cfg wie ich es sinngemäß bei mir umsetzen könnte.

Die OpenDTU Darstellung bei mir ist ähnlich folgender:
Du darfst diesen Dateianhang nicht ansehen.

In dieser sehe ich die Werte, wie Du Sie auch in Deinem Screenshot dargestellt hast.

Ich suche jetzt eine FHEM Umsetzung ähnlich folgenden im Netz gefundenen Beispielen:
Du darfst diesen Dateianhang nicht ansehen.Du darfst diesen Dateianhang nicht ansehen.Du darfst diesen Dateianhang nicht ansehen.   

Also, zum Beispiel einer Visualisierung der Tageserträge, da es diese in OpenDTU so nicht gibt.
Ich möchte nichts am Wechselrichter steuern oder ändern (z.B. Limit), da ich dies in OpenDTU einstellen kann, sondern in FHEM nur eine grapische Umsetzung der im Logfile gespeicherten Textdaten.

[laserrichi]

glaube du verwechselst da jetzt etwas, was du meinst ist ja mehr logging und svg plot.

hab zwar ahoy am laufen aber damit kannst du auch nichts anfangen:

Code Auswählen Erweitern

defmod MQTT2_inverter_MI600 MQTT2_DEVICE inverter_MI600
attr MQTT2_inverter_MI600 event-on-change-reading .*
attr MQTT2_inverter_MI600 model hoymiles_microinverter_inverter
attr MQTT2_inverter_MI600 readingList inverter/MI600/ch1/U_DC:.* U_DC1\
inverter/MI600/ch1/I_DC:.* I_DC1\
inverter/MI600/ch1/P_DC:.* P_DC1\
inverter/MI600/ch1/YieldDay:.* YieldDay1\
inverter/MI600/ch1/YieldTotal:.* YieldTotal\
inverter/MI600/ch1/Irradiation:.* Irradiation\
inverter/MI600/ch2/U_DC:.* U_DC2\
inverter/MI600/ch2/I_DC:.* I_DC2\
inverter/MI600/ch2/P_DC:.* P_DC2\
inverter/MI600/ch2/YieldDay:.* YieldDay2\
inverter/MI600/ch2/YieldTotal:.* YieldTotal\
inverter/MI600/ch2/Irradiation:.* Irradiation\
inverter/MI600/ch0/U_AC:.* U_AC\
inverter/MI600/ch0/I_AC:.* I_AC\
inverter/MI600/ch0/P_AC:.* P_AC\
inverter/MI600/ch0/Q_AC:.* Q_AC\
inverter/MI600/ch0/F_AC:.* F_AC\
inverter/MI600/ch0/PF_AC:.* PF_AC\
inverter/MI600/ch0/P_DC:.* P_DC\
inverter/MI600/ch0/Temp:.* Temp\
inverter/MI600/ch0/ALARM_MES_ID:.* ALARM_MES_ID\
inverter/MI600/ch0/YieldDay:.* YieldDay\
inverter/MI600/ch0/YieldTotal:.* YieldTotal\
inverter/MI600/ch0/Efficiency:.* Efficiency\
inverter/MI600/ch0/active_PowerLimit:.* limit\
inverter/MI600/ch0/FWVersion:.* FWVersion\
inverter/MI600/ch0/FWBuildYear:.* FWBuildYear\
inverter/MI600/ch0/FWBuildMonthDay:.* FWBuildMonthDay\
inverter/MI600/ch0/FWBuildHourMinute:.* FWBuildHourMinute\
inverter/MI600/ch0/HWPartId:.* HWPartId\
inverter/MI600/available:.* available\
attr MQTT2_inverter_MI600 setStateList on off
attr MQTT2_inverter_MI600 stateFormat YieldDay Wh P_DC W
deine Definitionen sind anders, dein WR ist anders und deine Readings...

Was du dann ins Filelog schreibst und daraus wieder in sachen svg plots aufarbeitest das kann dir hier keiner abnehmen.

Da suche und schau dir im wiki mal beispiele über logging und svg an, gibt auch einige wiki einträge für solar und auch forecast und svg Beispiele.

[kpwg]

Anbei zum Beitrag #251 von mir der Code. Ohne Logging 
Alles nix Neues, aber vielleicht kann es jemand gebrauchen oder auch optimieren.

Der HM-600. Hier habe ich nur ein wenig mit stateFormat gearbeitet sowie zum testen den Slider drin. Das Userreading macht Berechnungen im Nachgang einfacher.

Code Auswählen Erweitern

define DTU2 MQTT2_DEVICE OpenDTU_8850748
attr DTU2 alias HM-600
attr DTU2 autocreate 0
attr DTU2 bridgeRegexp 1141831xxxxx/([^/]+)/ch[0-9]+/.*:.* "1141831xxxxx_$1"
attr DTU2 devStateIcon .*:.*:noFhemwebLink
attr DTU2 devStateStyle style="text-align:left;;;;font-weight:narrow;;;;"
attr DTU2 event-min-interval .*:60
attr DTU2 event-on-change-reading .*
attr DTU2 group 2_BKW
attr DTU2 readingList OpenDTU_8850748:solar/dtu/uptime:.* uptime\
OpenDTU_8850748:solar/dtu/ip:.* ip\
OpenDTU_8850748:solar/dtu/hostname:.* hostname\
OpenDTU_8850748:solar/dtu/rssi:.* rssi\
OpenDTU_8850748:solar/1141831xxxxx/name:.* solar_1141831xxxxx_name\
OpenDTU_8850748:solar/1141831xxxxx/device/bootloaderversion:.* bootloaderversion\
OpenDTU_8850748:solar/1141831xxxxx/device/fwbuildversion:.* fwbuildversion\
OpenDTU_8850748:solar/1141831xxxxx/device/fwbuilddatetime:.* fwbuilddatetime\
OpenDTU_8850748:solar/1141831xxxxx/device/hwpartnumber:.* hwpartnumber\
OpenDTU_8850748:solar/1141831xxxxx/device/hwversion:.* hwversion\
OpenDTU_8850748:solar/1141831xxxxx/status/limit_relative:.* limit_relative\
OpenDTU_8850748:solar/1141831xxxxx/status/limit_absolute:.* limit_absolute\
OpenDTU_8850748:solar/1141831xxxxx/status/reachable:.* reachable\
OpenDTU_8850748:solar/1141831xxxxx/status/producing:.* producing\
OpenDTU_8850748:solar/1141831xxxxx/status/last_update:.* last_update\
OpenDTU_8850748:solar/1141831xxxxx/0/powerdc:.* 1141831xxxxx_0_powerdc\
OpenDTU_8850748:solar/1141831xxxxx/0/yieldday:.* 1141831xxxxx_0_yieldday\
OpenDTU_8850748:solar/1141831xxxxx/0/yieldtotal:.* 1141831xxxxx_0_yieldtotal\
OpenDTU_8850748:solar/1141831xxxxx/0/voltage:.* 1141831xxxxx_0_voltage\
OpenDTU_8850748:solar/1141831xxxxx/0/current:.* 1141831xxxxx_0_current\
OpenDTU_8850748:solar/1141831xxxxx/0/power:.* 1141831xxxxx_0_power\
OpenDTU_8850748:solar/1141831xxxxx/0/frequency:.* 1141831xxxxx_0_frequency\
OpenDTU_8850748:solar/1141831xxxxx/0/temperature:.* 1141831xxxxx_0_temperature\
OpenDTU_8850748:solar/1141831xxxxx/0/powerfactor:.* 1141831xxxxx_0_powerfactor\
OpenDTU_8850748:solar/1141831xxxxx/0/efficiency:.* 1141831xxxxx_0_efficiency\
OpenDTU_8850748:solar/1141831xxxxx/0/reactivepower:.* 1141831xxxxx_0_reactivepower\
OpenDTU_8850748:solar/1141831xxxxx/1/name:.* 1141831xxxxx_1_name\
OpenDTU_8850748:solar/1141831xxxxx/1/voltage:.* 1141831xxxxx_1_voltage\
OpenDTU_8850748:solar/1141831xxxxx/1/current:.* 1141831xxxxx_1_current\
OpenDTU_8850748:solar/1141831xxxxx/1/power:.* 1141831xxxxx_1_power\
OpenDTU_8850748:solar/1141831xxxxx/1/yieldday:.* 1141831xxxxx_1_yieldday\
OpenDTU_8850748:solar/1141831xxxxx/1/yieldtotal:.* 1141831xxxxx_1_yieldtotal\
OpenDTU_8850748:solar/1141831xxxxx/1/irradiation:.* 1141831xxxxx_1_irradiation\
OpenDTU_8850748:solar/1141831xxxxx/2/name:.* 1141831xxxxx_2_name\
OpenDTU_8850748:solar/1141831xxxxx/2/voltage:.* 1141831xxxxx_2_voltage\
OpenDTU_8850748:solar/1141831xxxxx/2/current:.* 1141831xxxxx_2_current\
OpenDTU_8850748:solar/1141831xxxxx/2/power:.* 1141831xxxxx_2_power\
OpenDTU_8850748:solar/1141831xxxxx/2/yieldday:.* 1141831xxxxx_2_yieldday\
OpenDTU_8850748:solar/1141831xxxxx/2/yieldtotal:.* 1141831xxxxx_2_yieldtotal\
OpenDTU_8850748:solar/1141831xxxxx/2/irradiation:.* 1141831xxxxx_2_irradiation
attr DTU2 room Energie
attr DTU2 setExtensionsEvent 0
attr DTU2 setList limit_persistent solar/1141831xxxxx/cmd/limit_persistent_absolute $EVTPART1\
limit_nonpersistent:slider,0,20,600 solar/1141831xxxxx/cmd/limit_nonpersistent_absolute $EVTPART1\
off:noArg solar/1141831xxxxx/cmd/power 0\
on:noArg solar/1141831xxxxx/cmd/power 1\
restart:noArg solar/1141831xxxxx/cmd/restart 1
attr DTU2 sortby 03
attr DTU2 stateFormat { sprintf("%.1f W aktuell, %.0f W gesetzt<br> %.1f V / %.2f Hz / %.1f °C <br> %.3f kWh heute",\
ReadingsVal($name,"1141831xxxxx_0_power","?") ,\
ReadingsVal($name,"limit_absolute","?") ,\
ReadingsVal($name,"1141831xxxxx_0_voltage","?") ,\
ReadingsVal($name,"1141831xxxxx_0_frequency","?") ,\
ReadingsVal($name,"1141831xxxxx_0_temperature","?"),\
ReadingsVal($name,"1141831xxxxx_0_yieldday","?")/1000) }
attr DTU2 userReadings limit_calc {ReadingsVal("DTU2","producing",'') eq "1" ? ReadingsNum("DTU2","1141831xxxxx_0_power",'') : 0 }
attr DTU2 webCmd :

Dazu das on/off, welches sich mit aufgehender bzw. untergehender Sonne selbst schaltet. Man KÖNNTE aber an der Stelle eingreifen.

Code Auswählen Erweitern

define rp_DTU2prod readingsProxy DTU2:producing
attr rp_DTU2prod alias BKW aktiv
attr rp_DTU2prod devStateIcon 1:on 0:off
attr rp_DTU2prod group 2_BKW
attr rp_DTU2prod room Energie
attr rp_DTU2prod setFn {($CMD eq "on")?fhem("set $DEVICE on"):fhem("set $DEVICE off");; return undef}
attr rp_DTU2prod setList on off
attr rp_DTU2prod sortby 02

Weiterhin der Slider, mit dem man regeln könnte. Besonderheit daran ist, das ich hier limit_nonpersistent mit Werten zwischen 0 und $limit beschreiben kann, wobei in diesem Beispiel $limit = 600 beträgt. Für die Anwendung einer Nulleinspeisung lässt sich somit zyklisch direkt der Wert aus dem Energiemonitor (z.B. Shelly 3EM) als einzuspeisende Leistung schreiben, nur eben eingeschränkt auf zulässige Werte.

Code Auswählen Erweitern

define rp_DTU2lim readingsProxy DTU2:limit_nonpersistent
attr rp_DTU2lim alias BKW Limit
attr rp_DTU2lim group 2_BKW
attr rp_DTU2lim room Energie
attr rp_DTU2lim setFn {\
my $pow = $ARGS;;\
my $limit = ReadingsVal('rp_DTU2lim','limit','');;\
    if ($pow > $limit) { $pow = $limit}\
    elsif ($pow < 1) { $pow = 0}\
fhem ("set $DEVICE limit_nonpersistent $pow") }
attr rp_DTU2lim setList limit_nonpersistent:slider,0,10,600
attr rp_DTU2lim sortby 01
attr rp_DTU2lim stateFormat &nbsp;;
attr rp_DTU2lim webCmd limit_nonpersistent

setreading rp_DTU2lim limit 600