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

[the.hein]

Hallo Frederik, Hallo Leute,

Dank der super Hilfe von Frederik läuft mein BSB-Lan Modul an der MHG Procon Gastherme wundderbar. Über den Browser ist auch eine Steuerung möglich.

Jetzt geht es an die Einbindung in HomeAssist. Ich habe zwar eine BSB-Lan Integration gefunden, die liefert mir aber nur den Wert des AussenTempSensors und die Einstellung der Raumtemperatur. Sonst nichts.

Gibt es eine andere Integration (die ich nur nicht finde) oder wie binde ich das BSBLAN Modul in HomeAssist ein?

Gruß, Uwe

[freetz]

Die BSB-LAN-Integration von HomeAssistant hat mal ein User geschrieben, aber die dürfte eigentlich nicht mehr mit den neueren Versionen funktionieren. Die meisten User machen das jetzt über MQTT, und seit BSB-LAN auch das Auto-Discovery unterstützt, hat man zumindest die Konfiguration schnell gemacht. Da ich selber HA nicht verwende und das hier ja auch quasi ein "Konkurrenz-Forum" ist, ist es wohl sinnvoller, wenn Du zu Detailfragen bei einem HA-Forum nachfragst.

[the.hein]

Alles klar mache ich. Im Netz und auf div. Seiten finde ich immer öfter einen Link zu einem Handbuch BSB-Lan, wo auch sachen die MQTT, Json etc. beschrieben werden. Die Links gehen aber ins leere... Gibt es das Handbuch nicht mehr, oder hättest du nen Link der funktioniert?

Gruß, Uwe

[freetz]

Die Links sind veraltet. Das neue Handbuch ist in meiner Info-Mail verlinkt, u.a. gelangt man dorthin auch über die Projektseite, wo Du die Software heruntergeladen hast, da ist der Link gleich in den ersten zwei Zeilen ...

[horizons]

Hi nachdem ich hier mein damals gekauftes BSB Lan hier schon ewig rumliegen habe (Asche auf mein Haupt ) wollte ich es jetzt doch mal anschließen.

Und habe gleich ein paar Fragen.
Ich habe eine Weishaupt Thermo Unit WTU 20-s das BSB Lan (habe die Olimex ESP32-EVB + "BSB-LAN ESP32"-Adapterplatine v4.4)

Auf der BSB-LAN gibt es ja die Anschlüsse CL+ und CL-

Auf der Weishaupt Seite sieht es bei mir wie auf diesem Bild aus https://docs.bsb-lan.de/images/RVS23.jpeg
Bild ist von hier https://docs.bsb-lan.de/supported_heating_systems.html  (RVS23 LPB connection: LPB/M)

Ich habe mir den "Weishaupt Stecker Nr. 13" gekauft und wollte es nun anschließen.
Ich habe also auf der Heizungsseite jeweils 2x LPB und M.

Was davon ist jetzt CL+ und welches CL-?

Leider ist auf der Seite https://docs.bsb-lan.de/install.html#connecting-bsb-lan-to-the-heating-system nur DB und MB für den LPB Anschluss die Rede und M wird nur für PPS erwähnt.

Ich vermute jetzt mal CL+ wird bei mir an LPB angeschlossen und CL- an M. Ist das richtig?


Weiterhin wird hier im Video (https://youtu.be/FQlDb4AeUxI?t=429) erwähnt dass man den Anschlusstyp auf der Einstellungsseite korrekt gewählt werden muss also zwischen BSP / LPB und PPS den richtigen Anschlusstyp wählen.

Muss dies vor oder kann dies auch erst nach dem Anschluss an die Heizung passieren?
Verliert man nicht das Setting wenn ich zu einem späteren Zeitpunkt mit der angepassten Parameter Liste die Firmware neu flashe?
Was passiert wenn man den falschen Typ auswählt?

Bei mir wäre es doch LPB?
Ich bin ein wenig verwirrt weil ich mit M eine PPS Bezeichnung auf meiner Weishaupt Heizung habe und an den Anschluss 13 laut Anleitung der Heizung an den Anschluss Nr. 13 Raumgeräte angeschlossen werden welche aber hier beim Anschlusstyp PPS erwähnt werden?

[freetz]

Ja, die Bezeichnungen sind nicht einheitlich, aber M steht i.d.R. für "Masse" und somit für "-". Im Zweifelsfall geht aber auch nichts kaputt, wenn Du es andersherum anschließt, dann leuchtet halt die LED am Adapter nicht, und Du weißt, dass es falsch gepolt ist. Wie es sich genau mit Deinem Regler verhält, weiß ich nicht, aber LPB ist LPB und nicht PPS. Normalerweise gibt es keine Raumgeräte, die über LPB arbeiten, aber ich meine, dass Weishaupt da eine Ausnahme ist.

Den Anschlusstyp kannst Du auch später noch umstellen, Du bekommst halt nur keine Werte auf Parameterabfragen, wenn die Einstellung nicht stimmt.

Die Settings bleiben so lange erhalten, bis das EEPROM gelöscht wird. Das Updaten hat keine Auswirkung darauf, wenn sich durch das Update nicht das EEPROM-Layout ändert. Dann wird das EEPROM mit den Werten aus der BSB_LAN_config.h neu initialisiert.

[freetz]

Dank luci84tm habe ich endlich die PPS-Erneureungen für Version 4 testen und noch einen dicken Fehler gefunden, so dass jetzt alles so läuft, wie es soll und ich endlich die Version 4 mit vielen Verbesserungen (aber auch "breaking changes") releasen konnte. Hier die Veränderungen im Überblick:

    ATTENTION: BREAKING CHANGE! Room temperature parameter 10000, 10001 and 10002 must now have the additional flag FL_SPECIAL_INF, otherwise setting temperature will not work!
    ATTENTION: BREAKING CHANGE! Outside temperature simulation parameter 10017 must have FL_SPECIAL_INF flag removed, otherwise setting temperature will not work!
    ATTENTION: BREAKING CHANGE! Room temperature parameter 10000, 10001 and 10002 for Weishaupt heaters (device families 49, 50, 51 and 59) must now have FL_SPECIAL_INF flag removd, otherwise setting temperature will not work!
    ATTENTION: BREAKING CHANGE! URL commands /U (dislpay user-defined variables) and /X (display MAX! values) have been removed as these values can now be accessed via parameters 20000++
    ATTENTION: BREAKING CHANGE! PPS time program parameters (15050-15091) have been streamlined with BSB/LPB time program parameters, resulting in only one parameter per day (instead of six), covering three switch points (start and end) per parameter.
    ATTENTION: For ESP32, BSB-LAN tries to support framework version 3.0.0 - please look out for errors or strange behaviour when using Ethernet with fixed IP, 1-Wire sensors or any other kind of strange behaviour/crashes
    ATTENTION: New configuration options in BSB_LAN_config.h - please update your existing configuration files! Web-based configuration will be overwritten with config file settings due to change in EEPROM layout!
    ATTENTION: New manual URL: https://docs.bsb-lan.de/
    BUTTONS and RGT_EMULATION have been moved from main code to custom_functions library. To continue using them, make use of BSB_LAN_custom_*.h files and activate CUSTOM_COMMANDS definement.
    Most configuration definements removed from BSB_LAN_config.h. Almost all functionality can now be configured without reflashing.
    BSB-LAN now supports MQTT auto discovery (supported e.g. by Home Assistant). To create devices, call URL command /M1 to remove them call /M0
    ATTENTION: MQTT auto discovery creates a general switch for the BSB-LAN device in Home Assistant. This switch will immediately write all parameters with the values stored in Home Assistant. DO NOT USE THIS SWITCH unless you REALLY know what it does!
    "Set" button in webinterface now also works with non-default destination devices (i.e. 1 instead of 0)
    Queried/set parameters are now forwarded to the MQTT broker (if MQTT is enabled)
    Previously used /M1 and /M0 for toggling monitor function have been removed since it can now be accessed via the configuration in the webinterface.
    Listing categories with /K now also works with destination device.
    Important bugfix for OTA update: Previous versions had a hard limit on file size which newer heating systems with several hundred parameters hit, so no OTA update was possible. This is now fixed, but affected users will have to make a USB-based update one more time.
    1-Wire- and DHT-sensors are now be disabled with value -1 instead of 0. In web interface, an empty field is also accepted.
    MQTTTopicPrefix is no longer optional, "fromBroker" topic removed (formerly used to send commands to BSB-LAN via MQTT)
    Using the 24h averages functionality no longer requires the use of an SD card. SD card will only be used to store averages if interval logging to SD card is active.
    New PPS room unit variant for RVD130, which increases high nibble of magic byte at every transaction.
    Polling current time from NTP server is active by default. Deactivate by setting ntp_server to empty string.
    New parameter flag FL_NOSWAP_QUR for parameters that do not swap the first two bytes of command ID in QUR telegram
    New parameter flag FL_FORCE_INF for parameters from which we are certain they only work with INF (such as room temperature). Will force an INF telegram even if /S is used to set the parameter (allows setting room temperature via web interface)
    BSB-LAN logo watermark in log graph display (DE-cr)
    Binary ENUMs (yes/no, on/off etc.) now return either 0 or 1 when queried, not - as is the case with some heating systems - 0 or 255. Setting any value from 1 to 255 is still possible.
    Fixed bug (or, based on perspective, reduced security) that prevented issuing commands via serial/telnet console when HTTP authentication was active
    Various bugfixes, among others logging of bus telegrams on storage device.
    New OneWireNg library version
    This release has been supported by the following sponsors: Erich Scheilko

[Markus_MG]

Alles klar mache ich. Im Netz und auf div. Seiten finde ich immer öfter einen Link zu einem Handbuch BSB-Lan, wo auch sachen die MQTT, Json etc. beschrieben werden. Die Links gehen aber ins leere... Gibt es das Handbuch nicht mehr, oder hättest du nen Link der funktioniert?

Gruß, Uwe

Habe mein neues BSB-Lan auch kürzlich im Homeassistant eingebunden, ohne Auto Discovery. Habe mich an dieser Anleitung gehalten:
https://github.com/ryann72/Home-assistant-tutoriel/blob/main/BSB-LAN/tutoriel%20BSB-LAN%20English.md

Es geht viel viel einfacher... Dankeschön für das Tutorial.

https://youtu.be/DbHEiWm5nBs?si=plKVI21eZywFHSKa

[freetz]

Dank einiger Rückmeldungen gab es jetzt noch mal einige (leider "breaking") Änderungen an der MQTT-Struktur, weil es tatsächlich Fälle gibt, wo mehrere Geräte (z.B. Brötje ZR1) mit der gleichen Gerätefamilie und -variante im System waren, welche dann nicht mehr eindeutig zuordenbar gewesen wären. In dem Zug habe ich aber auch gleichzeitig die schon von vielen gewünschte bessere Strukturierung der MQTT-Topics angegangen. Nun ist die Topic-Struktur so:
<TOPIC>/<DEVICE ID>/<KATEGORIE NR>/<PARAMETER NR>

Das hat den Vorteil, dass man nun gezielter einzelne Kategorien bestimmter Geräte subscriben kann, ohne hunderte Parameter immer gleich "mitnehmen" zu müssen. Leider bedeutet das, dass bisherige MQTT-Konfigurationen in Smart-Home-Systemen entsprechend angepasst werden müssen.
Wer die bisherige Auto-Discovery-Funktion schon verwendet, muss zuerst mit /M0 die alten Einträge im Broker entfernen lassen (geht auch direkt per Kommandozeile des jeweiligen Brokers), um sie dann nach dem Update mit /M1 neu anzulegen. Ich hoffe, dass dann aber erst mal Ruhe damit sein wird .

Hier das komplette ChangeLog dieses ansonsten eher kleinen Updates auf die Version 4.1:

- **ATTENTION: BREAKING CHANGE!** Changed topic structure for MQTT. This means that all existing MQTT entities in your home-automation system will have to be adjusted or created anew! The new structure now is `BSB-LAN/<device id>/<category id>/<parameter number>`.
- **ATTENTION: BREAKING CHANGE!** Changed unique_id for MQTT auto-discovery. This means that all MQTT entities that have been created via auto-discovery will have to be created anew!
- **ATTENTION:** Configuration options `fixed_device_family` and `fixed_device_variant` have been removed since they no longer work for device-specific parameter lists. If your heating system is off when turning on the microcontroller, BSB-LAN will try to acquire the details every 60 seconds.
- **ATTENTION:** Change of configuration options results in new EEPROM layout, therefore EEPROM will be reinitialized based on configuration of `BSB_LAN_config.h`.
- MQTT auto-discovery now works for all devices, not only device ID 0. Use `/M1!<x>` or `/M0!<x>` to create/remove entities for device ID `<x>`.
- Changed MQTT auto-discovery messages' flag to "retain" so that parameters remain available after reboot of Home Assistant.

[horizons]

Hi
ich habe heute mein BSB-Lan zuerstvon 4.0.64 auf 4.2.1 danach nochmal auf  4.2.2 geupdated.

Das OTA update ging eigentlich ohne Probleme nur musste ich meine Einstellung wieder über die Gui machen.
Alle settings waren wieder auf dem Standardwert und ich musste den Bus Typ, Mqtt, logging parameter wieder setzen.

Beim 2. update auf 4.2.2 habe ich dann einige paramter in die `BSB_LAN_config.h` gesetzt wie z.b. mqtt user/addresse etc.
Habe aber wohl nicht nicht alle parameter gefunden bzw. obwohl ich sie gesetzt habe waren sie in der GUI nicht gesetzt.

z.b. hatte ich
uint8_t bus_type = 1;  // set bus system at boot: 0 = BSB, 1 = LPB, 2 = PPS
aber es war in der GUI nach dem update dennoch wieder auf BSB.


Zu den Mqtt Sensoren:
Zuvor hatte ich meine gewünschen MQTT Sensoren manuell in mein Home assitant hinzugefügt.
Wollte aber heute das auto discovery nutzen da ich bisher nur lesbaren Sensoren wie Temperatur genutzt hatte und auch die anderen Optionen nutzen wollte.


Dabei ist mir folgendes aufgefallen nach /M0 habe ich immer noch diese Topics im mqtt explorer sichtbar
homeassistant/sensor/10000_255_255/config
homeassistant/sensor/10001_255_255/config
homeassistant/sensor/10002_255_255/config
homeassistant/sensor/10110_255_255/config

1. könnte man diese ganzen parameter bitte eine extra Kategorie z.b. "bsb-lan" geben damit diese übersichtlicher aufgelistet sind z.b. im Mqtt-Explorer addon.
die namen wären dann z.b.
homeassistant/sensor/bsb-lan/10000_255_255/config
homeassistant/sensor/bsb-lan/10001_255_255/config
usw.


2. diese topics die nicht zu meiner Heizung passen muss ich nach dem autodiscovery /M1 aufruf von hand löschen weil sie retained sind (ist zum Glück bei nur 4 Werten nicht so problematisch).



Nach dem /M1 habe ich neue Sensoren im homeassistant topic wie z.b.

Code Auswählen Erweitern

homeassistant/sensor/0_255_255/config
 {   "name":"00-00 Uhrzeit - 0 - Aktuelles Datum / Aktuelle Uhrzeit",   "unique_id":"0-255-255-16579",   "state_topic":"BSB-LAN/0/0/0","icon": "mdi:calendar",  "unit_of_measurement":"",   "device": {     "name":"BSB-LAN",     "identifiers":"BSB-LAN-244CAB23445C",     "manufacturer":"bsb-lan.de",     "model":"4.2.2"   } }

homeassistant/sensor/3_255_255/config
 {   "name":"00-00 Uhrzeit - 3 - Datum 2",   "unique_id":"3-255-255-16579",   "state_topic":"BSB-LAN/0/0/3","icon": "mdi:calendar",  "unit_of_measurement":"",   "device": {     "name":"BSB-LAN",     "identifiers":"BSB-LAN-244CAB23445C",     "manufacturer":"bsb-lan.de",     "model":"4.2.2"   } }

In der alten Version von BSB-lan 4.0.64 wurde beim /M1 die notwendigen parameter in die "Logging Parameter" Einstellung hinzugefügt bei mir war es "71,10110,110,111,112,113,114,115,116,118,120,125,126". Bei der neuen bleibt es bei "8700,8743,8314".
Ist das hinzufügen der Logging Parameter für MQTT nicht mehr notwendig?

bzgl der Namen der Sensoren wieso heißen sie z.b.
BSB-LAN 00-00 Uhrzeit - 0 - Aktuelles Datum / Aktuelle Uhrzeit
BSB-LAN 00-00 Uhrzeit - 3 - Datum 2
BSB-LAN 00-11 Servicefunktionen - 110 - Aussentemperaturfühler lokal

Woher kommt das "00-" welches bei jedem Sensor dabei steht?

Ich habe zudem das Problem dass auch nach längerem warten viele der Sensoren immer noch unbekannt sind.

wie z.b. sensor.bsb_lan_00_00_uhrzeit_0_aktuelles_datum_aktuelle_uhrzeit (also die config vom Aktuelles Datum / Aktuelle Uhrzeit siehe oben) während Datum 2 mit "2024" korrekt wiedergegeben wird?


Ich habe gemerkt dass dies alles Sensoren sind bei denen `unit_of_measurement: ""` festgelegt ist, diese sind dann "nicht verfügbar".

Wenn ich den Sensor von Hand anlege und dieses optionale setting weg lasse funktionieren diese.
Datum 2 wird wohl obwohl es auch dieses setting hat richtig angezeigt weil nur ein integer/float übergeben wird und kein string wie bei einer Uhrzeit oder Datums.

Habe es aber mal getestet wenn ich die mqtt sensoren wie folgt anlege funktioniert nur Datum_3.
Lasse ich `unit_of_measurement: ""` weg funktionieren alle.

Code Auswählen Erweitern

    - name: "Datum_0"
      state_topic: "BSB-LAN/0/0/0"
      object_id: "bsb_lan_Datum_0"
      unique_id: bsb_lan_Datum_0
      unit_of_measurement: ""
      availability_topic: "BSB-LAN/status"
      device:
        {
          identifiers: ["Heizung-BSB-LAN"],
          name: "Heizung-BSB-LAN",
          model: "Olimex ESP32-EVB",
          manufacturer: "Weishaupt",
        }
    - name: "Datum_1"
      state_topic: "BSB-LAN/0/0/1"
      object_id: "bsb_lan_Datum_1"
      unique_id: bsb_lan_Datum_1
      unit_of_measurement: ""
      availability_topic: "BSB-LAN/status"
      device:
        {
          identifiers: ["Heizung-BSB-LAN"],
          name: "Heizung-BSB-LAN",
          model: "Olimex ESP32-EVB",
          manufacturer: "Weishaupt",
        }
    - name: "Datum_2"
      state_topic: "BSB-LAN/0/0/2"
      object_id: "bsb_lan_Datum_2"
      unique_id: bsb_lan_Datum_2
      unit_of_measurement: ""
      availability_topic: "BSB-LAN/status"
      device:
        {
          identifiers: ["Heizung-BSB-LAN"],
          name: "Heizung-BSB-LAN",
          model: "Olimex ESP32-EVB",
          manufacturer: "Weishaupt",
        }
    - name: "Datum_3"
      state_topic: "BSB-LAN/0/0/3"
      object_id: "bsb_lan_Datum_3"
      unique_id: bsb_lan_Datum_3
      unit_of_measurement: ""
      availability_topic: "BSB-LAN/status"
      device:
        {
          identifiers: ["Heizung-BSB-LAN"],
          name: "Heizung-BSB-LAN",
          model: "Olimex ESP32-EVB",
          manufacturer: "Weishaupt",
        }


Bitte daher den code abändern dass kein leerString übergeben wird.
Laut der Doku sollte eigentlich null erlaubt sein aber der Parser in Vscode gibt hier auch einen Fehler zurück dass ein String erwartet wird.

Edit: Sehe gerade es betrifft nur readonly "sensoren" also werte die z.b. im "Schreibzugriff (Ebene) = Aus" angelegt werden.
Wenn ich auf Komplett gehe sind über die die binary_sensor/text/select und switch die werte über die entitäten korrekt ausgelesen.

[freetz]

Bitte, wenn Du zig Fragen auf einmal stellst, irgendwie sortieren/nummerieren/etc., denn sonst wird es sehr schnell konfus. Schon gar nicht in der Mitte irgendwo mit 1. und 2. anfangen und dann aufhören.
Ich antworte jetzt mal anhand der Reihenfolge und nummeriere neu, damit da ein bisschen Ordnung reinkommt:

1. Bei jedem Update, das das EEPROM ändert, werden die Angaben aus der BSB_LAN_config.h genommen. Steht auch im ChangeLog jedes Mal extra hervorgehoben.
2. Das /homeassistant/ Topic dient ausschließlich dem Auto-Discovery, das derzeit nur von Home Assistant genutzt wird. Da nicht dran rumspielen, sondern einfach ignorieren.
3. Welche Topics "passen nicht zu Deiner Heizung"? Die, die Du nicht haben willst, einfach in Deiner Home Automation Software ausblenden. Alternativ kann man alle retained messages, die von BSB-LAN kommen, mit /M0 entfernen lassen.
4. /M1 fügt nichts in die "Logging Parameter" Einstellungen hinzu. Das wirst Du selber gewesen sein. Wenn Du Parameterwerte aktiv an den MQTT Broker übertragen willst, musst Du weiterhin an MQTT loggen lassen.
5. Die Struktur der Parameterbezeichnung ist "BSB-LAN <Geräte ID>-<Kategorie Nr.> <Kategorie> - <Parameter Nr.> - <Parameter-Bezeichnung
6. Die Sensoren bleiben so lange unbekannt, bis diese durch direkte Abfrage (siehe Handbuch) befüllt werden.
7. Das mit dem "unit of measurement" verstehe ich noch nicht. Wie muss denn dann vorgegangen werden, wenn es keine Einheit gibt? Die Heizkurve (Parameter 720) hat ja auch keine Einheit und wird bei mir problemlos angezeigt. Um da programmbasiert etwas zu machen, müsste ich eindeutige Kriterien haben, wann was zu schicken ist.

[horizons]

Bitte, wenn Du zig Fragen auf einmal stellst, irgendwie sortieren/nummerieren/etc., denn sonst wird es sehr schnell konfus. Schon gar nicht in der Mitte irgendwo mit 1. und 2. anfangen und dann aufhören.
Ich antworte jetzt mal anhand der Reihenfolge und nummeriere neu, damit da ein bisschen Ordnung reinkommt:

1. Bei jedem Update, das das EEPROM ändert, werden die Angaben aus der BSB_LAN_config.h genommen. Steht auch im ChangeLog jedes Mal extra hervorgehoben.
2. Das /homeassistant/ Topic dient ausschließlich dem Auto-Discovery, das derzeit nur von Home Assistant genutzt wird. Da nicht dran rumspielen, sondern einfach ignorieren.
3. Welche Topics "passen nicht zu Deiner Heizung"? Die, die Du nicht haben willst, einfach in Deiner Home Automation Software ausblenden. Alternativ kann man alle retained messages, die von BSB-LAN kommen, mit /M0 entfernen lassen.
4. /M1 fügt nichts in die "Logging Parameter" Einstellungen hinzu. Das wirst Du selber gewesen sein. Wenn Du Parameterwerte aktiv an den MQTT Broker übertragen willst, musst Du weiterhin an MQTT loggen lassen.
5. Die Struktur der Parameterbezeichnung ist "BSB-LAN <Geräte ID>-<Kategorie Nr.> <Kategorie> - <Parameter Nr.> - <Parameter-Bezeichnung
6. Die Sensoren bleiben so lange unbekannt, bis diese durch direkte Abfrage (siehe Handbuch) befüllt werden.
7. Das mit dem "unit of measurement" verstehe ich noch nicht. Wie muss denn dann vorgegangen werden, wenn es keine Einheit gibt? Die Heizkurve (Parameter 720) hat ja auch keine Einheit und wird bei mir problemlos angezeigt. Um da programmbasiert etwas zu machen, müsste ich eindeutige Kriterien haben, wann was zu schicken ist.

1. du hattest ein paar postings drüber folgendes geschrieben "Die Settings bleiben so lange erhalten, bis das EEPROM gelöscht wird. Das Updaten hat keine Auswirkung darauf, wenn sich durch das Update nicht das EEPROM-Layout ändert. Dann wird das EEPROM mit den Werten aus der BSB_LAN_config.h neu initialisiert." Aber eventuell hat sich ja das EEPROM-Layout geändert

Wie ich geschrieben habe hatte ich beim update auf die 4.2.2 ja z.b. den bus typ auf LBP in der config.h geändert dennoch war es nach dem OTA update wieder auf BSP gestanden.

2. Es stimmt schon dass es nur für die Autodiscovery genutzt wird aber auch dort kann man ein unter topic anlegen damit die sensoren/settings vom bsb lan gruppiert sind. Habe ich auch bei anderen Mqtt Sensoren anderer dinge.
Es ist nur für die Übersicht und verhindert natürlich auch dass ein anderer über die autodiscovery angelegter mqtt sensor mit gleichem namen den anderen überschrieben würde. Auch wenn die Gefahr gering ist dass jemand das homeassistant/sensor/0_255_255 für einen sensor nutzt wäre homeassistant/sensor/bsb_lan/0_255_255 richtiger.

Sie auch die Bilder vom Mqtt-explorer es ist ohne einen subnamen einfach nicht übersichtlich andere wie die deye_dummycloud nutzen ein unter topic.

Du darfst diesen Dateianhang nicht ansehen.
Du darfst diesen Dateianhang nicht ansehen.

3. ich hatte glaube ich die Sensoren für diese log settings "8700,8743,8314" angelegt bekommen. Habe sie wie gesagt schon über dem mqtt-explorer gelöscht sie blieben auch bei einem /M0 drinnen.
Bin mir nicht mehr sicher eventuell wurden sie durch das autodiscovery angelegt welches ich direkt nach dem OTA update gemacht hatte und noch der falsche bus typ gesetzt war (siehe 1.) ich dann aber auf den richtigen typ gewechselt habe.

Beim löschen des MQTT topics musst du doch für jedes topic ein befehl abschicken oder?
Sendest du diese auch für topics die nicht zum Bus typ passen?
Wie gesagt wenn du eine unter topic nutzen würdest wäre es besser dann müsstest du auch nur

Code Auswählen Erweitern

homeassistant/sensor/bsb_lan/
homeassistant/binary_sensor/bsb_lan/
homeassistant/text/bsb_lan/
homeassistant/select/bsb_lan/
löschen als jedes topic für jeden wert einzeln?

4. ich bin mir sicher dass zig parameter bei der älteren version dem setting hinzugefügt wurden. Ich kann mich jedenfalls nicht erinnern dass ich die alle die bei dem setting standen selbst hinzugefügt hatte.
Aber prinzipielle Frage muss ich dort die einzelen Werte angeben damit sie über mqtt geloggt werden? Ich denke mal nein denn sonst hätte ich nicht 100te sensor werte wo in der Doku steht dass man nur 20 werte loggen kann.

Code Auswählen Erweitern

https://docs.bsb-lan.de/de/homeautomation.html
Select up to 20 Log Parameters you want to be sent to your home automation system.

6. die sensoren blieben über stunden "unbekannt" weil sie keine werte zugwiesen bekommen haben es hat nichts mit dem log interval oder so zu tun. Die Werte sind in MQTT vorhanden werden nur nicht in die Entität eingetragen.


7. Mir ist wie oben noch im edit aufgefallen ich hatte anfangs nur den read only modus aktiviert und bekam deswegen alle Werte als nur lesbare "sensor" entitäten in Homeassistant hinzugefügt.
Wenn ich auf den Schreibmodus=EIN ändere bekomme ich sie auch als text/select usw. entitäten und dort bekomme ich die Werte richtig angezeigt.
Also nur dort bei den "sensor" entitäten weiterhin "unbekannt".

bzgl dem `unit_of_measurement: ""` habe ich noch dieses issue gefunden.
https://github.com/home-assistant/core/issues/93071

Wenn ich aber in meiner lokalen yaml config "unit_of_measurement: null" angebe meckert die vscode extension rum dass sie einen string will und es funktioniert auch nicht wenn ich "unit_of_measurement = None" angebe..
Ich würde es also einfach weg lassen wenn "". Eventuell funktioniert ja auch das None im json in der autodiscovery. Im Yaml code geht es wie geschrieben null/None etc. alles nicht.
Integer und float werte werden auch mit unit_of_measurement = "" richtig eingetragen alles andere aber nicht.

[horizons]

zu diesem Punkt hätte ich noch eine Frage

5. Die Struktur der Parameterbezeichnung ist "BSB-LAN <Geräte ID>-<Kategorie Nr.> <Kategorie> - <Parameter Nr.> - <Parameter-Bezeichnung

Wo setze ich diese <Geräte ID>?
Die auf der Einstellungsseite kann es ja nicht sein, denn dort haben ich "BSB-LAN" genauso wie beim Topic Prefix.
Die Sensoren heißen dennoch alle: "BSB-LAN 00-00 Uhrzeit - 0 - Aktuelles Datum / Aktuelle Uhrzeit"

Ich finde auch nirgends eine Möglichkeit diese 00 zu ändern.

Ist die 00 eine Angabe wenn man mehrere BSB-Lans benutzt sodass der nächste 01 wäre?

Die autodiscovery funktioniert dann nämlich auch im moment nicht wenn man mehrere bsb-lans betreibt.
Denn die Sensoren würden sich ja gegenseitig überschreiben.

Es wäre dann erst recht ratsam eine untertopic pro gerät einzuführen denn ansonsten funktioniert das automatische anlegen nicht.
also "homeassistant/sensor/<mqtt_topic>-<geräte-id>/<sensor-id>"

Code Auswählen Erweitern

homeassistant / sensor / BSB-LAN-00 / 0_255_255
homeassistant / sensor / BSB-LAN-00 / 1_255_255
...
homeassistant / text / BSB-LAN-00 / 0_255_255
homeassistant / text / BSB-LAN-00 / 1_255_255
...

und die Werte dann auch so zu gruppieren z.B. <mqtt_topic> / <geräte-id> / <senor-topics>

also

Code Auswählen Erweitern

BSB-LAN / 00 / 0_255_255
BSB-LAN / 00 / 1_255_255
...


[freetz]

1. Keine Ahnung, von welcher Version auf welche Du genau upgedatet hast. Die Regel ist, dass das EEPROM entweder nicht von einem Update betroffen ist, oder komplett neu aus der _config.h übernommen wird. Vielleicht ist da irgendwo was im Update-Prozess schief gelaufen, dann einfach mit /NE das EEPROM löschen, dann wird es auf jeden Fall neu aus der _config.h angelegt. Mehr kann ich dazu nicht sagen.

2. Ich beziehe mich auf die offiziellen Spezifikationen von Home-Assistant, die hier zu finden sind:
https://www.home-assistant.io/integrations/mqtt/
Dort steht unter "Discovery Messages / Discovery Topic":

The discovery topic needs to follow a specific format:
<discovery_prefix>/<component>/[<node_id>/]<object_id>/config
[...]
Best practice for entities with a unique_id is to set <object_id> to unique_id and omit the <node_id>.

Da die einzelnen Parameter jeweils eine unique_id besitzen, halte ich mich an die sich dann empfohlene Struktur. Der unique_id habe ich vor ein paar Tagen übrigens schon noch die Seriennummer des Reglers hinzugesetzt, so dass es da extrem unwahrscheinlich ist, dass es Doppelungen gibt.

3. Meines Wissens kann man nicht komplette Topics einschließlich der Sub-Topics löschen, sondern man muss an jedes einzelne eine leere Message schicken, um es zu löschen. Unterschiedliche Geräte kann/muss man mit "/M0!x" gezielt ansprechen.

4. Es war ein Fehler/Feature einer vorherigen Version, dass bei einem Anlegen eines Parameters (oder eben Hunderter über auto-discovery) bei jedem Abfrageintervall in Home Assistant auch die Parameter in BSB-LAN abgefragt wurden und damit dann auch die Werte an den MQTT Broker gepusht wurden. Das ist jetzt "behoben", denn auch wenn es eigentlich schön wäre, führt die (ggf. unbeabsichtigte) Abfrage von Hunderten von Parametern zu einem Lahmlegen von BSB-LAN. Deswegen werden jetzt Parameter wie geplant nur dann an den Broker gesendet, wenn sie entweder über das Logging dorthin gesendet werden oder über einen URL-Aufruf der entsprechenden Parameter aufgerufen werden. Das ist inzwischen auch genauer im Handbuch erklärt.

5. Die Geräte-ID ist die, die Du z.B. als Zieladresse in den Einstellungen einträgst. I.d.R. ist das 0, beim LPB-Verbund dann entsprechend auch andere Geräte. Und wie gesagt, aus genau dem Grund gibt es schon seit ein paar Tagen die Seriennummer als weiteres Identifikationsmerkmal. Ein weiteres Sub-Topic (das ich dann ja generisch vergeben müsste, wie z.B. "BSB-LAN" würde da gar nichts bringen).

6. Gerade eben mit Datum, Uhrzeit und Tag (Parameter 0 bis 3) ausprobiert, waren sofort in HA angezeigt.

7. Solange ich nicht verstehe, worin das (reproduzierbare) Problem liegt, werde ich keine Änderungen im Code auf Verdacht hin machen.

Der Code ist wie gesagt noch im Prozess. Warte sonst einfach mal 1-2 Wochen und schau' Dir dann die Dinge, die für Dich ein Problem sind, noch mal an, vielleicht hat es sich dann von selbst geklärt.

[freetz]

So, ich habe jetzt noch mal recherchiert, das "unit_of_measurement" ist optional, so dass ich es jetzt weglasse, wenn kein Wert enthalten ist. Darüber hinaus habe ich dann bei Textfeldern, wo die Einheit eh' nicht angezeigt wird, die Einheit zu der Parameterbeschreibung hinzugefügt.
Da die Node ID zwar nach best practice nicht vorgesehen ist, aber auch nicht schädlich ist, habe ich das jetzt noch mal als Sortierkriterium hinzugefügt.

Außerdem gibt es jetzt bei MQTT noch das zentrale Topic /poll, an das man eine kommaseparierte Liste von Parametern publishen kann (entweder in Topic-Notation oder wie in der Liste der Logging-Parameter in den Einstellunge). Diese Parameter werden dann umgehend aktualisiert und in ihrem jeweiligen /status Topic abrufbar gemacht.