TRV Danfoss ally

[zhapwey]

hello:

I have a danfoss trv by zigbee protocol.
I have seen that it is very similar to that of hive (the one that I do not have to test). What happens to me is that it does not accept system_mode: off only accepts heat.

The problem is that if I use the manual TRV (playing with the hand) it works fine, but if I write the command to it by zigbee it seems that it does not eliminate the calculations of its algorithm for the previous command and it does very strange things.

I am trying to create a converter to tell open window and that the trv turns off but I am not able, I have this info:

but I am unable to find it, if someone can give me a hand I would appreciate it.

thanks

From what I have seen in deconz that he has supported it, it has things that are not standard, that are his own, if someone guides me I would be happy to do tests with it.

[zhapwey]

I've been looking because I'd love to understand how this is done.
Could be:

1.In /opt/zigbee2mqtt/node_modules/zigbee-herdsman/dist/zcl/definition/cluster.js edit the cluster hvacThermostat
and add a line for each new attribute to create. For example for:

MountingModeActive: { ID: 0x4013, type: dataType_1.default.boolean },

2.In /opt/zigbee/node_modules/zigbee-herdsman-converters/converters/toZigbee.js create a converter for this attribute(
This I don't quite understand how to do it). For example:
thermostat_MountingModeActive: {
key: ['MountingModeActive'],
convertSet: async (entity, key, value, meta) => {
const MountingModeActive = value;
await entity.write('hvacThermostat', {MountingModeActive});
return {state: {MountingModeActive: value}};
},
convertGet: async (entity, key, meta) => {
await entity.read('hvacThermostat', ['MountingModeActive']);
return {state: {MountingModeActive: value}};
},
},
3. In devices.js add in toZigbee devices tz.MountingModeActive

Does something I think make sense or am I very lost ???

Thanks,

[brozikcz]

Hi,

thank you for your investigation. Do you have any progress? :)

[zhapwey]

I am not afraid that for this trv to work well, it is necessary to use commands that I am not clear about how they work, without the help of people who know I am not sure how to continue, sorry.

[sjorge]

Did you get a list of the zigbee attribtutes it supports? If so we can probably work on this, if not it's guess work which is difficult without a testing unit.

[zhapwey]

hello @sjorge:
If I think I have the updated mapping
Danfoss trv.xlsx

I have already achieved that it is quite similar to hive's trv, write and read practically everything to it, the problem is that to write the setpoint, if you write directly through the OccupiedHeating Setpoint attribute, the trv takes a long time to answer, the correct way to do it seems to be through the command 0x40 giving it the command and the exchange rate of the same to make it faster or slower, but I am unable.

And my other problem is that I cannot read or write in the attributes that start with 0x4XXX, to add the open window functionality or external measured room...

I am at your disposal for any test that I can do with it, and regarding a test unit, I have no problem sending mine to someone if you are interested in working with it. Because I think that this trv is of quite a quality and quite reliable, if it worked well I would surely mount it at home, the rest of the options that we have not quite convinced me at all

best regards,

[sjorge]

Ah you've been reverse engineering by writing to it! Impressive.

Perhaps if there are custom attributes involved we need to set the manufacturing specific options, which requires a change to zigbee-herdsman to teach it about them I think.

[zhapwey]

If I have achieved something but I am blocked with the issue of the command 0x40, which also the valve reports it, that is.
If you change the setpoint from zigbee z2m/0x14b457fffeb6915c {"linkquality":123,"occupied_heating_setpoint":24.5,"setpoint_change_source":2}

If you manually change the setpoint (from the valve) z2m/0x14b457fffeb6915c {"linkquality":123,"occupied_heating_setpoint":22.5,"setpoint_change_source":0}

The manual change is done instantly and the one you do by zigbee takes a long time to react.

If you see possibilities to make it work I am at your disposal, do you think we can try to do something with it?

Best regards,

[Zeddy-]

Hi,

just wanted to jump in here as i am struggling with exactly the same thing. I have not seen any other device implement COMMANDS. just reading and writing attributes.

[zhapwey]

hi:
We continue at the same point, I do not know if there is no one who can give us a hand or this would be more to make a query in converts rather than in z2m, but I do not have the knowledge to advance here.

I have tried to write the commandtype setpoint separately and it won't let me, it tells me the attribute is read-only. So it seems that the only way to make the TRV work correctly is through that command.

Best Regards,

[GrahanF]

Hi Guys.

Just joined github as I came across this thread when I was looking for information on problems with changing setpoints on the Hive trv and I have information that may be pertinent to your issues.

I have just recently purchased 10 Hive trvs and they are intermittently failing to update their setpoint on a schedule change in the hive app. They can be updated manually within the app or by turning the wheel on the valve. Control always appears to follow the setpoint displayed on the valve. Hive firmware is V 21B. I am unaware of how much of the firmware is shared with the Danfoss variant and whether it too has this issue. Both appear to share some but not all features, however there is very little info out there. Tech support have been in denial for a month. The new firmware was pushed out on 23 September and was intended to cure a problem with slow response to heating demand.

As you guys are clearly interfacing with the valves at a level that is far more informed than mere "users", any insight you can share that might help to define the problem would be gratefully received,

The failure mode is unknown - random and intermittent but pointing perhaps to some internal memory corruption rather than a failure of comms or an issue with control logic.

The issue is causing major frustration within the Hive user community.

I hope this information is helpful and apologies if, through ignorance, I have breached protocols by interjecting in this conversation.

Regards.

Graham

Graham

[Zeddy-]

We updated the Ally with the latest firmware and so far what we noticed is external open window works, and setpoint seems to actually move the valve pretty fast. Open window closes the valve within 30 seconds, which is decent. But i think the main issue is that the internal PID is the reason why these are so slow.

But something i still find absolutely amazing is how zigbee commands are never talked about, anywhere? Have i misunderstood them or something? Why doesn't zigbee2mqtt have a single custom command integrated?

[sjorge]

Why doesn't zigbee2mqtt have a single custom command integrated?

Because the manufacturing specific cluster stuff is defined in zigbee-herdsman and they are used in zigzagged-herdsman-convertors?

e.g. https://github.com/Koenkk/zigbee-herdsman/blob/60418017ea739a7c0d96aca2814d82e79de01901/src/zcl/definition/cluster.ts#L446 which is then used here https://github.com/Koenkk/zigbee-herdsman-converters/blob/84b47e269be2fc50653854234fb970f7dc8c8f7d/converters/toZigbee.js#L3728

[AlexThePotter]

I get a similar issue with Hive TRV001.

If I use it manually, it reacts instantly. If I change set point over z2m the setpoint is changed - the screen shows new setpoint, but the device never changes the opened amount of the TRV. even if massively different to the current temp.

[zhapwey]

hello:

I did some tests but my knowledge of this is very limited, in fact that is why I asked for help but for now we have had no luck. In case they help someone

Try creating a command looking at setpoint_raise_lower.
In nano /opt/z2m/node_modules/zigbee-herdsman/dist/zcl/definition/cluster.js
setpointCommand: {
ID: 64,
parameters: [
{ name: 'setpointType', type: dataType_1.default.enum8 },
{ name: 'HeatingSetpoint', type: dataType_1.default.int16 },
],
},
And tozigbee.js:
thermostat_setpointCommand: {
key: ['setpointCommand'],
convertSet: async (entity, key, value, meta) => {
const payload = {setpointType: value.setpointType, HeatingSetpoint: Math.round(value.HeatingSetpoint)};
await entity.command('hvacThermostat', 'setpointCommand', payload, getOptions(meta.mapped, entity));
return {readAfterWriteTime: 250, setpoint: {setpointcommand: value}};
},
},

Call the converter from the device.js like this:

mosquitto_pub -t 'z2m/0x14b457fffeb6915c/set' -m '{"occupied_heating_setpoint":20,"Setpoint_Change_Source":1}'

And it does not give me a command error in the debug but it does not change the command either.

I have been confirmed from various sources that these trv, danfoss, viessman, hive (it is the same valve) change the setpoint differently if you change from the command with the setpoint_change_source to one value or another, and by default without writing there is very very slow

I have the specifications of the command but I don't know how to work in case they are worth it to someone:

I have stuck with her and I have not achieved anything, good luck for those who try.

If someone wants to do some test, happy to help you.
BR

[ma-zal]

For this issue I opened topic Danfoss Ally: Slow actuator response in Community HA. I hope other people will add experiences and knowledge, which it helps to solve the issue.

[randomuser389]

hello:

I did some tests but my knowledge of this is very limited, in fact that is why I asked for help but for now we have had no luck. In case they help someone

Try creating a command looking at setpoint_raise_lower.
In nano /opt/z2m/node_modules/zigbee-herdsman/dist/zcl/definition/cluster.js
setpointCommand: {
ID: 64,
parameters: [
{ name: 'setpointType', type: dataType_1.default.enum8 },
{ name: 'HeatingSetpoint', type: dataType_1.default.int16 },
],
},
And tozigbee.js:
thermostat_setpointCommand: {
key: ['setpointCommand'],
convertSet: async (entity, key, value, meta) => {
const payload = {setpointType: value.setpointType, HeatingSetpoint: Math.round(value.HeatingSetpoint)};
await entity.command('hvacThermostat', 'setpointCommand', payload, getOptions(meta.mapped, entity));
return {readAfterWriteTime: 250, setpoint: {setpointcommand: value}};
},
},

Call the converter from the device.js like this:

mosquitto_pub -t 'z2m/0x14b457fffeb6915c/set' -m '{"occupied_heating_setpoint":20,"Setpoint_Change_Source":1}'

And it does not give me a command error in the debug but it does not change the command either.

I have been confirmed from various sources that these trv, danfoss, viessman, hive (it is the same valve) change the setpoint differently if you change from the command with the setpoint_change_source to one value or another, and by default without writing there is very very slow

I have the specifications of the command but I don't know how to work in case they are worth it to someone:

I have stuck with her and I have not achieved anything, good luck for those who try.

If someone wants to do some test, happy to help you.
BR

note that the setpoint command is a danfoss manufacturer specific command so manufacturer needs to be set at 0x1246 in the command and the flag that indicate manufactuer needs to set true.

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days

[gielfeldt]

I think the payload published to mqtt need to be:

{
  "setpointCommand": {
     "setpointType": 1,
     "HeatingSetpoint": 20
  }
}

And the "thermostat_setpointCommand" need to be added to devices.js for the device in question.

If I'm reading the code right. Which I'll admit, I'm not sure I am :-)

[marcinkowalczyk]

Seems this issue has been fixed in Deconz, ia there a way to get it fixed here too?

[robertalexa]

For everyone interested in that command, plus a lot more features, keep an eye on the PR Koenkk/zigbee-herdsman-converters#2592

This handles a lot of features. This is what I've managed to get.

Rob

LE: sorry, just to clarify. Setting the temperature will now change the pi_heating_demand instantly, just like physically turning the termistat does, instead of passing it to the PID and taking even a couple of hours to happen.

I understand the point of the PID, but I am not sure it can be trusted when you want to automate things yourself. If you leave this to the PID, you might never have the expected temperatures at the times of your schedule

[zhapwey]

hello:

Great news, congratulations and great work!!!
I have tried to test your set_point but it has been impossible I add the converter in tozigbee.js and in devices the tozigbee but it give.s me an error, I will have to wait for the PR.

zigbee2mqtt/0x14b457fffebada95/set {"occupied_heating_setpoint":"24"}
zigbee2mqtt/bridge/logging {"level":"error","message":"Publish 'set' 'occupied_heating_setpoint' to '0x14b457fffebada95' failed: 'Error: Cluster 'hvacThermostat' has no command 'danfossSetpointCommand''"}
zigbee2mqtt/bridge/log {"message":"Publish 'set' 'occupied_heating_setpoint' to '0x14b457fffebada95' failed: 'Error: Cluster 'hvacThermostat' has no command 'danfossSetpointCommand''","meta":{"friendly_name":"0x14b457fffebada95"},"type":"zigbee_publish_error"}

I think I need to include something but I don't know what it is.

Best Regards,

[robertalexa]

@zhapwey

You are missing some code for zigbee-herdsman module.

The easiest way to get this is to run your tests on zigbee2mqtt dev branch (this will include the latest version of zigbee-herdsman with the danfossSetpointCommand).

So:
1: checkout zigbee2mqtt to dev branch
2: replace your danfoss.js with the on in PR
3. replace toZigbee.js
4. replace fromZigbee.js
5. test

Would you be kind to help me with some info about the Danfoss Ally? I do not have this device but I am trying to support it properly. Could you please tell me when you physically turn the temperature on the TRV, what is the range that the device allows? Is it 6 to 28 degrees Celsius or 5 to 32?

Thanks

[sjorge]

Would you be kind to help me with some info about the Danfoss Ally? I do not have this device but I am trying to support it properly. Could you please tell me when you physically turn the temperature on the TRV, what is the range that the device allows? Is it 6 to 28 degrees Celsius or 5 to 32?

It might be possible to query AbsMin/Max from the attributes, they are marked optional but I believe the viessmann had those, so there is a high chance the Danfoss and Hive have them too.

[robertalexa]

@sjorge I know them for Hive TRV, but because it uses a different firmware to Danfoss I just want to double check.

The original Danfoss code was set to 6 to 28 degrees and my Hive TRV physically goes 5 to 32. So I have corrected the code for Hive to the latter.

If Danfoss is the same, then I will change the code for Danfoss Ally as part of my PR.

Rob

[zhapwey]

good:
thanks a lot tomorrow i try your pr. Well, I have 3 units, two came to 6-28 and another to 5-35. Another issue that I have seen in these valves is that the first days they open at an hour and close, it seems that they are looking for the opening point of the valve or something like that, suddenly they stop doing it. It has happened to yours, I tell you after a reset or at the beginning, it seems that they have some register that puts them in regulation mode for this. regards,

[robertalexa]

Hi @ipeacocks I have never tried other TRVs, so i can't make a good comparison, but what i can say is that i have never been dissappointed by my 8 Hive TRVs (undercover Danfoss Ally). So i personally holehartedly recommend them.

• Is it possible to turn it off? I can't see such option in zigbee2mqtt. How to turn it off for summer?

Set the temperature to a low value, like 9C for example. So you end up with sth that looks like this:

• Is it possible to output pi_heating_demand value (valve position). I like to see how often it tries to open/close valve.

It is as of the latest release of z2m (today, 1st of December) #9759

Hope this helps :)

[ipeacocks]

Set the temperature to a low value, like 9C for example

It's just not very logical as for me. But not critical in general. As I understood it's more vendor-specific thing.

It is as of the latest release of z2m (today, 1st of December) #9759

Nice. Now I am fully happy.

[robertalexa]

It's just not very logical as for me. But not critical in general. As I understood it's more vendor-specific thing.

Unfortunately there is no better way. And this is not a limitation of z2m, but rather the device itself. Other thermostats will have an off system_mode. The Danfoss only has heat (on) and nothing else.

And from the device specs https://assets.danfoss.com/documents/176987/AM375549618098en-000101.pdf

So i guess we have to make it work with what we've got :)

This is what I am doing in my setup and automations and I have personally not had any issues because of it (or weird quirks). :)

[rindlerblabla]

Another question regarding the external temperature sensor. Would it be possible to bind the external sensor somehow directly to the thermostat without sending those values from eg Home Assistant? Does zigbee in general support these kind of bindings?

[robertalexa]

Based on the specifications of the thermostat, my guess would be that it is not possible. The specs mention that the gateway should / will be sending the relevant information at certain time intervals and temperature differences. So based on that logic, a direct binding will not do the same.

As to the actual binding (based on my understanding of binding), that would not be possible. In binding you need 2 devices to communicate "about" the same cluster and attributes. A temperature sensor will not talk about the climate cluster, and a very specific attribute (which in this case is a danfoss specific one). Hopefully I am not misunderstanding it so that i am misinforming you.

Hope this helps

[kennylevinsen]

@robertalexa thank you very much for your work. Previously I've bought one Moes HY368 TRV. It's quite strange thermostat, it works but very inertial and opens valve very slow even when temperature is 4 C less than target one.

Danfoss uses a custom command for quick response, otherwise doing very slow response. Maybe it's the same for Moes?

[ipeacocks]

Unfortunately there is no better way. And this is not a limitation of z2m, but rather the device itself. Other thermostats will have an off system_mode. The Danfoss only has heat (on) and nothing else.

@robertalexa I am not blaming you of course. Just wished to ask that directly. I've more or less suspected that it's the nature of this valve. Just shared that it's a bit strange. Thank you for you integration because so far I am very happy with this valve.

[robertalexa]

@ipeacocks nothing to thanks me for :) and I am not the only one that worked on this. @sjorge is the main hero for supporting this device at first, and a few other people that added more features throughout time. Happy to help

[ipeacocks]

Another question regarding the external temperature sensor. Would it be possible to bind the external sensor somehow directly to the thermostat without sending those values from eg Home Assistant? Does zigbee in general support these kind of bindings?

@rindlerblabla I haven't heard that any TRV can do that. Some people just making hacks for making this but those hacks are quite bad.

For example with Moes HY368 TRV you can force valve to fully open and close. So it's possible to make generic thermostat in HA with this switch where you can use external temp sensor. But batteries probably won't live long.
Second technic of bypassing this problem is dynamically set temperature calibration (temp correction) to valve. Moes HY368 TRV have special field for that. I think it's also bad because of batteries life.

[ipeacocks]

Danfoss uses a custom command for quick response, otherwise doing very slow response. Maybe it's the same for Moes?

Not sure that you got me correct, let me provide an example. Suppose my target temp is 25 C but current temp in room is 18 C. I think in this situation (temp delta is huge) it's more logical to fully open valve (100%) and only then gradually close it. But it gradually opens (10% per 15 mins) valve even with such temp delta. That's why it's very inert and I am sitting in cold room 1h or so.

It's very popular valve as I can see at least in eastern Europe. That's why I think that's all possible features.

[robertalexa]

That is exactly the default behaviour of the Danfoss. The explanation is that alongside the temperature setting you can send an extra bit of information to define who requested that change (manual by turning the trv, PID- internal or schedule). A while ago i have made a change to the z2m code so that when setting the temperature it acts as a manual change, which means an instant reaction from the TRV. Otherwise, the reaction is very slow and processed by the PID. And yes, it was taking hours to fully open before.

However I am not familiar with the Moes TRVs so i can't say that the same is achievable with them. I think this is what Kenny was trying to say

[ipeacocks]

@robertalexa are you talking about this option for Danfoss?

How quick valve should react on big target temperature change? For me it seems 30 seconds or so.

[robertalexa]

No, just hidden in code.

This is the spec:

Found here:
https://github.com/Koenkk/zigbee-herdsman-converters/blob/1799f367ff90c7dbd66bfed4f5b2e91568ecc6c9/converters/toZigbee.js#L2425

The one you mentioned i think is related to the PID (internal brain) but i do not have enough information to say 100% that is the case. All my TRVs are set to 1 (factory setting)

[ipeacocks]

@robertalexa so it's activated by default, correct?

[robertalexa]

Yes, by default when you set the temperature the TRV reacts instantly, no matter how much it needs to close/open the valve. So it can go from 0% to 100% open instantly

[rindlerblabla]

Another question regarding the external temperature sensor. Would it be possible to bind the external sensor somehow directly to the thermostat without sending those values from eg Home Assistant? Does zigbee in general support these kind of bindings?

@rindlerblabla I haven't heard that any TRV can do that. Some people just making hacks for making this but those hacks are quite bad.

For example with Moes HY368 TRV you can force valve to fully open and close. So it's possible to make generic thermostat in HA with this switch where you can use external temp sensor. But batteries probably won't live long. Second technic of bypassing this problem is dynamically set temperature calibration (temp correction) to valve. Moes HY368 TRV have special field for that. I think it's also bad because of batteries life.

Those devices already support an external temperature sensor value being sent from HA (https://www.zigbee2mqtt.io/devices/014G2461.html#external-measured-room-sensor-numeric), I just wondered about zigbee functionality in general. And you are completely right, the batteries are consumed faster, but if/when the radiator/thermostat is covered it is just a nice functionality anyway.

[kennylevinsen]

Manual external temp correction would be done by maintaining a rolling window average of the room temperature and radiator temperature over the last, say, 1 hour, writing the difference as setpoint offset or temperature offset on the radiators depending on attribute availability.

An alternative implementation uses the average of both room and radiator temperature as the average room temperature, and diffs that against just the average radiator temperature. Depends on your goal.

This is what external measured temperature effectively does inside a Danfoss thermostat when you write the external measurement - it's not used directly for regulation. Keeping to the Danfoss recommended 3 hour minimum 30 min maximum write frequency should be sufficient to avoid battery wear as the radio likely wakes to report temp attributes much more often than that. The use of a 30min average also minimize fluctuations and thus valve actuator action.

This feature is to minimize temperature gradients/cold spots in a room. There should never be a need to manually control valve action, other than possibly to implement manual window detection. Implementing "bang-bang" regulation would be a huge power drain.

[rindlerblabla]

According to some user on the HA community forum there is also an expected coming release of the firmware with a "covered radiator" functionality. In these cases there will be no average calculation and the thermostat will only listen to the external sensor. Don't know ETA of that firmware version though.

[ipeacocks]

This is what external measured temperature effectively does inside a Danfoss thermostat when you write the external measurement - it's not used directly for regulation. Keeping to the Danfoss recommended 3 hour minimum 30 min maximum write frequency should be sufficient to avoid battery wear as the radio likely wakes to report temp attributes much more often than that. The use of a 30min average also minimize fluctuations and thus valve actuator action.

@kennylevinsen could you share own settings and success in temp difference? Mine thermostat shows +1-1.5 C more than separate room one. And would like to correct internal thermostat temp sensor.

[rindlerblabla]

Seems like 1.18 firmware is released, with the covered radiator functionality.

https://community.home-assistant.io/t/danfoss-ally-trv-working-with-remote-temp-sensor/276686/88

[ahaafin]

It is currently not supported, there has been some work done, but to my knowledge it is not yet completed.

The attribute has received support in zigbee-herdsman, but not yet in zigbee-herdsman-converters.

@kennylevinsen is Window Open Feature still something you plan on adding or should I have a look at it?

I don't know how much work would it need to implement the Window Open feature but I would really appreciate if someone could do it :D Here is a picture of Danfoss Ally's pi heating demand during today. Everytime the demand goes to 0 % Danfoss have thought that the window is open. The window open feature should really be disabled in this location.

[JackJensen]

If anyone has a danfoss ally (and even the Popp 701721 TRV) and is willing to help me test the above, then at least I know how to move forward?

toZigbee

    danfoss_window_open_feature_enable: {
        key: ['window_open_feature_enable'],
        convertSet: async (entity, key, value, meta) => {
            await entity.write('hvacThermostat', {'danfossWindowOpenFeatureEnable': value}, manufacturerOptions.danfoss);
            return {readAfterWriteTime: 200, state: {'window_open_feature_enable': value}};
        },
        convertGet: async (entity, key, meta) => {
            await entity.read('hvacThermostat', ['danfossWindowOpenFeatureEnable'], manufacturerOptions.danfoss);
        },
    },

fromZigbee

if (msg.data.hasOwnProperty('danfossWindowOpenFeatureEnable')) {
                result[postfixWithEndpointName('window_open_feature_enable', msg, model)] = (msg.data['danfossWindowOpenFeatureEnable'] === 1);
            }

Then on the device add this to toZigbee section: tz.danfoss_window_open_feature_enable and to the exposes:

exposes.binary('window_open_feature_enable', ea.ALL, true, false)
                .withDescription('Whether or not the window open feature is enabled'),

@robertalexa I tested this with a Danfoss Ally running firmware version 01.18.0008 01.18, but unfortunately I get the same response:
'ConfigureReporting 0xccccccfffe1daa87/1 hvacThermostat([{"attribute":"danfossWindowOpenFeatureEnable","minimumReportInterval":60,"maximumReportInterval":3600,"reportableChange":0}], {"sendWhenActive":true,"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (Status 'UNSUPPORTED_ATTRIBUTE')'

[robertalexa]

@JackJensen If you go to the Frontend of z2m, on this device, you will see the attribute. Can you clarify what happens when you click the refresh icon, or set a value? Please include the log for the attempted commands.

[JackJensen]

@robertalexa To my surprise this actually works great, so the attribute is obviously supported, but I still see the issue with the reporting

Enabling window_open_feature_enable from the front-end:

Zigbee2MQTT:info 2022-02-02 17:02:30: MQTT publish: topic 'zigbee2mqtt_development/0xccccccfffe1daa87', payload '{"algorithm_scale_factor":1,"battery":127.5,"day_of_week":"thursday","external_measured_room_sensor":-8000,"heat_available":true,"keypad_lockout":"unlock","linkquality":255,"load_balancing_enable":true,"load_estimate":410,"load_room_mean":-8000,"local_temperature":24.39,"max_heat_setpoint_limit":35,"min_heat_setpoint_limit":5,"mounted_mode_active":false,"mounted_mode_control":false,"pi_heating_demand":1,"radiator_covered":false,"system_mode":"heat","trigger_time":660,"update":{"state":"idle"},"update_available":false,"window_open_external":false,"window_open_feature_enable":true,"window_open_internal":"quarantine"}'

Disabling window_open_feature_enable from the front-end:

Zigbee2MQTT:info 2022-02-02 17:03:28: MQTT publish: topic 'zigbee2mqtt_development/0xccccccfffe1daa87', payload '{"algorithm_scale_factor":1,"battery":127.5,"day_of_week":"thursday","external_measured_room_sensor":-8000,"heat_available":true,"keypad_lockout":"unlock","linkquality":255,"load_balancing_enable":true,"load_estimate":410,"load_room_mean":-8000,"local_temperature":24.39,"max_heat_setpoint_limit":35,"min_heat_setpoint_limit":5,"mounted_mode_active":false,"mounted_mode_control":false,"pi_heating_demand":1,"radiator_covered":false,"system_mode":"heat","trigger_time":660,"update":{"state":"idle"},"update_available":false,"window_open_external":false,"window_open_feature_enable":false,"window_open_internal":"quarantine"}'

When trying to setup reporting for window_open_feature_enable

I get the following error:
Zigbee2MQTT:debug 2022-02-02 17:22:30: Received MQTT message on 'zigbee2mqtt_development/bridge/request/device/configure_reporting' with data '{"attribute":"danfossWindowOpenFeatureEnable","cluster":"hvacThermostat","id":"0xccccccfffe1daa87/1","maximum_report_interval":3600,"minimum_report_interval":60,"reportable_change":0,"transaction":"sfz2l-5"}'
Zigbee2MQTT:debug 2022-02-02 17:22:31: Received Zigbee message from '0xccccccfffe1daa87', type 'attributeReport', cluster 'hvacThermostat', data '{"danfossLoadEstimate":306}' from endpoint 1 with groupID null
Zigbee2MQTT:info 2022-02-02 17:22:31: MQTT publish: topic 'zigbee2mqtt_development/0xccccccfffe1daa87', payload '{"algorithm_scale_factor":1,"battery":127.5,"day_of_week":"thursday","external_measured_room_sensor":-8000,"heat_available":true,"keypad_lockout":"unlock","linkquality":255,"load_balancing_enable":true,"load_estimate":306,"load_room_mean":-8000,"local_temperature":23.92,"max_heat_setpoint_limit":35,"min_heat_setpoint_limit":5,"mounted_mode_active":false,"mounted_mode_control":false,"pi_heating_demand":1,"radiator_covered":false,"system_mode":"heat","trigger_time":660,"update":{"state":"idle"},"update_available":false,"window_open_external":false,"window_open_feature_enable":false,"window_open_internal":"quarantine"}'
Zigbee2MQTT:error 2022-02-02 17:22:33: Request 'zigbee2mqtt_development/bridge/request/device/configure_reporting' failed with error: 'ConfigureReporting 0xccccccfffe1daa87/1 hvacThermostat([{"attribute":"danfossWindowOpenFeatureEnable","minimumReportInterval":60,"maximumReportInterval":3600,"reportableChange":0}], {"sendWhenActive":true,"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (Status 'UNSUPPORTED_ATTRIBUTE')'
Zigbee2MQTT:debug 2022-02-02 17:22:33: Error: ConfigureReporting 0xccccccfffe1daa87/1 hvacThermostat([{"attribute":"danfossWindowOpenFeatureEnable","minimumReportInterval":60,"maximumReportInterval":3600,"reportableChange":0}], {"sendWhenActive":true,"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (Status 'UNSUPPORTED_ATTRIBUTE')
at Endpoint.checkStatus (C:\workspaces\zigbee2mqtt\node_modules\zigbee-herdsman\src\controller\model\endpoint.ts:310:23)
at Endpoint.configureReporting (C:\workspaces\zigbee2mqtt\node_modules\zigbee-herdsman\src\controller\model\endpoint.ts:644:22)
at Bridge.deviceConfigureReporting (C:\workspaces\zigbee2mqtt\lib\extension\bridge.ts:419:9)
at Bridge.onMQTTMessage (C:\workspaces\zigbee2mqtt\lib\extension\bridge.ts:118:34)
Zigbee2MQTT:info 2022-02-02 17:22:33: MQTT publish: topic 'zigbee2mqtt_development/bridge/response/device/configure_reporting', payload '{"data":{},"error":"ConfigureReporting 0xccccccfffe1daa87/1 hvacThermostat([{"attribute":"danfossWindowOpenFeatureEnable","minimumReportInterval":60,"maximumReportInterval":3600,"reportableChange":0}], {"sendWhenActive":true,"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (Status 'UNSUPPORTED_ATTRIBUTE')","status":"error","transaction":"sfz2l-5"}'

[robertalexa]

The attribute does not support reporting, as specified in the documentation. The code I suggested does not set reporting, this is something you would have tried to do manually.

The device will not change this attribute, hence no need to report

[robertalexa]

PR created Koenkk/zigbee-herdsman-converters#3800 to add this attribute natively supported. This should be available in the release next month. 1st of March.

Hope this helps

[JackJensen]

The attribute does not support reporting, as specified in the documentation. The code I suggested does not set reporting, this is something you would have tried to do manually.

The device will not change this attribute, hence no need to report

Makes sense. I did not check the documentation, sorry about that. Will do that next time.

[robertalexa]

Nothing to worry about. Glad it works. Happy to help :)

[Starceus001]

Here is the problem, Danfoss ally has some standard attributes but the 0x4xxx attributes are manufacturer specific and I believe they require a manufacturer code to read/write these (if allowed at all). Does anyone have more experience with this? I am trying to read cluster 0x0201 attribute 0x4012 and write cluster 0x0201 attribute 0x4013 with the manufacturer code inside the ZCL header, but I am getting the return code 134 (ZCL_STATUS_UNSUPPORTED_ATTRIBUTE ). Can anyone tell me what to do next?