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

[johndoe]

@Scherheinz: Nicht mehr, bin vor längerer Zeit gewechselt auf Home Assistant.
Wann die Kommunikation abriss, sieht man auch ganz gut in den Sensoren zu den verschiedenen Parametern, die dann zu einer völlig geraden Linie wechseln und mir auch sagen wann sie das letzte Update erfahren haben.
Zwar wird nicht für jeden Parameter mit jedem Intervall (bei mir 30 sec.) ein neuer Wert geschickt, aber es kommt umgekehrt auch kaum vor, dass sich keiner der Werte (Außentemp., Kesseltemp, Wassertemp, etc.) geändert hat.
Mit ein bisschen Bastelei könnte ich vermutlich auch auf der Ebene ein Lifebit erzeugen, inklusive Benachrichtigung wenn keine Updates mehr ankommen.
Aber mir geht es weniger darum, zu sehen wann die letzte Kommunikation war, als zu verstehen woran dann in der aktuellen Situation die Kommunikation hapert (->Fehlerquelle). Bisher konnte ich da an keiner der Stationen einen Verursacher finden in den jeweiligen Situationen, und umgekehrt auch nicht eingrenzen wodurch verursacht es irgendwann wieder läuft.
Nicht reproduzierbare Fehler sind halt immer das Schlimmste

Ich habe auch noch ein zweites Mysterium, das ich versuche einzugrenzen, siehe Anhang.
Das rote ist die Trinkwassertemperatur, das blaue der Sollwert. Normalerweise wird bei 4 Grad Unterschreitung wieder auf den Sollwert erhitzt, in dem Fall den Reduziertsollwert (44 Grad)
Dieser Spike ist offensichtlich ein Trinkwasserpush auf den Nennsollwert (52 Grad). Den habe ich aber nicht ausgelöst (zu der Zeit geschlafen), im Smart Home gibt es dafür keine Automatisierung, und die Heizung macht das höchstens bei doppelter Unterschreitung des Sollwertes (also 36 Grad).
In bisherigen Tests ist dieses Verhalten ausgeblieben, so lange ich BSB-LAN den Schreibzugriff entzogen habe, was dafür spricht dass der Trinkwasserpush von außen getriggert wurde. Wie es aber dazu kommt, konnte ich auch noch nicht ergründen.
Auch da wäre es hilfreich, wenn man irgendwie sehen könnte welche Befehle (in meinem Fall kommt höchstens MQTT in Frage) BSB-Lan von außen empfängt.

[Schotty]

@johndoe:
Nutzt du denn die MQTT-funktion, bei der du die 'Loggingparameter' bei BSB-LAN einstellst und mit einem festen Intervall sendest, oder nutzt du die neuere Funktion, bei der du brokerseitig die Parameter bei BSB-LAN 'abrufst'?
Bzgl Letzterer gibt's im Handbuch ein Beispiel von User "tiger42" bzgl MQTT-Einbindung in HomeAssistant, vielleicht sonst damit mal probieren..?
https://1coderookie.github.io/BSB-LPB-LAN/kap08.html#811-home-assistant
Ich kenne mich mit HA nicht aus, aber ich könnte mir vorstellen, dass du sonst bei HA evtl Fehlereinträge finden könntest, falls ein Abruf bei BSB-LAN scheitert..

[Schotty]

Dieser Spike ist offensichtlich ein Trinkwasserpush auf den Nennsollwert (52 Grad). Den habe ich aber nicht ausgelöst (zu der Zeit geschlafen), im Smart Home gibt es dafür keine Automatisierung, und die Heizung macht das höchstens bei doppelter Unterschreitung des Sollwertes (also 36 Grad).

Was ist bei dir bei Parameter 5070 "TWW Automatischer Push" eingestellt? EIN oder AUS?
Falls EIN: "Fällt die Trinkwassertemperatur um mehr als zwei Schaltdifferenzen (Bedienzeile 5024) unter den Reduziertsollwert (Bedienzeile 1612), wird einmalig wieder auf den Trinkwassernennsollwert (Bedienzeile 1610) geladen." - das würde ich erstmal überprüfen, also auch auch 5024 in dem Zusammenhang.
EDIT: Nochmal deutlicher: "und die Heizung macht das höchstens bei doppelter Unterschreitung des Sollwertes (also 36 Grad)" -> nein, die Hzg macht das automatisch bei 'doppelter Unterschreitung' zweier Schaltdifferenzen (5024), das ist ein großer Unterschied..

Wenn es wirklich ein Push wäre, dann müsste das eigtl auch als INF über den Bus gehen (iirc) - versuch doch sonst mal, ne microSD-Karte einzulegen und "alle Bustelegramme" zu loggen, vielleicht kannst du dort dann was sehen.

[johndoe]

5070 ist an, ja. Der hat auch gar keinen SET-Knopf bei mir, sprich kann über BSB-LAN gar nicht geändert werden.
Deine Beschreibung ist völlig richtig und ist mir so auch geläufig, nur in der Tat von mir schlecht beschrieben.
Die Schaltdifferenz ist bei mir 4 Grad. Deshalb sieht man ja auch, dass er normalerweise bei ca. 40 Grad wieder auf 44 heizt, und damit eben höchstens bei 36 Grad (zwei Mal 4 Grad unterschritten) den Push auslösen sollte. Dass das inhaltlich ein Push ist, sieht man daran dass der Sollwert sinkt, sobald die 52 Grad erreicht sind, genauso das macht ja den Push aus.
Daher verwundert es mich ja auch, dass diese Spikes scheinbar nicht bei völlig willkürlichen Werten auftreten, sondern scheinbar bei diesen 4-Grad-Thresholds (aber eben auch nur selten, ohne Regel).
Im Anhang noch ein Beispiel von vorhin, da scheinbar bei 48 Grad (Nennsollwert minus eine Schaltdifferenz), für reinen Zufall liegt das bisher immerzu sehr an diesen Grenzen.
Wie gesagt, bei Deaktivierung von Schreibzugriff für BSB-LAN gab es davon über 24 Stunden keinen einzigen Fall, gestern abend wieder aktiviert und schon gibt es wieder diese Fällt. Werde in den nächsten Tagen aber weiter testen ob es da einen Kausalzusammenhang gibt, und das nicht nur Zufall war.

Ich nutze größtenteils MQTT mit Eintrag der Parameter in den Einstellungen unter Logging, die übertragen werden sollen, mit fester Frequenz von 30 Sekunden.
Der TW-Push (1603) steht in BSB-LAN immer auf Aus, selbst wenn ich ihn einschalte, daher lasse ich da keinen Status übertragen, sondern schicke das höchstens manuell aus HA mit 1603=1, was dann bei Bedarf auch einen Push auslöst (z.B. Bad nehmen zu ungewöhnlicher Zeit).
Das Beispiel von tiger42 ist mir bekannt und hat für mich u.a. auch als Orientierung gedient, von REST/JSON habe ich aber nach den ersten Anfängen wieder Abstand genommen, da es mir das zu kompliziert gemacht hat und ich generell keinen Bedarf sehe, wenn das mit dem bereits vorhandenen MQTT einwandfrei läuft. Ich vermute das meinst du mit "neuere Funktion"

Ich nutze den NodeMCU, weil ich eigentlich gar keinen Bedarf an Logging auf dem Gerät habe. Mit diesen Themen hatte ich im Vorfeld natürlich nicht gerechnet

[Schotty]

5070 ist an, ja. Der hat auch gar keinen SET-Knopf bei mir, sprich kann über BSB-LAN gar nicht geändert werden.

Wenn du den Schreibzugriff bei BSB-LAN deaktiviert hast, dann kannst du den natürlich auch nicht setzen. So oder so kannst du ihn aber ja auf jeden Fall an der Bedieneinheit ausschalten und dann mal beobachten.

Ich nutze größtenteils MQTT mit Eintrag der Parameter in den Einstellungen unter Logging, die übertragen werden sollen, mit fester Frequenz von 30 Sekunden.

Das ist die 'alte' Funktion, s. Beschreibung im ersten Teil des MQTT-Kap. im Handbuch.

Das Beispiel von tiger42 ist mir bekannt und hat für mich u.a. auch als Orientierung gedient, von REST/JSON habe ich aber nach den ersten Anfängen wieder Abstand genommen, da es mir das zu kompliziert gemacht hat und ich generell keinen Bedarf sehe, wenn das mit dem bereits vorhandenen MQTT einwandfrei läuft. Ich vermute das meinst du mit "neuere Funktion"

Mit 'neuer' MQTT-Funktion meine ich das MQTT-Einbindungsbeispiel von tiger42, siehe auch unterer Teil im entspr Kap im Handbuch (dort, wo die Befehlssyntax für Abfragen&Senden beschrieben ist; der Abschnitt fängt an mit dem Satz "Neben dem (brokerseitigen) reinen Empfangen ist es auch möglich, via MQTT vom Broker aus sowohl Abfragen als auch Steuerbefehle (URL-Befehle /S und /I) an BSB-LAN zu senden.").
REST/JSON meinte ich nicht, da du ja MQTT nutzt

[freetz]

...ich vermute, er meint mqtt_mode 2 oder 3...

[Schotty]

Ich nutze den NodeMCU, weil ich eigentlich gar keinen Bedarf an Logging auf dem Gerät habe. Mit diesen Themen hatte ich im Vorfeld natürlich nicht gerechnet

..also keine Möglichkeit, die Bustelegramme auf Karte zu loggen, ok.
Diese Probleme/'Themen' müssen imho aber eben nicht zwangsläufig in BSB-LAN begründet sein, denn bisher bist du der einzige User, der diesbzgl etwas berichtet. Wäre das MQTT- oder Pushproblem ein 'gängiges' BSB-LAN-Problem, hätte m.M.n. ganz sicher schon früher jemand darauf hingewiesen..

[freetz]

Naja, da wir vor ein paar Wochen oder so an dem Code dran waren (https://github.com/fredlcore/BSB-LAN/issues/409), kann es schon sein, dass sich da was verhakt hat und die User mit älterer Software das Problem deswegen nicht haben, insofern würde ich das jetzt noch nicht abhaken; ich habe gerade noch mal in den Code geschaut: Also beim Setzen von Parametern über MQTT in der Form

Code Auswählen Erweitern

set <mqtt2Server> publish <MQTTTopicPrefix> S700=1
wird auf dem SerMo eine entsprechende Nachricht ausgegeben, beginnend mit

Code Auswählen Erweitern

##MQTT#############################
mqtt-message arrived [topic]
Kannst Du das bitte einmal prüfen?

Dann suche mal bitte in der BSB_LAN.ino bei etwa Zeile 6531 nach dieser Zeile:

Code Auswählen Erweitern

      if ((((millis() - lastMQTTTime >= (log_interval * 1000)) && log_interval > 0) || log_now > 0) && numLogValues > 0) {
und füge direkt darunter diese Zeilen ein:

Code Auswählen Erweitern

printlnToDebug(millis());
printlnToDebug(lastMQTTTime);
Die erste Zeile müsste bei einem Log-Intervall von 30 Sekunden jedes Mal ca. 30000 größer sein, als die zweite Zeile. Und diese Ausgabe müsste dann auch alle 30 Sekunden im SerMo zu sehen sein.

Interessant ist jetzt zu schauen:
1. Wenn die Parameter nicht mehr übertragen werden, kommen dann trotzdem noch die beiden Zeitangaben im 30-Sekunden-Intervall und ist der erste Wert weiterhin ca. 30000 höher als der zweite?
2. Wenn die Parameter nicht mehr übertragen werden und dann wieder übertragen werden, wie sieht die erste Ausgabe der beiden Werte aus?

Vielleicht kommen wir der Sache da entsprechend näher.

[johndoe]

Mit 'neuer' MQTT-Funktion meine ich das MQTT-Einbindungsbeispiel von tiger42, siehe auch unterer Teil im entspr Kap im Handbuch (dort, wo die Befehlssyntax für Abfragen&Senden beschrieben ist; der Abschnitt fängt an mit dem Satz "Neben dem (brokerseitigen) reinen Empfangen ist es auch möglich, via MQTT vom Broker aus sowohl Abfragen als auch Steuerbefehle (URL-Befehle /S und /I) an BSB-LAN zu senden.").
REST/JSON meinte ich nicht, da du ja MQTT nutzt

Das steht aber nicht in dem tiger42-HA-Beispiel in Kapitel 8, sondern bei MQTT in Kapitel 5, hatte schon an der Browser-Suchfunktion gezweifelt
ÄNDERN von Werten mache ich genau über ein mqtt.publish an das Topic BSB-LAN mit /SXXXX=1, da kenne ich gar keine andere Lösung und das funktioniert generell auch einwandfrei. Nur für das Auslesen benutze ich das Logging-Publish von BSB-LAN. Über /I eine Abfrage zu senden habe ich nicht probiert da ich MQTT nur in die andere Richtung kannte und das erstmal unintuiv fand bzw. auch schwerer entsprechend aufzusetzen und zu verstehen.

Wenn du den Schreibzugriff bei BSB-LAN deaktiviert hast, dann kannst du den natürlich auch nicht setzen. So oder so kannst du ihn aber ja auf jeden Fall an der Bedieneinheit ausschalten und dann mal beobachten.

Schon klar Siehe Anhang, da ist keine Änderungsoption, aber ja, ich könnte auch mal an der Heizung danach suchen (habe da bisher nur die Endanwender-Parameter in der Anzeige).

Diese Probleme/'Themen' müssen imho aber eben nicht zwangsläufig in BSB-LAN begründet sein, denn bisher bist du der einzige User, der diesbzgl etwas berichtet. Wäre das MQTT- oder Pushproblem ein 'gängiges' BSB-LAN-Problem, hätte m.M.n. ganz sicher schon früher jemand darauf hingewiesen..

Völlig klar, ich sage auch gar nicht das BSB-LAN einen Bug hat, darum suche ich ja auch bei der Heizung oder Home Assistant, ich versuche ja einzugrenzen was die Ursache ist.

Ich nutze aktuell Version Version 2.1.0-20211231181308, also zumindest relativ aktuell.

Ich habe gesehen, dass ich dem MQTT-Befehl für den Trinkwasserpush ein retain flag mitgegeben hatte (Gedanke war: Wenn BSB-LAN im Moment des Knopfdrucks nicht empfängt, soll die Nachricht nicht verloren gehen).
Das habe ich jetzt mal rausgenommen. Kann da ggf. diese Nachricht dauerhaft vorgelegen haben und daher ab und zu den Push erneut ausgelöst haben? Dann hätte ich das aber eher fortlaufend erwartet, und nicht völlig unregelmäßig (ohne das der Befehl dazwischen ausgelöst wurde).
Im nächsten Schritt würde ich sonst auch mal die MQTT-Befehle für 1603 komplett aus HA entfernen, so dass es den gar nicht senden kann. Stück für Stück Ausschluss von Ursachen...

ich habe gerade noch mal in den Code geschaut: Also beim Setzen von Parametern über MQTT in der Form...
wird auf dem SerMo eine entsprechende Nachricht ausgegeben, beginnend mit...

Das überfordert mich technisch etwas
Hieße ich muss den NodeMCU an den Computer anschließen und darüber irgendwie Log-Nachrichten mitlaufen lassen?

[freetz]

Jein, Du kannst auch Debug auf Telnet setzen und Dich dann über Telnet mit BSB-LAN verbinden und siehst da dann den Log-Output. Aber ohne Logs werden wir dem Problem nicht auf die Spur kommen...

[Schotty]

Das steht aber nicht in dem tiger42-HA-Beispiel in Kapitel 8, sondern bei MQTT in Kapitel 5, hatte schon an der Browser-Suchfunktion gezweifelt

Sorry, my bad - du hast völlig recht, tiger42 scheint auch nur 'passiv' auf die von BSB-LAN gesendeten Werte zu warten (das hatte ich irgendwie anders im Hinterkopf)..

Schon klar Siehe Anhang, da ist keine Änderungsoption, aber ja, ich könnte auch mal an der Heizung danach suchen (habe da bisher nur die Endanwender-Parameter in der Anzeige).

Hab gerade mal kurz geguckt: Also zumindest bei meinen RVS-Reglern liegt der in der OEM-Ebene und ist per default auch auf EIN (zum Ändern müsstest du dann bei BSB-LAN Schreibzugriff auf 'komplett' setzen, dann sollte es möglich sein ), vermutlich einfach deshalb, damit bei nem Vollbad schnell wieder auf Solltemp aufgeheizt wird.

Völlig klar, ich sage auch gar nicht das BSB-LAN einen Bug hat, darum suche ich ja auch bei der Heizung oder Home Assistant, ich versuche ja einzugrenzen was die Ursache ist.

Naja, aber (habe gerade nochmal deine vorherigen Beiträge überflogen) wenn das Webinterface erreichbar ist, aber BSB-LAN nix mehr via MQTT sendet, kann das natürlich doch irgendwie so sein - keine Ahnung

Ich nutze aktuell Version Version 2.1.0-20211231181308, also zumindest relativ aktuell.

Dann ruhig erstmal updaten, evtl hat sich da ja irgendwas getan (s. freetz' Beitrag bzgl Issue).

Ich habe gesehen, dass ich dem MQTT-Befehl für den Trinkwasserpush ein retain flag mitgegeben hatte (Gedanke war: Wenn BSB-LAN im Moment des Knopfdrucks nicht empfängt, soll die Nachricht nicht verloren gehen).
Das habe ich jetzt mal rausgenommen. Kann da ggf. diese Nachricht dauerhaft vorgelegen haben und daher ab und zu den Push erneut ausgelöst haben? Dann hätte ich das aber eher fortlaufend erwartet, und nicht völlig unregelmäßig (ohne das der Befehl dazwischen ausgelöst wurde).

Da kenne ich mich leider nicht mit MQTT aus, um darauf antworten zu können
Vielleicht weiß ja @Luposoft was diesbzgl?

Im nächsten Schritt würde ich sonst auch mal die MQTT-Befehle für 1603 komplett aus HA entfernen, so dass es den gar nicht senden kann. Stück für Stück Ausschluss von Ursachen...

Macht Sinn

Viel Erfolg!

[fridi]

Nachdem die Joy-It ESP32 NodeMCU auf der Adapterplatine steckt und alles programmiert, konfiguriert und an der Brötje-Heizung angeschlossen ist, hätte ich euch gerne die Parameterliste nach <IP>/Q zukommen lassen. Allerdings reagiert der ESP32 mit einem veritablen Absturz:

Nach Eingabe der URL mit dem Befehl /Q sieht es erst gut aus. Er erkennt zwei Geräte 0 und 10 (manchmal auch ein drittes mit der Nr 6), will dann das Gerät mit der Nr 0 testen... und wenige Sekunden später erfolgt ein Neustart.

Einen Auszug aus dem Mitschnitt des seriellen Monitors findet ihr im Anhang.
Ich habe verschiedenste Einstellungen ausprobiert, das Ergebnis war immer dasselbe.

Alles andere funktionierte bisher einwandfrei.

[freetz]

Ja, da ist ein Speicherüberlauf-Fehler, den ich absurderweise bei mir nicht reproduzieren kann.

Kannst Du bitte in BSB_LAN.ino in etwa in Zeile 5347 folgende Zeilen

Code Auswählen Erweitern


           for (uint16_t q = 0; q < sizeof(proglist4q)/sizeof(int); q++) {
             int prognr = 0;
#if defined(__AVR__)
             prognr = pgm_read_word_far(pgm_get_far_address(proglist4q) + (q) * sizeof(proglist4q[0]));
#else
             prognr = proglist4q[q];
#endif
             query_program_and_print_result(prognr, PSTR("\r\n"), NULL);
           }


durch folgende ersetzen:

Code Auswählen Erweitern


           for (uint16_t q = 0; q < 17; q++) {
Serial.println(q);
Serial.println(sizeof(progslist4q);
Serial.println(sizeof(int);
             int prognr = 0;
#if defined(__AVR__)
             prognr = pgm_read_word_far(pgm_get_far_address(proglist4q) + (q) * sizeof(proglist4q[0]));
#else
             prognr = proglist4q[q];
#endif
Serial.println(prognr);
             query_program_and_print_result(prognr, PSTR("\r\n"), NULL);
           }



und dann einmal /Q ausführen und loggen? Danke!

[fridi]

Wie gewünscht habe ich BSB_LAN.ino geändert und im seriellen Monitor das Ergebnis von /Q geloggt. (Siehe Anhang).

Um einen Speicherdefekt des aktuellen ESP32 auszuschließen, habe ich es auch einmal mit einem zweiten ESP32 ausprobiert. Auch der schmiert bei /Q ab.

[freetz]

Danke für den Log, das hilft schon mal insofern weiter, dass der Fehler mir zumindest nicht erklärlich ist; vielleicht kann jemand anderes mit Programmierkenntnissen da ja noch mal mit draufschauen:
Im Log sieht man vor der jeweiligen Ausgabe der Telegramme vier Zahlen, die erste davon ist der Index für proglist4q, was in der BSB_LAN_defs.h etwa in Zeile 846 definiert ist.
Man sieht direkt vor dem Crash, dass auf Parameter 6236 in der vierten Zeile der Zahlen der Parameter 6237 ermittelt wird. Dabei gibt es den Parameter 6237 gar nicht!
Beim Mega würde ich an einen Speicherüberlauf etc. denken, aber mitten in einer Schleife, die noch nicht mal an einer Zweierpotenz-Grenze liegt, ist mir das nicht erklärlich, zumal quasi der identische Code bei params4q ohne Probleme durchläuft.

Bei den anderen Usern, wo das Problem auftrat, half es, proglist4q um einen Eintrag zu kürzen, anscheinend egal welchen. Das würde das plötzliche Auftreten des Fehlers erklären, denn ich hatte hier vor Kurzem einen Parameter hinzugefügt. Aber warum dieses Problem dann jetzt auftritt, und dann auch noch bei manchen und nicht allen Usern, ist mir wirklich nicht erklärbar. Aber wie gesagt, vielleicht hat ja noch jemand anderes eine Idee?