Isn’t demand also reflective of how far open/closed an iTRV is?
not that I have seen, but I have Stats in every room and not just TRV’s, besides most TRV header values, open fully with a 1/4 or half turn, very few have a proper granular value opening, There are LOADS of YouTube vids’s on this, have have to get the top high end TRV Headers to have this.
Thanks, so does that mean this graph is useless for me as the boiler doesn’t have openTherm and therefore only does on/off?
Hi All. Is there a way to add the passive mode toggle within HA’s thermostat card?
I would say, yes.
I will take a stab. I think these errors are due to network issues: Failure to communicate with the hub or not receiving all packets of an http response. I see these occassionally and whilst the error messages have changed over time, presumably due to HA & integration upgrades, the underlying cause is the same, flaky hub networking stack/OS.
I never heard of this before. Mine, when they’ve a traditional TRV fitted, seem to work as I’d expect. Noticable differences between each position. Certainly discernable from 1 to 4 at any rate.
so you are saying that the rad changes temp (when TRV is open, not when closed) depending on the TRV setting, TRV are only designed to open or close depending on room temp. I.E, open or closed, but TRV like tado or wiser are supposed to open bit by bit, to supposedly control the flow of water through the rad, to allow the rad from getting to hot etc (for standard boilers), but as I said most TRV body valves become fully open on the slightest open.
I think you mean the room temp is different between settings, that is NOT what what I am talking about.
1 Like
I was being thick! Turning a traditional TRV head doesn’t directly translate to movement of the valve pin.
WRT to Wiser TRVs, I did feel the graduated opening of the valves was kind of effective here but could be wrong (again)!
Thanks. I will drop a line to Wiser support and see what they have to say
Check too that your hub is on the latest firmware. Wiser addressed some networking issues in one of the updates.
So, for anyone else who has been having their original HubR dropping the WiFi connection constantly, get a really old WiFi extender. For whatever reason, the Wiser network stack hates anything that isn’t a plain 2.4ghz wpa2 network with absolutely no bells and whistles.
I’ve just switched from a Linksys Velop mesh (which was generally a pig to manage) to a super cheap Mercusys H60x mesh. Amusingly, despite the whole new system costing less than a single node of the old one, it’s infinitely more stable, apart from the Wiser hub which hated it. Constant reconnect attempts, dropped connections and resets, the works. It could stay connected for one specific node for about 45 mins, then just gave up.
I had an old TPLink TL-WA854RE Amazon.co.uk kicking around, so I set it up as a repeater with the same network name as my mesh WiFi and blocked the Wiser hub from the mesh only. The hub instantly joined onto the repeater and, for the first time ever, has kept its connection solidly for more than a few hours. Not a single error or missed update in Home Assistant.
2 Likes
Yes it is a bit bizarre how badly the hub behaves on mesh systems. I have a Tplink Deco mesh, and it would work fine for weeks on that and then go really unreliable for weeks, no discernable reason that I could ever find. Everything else uses the mesh and it is rock solid, nothing has any trouble with it. I now have the hub connect direct to the wifi on my main router instead of the mesh and it is perfectly happy there.
Hi all,
I know a few people have downloaded the v3.4.9 release today and reported issues. Firstly, apologies for that. I do try and ensure a smooth upgrade journey but looks like this wasn’t the case.
Anyway, v3.4.9 has been pulled as I suspect it will cause issues for many people. It has been replaced by a fixed v3.4.10 which should not cause issue.
It fixes a number of issues.
4 Likes
it is probably due to that fact that the Wiser HubR only supports WiFi1, and many new WiFi routers supplied by ISP’s etc, dropped support support for this a long time ago, I use Unfi U6+ and it seems to have zero issues.
“Wifi 1” in Unifi just means IEEE 802.11b though, which basically every 2.6GHz capable access point should support. Hell, my mesh and the repeater I’m using support exactly the same set of specs on the 2.6 network, 802.11 b/g/n.
The really odd bit is that the hub can connect to most mesh systems… for just long enough to get a DHCP request out, get assigned an IP and ping the cloud servers. And then it faceplants. Presumably the mesh AP tries to upgrade the Hub’s connection or channel shift it or something and that makes the Wiser network stack absolutely sh*t itself. Which is just bizarre, if it was properly identifying it’s capabilities and handling “unknown” WiFi frames gracefully, like it should be, there’d be no issues.
Hang on… As I wrote that slight rant, something hit me. Does your Unifi system have band steering turned on in the WiFi settings on the controller?
No, I have separate 2.4Ghz and 5Ghz SSID’s, (I found) having them joined causes nothing but issues for older standards.
Yep, it’s band steering / client steering. Since it’s not actually a part of the b spec as such, the AP just tries to nudge clients to the preferred band or AP via the incredibly cunning tactic of just not responding to the client and hoping it will reconnect to the “right” AP.
So the hub sees the AP but can’t get a response, and just blindly shouts at it until a timeout happens or its DHCP lease expires. Then it reconnects, and the cycle happens again until it lands on the “right” AP. Which in a three node mesh is a 1 in 3 chance each disconnect cycle, and at any point the definition of “right” might change and the whole thing starts again.
Thanks for that. I have TP-Link Deco pushing wifi around the big stone pile so it looks like a few quid invested in a low tech repeater may be a worthwhile experiment