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

[freetz]

"Mann, komm malwieder runter!"
"[...] nach ewiger Leserei [...]"

Keine Ahnung, was Du ewig gelesen hast, aber zu dem, was Du suchst, kommt man mit drei Klicks, die nun wirklich nicht unintuitiv sind. Aber wenn Du meinst, dass Du in dem Ton von mir irgendeine Unterstützung bekommst, kannst Du sehr froh sein, dass Du Glück hast, dass Dir andere helfen.

Davon ab: Ich bin kein Admin dieses Forums, aber ob in einem FHEM-Forum HomeAssistant-Diskussionen toleriert, kann ich nicht beurteilen...

[bimmerfriend]

@ freetz, lass gut sein. Ich weiss nicht, was Du mit meinem Ton hast. Ich hab Dich weder angegriffen, noch Deine Arbeit nicht wertgeschätzt, noch hab ich mich in irgendeiner Weise beschwert. Ich lass mich nur ungern von der Seite anblasen.

Aber wie gesagt, alles gut. Frohes Schaffen noch und einen schönen Montag noch

[freetz]

Ach so, Du lässt Dich nicht gern von der Seite anblasen, aber ich soll "mal runterkommen", weil ich Dich darauf hinweise, dass exakt das, was Du suchst, im Wiki steht, und sogar worauf Du klicken musst, um dahin zu kommen? Nur weil ich Dich gleichzeitig auch darauf hinweise, dass ein bisschen Eigeninitiative auch eine Form von Wertschätzung der vielen Stunden bedeutet, die in so eine Doku (von dem Projekt mal ganz abgesehen) fließen? Ich wäre in der umgekehrten Situation ehrlich gesagt ganz klein mit Hut, wenn mir sowas Offensichtliches entgehen würde, aber nun ja...

[thetaphi]

Hallo Freetz,

Davon ab: Ich bin kein Admin dieses Forums, aber ob in einem FHEM-Forum HomeAssistant-Diskussionen toleriert, kann ich nicht beurteilen...

Ich habe das auch überlegt und vorher geschaut. Die Anzahl an Antworten und Fragen auch in diesem Forum bezüglich HASS liegt inzwischen recht hoch. Es wurde bisher toleriert, deswegen hatte ich meine Erfahrung hier gepostet. Generell ist dieses Forum ja die "Hauptanlaufstelle" für BSB-LAN Kommunikation und mehr und mehr Leute gehen zu Home Assistant (und du selber hast hier auch schon Features bzgl. MQTT und der Home Assistant Anbindung hier gepostet). MQTT ist bei FHEM glaube ich nicht so relevant (da gibt's native Anbindung, oder?), aber bei HASS ist MQTT für viele die erste Wahl, weil es - wenn die Topic-Struktur gut ist und Auto-Discovery funktioniert - prima und universell funktioniert. Großes Lob zu den Recent Updates!

Danke auf jeden Fall. Wenn wir hier nichts mehr mit HASS posten sollen, wäre aber ein Hinweis in diesem Thread ganz oben gut, denn das werden die Leute immer tun. Falls ich also was falsch gemacht habe bzgl Home Assistant Hilfe/Howto, ich kann's zukünftig sein lassen.

Ich wollte hier @bimmerfriend helfen, weil es zur neuen Topic-Struktur und der spezielle Fall "Raumtemperatur senden" noch kein Howto gibt. Bei HASS gibt es kein spezielles BSB-LAN Forum, da gehen Fragen unter und werden dort auch als "zu speziell" empfunden. Dein Wiki ist sicher richtig, aber es behandelt für den Fall "Raumtemperatur Update" nur die HTTP-API, wenn man aber HASS nutzt ist MQTT die bessere Wahl weil es auch sequentiell abläuft, die HTTP API von BSB LAN hat bei Home Ass oft Probleme weil das Ding Heavy Multithreaded ist und so oftmals mehrere Poll Anfragen und oder Uhrzeit/Raumtemperatur Updates parallel kommen und das den single-threaded BSB-LAN Webserver oftmals überfordert. Bei MQTT ist alles sequentiell und BSB-LAN ist wunderbar stabil.

Liebe Grüße,
Uwe

P.S.: Seit dem Update des MQTT-Clienten ist es 100% stabil, die übrigen Reconnects/Ausfälle die ich noch beobachtet hatte, waren bei mir am Ende nur noch wegen PoE-Widerstands-Überhitzung des OLIMEX. Am Ende hat er aufgegeben und ich habe den Olimex auf WLAN umgestellt mit USB-Netzteil. Das Runtertransformieren von 53 Volt ist leider in dem Olimex "broken", v.a. wegen des Widerstandes von 4.7 kOhm Parallel zur Last um die Minimalanforderung von 10 mA für PoE-Erkennung zu erzeugen: Bei 53 Volt sind 4.7 kOhm fast 0.6 Watt verbrannte Energie und dabei werden die Elkos daneben gegrillt... (siehe das Olimex-Forum mit uraltem Thread und vielen Beschwerden). Die Updates waren aber trotzdem wichtig, denn einige der Ausfälle betrafen wirklich aktive Disconnects des Code wegen Timeouts (was aber auch dem schwächelnden Ethernet geschuldet war).

[bimmerfriend]

So, ich verlinke mal die beiden Welten, denn angefangen hat das Thema als HomeAssistant Frage im Nachbar-Forum:
https://community.simon42.com/t/bsb-lan-broetje-heizung-via-mqtt-in-ha/9963

Ich hoffe, damit ist allen, die auch etwas suchen, vielleicht ein bisschen geholfen und denen, die hier verwalten, bin ich nicht auf die Zehen getreten.

Aber zum Thema zurück:

Ich danke Dir nochmal, thetaphi! Ich habe versucht, die Schreiberei über die Confi-YAML zu machen, das war ja ein Holzweg... die Theorie ist jetzt schon mal klar, das Schreiben der Werte läuft auch prima. Nur will der Adapter den Setz-Wert noch nicht annehmen. Aber Du hast ja geschrieben, dass das erst mit neuester FW im BSB-LAN funktioniert. Da muss ich jetzt erst einmal ran, ich bin noch auf 4.0.53...

[thetaphi]

Hi,

Ich danke Dir nochmal, thetaphi! Ich habe versucht, die Schreiberei über die Confi-YAML zu machen, das war ja ein Holzweg... die Theorie ist jetzt schon mal klar, das Schreiben der Werte läuft auch prima. Nur will der Adapter den Setz-Wert noch nicht annehmen. Aber Du hast ja geschrieben, dass das erst mit neuester FW im BSB-LAN funktioniert. Da muss ich jetzt erst einmal ran, ich bin noch auf 4.0.53...

Die MQTT Topics sind in der alten Version ganz anders, bei der alten Version würde die Action auch ganz anders aussehen. Bei der alten Version sendet man an das Topic "BSB-LAN" auf der obersten Ebene und muss als Payload dann "I10000=xxxx" senden (das ist wie die URL Struktur; I = Inf Message, S = Set Message). Das macht es etwas komplizierter, weil das Topic-Payload dann anders ausschaut mit dieser Syntax.

Das YAML umschreiben ist leider mit der neuen Topic-Struktur etwas search/replace/copy/paste, man muss es aber nur einmal machen. Gerne auch in diesem Github Issue nachlesen wie man es sich "vereinfachen kann" (bzgl der meiner Meinung nach nutzlosen Category IDs, da sind freetz und ich uns aber nicht einig gewesen, dank "Wildcards" kann man es aber gut handeln): https://github.com/fredlcore/BSB-LAN/issues/680#issuecomment-2518549348

Ich sende bei mir auf in der neuen Topic-Struktur "BSB-LAN/poll" Nachrichten mit der Liste der Parameter IDs, die mich interessieren. Das ist flexibler, denn die Config von BSB-LAN Logging Parametern ist dabei vollständig leer und andererseits kann ich das Interval je nach Parameter anpassen. So Live-Werte die den aktuellen Kesselbetrieb betreffen (Feuerungsautomat Status, Kesseltemperatur,...) holt er bei mir alle 8 Sekunden, die normalen Temperaturen des Heizkreises alle 30 Sekunden und solche Dinge wie Sollwerte nur alle 10 Minuten oder wenn sich was anderes ändert. Und zuletzt die aktuellen Heizkurvensteilheiten usw. alle Stunde.

Gruß,
Uwe

P.S.: Ich habe auch noch einen stündlichen Trigger, der die Uhrzeit in der Heizung setzt. Dazu (auch neue Version) an "BSB-LAN/0/0/0/set" die Uhrzeit so senden: "{{ utcnow().timestamp() | timestamp_custom('%d.%m.%Y %H:%M:%S', true) }}" (Vorsicht, das ist das neue Zeitformat was auch nur mit neuer Version geht).
P.P.S.: Ich habe noch viele weiter Heizungsautomatisierungen drinnen: So setzt er die Reduzierttemperatur automatisch 1.5°C unter die Komfortsollwert, wenn ich außer Haus bin setzt er das Trinkwasser auf "40°C" (alternativ auch ganz aus, falls gewünscht kommt aber auf selbe raus). Außerdem holt er sich Trinkwasser-Sollwerttemperatur (als Referenz - daran erkennt er welcher Modus gerade läuft). Wenn <41°C wird es bei mir als "ausgeschaltet" gehandelt und steuert damit u.a. die Zirkulationspumpe, die in einem Zigbee Steckerschalter hängt. Der Trick mit den zwei Sollwerten hilft, weil es keine Möglichkeit gibt, bei angeschalteten Trinkwasserbetrieb den Reduziert- vs. Voll-Status zu erfahren, außer man kennt genau den Zeitplan. Bei der Heizung geht das, aber auch da nehme ich den aktuellen Raumsollwert aus BSB-LAN um dem Rest zu steuern. So muss man nicht alle möglichen Einstellungen logisch miteinander kombinieren. Wenn der Raumsollwert unter dem aktuellen Komfortsollwert liegt, weiß man dass die Anlage gerade reduziert ist oder sonst irgendwas unnormales macht.

[thetaphi]

Hi nochmal,

Zur Kontrolle, ob das Raumtemperatur setzen überhaupt funktioniert, solltest du mal über das Webinterface den Parameter 10000 auf irgendwas fiktives setzen und dann auf dem Heizungsdisplay kontrollieren, ob der Wert dort ankommt. Wenn das schon nicht geht, dann liegt es evtl an veralteter custom_defs-Datei, wo bei Parameter 10000 das "enforce as INF" fehlt. Dazu mal in den Changelog und die Doku von BSB-LAN schauen.

Background: Das Problem bei der Raumtemperatur ist, dass es nicht per "Set" gesetzt werden darf (dann ignorieren es anscheinend die meisten Controllervarianten), sondern als "Inf" Nachricht gesendet werden muss. Die custom-defs haben da ein Flag, was bei 10000 (HK1) und 10001 (HK2) einen "Workaround" aktiviert, so dass auch "Set" command automatisch in Inf durch BSB-LAN umgewandelt werden. Es muss etwa so aussehen (wichtig sind die FL-Flags am Ende), ich weiß nicht wie alt deine custom-defs.h Datei ist. Nicht einfach Copypasten, nur die FL_FORCE_INF und FL_SPECIAL_INF Flags mal kontrollieren:

{0x2D3D0215,  VT_TEMP,            10000, S10000,   0,                  NULL,         DEFAULT_FLAG+FL_WONLY+FL_FORCE_INF+FL_SPECIAL_INF, 255, 255},

Es ist dokumentiert, was da bei uralten Dateien geändert werden muss. Ich hatte zum Glück eine aktuelle Variante von freetz bekommen, weil ich das Modul im Oktober bestellt hatte.

Achtung: Nach 10 Minuten verschwindet der gesetzte Wert aber wieder, weil dann die Heizung sagt "das Raumthermometer sendet nix mehr, ich wechsel zurück nach Außentemperatur-Only".

Generell sollte aber korrekterweise "Inf" benutzt werden und nicht "Set".

Uwe

[bimmerfriend]

Und nochmal danke

Werde berichten, wie ich es in den Griff bekommen habe.

Viele Grüße

[freetz]

Danke auf jeden Fall. Wenn wir hier nichts mehr mit HASS posten sollen, wäre aber ein Hinweis in diesem Thread ganz oben gut, denn das werden die Leute immer tun. Falls ich also was falsch gemacht habe bzgl Home Assistant Hilfe/Howto, ich kann's zukünftig sein lassen.

Wie gesagt, ich bin kein Moderator, und mir ist es ehrlich egal, was hier diskutiert wird. Ich bin allerdings FHEM'ler und kein HA User, von daher kann ich bei HA-Fragen nicht wirklich helfen. Wenn Du Dir das entsprechende GitHub-Issue anschaust, siehst Du, dass es zwei Jahre gedauert hat, bis ich die Autodiscovery umgesetzt habe, dann kannst Du Dir ein Bild machen, wie weit mein HA-Wissen geht. Und davon ab freue ich mich natürlich, wenn der Support hier keine One-Man-Show ist und Du hier Dein Wissen teilst. Aber wie gesagt, ich entscheide hier nichts, und die Interpretation der Forenregeln obliegt jedem einzelnen User.

Ich wollte hier @bimmerfriend helfen, weil es zur neuen Topic-Struktur und der spezielle Fall "Raumtemperatur senden" noch kein Howto gibt. Bei HASS gibt es kein spezielles BSB-LAN Forum, da gehen Fragen unter und werden dort auch als "zu speziell" empfunden. Dein Wiki ist sicher richtig, aber es behandelt für den Fall "Raumtemperatur Update" nur die HTTP-API

In der Ausgangsfrage des Users war von HA aber keine Rede, sondern es wurde generell nach dem Senden der Raumtemperatur gefragt. Und da ist das Wiki als Grundlage, um zu verstehen, was zu tun ist, der richtige Ort. Es ist ja wegen Raumeinfluss, Zeitintervall etc. nicht damit getan, einen richtigen Befehl abzusetzen. Zu speziellen MQTT-Thematiken gibt es im Übrigen genauso wenig ein HowTo wie zur JSON-Schnittstelle, denn die Strukturen zum Setzen und Abfragen von Parametern sind ja grundsätzlich im Handbuch erklärt. Wenn ich weiß, was zu tun ist, um einen Parameter zu setzen, egal ob über HTTP, MQTT oder JSON, dann ist es relativ egal, um welchen Parameter es geht. Und wie gesagt, das, was man heizungstechnisch wissen muss, um es umzusetzen, steht im alles Wiki.

Das war's jetzt von meiner Seite, Du kannst ihm hier von mir aus gerne weiterhelfen, für mich ist dieser Strang aber hier zu Ende.

[bimmerfriend]

Und nun ein Update... sozusagen das Update vom Update.

Ich habe von 4.0.53 auf 4.2.58 "upgedated". Lief eher holperig, aber nach ein paar kleineren Lern- und Erinnerungskurven hat es dann funktioniert. Mittlerweile sollten die Einstellungen auch wieder passen, ich lasse es erst einmal über Nacht laufen.

Getestet habe ich die Raumtemperatur schon einmal - läuft !

Mir ist noch nicht ganz klar, was die Änderungen beim MQTT Discovery bedeuten, aber da denke ich heute nicht mehr drüber nach. Un dann wäre da noch TWW Push, da muss ich auch noch etwas lesen. Es wird halt nicht langweilig...

Viele Grüße und gute Nacht!

[thetaphi]

Un dann wäre da noch TWW Push, da muss ich auch noch etwas lesen. Es wird halt nicht langweilig...

Trinkwasser Push ist eigentlich trivial. Einfach eine 1 senden:

Du darfst diesen Dateianhang nicht ansehen.

Das ist bei mir Teil einer Automation, aber man könnte auch einen Button draus machen in der config.yaml. Die Automation läuft  jedes Mal wenn ich das Warmwasser in 1.5 km Entfernung von Zuhause wieder anmache ums sofort Aufzuheizen, damit man warm Duschen kann nach dem Sport. 😜

Interessanterweise geht das bei meiner Brötje, obwohl er bei 3 Sekunden die Warmwassertaste drücken sagt, dass die Funktion gesperrt sei. Ich habe bis heute nicht rausgefunden, welcher Parameter unter den vielen unbekannten Bitfeldern unter Konfiguration das verursacht. 😉

Uwe

[bimmerfriend]

Das hatte ich mir auch gedacht, daß die TWW Push eine Sofort-Erwärmung ist. Ich muss/will nur vorher noch die Parameter verstehen und die Heizung begreifen, bevor ich das programmiere. Sprich: Hinabsteigen in den Doku-Keller von Brötje, denn die Funktion läuft bei mir lokal an der Heizung auch nicht. Momentan umgehe ich das noch mit dem kurzzeitigen Umschalten von TWW Zeitprogramm4 auf TWW 24h - das hat irgendwie einen ähnlichen Effekt.

Aber jetzt steht erst einmal MQTT und Logging an. Das Setzen mit der neuen Methode funktioniert, allerdings laufen meine alten Logging Parameter noch nicht wieder. Sprich alle Sensoren, die ich in der Confi YAML eingestellt habe, bleiben leer bzw. auf den alten Werten. Einstellungen sind jetzt nachgepflegt (auf alten Einstellungen), die waren verloren gegangen. Ich suche weiter...

[thetaphi]

Moin,

Aber jetzt steht erst einmal MQTT und Logging an. Das Setzen mit der neuen Methode funktioniert, allerdings laufen meine alten Logging Parameter noch nicht wieder. Sprich alle Sensoren, die ich in der Confi YAML eingestellt habe, bleiben leer bzw. auf den alten Werten. Einstellungen sind jetzt nachgepflegt (auf alten Einstellungen), die waren verloren gegangen. Ich suche weiter...

Das liegt leider an der geänderten Topic-Struktur. Du musst durch die ganze Config.yaml durchgehen und alle Topics anpassen. Ich hatte oben ja einen Link auf den Github-Issue gegeben, wie man es ohne die Category-IDs hinbekommt.

Das hatte ich mir auch gedacht, daß die TWW Push eine Sofort-Erwärmung ist. Ich muss/will nur vorher noch die Parameter verstehen und die Heizung begreifen, bevor ich das programmiere.

Das ist genau so, egal in welchem Programm der ist, wenn man über 10019 eine 1 sendet, dann macht er einen Push. Man sieht das auch sofort am Status des Trinkwassers (Parameter 8003): Zum Testen einmal auf Reduziertbetrieb schalten und dann Push via Web Interface auf 10019 auslösen, dann wechselt der Status auf "Ladung Nennsollwert, Push" oder so ähnlich. Außerdem geht der "Trinkwassersollwert" (8831) auf den höheren Wert. Wenn er gerade Legionellen macht sieht man das am Trinkwassersollwert auch. Sofern ich mich erinnere (ich hab's nimmer im Kopf), kann man sogar bei "Trinkwasser aus" den Push auslösen. Sobald er aufgeheizt hat, wechselt der Nennsollwert wieder auf den reduzierten Wert. Daher ist das der beste Parameter um zu beobachten was er tun (will).

Warum das mit der Trinkwassertaste 3 Sekunden nicht geht ist mir vollkommen unbekannt und laut Brötje Doku sollte es eigentlich auslösbar sein. Ich befürchte es ist in irgendeiner von den Bitsets ohne Beschriftung bei Konfiguration deaktiviert (warum auch immer). Vielleicht weiß jemand anderes warum programmatischer Push über 10019 geht, aber kein manueller an der Displayeinheit.

Generell ist die Dokumentation wenig hilfreich, teilweise sogar inkorrekt weil man exakt die Dokumentation zu seiner Softwareversion braucht und oftmals die auf polo.brötje.de gelieferten PDFs zu neu/zu alt sind und nicht zum aktuellen Gerät passen. Daher: Vieles muss man ausprobieren und beobachten. Zum Glück ist das Ding ja bei den Statuswerten sehr gesprächig.

[thetaphi]

Huhu,
soeben getestet: Trinkwasser ist komplett aus, Push auf 10019 wechselt dann den Status des TWW nach "93 - Push, Nennsollwert".
Uwe

[bimmerfriend]

Mittlerweile läuft das Meiste wieder. Die MQQT Einstellungen sind soweit wieder glatt gezogen: Die Autodiscovery-Funktion schiebt ja wohl alle Parameter raus, damit kann ich dann das Logging aufräumen und alle Werte aus den BSB-LAN Einstellungen als auch aus der Confi-YAML rausnehmen.

Die Push Thematik habe ich noch nicht weiter eruiert. An der Therme kann ich das auch nicht auslösen, laut Netz und Brötje sei die Funktion nicht unterstützt und wohl nur für andere Hersteller implementiert (da vom OEM Hersteller so entwickelt). Funktion probiere ich heute/am Wochenende mal aus, mir ist noch nicht ganz klar, mit welchen Daten die Funktion parametrisiert wird - Einmal auf Sollwert heizen und dann ist sie automatisch wieder aus? Oder erhalten für eine (einstellbare?) Zeit?Hat Push etwas mit Direktladen zu tun? Ich werde mal forschen...

Ansonsten nochmal ein dickes Danke an Dich, Uwe! Deine Hilfe hat mich echt weitergebracht. Und die eine oder andere Idee hast Du bei mir auch gezündet - Uhrzeit setzen war eine davon. Es ist zwar nicht existentiell, aber da die Brötje immer wieder weggelaufen ist, ein cooles Gimmick


Frohes Schaffen noch!