Yes, so whenever it receives an MQTT message from zigbee2mqtt for that TRV it sends an update back resetting the temperature.
Every two hours I hear the TRV close when it resets to 20C then about a minute later it opens again.
Also, I’ve opened an issue with the zigbee2mqtt project here: Wiser TRv resets to 20c after 2 hours · Issue #11758 · Koenkk/zigbee2mqtt · GitHub
Hopefully the zigbee2mqtt people can get to the bottom of it. It drove me crazy a few nights back as the bedroom (where the TRV lives) was just too warm! So at 3:30am I just had enough of constant resetting the TRV and just ordered a new TRV… I know, I know, I should have taken your advice and just made a routine to just set the temp whenever HA sees it change back to 20c. I just lost it and bought a new one LOL
Took a little while but fitted it today and had loads of problems with the Shelly app, but finally have it all installed in HA. It’s such a shame as I really liked the Drayton, not too noisy and a simple twist to just have a set to “min” or “max”.
Hi all - don’t suppose anyone managed to get to the bottom of the issue? Got my first Wiser iTRV yesterday and have been seeing the same reset to “20-26” temperature range issues that have been reported here. Such a shame as I was going to go all in on Wiser if this worked but it looks as though I just wasted £50!
Sadly no… I gave up after my last post, with the idea of looking at it again as ZHA matured. But have not gone back 
TLDR: my post/comment is not a fix, but my experience so far using these TRVs
Hi All - I’m late to the game on this one - 2/3-ish years ago, I bought a complete set of the Drayton wiser kit, to go with the new boiler I had at the time (I splashed, as I hadn’t had a working boiler for 2 years prior to that!) 
I’m heavily invested in this, as I had 8x Drayton Wiser (/Schneider Electric) TRVs+ the Drayton hub (will not use now) and a room thermostat too.
Due to life etc. I never set anything up originally, and only tried one of the TRVs for luck the other day, using ZHA and a sonoff wifi/igbee bridge. - I remembered that you could get a drayton plug to extend the “wifi” network , and thought - ooh… maybe that’s Zigbee too…
I found the compatibility page, showing that the TRV was “tested working” with both ZHA and Zigbee2MQTT, so I thought it wouldn’t hurt to try
The TRV paired easily with ZHA, but didn’t appear to be responsive, either by using the twist control, or by using the suggested Lovelace dashboard card thingie (whatever they are called)
I have had some issues with ZHA compatibility , and was already planning on moving to Zigbee2MQTT, so I deleted the TRV, and re-added to Zigbee2MQTT (the latter is connected via a sonoff zigbee 3 USB dongle)
It re-paired easily, and had a slightly different lovelace card , as noted above - the ZHA one had a low and high temp selector, and the Zigbee2MQTT one, had just a single temp setpoint.
the behaviour in Zigbee2MQTT was almost identical though. (To that when connected via ZHA)
To ensure it was not a duff TRV / battery issue, I fired up and paired a second TRV, with new batteries , and had the same result.
So mine seems to be slightly different - I can see the logs saying the TRV is sending back info, and it seems to have the current temperature ok. if I manually twist the control on the TRV, I can sometimes make the lovelace card change between 18’C (lowest) and 22’C (highest) , but nothing outside these values.
When I change this using the twist control, it does not affect the TRV radiator valve push pin at all , it only seems to send to HA via MQTT
To me this seems correct, as you wouldn’t want local over-ride, as it would potentially cause HA to tell the TRV to revert to the setting it thinks the TRV should be at.
When I change the control / set temperature on the lovelace card, for either TRV, I cannot get it to change the radiator valve push pin.
When I paired the TRVs, at some point either before or after that process, the radiator valve push pin did move , and randomly, I have heard one or the other TRV buzz, where I think it has fractionally moved the radiator pushpin, but not to any significant amount, that would make a change when is service.
It would be nice to make a work around to use these (especially as I have 8 TRVs!) , but I’d prefer if there was a software upgrade to fix it, as from reading above, it might be that these are not 100% zigbee compliant, and I’d rather not have any devices like that , if I have a choice
As a side note, the wireless room thermostat that came with all this kit, seems to work ok, at least in terms that it sends back the correct temperature, and humidity
Hope this helps
Wire a power cable to the Hub, fire it up and pair all your TRVs and Room Thermostat to that. There is an integration for the Drayton Wiser kit. You will be able to control all the TRVs and would make more sense than playing with an incompatible ZHA/Z2M integration.
FYI when you twist the knob the valve boosts, it send a message that it has been boosted up or down. It sets the target temperature to current temperature +/-2 Celsius. And should open or close the valve accordingly.
Your TRVs must be on a firmware where the valves required a response from the Hub to change the state of the valve.
The Drayton Wiser integration’s topic:
A fair note, the Wiser Hubs have an issue as they loose wifi connections recently, but Wiser is looking at the issue currently.
PS.: I went down the same route, first developing a Device Handler in SmartThings then moving to Z2M. But at the end, I fired up the Hub and I do not regret it at all. It works really well. And it does not Matter (
) that it is the 4th Zigbee network in the House. 
Hiya Gábor, thanks for this
I might have to do that, as suggested, use the integration. I’m generally not keep on most integrations, as I like to keep everything local and off-net, and I presume the Drayton hub and app software, is cloud controlled?
I’ve got a lot of network congestion issues too - I’m in a corner plot where I live, and have five neighbours all blasting out Wifi on 2.4Ghz. I have to run 3 Wifi APs myself on different channels to get reliable signal to my wall power sockets, which are Wifi controlled too. I have dead spots for Zigbee at the moment already, so firing up another broadcasting device does make me worry a bit 
Really appreciate the info on the TRVs - that makes a lot more sense now , to what I am seeing
In case if helps, the current spec of my TRVs is:
Model: WV704R0A0902
Firmware: ad3e958
(values taken from what is being reported to Zigbee2MQTT)
Thanks
The Hub and app uses the cloud when you away from home and for firmware updates, but the integration is completely local the same way as the app communicates with the Hub on your local network.
The latest TRv firmware 0000dac0 from the Wiser app. I don’t know how is that compares to Z2M, but it has been released somewhere at the beginning of last winter as I can remember, or just before that.
Hi Gábor - Cool , thanks very much again for helping answer my questions This has definitely given me something to think about
Hi all - we purchased a few of these after seeing them recommended on Reddit and available from a local seller.
Is there currently a way to get them working inside of HA? It’s almost two years since this thread was created so I just wanted to see if there was any progress. We currently use ZHA.
Many thanks - any help would be much appreciated.
Dan
With the intention of trying to figure out this ‘reset to 20°C after two hours’ issue, here’s what I’ve found.
I’ve got 3 x WV704R0A0902 TRVs bought as a pack running firmware f60f643; no Wiser Hub. These have worked well for about two months but, after a hard reset, 1 x TRV has started automatically changing its setpoint to 20°C. The other two TRVs still work as expected. I’m therefore in a privileged position to be able to compare TRVs with and without issues.
Here’s what I’ve discovered in Z2M (apologies: I know this thread is tagged ZHA but it appears the issue occurs across platforms):
(As a new user I can only post one image - so apologies for the description where a picture should be!)
1 - Fewer clusters are available to bind
Working TRVs:
Under Device -> Bind -> Clusters there are tickboxes for:
* genBasic
* Ota
* genPollCtrl
* PowerCfg
* haDiagnostic
* hvacThermostat
Failing TRV:
Under Device -> Bind -> Clusters there are tickboxes for:
* genBasic
* Ota
* genPollCtrl
2 - Nothing to report
Working TRVs:
Failing TRV:
Compared to the above, only the empty line with 'Select endpoint' is visible.
3 - Fewer State attributes
Working TRVs:
{
"ADC": "1619,1619,2,134,-32768,1100,0,0,100,135,135,142",
"ALG": "649,1,110,134,-24,0,0,163,8058,0,100",
"MOT": "CloseValve",
"battery": 100,
"boost": "Up",
"keypad_lockout": "unlock",
"linkquality": 255,
"local_temperature": 13.4,
"occupied_heating_setpoint": 11,
"pi_heating_demand": 0,
"voltage": 3,
"running_state": null
}
Failing TRV:
{
"ADC": "1538,1540,1,166,-32768,1500,0,162,100,166,165,166",
"ALG": "4,1,150,166,-10,-15,162,15,838,3,100",
"MOT": "CloseValve",
"battery": 100,
"linkquality": 191,
"local_temperature": 16.6,
"occupied_heating_setpoint": 15, #This will reset to 20
"pi_heating_demand": 3,
"voltage": 3,
"running_state": null
}
What I’ve tried
keypad_lockout attribute through Z2M’s Dev Console (seemed hopeful but ultimately fruitless)What I’m wondering
I’ll keep playing and will report with anything useful. If you have any ideas you’d like tested, please suggest them.
This looks quite interesting!
Can you please check that all the TRVs are reported as the same kind of device. I mean they are all reported as WV704R0A0902 in Z2M?
As for debugging the issue, can you try the following, a bit different than what you have done before with an extra step.
Reset the device and force remove from Z2M as before, but as a twist, please restart Z2M before trying to pair it again. You don’t need to leave the batteries out for 2+ days.
After the restart, try to pair it again, and let’s see how it goes.
You can add the bindings manually if you want, and probably you are right regarding the “some artefact” statement.
Also, if the above does not fixes the TRV’s reporting, then you can try to use the “Reconfigure device” button. You know the yellow one on the device’s page with the “refresh icon” in Z2M. But I hope the first one will solve the issue.
Confirmed as being 3 x WV704R0A0902 TRVs. FWIW, the IEEE Address of the problem device is within 0x5085 = 20,645 of the other two, which are themselves consecutive - but, as I say, even the TRV with the issue worked fine until it was hard reset.
Good idea to make sure the reset is complete. I followed these steps:
Device is accepted and is available, but an error occurs in the logs and there are some interesting entries: the frequent skipping of what appear to be useful messages from the device may be a red flag. I’ve also tried looking through zigbee-herdsman/deconzAdapter.ts but that doesn’t seem to point to what error 140 means (or I just haven’t found it):
info 2022-11-28 20:30:25: Zigbee: allowing new devices to join.
info 2022-11-28 20:30:51: Device '0x50325ffffxxxxxxx' joined
info 2022-11-28 20:30:51: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"friendly_name":"0x50325ffffxxxxxxx","ieee_address":"0x50325ffffxxxxxxx"},"type":"device_joined"}'
info 2022-11-28 20:30:51: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"message":{"friendly_name":"0x50325ffffxxxxxxx"},"type":"device_connected"}'
info 2022-11-28 20:30:51: Starting interview of '0x50325ffffxxxxxxx'
info 2022-11-28 20:30:51: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"friendly_name":"0x50325ffffxxxxxxx","ieee_address":"0x50325ffffxxxxxxx","status":"started"},"type":"device_interview"}'
info 2022-11-28 20:30:51: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"message":"interview_started","meta":{"friendly_name":"0x50325ffffxxxxxxx"},"type":"pairing"}'
debug 2022-11-28 20:30:51: Received Zigbee message from '0x50325ffffxxxxxxx', type 'read', cluster 'genBasic', data '["zclVersion"]' from endpoint 1 with groupID null
debug 2022-11-28 20:30:51: Skipping message, definition is undefined and still interviewing
debug 2022-11-28 20:30:52: Received Zigbee message from '0x50325ffffxxxxxxx', type 'readResponse', cluster 'genBasic', data '{"modelId":"iTRV"}' from endpoint 1 with groupID null
debug 2022-11-28 20:30:52: Skipping message, definition is undefined and still interviewing
debug 2022-11-28 20:30:52: Received Zigbee message from '0x50325ffffxxxxxxx', type 'readResponse', cluster 'genBasic', data '{"manufacturerName":"Schneider Electric"}' from endpoint 1 with groupID null
debug 2022-11-28 20:30:52: Skipping message, definition is undefined and still interviewing
debug 2022-11-28 20:30:52: Received Zigbee message from 'Thermostat-Hallway', type 'commandCheckIn', cluster 'genPollCtrl', data '{}' from endpoint 9 with groupID null
debug 2022-11-28 20:30:52: Received Zigbee message from '0x50325ffffxxxxxxx', type 'readResponse', cluster 'genBasic', data '{"powerSource":3}' from endpoint 1 with groupID null
debug 2022-11-28 20:30:52: Skipping message, definition is undefined and still interviewing
debug 2022-11-28 20:30:53: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'genOta', data '{"currentFileVersion":56000,"currentZigbeeStackVersion":2,"fileOffset":4294967295,"imageTypeId":513,"imageUpgradeStatus":0,"manufacturerId":4190}' from endpoint 1 with groupID null
debug 2022-11-28 20:30:53: Skipping message, definition is undefined and still interviewing
debug 2022-11-28 20:30:53: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'hvacUserInterfaceCfg', data '{"keypadLockout":0}' from endpoint 1 with groupID null
debug 2022-11-28 20:30:53: Skipping message, definition is undefined and still interviewing
debug 2022-11-28 20:30:53: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'genPowerCfg', data '{"256":0}' from endpoint 1 with groupID null
debug 2022-11-28 20:30:53: Skipping message, definition is undefined and still interviewing
debug 2022-11-28 20:30:53: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'wiserDeviceInfo', data '{"deviceInfo":"BAT,2.90,Full"}' from endpoint 1 with groupID null
debug 2022-11-28 20:30:53: Skipping message, definition is undefined and still interviewing
debug 2022-11-28 20:30:53: Received Zigbee message from '0x50325ffffxxxxxxx', type 'read', cluster 'genBasic', data '["zclVersion"]' from endpoint 1 with groupID null
debug 2022-11-28 20:30:53: Skipping message, definition is undefined and still interviewing
debug 2022-11-28 20:30:53: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'genBasic', data '{"57345":"0201000000056000","57346":"0","57348":"50325FFFFE496716"}' from endpoint 1 with groupID null
debug 2022-11-28 20:30:53: Skipping message, definition is undefined and still interviewing
debug 2022-11-28 20:30:53: Received Zigbee message from '0x50325ffffxxxxxxx', type 'readResponse', cluster 'genBasic', data '{"zclVersion":2}' from endpoint 1 with groupID null
debug 2022-11-28 20:30:53: Skipping message, definition is undefined and still interviewing
debug 2022-11-28 20:30:54: Received Zigbee message from '0x50325ffffxxxxxxx', type 'readResponse', cluster 'genBasic', data '{"appVersion":0}' from endpoint 1 with groupID null
debug 2022-11-28 20:30:54: Skipping message, definition is undefined and still interviewing
debug 2022-11-28 20:30:54: Received Zigbee message from '0x50325ffffxxxxxxx', type 'readResponse', cluster 'genBasic', data '{}' from endpoint 1 with groupID null
debug 2022-11-28 20:30:54: Skipping message, definition is undefined and still interviewing
debug 2022-11-28 20:30:55: Received Zigbee message from '0x50325ffffxxxxxxx', type 'readResponse', cluster 'genBasic', data '{"hwVersion":0}' from endpoint 1 with groupID null
debug 2022-11-28 20:30:55: Skipping message, definition is undefined and still interviewing
debug 2022-11-28 20:30:55: Received Zigbee message from '0x50325ffffxxxxxxx', type 'readResponse', cluster 'genBasic', data '{}' from endpoint 1 with groupID null
debug 2022-11-28 20:30:55: Skipping message, definition is undefined and still interviewing
debug 2022-11-28 20:30:56: Received Zigbee message from '0x50325ffffxxxxxxx', type 'readResponse', cluster 'genBasic', data '{"swBuildId":"f60f643"}' from endpoint 1 with groupID null
debug 2022-11-28 20:30:56: Skipping message, definition is undefined and still interviewing
debug 2022-11-28 20:30:57: Received Zigbee message from '0x50325ffffxxxxxxx', type 'readResponse', cluster 'genPollCtrl', data '{"checkinInterval":14400}' from endpoint 1 with groupID null
debug 2022-11-28 20:30:57: Skipping message, definition is undefined and still interviewing
info 2022-11-28 20:30:57: Successfully interviewed '0x50325ffffxxxxxxx', device has successfully been paired
info 2022-11-28 20:30:57: Device '0x50325ffffxxxxxxx' is supported, identified as: Schneider Electric Wiser radiator thermostat (WV704R0A0902)
info 2022-11-28 20:30:57: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"definition":{"description":"Wiser radiator thermostat","exposes":[{"features":[{"access":7,"description":"Temperature setpoint","name":"occupied_heating_setpoint","property":"occupied_heating_setpoint","type":"numeric","unit":"°C","value_max":30,"value_min":7,"value_step":1},{"access":1,"description":"Current temperature measured on the device","name":"local_temperature","property":"local_temperature","type":"numeric","unit":"°C"},{"access":1,"description":"The current running state","name":"running_state","property":"running_state","type":"enum","values":["idle","heat"]},{"access":1,"description":"Position of the valve (= demanded heat) where 0% is fully closed and 100% is fully open","name":"pi_heating_demand","property":"pi_heating_demand","type":"numeric","unit":"%","value_max":100,"value_min":0}],"type":"climate"},{"access":1,"description":"Link quality (signal strength)","name":"linkquality","property":"linkquality","type":"numeric","unit":"lqi","value_max":255,"value_min":0}],"model":"WV704R0A0902","options":[{"access":2,"description":"Controls the temperature unit of the thermostat (default celsius).","name":"thermostat_unit","property":"thermostat_unit","type":"enum","values":["celsius","fahrenheit"]},{"access":2,"description":"Set to false to disable the legacy integration (highly recommended), will change structure of the published payload (default true).","name":"legacy","property":"legacy","type":"binary","value_off":false,"value_on":true}],"supports_ota":false,"vendor":"Schneider Electric"},"friendly_name":"0x50325ffffxxxxxxx","ieee_address":"0x50325ffffxxxxxxx","status":"successful","supported":true},"type":"device_interview"}'
info 2022-11-28 20:30:57: Configuring '0x50325ffffxxxxxxx'
info 2022-11-28 20:30:57: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"message":"interview_successful","meta":{"description":"Wiser radiator thermostat","friendly_name":"0x50325ffffxxxxxxx","model":"WV704R0A0902","supported":true,"vendor":"Schneider Electric"},"type":"pairing"}'
info 2022-11-28 20:30:57: MQTT publish: topic 'homeassistant/sensor/0x50325ffffxxxxxxx/pi_heating_demand/config', payload '{"availability":[{"topic":"zigbee2mqtt/bridge/state"}],"device":{"identifiers":["zigbee2mqtt_0x50325ffffxxxxxxx"],"manufacturer":"Schneider Electric","model":"Wiser radiator thermostat (WV704R0A0902)","name":"0x50325ffffxxxxxxx","sw_version":"f60f643"},"entity_category":"diagnostic","icon":"mdi:radiator","json_attributes_topic":"zigbee2mqtt/0x50325ffffxxxxxxx","name":"0x50325ffffxxxxxxx pi heating demand","state_topic":"zigbee2mqtt/0x50325ffffxxxxxxx","unique_id":"0x50325ffffxxxxxxx_pi_heating_demand_zigbee2mqtt","unit_of_measurement":"%","value_template":"{{ value_json.pi_heating_demand }}"}'
info 2022-11-28 20:30:57: MQTT publish: topic 'homeassistant/climate/0x50325ffffxxxxxxx/climate/config', payload '{"action_template":"{% set values = {None:None,'idle':'off','heat':'heating','cool':'cooling','fan_only':'fan'} %}{{ values[value_json.running_state] }}","action_topic":"zigbee2mqtt/0x50325ffffxxxxxxx","availability":[{"topic":"zigbee2mqtt/bridge/state"}],"current_temperature_template":"{{ value_json.local_temperature }}","current_temperature_topic":"zigbee2mqtt/0x50325ffffxxxxxxx","device":{"identifiers":["zigbee2mqtt_0x50325ffffxxxxxxx"],"manufacturer":"Schneider Electric","model":"Wiser radiator thermostat (WV704R0A0902)","name":"0x50325ffffxxxxxxx","sw_version":"f60f643"},"json_attributes_topic":"zigbee2mqtt/0x50325ffffxxxxxxx","max_temp":"30","min_temp":"7","name":"0x50325ffffxxxxxxx","temp_step":1,"temperature_command_topic":"zigbee2mqtt/0x50325ffffxxxxxxx/set/occupied_heating_setpoint","temperature_state_template":"{{ value_json.occupied_heating_setpoint }}","temperature_state_topic":"zigbee2mqtt/0x50325ffffxxxxxxx","temperature_unit":"C","unique_id":"0x50325ffffxxxxxxx_climate_zigbee2mqtt"}'
info 2022-11-28 20:30:57: MQTT publish: topic 'homeassistant/sensor/0x50325ffffxxxxxxx/linkquality/config', payload '{"availability":[{"topic":"zigbee2mqtt/bridge/state"}],"device":{"identifiers":["zigbee2mqtt_0x50325ffffxxxxxxx"],"manufacturer":"Schneider Electric","model":"Wiser radiator thermostat (WV704R0A0902)","name":"0x50325ffffxxxxxxx","sw_version":"f60f643"},"enabled_by_default":false,"entity_category":"diagnostic","icon":"mdi:signal","json_attributes_topic":"zigbee2mqtt/0x50325ffffxxxxxxx","name":"0x50325ffffxxxxxxx linkquality","state_class":"measurement","state_topic":"zigbee2mqtt/0x50325ffffxxxxxxx","unique_id":"0x50325ffffxxxxxxx_linkquality_zigbee2mqtt","unit_of_measurement":"lqi","value_template":"{{ value_json.linkquality }}"}'
debug 2022-11-28 20:30:57: Received MQTT message on 'homeassistant/sensor/0x50325ffffxxxxxxx/pi_heating_demand/config' with data '{"availability":[{"topic":"zigbee2mqtt/bridge/state"}],"device":{"identifiers":["zigbee2mqtt_0x50325ffffxxxxxxx"],"manufacturer":"Schneider Electric","model":"Wiser radiator thermostat (WV704R0A0902)","name":"0x50325ffffxxxxxxx","sw_version":"f60f643"},"entity_category":"diagnostic","icon":"mdi:radiator","json_attributes_topic":"zigbee2mqtt/0x50325ffffxxxxxxx","name":"0x50325ffffxxxxxxx pi heating demand","state_topic":"zigbee2mqtt/0x50325ffffxxxxxxx","unique_id":"0x50325ffffxxxxxxx_pi_heating_demand_zigbee2mqtt","unit_of_measurement":"%","value_template":"{{ value_json.pi_heating_demand }}"}'
debug 2022-11-28 20:30:57: Received MQTT message on 'homeassistant/climate/0x50325ffffxxxxxxx/climate/config' with data '{"action_template":"{% set values = {None:None,'idle':'off','heat':'heating','cool':'cooling','fan_only':'fan'} %}{{ values[value_json.running_state] }}","action_topic":"zigbee2mqtt/0x50325ffffxxxxxxx","availability":[{"topic":"zigbee2mqtt/bridge/state"}],"current_temperature_template":"{{ value_json.local_temperature }}","current_temperature_topic":"zigbee2mqtt/0x50325ffffxxxxxxx","device":{"identifiers":["zigbee2mqtt_0x50325ffffxxxxxxx"],"manufacturer":"Schneider Electric","model":"Wiser radiator thermostat (WV704R0A0902)","name":"0x50325ffffxxxxxxx","sw_version":"f60f643"},"json_attributes_topic":"zigbee2mqtt/0x50325ffffxxxxxxx","max_temp":"30","min_temp":"7","name":"0x50325ffffxxxxxxx","temp_step":1,"temperature_command_topic":"zigbee2mqtt/0x50325ffffxxxxxxx/set/occupied_heating_setpoint","temperature_state_template":"{{ value_json.occupied_heating_setpoint }}","temperature_state_topic":"zigbee2mqtt/0x50325ffffxxxxxxx","temperature_unit":"C","unique_id":"0x50325ffffxxxxxxx_climate_zigbee2mqtt"}'
debug 2022-11-28 20:30:57: Received MQTT message on 'homeassistant/sensor/0x50325ffffxxxxxxx/linkquality/config' with data '{"availability":[{"topic":"zigbee2mqtt/bridge/state"}],"device":{"identifiers":["zigbee2mqtt_0x50325ffffxxxxxxx"],"manufacturer":"Schneider Electric","model":"Wiser radiator thermostat (WV704R0A0902)","name":"0x50325ffffxxxxxxx","sw_version":"f60f643"},"enabled_by_default":false,"entity_category":"diagnostic","icon":"mdi:signal","json_attributes_topic":"zigbee2mqtt/0x50325ffffxxxxxxx","name":"0x50325ffffxxxxxxx linkquality","state_class":"measurement","state_topic":"zigbee2mqtt/0x50325ffffxxxxxxx","unique_id":"0x50325ffffxxxxxxx_linkquality_zigbee2mqtt","unit_of_measurement":"lqi","value_template":"{{ value_json.linkquality }}"}'
error 2022-11-28 20:30:58: Failed to configure '0x50325ffffxxxxxxx', attempt 1 (Error: Bind 0x50325ffffxxxxxxx/1 genPowerCfg from '0x00212effff05b9fb/1' failed (Error: status: 140)
at DeconzAdapter.bind (/app/node_modules/zigbee-herdsman/src/adapter/deconz/adapter/deconzAdapter.ts:768:19)
at Endpoint.bind (/app/node_modules/zigbee-herdsman/src/controller/model/endpoint.ts:567:13)
at Object.bind (/app/node_modules/zigbee-herdsman-converters/lib/reporting.js:40:9)
at Object.configure (/app/node_modules/zigbee-herdsman-converters/devices/schneider_electric.js:220:13)
at Configure.configure (/app/lib/extension/configure.ts:115:13))
debug 2022-11-28 20:31:05: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'wiserDeviceInfo', data '{"deviceInfo":"ADC,1412,1371,1,204,-32768,2000,0,0,100,212,227,237"}' from endpoint 1 with groupID null
info 2022-11-28 20:31:05: Configuring '0x50325ffffxxxxxxx'
info 2022-11-28 20:31:05: MQTT publish: topic 'zigbee2mqtt/0x50325ffffxxxxxxx', payload '{"ADC":"1412,1371,1,204,-32768,2000,0,0,100,212,227,237","linkquality":255,"local_temperature":20.4,"occupied_heating_setpoint":20,"pi_heating_demand":null,"running_state":null}'
debug 2022-11-28 20:31:05: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'wiserDeviceInfo', data '{"deviceInfo":"ALG,1,1,200,204,-4,0,0,0,0,0,100"}' from endpoint 1 with groupID null
info 2022-11-28 20:31:05: MQTT publish: topic 'zigbee2mqtt/0x50325ffffxxxxxxx', payload '{"ADC":"1412,1371,1,204,-32768,2000,0,0,100,212,227,237","ALG":"1,1,200,204,-4,0,0,0,0,0,100","linkquality":255,"local_temperature":20.4,"occupied_heating_setpoint":20,"pi_heating_demand":0,"running_state":null}'
debug 2022-11-28 20:31:05: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'haDiagnostic', data '{"lastMessageLqi":148,"lastMessageRssi":-63}' from endpoint 1 with groupID null
debug 2022-11-28 20:31:05: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'haDiagnostic', data '{"57345":65534}' from endpoint 1 with groupID null
debug 2022-11-28 20:31:05: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'wiserDeviceInfo', data '{"deviceInfo":"RST,06,0601,346951ms ago."}' from endpoint 1 with groupID null
Finally, worth mentioning that the device is removed entirely from /config/zibee2mqtt/database.db and state.json once it is removed from the UI - which is what you’d expect - so if there’s an artefact somewhere it might be elsewhere. After re-pairing, the device appears in both files but its entry in database.db is notably smaller than those of the other two identical TRVs. Which, if it’s ignoring messages from the device, may also be what you’d expect.
Has it fulfilled all the bindings as the others?
If the interview/configuration is non-successful then you can try during the interview/configuration to twist the head to keep the device “awake”.
Also, as a test, you can try to reset the device twice.
At the end in the log the configuration finished with or without an error? Do you see the Failed to configure '0x50325ffffxxxxxxx', attempt 1 (Error: Bind 0x50325ffffxxxxxxx/1 genPowerCfg from '0x00212effff05b9fb/1' failed (Error: status: 140) multiple times or only once?
It had not fulfilled the bindings. The error was also repeated multiple times (at least 3, possibly 4).
However, there’s some hopeful news this morning. Inspired by your suggestions to “try to reset the device twice” and also to “restart Z2M”, I have now got Bind, Reporting, and State tabs which are consistent with the other two TRVs. And no errors in the logs.
I’ve had the TRV batteries out overnight. It may not be necessary to wait that long: think I read a suggestion to try that with a different Wiser device. Maybe a minute or two is required, if at all?
Starting with the TRV force removed from Z2M and the TRV with batteries out, detailed steps:
So the TRV, which used to work fine and has only experienced this issue over the past week, now appears to be in a state consistent with the other two identical TRVs, which have continued to work correctly.
Will this fix the 20°C issue? I’ll let you know in a few hours… 
I experienced that with Z2M, if the device was forced removed and the paired back, Z2M was not doing a full interview and configuration. That’s why I suggested that step, before pairing.
For the missing binding, if the device failed on the power configuration binding, that means the whole binding part hasn’t finished of the code as it exited with and error message.
If the device stops doing the 20C resets, then it means, it needs to have these bindings for correct operation.
{
zigbeeModel: ['iTRV'],
model: 'WV704R0A0902',
vendor: 'Schneider Electric',
description: 'Wiser radiator thermostat',
fromZigbee: [fz.ignore_basic_report, fz.ignore_haDiagnostic, fz.ignore_genOta, fz.ignore_zclversion_read,
fz.legacy.wiser_thermostat, fz.legacy.wiser_itrv_battery, fz.hvac_user_interface, fz.wiser_device_info],
toZigbee: [tz.thermostat_occupied_heating_setpoint, tz.thermostat_keypad_lockout],
exposes: [exposes.climate().withSetpoint('occupied_heating_setpoint', 7, 30, 1).withLocalTemperature(ea.STATE)
.withRunningState(['idle', 'heat'], ea.STATE).withPiHeatingDemand()],
configure: async (device, coordinatorEndpoint, logger) => {
const endpoint = device.getEndpoint(1);
const binds = ['genBasic', 'genPowerCfg', 'hvacThermostat', 'haDiagnostic'];
await reporting.bind(endpoint, coordinatorEndpoint, binds);
await reporting.batteryVoltage(endpoint);
await reporting.thermostatTemperature(endpoint);
await reporting.thermostatOccupiedHeatingSetpoint(endpoint);
await reporting.thermostatPIHeatingDemand(endpoint);
// bind of hvacUserInterfaceCfg fails with 'Table Full', does this have any effect?
await endpoint.configureReporting('hvacUserInterfaceCfg', [{attribute: 'keypadLockout', reportableChange: 1,
minimumReportInterval: constants.repInterval.MINUTE, maximumReportInterval: constants.repInterval.HOUR}]);
},
},
For getting the device “depleted”, it is enough to twist the head a few times after you removed the battery.
It has reset to 20°C. 
I noticed, just before it changed, that three lights flashed: red-???-blue (??? = presumably green or yellow - can’t remember which)
See what you think of the logs. It appears to me that something external to the TRV is making the change to 20°, based on an entry at 10:59:58, unless the TRV itself is publishing to the topic? Is there a way to trace the source of a message? I’ve enabled debug logging on the MQTT broker
Zigbee2MQTT:debug 2022-11-29 10:58:44: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'wiserDeviceInfo', data '{"deviceInfo":"ADC,1485,1487,3,185,-32768,1500,0,0,100,185,185,189"}' from endpoint 1 with groupID null
Zigbee2MQTT:info 2022-11-29 10:58:44: MQTT publish: topic 'zigbee2mqtt/0x50325ffffxxxxxxx', payload '{"ADC":"1485,1487,3,185,-32768,1500,0,0,100,185,185,189","ALG":"1b,1,150,185,-35,0,0,0,0,0,100","MOT":"CloseValve","battery":88,"boost":"None","keypad_lockout":"unlock","linkquality":255,"local_temperature":18.5,"occupied_heating_setpoint":15,"pi_heating_demand":0,"running_state":null,"voltage":2.9}'
Zigbee2MQTT:debug 2022-11-29 10:58:44: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'wiserDeviceInfo', data '{"deviceInfo":"ALG,1b,1,150,185,-35,0,0,0,0,0,100"}' from endpoint 1 with groupID null
Zigbee2MQTT:info 2022-11-29 10:58:44: MQTT publish: topic 'zigbee2mqtt/0x50325ffffxxxxxxx', payload '{"ADC":"1485,1487,3,185,-32768,1500,0,0,100,185,185,189","ALG":"1b,1,150,185,-35,0,0,0,0,0,100","MOT":"CloseValve","battery":88,"boost":"None","keypad_lockout":"unlock","linkquality":255,"local_temperature":18.5,"occupied_heating_setpoint":15,"pi_heating_demand":0,"running_state":null,"voltage":2.9}'
Zigbee2MQTT:debug 2022-11-29 10:58:45: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'haDiagnostic', data '{"lastMessageLqi":172,"lastMessageRssi":-57}' from endpoint 1 with groupID null
Zigbee2MQTT:debug 2022-11-29 10:59:44: Received Zigbee message from '0x50325ffffxxxxxxx', type 'read', cluster 'genBasic', data '["zclVersion"]' from endpoint 1 with groupID null
Zigbee2MQTT:debug 2022-11-29 10:59:46: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'genOta', data '{"currentFileVersion":56000,"currentZigbeeStackVersion":2,"fileOffset":4294967295,"imageTypeId":513,"imageUpgradeStatus":0,"manufacturerId":4190}' from endpoint 1 with groupID null
Zigbee2MQTT:debug 2022-11-29 10:59:46: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'wiserDeviceInfo', data '{"deviceInfo":"NWK,WiserHeatUserRejoin,3874,4240"}' from endpoint 1 with groupID null
Zigbee2MQTT:debug 2022-11-29 10:59:46: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'hvacUserInterfaceCfg', data '{"keypadLockout":0}' from endpoint 1 with groupID null
Zigbee2MQTT:info 2022-11-29 10:59:46: MQTT publish: topic 'zigbee2mqtt/0x50325ffffxxxxxxx', payload '{"ADC":"1485,1487,3,185,-32768,1500,0,0,100,185,185,189","ALG":"1b,1,150,185,-35,0,0,0,0,0,100","MOT":"CloseValve","battery":88,"boost":"None","keypad_lockout":"unlock","linkquality":255,"local_temperature":18.5,"occupied_heating_setpoint":15,"pi_heating_demand":0,"running_state":null,"voltage":2.9}'
Zigbee2MQTT:debug 2022-11-29 10:59:46: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'genPowerCfg', data '{"batteryVoltage":29}' from endpoint 1 with groupID null
Zigbee2MQTT:info 2022-11-29 10:59:46: MQTT publish: topic 'zigbee2mqtt/0x50325ffffxxxxxxx', payload '{"ADC":"1485,1487,3,185,-32768,1500,0,0,100,185,185,189","ALG":"1b,1,150,185,-35,0,0,0,0,0,100","MOT":"CloseValve","battery":88,"boost":"None","keypad_lockout":"unlock","linkquality":255,"local_temperature":18.5,"occupied_heating_setpoint":15,"pi_heating_demand":0,"running_state":null,"voltage":2.9}'
Zigbee2MQTT:debug 2022-11-29 10:59:46: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'genPowerCfg', data '{"256":0}' from endpoint 1 with groupID null
Zigbee2MQTT:debug 2022-11-29 10:59:48: Received Zigbee message from '0x50325ffffxxxxxxx', type 'read', cluster 'genBasic', data '["zclVersion"]' from endpoint 1 with groupID null
Zigbee2MQTT:debug 2022-11-29 10:59:48: Received Zigbee message from '0x50325ffffxxxxxxx', type 'commandQueryNextImageRequest', cluster 'genOta', data '{"fieldControl":1,"fileVersion":56000,"imageType":513,"manufacturerCode":4190}' from endpoint 1 with groupID null
Zigbee2MQTT:debug 2022-11-29 10:59:48: Device '0x50325ffffxxxxxxx' requested OTA
Zigbee2MQTT:debug 2022-11-29 10:59:58: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'wiserDeviceInfo', data '{"deviceInfo":"ADC,1486,1483,1,185,-32768,2000,0,435,100,185,186,190"}' from endpoint 1 with groupID null
Zigbee2MQTT:info 2022-11-29 10:59:58: MQTT publish: topic 'zigbee2mqtt/0x50325ffffxxxxxxx', payload '{"ADC":"1486,1483,1,185,-32768,2000,0,435,100,185,186,190","ALG":"1b,1,150,185,-35,0,0,0,0,0,100","MOT":"CloseValve","battery":88,"boost":"None","keypad_lockout":"unlock","linkquality":255,"local_temperature":18.5,"occupied_heating_setpoint":20,"pi_heating_demand":0,"running_state":null,"voltage":2.9}'
Zigbee2MQTT:debug 2022-11-29 10:59:58: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'wiserDeviceInfo', data '{"deviceInfo":"ALG,1,1,200,185,15,435,435,1,435,81,100"}' from endpoint 1 with groupID null
Zigbee2MQTT:info 2022-11-29 10:59:58: MQTT publish: topic 'zigbee2mqtt/0x50325ffffxxxxxxx', payload '{"ADC":"1486,1483,1,185,-32768,2000,0,435,100,185,186,190","ALG":"1,1,200,185,15,435,435,1,435,81,100","MOT":"CloseValve","battery":88,"boost":"None","keypad_lockout":"unlock","linkquality":255,"local_temperature":18.5,"occupied_heating_setpoint":20,"pi_heating_demand":81,"running_state":null,"voltage":2.9}'
Zigbee2MQTT:debug 2022-11-29 10:59:58: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'haDiagnostic', data '{"lastMessageLqi":172,"lastMessageRssi":-57}' from endpoint 1 with groupID null
Zigbee2MQTT:debug 2022-11-29 10:59:58: Received Zigbee message from '0x50325ffffxxxxxxx', type 'attributeReport', cluster 'haDiagnostic', data '{"57345":65534}' from endpoint 1 with groupID null
FWIW, the request for OTA looks like it might be relevant, but a working TRV logged the same activity a few seconds earlier:
Zigbee2MQTT:debug 2022-11-29 10:59:36: Received Zigbee message from 'WorkingTRV', type 'attributeReport', cluster 'haDiagnostic', data '{"lastMessageLqi":192,"lastMessageRssi":-52}' from endpoint 1 with groupID null
Zigbee2MQTT:debug 2022-11-29 10:59:36: Received Zigbee message from 'WorkingTRV', type 'attributeReport', cluster 'haDiagnostic', data '{"57345":59735}' from endpoint 1 with groupID null
Zigbee2MQTT:debug 2022-11-29 10:59:36: Received Zigbee message from 'WorkingTRV', type 'commandQueryNextImageRequest', cluster 'genOta', data '{"fieldControl":1,"fileVersion":56000,"imageType":513,"manufacturerCode":4190}' from endpoint 1 with groupID null
Zigbee2MQTT:debug 2022-11-29 10:59:36: Device 'WorkingTRV' requested OTA
Zigbee2MQTT:debug 2022-11-29 10:59:38: Received Zigbee message from 'WorkingTRV', type 'attributeReport', cluster 'wiserDeviceInfo', data '{"deviceInfo":"ADC,1634,1634,2,130,-32768,1100,0,0,100,130,130,130"}' from endpoint 1 with groupID null
Finally, these entries frequently appear in the MQTT broker logs:
2022-11-29 10:59:46: New connection from 172.30.32.2:43098 on port 1883.
2022-11-29 10:59:46: Client <unknown> closed its connection.
2022-11-29 11:01:46: New connection from 172.30.32.2:44750 on port 1883.
I’m assuming 172.x.x.x is the Docker subnet?
20°C issue 'hack’
There is a fix workaround hack which seems to stop the TRV resetting to 20°C. It has so far remained constant for five days, and I have been able to replicate it multiple times.
I use Zigbee2MQTT but maybe it can be adapted for ZHA.
Step 1: Clean out.
HA: Settings -> Add-Ons -> Zigbee2MQTT).Step 2: Pair TRV. This may appear to work but check whether there are multiple bindings under Z2M: [device] -> Reporting. There should be five but frequently there are none: this means it has only partially paired. You are likely also to see errors in the logs.
If bindings are missing:
In short: restart / reset / re-pair / repeat.
I have found this process has a good chance of success but it’s not an exact science and YMMV.
Step 3: Disable the TRV in Home Assistant between 1h 45m and 2h 15m after successful pairing.
HA: Settings -> Devices & Services -> MQTT (n devices) -> [TRV] -> Edit Settings (pencil icon) -> Toggle 'Enable device'.
It’s a good idea to change the setpoint to something other than 20°C before disabling it, just to prove that it hadn’t changed when you re-enable it. Don’t disable it too early: at around 1h 30m the TRV whirrs and adjusts itself, but if it’s disabled at this time then the hack fails.
At 2h 15m, re-enable the device. It should now stop resetting to 20°C.
Good luck. Feedback welcome.
Can you try to set up an automation to react to the aforementioned message with a heating setpoint publish to the TRV?
Just a blind guess, but this seems to be really suspicious to me…
It seems a reasonable blind guess. WiserHeatUserRejoin consistently appears in the logs about 12 seconds before the TRV reports a new setpoint of 20°C.
Do you know of a way to get the automation to trigger only when the payload includes that string? The following automation trigger triggers on every message but the condition also seems to block every message, and obviously I want to react only to messages that include WiserHeatUserRejoin:
- platform: mqtt
topic: zigbee2mqtt/0x50325ffffxxxxxxx
condition:
- condition: template
value_template: "{{ \"WiserHeatUserRejoin\" in trigger.payload }}"
Incidentally, the ‘hack’ I wrote above held successfully for five days, until I reset the TRV to continue experimenting.