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

FSausF

Zitat von: Jochen_M am 11 Juni 2023, 13:30:13Hi 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

#241
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!
FHEM auf Raspberry Pi
für z.B. Lichtsteuerung, Temperaturmessung, Balkonkraftwerk,
Öltankfüllstandsmessung und für Hühnerstall Hühnerklappe

Beta-User

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

(Ist für OpenDTU wohl verbesserungsfähig, aber auch vorhanden.)
Server: HP-T620@Debian 11, 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

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.
FHEM auf Raspberry Pi
für z.B. Lichtsteuerung, Temperaturmessung, Balkonkraftwerk,
Öltankfüllstandsmessung und für Hühnerstall Hühnerklappe

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?!?
Server: HP-T620@Debian 11, 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

Bracew

Hallo Beta-User,

die Erklärung ist:
Zitat von: Bracew am 05 Juli 2023, 19:35:52Eine 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.
FHEM auf Raspberry Pi
für z.B. Lichtsteuerung, Temperaturmessung, Balkonkraftwerk,
Öltankfüllstandsmessung und für Hühnerstall Hühnerklappe

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....
Server: HP-T620@Debian 11, 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

Bracew

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

Du darfst diesen Dateianhang nicht ansehen.

Gibt es keine Visualisierung?
FHEM auf Raspberry Pi
für z.B. Lichtsteuerung, Temperaturmessung, Balkonkraftwerk,
Öltankfüllstandsmessung und für Hühnerstall Hühnerklappe

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
FHEM auf Raspberry Pi
für z.B. Lichtsteuerung, Temperaturmessung, Balkonkraftwerk,
Öltankfüllstandsmessung und für Hühnerstall Hühnerklappe

Maista

Zitat von: Bracew am 06 Juli 2023, 19:15:35Also 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

#250
Hallo Gerd,

Zitat von: Maista am 09 Juli 2023, 17:20:50Ich 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.

Zitat von: Maista am 09 Juli 2023, 17:20:50Wir 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.

Zitat von: Maista am 09 Juli 2023, 17:20:50Meinst 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?


FHEM auf Raspberry Pi
für z.B. Lichtsteuerung, Temperaturmessung, Balkonkraftwerk,
Öltankfüllstandsmessung und für Hühnerstall Hühnerklappe

kpwg

Zitat von: Bracew am 09 Juli 2023, 20:04:38Wie 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 :D ). 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  ;D

Viele Grüße,

Ricardo


Bracew

#252
Hallo Ricardo,

danke für Deine Antwort.

Zitat von: kpwg am 10 Juli 2023, 07:14:17Wir 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.

Zitat von: kpwg am 10 Juli 2023, 07:14:17Wenn 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
Zitat von: Bracew am 09 Juli 2023, 20:04:38Deshalb 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.
FHEM auf Raspberry Pi
für z.B. Lichtsteuerung, Temperaturmessung, Balkonkraftwerk,
Öltankfüllstandsmessung und für Hühnerstall Hühnerklappe

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:

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.

RaspberryPi 4 Bullseye,Homematic,Z-Wave,Rademacher Duofern,Signalduino,Fritz7590,ESPEasy,Tasmota,Robonect,Kameras,1-Wire,Modbus,Solar,Maranz,VU+,ulanzi tc001 mit awtrix light

kpwg

#254
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.
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.
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.
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