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

Begonnen von justme1968, 29 November 2014, 19:50:40

Vorheriges Thema - Nächstes Thema

fridi

The WiFi connection works!!!  :)

I had an idea and could not hold off testing it.
The problem was the Fritzbox. On the web page "Safety" the point "Unterstützung für geschützte Anmeldungen von WLAN-Geräten (PMF) aktivieren" had to be disabled. This point raises security by using encoded information for setup and service of WLAN connections. The ESP32 with Arduino WiFi library is the first device I found that did not support these Protected Management Frames.

Thanks a lot for your help!

freetz

True, I had this problem as well with another WiFi application that I built around the ESP32. Must be related to the Adruino/ESP32 libraries, I assume, because my Shellys don't have this problem. Since that was before we added WiFi to BSB-LAN, I never realized that this could be a problem (and I'm surprised no one has raised this so far), but it would probably be good to note this in the manual.
Alle Infos zur Anbindung von Heizungssystemen mit PPS-, LPB- bzw. BSB-Bus ans LAN gibt es hier:
https://github.com/fredlcore/bsb_lan

Alle Infos zum WLAN-Interface "Robotan" für Ambrogio/Stiga/Wolf und baugleiche Rasenmähroboter:
https://github.com/fredlcore/robotan

Schotty

Great! Thanks for that info, I'll have a look at that at my FritzBox an then I'll mention it in the manual.

Btw: Make sure to flash again with "byte useEEPROM=1"!

Once you've connected it to your heating system, please give us feedback about the exact model and type of your heating system and send us the output of /Q.
Thanks
Handbuch zur BSB-LAN Hard- & Software (Anbindung v. Heizungsreglern, u.a. von Brötje & Elco):
https://1coderookie.github.io/BSB-LPB-LAN/

gustav0

Ich hatte Anfang Dezember schonmal hier geschrieben und seit dieser Hilfe läuft das BSB-Lan Board auf dem ESP32 durch und gibt die Daten an meine Homeassistant-Instanz weiter.
Allerdings bisher nur per MQTT und damit nur von einer Busadresse. Ich habe am BSB-Bus aber 2 Geräte: eine ISR-M Steuerung und eine WGB EVO Gastherme. Ich würde jetzt gerne auch die Daten der Gasthmere in meine Homeassistent Instanz kriegen und habe deshalb folgende Fragen:

1. MQTT gibt die Daten immer von der eingestellten Standardadresse weiter und ist somit nicht nutzbar für die Daten der zweiten Adresse, richtig?

Per HTTP-URL-Call kann man die Adresse ja mit ! anhängen - das funktioniert soweit. Da HTTP aber schwer Maschinenlesbar ist wollte ich auf JSON gehen. Ich habe in der Doku, im Forum und auch sonst überall gesucht aber keine Dokumentation gefunden, wie ich bei JSON die gewünschte Adresse mitgeben kann. Ich habe mir den Code angesehen und mir scheint es so, als ob beim JSON verarbeiten das verarbeiten einer mitgegeben Zieladresse vorgesehen ist. So richtig schlau bin ich aber nicht geworden wo die her kommt. Deshalb:

2. Wie kann ich bei einem JSON-Request die Zieladresse für den Bus mitgeben?

Wenn ich das wüsste kännte ich die Homeassistent REST API verwenden um mir die Daten zu holen.

Vielen Dank euch schonmal. Die Übersichten im Homeassistent haben mir schon sehr geholfen mein System ordentlich einzustellen, zumal jetzt noch eine Photovoltaikanlage dazu gekommen ist, die gut mit dem zweiten Wärmeerzeuger Wärmepumpe zusammen arbeiten soll.

Gustav

freetz

Hallo Gustav,

ja, BSB-LAN ist grundsätzlich auf die Abfrage eines Gerätes ausgelegt. Über solche Krücken wie das '!' gibt es dann auch die Möglichkeit, die Abfragen auf andere Geräte "umzubiegen". Da das Parsing bei JSON anders läuft, ist das nicht 1:1 übertragbar, ich kann's aber mal mit auf die ToDo-Liste setzen. Wenn HTTP-Aufrufe keine Option sind, bliebe momentan nur ein zusätzlicher Adapter.

F.
Alle Infos zur Anbindung von Heizungssystemen mit PPS-, LPB- bzw. BSB-Bus ans LAN gibt es hier:
https://github.com/fredlcore/bsb_lan

Alle Infos zum WLAN-Interface "Robotan" für Ambrogio/Stiga/Wolf und baugleiche Rasenmähroboter:
https://github.com/fredlcore/robotan

Schotty

Hi gustav0,

hattest du uns da die Q-Ausgabe schon geschickt?

Zitat von: gustav0 am 11 Dezember 2021, 21:06:02
Log der Prüfung auf neue Parameter kommt per Email genauso wie ein kurzer Mitschnitt einiger Kommunikationspackete zwischen ISR und WGB, welche vom BSB-Lan nicht mit entsprechendem Text dekodiert werden. Oder sollte ich die hier auch mit ins Forum stellen?
Handbuch zur BSB-LAN Hard- & Software (Anbindung v. Heizungsreglern, u.a. von Brötje & Elco):
https://1coderookie.github.io/BSB-LPB-LAN/

gustav0

Zitat von: Schotty am 17 Februar 2022, 18:13:05
Hi gustav0,

hattest du uns da die Q-Ausgabe schon geschickt?

Ja das hatte ich freetz per Mail geschrieben.

loetmeister

Hallo,

beim testen der aktuelle Version ist mir aufgefallen, das der Parameter 1600 nicht mehr als "Trinkwasserbetrieb", sondern als "Betriebsart" angezeigt wird
#define STR1600 STR700_TEXT
Bei meiner BGB EVO 20i wird mit 1600 der Trinkwasserbetrieb geschaltet. Es passt zur Anzeige im Display und 1600 lässt sich auch entsprechend setzen (0, 1).
Habe ich etwas übersehen? :)

Gruß,
Thomas

freetz

Wir sind dazu übergegangen, die Bezeichnungen, die sich aus der Kategorie ergeben, nicht noch einmal mit aufzuführen. Die Logik der 00er Parameter (700, 1000, 1200, 1600 etc.) ist ja jeweils die Betriebsart der Kategorie. Das macht es dann für die Übersetzenden auch noch mal einfacher, weil der Begriff eben nur an einer Stelle übersetzt werden muss.
Alle Infos zur Anbindung von Heizungssystemen mit PPS-, LPB- bzw. BSB-Bus ans LAN gibt es hier:
https://github.com/fredlcore/bsb_lan

Alle Infos zum WLAN-Interface "Robotan" für Ambrogio/Stiga/Wolf und baugleiche Rasenmähroboter:
https://github.com/fredlcore/robotan

johndoe

Mir ist es jetzt zweimal passiert, dass BSB-LAN scheinbar irgendwie hängt. Webinterface ist ganz normal erreichbar, aber es kommt per MQTT nichts mehr beim Empfänger an.
Mit /N soll man ja neustarten können, da steht dann auch "restarting Arduino", aber das behebt das Problem nicht - während nach kurzem Trennen der Stromzufuhr die Werte wieder korrekt gesendet werden. Laut Handbuch hätte man die Restart-Funktionalität in der config aktivieren müssen (was ich damals nicht habe). Führt das zum beobachteten Verhalten, das er eigentlich gar nicht neu startet?
Muss mein NodeMCU also noch einmal an den Computer und neu geflasht werden, weil ich ihn sonst nicht aus der Ferne neustarten kann?

freetz

Dass man in der Config "#define RESET" aktivieren muss, ist nicht mehr aktuell, ich weiß aber nicht, wie lange das schon geändert ist. Wenn aber die Neustart-Meldung kommt, dann ist es auch aktiv. Ob der Neustart geklappt hat, sieht man auf der Einstellungs-Seite: Ist unten bei "Uptime" ein fünfstelliger Wert oder kleiner, dann hat der Neustart funktioniert. Ist er (deutlich) größer, dann hat es nicht geklappt.
Alle Infos zur Anbindung von Heizungssystemen mit PPS-, LPB- bzw. BSB-Bus ans LAN gibt es hier:
https://github.com/fredlcore/bsb_lan

Alle Infos zum WLAN-Interface "Robotan" für Ambrogio/Stiga/Wolf und baugleiche Rasenmähroboter:
https://github.com/fredlcore/robotan

loetmeister

Zitat von: freetz am 17 Februar 2022, 22:19:54
Wir sind dazu übergegangen, die Bezeichnungen, die sich aus der Kategorie ergeben, nicht noch einmal mit aufzuführen. Die Logik der 00er Parameter (700, 1000, 1200, 1600 etc.) ist ja jeweils die Betriebsart der Kategorie. Das macht es dann für die Übersetzenden auch noch mal einfacher, weil der Begriff eben nur an einer Stelle übersetzt werden muss.
Ok, verstehe. Im web interface ist das gut, da solle man "1600 Trinkwasser - Betriebsart" sehen (Ich sehe es wie im Anhang, aber denke das liegt am ATMega... ein paar Ausgaben sind da "kaputt"/durcheinander... als ob da pointer überlagern... :)
Bei der JSON Abfrage steht aber nur der Name "Betriebsart", nicht mehr die Bez. der Kategorie "Trinkwasser". Da ist es nicht mehr so eindeutig - natürlich über den Parameter.... aber ich nutze "name" in FEHM zur Darstellung der Werte, da war "Trinkwasserbetrieb" schöner. (ich kanns natürlich wieder ändern  ;))

Gruß,
Thomas

johndoe

Hallo zusammen,
gibt es eine Möglichkeit, das Senden der Parameter per MQTT seitens BSB-LAN irgendwie zu überwachen/debuggen?

Ich hatte gestern zwei Mal die Situation, dass beim Subscriber nichts mehr ankam für mehrere Stunden.

BSB-LAN/status meldet online, aber das hat ja auch ein retain flag, die anderen Parameter wurden auch beim aktiven Zuhören nicht empfangen.
Ich habe nacheinander alles neu gestartet, BSB-LAN, Router, Broker, Subscriber, immer noch tot. Irgendwann ging es dann plötzlich wieder, als wäre nichts gewesen, ich kann das aber bisher nicht eingrenzen. An keiner der Stellen konnte ich eine Auffälligkeit feststellen, sah alles wie gewohnt aus.
Kann man irgendwie seitens BSB-LAN schauen, ob da wirklich etwas gesendet wird, um irgendwie den Fehler einzugrenzen?

Interessant wäre auch umgekehrt ein Monitor bzg. empfangener Befehle. Vorgestern wurde nämlich bei mir einige Male ein Trinkwasserpush ausgelöst, für den ich keinen Sendebefehl finden kann. Seit ich testweise Schreibzugriff deaktiviert habe, passiert das nicht mehr, das hat also scheinbar nicht die Heizung selbst ausgelöst.

freetz

Für MQTT gibt es kein Debugging per se. Da ich MQTT selber nicht nutze und die entsprechenden Funktionen von mehrern Personen geschrieben wurden, kann ich da auch nur begrenzt weiterhelfen. Wenn Du selber in include/mqtt_handler.h in den entsprechenden Funktionen Debug-Ausgaben auf der seriellen Konsole hinzufügen, vielleicht hilft das weiter? Ansonsten können wir nur dann genauer schauen, wenn ein Problem auf konkrete Weise reproduzierbar ist...
Alle Infos zur Anbindung von Heizungssystemen mit PPS-, LPB- bzw. BSB-Bus ans LAN gibt es hier:
https://github.com/fredlcore/bsb_lan

Alle Infos zum WLAN-Interface "Robotan" für Ambrogio/Stiga/Wolf und baugleiche Rasenmähroboter:
https://github.com/fredlcore/robotan

Scherheinz

@Johndoe: benutzt du denn FHEM?

Dann könntest du zeitgesteuert was an den Arduino schicken der dir dann darauf antwortet und das ganze in einer Logfile speichern. Halt so eine Art "Lifebit", dann siehst genau wann und in welcher Richtung die letzte Kommunikation war.

Gruß