Danfoss Ally - need to be able to set 1 for pi_heating_demand as it is 0 after FACTORY RESET of the thermostat

[Jodifoto]

Danfoss Ally was working after initial pairing BUT it started the heating at 3:00 a.m. There seems to be a schedule and temperature setpoint in the thermostat when purchased. To get rid of it I performed a RESET pushing the o-button for more that 10 seconds after inserting the batteries. After pairing I got it connected again. However it is NOT publishing the changes to measured temperature nor changes to setpoint any more. This is a problem to work with it. The only change in parameters is that "pi_heating_demand" was 1 when it worked ... and now it is 0. I can not change "pi_heating_demand" to 1 again with a "set" command published in mqtt. I get the error message : {"level":"error","message":"No converter available for 'pi_heating_demand' (1)"} My hope is that once this will be possible the thermostat will do publishing of his values again.

What did you expect to happen

I expected that the "set" command {"pi_heating_demand": 1} published in mqtt would restore the needed value of 1 allowing regular MQTT-publishing of changed measured temperature and changed setpoint.

How to reproduce it (minimal and precise)

Debug info

Zigbee2MQTT version: 1.18.2 Adapter hardware: [slae.sh] CC2652 stick Adapter firmware version: zStack3x0

[sjorge]

I don't think that attribute is writable, it wasn't one I briefly owned to do some testing. It indicates if the valve is open or closed.

So having it at 0 means the valve is closed, so hot experiencing heating makes sense. Trye setting system_mode to sleep and then after a few seconds back to heat.

[Jodifoto]

@sjorge, I tried to set "system_mode" to "sleep" with: topic: zigbee2mqtt/z2m_ally_therm_test/set
message-data: {"system_mode": "sleep"} but I get an error on: topic: zigbee2mqtt/bridge/logging
message-data: {"level":"error","message":"No converter available for 'system_mode' (sleep)"} As a test I used this publish: topic: zigbee2mqtt/z2m_ally_therm_test/get
message-data: {"local_temperature": ""} and got the right answer back from the Ally ... so mqtt-communication seems to work. I think you are right ... it is in a kind of "sleep/off" state. I have tried 2 things -1- setpoint below measured temperature and -2- setpoint above measured temperature. I hear the motor opening and closing ... so that works. But if I ask the info from the valve with "get" {"occupied_heating_setpoint": ""} I get the next results: -1- "heat_required":false,"linkquality":63,"local_temperature":21.88,"occupied_heating_setpoint":8.5,"pi_heating_demand":0 -2- "heat_required":false,"linkquality":63,"local_temperature":21.88,"occupied_heating_setpoint":28,"pi_heating_demand":0 "heat_required": stays on "false" and ,"pi_heating_demand": on 0 For the "heat_required": I have seen before the RESET to FACTORY that it jumps to "true" ... in the past. Before the RESET to FACTORY it also published any change to setpoint (and measured temperature) without asking ... Now I have to ask with
zigbee2mqtt/z2m_ally_therm_test/get
{"occupied_heating_setpoint": ""} ... again pointing at a "sleep/off" state. How can I get it back into "heat" state ? ... did I do something wrong in the publish ?

[sjorge]

Looks like the converter is indeed missing form the list, can you try after updating the existing block with this one in devices.js

// Danfoss
    {
        zigbeeModel: ['eTRV0100'],
        model: '014G2461',
        vendor: 'Danfoss',
        description: 'Ally thermostat',
        fromZigbee: [fz.battery, fz.legacy.thermostat_att_report, fz.danfoss_thermostat],
        toZigbee: [tz.thermostat_occupied_heating_setpoint, tz.thermostat_local_temperature, tz.danfoss_mounted_mode,
            tz.danfoss_thermostat_orientation, tz.danfoss_algorithm_scale_factor, tz.danfoss_heat_available, tz.danfoss_day_of_week,
            tz.danfoss_trigger_time, tz.danfoss_window_open, tz.danfoss_display_orientation, tz.thermostat_keypad_lockout,
            tz.thermostat_system_mode],
        exposes: [e.battery(), e.keypad_lockout(),
            exposes.binary('mounted_mode', ea.STATE, true, false).withDescription(
                'Mode in which the unit is mounted. This is set to `false` for normal mounting or `true` for vertical mounting'),
            exposes.binary('heat_required', ea.STATE, true, false).withDescription('Wether or not the unit needs warm water'),
            exposes.binary('window_open_internal', ea.STATE, 1, 0)
                .withDescription('0=Quarantine, 1=Windows are closed, 2=Hold - Windows are maybe about to open, ' +
                '3=Open window detected, 4=In window open state from external but detected closed locally'),
            exposes.binary('setpoint_change_source', ea.STATE, 0, 1)
                .withDescription('Values observed are `0` (set locally) or `2` (set via Zigbee)'),
            exposes.climate().withSetpoint('occupied_heating_setpoint', 6, 28, 0.5).withLocalTemperature().withPiHeatingDemand().withLocalTemperature().withSystemMode(['heat', 'sleep']),
            exposes.binary('window_open_external', ea.ALL, true, false),
            exposes.numeric('day_of_week', ea.ALL).withValueMin(0).withValueMax(7)
                .withDescription('Exercise day of week: 0=Sun...6=Sat, 7=undefined'),
            exposes.numeric('trigger_time', ea.ALL).withValueMin(0).withValueMax(65535)
                .withDescription('Exercise trigger time. Minutes since midnight (65535=undefined)'),
            exposes.binary('heat_available', ea.ALL, true, false),
            exposes.numeric('algorithm_scale_factor', ea.ALL).withValueMin(1).withValueMax(10)
                .withDescription('Scale factor of setpoint filter timeconstant'+
                ' ("aggressiveness" of control algorithm) 1= Quick ...  5=Moderate ... 10=Slow')],
        meta: {configureKey: 4},
        ota: ota.zigbeeOTA,
        configure: async (device, coordinatorEndpoint, logger) => {
            const endpoint = device.getEndpoint(1);
            const options = {manufacturerCode: 0x1246};
            await reporting.bind(endpoint, coordinatorEndpoint, ['genPowerCfg', 'hvacThermostat']);

            // standard ZCL attributes
            await reporting.batteryPercentageRemaining(endpoint, {min: 60, max: 43200, change: 1});
            await reporting.thermostatTemperature(endpoint, {min: 0, max: repInterval.MINUTES_10, change: 25});
            await reporting.thermostatPIHeatingDemand(endpoint, {min: 0, max: repInterval.MINUTES_10, change: 1});
            await reporting.thermostatOccupiedHeatingSetpoint(endpoint, {min: 0, max: repInterval.MINUTES_10, change: 25});

            // danfoss attributes
            await endpoint.configureReporting('hvacThermostat', [{attribute: {ID: 0x4012, type: 0x10}, minimumReportInterval: 0,
                maximumReportInterval: repInterval.MINUTES_10, reportableChange: 1}], options);
            await endpoint.configureReporting('hvacThermostat', [{attribute: {ID: 0x4000, type: 0x30}, minimumReportInterval: 0,
                maximumReportInterval: repInterval.HOUR, reportableChange: 1}], options);

            // read keypadLockout, we don't need reporting as it cannot be set physically on the device
            await endpoint.read('hvacUserInterfaceCfg', ['keypadLockout']);
            await endpoint.read('hvacThermostat', [0x4003, 0x4010, 0x4011, 0x4020], options);

            // Seems that it is bug in Danfoss, device does not asks for the time with binding
            // So, we need to write time during configure (same as for HEIMAN devices)
            const time = Math.round(((new Date()).getTime() - OneJanuary2000) / 1000);
            // Time-master + synchronised
            const values = {timeStatus: 3, time: time, timeZone: ((new Date()).getTimezoneOffset() * -1) * 60};
            endpoint.write('genTime', values);
        },
    },=

[Jodifoto]

Hi sjorge, thanks ... I tried it and "sleep" is giving errors ... but "heat" was accepted ... see hereafter. The behaviour of the thermostat is still the same ... see at the end. My Tuya thermostat also has an "auto" setting ... although this was not OK for my purpose ... I needed "heat" to have Tuya working as I wanted. Are there other states like "auto" for the Ally that we can consider ?

---- setting sleep ---- zigbee2mqtt/z2m_ally_therm_test/set {"system_mode": "sleep"}

zigbee2mqtt/bridge/logging {"level":"debug","message":"Received MQTT message on 'zigbee2mqtt/z2m_ally_therm_test/set' with data '{\"system_mode\": \"sleep\"}'"}

{"level":"debug","message":"Publishing 'set' 'system_mode' to 'z2m_ally_therm_test'"}

{"level":"error","message":"Publish 'set' 'system_mode' to 'z2m_ally_therm_test' failed: 'Error: Write 0x842e14fffe56f8bc/1 hvacThermostat({\"systemMode\":9}, {\"timeout\":10000,\"disableResponse\":false,\"disableRecovery\":false,\"disableDefaultResponse\":true,\"direction\":0,\"srcEndpoint\":null,\"reservedBits\":0,\"manufacturerCode\":null,\"transactionSequenceNumber\":null,\"writeUndiv\":false}) failed (Status 'INVALID_VALUE')'"}

{"level":"debug","message":"Error: Write 0x842e14fffe56f8bc/1 hvacThermostat({\"systemMode\":9}, {\"timeout\":10000,\"disableResponse\":false,\"disableRecovery\":false,\"disableDefaultResponse\":true,\"direction\":0,\"srcEndpoint\":null,\"reservedBits\":0,\"manufacturerCode\":null,\"transactionSequenceNumber\":null,\"writeUndiv\":false}) failed (Status 'INVALID_VALUE')\n at Endpoint.checkStatus (/app/node_modules/zigbee-herdsman/dist/controller/model/endpoint.js:196:23)\n at Endpoint. (/app/node_modules/zigbee-herdsman/dist/controller/model/endpoint.js:225:26)\n at Generator.next ()\n at fulfilled (/app/node_modules/zigbee-herdsman/dist/controller/model/endpoint.js:24:58)"}

{"level":"info","message":"MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{\"message\":\"Publish 'set' 'system_mode' to 'z2m_ally_therm_test' failed: 'Error: Write 0x842e14fffe56f8bc/1 hvacThermostat({\\"systemMode\\":9}, {\\"timeout\\":10000,\\"disableResponse\\":false,\\"disableRecovery\\":false,\\"disableDefaultResponse\\":true,\\"direction\\":0,\\"srcEndpoint\\":null,\\"reservedBits\\":0,\\"manufacturerCode\\":null,\\"transactionSequenceNumber\\":null,\\"writeUndiv\\":false}) failed (Status 'INVALID_VALUE')'\",\"meta\":{\"friendly_name\":\"z2m_ally_therm_test\"},\"type\":\"zigbee_publish_error\"}'"}

{"message":"Publish 'set' 'system_mode' to 'z2m_ally_therm_test' failed: 'Error: Write 0x842e14fffe56f8bc/1 hvacThermostat({\"systemMode\":9}, {\"timeout\":10000,\"disableResponse\":false,\"disableRecovery\":false,\"disableDefaultResponse\":true,\"direction\":0,\"srcEndpoint\":null,\"reservedBits\":0,\"manufacturerCode\":null,\"transactionSequenceNumber\":null,\"writeUndiv\":false}) failed (Status 'INVALID_VALUE')'","meta":{"friendly_name":"z2m_ally_therm_test"},"type":"zigbee_publish_error"}

---- setting heat ---- zigbee2mqtt/z2m_ally_therm_test/set {"system_mode": "heat"}

zigbee2mqtt/bridge/logging {"level":"debug","message":"Received MQTT message on 'zigbee2mqtt/z2m_ally_therm_test/set' with data '{\"system_mode\": \"heat\"}'"}

{"level":"debug","message":"Publishing 'set' 'system_mode' to 'z2m_ally_therm_test'"}

{"level":"info","message":"MQTT publish: topic 'zigbee2mqtt/z2m_ally_therm_test', payload '{\"battery\":89,\"device\":{\"applicationVersion\":2,\"dateCode\":\"20201117\",\"friendlyName\":\"z2m_ally_therm_test\",\"hardwareVersion\":69,\"ieeeAddr\":\"0x842e14fffe56f8bc\",\"manufacturerID\":4678,\"manufacturerName\":\"Danfoss\",\"model\":\"014G2461\",\"networkAddress\":65502,\"powerSource\":\"Battery\",\"softwareBuildID\":\"01.02.0008 01.02\",\"stackVersion\":8,\"type\":\"EndDevice\",\"zclVersion\":3},\"heat_required\":false,\"linkquality\":57,\"local_temperature\":21.88,\"occupied_heating_setpoint\":26.5,\"pi_heating_demand\":0,\"system_mode\":\"heat\",\"update\":{\"state\":\"available\"},\"update_available\":true}'"}

zigbee2mqtt/z2m_ally_therm_test {"battery":89,"device":{"applicationVersion":2,"dateCode":"20201117","friendlyName":"z2m_ally_therm_test","hardwareVersion":69,"ieeeAddr":"0x842e14fffe56f8bc","manufacturerID":4678,"manufacturerName":"Danfoss","model":"014G2461","networkAddress":65502,"powerSource":"Battery","softwareBuildID":"01.02.0008 01.02","stackVersion":8,"type":"EndDevice","zclVersion":3},"heat_required":false,"linkquality":57,"local_temperature":21.88,"occupied_heating_setpoint":26.5,"pi_heating_demand":0,"system_mode":"heat","update":{"state":"available"},"update_available":true}

After setting setpoint above room temperature I get: {"battery":89,"device":{"applicationVersion":2,"dateCode":"20201117","friendlyName":"z2m_ally_therm_test","hardwareVersion":69,"ieeeAddr":"0x842e14fffe56f8bc","manufacturerID":4678,"manufacturerName":"Danfoss","model":"014G2461","networkAddress":65502,"powerSource":"Battery","softwareBuildID":"01.02.0008 01.02","stackVersion":8,"type":"EndDevice","zclVersion":3},"heat_required":false,"linkquality":42,"local_temperature":21.88,"occupied_heating_setpoint":27.5,"pi_heating_demand":0,"system_mode":"heat","update":{"state":"available"},"update_available":true} => so no "heat_required" and no "pi_heating_demand" => also the publishing of changes to setpoint is not happening as before ... ... seems still sleeping.

NEW is that Ally now mention "system_mode":"heat" in its reporting ... I have never seen this before.

[sjorge]

Interesting, mine I had for tasking came with a super old firmware that did accept sleep and heat. Probably why system_mode was not expose as the newer ones don’t seem to support it, based on the invalid value result.

~ sjorge

On 21 Apr 2021, at 13:08, Jodifoto @.***> wrote:

 Hi sjorge, thanks ... I tried it and "sleep" is giving errors ... but "heat" was accepted ... see hereafter. The behaviour of the thermostat is still the same ... see at the end. My Tuya thermostat also has an "auto" setting ... although this was not OK for my purpose ... I needed "heat" to have Tuya working as I wanted. Are there other states like "auto" for the Ally that we can consider ?

---- setting sleep ---- zigbee2mqtt/z2m_ally_therm_test/set {"system_mode": "sleep"}

zigbee2mqtt/bridge/logging {"level":"debug","message":"Received MQTT message on 'zigbee2mqtt/z2m_ally_therm_test/set' with data '{"system_mode": "sleep"}'"}

{"level":"debug","message":"Publishing 'set' 'system_mode' to 'z2m_ally_therm_test'"}

{"level":"error","message":"Publish 'set' 'system_mode' to 'z2m_ally_therm_test' failed: 'Error: Write 0x842e14fffe56f8bc/1 hvacThermostat({"systemMode":9}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (Status 'INVALID_VALUE')'"}

{"level":"debug","message":"Error: Write 0x842e14fffe56f8bc/1 hvacThermostat({"systemMode":9}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (Status 'INVALID_VALUE')\n at Endpoint.checkStatus (/app/node_modules/zigbee-herdsman/dist/controller/model/endpoint.js:196:23)\n at Endpoint. (/app/node_modules/zigbee-herdsman/dist/controller/model/endpoint.js:225:26)\n at Generator.next ()\n at fulfilled (/app/node_modules/zigbee-herdsman/dist/controller/model/endpoint.js:24:58)"}

{"level":"info","message":"MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"message":"Publish 'set' 'system_mode' to 'z2m_ally_therm_test' failed: 'Error: Write 0x842e14fffe56f8bc/1 hvacThermostat({\"systemMode\":9}, {\"timeout\":10000,\"disableResponse\":false,\"disableRecovery\":false,\"disableDefaultResponse\":true,\"direction\":0,\"srcEndpoint\":null,\"reservedBits\":0,\"manufacturerCode\":null,\"transactionSequenceNumber\":null,\"writeUndiv\":false}) failed (Status 'INVALID_VALUE')'","meta":{"friendly_name":"z2m_ally_therm_test"},"type":"zigbee_publish_error"}'"}

{"message":"Publish 'set' 'system_mode' to 'z2m_ally_therm_test' failed: 'Error: Write 0x842e14fffe56f8bc/1 hvacThermostat({"systemMode":9}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (Status 'INVALID_VALUE')'","meta":{"friendly_name":"z2m_ally_therm_test"},"type":"zigbee_publish_error"}

---- setting heat ---- zigbee2mqtt/z2m_ally_therm_test/set {"system_mode": "heat"}

zigbee2mqtt/bridge/logging {"level":"debug","message":"Received MQTT message on 'zigbee2mqtt/z2m_ally_therm_test/set' with data '{"system_mode": "heat"}'"}

{"level":"debug","message":"Publishing 'set' 'system_mode' to 'z2m_ally_therm_test'"}

{"level":"info","message":"MQTT publish: topic 'zigbee2mqtt/z2m_ally_therm_test', payload '{"battery":89,"device":{"applicationVersion":2,"dateCode":"20201117","friendlyName":"z2m_ally_therm_test","hardwareVersion":69,"ieeeAddr":"0x842e14fffe56f8bc","manufacturerID":4678,"manufacturerName":"Danfoss","model":"014G2461","networkAddress":65502,"powerSource":"Battery","softwareBuildID":"01.02.0008 01.02","stackVersion":8,"type":"EndDevice","zclVersion":3},"heat_required":false,"linkquality":57,"local_temperature":21.88,"occupied_heating_setpoint":26.5,"pi_heating_demand":0,"system_mode":"heat","update":{"state":"available"},"update_available":true}'"}

zigbee2mqtt/z2m_ally_therm_test {"battery":89,"device":{"applicationVersion":2,"dateCode":"20201117","friendlyName":"z2m_ally_therm_test","hardwareVersion":69,"ieeeAddr":"0x842e14fffe56f8bc","manufacturerID":4678,"manufacturerName":"Danfoss","model":"014G2461","networkAddress":65502,"powerSource":"Battery","softwareBuildID":"01.02.0008 01.02","stackVersion":8,"type":"EndDevice","zclVersion":3},"heat_required":false,"linkquality":57,"local_temperature":21.88,"occupied_heating_setpoint":26.5,"pi_heating_demand":0,"system_mode":"heat","update":{"state":"available"},"update_available":true}

After setting setpoint above room temperature I get: {"battery":89,"device":{"applicationVersion":2,"dateCode":"20201117","friendlyName":"z2m_ally_therm_test","hardwareVersion":69,"ieeeAddr":"0x842e14fffe56f8bc","manufacturerID":4678,"manufacturerName":"Danfoss","model":"014G2461","networkAddress":65502,"powerSource":"Battery","softwareBuildID":"01.02.0008 01.02","stackVersion":8,"type":"EndDevice","zclVersion":3},"heat_required":false,"linkquality":42,"local_temperature":21.88,"occupied_heating_setpoint":27.5,"pi_heating_demand":0,"system_mode":"heat","update":{"state":"available"},"update_available":true} => so no "heat_required" and no "pi_heating_demand" => also the publishing of changes to setpoint is not happening as before ... ... seems still sleeping.

NEW is that Ally now mention "system_mode":"heat" in its reporting ... I have never seen this before.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[Jodifoto]

Hi @sjorge, do you still see a possibility to get my Ally alive again ?

[sjorge]

Aside from trying to reset it again, nothing comes to mind. Perhaps remove it from the network via z2m, take out the batteries for a bit, reinstert the batteries and join it again.

[Jodifoto]

Hi @sjorge, thanks for your help !! ... I will try that ... hope some other people had the same problem and find this discussion ... to share their solution ??... I hope ... PS: studied on the same university as you are ... probably before you were born ... ;-)) ... LOOONG time ago ....

[Jodifoto]

Hi @sjorge, I followed your last suggestion and took out the batteries ... for many days !! (+/- 1 week) ... AND IT WORKED !!!! After connecting to Zigbee2MQTT again ... it is posting its status AS BEFORE ! Changing the setpoint on the Danfoss itself causes a DIRECT publish of all values. Many thanks again for your help ! PS: the item ... "system_mode":"heat" ... is not in the publish any more

[robertalexa]

@Jodifoto A new PR has been merged into the dev branch of z2m that will highly improve the Danfoss Ally compared to its current state. https://github.com/Koenkk/zigbee-herdsman-converters/pull/2592

There is also another one in progress but only for a couple of things https://github.com/Koenkk/zigbee-herdsman-converters/pull/2614

Would you be kind to give the dev branch a test? If everything is well it would be great if you could close this issue in order to keep this clean.

[Jodifoto]

Taking out batteries solved the issue as mentioned in my previous post ... and there is a new development ... so thanks to @sjorge for his help and @robertalexa for the tip to the new development !

[frauhottelmann]

Hey @Jodifoto, I seem to have the same problem you originally had. My thermostats randomly start heating at night. I tried to reset them, but it happens again and again. You can see that I reset it before the night and the temperature is set lower than the room temp. It still starts in the middle of the night. Did you resolve this with the reset?

[jantielens]

@frauhottelmann same issue here: got a brand new Danfoss Ally, added it to my network and it goes into heating at night, even the desired temperature is lower than the measured temperature. Did you manage to resolve this?

[frauhottelmann]

@jantielens well, resolved nicht not be the right term 😄 It seems to me, that this happens when you set the temperature too low. Try raising it to something like 12° and see if it still happens. I had the feeling it happens when the thermostats are set to 10° and below.

[robertalexa]

Hey guys, here are some screenshots of my Hive TRVs (which are basically Danfoss Ally), to give you a comparison.

These are just a few of the TRVs, over the last few days, to give you a vision of how they behave vs the schedule.

With regards to the "orange" area, that would basically be the running state heating. In the case of the Danfoss Ally (and the other ones based on it), the running state is being emulated based on the heat_required attribute. https://github.com/Koenkk/zigbee-herdsman-converters/pull/2966/files

An interesting thing would be for you guys to check the heat_required attribute and see if they graphs for it and the "orange" overlap. That would help us understand what is happening. I would expect them to overlap, i would be worried if they don't.

Then from there I would ask how are you doing your schedulling? Have you attempted touching the "integrated" scheduler (which i heavy advise not to)? What are the values for these attributes? (I do not fully understand their behaviour, and the documentation doesn't help either, here is mine for comparison)

I would be curious to find out if that increase happens every 24h at the same time (so regularly). If that is the case, i would change trigger_time to see if that has an impact. I think setting it to 65535 should also disable it. The attribute is related to the internal scheduler, and I wonder if that overwrites.

Another question, on these TRVs that are misbehaving, did you ever set the temperature by command (not physical). I expect you did, just double checking.

It seems to me, that this happens when you set the temperature too low. Try raising it to something like 12° and see if it still happens. I had the feeling it happens when the thermostats are set to 10° and below.

Mine always go to 9C when "off" and I am not experiencing this

[Jodifoto]

@frauhottelmann My Danfoss Ally was working after initial pairing BUT it started the heating at 3:00 a.m. To me there seems to be a schedule and temperature setpoint in the thermostat when purchased. To get rid of it I performed a "total" RESET by pushing the o-button for more that 10 seconds during and after inserting the batteries. After pairing I got it connected again. However it was NOT publishing the changes to measured temperature nor changes to setpoint any more. This is a problem to work with it. As mentioned above, I followed the advice of sjorge by removing it from the network via z2m, taking out the batteries for a week, reinserting the batteries and join it again. This solved it.

[robertalexa]

However it was NOT publishing the changes to measured temperature nor changes to setpoint any more.

This feels like a failure to configure reporting correctly.

I would suggest the following. Make sure Join is disabled in z2m.

Reset the thermostat, hold the button, insert the batteries, keep holding until the screen turns on and off 3 times. After the 3rd time release the button. Put z2m in pairing mode, let the device pair and configure.

[frauhottelmann]

@robertalexa I can set my temp low tonight to see if it still does that. My scheduling is done with Home Assistant Automations, not with the build in one. If I remember correctly, the first one I bought (which is stuck on the older firmware, because z2m doesn't recognize the newer version, even though it's on Github) doesn't exhibit this behavior any more after a reset or two. I have reset the other 3 multiple times, it still happened, but I haven't taken out the batteries for e week (but they came without the batteries in them).

I can also try the 3 time display on and off reset. But not tonight 😄 I can also try with trigger time 65535...

[snp88]

@robertalexa for me even if i have setup temperature at 19 and in the room is 21 night heating still going ;( today i will try with reset

[robertalexa]

Hey @sjorge You have the Danfoss Ally in your house (if i remember correctly), can you have a look at the above? I am not seeing this behaviour with the Hive TRV. Trying to exclude a device issue. Thanks

[sjorge]

I returned it after testing, so I do not currently have access to one.

[tatec22]

So, I might be able to point you towards the right direction regarding the heating starting at 3.00am. I had the exact same behavior, but I figured it me be related to the adaption_run_status (0x404d) in the DanfossThermostatCluster (0x0201). The random heating happened with the thermostat in my bedroom. So I compared the adaption run status with my other rooms. In my other rooms the status was always 2 (OP found), but for the bedroom one it was 4 (OP lost). After repairing it, it changed to 2 but after a random time it switched back to 4 and the random heating started again. My guess is, that this random heating at 3.00am is some kind of automatic pairing process, which for some reason cannot be completed successfully. My solution right now: If you change the the value of adaption_run_settings from 1 to 0 it disables that pairing process. The ally works fine and since then I had no random 3.00am heating at all.