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
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