OpenWB - MQTT2 client configuration

Begonnen von ritter_runkel, 31 Juli 2021, 19:07:02

Vorheriges Thema - Nächstes Thema

ch.eick

#45
Hallo zusammen,
der Christian is ma widder am basteln dran, am tun :-)

Ich hatte einen Tag, an dem die 70% Abregelung zugeschlagen hat, obwohl schon alle must have Geräte bewust in der Mittagzeit liefen :-(
Zusätzlich hatte ich an dem Tag auch das BEV von 20 auf 80% geladen, was jedoch bei meinem Überschuss sehr schnell ging.

Die Ideee ist nun, da ich bereits alle Trigger dazu habe, das BEV mit berechneter Leistung über eine längere Zeit im Mittagshoch zu laden und den Rest Überschuss weiterhin ins Netz zu liefern.
Darüber hinaus würde die dynamische 70% Regelung des Kostal Plenticore noch zusätzlich Leistung liefern.

Um dies nun umzusetzen möchte ich die "70% beachten" der openWB verwenden. Diese Einstellung würde jedoch bei fester Einstellung jedes mal wirken und somit das normale Überschussladen einschränken. Deshalb möchte ich es entsprechend meiner WR Leistungsprognose aktivieren und deaktivieren.

Relevante MQTT Register in readingList

für die Konfiguration:
$DEVICETOPIC/config/get/pv/nurpv70dynact:.* nurpv70dynact
$DEVICETOPIC/config/get/pv/nurpv70dynw:.* nurpv70dynw
$DEVICETOPIC/config/set/pv/nurpv70dynact:.* nurpv70dynact
$DEVICETOPIC/config/set/pv/nurpv70dynw:.* nurpv70dynw

nurpv70dynact 1
nurpv70dynw 4000

Dieser Teil, der sich auf die konfiguration bezieht funktioniert schon mal richtig. Mit nurpv70dynw kann man den Schwellwert der Leistung beliebig verändern und es wirkt sich sofort auf den nächsten Regelzyklus aus.

für die aktive Anzeige:
$DEVICETOPIC/pv/bool70PVDynActive:.* bool70PVDynActive
$DEVICETOPIC/pv/bool70PVDynStatus:.* bool70PVDynStatus
$DEVICETOPIC/set/pv/NurPV70Status:.* bool70PVDynStatus

bool70PVDynActive 1
bool70PVDynStatus 1

An diesen beiden Registern erkennt man die aktuelle Einstellung, auch wenn am Display das "70% beachten" verändert wurde.


SetList

nurpv70dynact:0,1 { qq($DEVICETOPIC/config/set/pv/nurpv70dynact $EVTPART1) }
nurpv70dynw { qq($DEVICETOPIC/config/set/pv/nurpv70dynw $EVTPART1) }

bool70PVDynStatus:0,1 { qq($DEVICETOPIC/set/pv/NurPV70Status $EVTPART1) }


Das kleine Problem ist nun jedoch das ferngesteuerte bedienen der Schaltfläche "70% beachten", denn der Zustand wird über "$DEVICETOPIC/pv/bool70PVDynStatus:.* bool70PVDynStatus" signalisiert, das aktivieren geht jedoch über $DEVICETOPIC/set/pv/NurPV70Status:.*
Damit ich nun nicht zwei Definitionen habe, habe ich es auf das selbe reading bool70PVDynStatus gelegt. Allerdings scheint nun zwischen dem Wechsel von 0 und 1 noch zusätzlich ein Blank zu entstehen.

Die Frage ist nun, ob ich das mit dem MQTT richtig gemacht habe, oder wie es besser implementiert werden kamm. MQTT verwende ich momentan eher Empirisch :-)

Hier noch die Code Passage, wo das wohl programmiert ist:
https://github.com/snaptec/openWB/blob/1ceaeee579545ab69b6136ace27be514c5ccbe32/runs/mqttsub.py#L1175

            if (msg.topic == "openWB/set/pv/NurPV70Status"):
                if (int(msg.payload) >= 0 and int(msg.payload) <= 1):
                    client.publish("openWB/pv/bool70PVDynStatus", msg.payload.decode("utf-8"), qos=0, retain=True)
                    f = open('/var/www/html/openWB/ramdisk/nurpv70dynstatus', 'w')
                    f.write(msg.payload.decode("utf-8"))
                    f.close()

Demnach ist der Name für das Setzen und die Signalisierung im MQTT unterschiedlich definiert, aber davon verstehe ich zu wenig...

EDIT: Hier noch die Events, wo man sogar das Blank Event auch sehen kann

2022-06-30 09:38:56.559 MQTT2_DEVICE WB_1 bool70PVDynStatus: 1
2022-06-30 09:38:56.595 MQTT2_DEVICE WB_1 bool70PVDynStatus:
2022-06-30 09:39:01.183 MQTT2_DEVICE WB_1 bool70PVDynStatus: 1


EDIT 20220702 : Heute war der erste Tag für einen Testmit 70% beachten.
Im Diagramm sieht man sehr schön, wie die Ladezeit sich verlängert hat und wie während der Zeit noch ins Netz eingespeist wurde.
BEV ist lila und die schwarze Fläche bis zur blauem Linie geht ins Netz, oder in den Hausspeicher.
Nun werde ich nurpv70dynw dynamisch mit dem Verbrauch der anderen Starkverbraucher verändern, damit während deren Laufzeit nicht die Ladeleistung unnötig verringert wird.
rot ist die LWWP, gelb der Wirlpool, grün die Brunnen Pumpe und rose die Waschmaschiene.
Dadurch wird die Ladekurve zwischen 14 und 15 Uhr gleichmäßiger.

Über eine Hilfe zum MQTT würde ich mich nach wie vor freuen, ansonsten ziehe ich natürlich mit dem Thema Eigenverbrauch und BEV Laden in einen anderen Thread um ;-)

VG
   Christian
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

Beta-User

#46
Hmm, nachdem bisher keiner geantwortet hat, der sowas hat, hier mal der Versuch, das von der theoretischen Seite her anzugehen...

Zitat von: ch.eick am 30 Juni 2022, 09:17:52
Relevante MQTT Register in readingList

$DEVICETOPIC/config/get/pv/nurpv70dynact:.* nurpv70dynact
$DEVICETOPIC/config/get/pv/nurpv70dynw:.* nurpv70dynw
$DEVICETOPIC/config/set/pv/nurpv70dynact:.* nurpv70dynact
$DEVICETOPIC/config/set/pv/nurpv70dynw:.* nurpv70dynw


[...]

für die aktive Anzeige:
$DEVICETOPIC/pv/bool70PVDynActive:.* bool70PVDynActive
$DEVICETOPIC/pv/bool70PVDynStatus:.* bool70PVDynStatus
$DEVICETOPIC/set/pv/NurPV70Status:.* bool70PVDynStatus

[...]
Die Frage ist nun, ob ich das mit dem MQTT richtig gemacht habe, oder wie es besser implementiert werden kamm. MQTT verwende ich momentan eher Empirisch :-)
MAn. ist es ein logischer Fehler, wenn man die eigenen "set" (oder "get")-Anweisungen über die readingList auswertet. Mit MQTT2_SERVER sollte das (ohne explizit gesetztes Attribut rePublish) auch gar nicht funktionieren.

ZitatDemnach ist der Name für das Setzen und die Signalisierung im MQTT unterschiedlich definiert, aber davon verstehe ich zu wenig...
Es sollte idealtypischerweise nach meinem Verständnis immer so sein, dass die Anweisung und das Ergebnis auf unterschiedlichen Topics gesendet bzw. empfangen werden. Sonst hätte man "Schleifengefahr".

Da anscheinend zwischendurch eine leere Payload gesendet wird, müßtest/könntest du die rausfiltern, Kurzanleitung wäre zu finden in https://wiki.fhem.de/wiki/MQTT2_DEVICE_-_Schritt_f%C3%BCr_Schritt#Bedingte_Hash-R.C3.BCckgaben.

Hier könnte man evtl. mit einer length-Abfrage (für $EVENT (das steht für die payload)) die leeren Werte rausfiltern?

EDIT: Wenn du die Änderungen/Anweisungen von FHEM aus direkt in den Reading-Werten sehen willst, müßtest du setStateList auf "irgendwas" setzen. Dann werden die Reading-Werte aber erst zu "set_1" etc., bis die Rückmeldung von der Gegenseite kommt. Willst du hier vermutlich eher nicht.
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

ch.eick

Zitat von: Beta-User am 04 Juli 2022, 09:57:02
Hmm, nachdem bisher keiner geantwortet hat, der sowas hat, hier mal der Versuch, das von der theoretischen Seite her anzugehen...
MAn. ist es ein logischer Fehler, wenn man die eigenen "set" (oder "get")-Anweisungen über die readingList auswertet. Mit MQTT2_SERVER sollte das (ohne explizit gesetztes Attribut rePublish) auch gar nicht funktionieren.
Okay, da kenne ich mich im MQTT zuwenig aus. Ich habe das jetzt dann mal empirisch bereinigt.
In der readingList wären dann diese topics

bool* liefert den Zustand der Konfiguration zurück und ist nur als reading eingetragen
$DEVICETOPIC/pv/bool70PVDynActive:.* bool70PVDynActive
$DEVICETOPIC/pv/bool70PVDynStatus:.* bool70PVDynStatus

Diese beiden Topics werden auch nur gelesen und zeigen den aktuellen Zustand
$DEVICETOPIC/config/get/pv/nurpv70dynact:.* nurpv70dynact
$DEVICETOPIC/config/get/pv/nurpv70dynw:.* nurpv70dynw

Zum setzen habe ich dann in der ssetList folgendes

Hier wird ein Schwellwert für die 70% gesetzt
nurpv70dynw { qq($DEVICETOPIC/config/set/pv/nurpv70dynw $EVTPART1) }

Und hier wird das "70%_beachten" im Untermenü aktiviert, damit die Konfiguration mit dem Regeln beginnt.
NurPV70Status:0,1 { qq($DEVICETOPIC/set/pv/NurPV70Status $EVTPART1) }

Die Rückmeldung erfolgt dann über nurpv70dynact bei der readingList.


Zitat
Es sollte idealtypischerweise nach meinem Verständnis immer so sein, dass die Anweisung und das Ergebnis auf unterschiedlichen Topics gesendet bzw. empfangen werden. Sonst hätte man "Schleifengefahr".
Das wäre dann mit der obigen Einstellung gegeben :-)

Zitat
Da anscheinend zwischendurch eine leere Payload gesendet wird, müßtest/könntest du die rausfiltern, Kurzanleitung wäre zu finden in https://wiki.fhem.de/wiki/MQTT2_DEVICE_-_Schritt_f%C3%BCr_Schritt#Bedingte_Hash-R.C3.BCckgaben.

Hier könnte man evtl. mit einer length-Abfrage (für $EVENT (das steht für die payload)) die leeren Werte rausfiltern?

EDIT: Wenn du die Änderungen/Anweisungen von FHEM aus direkt in den Reading-Werten sehen willst, müßtest du setStateList auf "irgendwas" setzen. Dann werden die Reading-Werte aber erst zu "set_1" etc., bis die Rückmeldung von der Gegenseite kommt. Willst du hier vermutlich eher nicht.
Diesen Teil habe ich jetzt noch nicht verfolgt, da ich zuerst die Trennung machen wollte.

Bei der Verarbeitung det Events im DOIF habe ich jetzt von einer Nummerischen Abfrage mit "==" auf einen Text Vergleich mit "eq" gewechselt. Dadurch kommen dann im Perl auch keine Warnungen bei nicht Nummerischen Werten wie Blank oder leerer String.

Sollte es da noch weitere Probleme geben melde ich mich nochmal mit den dann neuen Meldungen ;-)

VG
    Christian
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

Beta-User

Kurz zu
ZitatDie Rückmeldung erfolgt dann über nurpv70dynact bei der readingList.
MAn. sollten setter und Readings möglichst gleich heißen, damit der Zusammenhang für den User besser erkennbar ist. Ich würde daher die setList anpassen.
ZitatDiese beiden Topics werden auch nur gelesen und zeigen den aktuellen Zustand
$DEVICETOPIC/config/get/pv/nurpv70dynact:.* nurpv70dynact
$DEVICETOPIC/config/get/pv/nurpv70dynw:.* nurpv70dynw
Topics mit sowas wie 'config/get/' sehen für mich immer nach Senderichtung aus und sind Kandidaten für getList. Habe daher arge Zweifel, ob das richtig ist!
getList ist "das schwierigste" der drei Attribute, falls du eine Beschreibung hast, wie der Kreislauf ist und welche Werte da wie zusammenpassen, kann ich ggf. weiterhelfen...
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

ch.eick

Zitat von: Beta-User am 06 Juli 2022, 14:06:28
Kurz zu MAn. sollten setter und Readings möglichst gleich heißen, damit der Zusammenhang für den User besser erkennbar ist.
Die Verwirrung entsteht bei mir daraus, dass die openWB beim set das NurPV70Status im Toping erwartet. Deshalb hatte ich es auch so benannt.

NurPV70Status:0,1 { qq($DEVICETOPIC/set/pv/NurPV70Status $EVTPART1) }

Nach Deinem Hinweis würde dann das daraus
nurpv70dynact:0,1 { qq($DEVICETOPIC/set/pv/NurPV70Status $EVTPART1) }


Zitat
Ich würde daher die setList anpassen.Topics mit sowas wie 'config/get/' sehen für mich immer nach Senderichtung aus und sind Kandidaten für getList. Habe daher arge Zweifel, ob das richtig ist!
getList ist "das schwierigste" der drei Attribute, falls du eine Beschreibung hast, wie der Kreislauf ist und welche Werte da wie zusammenpassen, kann ich ggf. weiterhelfen...
Das steht alles in der readingList und habe ich aus dem openWB MQTT Device so übernommen.
Was wäre denn der Unterschied zwischen der readingList und der getList ?
Mein Verständnis wäre, alles was die openWB von sich aus sendet gehört in die readingList .

Danke für Deine unermüdliche Hilfe

VG  Christian
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

Beta-User

ZitatNach Deinem Hinweis würde dann das daraus
nurpv70dynact:0,1 { qq($DEVICETOPIC/set/pv/NurPV70Status $EVTPART1) }
Vermutlich geht es auch einfacher, den Ausflug nach Perl kann man sich m.E. hier sparen:
nurpv70dynact:0,1 $DEVICETOPIC/set/pv/NurPV70Status $EVTPART1
Zitat von: ch.eick am 06 Juli 2022, 15:27:24
Das steht alles in der readingList und habe ich aus dem openWB MQTT Device so übernommen.
Was wäre denn der Unterschied zwischen der readingList und der getList ?
Mein Verständnis wäre, alles was die openWB von sich aus sendet gehört in die readingList .
Letzteres ist prinzipiell richtig, ich habe hier nur (wegen der komischen Namensgebung in den Topics) den Eindruck, dass da ein externer Server am Werk ist (also MQTT2_CLIENT als IO-Modul im Einsatz ist)? Dann bekommt man nämlich auch die eigenen Messages zurück, und nicht nur das, was die Gegenseite "von sich aus" sendet...

Ansonsten ist getList eher mit setList verwandt, man hat darüber halt die Option, asynchron was bei der Gegenstelle abzufragen.
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

ch.eick

Zitat von: Beta-User am 06 Juli 2022, 15:45:35
Vermutlich geht es auch einfacher, den Ausflug nach Perl kann man sich m.E. hier sparen:
nurpv70dynact:0,1 $DEVICETOPIC/set/pv/NurPV70Status $EVTPART1
Okay, dass kann ich testen, ich mag keine Umwege :-)

Zitat
Letzteres ist prinzipiell richtig, ich habe hier nur (wegen der komischen Namensgebung in den Topics) den Eindruck, dass da ein externer Server am Werk ist (also MQTT2_CLIENT als IO-Modul im Einsatz ist)? Dann bekommt man nämlich auch die eigenen Messages zurück, und nicht nur das, was die Gegenseite "von sich aus" sendet...

Ansonsten ist getList eher mit setList verwandt, man hat darüber halt die Option, asynchron was bei der Gegenstelle abzufragen.

Hiel mal ein gekürztes List der openWB und des MQTT2_CLIENT
Das Konstrukt habe ich aus dem Wiki und dem Forum, da ich MQTT erst noch lernen muss.

Internals:
   BUF       
   Clients    :MQTT2_DEVICE:MQTT_GENERIC_BRIDGE:
   ClientsKeepOrder 1
   DEF        192.168.178.61:1883
   DeviceName 192.168.178.61:1883
   FD         17
   FUUID      616c669b-f33f-61a8-e225-0e4ee6dcabf5155c
   FVERSION   00_MQTT2_CLIENT.pm:0.260550/2022-05-17
   NAME       WB_1_MQTT2
   NR         472
   PARTIAL   
   STATE      opened
   TYPE       MQTT2_CLIENT
   WBCallback
   clientId   WB_1_MQTT2
   eventCount 10
   lastMsgTime 1657118963.05161
   nextOpenDelay 5
   MatchList:
     1:MQTT2_DEVICE ^.
     2:MQTT_GENERIC_BRIDGE ^.
   READINGS:
     2022-06-30 15:13:04   state           opened
Attributes:
   DbLogExclude .*
   autocreate no
   group      PV Eigenverbrauch
   icon       solar_icon
   room       MQTT2_DEVICE
   sortby     312


=========================================================================

Internals:
   CID        WB_1_MQTT2
   DEF        WB_1_MQTT2
   FUUID      616c669b-f33f-61a8-f109-302fc3709d956d55
   FVERSION   10_MQTT2_DEVICE.pm:0.258890/2022-03-27
   IODev      WB_1_MQTT2
   LASTInputDev WB_1_MQTT2
   MSGCNT     2632404
   NAME       WB_1
   NR         473
   STATE      <html><table border=2 bordercolor='darkgreen' cellspacing=0 style='width: 100%'>

< snip >

</html>
   TYPE       MQTT2_DEVICE
   WB_1_MQTT2_MSGCNT 2632404
   WB_1_MQTT2_TIME 2022-07-06 16:43:37
   eventCount 44468
   Helper:
     DBLOG:
       ChargeMode:
         LogDB:
           TIME       1657101638.90532
           VALUE      NurPV
       DailyYieldAllChargePointsKwh:
         LogDB:
           TIME       1657116612.47068
           VALUE      24.01

< snip >

       lp_1_pluggedladungakt:
         LogDB:
           TIME       1657089505.75644
           VALUE      1
   OLDREADINGS:
   READINGS:
     2022-07-06 16:42:10   ASchieflast     2
     2022-06-30 15:13:04   ActualPriceForCharging 0
     2022-07-06 12:08:54   ChargeMode      NurPV
     2022-06-30 15:13:04   ConfiguredChargePoints 2

< snip >

     2022-07-06 12:12:57   topicSender     
     2022-06-30 15:13:04   updateInProgress 0
     2022-06-30 15:13:04   wizzardDone     100
Attributes:
   DbLogExclude .*
   DbLogInclude lp_1_.*,.*AllChargePoints.*,ChargeMode
   IODev      WB_1_MQTT2
   alias      WB_1
   autocreate 0
   comment    Die openWB besteht aus zwei Ladepunkten.
   devicetopic openWB
   disable    0
   event-on-change-reading lp_1_.*,.*AllChargePoints.*,ChargeMode,bool70.*
   group      PV Eigenverbrauch
   icon       fuel
   readingList $DEVICETOPIC/global/WHouseConsumption:.* WHouseConsumption
$DEVICETOPIC/global/WAllChargePoints:.* WAllChargePoints
$DEVICETOPIC/global/ChargeMode:.* {my %h=(0=>'SofortLaden',1=>'MinPV',2=>'NurPV',3=>'Stop',4=>'Standby'); return {ChargeMode=>$h{$EVENT}}}

$DEVICETOPIC/global/awattar/boolAwattarEnabled:.* boolAwattarEnabled

< ganz viel raus geschnitten, weil die openWB ist echt geschwätzig :-) >


$DEVICETOPIC/set/system/reloadDisplay:.* reloadDisplay
$DEVICETOPIC/set/system/topicSender:.* topicSender
$DEVICETOPIC/set/lp/2/faultState:.* lp_2_faultState
$DEVICETOPIC/set/lp/2/faultStr:.* lp_2_faultStr
$DEVICETOPIC/set/lp/2/ChargePointEnabled:.* lp_2_ChargePointEnabled


   room       MQTT2_DEVICE,Strom->Photovoltaik
   setList    Lademodus:SofortLaden,Min+PV,NurPV,Stop,Standby { my %h=(SofortLaden=>'0','Min+PV'=>'1',NurPV=>'2',Stop=>'3',Standby=>'4');qq($DEVICETOPIC/set/ChargeMode $h{$EVTPART1}) }
DirectChargeSubMode:Aus,kWh_Laden,SoC_Laden { my %h=(Aus=>'0',kWh_Laden=>'1',SoC_Laden=>'2');qq($DEVICETOPIC/set/lp1/DirectChargeSubMode $h{$EVTPART1}) }
lp_1_socToChargeTo:50,60,70,80,90,100 { qq($DEVICETOPIC/config/set/sofort/lp/1/socToChargeTo $EVTPART1) }
priorityModeEVBattery:0,1 { qq($DEVICETOPIC/config/set/pv/priorityModeEVBattery $EVTPART1) }

nurpv70dynact:0,1 { qq($DEVICETOPIC/config/set/pv/nurpv70dynact $EVTPART1) }
nurpv70dynw { qq($DEVICETOPIC/config/set/pv/nurpv70dynw $EVTPART1) }

NurPV70Status:0,1 { qq($DEVICETOPIC/set/pv/NurPV70Status $EVTPART1) }
   sortby     311
   stateFormat {

< snip >

}
   userReadings lp_1_kWhCounter_Month:lp_1_kWhCounter.* {  round(ReadingsVal("$NAME","lp_1_kWhCounter",0) - ReadingsVal("$NAME","lp_1_kWhCounter_init_Month",0),0) },
lp_1_kWhCounter_Year:lp_1_kWhCounter.* {  round(ReadingsVal("$NAME","lp_1_kWhCounter",0) - ReadingsVal("$NAME","lp_1_kWhCounter_init_Year",0),0)  },

lp_2_kWhCounter_Month:lp_2_kWhCounter.* {  round(ReadingsVal("$NAME","lp_2_kWhCounter",0) - ReadingsVal("$NAME","lp_2_kWhCounter_init_Month",0),0) },
lp_2_kWhCounter_Year:lp_2_kWhCounter.* {  round(ReadingsVal("$NAME","lp_2_kWhCounter",0) - ReadingsVal("$NAME","lp_2_kWhCounter_init_Year",0),0)  }
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

Beta-User

OK, also richtig geraten 8) : Es ist ein MQTT2_CLIENT am Werk....

Dann solltest du dir mal https://wiki.fhem.de/wiki/MQTT2_CLIENT#ignoreRegexp ansehen. Da muss m.E. (neben den dort genannten "sonstigen" Kommando- und "autoconfigure"-Bausteichen) dann noch ein Schnippsel rein, der in etwa so aussieht:
<DEVICETOPIC>/(set|/config/[gs]et)
Wobe eben <DEVICETOPIC> hier durch die passende Angabe in Klartext zu setzen wäre.

(Im MQTT-Bereich ist es meistens einfacher, mit raw-listings zu arbeiten).
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

ch.eick

Zitat von: Beta-User am 06 Juli 2022, 17:04:48
OK, also richtig geraten 8) : Es ist ein MQTT2_CLIENT am Werk....

Dann solltest du dir mal https://wiki.fhem.de/wiki/MQTT2_CLIENT#ignoreRegexp ansehen. Da muss m.E. (neben den dort genannten "sonstigen" Kommando- und "autoconfigure"-Bausteichen) dann noch ein Schnippsel rein, der in etwa so aussieht:
<DEVICETOPIC>/(set|/config/[gs]et)
Wobe eben <DEVICETOPIC> hier durch die passende Angabe in Klartext zu setzen wäre.

(Im MQTT-Bereich ist es meistens einfacher, mit raw-listings zu arbeiten).
Wie kann ich den den MQTT2_CLIENT weg lassen? Was ich nicht brauche macht auch keine Probleme :-)
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

Beta-User

Zitat von: ch.eick am 06 Juli 2022, 17:36:16
Wie kann ich den den MQTT2_CLIENT weg lassen? Was ich nicht brauche macht auch keine Probleme :-)
Wenn ich das richtig im Kopf habe, befindet sich der Server auf der Wallbox => du brauchst MQTT2_CLIENT, aber du solltest es richtig konfigurieren. Also nur abbonieren, was du auch brauchst bzw. verwerfen, was "Unsinn" ist (die eigenen Befehle fallen in diese Kategorie). "verwerfen" = ignoreRegexp entsprechend setzen, wobei es dann ausreicht, den Schnippsel "solo" zu verwenden, da ja keine anderen Geräte mit diesem (externen) Server auf der Box sprechen.
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

ch.eick

Zitat von: Beta-User am 06 Juli 2022, 17:43:42
Wenn ich das richtig im Kopf habe, befindet sich der Server auf der Wallbox => du brauchst MQTT2_CLIENT, aber du solltest es richtig konfigurieren. Also nur abbonieren, was du auch brauchst bzw. verwerfen, was "Unsinn" ist (die eigenen Befehle fallen in diese Kategorie). "verwerfen" = ignoreRegexp entsprechend setzen, wobei es dann ausreicht, den Schnippsel "solo" zu verwenden, da ja keine anderen Geräte mit diesem (externen) Server auf der Box sprechen.
Na super, da habe ich schon wieder etwas was ich noch lernen muss :-)

Vielen Dank für die vielen Anregungen
   Christian
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

MichaelO

Moin,
weil ich gerade gesehen habe (auch wenn schon älter)... wenn man per set den Lademodus von Sofortladen auf einen anderen wechselt und man zusätzlich preisbasiertes Laden nutzt, muss man noch die Freigabe der konfigurierten LP beachten.

Hintergrund ist: In der Version 1.9x wird bei Überschreitung des maximal erlaubten Preises nicht der Strom an den LP reduziert, sondern der LP wird gesperrt. Fällt der Preis unter die Grenze, wird er wieder freigegeben. Das ist ein recht unglückliches Verhalten, soll aber erst mit der Version 2.x geändert werden. Wenn nun wegen zu hohem Preis die LP gesperrt sind, und man dann den Modus wechselt, bleibt die Sperrung erhalten. Hab da an der Box selbst schon mehrfach am Abend blöd da gestanden, weil kein PV geladen wurde, weil ich das übersehen hatte.

Dazu habe ich gerade gestern eine Lösung an openWB geschickt, die bei gesperrten LP und Umschaltung durch Klick auf den Button in einen anderen Modus fragt, ob entsperrt werden soll. Ob das angenommen wird, weiß ich nicht, habs bei mir in einem extra Theme laufen. Wichtig ist: Wenn man den Modus per MQTT umschaltet, passiert nichts mit evtl. gesperrten LP, die muss man dann selbst freigeben.
Gruß
Michael