I’ve got the same issues, a couple of TRVs and a Conbee2 using zigbee2mqtt. 2 hours after changing the set point, it reverts to 20c.
One thing to add to this is that I monitored the mqtt messages when the change happened and there were no messages sent from Home Assistant, so the change happens on the TRV.
So I’m guessing the standard (non-HA) mode of operation is to send an update to the TRVs (maybe every hour?) to let them know they should keep their set point.
So, my next step will be to see if I can set that up, either in HA or Z2M.
It just changed after half an hour! This makes me think there’s some kind of internal clock in the TRV, but that seems really odd that it’s not holding the temp for longer. I think I need to do some more investigation, I wonder what logging I can get out of Z2M…
Now when posting this up I realised that I set it to monitor messages about the HallTRV rather the study one, but that doesn’t change my point, as it’s regularly reminding the system what the TRV setpoint should be.
When running this, I see the mqtt messages bounce back and forth, so it’s sending them, but after 2 hours, the setpoint changed back to 20C, then got bounced back up to 27C but the next mqtt message.
One of two things are happening here:
Zigbee2MQTT is ignoring the setpoint message if I’m setting it to the current setpoint. This seems reasonable, if it knows that’s the state of the device, there’s no need to waste battery sending that message.
The device is ignoring this anyway and changing it’s setpoint to 20C 2 hours after it was last changed. If this is the case, I don’t understand how the designers of these TRVs were expecting it to work.
@madbobmcjim it’s really frustrating as I just not knowledgeable enough to delve deeper into all of this. I’m still loathed to buy a hub for the TRV, I only bought one of these TRVs as a “test”. So, so far the test has been a dud
I’m just not knowledgeable enough to dig deep into all of this. I’ve tried to look over the logs, the same as yourself and it’s not really giving me any pointers at to what the problem is. I do think there is a secondary “network chatter” happening between the hub and the TRV.
I changes the temperature through HA to 28c. This can be observed @ 2022-03-01 17:07:38 // temperature=28.0
Waited for a few minutes and then observed the reference to “20c” in the logs (2022-03-01 17:09:02), yet in the HA GUI, I still saw the TRV set to 28c!
So my thought is, what are all of these attributes? And how do we set these and send the data to the TRV!?:
It’s all a little crazy, what and where are these “attributes”?
This article is an interesting read, seems a similar problem to what we’re facing?
I’m going to alter the state attributes for the TRV, so it should default to 19c rather than 20c, it’ll be a while before I can observe if the reset take affect.
Ok, so I attempted to “set state” the occupied_heating_setpoint to 1900, but when I do this and refresh my browser, the value is changed back to 2000. Which is a bit of a pain.
On your first question, I hear the motor turn when I alter the setpoint, so I’m happy that the TRV is responding to the requests.
The problem with your setup is that you’ve got a heating setpoint and a cooling setpoint, and moving the slider seems to be altering the cooling setpoint. These should be for AC systems rather than TRVs, so I’m not sure why ZHA does this. I had this when I was originally on ZHA, but the cooling setpoint vanished when I moved everything to Z2M.
Also, I’ve ordered a second Zigbee device to try and sniff the packets going over the air, so hopefully that’ll show me what’s going on.
I need to see if I can make it trigger on any TRV update, not just the study one, and then see if I can pass the TRV that triggered it into the payload template.
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!
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
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.
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)
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 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
Complete reset of TRV / force remove from Z2M / leave batteries out for 48+ hours
Manually setting the keypad_lockout attribute through Z2M’s Dev Console (seemed hopeful but ultimately fruitless)
What I’m wondering
Why the Binding and Reporting is different?
Whether there is some artefact left either in HA / Z2M or the TRV itself which prevents a ‘clean’ installation / pairing, leading to the different Binding and Reporting? Would the same issue occur on a fresh HA installation, for instance? I don’t have a spare to test, unfortunately.
Whether it’s possible to force all the attributes in the State report manually (TBC)?
I’ll keep playing and will report with anything useful. If you have any ideas you’d like tested, please suggest them.
) that it is the 4th Zigbee network in the House. 
