On the positive side, whilst ploughing through documentation to see if there were known issues, I discovered the zigbee map card which I’d missed. A great addition - I’ve been looking for such information for ages. Many thanks.
Possibly no help, and no consolation to those with issues, but I upgraded to 3.1.2 and everything is working fine as far as I can tell. HA can talk to the hub ok. My hub has a fixed IP address assigned by DHCP.
Just to say v3.1.2 has been re-released after some more testing (and maybe a couple of fixes to the schedule card!).
Please post issue on our github if you are having any issues installing and provide any errors in the system logs.
If you had already installed before we pulled it, please do a redownload via HACS.
1 Like
I have now reinstalled v3.1.2 and this time no drama, everything seems OK. I can only think that yesterday’s coincidental (?) crash of the Wiser Hub caused the surprising update failure. Thanks for your help in getting it sorted and all the goodies you keep adding to the Wiser Integration.
Can you put out a release with a bumped version, IE: 3.1.3, so we don’t have to rip out and reinstall 3.1.2? I have loads of entities with a “2” on the end from the last big upgrade, and I have managed to clean up all the old ones, so am worried that a complete reinstall now will revert me back to the original names and break a load of stuff. I can’t see how to force a reinstall or downgrade/upgrade again without deleting it completely.
SCRATCH THAT I just found where the “redownload” was hidden…
@msp1974 , Thanks, everything fine now.
I tried with :
- safari and firefox on macOs
- edge and firefox on windows
Important, we have to erase the bowser cache.
Quick question regarding Away mode. I’ve added a toggle to switch this on/off from HA which seems to work fine.
The issue is that when I select Away Mode either with the toggle or the Wiser app only 1 of my room TRVs reports being in Away Mode. The rest seem to stay as normal? Is this right or is something not working properly?
Cheers,
Carl
@mgb66 no all the trvs should report as in away mode. If this is happening with the app too, i would maybe contact wiser support. I do recollect that in the hub api output there is/was a parameter that showed against each room to ignore away mode but i could never find a way to change this. Maybe somehow yours are set this way. If you have the latest 3.1.2 of the integration, you can download the hub data to a text file by using the new diagnostics function and you will see your rooms data and whether this parameter is there and set. Go to settings → devices and services → click on the devices link on the wiser integration → click on any device → you will then see download diagnostics. Scroll down until you find the data section and you will see rooms a little further down. If you want me to look at it, log it on our github and upload the file. All sensitive data is redacted.
1 Like
Hi, thanks for the reply. I’ll try calling Wiser support as I’ve downloaded the diagnostics and some of the TRVs are showing entries for “AwayModeSuppressed” although marked as false so presumably that shouldn’t be the issue. Interestingly some TRVs don’t have this entry at all! There seem to be a range of firmware numbers across the devices, I’ve 8 TRVs, 1 Room Thermostat and the Hub.
All solved with help from Wiser support. The issue was that my Away set point (14 degC) was the same as my scheduled setpoint. So for the iTRVs with this as a set point nothing changed. Once I dropped the Away set point to 13 degC then they all showed as Away except those which are scheduled as Off, in which case they stayed Off. So all good thanks to clarifications from Wiser. 
2 Likes
Nice to see a company give good support
2 Likes
Is there any chance of an option to change the IP address the Integration is looking for the hub at? I set everything up with my hub on DHCP. Once I assigned it a different IP the integration broke, and I couldn’t see where to change the IP in the integration. I’ve worked around by assigning the hub it’s original IP, but my IP address OCD is itching as it’s in the wrong place.
Or…point me where to change the IP the integration is looking for? I couldn’t see it anywhere in the config files.
Youll find it in this file.
~/.homeassistant/.storage/core.config_entries
1 Like
That sorted it, thanks. 
Hi everybody,
First of all I just want to say that I installed the Drayton Heating Hub this summer in anticipation of this coming winter and so far I am very pleased with it. I also installed Home Assitant and the Drayton integration and I think it is fantastic the info and the control it provides.Kudos to @Angelo_Santagata and @msp1974 for their great work.
I believe I have found a minor bug in the integration and I am asking for confirmation:
I have setup a room in the Drayton app (with its corresponding climate entity in HA). The room has a schedule assigned to it but it is not following it (it is set to manual mode). When I turn off the climate entity and then turn it on again, the target temperature is not set equal to the previous one, but to the temperature corresponding to the schedule assigned to the room, even though the room is set to not follow it. It is my belief that the target temperature should be set equal to the one before turning the climate entity off.
Thanks,
Javier
Javier, glad you like it. This is how it works as you can’t actually turn off the room but it sets the target temp to -20C in manual mode. We interpret that as off in the api. As such, there is no record of the previous manual temp that was set before this as it has been overwritten. Therefore the only thing we can do is pick a temp to set when you put it back to heat. We chose current room temp as a preference to scheduled temp so that the heating doesn’t fire.
Hope that helps explain.
Mark
Hi Mark,
I see. No big deal, since I can do it with an external automation, but it would be nice if any time the climate entity was set to off (or, as you say, to minus 20 degrees) the integration would remember the temperature and restore it whenever the climate entity was set to on again (and no explicit target temperature was given and no schedule was assigned). Just an suggestion for future improvement 
.
We chose current room temp as a preference to scheduled temp so that the heating doesn’t fire.
Strange, but I find the opposite to be true. The climate entity is set to the scheduled temperature, so it may actually fire (or maybe it is set to the lower of the two? Since it is now summer, the current room temperature is way higher than the scheduled room temperature).
Thanks,
Javier
1 Like
Oh maybe i am wrong. Would you log this on out github as an enhancement and we’ll look at how we might be able to do it. Issue will be restarting HA in between but lets see what we can come up with.
Out of interest, do people have issues with the hub losing the wifi connection? Mine seems to lose the connection fairly frequently despite the router being on the same landing as the hub! Any suggestions on how to make it more stable?
Mine has been rock solid BUT i purposely assign it a fixed IP and its bound to a known SSID.
I did have issues when I had two routers, same SSID and the idea was you could roam between them. what i found is certain devices would randomly disconnect from the strong one and then attach themselves to the “weaker” one even though there was a stronger signal from a router with the same SSID… (I think in wifi talk its called stickyness)…
otherwise… rock solid…