Hallo,
in diesem Thread https://forum.fhem.de/index.php?topic=129896.0 (https://forum.fhem.de/index.php?topic=129896.0) sind ja sehr schön die 3 Methoden zum publishen beschrieben.
Über die 1. Stufe (notify) bin ich nie rausgekommen - funktioniert aber zuverlässig.
Jetzt möchte ich meiner OpenWB gerne den SOC des Batteriespeichers mitteilen. Die OpenWB hätte diesen Wert gerne im Topic openWB/set/houseBattery/%Soc
Der Wert kommt aber nicht an, was ich auf das Sonderzeichen im Topic zurückführe. Andere Werte (z. B. PV Leistung) kommen nämlich tadellos an.
Ich habe schon nach Dereferenzierung von Sonderzeichen gesucht, bin aber nicht schlau geworden.
Wie müßte das notify bzw. der publish Befehl aussehen ? So funktioniert es offensichtlich nicht:
defmod n_SOC2OpenWB notify VictronJKBMS:SOC:.* { fhem("set openWB/set/houseBattery/%SOC" . int($EVTPART1) ) }
Grüße, Gerd
Schon mal mit maskieren probiert (\)?
defmod n_SOC2OpenWB notify VictronJKBMS:SOC:.* { fhem("set openWB/set/houseBattery/\%SOC" . int($EVTPART1) ) }
Mache Sonderzeichen haben in Perl bestimmte Bedeutungen. Wenn du diese als Sonderzeichen verwenden möchtest, musst du sie maskieren.
Maskieren, nicht dereferenzieren, richtig ;)
Ja, hatte ich schon mal probiert, und hab's jetzt nochmal probiert.
Es tut leider nicht.
Noch eine andere Idee ?
Irgendwer muss den Befehl doch senden, diese Angabe (wer und mit welchem Befehl) fehlt doch zw. set openWB... in dem Fhem-Befehl ?
Dazu muss doch auch eine Meldung im Logfile stehen ?
Denke da muss nix escaped werden, das Device welches den Topic senden soll muss ergänzt werden mit dem entsprechenden setter und ein Leerzeichen nach dem SOC ?
Beispiel:
{ fhem("set MQTT2_Server publish openWB/set/houseBattery/%SOC " . int($EVTPART1) ) }
@ TomLee: Da hast Du absolut recht.
Ich gebe aber zu Bedenken, dass dieser Befehl funktioniert:
defmod n_EHZ_P2OpenWB notify myEHZremote:power:.* { fhem("set openwb publish openWB/set/evu/W " . int($EVTPART1) ) }
openwb ist ein MQTT2_CLIENT.
Es war ja nur ein Beispiel der "Syntax" wegen ...
Mir ist noch nicht klar, ob das Problem geloest ist.
Mit einem MQTT2_CLIENT (m2c) fuktionieren beide Alternativen:
fhem> { fhem("set m2c publish /a%b c") }
fhem> set m2c publish /a%b c
@FHEMGerd: was genau heisst "funktioniert es offensichtlich nicht"?
Was steht in "Show MQTT traffic" (in der Detailseite der MQTT2_CLIENT) oder in der Ausgabe von "mosquitto_pub -v -t#" ?
Das Problem betreffend dem Sonderzeichen im topic ist nicht gelöst.
Es ist so, das dieser Befehl (also das notify mit set Kommando und ohne Sonderzeichen im topic) in der openwb (ein m2c) ankommt (ebenso wie andere ohne Sonderzeichen im topic), das sehe ich z. B. an den Graphen, die die openwb malt:
defmod n_Victron_P2OpenWB notify VictronSystem:Battery_Power:.* { fhem("set openwb publish openWB/set/houseBattery/W " . int($EVTPART1) ) }Und dieser hier eben nicht, egal ob ich das % jetzt maskiere oder nicht (mehrmals probiert - und ja, die openwb will das topic Soc, nicht SOC):
defmod n_Victron_SOC2OpenWB notify VictronJKBMS:SOC:.* { fhem("set openwb openWB/set/houseBattery/\%Soc " . int($EVTPART1) ) }Einen mosquitto Broker habe ich nicht installiert, ich muss daher die Antwort schuldig bleiben was "mosquitto_pub -v -t#" liefern würde.
In "Show MQTT Traffic" stehen jede Menge Zeilen, ich zeige mal beispielhaft einige, ich lese das so, dass SENT bzw. RCVD die Sicht von FHEM ist.
Die Leistung des Batterie WR ist dabei (topic openWB/set/houseBattery/W), der SOC taucht nicht auf.
21:17:29.413 SENT openWB/set/houseBattery/W -347
21:19:47.567 SENT openWB/set/evu/WhImported 11587710
21:19:47.577 SENT openWB/set/evu/WhExported 28748680
21:19:47.586 SENT openWB/set/evu/W -2
21:19:48.843 RCVD openWB/lp/1/VPhase1 228.5
21:19:48.848 RCVD openWB/lp/1/VPhase3 230.6
@FHEMGerd
- bitte meine oben gezeigten Tests mit angepassten Parameter durchfuehren, und dabei auch "Show MQTT Traffic" pruefen
- das notify kann man auch mit "trigger VictronJKBMS SOC:BLA" ausfuehren, das hilft beim debuggen, bzw. beobachten des Monitors
- gibt es einen Grund, warum der Aufruf ueber perl laeuft (und damit fuer Sonderzeichenprobleme mehr Angriffsflaeche bietet)?
{ fhem("set X Y") } ist equivalent mit "set X Y". $EVTPARTx wird auch ohne perl ersetzt.
- ganz vergessen: Bei Problemen muss im FHEM-Log eine Meldung stehen. Wurde das Log daraufhin geprueft?
Zitat von: FHEMGerd am 22 Oktober 2023, 21:26:42defmod n_Victron_SOC2OpenWB notify VictronJKBMS:SOC:.* { fhem("set openwb openWB/set/houseBattery/\%Soc " . int($EVTPART1) ) }
Fehlt da nicht ein "publish" nach dem "set openwb"?
Zitat- gibt es einen Grund, warum der Aufruf ueber perl laeuft ...
Offensichtlich weil in $EVTPART1 keine Ganzzahl übergeben wird ?
gute Nachricht: es tut jetzt :)
schlechte Nachricht: ich kann Euch nicht sagen, woran es lag, dass es nicht funktioniert hat. :-[
Ich kann nur berichten was ich alles gemacht, bzw. nicht gemacht habe.
Erstmal das notify, dass jetzt offensichtlich tut, Maskierung ist also das Richtige:
define n_Victron_SOC2OpenWB notify VictronJKBMS:SOC:.* { fhem("set openwb publish openWB/set/houseBattery/\%Soc " . int($EVTPART1) ) }Ich bin ziemlich sicher, dass ich das erfolglos bereits so probiert hatte (@Christian83: auch mit publish).
Die fhem log Dateien hab ich durchwühlt, und da waren m. E. auch Fehler bzgl. obigen notifys - evtl. bzgl. falscher Notationen - drin.
Da die log Dateien überaus gross waren und ich mich beim Löschen überaus dämlich angestellt hab (wildcard für 2023 statt 2022) kann ich Euch die genauen Fehler leider nicht mehr zeigen. Sinngemäß stand da, ich müsse erst das topic (?) definieren, bevor ich es verwende bzw. publishe.
Letztendlich geholfen hat m. E. dann ein fhem Neustart, evtl. war es auch der reboot des raspi (auf dem FHEM läuft), das lief immerhin schon 100 Tage.
sudo systemctl stop fhem
sudo systemctl start fhem
Nebenbei krieg ich seitdem auch wieder Daten per BLE von meinen 3 Mija Temperatur/Feuchte-Sensoren (Modul XiaomiBTLESens).
Also ein Indiz, dass sich vorher FHEM - sagen wir mal - verheddert hatte.
Ein "set X Y" anstelle { fhem("set X Y") } hab ich nicht probiert.
Auch "Show MQTT Traffic" hab ich mir nicht näher angeschaut.
Im Eventmonitor war m. E. nichts auffälliges.
Es tut mir leid, dass Ihr über ein Pseudo-Problem nachgedacht habt, dessen Lösung schon frober am 22.10. beschrieben hat.
Vielen Dank an dieser Stelle für Eure kompetente Hilfe.
Das ist hier wirklich ein sehr angenehmes Forum, man wird nicht gleich, eigentlich gar nicht mit Häme und Belehrungen überzogen.
Gerd
Ein
attr VictronJKBMS mqttPublish SOC:topic={"openWB/set/houseBattery/\%Soc"}
würde vermutlich das selbe bewirken, ohne zusätzlichem Notify
@developer: Der Vorschlag gefällt mir, werde ich probieren.
Ist das im Prinzip das, was rudolfkoenig im eingangs erwähnten thread in seinem Post vom 26.10.2022 vorschlägt: ?
ZitatDie naechste Stufe ist MQTT_GENERIC_BRIDGE, was das Verbinden von notify/DOIF uebernimmt, indem man in der Quelle per Attribut spezifiziert, welches topic+message per publish gesendet werden soll, wenn sich was aendert.
D.h. ich brauche dann die MQTT_GENERIC_BRIDGE als eigenes device ?
Was ist effizienter (oder ressourcenschonender) aus Sicht FHEM, das notify oder der Weg über das Attribut in der Signalquelle ?
ZitatD.h. ich brauche dann die MQTT_GENERIC_BRIDGE als eigenes device ?
Ja.
ZitatWas ist effizienter (oder ressourcenschonender) aus Sicht FHEM, das notify oder der Weg über das Attribut in der Signalquelle ?
Fuer die Uebertragung eines Datenpunktes ist notify vmtl. etwas effizienter, d.h. messbar, aber nicht merkbar.
Es ging mir mehr um die Pflegbarkeit, wenn man mehr Daten austauschen will.