I detailed in post 882 how to use a wait_for_trigger to check and wait for the hub to come online, if it’s offline, to overcome this very problem you are describing about Away Mode, as I have the exact same issue.
See also post 876 for how to create the template binary_sensor on which this is based.
@darcey Thanks for that information - it’s very helpful.
Is this expected behaviour?
This sequence is expected: solid red is when the wifi has authenticated but before the hub has connected to the cloud. The lack of HTTP response during this time is almost certainly related to the cloud connection initialisation blocking HTTP activity until it is stable. Once it is connected, other network activity continues.
Perhaps this leads to confusion over solid vs flashing red state when hub is unreachable? It did for me, when I initially reported it.
Yes, I can understand that this is not ideal when we are looking into network problems in more detail. Importantly, it is very hard to know about the stage between “authenticated” on your wifi network and “DHCP bound” when it has been given an IP address - this is an area we are exploring in particular because we believe there to be some issues here.
just to add when my hub has gone offline for a prolonged period, it never recovers. I must switch in and out of softAP mode.
Switching in and out of SoftAP mode has the side effect of resetting the TCP/IP stack - this was added early in the product’s development as we found it made for a more stable wifi connection having “tinkered” with the access point mode on and off.
It was not the original intention but it does appear to allow users to get the hubs back online without a power cycle. This tells us that the rest of the system is working fine and it really is just the network stack (either at the WiFi level or the TCP/IP stack level) that has an issue. It also means your schedules and heating control will not suffer - but obviously, this is affecting user interaction so we must get to the bottom of it.
Fortunately I am seeing a marked improvement since switching channels on AP.
I welcome that news 
I think this is a multilayered problem: “good” wifi conditions make it harder to reproduce but do not cure it 100%. Equally, we believe poor wifi conditions make it more likely - but we still can’t force it to happen on demand 
We’ll keep pushing.
I would be very thankful if Schneider people could me out.
I have 6 radiator thermostats, 4 are on “0000dac0” and working fine, 2 are on “000008ed” and these are sometimes turning heating on against schedule. Zendesk kept asking me to do basic reset procedure multiple times, but this haven’t helped. Finally they closed ticked and in separate ticket told me: “This can be caused by iteration differences between the units though this will not affect their utility.” BTW, I wasn’t asked to send any logs or details of my hub.
Can you confirm there are devices which can’t be upgraded?
Is there no way for engineers to remotely trigger firmware upgrade?
Thank you!
Hi Roland,
The support team is the best route to getting an answer for you. Having said that, if you direct message me your Mac address I will have a quick look.
Just adding a data point here for somebody who has NOT experienced any drop outs as described above.
Router make/model: Custom pfsense box with Ubiquiti NanoHD ceiling mounted access points
Mesh network/extenders: No
WiFi protocol: Wifi3, fixed channel 6, 20MHz
Approximate distance between Wiser and router: 3 meters through 1 wall.
House wall construction type: Cinder block
Could the polling interval have anything to do with causing this issue, as it is something that I adjusted from default? I have mine set to 2 minutes in the configuration menu.
James,
I have continued to ‘experiment’ this afternoon and looking at what logging I have to ascertain more info.
I can quite easily force the hub into a dropped state that it does not recover from (not within 20 mins anyway). In the main this seems to be by taking some action on my router that restarts the wifi (either changing settings or rebooting the node) and therefore ‘kicking’ the hub off wifi. I have now had both my main and test hub exhibit this behaviour, in some cases a solid light, in others flashing light. I find that I may need to do this only 1 or 2 times on my router to make it happen. As such, I wonder if the light is not an accurate representation of the fault(?).
I have turned up my router logging to max (7 which isn’t as cool as if it were 11!) and I can see the following (note I have done this now 3 times to check and the pattern is consistent and across both hubs):
As @robertwigley has also tested, rebooting the wifi node when the hub is in either flashing or solid state, does not cause the hub to do anything against the wifi node - ie nothing in the logs. Only a setup on/off brings it back. When talking with @jamiebennett previously on drop instances seen before, it could recover after either 40mins or 2hrs (but I didn’t wait that long in this instance) and the tcp respawn count would increase. I am assuming the 40m/2h is some sort of watchdog in the hub to restart the tcp stack?
As I had to do something else, my last test of rebooting the mesh node, which kicked of my main hub and didn’t reconnect was left until it came back online itself. This was exactly 2 hours on a flashing red. I can assume it did a tcp respawn and in the router logs, I see 2 iterations, 1 minute apart of a DHCP DISCOVER, OFFER, REQUEST and ACK.
Message me if you want a copy of the router syslog as I have kept a copy.
This is great information and really helps, thanks.
Hi @jeptech - great to see you here looking into this!
I am also getting almost daily drops, with the HUB displaying a solid red LED (when observed). I cannot confirm wether it is ALWAYS solid red when the connection drops as sometimes it occurs within the early hours of the morning.
No pattern to time of day. Most of the time it’s back online within 40-60mins. A few times it has been offline for 2 hours or more.
The HUB drops off the network as confirmed within my network console.
HUB is connected to a dedicated IOT network, Fixed Channel (1) and assigned a static IP (DHCP reservation) from my router. Wifi signal strength is ~60dBm.
Last drop was 05/10, 03:39 until 04:20.
Your config is similar to my new setup and what I believe led to me seeing improvements.
My AP always seemed to be on channel 1 but was in fact set to auto. I changed to fixed channel 6. It was already on 20Mz only bw. I also increased the polling interval (60s). I made these changes and noticed benefit before upgrading integration to v3.1.7.
My setup
Router make/model: pfsense, Asus RT-N66U in AP mode (reports hub signal about -60dBm).
Mesh network/extenders: No other wifi infrastructure just clients.
WiFi protocol: 802.11gn, fixed channel 6, 20MHz
Approximate distance between Wiser and router: 5m, passing through one internal block wall.
House wall construction type: brick/block
EDIT of previous post re router syslogs
After realising a blonde moment (that the auth messages are actually in the syslog of the node and not passed to the main router syslog - duh!), I have setup a syslog server to capture logs from both nodes. I will monitor if/when I have a drop and see if anything useful.
Also note, the node syslog does have the auth messages when the hub reconnects but there is no auth messages for a hub that did not reconnect. Ie no request or response.
@darcey Looks like our setups are similar and from what I understand you are not experiencing too many issues. I have never had a single dropout as of yet.
Interesting that you have also adjusted the polling interval like me. Could the hub be crashing from overpolling, knocking it offline?
Thank you! I don’t seem to be able to PM you, maybe it’s user level issue? Clicking on any user profile doesn’t give me “letter icon” to direct message.
If you are OK with it, you can share your Wiser MAC address here. There is nothing public facing about it and it is only a partial MAC address shown in the app so there are no security concerns if you are OK with that.
Thank you in advance!
Another drop this morning (early hours) for exactly 2 hours: 00:46 to 02:46. Last drop was 05/10.
It dropped off the network between those times:
Had a 6h 00m 05s drop from 12:31 today.
That’s the longest one I’ve had.
So great and refreshing to see engagement from Schneider on this forum. It really is a great product priced at a reasonable price point (unlike some of the other systems). The ability to control it using home assistant via this integration is invaluable and I really do hope Schneider will continue to allow local access to their products far into the future.
Re: the disconnections I experience them infrequently but they do occasionally happen. Interestingly, it happened this morning - usually I would power cycle the heat hub but after reading on this forum about changing from setup mode and back again, I tried that. However, on this occasion it actually caused the hub to power cycle and once powered on it connected back on to my WiFi network. My network is just a Linksys router running Openwrt as the firewall/router and a number of Unifi APs.
Had another 6h 00m 5s outage. Had 2 in the last 24 hours. Not sure what’s changed to increase the durations on these.
On a side note does anyone know if the Wiser System is about to be made EOL, or specifically the TRVs?
I’ve bought a bigger house and I need 5 more TRVs and have been looking around to get them sorted before we move. Last week I had to replace a TRV under warranty and had to go down the refund and rebuy route as the retailer couldn’t do a straight exchange due to it being over 12 months.
I purchased it at £40 14 months ago, but I had to buy it again at £43 last week. This week they are £53 at the same retailer…but lots of places have them listed at around £35-40 but are on clearance or special offers but nearly everywhere is out of stock. Is this just a stock shortage or is something going on?
I am thinking of changing from Lightwave to Wiser as my LW Boiler switch is knackered and LW is rubbish in HA.
With wiser in HA would be able to do an automation where a trigger from Google Calender will let me alter the temperatures of the Trvs and therefore my heating would come on / go off?
I work shifts so cannot use a schedule.
Many thanks
This is the direct result of a global component shortage. We are making them as fast as we can but demand is very high at the moment.
