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

[freetz]

Wieso schreibst Du jetzt hier im Forum, wenn Du mir gerade vorgestern noch gemailt hast? Deine Konfigurationseinträge zeigen mehrere Fälle, die von dem Standard abweichen (u.a. "Verbositätsmodus -> Entwickler"), und wenn Du die REA70 über PPS angeschlossen hast, ist es kein Wunder, dass nichts funktioniert, wenn Du als Bus-Typ "BSB" und nicht "PPS" auswählst.

[barzw]

Ich nutze BSB-LAN seit knapp 2 Jahren. Den Umstieg auf 5.09 hatte ich vor ein paar Monaten erfolgreich durchgeführt. Jetzt hatte ich in HomeAssistant ein paar Probleme mit dem Update (seit der Version 2025.8.x). Nach vielen Tests und Versuchen hatte ich (auch wegen der vielen Fehler zu BSB-LAN wegen '---' BSB-LAN mal aus HomeAssistant rausgenommen und danach hat das Update von HomeAssistant sofort problemlos funktioniert.

Beim neu hinzufügen von BSB-LAN (Nutzung von Auto Discovery) sind jetzt aber einige der benötigten Sensoren als TEXT angekommen. Ein Workaround habe ich über die Erstellung von Template-Sensoren in Yaml lösen können. Gerne würde ich das Problem jedoch grundsätzlich lösen.

Kann mir hier jmd. weiterhelfen?

Gruß
Winfried

[freetz]

Das dürften die Sensoren sen, die eben ein "---" übermitteln. Schau' mal hier im ChangeLog:

- New configuration variable `mqtt_unit_set` defines how measurement units are sent via MQTT when using Rich JSON or auto-discovery: The default CF_MQTT_UNIT_LOCALIZED will send unit strings in the configured language, exactly as shown in the BSB-LAN web interface. CF_MQTT_UNIT_HOMEASSISTANT sends unit strings in the format used by Home Assistant to avoid warning messages about unknown unit strings. CF_MQTT_UNIT_NONE will send MQTT messags with no unit text. This setting only applies to MQTT and does not affect the web interface which will always show units in the localized language. When selecting Home Assistant as the unit format, the 'device_class' string will be sent for compatible parameters during MQTT auto-discovery so that automations can correctly identify sensor classes.
- Configuration variable `replaceDisabled` defines the value for a deactivated/inactive status in parameters with numerical values. Defaults to `---`; Home Assistant expects `None` here, others might expect `0`. Keep in mind that both is inexact information, but depending on the circumstances, this might be the closest you would get if otherwise the external systems would not accept the data coming from BSB-LAN.

[n300]

Hallo Leute,
Ich hätte eine Frage zum Logging via MQTT.
Derzeit frage ich jede Menge Sensor Daten zyklisch direkt über die JSON-API ab (mit node-Red). Hierbei ist ja bekanntlich das Thema, dass der BSB-LAN Adapter unresponsive wird, solange er mit der einer einzelnen Abfrage beschäftigt ist. Daher hab ich dafür in Node-Red einen einen Queuing Mechanismus gebaut, der Abfragen sequenziell abarbeitet und das Queue-Gate immer erst öffnet, wenn von der vorherigen Abfrage kein Connection-Timeout zurückgekommen ist - ansonsten retry ... usw. Es werden auch immer alle Sensorwerte einzeln abgefragt, weil das via Batches zu ziemlich langen Timeouts führen kann.

Soweit ich mich erinnere, war das dem Arduino-Framework geschuldet, dessen Mini-Webserver nur single threaded arbeitet und eben erst wieder Anfragen entgegen nimmt, sobald er mit der aktuellen Aufgabe fertig ist.

Ist das bei MQTT ebenfalls so?
Mir ist klar, dass die MQTT Integration super funktionieren wird für explizite Lese- und Schreibvorgänge von klassichen SET-Parametern wie Solltemperatur, die immer nur vom User verändert werden. Aber wie verhält es sich da mit Temperaturfühler, die ich ja auch aktiv pollen muss um an deren aktuellen value zu kommen? Stottert da der BSB-LAN ebenfalls?

[thetaphi]

Hi,

Ich hätte eine Frage zum Logging via MQTT.
Derzeit frage ich jede Menge Sensor Daten zyklisch direkt über die JSON-API ab (mit node-Red). Hierbei ist ja bekanntlich das Thema, dass der BSB-LAN Adapter unresponsive wird, solange er mit der einer einzelnen Abfrage beschäftigt ist. Daher hab ich dafür in Node-Red einen einen Queuing Mechanismus gebaut, der Abfragen sequenziell abarbeitet und das Queue-Gate immer erst öffnet, wenn von der vorherigen Abfrage kein Connection-Timeout zurückgekommen ist - ansonsten retry ... usw. Es werden auch immer alle Sensorwerte einzeln abgefragt, weil das via Batches zu ziemlich langen Timeouts führen kann.

Soweit ich mich erinnere, war das dem Arduino-Framework geschuldet, dessen Mini-Webserver nur single threaded arbeitet und eben erst wieder Anfragen entgegen nimmt, sobald er mit der aktuellen Aufgabe fertig ist.

Ist das bei MQTT ebenfalls so?
Mir ist klar, dass die MQTT Integration super funktionieren wird für explizite Lese- und Schreibvorgänge von klassichen SET-Parametern wie Solltemperatur, die immer nur vom User verändert werden. Aber wie verhält es sich da mit Temperaturfühler, die ich ja auch aktiv pollen muss um an deren aktuellen value zu kommen? Stottert da der BSB-LAN ebenfalls?

Genau deswegen sollte man MQTT nutzen. Das ist immer singlethreaded weil der Client (BSB-LAN) eine einzelne dauerhafte Verbindung zum MQTT Broker hat und dort Messages bekommt. Die werden sequentiell abgearbeitet. Wenn aktiv ein Parameter abgefragt werden soll sendet man eine Poll Message und irgendwann holte BSB die ab und sendet eine oder mehrere Nachrichten mit allen angefragten Parametern. Im Zentrum ist der MQTT Broker der die Queue aller Messages verwaltet.

Wenn du mit mqtt arbeiten willst musst du deine Logik etwas umbauen und asynchron machen.

Uwe

Uwe

[freetz]

Weil hier immer wieder mal davon gesprochen wird, dass man BSB-LAN mit dem ESP32 doch multi-threaded machen könnte: Das würde in weiten Teilen nichts helfen, weil der BSB-/LPB-Bus ja weiterhin nur eine Anfrage zur Zeit bearbeiten kann. Es würde also nichts helfen, mehrere Anfragen gleichzeitig bearbeiten zu können, wenn am Ende doch alles serialisiert über den Bus gehen muss.
Wenn man ausschließlich eigene Sensoren abfragen würde, ginge das schneller, aber dann müsste man das wieder als Logik hinterlegen, was paralell laufen kann und was nicht. Da diese Abfragen aber nicht die gleiche Verzögerung beinhalten wie die Abfragen über den Bus, wäre der Vorteil vermutlich kaum messbar.

[n300]

Die Frage ist für mich jetzt: "Hängt" der Adapter beim Abfragen über MQTT ebenfalls, bis er intern damit fertig ist?
Wenn ja, macht es für mich nicht viel Sinn meinen Workflow zu ändern. Ich frage 12 Sensoren 10 sekündlich (!!) ab und 40 States (nicht Sensoren) alle 60 Sekunden ab. Über Node-Red hab ich das stabil im Griff, ist aber natürlich nicht so komfortabel Hand zu haben wie über HA und MQTT. Da ich alle ausgelesenen Werte zwar super im RAM habe, aber jedes UI-Element zu Fuß im Node-Red bauen muss. Wenn MQTT jetzt maßgebliche Vorteile hätte und ich meinen recht komplizierten Queuing Mechanismus ablösen könnte, würd ich das machen. Wenns dieselben "Busy" Problemchen hat und ich mir dann ein neues Queueing bauen muss um sicher zu gehen, dass alle Anfragen wirklich durchkommen, lass ichs wie es ist.

Möglicherweise könnt ichs auch hybrid lösen. Also die States (wie Heizungsmodus, TWW Soll, Heizkreis Soll, etc) könnt ich via MQTT machen, da sich die eh nicht oft ändern. und bei den Sensoren bleib ich bei meinem Mechanismus.

[freetz]

Der Weg ist egal, am Ende landet alles bei der Abfrageroutine, und die ist seriell.
Ich frage mich ehrlich gesagt, was für einen Informationsgewinn es bringt, Sensoren 10sekündlich abzufragen, aber abgesehen davon kann ein Parameter schon mal zwei Sekunden dauern. Das heißt, dass Du bei 12 Sensoren auf jeden Fall länger als das eigentliche Abfrageintervall brauchst. Das heißt, es gibt keine "Luft" für BSB-LAN für das, was zwischen den Abfragen gemacht werden könnte (Logging etc.). Die wenigsten Parameter ändern sich so schnell/signifikant, als dass das sinnvoll wäre, aber das musst Du am Ende selber entscheiden.

[n300]

Ach der ist an sich recht flott. idR bekomm ich so 5 Get-Requests/Sek locker durch. Allerdings verlangsame ich den Flow bewusst über node-Red um den Adapter responsive zu halten auf max. 2/Sek. Das Queue-Gate wird auch erst geöffnet, nachdem ich ein valides JSON vom BSB-LAN erhalte. Das funktioniert wunderbar seit Jahren.
Kesseltemp zB. (ist eigentlich ne Wärmepumpe) ändern sich schon recht schnell. Gerade wenn sie abtauen muss. Um solche Dinge ordentlich zu erkennen und per Automation auch darauf reagieren zu können ist eine gute Auflösung schon gut. Meine WP ist leider etwas zickig was das Taktverhalten angeht auf Grund von besch...eidener Firmware auf die ich keinen Einfluss habe. Dafür hab ich diverse Workarounds gebastelt um das vollautomatisch abfangen zu können. Das geht aber umso besser, je genauer die Datenlage ist.
Bei zu schwacher Sample Rate ist es nämlich kaum zu unterscheiden, ob meine WP abtauen will, oder ob sie wie wild taktet.

[freetz]

Genau, das wäre einer der (wenigen) Werte, wo eine höhere Auflösung Sinn macht. Dazu vielleicht noch Vorlauf und Rücklauf, wenn vorhanden, aber alles andere reicht dicke mit 60 oder 300 Sekunden Auflösung. Welche 12 Werte sich so schnell verändern, wäre mir schleierhaft, aber ist auch etwas OT...

[n300]

2-3 Sensoren sind wirklich wichtig. Die Anderen sind jetzt optional und ich machs eben, weils problemlos möglich ist und meine Grafana Charts etwas hübscher macht