So, looking good so far - installed the beta around 19:30 yesterday, no disconnections from the wifi or cloud so far - that’s probably but the mockers on it now, but looking good.
1 Like
Yeah im not so sure. Mine disconnected again this morning for 40 mims but if it reduces it then maybe were heading in the right direction. I have some other things to try too.
1 Like
It is possible to pair the iTRVs directly with ZHA or Zigbee2MQTT rather than use this integration and without the Wiser Hub.
However you then need to figure out how to get the iTRV to tell the Nest system to start and stop your boiler. Since the Nest system is really designed to work with only one Nest thermostat (or one Nest thermostat per zone) I think this will be difficult. You need an integration that allows some level of overriding the Nest logic and triggering the boiler based on external thermostats.
I used Nest in a prior home and it was a pretty closed system as I recall. Google shut down their Works with Nest program, resulting in integrations disappearing and even stopping working. Things may have improved since, but Google seems to do this kind of thing all the time so that was the end of using Google for home automation for me. When I moved house I avoided it and found Wiser which I am far happier with.
I don’t see anything in the Nest HA integration documentation that allows control of the Nest Thermostat. It appears more focussed on using the Nest to trigger other things. If you have a Nest and can play around with it you may find more.
IMHO Wiser is far superior to Nest in terms of functionality and usability. The Nest Thermostat does look pretty nice, but once I had configured it, I barely glanced at it again - it isn’t really worth the premium or the risk of getting stranded in a closed off ecosystem.
Thank you. Im new to home assistant and I’ve set up with Zigbee2MQTT from the start
Thank you. I actually don’t intend to get the TRV to fire the boiler. I don’t want individual rooms calling for heat and cycling the boiler. I have 2 nest zones and one if them only has a single rad with no TRVs. I only want to use this to set the TRVs independent if the thermostat.
With smart things you can control the nest again now. I’m hoping HA can do the same. Not got round to enabling it yet
The Nest(s) will always be the master.
If you set the TRVs lower than the Nests then the boiler will run when you don’t want to heat the rooms any more. You are burning gas to heat water in pipes but not radiators.
Set them higher than the Nest and the Nest will shut the boiler off when it detects the setpoint is reached whatever the iTRVs detect, and the room never reaches the temp you wanted.
In either case you would save money by just sticking with old school TRVs IMHO.
Update, no further disconnections of the hub or cloud, however I now seem to be getting more cases of iTRVs, especially those with weaker signals, losing their connection to the hub, could this be related?
Under normal circumstances I would say this can’t be related, however, I am seeing a similar situation but only one of mine with a normally poor signal is doing this.
Thought it was just a coincidence but how very wierd!?
Has anyone else tried out the beta version? Can you report back situation so far re hub WiFi drops and if you also see trvs dropping off more.
The short answer is yes…
BUT, I would suggest not to do that. Z2M supports it to some extent, but it is painful.
@jamiebennett might can confirm, but the Wiser TRVs are not certified Zigbee devices. They do use the Zigbee protocol for communication, but they do not follow it according the whole standard’s requirements.
I started to experiment with the TRVs a few years ago, when I got my hand on a handful of it and a starter kit for some ridiculously cheap money.
I wrote a device handler for those TRVs for SmartThings and some other people tested it as well, but the results were a mixture. My TRVs reacted to the standard Zigbee commands, meanwhile other people with newer firmware on their TRVs had issues.
I have migrated to Z2M and used my TRVs with that setup. For me it was working again, but I talked with people with different firmware versions, that their TRVs do reset back after 2 hours to 20 Celsius.
Last winter was the time when I pulled the trigger and pulled out the Hub to control the TRVs. They work flawlessly with the Hub. I did not use the Hub before as my heating system is really complicated with floor heating, radiators and a fireplace which can heat the house as well, not just a simple gas burner. Meawhile the heater has been replaced and it is a condensation heater which supports modulation also. So no chance that I will put the Hub in use with that, but I can meanwhile control the TRVs with the standalone Hub and through HA I can also feed back information to the heater also.
All the Wiser TRVs and the Room Stat uses a manufacturer specific Zigbee cluster with proprietary communication. I did ask years ago support about it to provide some help, as if they will support integration without the Hub to other systems like SmartThings, they could sell more of their devices without the burden of their cloud infrastructure. They were not interested.
As the TRVs are not Zigbee certified, the complete control of the TRVs are going through the manufacturer specific clusters. Probably that is the reason why people were hitting this resetting temperature issue. There wasn’t enough will to reverse engineer the whole Hub-TRV communication process. (Sniff the Zigbee communication and decode how the Hub keeps the TRVs on temperature.)
At some point regarding the different firmware versions, the TRVs were not even reacting to the standard Zigbee set temperature commands either…
I played enough with them individually that I can honestly say, just use it with a Hub.
The interesting thing in the story that Schneider Electric is/used to be a Zigbee Alliance member. And they are member of the Connectivity Standards Alliance as well. Also the Matter work group. But if you search the Drayton Wiser website, the only place where Zigbee is mentioned is this article in their blog:
All documentation just states that the devices are using a 2.4Ghz frequency for communication.
2 Likes
Actually, the iTRV is Zigbee compliant but it does, like many other Zigbee devices on the market, have vendor-specific extensions. In fact, the iTRV sold in the UK closely follows the HA 1.2 spec but has extensions around, for example, the boost behaviour. In short, I would always recommend keeping the hub in the loop as there is a lot of logic in there that makes the iTRV operate more optimally.
Schneider is a very prominent voice in both alliances. To most people, Zigbee doesn’t mean anything. It’s like talking about 2.4ghz to somebody who just wants to browse the internet on their phone. It’s a communications method but the real value is in what you do with that which is why we don’t talk too loudly about enabler technologies. Having said that, Schneider makes a lot of devices globally, some like the devices we sell into the Nordics are 100% certified Zigbee 3.0, others are pure HA 1.2, others still are HA 1.2 with extensions. This only matters when you want to use the devices without the Wiser hub which is not a supported use case today.
3 Likes
I’ve only been running the beta since yesterday but the hub dropped from my network this morning for just under an hour. Will post further updates once it’s been running for a couple of days to see if it’s reducing the drop-outs overall.
Good choice. It’s a little more complex to use, but is more powerful than ZHA.
Thanks for the update Mark.
So far for me no drops of the hub from the wifi or cloud disconnections since I installed the beta. However as I said, like you, I’ve had a number of iTRV drop outs from those with normally poor signals.
Let me know if you want me to try anything specific.
Whilst possible I wouldnt , id just sell the nest themostats and go full drayton wiser. When I originally built the integration my main objective was it “supplemented” the wiser hub and not replaced it. I used to have a Max Eq3 and I went this route and it was an unreliable living hell… (well the wife made it living hell 
)…
2 Likes
For people having WiFi dropout issues, can you tell me what network setup you have? Ideally:
Router Make/Model:
Mesh Network/Extenders: Yes/No (If yes, what extender/mesh product):
Wifi Protocol Used (If known):
Approximate distance between Wiser and the router / extender:
House wall construction type:
Feel free to direct message me if you don’t want to post it publicly.
What I am trying to understand is if there is any commonality between the type of network being used and the disconnections.
1 Like
Mine did this too but has been stable since with no drops (albeit its only been a couple of days but was getting one most days and sometimes 2 a day). There maybe a need to reboot the hub once beta installed to clear any IP connections that have built up. This drop off (from what I have been looking at, probably restarted the TCP stack on the hub and cleared any open connections in the same way a restart of the hub would do).
Be very interested to see how it performs over the next few days and if you see a reduction in drop outs.
2 Likes
Anyone else’s hub gotten worse with wifi disconnections/going unavailable? Mines now dropping either several times a day for very short periods or its going offline for 4h00m5s instead of 2h00m5s.
Trying to work out if its coincided with a faulty TRV or not.
Edit: Just read the posts backwards to get to the one about the beta. I’ll give that a go. I do generally have good connections but only as I have a plug as a booster. I’ll try initially with the plug on and then I’ll try with teh plug off to force a poorer signal and see if that’s any different.
Router Make/Model: synology RT2600ac
Mesh Network/Extenders: no
Approximate distance between Wiser and the router / extender: 8m
House wall construction type: cinder block and plasterboard
If I can provide you more informations that should be helpful for Schneider and our community feel free to ask them
1 Like
In my previous life, when we try to open a connection, we ask first to close any connection before. May be for debug it should be interesting to count the connections opened.