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

[guck123]

Funktioniert jetzt. Danke nochmal!

[freetz]

Fein

[FunkOdyssey]

Ich sehe heute ja erst, dass es eine MQTT-Option für BSB gibt. Super. Danke.
Ich habe große Lust, das morgen mal auszuprobieren.

Aber ein paar Fragen:
- Kann man auch schreiben? (publisherSet)
- Kann man bei log_parameters auch Bereiche angeben? (1234-2345)?

[freetz]

Leider zweimal nein...

[FunkOdyssey]

Gibt es eine Chance, dass der Schreibzugriff wie bspw. die INF-Nachrichten für die Raumtemperatur.
Oder ggfls. für TWW-Push & Co. (S701, S1601, S710, S712)?

[Schotty]

Ich habe mal ein komplettes Beispiel für das Handbuch zusammengestellt.

Danke @mifh! Dann werde ich das erstmal so übernehmen.

[mifh]

Also ich denke, in die jetzige Konstruktion  noch die MQTT Empfangsseite zusätzlich reinbauen, könnte ein wenig fummelig werden. MQTT publish kann man ziemlich einfach implementieren, für den MQTT subscribe braucht man schon mehr (u.a. müsste man die MQTT Connection ständig offen halten, womit freetz ja Probleme hatte). Ob man das zusammen mit dem vorhandenen Webserver mit den recht beschränkten Arduino-Ressourcen stabil hinkriegt?
Außerdem gibt es zum Übertragen von Kommandos und Vorgabewerten  an BSB-LAN ja das http-Interface. Ist sicher etwas fummeliger in der Parameterierung als schlichtes MQTT, aber es läuft doch am Ende.

Ich fände es toll, wenn man die per publish zu übertragenden Parameter nicht im Code angeben müsste, sondern geeignet parametrieren könnte. Aber da fehlt ja wohl irgendwie die Infrastruktur für, um das einfach zu implementieren (auf dem esp32 gibt es da einen Key/Value store, den man einfach anbinden kann).

[FunkOdyssey]

Ich habe mir so etwas schon gedacht. Und ist auch nachvollziehbar.
Dann behalte ich halt ein abgestecktes HTTPMOD notfalls.

[freetz]

Die Log und MQTT Parameter lassen sich zur Laufzeit über den Parameter /L= parametrieren.

[FunkOdyssey]

Nach 12 Monaten des "Nicht-Updatens" habe ich nun auch wieder die neueste Code-Basis aktiv.
Das hat mich ein paar Stunden gekostet, da ich wieder einmal (wie damals auch) mit einem "query failed"-Fehler begrüßt wurde. Ich habe scheinbar irgendwo einen Wackelkontakt. Adapter vom Arduino getrennt und alles neu zusammengesteckt. Nun läuft es jedenfalls.

Ich bin begeistert von der MQTT-Schnittstelle. Mit dem MQTT2-Server lief alles innerhalb weniger Minuten. Am längsten hat das Anpassen der Readings-Name gedauert, da ich die Geräte im Hintergrund einfach austauschen will. Bin mal gespannt, ob das funktioniert.

Der schöne Vorteil: Ich muss mir aktuell keine Gedanken über RegEx machen.

Vielen vielen Dank.

Aber: Ich vermisse etwas. Es werden scheinbar nur die ersten Werte angezeigt und der Langtext (ENUM-Werte?) fehlt:

Beispiele:

• 6801 Historie 01 Fehlercode: 110 (MQTT)
• 6801 Historie 01 Fehlercode: 110 - STB Störabschaltung (HTTPMOD)

• Betriebsart: 1 (MQTT)
• Betriebsart: 1 - Automatik (HTTPMOD)

• Brennerstufe_1: 0 (MQTT)
• Brennerstufe_1: 0 - Aus (HTTPMOD)

Ich fand die alten Information sehr spannend und auch wichtig, da diese Texte anschließend in readingsGroups oder readingsHistory angezeigt wurden.

[freetz]

Ja, das ist ein Problem, weil andere Leute die Werte rein numerisch haben woll(te)n. Ich muss mal schauen, ob ich das "Abhacken" bei den ENUMs übergehen kann, vielleicht wäre das eine Lösung...

[FunkOdyssey]

Ich gehöre ja auch zu denen, die numerische Werte in Temperatur und Drehzahlenfeldern haben wollten.
Aber alles andere sind ja Statusfelder mit Strings. Man müsste ja sonst ein Großteil der Mappings aus der BSB_lan_defs.h in FHEM nachbauen (z.B. Kesselstatus & Co.), wenn man wissen will, das 122 für die Raumtemp'begrenzung steht.

Bitte bitte bitte. Lasst uns das besprechen. Ich will niemanden vor dem Kopf stoßen und seine Konfiguration inkompatibel machen. Aber ich kann mir vorstellen, dass diese Langtexte sicherlich für alle von Interesse sind.

[Schotty]

Mit dem MQTT2-Server lief alles innerhalb weniger Minuten.

mifh hatte ja hier https://forum.fhem.de/index.php/topic,29762.msg899597.html#msg899597 eine Beispielkonfig fürs handbuch gepostet, allerdings noch nicht mir dem MQTT2-Server. Könntest du evtl gucken, ob bzw wie das Beispiel anzupassen ist, wenn man den MQTT2-Server benutzen möchte (wobei ich persönlich jetzt gar nicht weiß, wo die Unterschiede sind - habe mich da noch nicht weiter mit auseinander gesetzt). Das wäre klasse! Danke

[FunkOdyssey]

Ich kann dir morgen ein paar Zeilen dazu schreiben.
Aber mit dem MQTT2-Server hast du "autocreate". Ich habe eigentlich gar nicht selbstständig gemacht. Das macht alles FHEM. Die Readings kamen von alleine.

[TequilaTom]

Bitte mal /Q aufrufen und die Ausgabe posten...

Hallo Freetz,

ich habe deine PCB heute in Betrieb genommen, läuft ohne irgendein Problem sofort los.

Somit könntet Ihr im Kapitel 3.1.1 im Handbuch folgende Heizung übernehmen:
Brötje BSK 15 [LMS14] (Gasbrenner)
Brötje BSK 20 [LMS14] (Gasbrenner)

Hier meine Ausgabe von meiner Brötje BSK20 mit dem /Q.

Gerätefamilie: 162
Gerätevariante: 11
Start Test...

857
857 Heizkreis 1 - Estrich Tage erfüllt: error 7 (parameter not supported)
DC 86 00 0B 06 3D 21 0B 43 75 2C
DC 80 06 0D 07 21 3D 0B 43 00 00 9D C9
1157
1157 Heizkreis 2 - Estrich Tag erfüllt: error 7 (parameter not supported)
DC 86 00 0B 06 3D 22 0B 43 2C 7C
DC 80 06 0D 07 22 3D 0B 43 00 00 53 29
Test Ende.

6220 Konfiguration - Software-Version: 3.5       
6221 Konfiguration - Entwicklungs-Index: error 7 (parameter not supported)    
6222 Konfiguration - Gerätebetriebsstunden: 40302 h       
6223 Konfiguration - Bisher unbekannte Geräteabfrage: 000014 - unknown type    
6224 Konfiguration - Geräte-Identifikation: LMS14.002A100       
6225 Konfiguration - Gerätefamilie: 162       
6226 Konfiguration - Gerätevariante: 11       
6227 Konfiguration - Objektverzeichnis-Version: 1.4       
6228 Konfiguration - Hersteller-ID (letzten vier Bytes): 00A2000B000E07EC0BC3 - unknown type

Gruß Tom