Yes everything is still working and, because the weather is still relatively warm, they’re not working very hard so will last quite some time. I learned long ago that the Wiser battery warning was somewhat premature and there was a lot more life in the batteries.
It might be more honest to simply have the voltage readout and we then make up our own minds when to change them based on the experience for a particular brand/type. The %, started by Wiser with their battery icons, is clearly both arbitrary and subjective.
I shall let them run until the WiFi signal dies and report the outcome. It may take quite some time
Pete,
Just to keep you updated on these issues.
-
Error when setting preset mode in UI
Error when setting preset mode in UI · Issue #300 · asantaga/wiserHomeAssistantPlatform · GitHub
I have raised a PR to HA frontend for this issue as it seems (to me anyway) that this is a UI bug. We’ll see if it is accepted. -
The LTS target temp sensor showing -20C when Off
Wiser LTS temperature sensor shows -20C when room set to off · Issue #301 · asantaga/wiserHomeAssistantPlatform · GitHub
This will show None as its value when Off in 3.1.6 release when released.
I have included the issue refs on our github to keep track.
Perfect - thank you.
Interestingly I’ve had this start to happen to me. I’ve got a single Unifi access point in the loft, which is approx 25-30ft from the Hub so I added a ping sensor to HA. Whilst it’s not had a red light since, I can see it’s dropping off and reconnecting after an for oddly specific length of time, 2h 0m and 5s and at random times of the day. Somedays it’s just once, some days as many as 5 times.Occasionally it’s dropping for short times, 5-10mins. The fact it’s 2h0m5s suggests there is some kind of 2h timeout and it’s reconnecting once the timeout is over.
I’ve set the AP to log what it’s doing to see what’s going on when it next drops and that may give me a clue and I’ve set up HA to notify me when it next goes off so I can see if I have a red light or not.
1 Like
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
1 Like
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.
2 Likes
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.
1 Like
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.