Router Make/Model: All Unifi / AP Pro’s
Mesh Network/Extenders: No
Wifi Protocol Used (If known): WIFI 3
Approximate distance between Wiser and the router / extender: Through floor to an upstairs access point (~3m)
House wall construction type: Block
Wiser Hub has a fixed IP, locked to that specific AP and on a dedicated 2.4Ghz IOT Network.
All, just to say, as the improvements were looking positive from my end, I have released a v3.1.7 version with the wifi drop out reduction changes. The beta release will be removed.
I would also say that it is possibly a good idea to reboot your hub once you have installed this. Otherwise, you may get one more drop out before it stabilises.
Please feedback if you see improvements or not.
Nearly 24h here since I upgraded to 3.1.7b1 then then 3.1.7 and I’ve had no drop so far.
I am still on 3.1.6 and I did not have any dropout since the 2nd of October afternoon, when I had a 2 hour dropout.
Gábor, I’m really looking for people to move to 3.1.7 who have been having drop out issues and feedback if they have stopped or not. v3.1.6 does not have any fix for this and afaik, Wiser have not made any changes, so your lack of drop out so far is more luck than anything else.
As the device drops off from the network, I would hardly believe that it would be due to anything but the firmware on the device and how it handles the WiFi connection. There are too many people with this issue with a huge range of WiFi network equipment.
I wanted to represent a control group.
If you look at Amazon’s 1 star reviews of the Wiser Kit you will find some recent ones from 2022 and some earlier ones, where people describe the same issues.
When @Angelo_Santagata posted his question a month or two ago with his TRVs getting boosted during the summer, one of the old reviews came into my mind who described a similar problem years ago. (Heating turning on in a middle of a heatwave.)
When I look at some new products that I want to get, I always check negative reviews. They are the honest ones. Of course, you need to consider them with a pinch of salt. But those issues are showing what are the real problems with a product that nobody talks about.
I’ve updated to 3.1.7 this morning, following two drop outs, one last night for half an hour and one this morning for two hours. These are the first I have seen in about a week, so it could be a while before I can confirm any improvement in 3.1.7. I rebooted the hub following the update and will continue to monitor and feedback.
I also suspect this is firmware related and nothing to do with the integration.
I could agree and disagree with this (and Wiser are looking at whether they can make elements of it more robust), but I am focussed on making this integration coupled with the Wiser hub the best it can be and these drop outs really spoil it. I did find in our code something that could cause a small embedded device like the Wiser hub to have issues and that is what v3.1.7 attempts to address. The issue identified would be at the tcp connection layer. It obviously is not really designed for what we are doing (constant polling) but more designed for infrequent access via the Wiser app and then run its own thing. This may or may not resolve it but so far, results are more on the positive side. It maybe that we need a combination of this change and some changes from Wiser, but I am trying to use our group (those who have been seeing frequent drop outs - which includes me), to move to this new version and report back if they are seeing improvements. To have a control group we would have to have more commonality of our setups, which seem very different across the board (albeit, many seem to have mesh of some sort).
I also read your link to Amazon reviews and I would say that (to be fair to Wiser - as Jamie is on this chat!), many of these reviews complain about the zigbee dropping off, which with reliance on battery zigbee devices is one of those zigbee quirks. Because zigbee battery devices do not act a repeaters in a zigbee network, I am sure many people will need the repeater plugs to get good connectivity of their TRVs to their hub due to house layout, construction etc (and Jamie - yes how much!! ;-)). This is not easy for those non technical people to understand or want to care about but it does matter to have a robustly working system. I would also say that it also has many great reviews where this is clearly working as designed and a lot of the negativity is regarding the app functionality or zigbee. I see 1 or 2 re wifi but do we know they have a good wifi setup?
If you disconnect for a moment, the standard Wiser offering (and what maybe thought about how easy/difficult etc it is to use/configure/be pointed to issues), we are trying to target a more technical audience here who likely would understand signal strength etc, one of the reasons we created the zigbee network card so that you can see if you have a trv with a poor signal (which will very likely drop off) and either reposition existing repeater plugs or add them to your setup. I would add that imho, the trvs could do a better job of hooking onto the strongest signal as I do see that mine don’t do that, however they have a strong enough signal to be reliable (since I added a second repeater!).
All this, however, is not the same as a wifi drop off. I agree with you there are a myriad of different wifi setups, with which comes a myriad of different wifi related issues. Wifi signal strength, channel congestion, mesh v non mesh, node locking on mesh v not, mesh cross over by not positioning the base units well, crappy hubs supplied by broadband provider that cannot cope with number of connections, technical people v not so technical people in their ability to set up wifi well and explanation of issues etc etc which makes all this challenging to get to the bottom of.
As such, I am listening to what I hear, doing some technical diagnostics (25 years in technology and an Electronic Engineering background) to narrow down possible likely causes and speedily find resolutions/improvements even if not the end answer. Angelo and I put a lot of our time into writing, supporting and enhancing this integration and we want people to love it and not loose faith with unreliability (which is the biggest killer of interest in a product as we know). I also don’t want people to be blaming Jamie (yes Jamie personally! ;-)) or Wiser that their product is unreliable when it could be the integration causing a problem.
What I need in return (and Jamie for his part in helping with this) is to have good structured feedback on the situation that those who have been seeing consistent issues now see with changes we make to improve it.
Sorry it sounds like a rant but please don’t think it is. Trying to explain our need to help everyone here.
Keep contributing to this forum, we appreciate your input!
I’ve installed the release 3.1.7 yesterday as it had been published and I’ ve the issue again since 10 minutes ( 2022/10/04 15:54:02).
I haven’t rebooted the wiser hub yesterday.
My installation is shown in the post 977.
@msp1974 what kind of informations or tests should help us?
I just have rebooted the wiser hub and the HA server.
Mark, don’t worry. I know what you are talking about and understand what you meant. I didn’t want to be a troll either.
But you need to think a bit further as well. If the Hub is loosing WiFi connection due to our interaction with it, then it means it is really vulnerable to DoS attacks. There is nothing excessive what we are doing with the Hub.
And that has to fixed by the firmware.
I’ve just installed your latest update.
I noticed, in a packet capture I did a while ago that the integration’s API requests occurred from a new tcp port on each polling. AIUI the changes in your Wiser API mitigate this by not reinstantiating the rest object. Would that be right?
I wanted to mention that I have seen considerable improvement last few days from doing the following:
I increased the polling interval to 60 seconds. I think this helped a bit, but difficult to quantify.
I then changed wifi channel. After doing another wifi survey in the vacinity of the hub, I noticed there was a very intermittent but strong wifi BSSID which I failed to pick up before. So I switched from channel 1 to the more congested channel 6 (avoiding 11 thanks @dunxd) and got no host down notifications from icinga and no integration log reports of tcp/http connection issues for two days!
Icinga pings the hub once every 5 minutes. If it encounters no reply, it then pings once per minute for the subsequent 4 pings. If no replies to these, it flags the host as down.
Earlier, I considered ping monitoring the hub with the integration disabled, to see if the integration might impact hub’s responsiveness, but haven’t done so.
MAny thanks for the project. I do like the Wiser system and the integration significantly enhances it for me.
Router make/model: Netgear Nighthawk R7000 flashed with dd-wrt firmware
Mesh network/extenders: No
WiFi protocol: NG-Mixed
Approximate distance between Wiser and router: 5 meters through 1 floor and 1 wall
House wall construction type: Timber frame with 100% stud partition internal walls
Additional notes: Wiser hub has a static/reserved IP address. We live in a detached house a decent distance from neighbours, so shouldn’t be getting too much interference from their WiFi networks. I have two other Zigbee networks in addition to the Wiser Zigbee network and specifically set these all up so as to avoid interference from each other. My Hue hub is on Zigbee channel 11, my Zigbee2MQTT Home Assistant Add-on is on channel 15, my Wiser Zigbee is on channel 14 (I wanted to put this on channel 13, but as per my previous post about Zigbee channels, there is currently no way to manually set this) and my WiFi is on channel 11.
Absolutely agree, although somewhat mitigated to DoS attacks unless you have exposed on the interwebs. But yes, it should be more robust in handling this. As I said, think it wasn’t designed with this use in mind and maybe needs some revision.
I have a TP-Link Omada set up with three access points, running on different 2.4 GHz channels (1, 6 and 11). It’s quite a complicated set up, and I don’t want to bore people here with the details, but suffice to say that the Hub consistently prefers to connect to the one on channel 1 and reports a signal strength around -75 dB since I have done some tuning prompted by a message from @jamiebennett.
That signal isn’t very good, so I don’t think I’d make a good control… @msp1974 I’m happy to do any tests, set up and share measurements etc. as might be helpful. Just let me know.
I installed 3.1.7 last night, and had three ~40 minute outages since then. I didn’t power cycle the hub as suggested till this afternoon. I’ll keep an eye on things.
Yes that is correct. We use the requests library which in turn uses urllib3. This creates a connection pool with keep alive and we were reinstantiating this on each request. I think this could have created a situation whereby connections got dropped by the integration but not the hub and ended up with a maxed out connection limit on the hub. I have now changed to not do this and also include a Connection: close header in requests to prevent the urllib3 pool keeping the connection alive. This has a slight performance degradation but due to the very low volume of queries, nothing noticeable.
I actually have a ‘spare’ hub i use for testing changes to the integration. It is not in the same part of the house but I was thinking something similar of moving it to same location and lock to same mesh node and see if they went down together, or at all (not sure I can bring myself to stop the integration for a few days - I might wake up in a cold sweat! ;-). If I see another similar drop off, this is my next move.
I would say that one of the things that has lead me to these changes is the fact that this hub rarely drops off the network and whilst was not monitored in the same way and doesn’t have any devices attached, it sits next to me in my office where I work from home!
Do you remember this?
Still looking positive here.
Purple are the drops. Added the fixed version on 30th evening. Sat morning one was what I think it is good to reboot but nothing since.
Hopefully if we can get stability for the majority then maybe the others might be more wifi related and this can then be focussed on more.
@dunxd - firstly congrats on your 1 year anniversary of being on the forum. I would be interested to see if this calms down or continues. It would also be useful to see a similar history graph if you have one - if not, add the below to your configuration.yaml which will give you this history graph and also a sensor to monitor wifi strength from the hubs point of view like below and see if it shows anything interesting:
template:
- sensor:
- name: "Wiser Status"
state: >
{{ state_attr('sensor.wiser_heating_operation_mode','last_update_status') }}
- sensor:
- name: Wiser Hub Signal Strength
state: >
{{ state_attr('sensor.wiser_heathub_signal','wifi_strength') }}Christian, if this is the first issue since the update to 3.1.7 and you didn’t reboot then this is maybe not unexpected. Do reboot it just to clear everything out and then like the post above, have these monitors and see if they show anything interesting.
Oh and as I have been waffling a lot today, I thought I would post one more as the 1,000 post in this forum page.
Thanks to all of you who join in and contribute - it makes it really enjoyable to be part of a group of people who share knowledge, tips and pain! 
Here’s to the next 1,000 but it will make it hard to read!