Firstly welcome to our integration! The heat button basically puts the room/trv in manual mode. Ie the follow/not follow schedule setting in the wiser app. It will default the temperature to the last manual temp setting you used since starting HA. There is a setting in the integration config to determine what is uses if heat has not been set since starting HA to use current, min or scheduled temp. Hope that answers your question.
Understood. Thanks Mark.
Itās our first cool day today since summer. Maybe I have been a little stingy with the thermostat schedule but already I have detected some unauthorized TRV tampering. I may have to test the device lock 
Thank you both - that is very helpful indeed. I actually found a broken Wiser roomthermostat for parts on ebay and fixed it, so am very happy now 
I have been battling with something else, but am confused about how I made it work. I wanted the tasmota fan to only be triggered when the kitchen was heating. That seemed easy via a state change of the kitchenās is_heating boolean attribute.
In dev tools that is shown as a boolean, like:
is_heating: true
But I could not get that to work as boolean trye/false for the ātoā state of trigger. The only way I could get it to work was a number_state trigger like this:
platform: numeric_state
entity_id: climate.wiser_kitchen
attribute: is_heating
above: "0"
and
platform: numeric_state
entity_id: climate.wiser_kitchen
attribute: is_heating
below: "1"
I used that numeric approach because I noticed that āWiser Room heatingā entry on the history chart is either equal to the current room temp, or there is nothing. A number, rather than a boolean. I guess that this ānothingā is actually a NULL or something, so maybe having a "below: ā1ā trigger wouldnāt work, but it did work. I paste the chart below. When there is a something with a zero value on the y axis you actually see that the orange disappears and the orange doesnāt actually go to zero per se.
Your trigger issue made me scratch my head a little as using true or false should work fine. After a bit of playing i worked out the issue and it is to do with the UI automations function and the way it works. Basically when you type true in the to value it actually stores it as ātrueā. Ie as a string and not a boolean value.
If you use yaml editor for your trigger and remove the quote marks, this will work. Ie
platform: state
entity_id:
- climate.wiser_office
attribute: is_heating
to: true
1 Like
Should also say, the fill on the graph for is heating is just how the graph displays ture/false on a numeric scale.
One of the features of the Wiser HA integration which Iāve found invaluable since day one, was the much clearer ābattery stateā readout compared to the Wiser App. However, since a fairly recent update, I note that the battery level entity appears to stick at 30% and no lower.
Has anyone else noticed this? Itās unfortunate that it appears to have lost sensitivity at precisely the range where itās most needed. Iām not aware of any change Iāve made which could have caused this
As the wiser hub only shows voltage and a description level we convert it to a % in the api. We did make a change to this recently as a hub update changed the voltage range on trvs. As such, the below is the mapping from the api of voltage v percentage. I have not seen them stick at 30% and mine certainly go to 20 and 10 before 0. What kind of batteries are you using?
TRV_BATTERY_LEVEL_MAPPING = { 3.0:100, 2.9:80, 2.8:60, 2.7:40, 2.6:30, 2.5:20, 2.4:10, 2.3:0 }
Iām using the same Procell alkaline batteries as ever. Around the time of the change I noticed that a number of TRVs went up from 20% to 30%, which I hadnāt seen before - previously only 20% steps.
Iām now getting warnings from these and other TRVs, via the Wiser app, that batteries are running low however they continue to show 30% yet I know that they must be near end of life. All a bit unexpected.
30% and 20% match the low description and 10% critical. So i would think wiser app will give a low battery warning at 30%. However, this bases it from voltage too so depending on your battery chemistry, they should keep running down to 0%. Prior to the update 2.6v would have shown 20% and the to 0% at 2.5v. Maybe the % to voltage mapping is not right in the real world. Are your trvs still operating?
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.