New Component: BSB

ESPHome
1

I made an new component for ESPHome to connect heating systems with BSB. I was not really satisfied with BSB-LAN, as it is good from an usability perspective (although the “send me your log and I make you a configuration”-part bothers me…), I don’t want to have a dedicated ESP for every connected device in my home. This was especially a problem, as I have two gas meters in the vincinity of the heating system, so I couldn’t combine them into one device, even if the ESP32 has three UARTs. I use PoE a lot, so it was also a logistical question: I don’t want to buy a lot of pretty expensive equipment (switches and ESPs with PoE), only to let it run code from different sources and basically let the MCUs wait 99% of the time.

This was the start of the journey to create a BSB-component for ESPHome. As BSB-LAN is more than 50k SLOC (a lot more if you count the libs too) and supports a lot of different systems, it was many hours searching and trying to understand the quite convoluted and special-cased code. Well, after two weeks of testing and coding, my component was working: less than 1k C++ and 350 Python SLOC. I focused on the basic functionality, so it only works with BSB (no PPS or LPB) and lets you create sensors, text_sensors and numbers. Switches and binary_sensors are there too and should work, but not really tested, as it is simpler to just define them as sensors and numbers and let HA sort out the magic values with automations and templates.

You have to know a couple of things to get/set values from/to the heating system, like the field ID, the enable_byte, etc. These aren’t really documented anywhere, you have to search them inside a 12k+ header file of BSB-LAN version 2.2.2. This is tidious, but can’t be helped. My code focuses mainly on letting you define the values, so work is shifted from me as developper to the users (flexibility through configuration instead of ease of use through baked in information). This makes the code really simple and easy to understand: the business logic without boiler plate code is about 200 SLOC.

It can do:

  • tested now for more than a month of continous running with two different heating systems and a couple of updates of ESPHome in between
  • read values out of the heating system with different update_intervals
  • set values on the heating system, either as parameters or INF/broadcasts
  • robust, non blocking sending/retrying/timeout handling without overloading the bus, ACK/NACK handling
  • flexible type system
  • inherits from UART device and can be instantiated multiple times on the same ESP. This also allows for inverting the UART GPIOs so you are really flexible in the used interface: use whatever you like and have lying around
  • checks a lot of stuff in the YAML stage
  • should be documented sufficiently
  • prints all the telegrams on the log, so can be used to sniff the bus
  • integrates well into ESPHome/HA:
    • the communication, MQTT, API, wifi, ethernet, OTA, etc stuff is already implemented and is kept up to date
    • lets you combine different sensors, actors and connections to devices/busses on the same MCU
    • all the power of device_class, unit_of_measurement, accuracy_decimals, etc. No manual definitions of MQTT-entries anymore
    • settings can be styled and stepped/min/maxed in the frontend from one central definition
    • as the connection to the heating system is implemented as normal sensors/numbers, local automation/control is possible (pe continously setting the outside temperature)
    • it just works :wink:

What it can’t (and won’t) do:

  • implement LPB (I don’t have) or PPS (is really timing sensitive and only used in quite old systems anymore)
  • scan the heating system
  • support every last heating system out there, I consiously limited the special casing to a minimum (implementing INF/broadcast was bad enough…)
  • do special stuff like setting the time, time tables or the like (who needs that anyway if you have the power of the automations of HA in the background? Just set the comfort temperature directly)

Here is the link to the project: GitHub - eringerli/esphome-bsb

1 Like
2

Dear eringerli ,
I am interesting about your project.
I am using BSB LAN now, and I like esphome nodes.
My basic and important question is:
Can I create a button that, when pressed, starts heating hot water?
At home, we use it to save energy, we don’t heat the boiler unnecessarily when no one is taking a bath.
In BSB LAN, I use the command
“S10019=1” via MQTT

button:
- name: DHW push
  unique_id: bsb_lan_dhw_push
  availability_topic: "BSB-LAN/status"
  command_topic: "BSB-LAN"
  payload_press: "S10019=1"
  qos: 0
  retain: false

Thank you very much for answer.

3

Sorry for the late reply.

In theory, you can. At the moment, binary_sensors and switches are implemented, but as I don’t use them, not tested and therefore not documented. I left it in the repository, as it should theoretically work, they are only thin layers on top of numbers and sensors.

Switches/binary_sensors work by defining an on_value and off_value, you can look the exact parameters up in the code. I think, the easiest way to make this happen is pressing the function on the heating system and looking at the logs at the same time. It should print the exact values the controller sends to the system to heat the boiler. Then define a switch with these values. If you really need a button, define one in ESPHOME that enables the switch in its on_press-configuration. I personally only use sensors/numbers and interpret/send the special values in HA.

BSB-LAN hides this trickery with a lot of baked in special-casing. I personally find this quite unmaintainable, so I didn’t go down that route with my code. But if switches/binary_sensors work for you, I can add it to the documentation.