So after reading the whole of this thread (which took several days!) I’m just about to dump my Hive for a (UK) Drayton Wiser Kit 2 with a Gen 1 Hub. Even though the Gen 2 Hub (no Thermostat) is now available from CEF for £159.04, Toolstation are currently doing the Kit 2 Gen 1 for £129.99, so it’s a win for Toolstation.
What seems to be a recurring theme in this (long) thread is regular WiFi disconnects, which is something I’ve been experiencing on a regular basis with my ESPHome devices and Amazon Echo Show, even though I know the WiFi Signal Strength for these devices is good. The wierd thing is that looking more closely, it almost always seemed to happen at 09:00 and/or 21:00 and was showing up as Warnings in my Home Assistant log
After digging around in the internal logs on my elderly Synology RT1900ac router, I noticed regular 09:00/21:00 log entries related to the Dynamic Frequency Scheduling system that 5GHz WiFi devices must comply with to gain certification. Avid readers can Google it to find out what it’s purpose is.
As I live nowhere near a radar station and have my 5GHz WiFi set to Channel 48, which is a non-DFS channel, I commented out the relevant entries in the router /etc/crontab and forced a restart of the cron daemon.
Early days, but no ESP disconnections this morning and no dropout of our Amazon Echo Show.
I appreciate that not everyone that experiences these WiFi dropouts is going to have an RT1900ac, but it sure raises the question of whether DFS is a culprit for some people.
Thanks for the heads up. I’ve experienced networking issues with IoT devices, including several wemos D1s as well as the wiser hub. The wiser firmware update definitely helped though.
The 2.4GHz environment has become very crowded here and I’m amazed by the increasing number of stations I see whenever I run a channel scan on my AP.
I’m guessing your ESPHome devices are 2.4GHz. So I don’t understand how 5GHz DFS affects 2.4GHz. But it seems it may be a thing as I have seen it mentioned elsewhere. I’m using OpenWRT and I may try explicitly setting a non DFS channel (rather than auto), which I’m assuming may turn off DFS scanning.
I’m guessing wlan0 is my 2.4GHz network and wlan1 is the 5GHz network (or vice versa), so maybe it’s a bug to have both crontask entries, as like you, I would not have expected 5GHz DFS functionality to have affected the 2.4GHz band.
My understanding of 5GHz Wifi and DFS is that when a 5GHz radio starts up and, either auto or a DFS channel are set, the AP scans the 5GHz range for a non-DFS fallback channel. Then, when/if radar is later encountered, it should instantly switch to this predetermined fallback channel. When on a DFS channel, the kernel must continuously check frames for non-wifi traffic in order to act quickly when needed. I’m guessing therefore that your hourly cron jobs, if related to DFS, are redoing the scan for a fallback channel and might exit, doing nothing, if your AP is already set to use a non DFS channel. Still, it doesn’t explain how this could impact 2.4GHz.
Even though the cron jobs fire every hour, I think there is an additional schedule check being done that is not exposed in the GUI (–exec-schedule) which means that they only do something at 09:00 and 21:00.
This is typical of what regularly appeared in the internal message log until I disabled the cron jobs
May 22 09:00:04 SynologyRouter kernel: [1645150.050000] wl1: wlc_dfs_chanspec: dfs selected chanspec 108 (d06c)
May 22 09:00:04 SynologyRouter kernel: [1645150.060000] wl1: wlc_dfs_sel_chspec: dfs selected channel 108
May 22 09:00:04 SynologyRouter kernel: [1645150.170000] wl1: wlc_set_dfs_cacstate dfs from OFF to ON
May 22 09:00:04 SynologyRouter kernel: [1645150.180000] DFS State IDLE -> IDLE
May 22 09:00:04 SynologyRouter kernel: [1645150.180000] wl1: dfs : state to IDLE channel 48 at 0ms
May 22 09:00:04 SynologyRouter kernel: [1645150.190000] wl1: dfs chanspec d030 is a radar channel, using 60 second CAC time
May 22 09:00:04 SynologyRouter kernel: [1645150.190000] wl1: wlc_dfs_cacstate_init: state to IDLE channel 48
May 22 09:00:04 SynologyRouter kernel: [1645150.520000] wl1: wlc_dfs_chanspec: dfs selected chanspec 104 (d068)
May 22 09:00:04 SynologyRouter kernel: [1645150.530000] wl1: wlc_dfs_sel_chspec: dfs selected channel 104
May 22 09:00:05 SynologyRouter ipv6_change hook event: wlan1 ->fe80::211:32ff:fe50:3dc8 64
May 22 09:00:06 SynologyRouter if_link_up hook event: wl1.1
May 22 09:00:06 SynologyRouter kernel: [1645152.380000] wl1: wlc_set_dfs_cacstate dfs from OFF to ON
May 22 09:00:06 SynologyRouter kernel: [1645152.380000] DFS State IDLE -> IDLE
May 22 09:00:06 SynologyRouter kernel: [1645152.390000] wl1: dfs : state to IDLE channel 48 at 0ms
May 22 09:00:06 SynologyRouter kernel: [1645152.390000] wl1: dfs chanspec d030 is a radar channel, using 60 second CAC time
May 22 09:00:06 SynologyRouter kernel: [1645152.400000] wl1: wlc_dfs_cacstate_init: state to IDLE channel 48
May 22 09:00:06 SynologyRouter kernel: [1645152.590000] wl1: wlc_set_dfs_cacstate dfs from OFF to ON
May 22 09:00:06 SynologyRouter kernel: [1645152.600000] DFS State IDLE -> IDLE
May 22 09:00:06 SynologyRouter kernel: [1645152.600000] wl1: dfs : state to IDLE channel 48 at 0ms
May 22 09:00:06 SynologyRouter kernel: [1645152.610000] wl1: dfs chanspec d030 is a radar channel, using 60 second CAC time
May 22 09:00:06 SynologyRouter kernel: [1645152.620000] wl1: wlc_dfs_cacstate_init: state to IDLE channel 48
May 22 09:00:07 SynologyRouter ipv6_change hook event: wl1.1 ->fe80::11:32ff:fe50:3dca 64
May 22 09:00:09 SynologyRouter if_link_up hook event: gbr0
May 22 09:00:17 SynologyRouter ipv6_change hook event: wlan0 ->fe80::211:32ff:fe50:3dc7 64
May 22 09:00:18 SynologyRouter if_link_up hook event: wl0.1
May 22 09:00:19 SynologyRouter ipv6_change hook event: wl0.1 ->fe80::11:32ff:fe50:3dc9 64
May 22 21:00:03 SynologyRouter if_link_down hook event: wl1.1
May 22 21:00:06 SynologyRouter ipv6_change hook event: wlan1 ->fe80::211:32ff:fe50:3dc8 64
May 22 21:00:06 SynologyRouter kernel: [1688352.640000] wl1: wlc_dfs_chanspec: dfs selected chanspec 44 (d02c)
May 22 21:00:06 SynologyRouter kernel: [1688352.650000] wl1: wlc_dfs_sel_chspec: dfs selected channel 44
May 22 21:00:07 SynologyRouter kernel: [1688352.840000] wl1: wlc_set_dfs_cacstate dfs from OFF to ON
May 22 21:00:07 SynologyRouter kernel: [1688352.840000] DFS State IDLE -> IDLE
May 22 21:00:07 SynologyRouter kernel: [1688352.850000] wl1: dfs : state to IDLE channel 48 at 0ms
May 22 21:00:07 SynologyRouter kernel: [1688352.850000] wl1: dfs chanspec d030 is a radar channel, using 60 second CAC time
May 22 21:00:07 SynologyRouter kernel: [1688352.860000] wl1: wlc_dfs_cacstate_init: state to IDLE channel 48
May 22 21:00:12 SynologyRouter if_link_down hook event: gbr0
May 22 21:00:13 SynologyRouter if_link_down hook event: wl0.1
May 22 21:00:16 SynologyRouter ipv6_change hook event: wlan0 ->fe80::211:32ff:fe50:3dc7 64
And this is typical of what I saw in HA that led me to dig deeper
I completely agree that DFS functionality should not have affected 2.4GHz operation, so I can only assume that this is a cock-up by Synology, which is never going to be fixed as the RT1900ac is now End Of Life
At the risk of stirring a hornets nest, how is this discussion relevant to wiser? I have had very few issues with WiFi since the firmware updates and moving my wiser hub to a dedicated 2.4GHz vlan.
The WiFi dropouts seem to have disappeared as a topic (and in my experience it is not an issue anymore) - I haven’t seen an comments relating to this in this blog for months.
It’s a fair point. Reading the entire thread in a few days you lose track of how recent or not some of the common issues are and I thought it might be interesting to mention. I’ll go back in my cave now
I would like to get an idea of energy usage and efficiency in my system.
Is it possible to download logs into a spreadsheet format covering a few months, of when heating/hot water water was turned on?
My entity for Wiser LTS hearing demand for radiators/underfloor heating, shows 01-100% demand.
a) what would 70% demand mean, as my vaillant boiler can’t be controlled or down regulated by wiser?
b) Does demand mean when its actually turned on, or when it was scheduled to be turned on?
Unrelated - but ever since switching from Nest to Wiser, my hot water from unvented cylinder isn’t as hot as it used to be. I don’t think the temperature on cylinder has been changed. Could Wiser have played a part in this ongoing problem?
What is unclear is whether the new hub still has the standardised backplate allowing for a simple upgrade path. My gut feeling is that it probably doesn’t. I hope I am wrong as that’s a missed opportunity and major annoyance if not.
Great news for British people.
Of course the 2nd generation is a new hardware and software , no upgrade possible and also no migration for the configuration , but home assistant is already compliant…
Do you know if it fits on the standard Drayton backplate? Like this:
EDIT: It appears to have a new backplate.
Can anyone confirm that the exisiting iTRVs and Room Thermostats are compatible with the Gen2 hub and that we don’t need to purchase 2nd Generation versions of them?
At the risk of opening old wounds, can anyone (@jamiebennett) offer any insights into why my Gen 1 Hub appears to go offline (according to Ping integration) for approx 5 mins every couple of hours. It’s connected to (and mac address locked to) my wired Synology RT1900ac Access Point about 2 feet away from it in the loft, which also has some ESPHome devices connected to it which do not go offline. The Hub doesn’t always lose the Wiser Cloud connection, but when it does it seems to happen towards the end of the Hub offline period, which makes me think it’s actually rebooting during these periods. The one time I video recorded what the Hub was doing, it showed the status LED turning red for the duration of the offline period before returning to green.
After fixing my previously mentioned network issues that was causing it to reboot, My hub has been been stable…
Until recently and I am also seeing a similar issue where the Hub is showing the Red light and going offline/not pinging for 5 minutes.
I have sensors set up to record the reboot time/reason but these have not changed in a week or two (since I had an internet outage) so in my case the Hub is not rebooting.
I haven’t been able to catch it going offline while I’ve had the access point management open so I’m not sure if it’s actually disconnecting from the wireless network.
Hmmm. I can’t find a sensor with that name. There is a Hub attribute that tells me the last reset reason (a Soft Reset), but not when it happened so I can line it up with the disconnection periods
