MQTT Switch in Home Assistant

[GSzabados]

Hello,

I am struggling to find the correct format for an MQTT Switch in Home Assistant to set the Domestic Hot Water on and off.

This is what I have tried so far and a few permutations regarding topics, commands, etc., but I cannot set it for some reason. What do I miss or do wrongly? I cannot even see the status, but I set BSB-LAN to send 1600 as well as many others (others are received and displayed correctly, but those are sensors). And just to confirm, I can set the value from URL, but not from the Web interface. (I am on version 2.0.93-20210423142305)

#BSB-LAN
  - platform: mqtt
    unique_id: bsb_lan_dhw
    state_topic: "BSB-LAN/1600"
    name: BSB-LAN Domestic How Water Switch
    command_topic: "BSB-LAN"
    payload_on: "/S1600=1"
    payload_off: "/S1600=0"
    state_on: "1"
    state_off: "0"
    optimistic: false
    qos: 0
    retain: true

@fredlcore, @torbennehmer - could you please help me out what would be the right syntax?

[fredlcore]

First of all, please update to the most recent version on GitHub.
Then please report if anything is not working in the web interface.
If there are any problems here, I'll look into them, but if it is only related to your MQTT setup,I cannot help you here because I'm not using MQTT myself. As for @torbennehmer, it's up to him to decide if he wants to look into this any further.

[GSzabados]

@fredlcore, ok, no worries, at the moment I cannot update to the latest version, as I don't have any access to the device if something would go wrong and any physical interaction would be required, but I will do once I have a chance to do so.

Tagged @torbennehmer, because I read that he is using HA and MQTT as well and I saw from his comments that he has gone through probably this sort of setup.

[GSzabados]

I struggled a bit more an have found the right syntax.

#BSB-LAN
  - platform: mqtt
    unique_id: bsb_lan_dhw
    state_topic: "BSB-LAN/1600"
    name: BSB-LAN Domestic How Water Switch
    command_topic: "BSB-LAN"
    payload_on: "S1600=1"
    payload_off: "S1600=0"
    state_on: "1 - On"
    state_off: "0 - Off"
    optimistic: false
    qos: 0
    retain: true

@fredlcore - by any chance do you know what is the difference between the On and the Eco option? I guess it must be related to the reduced temperature and the schedule of the reduced temperature, but I am just guessing.

[GSzabados]

@1coderookie - Thanks for the really long answer, I really appreciate it. Yes, that is a bit of my lack of knowledge of the heater and BSB-LAN. But it helps a lot.

Once I will have physical access to the device, then I will confirm your questions. But until then, here is my setup.

The normal DHW temperature is set to 50 Celsius with a hysteresis of 5 Celsius, as I can recall fron the top of my head at the moment. So if DHW drops below 50 C then it starts the charging cycle up to 55 C. (Probably I could reduce the 50 to 45 to keep it comfortable, and think of your comments, I should change the normal and reduced schedule but I will come back to that later...) The reduced temperature is 40 as I can recall but even during the night the heater doesn't kick in as the temperature in the tank hasn't drops below that level.
As I was making the DHW accessible from HA, I just looked at the parameters related to DHW and I think the max temperature and the anti-legionela settings are set to 65 Celsius. So the situation might have been that I turned on the DHW and as it has dropped down for a few days to something around 20 the system heated up automatically to the anti-legionela temperature, I don't know, I am just speculating and guessing, but it would make sense. An that's the reason why I was confused by the high temperature of 65 Celsius in the tank, what is not a common thing that I have ever seen. (Disregarding the time when this new system was installed at the end of April and for a night the hot water tank was charged by an electric heater, which was installed at that time, and hasn't been used since.)
The 20 minutes charging time what I was mentioning is a full cycle charging from around 20 to the desired 50 (55) Celsius, and it is amazing compared to the previous one. To be honest, I love this new heater compared to the previous one which one was again a Brötje, but it hasn't had the fine tuning options like this new. (The DHW was only a dial with some temperature markings, and it was never working as I expected. I set to 40, then it was 35, then I turned just a bit and it was 60 the temperature in the tank, the adjustment was just not working. To confirm temperatures, I fitted DS18B20 temperature sensor under the top plastic lid on the top of the metal tank, just below the polystyrene insulation. It is not really reactive as it is sensing more the whole metal tank than directly the water, but it gives an idea what temperature is the maximum and when it heats and cools down, with delay.)

I will definitely check the installation manual, if I have a copy of that. Brötje is not so much generous providing those publicly as I can recall, but I will have a look.

Just to have a better picture, what my setup. I have Heating Circuit 1 which consist of 6 radiators smaller/bigger radiators and 1 towel rack radiator. And Heating Circuit 2 which is floor heating, I don't know how many sections and square meter, about 40 percent of the house mostly where is no wooden floor and no radiators, except the bathroom. There is the DHW circuit. And I do have an external heater, I believe that's how Brötje calls it, it is a fireplace with a water tank. If the water temperature reaches 40 Celsius, it shuts of the gas heater, and circulates the water through the radiators in HC 1, as I recall. There are total 3 or 4 pumps and 1 or 2 mixing valves, I cannot remember exactly.
I think when it was installed I managed to understand the system in details, especially after receiving the BSB-LAN module and set it up. The only thing what I missed is a temperature sensor on the HC 1 line, the system assumes for HC 1 temperature from the temperature leaving the heater as I can recall, but I guess this is a standard setup, as really HC 2 requires temperature limitations.

So back to the time schedule, after your explanation, I think I should set/leave the normal temperature at 50 Celsius, but set the time range only the morning and evening 3-4 hours each (max.) and leave the rest on reduced temperature 35-40. You are right, the higher temperature is only required if we take a shower/bath, and if really needed, I could set up the push function as well outside of those times. (I don't know how that works but I believe that's would be use case for that.)

Thanks for all the advices again, I really appreciate them! They are really useful!

@fredlcore, @1coderookie - all your work are amazing, what you have made in this piece of hardware and software. Thanks again!

[1coderookie]

@fredlcore: Thanks ☺️

@GSzabados: You're welcome, I'm glad if it was helpful.
You're detailed description was good, now the picture gets more clear and your system doesn't seem to be as 'misconfigured' as it seemed to be before ;)

The normal DHW temperature is set to 50 Celsius with a hysteresis of 5 Celsius, as I can recall fron the top of my head at the moment. So if DHW drops below 50 C then it starts the charging cycle up to 55 C.

In this case hysteresis = 5K means that the charging starts when the temps drops below 45° (50° - 5K = 45°), the charging usually stops when it reaches 50° then because 50° is the desired comfort temp. It can get a bit higher sometimes if the pump still runs somes time after the WBS stopped, but in general that 'charging process' (= WBS heats up for DHW) already should have stopped then.

The reduced temperature is 40 as I can recall but even during the night the heater doesn't kick in as the temperature in the tank hasn't drops below that level.

Comfort = 50° and reduced = 40° sounds good to me. If the heater doesn't kick in during the night, then it's already positive.

As I was making the DHW accessible from HA, I just looked at the parameters related to DHW and I think the max temperature and the anti-legionela settings are set to 65 Celsius. So the situation might have been that I turned on the DHW and as it has dropped down for a few days to something around 20 the system heated up automatically to the anti-legionela temperature, I don't know, I am just speculating and guessing, but it would make sense.

Hmm, doesn't really make sense to me though ;) It could have happened that you turned 1600 to OFF before and because of that DHW dropped down to 20° - if 1600 was ON all the time and DHW dropped down to 20° your system wouldn't have worked correct as you have the beforementioned hysteresis set to 5K.
You can set anti-legionella to once per week btw. (1640) which is sufficient (no need to run anti-legionella 3 times a week with a 100l storage).

The 20 minutes charging time what I was mentioning is a full cycle charging from around 20 to the desired 50 (55) Celsius, and it is amazing compared to the previous one.

Ah ok, that sounds much better! :)

To be honest, I love this new heater compared to the previous one which one was again a Brötje, but it hasn't had the fine tuning options like this new.

Good to hear that you're happy with it - and now with BSB-LAN at your hand it even get's better! :)

I will definitely check the installation manual, if I have a copy of that. Brötje is not so much generous providing those publicly as I can recall, but I will have a look.

If you need manuals, send me an email, maybe I can help you out with that.. ;)

Just to have a better picture, what my setup. (...)

That sounds good, so for your HC1 you already need higher temperatures and DHW doesn't interfere with a low-temperature system.
You can also check 1630 to make sure that only DHW gets the heat when heating up the DHW storage (setting: '0 = absolute') which often results in a faster process of heating it up as it prevents that the heat from the boiler reaches the HCs during the time of charging the DHW storage tank.
Also 5040 could be interesting for you - there you can enable the function that the DHW pump only starts when the boiler temp already is high enough to charge your DHW storage tank to prevent pulling the heat from the storage when starting the charging cycle.

The only thing what I missed is a temperature sensor on the HC 1 line, the system assumes for HC 1 temperature from the temperature leaving the heater as I can recall, ..

Correct, in most cases there is no sensor for HC1 as it gets the heat directly from the boiler.

.. I could set up the push function as well outside of those times. (I don't know how that works but I believe that's would be use case for that.)

DHW push works that way: if the DHW temp is lower than the comfort temp you can
a) press and hold the button for DHW at the operation/room unit (the button in the top left corner, where you can switch between DHW on/off) or
b) initiate the push using BSB-LAN (see https://1coderookie.github.io/BSB-LPB-LAN_EN/chap06.html#65-triggering-a-manual-dhw-push).
Then the DHW charging cycle should start until the comfort temp is reached. For the first time testing the DHW push, just use the operation unit at the WBS - if the DHW push doesn't work then, check 5070 using BSB-LAN.

Thanks for all the advices again, I really appreciate them! They are really useful!

@fredlcore, @1coderookie - all your work are amazing, what you have made in this piece of hardware and software. Thanks again!

Thanks - we're always happy if it helps people to optimize their system for saving some of that valuable and limited energy resource of our planet..

[GSzabados]

Hmm, doesn't really make sense to me though ;) It could have happened that you turned 1600 to OFF before and because of that DHW dropped down to 20° - if 1600 was ON all the time and DHW dropped down to 20° your system wouldn't have worked correct as you have the beforementioned hysteresis set to 5K.

Yes, the DHW was OFF for about 4-5 days at the time when I turned it to ON, that was the reason of the DHW was at about 20 Celsius. If DHW is ON all the time, then there isn't any situation like this. I haven't looked at this before, so by first glace it was weird heating that high, but I will observe it again once I do the same long OFF and then ON "cycle".

Thanks for all the advices. I really see now how I can improve the DHW setup for more comfortable and affordable settings. I will definitely get back to you once I set it up and tested it.

[GSzabados]

In this case hysteresis = 5K means that the charging starts when the temps drops below 45° (50° - 5K = 45°), the charging usually stops when it reaches 50° then because 50° is the desired comfort temp. It can get a bit higher sometimes if the pump still runs somes time after the WBS stopped, but in general that 'charging process' (= WBS heats up for DHW) already should have stopped then.

Ok, so I looked at things and that's exactly how it is happening. I thought that it heats above 50, to 55, but actually the burner stops at 50, and when the residual heat circulated the tank reaches 55.

Comfort = 50° and reduced = 40° sounds good to me. If the heater doesn't kick in during the night, then it's already positive.

Reduced was 45, but I changed now to 40,even with 45 it was not turning on the heater during the night, but as I mentioned, I adjusted now the schedule as well. Reduced all day long except 2x 4 hours in the morning and the evening.
Thanks for the advises, I think it will be better for lowering consumption.

Regarding anti-legionela, it is set for once a week, Sunday. I am not sure was it Sunday or Monday when I was fiddling with it the first time, so it might have kicked in and heated to 65. So that explains it.

1630 is set to Absolute
5040 is set to Automatic

Managed to use the DHW push as well, both on the panel and from BSB-LAN as well. I will set up a button in the bathroom if for some reason someone wants to have a bath during the day, then the push can be initiated.

And back to your question regarding the ECO function of 1600.

The unit allows BSB-LAN to set ECO, and the display shows that DHW is ON (shows the mark next to the DHW icon), but if I turn OFF and ON on the controller, then it sets 1600 to ON state.
I haven't tried to run the unit with ECO for a longer period to see what does it mean for it, but as you suggested, it should be ON and OFF only, as that is what the controller panel switches between.

[1coderookie]

Thanks for the feedback, I'm glad may suggestions were helpful.

Regarding anti-legionela, it is set for once a week, Sunday. I am not sure was it Sunday or Monday when I was fiddling with it the first time, so it might have kicked in and heated to 65. So that explains it.

It could/would be smart to set the time and date for anti-legionella in a way that you can use the >60° hot water a) during the day and b) at a day which is most likely a day when you'll use the water. In this way you don't waste that energy (heat) by just heating it up and leave it standing still in the storage until the temp drops.
It's just a bit of a finetuning here to miniminze the standstill losses of the DHW storage tank. In this way you can also probably prevent the system to heat up the DHW a second time during the day (e.g. you'll make anti-legionella in the morning and don't really use that much of water, it could be hot enough that the system doesn't kick in to heat up the DHW a second time that day in the evening).

1630 is set to Absolute
5040 is set to Automatic

1630 is good; 5040 would probably better if you'll set it to 'always'. Maybe it doesn't really make a difference or just a little one - within my system it made sense though (but I also have a bigger DHW storage tank, so maybe that effect also kicks in more). You can maybe measure the effect by logging the time of the DHW loading process (but of course then you also have to log the boiler and water temperature etc to get a reliable measurement). But just from my feeling and experience, I'd say set it to absolute.

And back to your question regarding the ECO function of 1600.

The unit allows BSB-LAN to set ECO, and the display shows that DHW is ON (shows the mark next to the DHW icon), but if I turn OFF and ON on the controller, then it sets 1600 to ON state.
I haven't tried to run the unit with ECO for a longer period to see what does it mean for it, but as you suggested, it should be ON and OFF only, as that is what the controller panel switches between.

Yes, that's what I assumed - so ECO isn't available at your system (even though it seems that you can set it to ECO using BSB-LAN because you don't get an error message back). If this ECO option isn't available at the operation unit of your system, then you simply don't have it (which makes sense regarding the notes in the boiler manuals).

Have fun with BSB-LAN and optimizing your system! ;)

[fredlcore]

Great, but it would help us all if you could let us know what the problem was: was it the missing slash? Or something else? As for the exact meaning of 1600, probably @1coderookie knows best.

[GSzabados]

First of all, I was expecting as a status value either a 1 and 0 or On and Off, and not the 1 - On and 0 - Off statuses. So that was the first mistake. I just expected a simplified result, not a mixture of number and text. But with the Eco and some other options it makes sense, except, that I would keep it simple as a number only and use a library to assign the On, Off or Eco when displayed on the web interface. But that is only my thinking. As I know now, it works and good.

So the second was the payload. Usually an MQTT device builds up from different endpoints with /get and /set for different parameters as @torbennehmer suggested in another discussion. I am familiar with that setup but using the payload to access endpoint was no clear, as in your example in the documentation it suggested that the payload should be /S1600=1, but it has turned out that in the MQTT setup of HA it has to be S1600=1 without the first /

The other major issue was from my side that this was the first time that I tried to set up manually a MQTT switch and I haven't had too much experience with the MQTT integration in HA. I have found at the end that part of the integration, where it mentions that there is an option in the Integration page where you can configure the MQTT integration and send manually commands and subscribe to topics. That has helped to solve the status information 1 - On. The other part was pure luck as I've just noticed that I turned on the function with the MQTT command, but the aforementioned option in the integration would have helped me if I would have found it before.

[fredlcore]

Thanks for the detailed feedback - as for the question of including the option as clear text in the response or not, this has been an ongoing discussion for quite a while. The problem is that there is no consistent numbering scheme for these options even for the same parameter across different heating models. Take parameter number 5950 as an example, I think we have four or more different sets of option numbers here where the same number means different things on different heaters. That's why we have to send the clear text meaning as well.

As for the payload with or without slash, does this mean that for general MQTT payloads, you have to use the slash, but for the specific HA integration via MQTT, you don't? Sorry, since I don't use this setup, I can't determine this by myself, but it would be good to have this clear for @1coderookie's documentation.

Thanks!

[torbennehmer]

The leading slash shouldn't be needed anywhere, the code doesn't make a difference and HA just sends the given payload to the topic. That slash is needed as an artifact in the URL Parser of the webinterface - they are completely different protocols and have their own rules there. HTTP uses slashes (and ? and & and such) to separate commands. MQTT uses them in topic identifiers as well, but the message you send to a topic is a separate thing, MQTT clients do not concatenate them, they just post any payload you need to the topic in question. HA is no different from other MQTT clients here.

As for the payload with or without slash, does this mean that for general MQTT payloads, you have to use the slash, but for the specific HA integration via MQTT, you don't? Sorry, since I don't use this setup, I can't determine this by myself, but it would be good to have this clear for @1coderookie's documentation.

@fredlcore I'll check this one final time, but I think the current docs are ambigous/incorrect there, at least the english ones. There should not be any difference between HA's MQTT client and others. GIve me a few days to verify this with my command line tools, then I'll send you an update. That should avoid the confusion, @GSzabados had.

So the second was the payload. Usually an MQTT device builds up from different endpoints with /get and /set for different parameters as @torbennehmer suggested in another discussion.

Yeah, I am working on a new implementation for this - it got delayed by my job unfortunately in the last three months (we had a big project there), but that one is through yet, so I'll be able to continue that implementation over the summer. Right now, think of the MQTT bridge as a separate frontend for what the web server does (with the cavets mentioned above). Works like a breeze in general, it just isn't what you'd expect from a MQTT interface without reading the docs.

First of all, I was expecting as a status value either a 1 and 0 or On and Off, and not the 1 - On and 0 - Off statuses. So that was the first mistake. I just expected a simplified result, not a mixture of number and text. But with the Eco and some other options it makes sense, except, that I would keep it simple as a number only and use a library to assign the On, Off or Eco when displayed on the web interface.

I can understand that, it is strange at that point, one more thing that should go into the docs, I guess. It follows from the MQTT-is-an-alternative-for-HTTP thing. Right now, for anything you do just switch it from the web UI and take the complete command, that the web UI sends to the BSB-LAN and put it into the MQTT topic.

Thanks for the detailed feedback - as for the question of including the option as clear text in the response or not, this has been an ongoing discussion for quite a while. The problem is that there is no consistent numbering scheme for these options even for the same parameter across different heating models. Take parameter number 5950 as an example, I think we have four or more different sets of option numbers here where the same number means different things on different heaters. That's why we have to send the clear text meaning as well.

Yeah, that's often a problem with numeric constants. On the other hand, any automation is specific for a given setup anyway. I wouldn't change anything in the current MQTT implementation, to keep it in line with the web interface along with updated docs to go along with it.

I will give this problem a few thoughts when I'm back on the MQTT code base, we should be able to address this in the extended approach with a deep topic structure. I have to fully understand how the options come together, but there should be a solution even to that one. At least if we say, that the indexes apply only to the current setup.

Honestly, I wouldn't assume that I can transfer any automation to a new heater as-is anyway, give how wide the range of supported devices is. So some adjustment should be expected here.

Greetings, Torben

[fredlcore]

Thanks, @torbennehmer (and I still owe you merging your pull request, but like you, I was/am still caught up in other pressing projects (well, and for now, I'm on vacation ;) ). Once it's clear if there is any need to adjust the manual, please let us know. As for the numeric constants, of course you cannot expect the constants to remaind the same if you switch to a new system, but the alternative would be that you have to manually decode the values to clear text in your home automation system, wouldn't it? And this would potentially affect hundreds of option values (burner status alone has a few dozen). For me, working with FHEM, I can just dissect the return value, and thus use both the numeric value and the clear text for whatever purpose I want. But this may of course be different in other homeautomation systems.

[GSzabados]

@torbennehmer, thanks for the answer and the detailed explanation. I am also looking forward for your future work regarding the MQTT component.
There is another function what I miss a bit, and that is the secure connection. It would be nice to use https (and authentication) on both webserver and MQTT, even if the certificates are self signed. That would give the feeling that no other device can read on the network the traffic unencrypted. And would provide one side less for any harmful actor.

[torbennehmer]

@fredlcore No problem, take your time.

@GSzabados Please file a separate issue for this. The point is very reasonable and I fully agree. However, I have no idea yet about TLS on Arduino, it doesn't have any Certificate Root Chains available, so I will have to spend some time pondering an implementation approach here, that works with the limited resources of the small system. Self-Signed certs are a first approach here, but I'd at least want to consider something more.

@fredlcore Just assign that issue to me, so that we can continue the discussion there.

Best regards, Torben.

[proasnet]

Now I want create an MQTT momentary push button for Push DHW.
What payload parameter for this is actual for v3?
Thanks

[proasnet]

/1603=1
/S1603=1
not working

[torbennehmer]

@proasnet The syntax is simply S1603=1, send it to the configured topic. You basically send the same token as the UI would, but without any slashes etc.
Be aware, that BSBLan of course needs to be configured to give you write access to this parameter. So the usual thing I do is testing the whole thing via the Web UI before moving to MQTT. Once the Web UI gives you the desired results, MQTT should too.

Here is an example from my Home Assistant condfiguration that works:

  - service: mqtt.publish
    data:
      topic: 'BSB-LAN'
      payload: 'S700=3'

[proasnet]

I create a MQTT button

button:
  - name: DHW push
    availability_topic: "BSB-LAN/status"
    command_topic: "BSB-LAN/S1603=1"

But, if I use
bsbip/S1603=1
the web interface does not return any response, nor does the system start heating the water
In the manual, chapter 6.5, it is stated that this function must be enabled according to chapter 2.2.
I don't know exactly what to look for and what to set in BSB to enable it

[proasnet]

http://192.168.0.150/S1603=1
web: ERROR: set failed!

[1coderookie]

First of all, this seems to refer to this issue/discussion here: #513
So it would (have been) smart to list the engaged people here, so that they know that you're writing here.. @Devil-of-Chaos @mirkolenz @tiger42 @GSzabados

@proasnet: In chapter 2.2.1 you see all the possible settings from the webconfig explained. The 3rd one is write access..

[proasnet]

I has ON value

[1coderookie]

@fredlcore Is 1603 still DHW push..?

[fredlcore]

Probably not in his BSB_LAN_custom_defs.h
@proasnet: Does 1603 show up in the DHW category? If not, then it's no wonder that writing fails.
If you need that parameter, either copy it from version 2.2 or use the BSB_LAN_custom_defs.h from 2.2 altogether. But we don't recommend that.

[proasnet]

@fredlcore yestarday morning I sended you my txt file, is implemented?
I have a DHW from your file, what you sended me

[fredlcore]

What do you mean "is it implemented"? I sent you the output file and you are using it. If you haven't understood the new concept yet, please read the manual first.

[proasnet]

1603 I have not in a DHW category.

But my heather system have it. I am using by a QAA70

[1coderookie]

QAA70? I guess/hope you mean QAA75 - QAA70 would be at a LMU64+OCI420 btw...

[proasnet]

Oh, yes. I am sorry. QAA75 is right

[fredlcore]

Yes, your system may have it, but doesn't advertise it in the dump that the heater generates. Then there is no way for me to generate that parameter in the BSB_LAN_custom_defs.h that I create for each user. You can copy the relevant lines from the BSB_LAN_custom_defs.h from version 2.2 or use the BSB_LAN_custom_defs.h from 2.2 alltogether, but as I said, we don't recommend that.
The new system has positive and negative aspects. The positive aspect is that you have all the parameters that your heater advertises, including all the correct options and descriptions. The negative aspect is that you no longer benefit from parameters that other systems support and that your heater (secretly) also supports. But you will never know if it actually works the same way or has any unknown side-effects.
We no longer want to provide a system where this risk exists. But we allow users to take whatever they want from the old system (2.2) and use it in the current version, but at their own risk. But we won't be able to support this.
As for 1603, we're currently thinking of a solution because this (and two or three other) parameter seems to be stored not in the heater but in the room unit / QAA. But as I said, for the moment you only have the options mentioned above, and without any kind of support.

[proasnet]

What specific lines should I copy from the older version?
Could it be from 2.1.8 as well?

[1coderookie]

I don't mean to offend you, so please don't get me wrong now - but
a) first of all @fredlcore wrote v2.2 - so what's the problem in downloading that version?
b) maybe you shouldn't try to add that function from v2.2 to your v3.x now, unless you really know what you're doing - and (no offense!) sorry, but to me it doesn't really seem so right now. So maybe just stay on the safe side: Wait until we come up with an official solution for that and until then just use the DHW push at your QAA75..

[proasnet]

Okay.

[fredlcore]

I second that. Install version 2.2 and stick with that one.

[1coderookie]

..well, actually I'd vote for sticking with the v3.x now and not use the v2.2 instead, but of course it's your decision @proasnet .. As I said, until a solution will be available, just use your QAA75 for DHW push..

[GSzabados]

May I ask, what is your use case with the DHW Push?

And does your controller supports it physically? As I remember the DHW button has to be pressed long and then it does a push for DHW, if it is supported physically.
To be honest, I have never tried on my setup, as I have it in the basement, and haven't figured out why it would be good to do an extra push, unless your reduced temperature is really low, but according your config it is still warm enough for a shower or any normal use. And the nominal would keep the temperature above 55C as your setting there is 60.

And I think your nominal max shouldn't be the same as your nominal temp. But if I am.wrong then @1coderookie will correct me.

[proasnet]

My QAA75 control panel has this feature. It is not activated by long pressing as you write, but it is hidden in the menu. I want to make life easier for my wife because she has to look for it every time. She has HA on her mobile and this is a better solution for her. And I'm sure my system has this feature because I personally always activate it. We try to save energy, so we heat water when we need it. Yes, there can also be a time program, but that is inappropriate at this time.

[1coderookie]

@GSzabados No, you're not wrong :)
The DHW push usually is supported by these types of controllers, so that shouldn't be the problem. He also has a QAA75 which also offers the button&function, that's why I wrote that he should just wait for the official implementation. Imho it doesn't make sense to set up the whole HA system with an older version, knowing that I want to to use the recent version which is safe to use cuz it offers exactly the functionality of that specific controller - but anyway, that wasn't your topic here.
So yes, the usecase of the manual DHW push (cuz there is an automatic DHW push also anyway!) is more like when you set your reduced DHW temperature really low and you only heat up the DHW once or twice a day (which -depending on the amount of water you store in the buffer tank- makes sense) and then you suddenly need a big amount of hot water. Let's say you're sick at home and want to take a bath, but your DHW only is 35° at that time - then you just use the manual DHW push.

[1coderookie]

We try to save energy, so we heat water when we need it. Yes, there can also be a time program, but that is inappropriate at this time.

@proasnet But your screenshot from above doesn't say so: nominal temp = 60° and time program 4 for example (ok, but of course I don't know how you configured the time program).
Note: Depending on the amount of water within your DHW storage tank and the amount of water you guys are using throughout the day, keep in mind that it could be risky not heating up the DHW regularly because of legionella..

[GSzabados]

Note: Depending on the amount of water within your DHW storage tank and the amount of water you guys are using throughout the day, keep in mind that it could be risky not heating up the DHW regularly because of legionella..

That's what I like in the Legionella program. It does it every week disregarding how the DHW tank was used. Mine is set to Sundays, so you can take the opportunity to take a bath on Sunday morning. 😉

Otherwise, if the DHW was off for days and Sunday passed meanwhile, the system heats up the water to Legionella temp when it starts, so the standing water in the DHW tank gets purged.

[1coderookie]

Yes, basically you're right about the legio-prog, but unfortunately it's not (always) that simple. Sometimes it can make sense, sometimes it's a waste of energy. It depends on different factors. But that's too much offtopic here..

[proasnet]

Hello, I would like to ask at this moment if the project can already send DHW push? And if so, is it necessary to have BSB_LAN_custom_defs.h generated again?
Thank you

[proasnet]

Today I updated BSB LAN to 3.0.4 version and very importand is:
All parameters, that hads xxx.00 not working, entities was unavailable. Now must not have sensors decimal zeroes !!!