It will be interesting to hear more about what you find out.
I get what appear to be random drop outs, some days lots others none. Some are very short, others long.
I’ve set up a ping so I can see when it drops out. Interestingly sometimes when there is a red light I still seem to be getting information even though the hub appears to be disconnected!
Mine is bound to a mesh unit around 3m away.
I contacted Wiser support about this earlier this week, as I just purchased and installed the system last weekend.
Apparently, the hub will determine the least congested Zigbee channel and choose it automatically at the setup stage. It’s not currently possible to change the channel without resetting everything and it will still automatically choose a channel based on what it thinks is best at the time. I asked them to put an option to choose the channel in the development queue, even if it means I need to reset everything. They said they had passed it on.
They can at least tell you the channel your hub is using if you contact them, even though it’s not visible in the app. Maybe it’s visible in this integration, but I only installed it a couple of days ago and am currently wading through the hundreds of posts in this thread, but this is the first mention I have seen about Zigbee channels as of post 514/813 by @euinor
Yes, being able to turn on the thermostat screen by calling a service or pressing a button entity would be useful. It’s one thing I’m not liking with the system so far, the fact that the thermostat screen is permanently off unless you physically interact with it.
Regarding the repeated questions about working locally. It would be a good idea to add it to the Github description, as it’s probably one of the first things people want to know.
Thanks for a terrific integration BTW, both @Angelo_Santagata and @msp1974. I made my decision to purchase Wiser largely based on this integration into Home Assistant and the fact that it all runs locally, which I managed to find by searching this thread. It would have been easier to have seen it right at the top of the Github description though.
Thanks again guys and keep up the teriffic work. 
much appreciated - I’ll go back setting up the buttons and will report back.
Briefly going back to all the rebooting the hub to fix disconnections discussion about a month ago (sorry I’m late to the party). If you’ve got a spare SwitchBot Bot kicking around, a quick solution (with no rewiring required), to be able to reboot if needed, would be to use that on the power switch. I haven’t seen a disconnection yet, although I only installed the system at the weekend just gone, but given I have a couple of spare ones, I’m now planning on using one on the bolier isolator switch so I can ‘reboot remotely’ if I ever need to. If it becomes a regular occurrance, I may look into something hardwired that doesn’t also switch the boiler off.
I have experienced connectivity issues over the week I’ve had the Wiser system up and running. During that time, the hub LED has gone solid red on 3 occassions. Each time, I left it be (almost 2 hours on one occassion) to see if it recovered. It did not. Rather than power cycle the hub, I switched it back and forth between wifi client and access point mode. This seemed to get it back online again.
I ran a packet capture, commencing just prior to red LED extinguishing, and ended once I got a successful API connection. Some things I noticed:
It didn’t seem to react promptly to apparent successful dhcp lease from router.
Then, once it was successfully connected to the LAN, it was communicating with the WAN but unresponsive to ping or http. A significant amount of traffic passed during this time, including DNS requests 8.8.8.8 (which I later decided to forward to my router!) and about 100KB of TLS traffic to 20.49.110.134:5671.
It does seem the hub is often unresponsive to ping and/or api despite being otherwise successfully connected to the LAN and reaching the WAN. As others have pointerd out, it seems there is more at play than wifi signal strength/sensitivity. I noticed earlier else mention of a (low) maximum number of simultaneous connection states (be it tcp, http) the device can handle, making it unresponsive.
All the talk about ZigBee and hub disconnections reminded me that ZigBee channels overlap the 2.4GHz WiFi channels, and to avoid interference needs some planning.
Changing ZigBee channels isn’t very easy, but changing WiFi channels is.
To find what ZigBee channel is being used by the Wiser Hub look at the attributes of sensor.wiser_heathub_signal. In my case it is channel 24. I have another ZigBee network in my home. I use ZHA for that, and can find the channel it uses by clicking Configure under the ZHA integration in Devices and Services (named after the coordinator model confusingly). Under the Network tab I can see I am using channel 25.
ZigBee channels 24 and 25 interfere with WiFi channel 11 which I was using with the AP nearest my Wiser hub. The hub only connects to 2.4 networks. I’ve switched to using only channels 1 and 6 for 2.4 GHz WiFi.
Let’s see if that reduces the disconnections for my Wiser hub. It may also improve the performance of my ZigBee networks.
Just looked at mine - ZHA is on 20, Heathub is on 20 and Wifi in 6.
This could explain why ZHA has never been 100% right since I got the Wiser.
Looking at schedules and planning to have buttons to allow switching, for example between unoccupied and occupied for some rooms.
I can set up two different schedules using the schedule card, and use the service assign schedule to assign the appropriate schedule to a room. However to assign a schedule I need to know the ID number. Would it be possible to either:
a. modify the service to read from the schedule names
b. make the schedule ID visible (perhaps as an option) on the schedule card without having to go into the schedule. Perhaps list the schedules using their IDs
Just a couple of thoughts.
I’ve just looked at my channels.
Wiser: Channel 25
Zigbee (Deconz): Channel 25
Wifi: Channel 6
So the Wifi should be away from the Zigbee channel and interestingly I don’t tend to have issue with connectivity between the TRVs etc. and the hub interfering with the Deconz network even though they are on the same channel. So rather than messing things up I’ve left them alone.
I continue to get drop outs of the hub, but can’t pin it down to a pattern. I’ve checked my wifi vs. the neighbours and I seem to be OK with channel 6 - everyone else is on 1 or 11!
I know this is not directly related to this integration, but there is a lot of discussion on here regarding the hub disconnections, and rightly so, as this does affect the usefulness of the integration (especially if you are using Home Assistant presence detection to switch Away Mode on and off) and the utility of the standalone Wiser system as a whole.
Well, having had the hub installed for just under a week now and having setup some monitoring (a ping binary sensor and automation to notify based on the numeric_state of the minutes_since_last_update attribute of sensor.wiser_hub_heating_operation_mode changing to 1 i.e. above 0) based on the previous disconnection discussions in this thread, I saw my first disconnection while out for dinner last night. I returned home to find the hub light flashing red. Fortunately I had been alerted to the disconnection an hour or so before getting home based on my sensors and automations. If I hadn’t I would have been completely unaware and probably would have woken up this morning to a cold house and no hot water, as Away Mode had been activated before the hub disconnected. Consequently, Away Mode was never automatically switched off when we returned home as Home Assistant couldn’t connect to the hub to send it the instruction to switch it off.
According to the Wiser HubR LED behaviour guide, the hub light flashing red is actually the indicator of the hub having disconnected from WiFi, not solid red as others have been suggesting. The guide says that solid red indicates either a firmware upgrade or connection to the Wiser cloud has been lost.
While in the flashing red state, the Wiser Home app was also giving an error saying it was unable to connect to or find the hub. The only way I could get the hub to reconnect to my WiFi was power cycling it. If this is a regular occurance, the utility of the Wiser system as a whole is seriously downgraded.
@dunxd is right to point out need to plan Zigbee and WiFi channels to avoid interference and I planned out my installations using the Zigbee and WiFi coexistence guide. However, you should also be aware that it’s recommended to keep your ZHA or Zigbee2MQTT network on one of the channels that also supports ZLL (Zigbee Light Link), to avoid problems with some Zigbee devices.
Note: use a ZLL channel: 11, 15, 20, or 25 to avoid problems
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 a few back about Zigbee channels, there is currently no way to manually set this) and my WiFi is on channel 11. I’m using a decent Netgear Nighthawk router running dd-wrt and not the Virgin Hub, which set to modem only mode.
Based on this, there should be no interference from these devices competing with each other. However, unfortunately, the 2.4GHz radio spectrum is also congested by Bluetooth, DECT phones and can even be affected by such things as microwaves and a plethora of other wireless devices that operate in this range. The only surefire way to detect interference properly seems to be using something like Wi-Spy and Chanalyzer, which I don’t have access to.
My best guess though, based on all the above and given that so many people are reporting disconnections, although I would be interested to hear how many of these are flashing red light as opposed to solid red, is that there is something flawed in the Wiser hub firmware that is causing these and not environmental factors at play here.
I’m not sure what my next step will be with this yet, other than monitor it for a while and open a support ticket with Wiser (they will be getting fed up with me as I’ve already contacted them a few times about various things), but I am already considering not using the spare SwitchBot Bot as a way of power cycling the boiler isolator switch (as I mentioned in my previous post about this) and hardwiring something more permanant (probably a Zigbee relay rather than something like a Sonoff which uses WiFi and is inherently less reliable) directly to the power supply for the Wiser hub, assuming, of course, that I decide to keep this. I could still return it to Amazon for a refund as I am well within my 30 days return window. However, returning it would be a pity, as other than this problem, which I may be able to work around dependent on how frequent it is, the Wiser system so far seems to be excellent.
I’ve been had my Drayton Wiser installed for about 8 months or so. Had my first disconnection in the last few days and had to power cycle the unit.
I’ve also noticed that the heathub is flipping between home and away every 10 seconds or so.
The Wiser is running on channel 20
ZHA is on 15
Other than this issue, its been solid.
Not sure I can explain that and I’m not seeing this as I only have certain devices set to be tracked. What is your Device Tracker setup i.e what’s your device_tracker settings in configuration.yaml? You probably don’t really want to have your Wiser hub set as a device tracker mind you. You can set track: false for it in known_devices.yaml to exclude it. Personally I have track_new_devices: false set in configuration.yaml and only add track: true to devices I wantt to track in known_devices.yaml. However, I might temporarily enable tracking to see if I am getting the same.
I don’t have device tracker set as far as I know.
There is no entry for it in configuration.yaml and I also don’t have a known_devices.yaml
I might just disable it as I don’t think it really serves a purpose.
I’ve just been looking through some logs and it seems to have been doing this home/away flipping for a while.
Not sure if its related but when I downloaded the config_entry-wiser-****.json.txt it has my GeoPosition as bring in the Iranian desert, which I most definitely am not.
“GeoPosition”: {
“Latitude”: 30.4865,
“Longitude”: 58.4892
}
Weird. I know there were some changes to device tracking stuff in Home Assistant a few releases back and not automatically adding stuff to be tracked by default. I don’t recall which release it was though, or exactly what the changes were. I’d have to go back through the release notes and check. I am definitely not seeing this though and I have enabled it as a device tracker specifically and it’s (currently at least), steady as showing home. I also downloaded the diagnostics for the hub and have the exact same GeoPosition as you, so I don’t think that’s significant in any way, just something they’ve set as a constant for some strange reason.
Just so you know, when you download diagnostics, it anonymises a number of things so that you can post it on github without revealing anything personal. The geoposition is one of those anonymised and is set to the Lut desert in Iran as it is the hotest place on earth. It was just a little Mark joke! On the hub itself, you will have the correct geoposition for your location from your address entered during setup of wiser in the app.
There is no device tracker as part of the wiser integration, so not sure what this is, presume maybe some wifi based tracker? It also is updating much quicker than the integration should be updating from the hub, so i would say this is not related to any data from the hub itself.
The device tracker in HA is for use with devices that you might want to use to determine if a person is at home. I don’t think it a good idea to use the Wiser Hub in this way as it is likely permanently attached to a wall in your house 
To track its uptime on your network you should probably use either the nmap or ping integration against the hubs IP address, and use DHCP address assignment to ensure it always uses the same IP address.
