[FEATURE REQUEST] Forward all value updates to MQTT

[escoand]

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.

[1coderookie]

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.

[escoand]

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.

[fredlcore]

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" :)...

[escoand]

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

[fredlcore]

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?

[fredlcore]

@escoand, can you get back to my follow-up question once you have the time?

[escoand]

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.

[henrythasler]

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

[fredlcore]

@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

[escoand]

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.

[fredlcore]

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.

[todor-dk]

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

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

[parsley]

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.

[fredlcore]

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.

[todor-dk]

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

[fredlcore]

I'd say we move this to a separate discussion, because it has nothing to do with the original issue.

[1coderookie]

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

[fredlcore]

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

[mirkolenz]

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.

[fredlcore]

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.

[mirkolenz]

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?

[fredlcore]

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?

[mirkolenz]

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.

[fredlcore]

Ok, thanks

[mirkolenz]

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.

[1coderookie]

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

[liudger]

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.

[fredlcore]

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?

[mirkolenz]

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.

[mirkolenz]

I just arrived home after a long day and was happy to see a new release of BSB-LAN with fixes for the auto discovery retain behavior 😄

Regarding your question (I'm a little late but would like to provide my thoughts anyway 😉 ):

/<device_id>/<parameter_number> or /<parameter_number>/<device_id>

I agree that the most logical structure would be /device/parameter, but one could also argue that if the parameters are guaranteed to be identical across all devices that the second option could be more elegant as it aligns more closely with the URL structure. However, ignoring this "legacy" aspect putting the device id first makes most sense.

I also saw that you have included a category in the topic as part of the new release. Would that be the number that is also included in the the URL scheme (e.g., the parameter with the number 904 is included on the webpage /K10!0 with 10 being the category)? If not, how could one obtain that number in case some sensors are defined manually?

Thanks!

[fredlcore]

Thanks for chiming in anytime, @mirkolenz - I chose to go by some kind of "device hierarchy" in the end because it might make filtering based on topic (something that some users had asked for in a long time) easier. For example, if you have a LPB system, you have the main controller which carries almost all the relevant parameters, plus the heat generator which also has a large number of parameters, but most of them are overridden by the main controller. For my gas heater, for example, only very few parameters which directly relate to the actual heat generating process (fan modulation, for example) are relevant. So now I can subscribe to all parameters from device ID 0 plus a few selected ones from device ID 1.

In the same way, I also added the category as an additional part of the topic. The category number is the number that follows the /Kand before any (optional) !, so the 10 in your example. While this is different for every controller, at least it's the same across any chosen language (some users had asked for the category to be human-readable, but then it would differ accross langauges). So in case someone changes the language, the topics will stay the same.

Anyway, I'm glad that as a MQTT newbie, I'm not totally off with this approach and hope that it can stay now as it is, without adding more breaking changes (in this regard ;) )...

[mirkolenz]

Great, thanks for the detailed explanation! Did you also adjust the way one should write to MQTT topics or does it still work the same as before (i.e., by publishing to the main BSB-LAN topic with some payload such as S700=VALUE without needing to include the category id)?

[fredlcore]

No, that would have required some more substantial rewriting. Would there be any (significant) benefit from that in terms of integrating BSB-LAN into MQTT-based systems?

[mirkolenz]

Would there be any (significant) benefit from that in terms of integrating BSB-LAN into MQTT-based systems?

I don't think so, this is perfectly fine as-is. Just wanted to confirm the behavior 😄

[fredlcore]

I guess it would not be too difficult to implement parsing anything written to a topic based on the same structure, but I don't really understand how a proper implementation would prevent the behavior I'm seeing now:
When I write to the topic BSB-LAN/0/16/700 the new value I want to set there, it will be received again by BSB-LAN as the broker the same way the broker supplies it to all other subscribers of the topic.
So I wonder how to differentiate between a value that has originated from BSB-LAN and comes back on the same topic, or whether it is a value that has been published by some other device and "legitimately" is meant for BSB-LAN to receive/process.

If there would be a clear way of how to differentiate between those, then I could implement it relatively easily.

[mirkolenz]

AFAIK there is no clean way to reuse the same topic for publishing states and receiving write commands. The only other option I could imagine would be support for publishing JSON payloads to some topic like BSB-LAN/write or plain payloads to an address like BSB-LAN/write/DEVICE/CATEGORY/PARAMETER (similar to how zigbee2mqtt does it): https://www.zigbee2mqtt.io/guide/usage/mqtt_topics_and_messages.html#zigbee2mqtt-friendly-name-set

[fredlcore]

Thanks, I just don't know what a best-practice approach would be here, so thanks for the link. The way with "/set" would be easily doable, but would that require to also implement a "/get" path to make a "clean" implementation? I think what I still don't understand is (based on the requests by those users) why it would make it easier or be an advantage otherwise if one doesn't write "S700=3" to the BSB-LAN topic, but would write "3" to the /BSB-LAN/set/0/16/700 topic.
I thought that the path structure for both reading and writing would make it easier to generate smaller/easier configurations for Home Assistant etc., but I'm not sure if that's the case.

[mirkolenz]

The way with "/set" would be easily doable, but would that require to also implement a "/get" path to make a "clean" implementation?

I'd say yes, z2m also has the set/get topic.

why it would make it easier or be an advantage otherwise if one doesn't write "S700=3" to the BSB-LAN topic, but would write "3" to the /BSB-LAN/set/0/16/700 topic.

From my perspective such a set topic would decouple the MQTT implementation completely from the URL endpoints. Currently, one needs to look up the URL scheme to write values, but not to read them. But I still don't know if it's worth the trouble of implementing and maintaining it...

[fredlcore]

Ok, thanks, then I guess I'll leave it as it is for now...

[fredlcore]

...or not ;)... I have now introduced the topics /status, /set, /inf and /poll added at the end of the above mentioned topic structure to control the behavior of a parameter. Furthermore, I have removed the /json topic to which data was written when selecting JSON message content. This doesn't really make sense to me, so now this setting only defines the message content and all messages are sent to the /status topic.
I hope this makes the whole thing more coherent, even though it may break compatibility at some points (controlling BSB-LAN via URL-commands via the top-level BSB-LAN topic is still possible, but deprecated).

[mirkolenz]

Cool, can't wait to try it out 😃 I could test the new topic structure next weekend and give you feedback before the release of v4.2 if you'd like!

[fredlcore]

Yes, that would be great, thanks!

[mirkolenz]

One question regarding the new structure: What payload should be published to the /poll topic? Just an empty string?

[fredlcore]

Yes, the same as if you call /status for example.

[fredlcore]

BTW, Regarding the general on/off button: The interesting thing is that it disappears once I select some entities to be hidden. Once there are only the selected ones shown, the button is gone :).

[fredlcore]

I found several (rather cosmetic) bugs in the last couple of hours, most notably under the hood. Nothing that should impact testing, but worth updating if you're missing any important parameters after auto-discovery.

[mirkolenz]

Just updated my device with the latest changes from master and everything works as expected, great job!

Yes, the same as if you call /status for example.

But wouldn't you just subscribe to the static topic (and thus need no payload at all) ? With the poll topic, you need to publish something (but the empty string seems to work).

BTW, Regarding the general on/off button: The interesting thing is that it disappears once I select some entities to be hidden. Once there are only the selected ones shown, the button is gone :).

Interesting, never saw the global button myself 😄

[fredlcore]

Great to hear :) - please also let me know if the hierarchy or the topic structure needs improvement - better do it now than at a later time when people are used to it.

And yes, you are right, the /status topic needs to be subscribed, and the /poll topic needs to be written to. The content here is irrelevant, although I'm still thinking if I also add this to the top BSB-LAN topic and then accept a dash-separated list of parameters as payload, so that one could force all updates in one go, but that would need some more changes in the code.

[fredlcore]

Ok, again, it wasn't as difficult as I had thought. Now you can publish any(?) number of parameters, separated by comma, semicolon, dash or pipe to the /poll topic directly underneath the main topic (BSB-LAN by default), and the /status topic of each parameter will immediately be updated with the latest parameter value queried from the device. Non-default destination devices can be addressed via the <x>!<addr> notation, just as in the URL calls.

I think that's going to be it now. Thanks again for everyone's help, suggestions and testing!

[mirkolenz]

Even better! I think the new topic structure is a major improvement. The only inconsistency with the new BSB-LAN/poll topic is that it expects parameters in the "URL-syntax" (i.e., the device is defined via an exclamation mark and the categories are not needed at all). Would it be alternative to use a list of topics to be polled, for example /0/1/700,/0/2/800?

[fredlcore]

Sure, that wouldn't be a problem, but the added category is not necessary for the actual query, but people would have to look it up nevertheless. For most use cases, where users only have one controller, just entering the parameter numbers would probably be easier (and less error-prone) than being compelled to always enter the device and category number.
Or would it be easier to (programmatically) generate the list of polled topics? I'm still not sure what the most common use-cases and their implementations would be here...

[fredlcore]

Since sscanf allows for a very easy handling of string parsing, it was just a few lines to add to enable both notations. However, due to the ambiguity of the dash, only comma-separated topics/ parameters are allowed now. Examples have been updated in the documentation.

[mirkolenz]

Great that you decided to support both variants!

the added category is not necessary for the actual query, but people would have to look it up nevertheless

That is very true, but it is also not strictly required for the mqtt status topics (even though it makes sense to have them there for a better organization). Having them here as well makes the poll endpoint much more consistent!

[fredlcore]

That's right. I was thinking of dropping the category altogether, but some users were saying that having all parameters right under the device was a mess and would prevent subscribing to selected categories only (such as just the status category). In the end, one can just set the category to zero when publishing to BSB-LAN/poll, as it is ignored anyway.
Great, so I think I can leave this construction site for now, thanks again for testing and suggesting :)!

[mirkolenz]

Great, so I think I can leave this construction site for now

Yes indeed, just tested the latest master and the global /poll topic seems to work as expected and I could simplify some of my automations 😃 Thank you too for iterating so fast!

[fredlcore]

Great, could you maybe describe briefly what kind of MQTT-related automations you are using? I'm planning to make a few Home Assistant-related tutorial videos, for example one where I show how to set up individual periodical updates for groups of parameters with different intervals (something that users have asked for a long time), but maybe there are other things that would be good to show as well for first-time users who want to get standard use-cases up-and-running quickly...

[fredlcore]

By the way, this is the automation I created for individual poll parameter intervals:

alias: Update parameters
description: This automation updates the parameters in the payload every one and five minutes respectively.
triggers:
  - trigger: time_pattern
    minutes: /5
    variables:
      parameters: /0/51/8700,/0/51/8740
  - trigger: time_pattern
    minutes: /1
    variables:
      parameters: /1/50/8326,/1/51/8950
actions:
  - data:
      topic: BSB-LAN/poll
      payload: "{{parameters}}"
    action: mqtt.publish
mode: single

[mirkolenz]

for example one where I show how to set up individual periodical updates for groups of parameters with different intervals

That is also my primary use case for automations. My current setup is that I use the logging feature of BSB-LAN to publish values every minutes automatically. Then I have some parameters that I only sync once a day (or when Home Assistant or the MQTT integration are restarted). Besides this "general" use case, I have setup up a KNX switch to enable/disable the heating. If its value is changes, the boiler mode is then updated as well. That's it basically, here is the complete automation if anyone is interested:

mode: single
alias: BSB-LAN
variables:
  mqtt_topics:
    - /0/9/700
    - /0/9/710
    - /0/9/712
    - /0/9/730
    - /0/13/1600
triggers:
  - platform: state
    id: mqtt_poll
    entity_id: input_button.boiler_refresh_parameters
  - platform: homeassistant
    id: mqtt_poll
    event: start
  - platform: event
    id: mqtt_poll
    event_type: event_mqtt_reloaded
  - platform: time
    id: mqtt_poll
    at: 03:00:00
  - platform: state
    id: enable_heating
    entity_id: switch.enable_heating
    from: "off"
    to: "on"
  - platform: state
    id: disable_heating
    entity_id: switch.enable_heating
    from: "on"
    to: "off"
conditions: []
actions:
  - choose:
      - conditions:
          - condition: trigger
            id: mqtt_poll
        sequence:
          - action: mqtt.publish
            data:
              payload: "{{ mqtt_topics | join(',') }}"
              topic: "bsblan/poll"
      - conditions:
          - condition: trigger
            id: enable_heating
        sequence:
          - action: select.select_option
            target:
              entity_id: select.boiler_operating_mode
            data:
              option: Automatic
      - conditions:
          - condition: trigger
            id: disable_heating
        sequence:
          - action: select.select_option
            target:
              entity_id: select.boiler_operating_mode
            data:
              option: Protection

[fredlcore]

Nice, I still haven't completely grasped YAML (and kind of hate languages that are whitespace-sensitive ;) ), but I'll have a look at it in more detail...