see my post 908
Sometimes the communication between HA and the Wiser hub stop.
sometimes the led of the wiser hub stay in green sometimes in red or red blinking.
I read all the conversations on the forum; I imagine another scenario.
My scenario
For my point of view the WiserHub can manage a certain number of connections as server.
In this case there are two ways to recover:
Wait until the Wiserhub close the connection on time out
A power cycle clears all the connections and then the communications capability is available again.
I âve made some tests
In HA I restart the system and I check the communication on Wireshark.
In the following example, I made it 6 times. For the 5 firsts the communication restart but the 6th Iâve got an issue
The Issue starts at 14:54:21.649 and ends at 13:31:16:.270, so time-out is about 36:54.
Another same test :
2202.09.01 an issue began at 17:01:23 and stopped at 20:06:35
I couldnât ping the wiser hub
the led was Red
after a power cycle on the Wiser Hub the communication restart normally
Sometimes the communication between HA and the Wiser hub stop.
sometimes the led of the wiser hub stay in green sometimes in red or red blinking.
I âve made some tests
In HA I restart the system and I check the communication on Wireshark. In the following example, I made it 6 times. For the 5 firsts the communication restart but the 6th Iâve got an issue
The Issue starts at 14:54:21.649 and ends at 13:31:16:.270, so time-out is about 36:54.
The led of the WiserHub is still green and the wiser entities are not refreshed in HA, they had been initialized.
Another time( 2022.09.01) an issue began at 17:01:23 and stopped at 20:06:35
I couldnât ping the wiser hub
the led was Red
after a power cycle on the Wiser Hub the communication restart normally
Hi James. It is good to see another member of Schneider.
My experience, when hub has seemed unresponsive for a prolonged time, has been:
My access point does not show wiserhub (i.e. dropped out of the list of associated wireless clients) and hubâs lefthand LED is flashing red.
Switching to and from softAP mode at the hub, restores LAN wifi connection.
When it comes back up, it very briefly flashes red.
Then goes solid red for a while (minute or so) during which time it has network connectivity (since I can see it making DNS queries and communicating with cloud) but does not respond to LAN clients (ping or http).
Then goes green and resumes normal operation.
Is this expected behaviour? Perhaps this leads to confusion over solid vs flashing red state when hub is unreachable? It did for me, when I initially reported it.
EDIT - 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. Fortunately I am seeing a mraked improvement since switching channels on AP.
My understanding of the Wiser system is that even if it is offline, the hub will still be able to run schedules for heating as it runs its own clock and has its own ways of communicating with my boiler and the radiator valves.
So the main problem for me is to do with automations. For example, I use HA to tell Wiser when members of my family arrived home, and Away mode should be turned off.
If the Hub is offline at this time, when it comes back online it will stay in Away mode, till the house gets cold enough that someone notices.
I have just created a couple of automations that are triggered when HA detects the Wiser Hub has come back online to handle this. Here is the YAML (but created through the UI so includes some unique ids which I have redacted):
- id: 'unique id'
alias: Wiser Recovery Away Turn Off
description: 'When the Wiser Hub comes back online, if Away is on check to see if anyone is home, and if they are turn off Away mode'
trigger:
- platform: state
entity_id:
- binary_sensor.wiser_hub
from: 'off'
to: 'on'
alias: Wiser Hub comes back online
condition:
- condition: state
entity_id: group.family
state: home
- condition: state
entity_id: switch.wiser_away_mode
state: 'on'
action:
- type: turn_off
device_id: unique_id
entity_id: switch.wiser_away_mode
domain: switch
mode: single
- id: 'unique id'
alias: Wiser Hub Recovery Away Turn On
description: 'When Wiser Hub '
trigger:
- platform: state
entity_id:
- binary_sensor.wiser_hub
from: 'off'
to: 'on'
alias: 'Wiser Hub comes back online, if Away mode is off, check to see if anyone is still in the house, and if not, turn Away mode on'
condition:
- condition: state
entity_id: group.family
state: away
- condition: state
entity_id: switch.wiser_away_mode
state: 'off'
action:
- type: turn_on
device_id: unique_id
entity_id: switch.wiser_away_mode
domain: switch
mode: single
These rely on a manually created Old Style Group containing person type entities. This will be home if anyone of the people is home, and otherwise away.
Has anyone else got any workaround automations they might share?
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!
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.
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):
If the hub comes back online, I do not see an auth request but I do see a DHCPREQUEST for its previous IP address and a DHCPACK back from the router.
If the hub does not come back online, there is nothing in the logs at all relating to auth or DHCP.
Also worth noting, my âcontrolâ device - and ESP32 bound to same node and further away, also looks the same in the logs as a successful reconnect of the hub, ie no auth but DHCPREQUEST and DHCPACK. I would expect to see and auth request (as how would it connect on the Wifi?) and this maybe a logging issue on the Asus syslog.
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.
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.
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
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.
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.
