Danfoss Ally (Popp, Hive) thermostats occupied heating setpoint

[Retr0Joe]

Hello. I have a "problem" with zigbee2mqtt and danfoss ally room thermostats 014G2461. The thermostats support two ways to define the target temperature.

1st option is "occupied_heating_setpoint" which sets the thermostat to the defined temperature and the thermostats should react normally fast. Some people thought, that this can lead to overshoot temperature in a room, but that is highly depending on house and rooms, temperaure losses..

2nd option is "occupied_heating_setpoint_scheduled" which lets the room temperature slowly/smooth react to temperature alterations.

The actual problem is, then when you set climate set temperature from home assistant or locally change at the thermostat, every time "occupied_heating_setpoint_scheduled" will be called. From my understanding, this is not how the thermostat is designed to work. When you look at the device page, every time when you do a temperature change, both values "occupied_heating_setpoint" and "occupied_heating_setpoint_scheduled" will be changed, which cannot be right and could lead to weird behaviours. Only 1 option should be sent to the devices, never both.

I think the solution could be:

• When temperature is set locally at the thermostat, only "occupied heating setpoint" should be called.

• When "Algorithm scale factor" is set to 0, then "occupied heating setpoint" should be called for remote temperature control.
  This needs to be added, actually only values between 1 and 10 are possible.

• When "Algorithm scale factor" is between 1 and 10, then "occupied heating setpoint scheduled" should be called for remote temperature control.

@Koenkk
I am not sure, where or what needs to be changed. Is it possible, that we change this for testing? I could test these changes and report back then. You can also see, that the thermostats report "Setpoint change source" back, when you change the temperature remotely, localy (maualy) or scheduled,

When you look at forums, many people have problems with the temperature control of these devices. I added some photos where you see, how slow these valves are reacting. The "learning" adapation run was finished, that isnt the problem.

I found many topics, where some people had nearly similar problems. At once, see:

#12606
#15256
#19495
Koenkk/zigbee-herdsman-converters#4734

[Retr0Joe]

AM375549618098en-000103.pdf

AU417130778872en-000101.pdf

[robertalexa]

My 2 cents on this, whatever the outcome of this will be, please take into consideration the first paragraph of my very old comment Koenkk/zigbee-herdsman-converters#4734 (comment)

The slow valve opening used to be the default in multiple implementations, and everyone hated it. Just dont change it so that the default is slow again. If algorithm factor gets taken into account for what command should be called, remember to document the behaviour and correlation.

Also happy to contribute to testing should time allow me. I still have the hive trvs as daily drivers.

[surrealo]

hmm, I'm confused, I thought you could choose what you want to use, either 'Occupied heating setpoint' or 'Occupied heating setpoint scheduled' . The two values will sync ( Koenkk/zigbee-herdsman-converters#4734 (comment)). If you physically change the temperature on the TRV it's always more aggressive. Personally I prefer having the choice to select what I want to do.

I've only ever seen 'Setpoint change source' reported as externally or manual.

I think the main problem is the basic understanding of when to do remote temperature updates, I posted this recently and that interpretation seems to work https://community.home-assistant.io/t/danfoss-ally-trv-working-with-remote-temp-sensor/276686/192?u=surreallo

[robertalexa]

Sorry didn't mean to make it more confusing than it already is. Indeed the behaviour is separate just as you have described and i do not have an issue with it.

My point is only that no "breaking change' is introduced as to what is the default behaviour. E.g. swapping behaviour around, or linking the algorithm factor into the aggressive setpoint changing how it naturally behaves. As that would mess with a lot of people's existing setups.

Apart from that i am happy to assist if needed and test for anyone that will try to improve the behaviour.

[surrealo]

yeah I would be very unhappy if suddenly the default behaviour changed :)

[0x0013]

I think this is due to both setpoint attributes reading the setpoint value reported from the TRV. There is only one value on the TRV, it just gets set with a different parameter, depending on which approach is called. So it makes sense that the value gets updated on both - same as it gets updated if you physically turn the valve, even though you didn't set any of the attributes through zigbee.

However, I think this is just the reported value - I don't think that updating of the attribute current reported value actually sends the changed value back via a SET command.

[Retr0Joe]

Well, it seems that some people have different interpretations how this should work. Actually it is not right how it is. It is not okay, when i remotely set the temperature, that "occupied_heating_setpoint" and "occupied_heating_setpoint_scheduled" will be set. They should not be synced. This is wrong. There are maybe more possibilities to change this. But we should discuss this. Only because of "i dont want a breaking change", we shouldnt let it wrong.

When i send occupied_heating_setpoint via automation, it every time uses: "occupied_heating_setpoint_scheduled".

glad-wolf described it it right. We need both possibilities, aggressive and non aggressive.
Koenkk/zigbee-herdsman-converters#4734 (comment)

Look at 0x0201 0x40 Setpoint Command:
Setpoint command sends: setpointType
(enum8) + HeatingSetpoint (16bit)
if setpointType = 1 the actuator will make a
large movement to minimize reaction time to UI.
If setpointType = 0 the behavior will be the
same as setting the attribute "Occupied Heating
Setpoint" to the same value.
if setpointType = 2 displayed setpoint is not
effected but regulated setpoint will change. can
be used for Forecast functionality

So, maybe we need a "switch" to change between "occupied_heating_setpoint" and "occupied_heating_setpoint_scheduled" which could be set at the gui and via a custom command.

There are more wrong things at the basic configuration:
The initial state of "Adaptation run control" should be "none". It does not make sense, that it is set to "initiate_adaption". Because when you mount a new thermostat or reset it, it has no saved valve response. You then should set it to "initiate_adaption" when state is like this: {{ trigger.payload_json.adaptation_run_status == 'none' or trigger.payload_json.adaptation_run_status == 'lost' }}. When state is "found", it should reset to "none" When state is "initiate_adaption" you should be able to set it to "cancel_adaption".

[surrealo]

So, maybe we need a "switch" to change between "occupied_heating_setpoint" and "occupied_heating_setpoint_scheduled" which could be set at the gui and via a custom command.

maybe, however if it needs to be sent within the same payload for it to work I don't know how that would be done since it doesn't seem to be a stored value. occupied_heating_setpoint and occupied_heating_setpoint_scheduled is essentially that 'switch'.

The initial state of "Adaptation run control" should be "none". It does not make sense, that it is set to "initiate_adaption".

it is set to none, I just reset 8 TRVs (after firmware upgrade because of the firmware version bug) and all of them are set to none.

IMHO zigbe2qtt should just report and set the values and not have any logic. If you want logic that's what automations are for. I don't know if the TRVs report back the value of the Adaptation run control. If they do then maybe that's something that could be added.

[robertalexa]

Ok let me make one final intervention and then i will stay out of the conversation, as it seems you took my comment very personal.

I invite to have a look at all the dafoss ally, popp trv and hive trv in z2m and understand how back i go with this device. And i did simply from frustration of initial incomplete implementations.

A few years ago the default has a slow valve actuation and almost none of the current features implemented. The devices reported temperature and thats pretty much it. I, with the help of @sjorge, @Koen and various other members of the community expanded the featureset. By a significant amount. The first and most important thing i changef was the valve to aggressive, just like it happens when you manually set the temp on yhe device. That should be the default. Always, no matter what people want to think of it. Input sth output sth. Anything in between should not be the responsibility of the controller, but rather the automation logic.

Later on there was a PR introducing an extra property for people that prefer to use the slow valve. This is how this second thing came into existance. It is a replica of the default behaviour, with one bit different. I have left the same feedback there. If you experience overshooting it means you failed you learn how the device works with your radiator, your boiler, your house, the external temp, and failed to account for that in your rules for setting the temperature. Of course this is oversimplified, and i am trully open to learning more about this and maybe even change my own automations to make use of it. Since then, nobody came back to me comments with any feedback.

I have not investigated the issue you have described, so i do not have any remarks over are you right or wrong. My only remark is as follows. However this PR improves the controller, it should not change the current default behaviour. An aggressive valve turn just like manually controlling the valve. The reasoning is that if i want to automate, i want to be able to have predictable and replicable behaviour. The slow valve turning doesnt offer that. Proven by my findings as well as tens of other people saying the same all over the net.

Ps. Do not take this personally, i never intended to write an essay and go 2 - 3 years into the past. All the best

[surrealo]

I for one am definitely very grateful for all the time and effort put into development :). thanks robertalexa and all the others involved! :)

[Retr0Joe]

Hello @robertalexa. I think there are some misinterpretations in here. Let me explain. First of all, i like the work and effort that people who own these devices spent into this project. I own 20 of the devices since november 2022. I started to buy popp ones and sold them later to replace them with the danfoss ones. The reason was, that i wanted to use these also with the danfoss ally app, which is not possible with the rebranded ones. This time i also started with home assistant and zha. Later i changed the coordinator and switched to zigbee2mqtt. At the beginning, i was also very unhappy how these devices react to setpoint changes. Then i tried "better_thermostat", but that was also a fail. Then i found the zigbee specifications and the feature catalgue of these valves and tried to read, understand and change options within zigbee2mqtt.

Believe me, that i tested a lot with these devices and my environment to let them work how they should and i know how gas boilers work. Maybe my first post was not clear enough, maybe i just missed something, that is not well documented. Let my try to explain again.

There are two ways to set the temperature:

aggressive mode:
When temperature is set locally at the thermostat, "occupied heating setpoint" will be locally set and readed from zigbee.

When temperature is set remotely "occupied heating setpoint" and "which function" are set?

non aggressive mode:
When temperature is set remotely "occupied heating setpoint scheduled" and "which function" are set?

Actually, every time when i change the temperature remotely via home assistant, i see "occupied heating setpoint scheduled". This leads to very slow temperature response/valve opening. I cannot find any function, where i can switch between these modes. It does not make any difference if i send, "climate set temperature" or "occupied heating setpoint" to xx degrees. Every time "occupied heating setpoint scheduled" will be sent, and shown in the logs.

Second thing is, if these values are synced and only ""occupied heating setpoint schedule" is shown at the logs, how can people know which mode is working? As is said, maybe i missed something. Where or what is the option, to change between these two modes?

And my 2 cents is also, that the valve reaction by remotely set temperature should be the same, as when it is locally set at the thermostat. But actually it is not at my environment.

[robertalexa]

Ok. In that case, that is worrysome. To my understanding, the regular setpoint should have been bound to the HA thermostat behaviour. While the scheduled setpoint would have been something that people manually called if they preferred that behaviour.

Your comment suggests that is not the case. And if it is not, then that is indeed a big problem. I am currently undergoing renovations in the house, but will do my best to check things at my end asap, as if ehat you are saying is true, then everyones trvs are slow by default.

Thank you kindly for your comment and clarifications, ive never intended to step on your toes.

Will let you know what i find asap.

Ps. I think in principle it is possible to see the raw command if herdsman is in debug mode, but i dont remember for sure

[Retr0Joe]

Hello robert, thank you for your fast reply. I also did not to intend, to step onto someones toes. I just like to understand how things work like they are specified from a manufacturer. Sometimes, things are not clearly defined and let room for interpretations. Some of the modes and functions of these danfoss device are not very well documented by danfoss. These devices are very powerful, if they will be used correctly. I wonder, why danfoss does not look from time to time to official forums, github or something like this. If they would support the community more, that would lead to more recommendations from peoples to buy these products.

An example about boiler configurations. Actually, we have two options to communicate with boilers (heat pumps etc.) and our danfoss valves.

1st) You own a gas boiler. The gas boilers has a physical connection and you own at once Danfoss Ally Boiler-Relay which is physically attached to your boiler and it can be set on and of with these relay (or another external switch, which you can set via zigbee or wifi). The valves have the states "heat required" and "idle". You can now make an automation, lets say, if 3 of 15 radiators call for heat required, then set the relay and the boiler can heat.

2nd) This is the one that i use. You own a gas boiler. Depending on the thermal needs of your house and the minimum power that the heater can give, it goes on and off. Because when it gets warm outside, the thermal needs will be lower and the heater begins to cycle. I now have an automation, which sends "heat_available" true to all valves if the heater is on and false if the heater is off. I am not sure, if that has influence on the PID algorithm of the danfoss valve.

3rd) You have external heat and no influence to set the heater on and off. Default is "heat_available" true.

There are many things that could be done with these valves, i really like them. I try to understand now, how i can send not yet implemented commands directly to the valves and document these via trial and error.

AI459141322073en-000102.pdf

[Retr0Joe]

Whatever or however i set temperature, this is the outcome.

[robertalexa]

As this is exposed in HA that is expected behaviour. Both setpoints are expoaed to HA by default. The aggresive entity should be connected to the climate entity though while the slow valve ia the one in your screenshot. Whichever value you change, will change both by design. If you do not use the slow valve, you can disable it in HA. If you do not use the aggressive one, you might be able to replace it with the slow. I havent personally tried so i do not know if the best approach would be via z2m or ha.

With regards to your other comment, i went down that route too, there are a lot of features that the trv can do, or at least provide to you so you can make decisions. I personally didn't make use of a lot of things. In my personal setup i have hive trv (same device as danfoss ally but with custom incomplete huve firmware) and the hive boiler controller with a thermostat. I then rely on the thermostat to dictate the main temp in the middle of the house and make other decisions on a per room basis by temperature only. I have not yet configured any "boost" behaviour where the main thermostat increases a bit because the rads need more. In fact, this is exactly why i stopped using hive software and did it my way in z2m.

I found out the hard way that you end up in pretty much a permanent boost, because rooms will start cooling down. The more rooms, the more chances rooms will demand heating.

I will have a look at z2m and ha logs as soon as i can

[surrealo]

Actually, every time when i change the temperature remotely via home assistant, i see "occupied heating setpoint scheduled". This leads to very slow temperature response/valve opening. I cannot find any function, where i can switch between these modes. It does not make any difference if i send, "climate set temperature" or "occupied heating setpoint" to xx degrees. Every time "occupied heating setpoint scheduled" will be sent, and shown in the logs.

that's strange, I just changed the setpoint via the HA climate card (or whatever it's called) and I still just see externally

maybe its because I have this set?

out of curiosity I checked the zigbee2mqtt logs regardless of how I change, through HA or the zigbee2mqtt it seems both values get sent over in the payload ( "occupied_heating_setpoint": 19.5, "occupied_heating_setpoint_scheduled": 19.5, ).

hehehe now I'm confused again ;)

@robertalexa , if you want some logs or tests or something, let me know

[surrealo]

this might be a silly question, are you on the latest firmware? does the version show up in the OTA tab or a string of chars like AABBBCCCD? in which case you might want to check out this thread #11049

[Retr0Joe]

Yes, i am at the latest firmware. I updated 15 thermostats to version "00.28.0008 00.28". Problem was also before updating.

[surrealo]

i suppose you meat "01.28.0008 01.28" :)

[Retr0Joe]

That depends on the hardware-version of your thermostats, i have two versions, both are nearly the same. They just actualized some hardware chip.

[Retr0Joe]

Now i tried to set the entity off, but seems not to be allowed via service-call.

description: ""
trigger: []
condition: []
action:

• service: homeassistant.turn_off
  metadata: {}
  data: {}
  target:
  entity_id: number.tcv_buero_occupied_heating_setpoint_scheduled

[Retr0Joe]

Okay, i think, i found the problem. It seems, that i do not have the entities "occupied_heating_setpoint". I dont know why, but all of my thermostats only have the entity "occupied_heating_setpoint_scheduled". Now it is clear, that only this can be called. The question is, why is it like this? I am very sure, when i bought my first popp thermostats, that i had the entity "occupied_heating_setpoint".

Very strange. Deleting and repairing them does not change anything.

[Retr0Joe]

Now i stopped z2m and renamed all entities at "core.entity_registry" and reboot home assistant os. We will see if that helps.

Edit:
It does not work. Something must have changed. The entities do not exist. I renamed all from "occupied_heating_setpoint_scheduled" to occupied_heating_setpoint and also the descriptions. See below.

[robertalexa]

The clue is simple. Set your valve to 8 degrees. If you hear a lot of noise, that is aggressive. If you hear one single click its slow. Then do thr opposite and set them to 30.

Stop looking for aggressive setpoint. It is already attached to the climate entity.
https://github.com/Koenkk/zigbee-herdsman-converters/blob/f7cb1f160f07fcca7a354429cad9d63c7272ea85/src/devices/danfoss.ts#L60

And because it is bound to climate, and the majority of people will use yhe default climate, that is the default behaviour.

The scheduled entity is extra, not bound to climate, for advanced users that want to make their own climate, and enabled by default. But not being sent to the device unless done by the user. However. It receives updates from z2m to match the climate temperature identically.

https://github.com/Koenkk/zigbee-herdsman-converters/blob/f7cb1f160f07fcca7a354429cad9d63c7272ea85/src/devices/danfoss.ts#L62

With all of this clarified, and now that i looked at the current code, none if this is an issue. Everything works as per intended implementation.

[Retr0Joe]

Thank you for the clarification. The question is now. Must the "occupied_heating_setpoint_scheduled"-entity be disabled or not? I did not really get it, sorry.

From what i see now, it doesnt matter if the "occupied_heating_setpoint_scheduled"entity is enabled? You have to actively set a topic like this for slow response?

service: mqtt.publish
data_template:
topic: zigbee2mqtt/{{ "[TCV] Buero" }}/set/occupied_heating_setpoint_scheduled
payload: 20

[robertalexa]

If you intend to use the aggresive behaviour, disable it (although it does no harm having it enabled. in my case, i disabled all of the entities i do not use to save on database writes in HA).

If you intend to use the slow behaviour, look into Generic Thermostats. creat yourself a custom one consisting of the entities required. Then you can disable the climate one provided on the device. You do not need to do service mqtt.publish. You simply set the value on occupied_heating_setpoint_scheduled and everyhting is handled by HA -> MQTT -> Z2M

[Retr0Joe]

Thank you! Problem solved.

[robertalexa]

You are welcome :)

[ooglyhLL]

1st) You own a gas boiler. The gas boilers has a physical connection and you own at once Danfoss Ally Boiler-Relay which is physically attached to your boiler and it can be set on and of with these relay (or another external switch, which you can set via zigbee or wifi). The valves have the states "heat required" and "idle". You can now make an automation, lets say, if 3 of 15 radiators call for heat required, then set the relay and the boiler can heat.

This is what I had implemented with my previous TRV, based on valve position for lack of other parameters. Worked reasonably well. With my new Popp TRVs, I am a bit clueless what “heat required” relates to. All rooms above setpoint, all valves at 0, or 1%, yet “heat required” flips to 1 for no apparent reason. Any ideas?

[Miclot-mth]

It seems that the "heat required" state is related to the "Heat available" command and the "Heating System Mode" parameter (defaults to auto mode).
But I don't understand the interaction of all this.