BSB-LAN
BSB-LAN copied to clipboard
fredlcore
[FEATURE REQUEST] Forward all value updates to MQTT
Is your feature request related to a problem? Please describe. The current MQTT solution is just transmitting some manual selected parameters regularly to the broker.
Describe the solution you'd like I would like to propose to implement a way to constantly publish all BSB/LSP values to the MQTT broker. Furthermore I would like to add MQTT discovery messages (https://www.home-assistant.io/docs/mqtt/discovery/). With this solution you don't need to add any configuration (beside the MQTT broker) in your smart home system, at least Home Assistant. The overall goal for me is to use BSB-LAN just as a bridge from BSB/LSP to MQTT and do all the view, historize and controlling stuff with Home Assistant.
Describe alternatives you've considered I've implemented a working solution based on ESPHome. But this is currently only listening on BSB, so manly only the "Kesseltemperatur" is updated regularly in my case. https://gist.github.com/escoand/180b6b317705944887c6fcdae3007a16
Describe your own contribution I could adapt my implementation to BSB-LAN. The issue is mainly for discussion the general idea and the concrete implementation.
Additional context This was already initially discussed with @fredlcore and @1coderookie via mail.
Thanks @escoand , I really like this idea/function! :) @dukess and @Luposoft63 please note this issue..
Just a little note about your current state, that right now only the boiler temperature ("Kesseltemperatur") is transmitted: that's because it's the default parameter which is shown at the display of the controller unit at your heating system. The controller sends an INF message via broadcast with this parameter - if you have a look at the display of the controller unit, you'll see this parameter as a permament displayed parameter at the display. (If you'd have the adapter and the BSB-LAN software, you could see that telegram coming in from the controller regularly also at the serial monitor.) If you'd have an additional room unit like QAA75 for example, then also the room temperature ("Raumtemperatur") would be transmitted, because that is the standard parameter which is shown at the room unit.
If you want to test if your function is already working with different parameters, you can do it by simply quering another parameter at the display of the controller unit. Of course you'd need the adapter setup and the connection to the controller for that, but just to have it mentioned already.. E.g.: If you use the info button and switch to the outside temperature, the dhw temperature or so, the belonging parameter should also be sent over the bus and you should be able to receive it via MQTT then. This also works if you e.g. enter a menu and have a parameter displayed, which doesn't appear using the info button. So let's say you are entering the menu and you are picking the parameter for setting the dhw setpoint temperature, then that parameter will be send across the bus as long as it's been displayed. If no changes occur, the display switches back to the default parameter boiler temp / Kesseltemperatur after a while.
If you want to test if your function is already working with different parameters, you can do it by simply quering another parameter at the display of the controller unit. Of course you'd need the adapter setup and the connection to the controller for that, but just to have it mentioned already.. E.g.: If you use the info button and switch to the outside temperature, the dhw temperature or so, the belonging parameter should also be sent over the bus and you should be able to receive it via MQTT then. This also works if you e.g. enter a menu and have a parameter displayed, which doesn't appear using the info button. So let's say you are entering the menu and you are picking the parameter for setting the dhw setpoint temperature, then that parameter will be send across the bus as long as it's been displayed. If no changes occur, the display switches back to the default parameter boiler temp / Kesseltemperatur after a while.
Yes, this already working correctly. But my wiring is currently only connected to CL+ so no requests of the other parameters is possible.
I also like the idea, especially if it is zero-config later on :). What I don't understand is how you want to manage to send "all" parameters to the broker. On some heaters these are more than one thousand! Querying one parameter takes approx. 2-3 seconds (the bus only works on 4800bps plus the time it takes for heater to answer). So if you query let's say the 1600 parameters that the RVS63 offers, that would be more than one hour to query all of them. So you couldn't even get a stable one hour interval for each parameter - and with many of them, you'll want a much tighter schedule, such as every 5 minutes or even less.
But maybe I got this wrong and in the end, it's the Home Automation System which tells BSB-LAN which parameters to send, I don't know. We chose the 20(?) parameters you can define for pushing in BSB-LAN because that seemed to be a good compromise between polling interval and not blocking the bus too much. But I'm in favor of any solution that gives users the flexibility they want and at the same time the bus enough "air to breathe" :)...
@fredlcore As far as I can see is BSB-LAN providing a history for some/important/any values. They need to get polled from the bus as well, or how is this done? That's the same point I would additionally send the answers to MQTT. Nothing more, but also nothing less. So my goal is to use the bus as much as it's already done today.
Hm, not sure if I understand what you mean by "history" - BSB-LAN itself polls only those parameters from the bus which are defined as log_parameters (up to 20) with the interval of log_intervall seconds. You can specify another 20 parameters as avg_parameters which will be polled every minute. For these parameters a 24 hour average will be calculated. But other than that it's completely up to the home automation system to decide how many parameter it polls and in which frequency. So I'm not sure where in this process you would link in your code?
@escoand, can you get back to my follow-up question once you have the time?
Sure. I wasn't aware of how BSB-LAN works. So my idea would end in just sending other (or additional) MQTT telegrams than today.
I'm using node-red-contrib-bsb-lan to regularly (30s) query a set of 12 values via the http-endpoint. This takes around 28s. So this is about the bandwidth you can get (25 Values/min).
To solve the bandwidth-problem, you might need a dynamic approach where values that change more often are queried more often and more static values are queried less often. This could be done with different trigger nodes in node-red (or something else) but you might soon reach it's limits as well...
@escoand: So what do you mean with "sending other (or additional) MQTT telegrams than today"? That is what our log_parameter is for, or do you mean something else?
@henrythasler: It's hard to tell beforehand which parameters change (often) and which ones not (so often), especially since it depends on what kind of heater you are using. Gas modulation for example changes every second on my heater but will never change on a heat pump. And some controllers can be used in multiple settings, so it's not really feasible to define this beforehand as part of BSB-LAN
I meant the MQTT discovery linked in the issue description. With this (at least Home Assistant) needs no further configuration to know everything about the sensor. But for this you have to remember which discovery message was already send.
I don't use MQTT nor do I use Home Assistant. So if you want MQTT discovery implemented, you would have to provide more information (or even better provide a PR with the necessary changes). Just like that it's not possible nor feasible for me to make any changes.
@fredlcore: Unrelated to the MQTT issue, but which parameter indicates the "gas modulation" on your boiler? If I remember it is the LM75. In those sky-high gas-price days, I'd like to see if mine is burning gas faster than the Titanic took water in.
It's 8323 (fan rpm) and 8326 (burner modulation). I think the former is a bit more accurate because sometimes the modulation is at 0% but the burner is still running...
Yes, 0% burner modulation is often defined at minimum burner capacity. E.g. in OpenTherm Protocol ID14 and ID17 have this kind of definition. Minimum burner capacity is of cause the lowest possible burn rate. Furthermore since the minimum capacity depends on certain circumstances you might even recognize that 0% burner modulation is not always at the same RPM rate. Therefore the RPM is a much better indicator for gas consumption. But at least in modern boilers you also find one switching and one modulating gas valve to be able to adjust the gas to air ratio (lambda control). So the RPM is a much better indicator than the boiler modulation but for a really accurate gas consumption you would also have to take the gas valve modulation value into account. In my case ist might be “2702 Sitherm Pro - Position Schrittmotor” but that’s just a guess. In fact if you just use the RPM value, you should gain a real good estimate. Perhaps combine the RPM with the gas valve information since on pre-purge and post-purge the RPM rate might be quite high but since the gas valve is closed there is no gas consumption in these phases.
Am 22.09.2022 um 23:16 schrieb fredlcore @.***>:
It's 8323 (fan rpm) and 8326 (burner modulation). I think the former is a bit more accurate because sometimes the modulation is at 0% but the burner is still running...
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.
Yes, you are right, the problem with RPM, however, is that it's not linear. I tried to make an Excel sheet with the rpm values in relation to gas consumption, but couldn't find out a proper equation. For a rough estimate it is fine, though.
Interesting about the fan RPM. I will have to check the correlation between the flame indicator on the display and the 8326 burner modulation (relative output) and the 8323 fan speed. I can't say for sure, but I think on mine LM74, when 8326 is 0%, the flame indicator is off. The values for 8326 that I've seen are 0%, 2%, 10%, 20% ... 100%.
Does anybody know the correlation between 8323 and 8324 (named Current fan speed on mine)?
I'd say we move this to a separate discussion, because it has nothing to do with the original issue.
@todor-dk I remember that I had a graphic about the fan speed/power correlation etc somewhere, but I can't find it right now - maybe send me an email so I don't forget to look further and that I can send it to you directly if I'll find it..
@escoand: After we have diverted from the original issue, can you please clarify what exactly you want the code to do? Because as me and others have pointed out, publishing "all" parameters is not possible if it means querying them via the bus from the heater.
I did not open the thread, but one major feature request in the initial post was to support MQTT autodiscovery (e.g., supported by Home Assistant). Should we open a separate issue for this functionality?
Another nice addition would be some sort of "push" updates for certain parameters. For instance, I configured a button to enable/disable the warm water in my boiler. I do not need updates for this parameter every minute, but would like to be informed if it is changed from the main console. My current workaround is that I added an automation that queries this parameter every night to synchronize it in case it has been changed on the boiler itself. It would be nice to have such functionality built into bsblan itself. But this could also be considered a separate feature request.
We can stick with the autodiscovery here because I think the functionality to constantly publish all values to BSB-LAN is not doable (at least as I understood it above). But I don't know much about this feature, so I'd need more info of what is expected exactly.
As for pushing certain parameters, this is what the logging function in combination with MQTT already does, isn't it? In any case, BSB-LAN has no further knowledge about the current state than you have. I.e. it would have to constantly/regularly have to query certain parameters and then act upon them, the same way as you do now already.
I am on the go currently, but I will provide you with more details about this autodiscovery later.
Regarding the second topic: I also use the logging feature, but I set it to an interval of 60 seconds. I have quite a number of control values like the heating mode, comfort temp and so on. All of these combined with my regular logging parameters (like inlet temperature and modulation) are way more than twenty. However, these control values seldomly change and thus I would like to have a different interval for them. So for me the best solution would be to have a new list of "control values" in addition to the log values with a different interval. Does that make sense to you?
Yes, it makes sense, but not as a function in BSB-LAN. Setting this up would become quite tedious in the webinterface. And maybe you are content with two different log intervals, but others want three or four - that is something that should be done in the home automation software because it is technically going to be the same: In both cases, a query is sent to the bus and the data returned to the caller. Doing it via BSB-LAN would only add another middle-man. Or am I missing something else here?
Yeah, that all makes sense. In the end, it would only be a convenience function that may not satisfy every need nonetheless. So I will just continue to handle it like I do now. As I said I will provide more information on the autodiscovery as soon as possible.
The basic information about MQTT discovery can be found in the Home Assistant documentation. For it to work, it requires that each entity is made available under the following MQTT topic scheme: <discovery_prefix>/<component>/[<node_id>/]<object_id>/config. The discovery prefix should be configurable by the user (in most cases however, it will be homeassistant). Component denotes the type of an entity, for instance binary_sensor, switch, or sensor. The object id should be some kind of unique identifier (it does not have to be human-readable). The config then includes the regular configuration object that Home Assistant uses to set up the configured component type. This object includes (among others) the name, MQTT topics, value templates to correctly set the sensor values, units and so on.
The main question is whether this feature (if possible at all) should expose all log parameters as sensors or binary sensors only or if there should be a way to control them as well (e.g., with a switch or select field). In a best case scenario, all parameters that are writable by BSB-LAN should also be exposed with control features.
I am not in a position to know whether this feature can easily be added to the existing codebase, but I hope to have conveyed the main idea: Making available all log parameters of BSB-LAN in any home automation software that implements this automatic discovery with zero configuration necessary for the user.
Sidenote: If I'm not completely wrong, @liudger asked for something like that in the past to have BSB-LAN autodetected in HomeAssistant for his implementation. I'm not talking about the whole log parameters though, I think it was just about some kind of 'here-I-am-message' or so (iirc)..
Sidenote:
If I'm not completely wrong, @liudger asked for something like that in the past to have BSB-LAN autodetected in HomeAssistant for his implementation. I'm not talking about the whole log parameters though, I think it was just about some kind of 'here-I-am-message' or so (iirc)..
Hi @1coderookie ,
It's a bit different. For a integration to discover bsblan, the already implemented mdns should work. I hadn't got time to implement it yet, but will do it soon. For mqtt it's different as described above.
Since I don't use neither HA nor MQTT, could you clearly state what needs to be changed/added to the way it is being dealt with now? Please keep in mind that depending on whether people use the device-specific parameter list or the previously used "one size fits all" parameter list, BSB-LAN has no way of knowing what parameters the heater really supports. One could argue that this is the user's problem/choice and another reason to switch to the device-specitic parameter list, but I just wanted to highlight that this could be a problem. Furthermore, does this mean that actual values are also transmitted in this process or is this just the structure or available parameters and querying them is done in a different, unrelated step? If values would have to be transmitted, this would result in a full query of all parameters over the bus taking several minutes. Or are we only talking about the 20 or so log parameters that the users define?
These are all valid questions. My proposal was concerned with making the ~20 log parameters available via the discovery feature. The following would need to be changed:
- Add config options "Enable MQTT Discovery" (bool, default:
false) and "MQTT Discovery Prefix" (string, default:homeassistant). - For all user-defined log values, publish them under the discovery prefix according to the scheme outlined above.
Conceptually, that is all there is to it. You could basically treat it as an extension to the existing MQTT logger. As of now, the configuration flow in Home Assistant for every log parameter requires you to write a custom yaml like the following:
Sensor:
unique_id: 93ee89e4-3486-478d-a2ff-20fe38d1e0d9
force_update: true
availability_topic: "bsblan/status"
state_topic: "bsblan/8310"
name: Boiler inlet temperature
value_template: "{{value | replace('---', '0.0', 1) | float}}"
unit_of_measurement: °C
device_class: temperature
icon: mdi:thermometer-chevron-up
Switch:
name: Boiler hot water
unique_id: 30d66077-1ea6-4c9a-a1a3-6871d1133525
state_topic: "bsblan/1600"
state_on: "1 - On"
state_off: "0 - Off"
command_topic: "bsblan"
payload_on: "S1600=1"
payload_off: "S1600=0"
availability_topic: "bsblan/status"
icon: mdi:water-boiler
The main question that remains is how one should deal with values that can be written to by BSB-LAN. Ideally, these would be discovered as buttons/switches/selects that allow to write to them from the home automation app. The main issue I see here is how to deal with certain options. Consider for example the following input number:
name: Boiler changeover temperature
unique_id: dac63f1c-37dd-4837-a93b-0234c600dc14
state_topic: "bsblan/730"
command_topic: "bsblan"
availability_topic: "bsblan/status"
min: 10.0
max: 20.0
step: 0.5
mode: slider
unit_of_measurement: °C
device_class: temperature
command_template: "S730={{value}}"
value_template: "{{value | float}}"
icon: mdi:sun-snowflake-variant
It is possible to define min/max/step values that control the behavior of the slider in Home Assistant. How should BSB-LAN set them correctly? If the boiler provides information about min/max values, then this would be an easy feat. But I just do not know if such information is available to you. If not, one could for instance just leave them out of the discovery payload and use the "default" values of the home automation software.
I think correctly handling this will be the main discussion topic for such a feature. Hopefully, I was able to convey the required changes better than in my last comment. If not, please let me know what is still unclear. I could also provide you with my complete configuration for various sensors/buttons and so on in Home Assistant as the discovery payload will be mostly identical to the manual configuration.