LAN-Anbindung für BSB-Bus (Brötje, Elco Thision etc.)

[freetz]

Nachdem es einige Nachfragen dazu gab: Logging auf einen MQTT Broker ist nun mit neuester Version auf GitHub möglich. Broker über
#define MQTTBrokerIP 192,168,XXX,XXX
in der _config.h eintragen (Kommas statt Punkte!), der Broker muss auf 1883 ohne Username und Passwort lauschen. Topic ist "BSB-LAN", Payload ist rudimentärstes JSON. Falls jemand einen schönen Use-Case dafür hat, bitte gerne mal hier vorstellen!

[mifh]

Hallo freeetz,

das sieht ja schon sehr gut aus. Und ein connect mit username und password ist ja inzwischen auch im git. Sehr gut!
Ich habe noch ein paar Kommentare/Verbesserungsvorschläge:

• ein kleines #define MQTTTopicPrefix /mein/eigenes/prefix würde es erlauben, dem Zusammenbau des MQTTTopic zu parametrieren, also z.B.
  

Code Auswählen Erweitern

#ifdef MQTTTopicPrefix
String MQTTTopic = MQTTTopicPrefix;
#else
String MQTTTopic = "BSB-LAN/";
#endif

Damit könnte man dann sein eigenes Namensschema bei bestehenden MQTT Installationen (z.B. bei mir ) verwenden.[/li]

• Den MQTT-Connect in der loop halte ich für fehleranfällig. Das kann schon mal einen Moment dauern und dann kriegst Du evtl. events auf dem Bus nicht mit. Dummerweise habe ich keine Ahnung, was man beim Arduino dagegen tun würde. Auf dem esp32 packe ich das Handling der Verbindung einfach in einen zweiten Thread, dann blockt das nicht.
  
• Auf jeden Fall würde ich daher vermeiden, die Verbindung bei jedem Durchlauf abzubauen. Ich denke, den MQTTClient.disconnect solltest Du weglassen. Wenn Du Pech hast, schmeisst der MQTT-Server Dich trotzdem raus, wenn Du nicht oft genug die Connection aktiv nutzt, aber dazu prüfst Du ja die Verbindung.


• Ein separater Timer mqtt_log_intervall wäre ja vielleicht auch ganz sinnvoll, falls man da einen anderen Takt braucht.

Da mein BSB-Lan noch nicht an meiner Heizung hängt, habe ich noch nicht ausprobieren können, wie die Nachrichten ankommen aber ich bin schon gespannt und würde das gerne nutzen!

[freetz]

Das mit dem Präfix kann ich machen, einen eigenen Counter finde ich ehrlich gesagt überflüssig, weil ich mir kein (überzeugendes) Szenario vorstellen kann, wo man sowohl auf SD, als auch auf MQTT loggt, aber das zu unterschiedlichen Zeiten. Wer das unbedingt braucht, kann dafür die _custom.h verwenden, die ja einen Timer hat.

Das erneute connecten hat wieder mal seinen Grund in den Aussetzern der Ethernet Library, denn ohne den Disconnect stieg das Programm bei mir nach zwei MQTT-Übertragungen aus - vermutlich, weil wieder alle Sockets belegt waren. Mir dem Disconnect waren die Probleme weg.
Das Ganze nur einmal zu Beginn zu machen, wäre problematisch, wenn BSB-LAN wochenlang läuft und die Verbindung zum MQTT Broker einmal abbricht, dann würde sie dann nicht mehr aufgebaut.
Ich habe es jetzt aber so gemacht, dass nicht für jeden Log-Parameter eine Verbindung aufgebaut wird, sondern pro Log-Durchlauf.

Ein User hat auf Grafana schon tolle Visualisierungen damit hinbekommen, vielleicht kriege ich ihn dazu, ein kleines Tutorial dazu für's Handbuch zu schreiben. Für diejenigen, die nur loggen wollen und denen die grafische Darstellung von BSB-LAN zu spartanisch ist, wäre das eine interessante Alternative zu FHEM...

[mifh]

Nicht dass wir da an einander vorbeireden: das Prüfen der Verbindung und ein neuer Connect im Bedarfsfall ist auf jeden Fall ok. Das mache ich auch so.

Ich bin nicht von dem Disconnect begeistert. Wenn Du den brauchst, weil ansonsten der Ethnernetstack durcheinanderkommt, ok, dann ist das halt so. Hat halt auch Nachteile. Aber wenn es nicht anders geht, ist das eine schnelle Entscheidung.
Du könntest auch ein PubSubClient.loop() alle 1-2 Sekunden ausprobieren. Zwar horchst Du nicht auf Nachrichten per MQTT, aber wenn ich es richtig verstanden habe, hält loop() auch die Connection auf.

[freetz]

Nein, schon verstanden. WIe gesagt, die Ethernet-Blockade verschwand in dem Moment, wo ich ein Disconnect hinzugefügt hatte. Mag sein, dass der Destruktor nach Verlassen des Scopes noch einen Timeout o.ä. hat oder in PubSubClient nicht so definiert ist, aber Stand jetzt lässt es sich nicht anders (halbwegs) stabil fahren.
Viel häufiger als einmal pro Minute wird man vermutlich auch nicht loggen - da jetzt bei den doch relativ knapp bemessenen vier Sockets immer noch welche offen zu halten, nur damit man sie dann nicht wieder öffnen muss, ist dann doch vielleicht etwas übertrieben.
Und das bis zu dreimalige Versuchen eines Verbindungsaufbaus mit einer Sekunde Pause dazwischen blockiert zwar die weitere Ausführung, aber das lässt sich beim Arduino nicht anders machen. Bei BBS gibt es (außer den Brenner-Broadcast-Meldungen) ja auch keine Meldungen von der Heizung an sich, die werden ja alle von BSB-LAN initiiert. Problematisch wird das nur bei PPS-angebundenen Heizungen, weil da ständig was über den Draht geht und da wirklich Infos verpasst werden können (die aber dann etwas später erneut wieder "angeboten" werden) und es ggf. zu einer Unterbrechung der Verbindung mit der Heizung kommen kann. Insofern überlege ich noch, ob ich das "fire-and-forget"-Prinzip von MQTT (in QoS-Level 0) einfach übernehme und bei einer fehlgeschlagenen Verbindung dann eben ein Messpunkt ausfällt. Mal schauen. MQTT-Präfix ist jetzt auf GitHub.

[cubase]

Ein User hat auf Grafana schon tolle Visualisierungen damit hinbekommen...

Das wäre in dem Fall wohl ich
Ich möchte mich zuerst mal ganz FETT bei Frederik bedanken, der die MQTT-Funktion so schnell integriert hat!!!
Nach gut einem Jahr Abstinenz hatte ich vor zwei Tagen bei ihm angefragt, ob nicht ein MQTT-Publish möglich wäre. Und nun das: 

https://snapshot.raintank.io/dashboard/snapshot/Wko18UzX8DhieGLuqN9aw3HEiYhBUBfC?orgId=2

Das ist ein 6h-Snapshot meiner Grafana-Visualisierung. Ein kleines HowTo ist in Bearbeitung...

[freetz]

Danke, gern - als ich festgestellt hatte, dass Schotty mich schon vor einiger Zeit mal auf die Library hingewiesen hatte, war es dann die Kombination mit Deinem Hinweis, das ganze wie das SD-Karten-Logging zu behandeln, der den Knoten im Kopf gelöst hatte, der Rest war dann einfach - gutes Teamwork also .

Meine Annahme, dass Grafena sich aber direkt mit MQTT-Telegrammen befüttern lässt, scheint aber nicht richtig zu sein, oder? Es muss also noch irgendwo (lokal?) eine InfluxDB-Datenbank installiert sein, womit man dann doch wieder einen Raspberry o.ä. bräuchte. Ich hatte die Hoffnung, dass man das vielleicht umgehen könnte und über so ein standardisiertes Protokoll wie MQTT direkt einen dieser Visualisierungsdienste nutzen könnte. Aber trotzdem ist es für die reinen Visualisierer, die nur hier und da mal eine Funktion über das Webinterface schalten möchten, sicher ein deutlich einfacherer Weg, als gleich eine FHEM-Instanz zu installieren (zumindest, wenn es grafisch auch so gut aussehen soll )...

[freetz]

PS: Da ich in Deiner Sig sehe, dass Du BSB-LAN auch mit Node-Red laufen hast, wozu es auch schon einige Anfragen gab, könntest Du da auch so einen kurzen Abriss zu schreiben? Das wäre sehr hilfreich!

[cubase]

Meine Annahme, dass Grafena sich aber direkt mit MQTT-Telegrammen befüttern lässt, scheint aber nicht richtig zu sein, oder? Es muss also noch irgendwo (lokal?) eine InfluxDB-Datenbank installiert sein, womit man dann doch wieder einen Raspberry o.ä. bräuchte

Die Werte werden halt vom Sensor (BSB lan) alle x Sekunden/Minuten nur in den "MQTT-Raum" geworfen. Ohne Broker ( z.B. Mosquitto) geht da m.M. eh nichts weiter. Somit brauchst Du schon einmal eine Instanz für den Broker. Wenn Du nur Momentanwerte anzeigen willst (also immer den aktuell/letzen mqtt publish) dann geht das ohne Speicherung (z.B. auf Android mit MQTTDash). Willst Du aber Graphen zeichnen muss man die Werte irgendwo speichern.

https://blog.doubleslash.de/mqtt-fuer-dummies/

[freetz]

Ja, das ist klar - nur der Broker lässt sich z.B. auf meiner NAS mit einem Klick ohne weitere Konfiguration installieren, das kriegt halt jeder hin. Ich dachte, dass Grafana (oder ein anderer Dienst) die Werte auch irgendwo speichert, denn ansonsten müssten ja bei jedem Aufruf immer alle Daten von der jeweiligen Datenbank durch's Netz geschoben werden, das wäre ja eine ganz schöne Bandbreitenverschwendung...

[cubase]

PS: Da ich in Deiner Sig sehe, dass Du BSB-LAN auch mit Node-Red laufen hast, wozu es auch schon einige Anfragen gab, könntest Du da auch so einen kurzen Abriss zu schreiben? Das wäre sehr hilfreich!

Gern.

Die Node-Red Installation hatte ich bis dato verwendet um die Werte aus dem BSB-lan-HTML-Interface  zu extrahieren und weiter zu verarbeiten/senden. In meinem Fall hatte ich die Werte weiter zu emoncms.org gesendet

Siehe Anhang : nodered_http_request


Den sozusagen Html-Parser in Nodered braucht es nun nicht mehr. Jetzt kann man einfach über eine Mqtt-Input Node die entsprechenden Werte (topics z.B. "BSB-LAN/8700" für Aussentemp.) beim Broker abbonieren/abholen (suscribe) und dann weiterverarbeiten wie gewünscht. (z.B. NodeRed-Dashbord, weitersenden zu Emoncms/Thinger.io, Thinkspeak, in DB speichern, usw.)

Siehe Anhang : nodered_bsb_sample

Ich könnte somit Node-Red auch nutzen um die Werte beim Broker abzuholen und weiter zu InfluxDB zum speichern zu senden, um daraus dann mit Grafana die Graphs zu plotten. Und genau das lasse ich aber  Telegraf machen. Somit entfällt für mich die NodeRed Instanz. Installationen somit:

-MQTT-Broker
-Telegraf oder(und)(1) Node-Red
-InfluxDB

-und für die Visualisierung der InfluxDB-Daten > Grafana


(1) Ich habe aber dennoch eine Node-Red Instanz, da ich z.B. damit Werte aus der BL-Net (UVR1611) hole und ich Werte wie oben angesprochen an externe Dienste wie Emoncms weiterleite.

(2) Apropos Broker. Der ist bei mir mittlerweile fester und wichtiger Bestandteil meiner Haus-IT, da ich auch Werte von etlichen Tasmota/Espeasy/Shelly...-Sensoren/Aktoren verarbeite und diese alle schön über mqtt senden/empfangen. Und jetzt auch meine olle Wärmepumpe

(3) bezüglich des Noder-Red Dashboards bin ich der Meinung, dass die Daten dort nicht persistent sind, sprich nach einem Neustart ist alles weg.

[cubase]

Ja, das ist klar - nur der Broker lässt sich z.B. auf meiner NAS mit einem Klick ohne weitere Konfiguration installieren, das kriegt halt jeder hin. Ich dachte, dass Grafana (oder ein anderer Dienst) die Werte auch irgendwo speichert, denn ansonsten müssten ja bei jedem Aufruf immer alle Daten von der jeweiligen Datenbank durch's Netz geschoben werden, das wäre ja eine ganz schöne Bandbreitenverschwendung...

Zum Broker. Ja, der ist schnell installiert. Da braucht es keine grossen Einstellungen.
Zum Breitband. Das stimmt eventuell. Bei mir liegt allerdings die Datenbank und Grafana  (und Broker) auf dem selben Server. Somit ist das Netz nur zum holen der mqtt-Nachrichten und zum Abruf des Grafana Frontends "belastet".

[Madmaxx126]

Liebe Leute,

Erstmal danke für das tolle Projekt, Ich hab seit ca. einem Jahr den Adapter an der Heizung aber erst jetzt Zeit gehabt daran rumzuspielen.
Ich hab eine Waterstage WP 5kw mit Steuerung RVS41.813/327, Gerätefamilie: 119, Gerätevariante: 235.

Ich hab mal mit dem Brute-Force-Scanner gespielt, mir sind da ein paar Sachen aufgefallen, aber ich bin mir nicht ganz sicher wie sich das verwenden lässt.

Meine WP ist begrenzt auf 80%. Startwert der Modulation ist 16%. (2870 Verdichtermodulation Max, 2871 Verdichtermodulation Min)
Das würde auf die 2 Werte hier passen:
593D0BA2
DC 80 06 0D 07 59 3D 0B A2 00 50 18 E3 ^M
593D0BA3
DC 80 06 0D 07 59 3D 0B A3 00 10 67 17 ^M
Das müssten %-Werte sein, kann man da den Datentyp VT_PERCENT verwenden, oder geht das mit obiger Ausgabe nicht? (wegen dem Enable 0x6)?

Interessant sind auch diese 4 5Byte-Werte hier:

053D1770
DC 80 06 10 07 05 3D 17 70 00 00 00 00 00 57 76
053D1771
DC 80 06 10 07 05 3D 17 71 00 00 00 00 00 12 D6
053D1772
DC 80 06 10 07 05 3D 17 72 00 00 00 30 92 7A 58
053D1773
DC 80 06 10 07 05 3D 17 73 00 00 00 AD 9C B0 81

Als D-Word sind die groß genug um eine 5-stellige Zahl abzubilden und genau hintereinander.
(Mit dem Unterschied daß das VT_DWORD auch ein enable-Bit hat, der scan nicht.)
In den Lan_defs hab ich sie jedenfalls nicht entdecken können.
Bei mir sind die Werte 0 / 0 / 12434 / 44444.
Meiner Vermutung nach könnten das die Codes für Inbetriebsetzung, Fachmann, OEM und OEM2 sein (ich hab ein PDF gefunden in dem Zeilennummern 6345 Code Inbetriebsetzung / 6346 Code Fachmann/ 6347 Code OEM genannt werden).
12434 ist außerdem schon mal im Haustechnikdialog als Code genannt worden.
(https://www.haustechnikdialog.de/Forum/t/15176/QAA73-Hilfe-KeinZugriff-mehr-auf-Parameter-500)
Das Problem ist nur - sie funktionieren nicht

Während der Codeeingabe gibts auch nix an Kommunikation am Bus, ich denke also der Code ist nochmal im Bedienteil gespeichert und in der Steuerung stehen nur die Defaults. (Wie bei der Zeit)
Vielleicht hilfts jemandem bei dem der Code im Bedienteil und in der Steuerung ident sind.
Das Thema Display ist ja gerade Ende 2018 aufgepoppt, aber was ich so gelesen hab kann man das Display ja weder fragen noch beschicken, oder?

(...ich hab noch vor wenn Zeit vorhanden ist die ganzen anderen Paramter zu checken, und zu melden...)

Grüße,
Markus

[Schotty]

Hi Madmaxx,
nur ganz kurz: Erstmal danke für die 'Meldung' und deine Beobachtungen!
Nur eine kurze Bitte, um etwaigen 'Stress' zu vermeiden: OEM-Codes bitte nicht im Klartext als solche benannt posten - es hat seinen Grund, dass die Hersteller die normalerweise streng unter Verschluss halten..
Ansonsten dazu: 1. der Link funzt bei mir nicht, 2. hast du m.W. eine ISR (QAA55/75 und nicht QAA73=OpenTherm), 3. die Codes sind herstellerspezifisch und je nach Firmenbranding unterschiedlich (sprich, Fujitsu wird einen anderen Code haben als bspw Brötje oder Elco), 4. bei Parametern in der OEM-Ebene sollte man absolute Vorsicht walten lassen, wenn man denn wirklich irgendwie den passenden Code gefunden und Zugriff hat. Mit falschen Einstellungen geht nämlich ruckzuck nichts mehr..
Gruß

[Schotty]

@cubase:
Danke für die Beispiele, evtl melde ich mich nochmal direkt bei dir, wenn ich die Beispiele ins Handbuch übernehme - momentan komme ich zeitlich leider noch nicht dazu. Gruß