Hallo,
ich kenne mich mit MQTT nicht so gut aus und da ich im BSB LAN Thread bekommen habe versuche ich es hier.
https://forum.fhem.de/index.php/topic,29762.6405.html#lastPost
Für meine Heizungssteuerung benutze ich den BSB Lan Adapter. Seit der Version 3 ist es möglich diesen per MQTT an
fhem anzubinden. Momentan benutze ich noch HTTPMOD. BSB Lan kann MQTT sowohl als ,,Plan Text" , ,,JSON oder
Rich JSON.
Nach Eintrag der Parameter in die Logging Parameterliste (in den Einstellungen BSB Lan) werden diese als
Readings in fhem angezeigt. Leider gibt es Unterschiede im Readinginhalt (HTTPMOD MQTT) z.B.
PARAMETER HTTPMOD MQTT
700 Automatik 1 - Automatik
8009 In Betrieb 18 - In Betrieb
Kann man den Inhalt der Readings so verändern das nur der Text in die Readings geschrieben werden. ( bei HTTPMOD wird dies
dur REGEX erreicht. )
Besteht die Möglichkeit den Readingname zu verändern. (z.B. 8700 auf Aussentemperatur)
Hi,
ja kann man, siehe https://regex101.com/r/XmCqCR/1
Gruß Otto
Vielleicht etwas ausführlicher:
- ich würde die JSON-Optionen mal ausprobieren, das erzeugt tendenziell weniger Event-Loops.
Auf Basis des Text-Formats:
- Du kannst "hinten" einfach den gewünschten Reading-Namen hinschreiben, siehe https://wiki.fhem.de/wiki/MQTT2_DEVICE_-_Schritt_f%C3%BCr_Schritt. Da screenshot (bäh!) ohne konkretes Beispiel.
- "readingsChange" kann genutzt werden, um den Vorschlag von Otto123 umzusetzen, per regex die Werte zu ändern. Oder du machst es direkt in Perl (siehe Link oben)....
Hallo Beta-User,
nach der Umstellung BSB Lan auf das Json Format sehen die Readings wie folgt aus.
Im MQTT-Explorer wird folgendes angezeigt.
{"BSB_LAN":{"status":{"8009":"216 - Standby"}}} was mir den Namen des Readings erklärt.
Nur wie ich den Reading Namen ändern kann erschließt sich mir nicht. Irgendwie fehlt mir der
Ansatz für die Lösung.
BSB_LAN_status_1000 1 - Automatik 2022-12-28 15:16:42
BSB_LAN_status_1010 19.0 2022-12-28 15:16:43
BSB_LAN_status_1012 17.0 2022-12-28 15:16:43
BSB_LAN_status_1020 0.36 2022-12-28 15:16:43
BSB_LAN_status_20300 283038AB13210181 2022-12-28 15:16:47
BSB_LAN_status_20301 28FFF2B313210181 2022-12-28 15:16:47
BSB_LAN_status_700 1 - Automatik 2022-12-28 15:16:42
BSB_LAN_status_710 20.0 2022-12-28 15:16:42
BSB_LAN_status_712 17.0 2022-12-28 15:16:42
BSB_LAN_status_720 0.36 2022-12-28 15:16:42
BSB_LAN_status_8009 216 - Standby 2022-12-28 15:16:43
BSB_LAN_status_8310 25.8 2022-12-28 15:16:43
BSB_LAN_status_8311 31.4 2022-12-28 15:16:44
BSB_LAN_status_8312 26.4 2022-12-28 15:16:44
BSB_LAN_status_8314 25.5 2022-12-28 15:16:44
BSB_LAN_status_8326 --- 2022-12-28 15:16:44
BSB_LAN_status_8330 10719 2022-12-28 15:16:45
BSB_LAN_status_8331 51604 2022-12-28 15:16:45
BSB_LAN_status_8380 1426 2022-12-28 15:16:45
BSB_LAN_status_8700 8.1 2022-12-28 15:16:45
BSB_LAN_status_8735 50 2022-12-28 15:16:45
BSB_LAN_status_8743 --- 2022-12-28 15:16:46
BSB_LAN_status_8744 26.4 2022-12-28 15:16:46
BSB_LAN_status_8773 24.4 2022-12-28 15:16:46
BSB_LAN_status_8774 26.4 2022-12-28 15:16:46
BSB_LAN_status_8830 44.2 2022-12-28 15:16:47
BSB_LAN_status_8831 50.0 2022-12-28 15:16:47
IODev MQTT2_Server 2022-12-28 15:14:27
status online 2022-12-28 15:15:17
readingList BSB_LAN:Broetje/status:.* status
BSB_LAN:Broetje/json:.* { json2nameValue($EVENT) }
Hmm, wenn dann per JSON nur umständlich verpackte Einzelreadings kommen, ist es auch keine wirkliche Verbesserung...
Und ist das mit "Broetje" jetzt wegen JSON umgestellt oder eine weitere Aktion von dir? Mal angenommen, das ist von dir und allgemeingültig, müßte es mit der Text-Variante beispielhaft in etwa so gehen (raw-Format):
attr DEVICE readingList Broetje/status:.* status\
Broetje/700:.* {$mode = $EVENT =~m,\d+\s-\s(.*),? $1 : $EVENT; {mode => $mode}}
ZitatBroetje/700:.* {$mode = $EVENT =~m,\d+\s-\s(.*),? $1 : $EVENT; {mode => $mode}}
Ohne $mode zu deklarieren wird das aber nix und selbst dann passt auch net, weil dann der Rest (
"}}} ) mit anhängt an dem match.
So in der Art eher, zumindest klappts so, aber ich und regexp ;D :
Broetje/700:.* {my $mode = $EVENT =~m,\d+\s-\s(.*)...., ? $1 : $EVENT; {mode => $mode}}
Also MQTT und BSB-LAN ist IMHO recht einfach.
Am Ende des Tages hängt es ja davon ab, welche Register Du abonniert hast.
Hier mal meine "readingList" als Anfang:
BSB_LAN:BSB-LAN/status:.* status
BSB_LAN:BSB-LAN/json:.* { json2nameValue($EVENT, 'json_', $JSONMAP) }
BSB_LAN:BSB-LAN/8700:.* Aussentemperatur
BSB_LAN:BSB-LAN/8743:.* Vorlauf_1
BSB_LAN:BSB-LAN/8314:.* Kessel_Ruecklauf
BSB_LAN:BSB-LAN/8830:.* Trinkwasser_Ist
BSB_LAN:BSB-LAN/8325:.* PWM_Drehzahl
BSB_LAN:BSB-LAN/8326:.* Brennermodulation
BSB_LAN:BSB-LAN/8327:.* Wasserdruck
BSB_LAN:BSB-LAN/8310:.* Kesseltemperatur
BSB_LAN:BSB-LAN/8308:.* Kesselpumpe_Drehzahl
BSB_LAN:BSB-LAN/8300:.* Brennerstufe_T2
BSB_LAN:BSB-LAN/8301:.* Brennerstufe_T8
BSB_LAN:BSB-LAN/8950:.* Schienenvorlauf_Ist
BSB_LAN:BSB-LAN/8951:.* Schienenvorlauf_Soll
BSB_LAN:BSB-LAN/8731:.* BSB-LAN_8731
BSB_LAN:BSB-LAN/8732:.* BSB-LAN_8732
BSB_LAN:BSB-LAN/8005:.* kessel_status
BSB_LAN:BSB-LAN/8381:.* Gas_Heizen
BSB_LAN:BSB-LAN/8382:.* Gas_Wasser
BSB_LAN:BSB-LAN/8383:.* Gas_Gesamt
BSB_LAN:BSB-LAN/8831:.* Trinkwasser_Soll
BSB_LAN:BSB-LAN/8009:.* brenner_status
BSB_LAN:BSB-LAN/700:.* heizung_status
BSB_LAN:BSB-LAN/710:.* Raumtemperatur_Soll
BSB_LAN:BSB-LAN/MQTT:.* MQTT
BSB_LAN:BSB-LAN/0:.* BSB-LAN_0
Abonniere ich neue Werte, füge ich dies per Hand dazu.
Läuft hier einwandfrei - woran ich noch hänge, ist die Steuerung via MQTT, aber das ist ein anderes Thema.
@sledge .. vielen Dank werde das heute Abend mal testen.
Als Hinweis: Ich habe bei BSB-LAN unter MQTT "plain" eingestellt - warum erst als JSON "verpacken", um es dann in FHEM wieder auseinanderzunehmen.
Zitat von: sledge am 29 Dezember 2022, 13:35:16
warum erst als JSON "verpacken", um es dann in FHEM wieder auseinanderzunehmen.
Weil es - wenn es denn anders gelöst wäre als es hier der Fall zu sein scheint - in FHEM effizienter ist, wenn mehrere Infos auf einmal kommen (was bei JSON ginge). Pro readingList-Eintrag gibt es eben eine Event-loop, wenn da eine Message kommt, ganz egal, wie viele Infos da drin dann verpackt sind ;) .
Wenn wie hier nur jeweils immer eine Message pro Einzel-Info kommt, ist die Frage aber völlig berechtigt!
Valider Punkt - indeed. Mangels Notwendigkeit noch nicht aus der Perspektive betrachtet. Vom Design her sauberer.
Aber bei der Menge an Registern, die man sinnvoller Weise alle 60 Sekunden aus seiner Gastherme zieht, hält sich die Systemlast durch die ggf unnötig ausgelösten Events in Grenzen.
Hallo und vielen Dank, der Rename der Readings funktioniert nun. Vor dem Testen habe ich den BSB Lan auf PlainText
umgestellt.
Folgendes habe ich in die readinglList eingefügt.
BSB_LAN:Broetje/status:.* status
BSB_LAN:Broetje/json:.* { json2nameValue($EVENT, 'json_', $JSONMAP) }
BSB_LAN:Broetje/700:.* HK1_Betriebsmodi
BSB_LAN:Broetje/710:.* HK1_OGKomfortsollwert
BSB_LAN:Broetje/8009:.* Brenner_Status
BSB_LAN:Broetje/8310:.* Kesseltemperatur
Nun würde ich gerne verstehen wie es Funktioniert, was bewirkt diese Zeile
BSB_LAN:Broetje/json:.* { json2nameValue($EVENT, 'json_', $JSONMAP) }
Habe gedacht dies ist nur notwendig wenn MQTT mit Json läuft, und dann
auch nur in Zusammenhang mit dem Attribute jsonMap
Was jetzt noch fehlt ist das formatieren des Readinginhalts ...
ich denke so (Beispiel):
BSB_LAN:Broetje/700:.* {my $var= $EVENT =~m,\d+\s-\s(.*), ? $1 : $EVENT; {HK1_Betriebsmodi => $var}}
Annahme: In $EVENT steht 1 - Automatik
Die Funktion des regExp war in meinem Link oben erklärt.
Das Ganze steht in einem ternären Ausdruck - Erklärung siehe https://perldoc.perl.org/perlop#Conditional-Operator
Zuletzt wird ein Key-Value Pärchen {Readingsname => Inhalt} zurückgegeben, welches FHEM an der Stelle entsprechend verarbeitet.
Hallo Otto123 .. Vielen Dank so funktioniert es ....
Zitat von: Beta-User am 29 Dezember 2022, 14:25:23
Weil es - wenn es denn anders gelöst wäre als es hier der Fall zu sein scheint - in FHEM effizienter ist, wenn mehrere Infos auf einmal kommen (was bei JSON ginge).
Wenn wie hier nur jeweils immer eine Message pro Einzel-Info kommt, ist die Frage aber völlig berechtigt!
Das ginge theoretisch, aber es würde bedeuten, dass wir einen entsprechend großen String vorhalten müssten, der dann die JSON-Struktur von x Parametern gleichzeitg aufnehmen könnte. Da wir es bei den von uns verwendeten Arduino Due und ESP32 Systemen mit Speichergrößen im
Kilobyte-Bereich zu tun haben, ist das nicht so ohne Weiteres möglich.
Wenn es einen signifikanten Performance-Gewinn bedeuten würde, würde ich noch mal darüber nachdenken, aber wenn es mehr um Eleganz geht, ist es in meinen Augen sicherer, bei der jetzigen Lösung zu bleiben.
Zitat von: freetz am 01 Januar 2023, 13:19:05
Das ginge theoretisch, aber es würde bedeuten, dass wir einen entsprechend großen String vorhalten müssten, der dann die JSON-Struktur von x Parametern gleichzeitg aufnehmen könnte. Da wir es bei den von uns verwendeten Arduino Due und ESP32 Systemen mit Speichergrößen im Kilobyte-Bereich zu tun haben, ist das nicht so ohne Weiteres möglich.
Na ja, mit ESP32 ist schon zumindest etwas Speicher vorhanden, und man bräuchte auch nicht unbedingt immer alles in einen einzigen JSON zu verpacken, sondern könnte z.B. Pakete zu je 10 Infos machen.
Da die Sendefrequenz aber gleichzeitig gering zu sein scheint (?), ist die Diskussion vermutlich müßig, ich sehe hier ja nur einzelne Bruchstücke vom Gesamtbild und kann von daher nur die "Eleganz-Frage" beantworten. Und da ist eine Info/JSON-Blob halt irritierend wenig ;) . Wollte jedenfalls niemandem auf die Füße treten ::) .
Zitat
Wenn es einen signifikanten Performance-Gewinn bedeuten würde, würde ich noch mal darüber nachdenken, aber wenn es mehr um Eleganz geht, ist es in meinen Augen sicherer, bei der jetzigen Lösung zu bleiben.
Wie gesagt: Was "besser" ist, ist nicht zuletzt auch eine Frage der Sendefrequenz...
Nein, das war ja ein wichtiger Hinweis (da ich selber kein MQTT nutze, war mir nicht klar, dass das überhaupt eine Möglichkeit ist). Falls wir irgendwann mal auf leistungsfähigere Hardware umsteigen und den Support für ältere Geräte auslaufen lassen, ist das sicherlich eine Option, insofern danke für den Hinweis!