Looks like I found the culprit. It seems that the hub is coded to ping 1.1.1.1, presumably to test internet connectivity. I have rules in place on my network that blocks external DNS servers, so the hub probably got stuck in a connect/disconnect loop. I’ve added a rule to allow ICMP to 1.1.1.1 and now all is sweet.
Strange as it didn’t have this problem before and I’ve been using Wiser for over 2 years.
I suspect the ping came in with the recent 3.12.1 firmware update as that included a healthcheck routine. If your problem started on 2nd March that’s more than likely the cause.
Yes, according to HA history, problem started 2nd March in the afternoon around 3:30pm
I also noticed this after FW upgrade. The hub pings 1.1.1.1 every minute! I already port forward DNS to the router but the ping is new and, whilst blocked didn’t seem to cause issues, like you I opened it up.
OK, been quiet for a bit on the progress of passive mode as had other projects on. However, been thinking this through as to how to have both manual and follow schedule passive modes that are compatible (ie do not cause errors in the logs of these integrations) with Alexa, Google, Homekit etc.
Below is where I am upto. Main changes are:
See video below. Welcome feedback before we make this the released version.
As you can see, does not work too well with mushroom climate card (haven’t tested others) but this is because this card does not show the preset mode at all - so same issue if boosted. I think I have to leave that with these other cards to add preset mode as no other way to do this.
I’m just catching up with the passive mode developments. I’m struggling to see how to switch to passive schedule mode. I’ve tried switching schedule back on via the Wiser app after first switching to passive via HA - Wiser app says scheduled, HA doesn’t change to passive scheduled.
Early days!
I like the look of this. Especially welcome is that fact you can see if idle or heating.
Please can you release to beta, so I can test it?
I’ve also been thinking it would be nice to be able to see what the actual target temperature is set to by the automation that’s handling this in the background, even if it’s only for debugging purposes to make sure it’s working as it’s intended. There’s been a few occasions where the room temperature has been higher than the max and it’s left me wondering if it’s going beyond the max setpoint. Is it possible to expose this as an optional sensor?
OK, I’ll fix remaining bugs and do a beta release. Unfortunately it will leave orphaned select entities that will need deleting (again) but that’s the risk of betas 
I’m wondering if we add this actual target temp as an attribute on the climate device, otherwise we risk creating and orphaning sensors by turning on and off passive mode. WDYT?
Super. Looking forward to giving it a test. I assume that Passive Mode may need re-enabling in the configuration again too? No worries if it does (now I am aware of it), or about deleting the orpaned entities. It’s not a problem and a small price to pay for moving this forward.
Regarding the actual target tempertature, an attribute would work for me. I can template a sensor out of the attributes, if needed, anyway. Either that, or just assign it a null value when Passive Mode is not turned on? The main thing is just being able to check/see that it’s behaving as it’s intended, especially while we are in this beta stage.
The above video is not released yet. Depending on the Wiser integration version you have will depend on whether you have this funtion or not.
v3.3.0 has only a passive (manual) mode
v3.3.1beta has the initial version of passive schedule mode (but there are compatibility issues with this for lexa, Google Home etc).
The above will be released in the coming days in a v3.3.1beta2
A further thought on the actual target temperature sensor/attribute for Passive Mode. To save creating/orphaning sensors, when Passive Mode is disabled, rather than null, it could just reflect the target temperature as normal?
This looks great! Will give it a go once released.
For info, this is really dependant on the boiler. Ive been running OT for some time and it works excellently.
"operatingMode": "OTplus",
"preDefinedRemoteBoilerParameters": {
"dhwSetpointTransferEnable": true,
"maxChSetpointTransferEnable": true,
I have in the boiler menu, a CH Max Temp value which can be adjusted, I keep this at 80c.
"OpenTherm": {
"chFlowActiveUpperSetpoint": 800,
"chFlowActiveLowerSetpoint": 450,
Then I have the main dial on the front of the boiler which I can choose the CH Working Max Temp, I keep this at 65c. OT then works between 45c & 65c. The 45c lower setpoint can be adjusted my calling the service through HA, this was originally 35c but I bumped it up.
Hope this helps.
No the passive mode automation will not need re-enabling. This was a change I made to the config setup that I forgot to mention was a breaking change. This will stay consistant in the next release but you may need to set the right passive mode (ie if you had follow schedule it maybe will update to Manual) - all done via thermostat card. Switch will be on if you had either mode enabled.
As a side note, had a look at the attribute to show actual target temp and it is already there as display_target_temp. So, for now, I think we will leave this as is and allow those who want to to create a template sensor.
I would like to get some more feedback on battery life with passive mode.
I have also made a change to increment in 1C increments instead of 0.5C increments as (in the short testing I have done), it seems that the passive TRVs do stop and start heating as the temp reaches the set 0.5C increment, and then the automation ups it again and it starts heating again. I hear my valve on my test radiator working a lot. Im also questioning why you/we didn’t/don’t just set it to the max temp when active radiators are heating?
Anyway, just published v3.3.1beta2 for you to have a play with.
Thanks @msp1974. I will install later, test and provide feedback as and when I have any.
Good to know regarding not having to re-enable Passive Mode and that makes sense about having to set Manual or Follow Schedule via the Thermostat card due to the changes in this release.
I hadn’t noticed that there was a display_target_temp attribute already and that relates to this. I’ll probably template these out so I can keep a track of history for debugging purposes, for now at least anyway.
I have not noticed any impact on iTRV battery life. My iTRVs were all installed at more or less the same time about 6 months ago and I haven’t had to change any of the batteries. The Passive Mode ones, apart from the one in the Garage, which seems to have a weaker signal (and is in Passive Mode) and is reading 40%, are all reading the same at 60%, which is the same as the ones in Active mode.
I went with 0.5 degree increments in the original automation as my observations were that the iTRVs will often open slightly to let hot water circulate without actually calling for heat when there is only a minor difference in temperature between the target and the room. In theory, switching up to max if room temperature is way under the target temperature would increase heating demand to 100% and use a lot of gas unnecessarily. The idea was to keep heating demand to the passive rooms to an absolute minimum by using the loop to increase it incrementally over time. Maybe a setting is required to allow people to set the increment as they see fit? I think I may have even mentioned this in my original post about the automation, that people may want to tweak the increment value to suit themselves. 
@msp1974 is the attribute you are referring to actually called displayed_setpoint? I can’t see anything called display_target_temp.
Sorry yes thats the right one. I think maybe youre right and we have this as a config option on this automation. Anyway, see how you get on and feedback anything you think could improve or and bugs you find. Thx
Thanks for confirming. Will do. Just about to install and start testing.
@msp1974 I’ve got quite a lot of feedback on the latest beta. Unfortunately, I don’t have time to write it all up now (I will do so later). However, I really just wanted to share the biggest and most important observation with you immediately.
Having the displayed_setpoint templated out as a sensor has been extremely helpful to see what’s going on ‘under the hood’. I am pretty sure the reason you “hear [your] valve on [your] test radiator working a lot” is nothing to do with the 0.5/1 degree increment setting, but actually that in the automation controlling it you are setting the target temperature based on sensor.wiser_hub_heating (or the is_heating state of the Active TRVs) rather than binary_sensor.active_trvs_heating_demand, which was a template entity that I created using the sensor.room_heating_demand of all rooms that are classed as Active (see my orginal post and code for further details). It’s not something I had noticed, but now I can track the history of the Setpoint, it’s pretty obvious. Even if that’s not what is/was intended, it is what’s happening.
I used the heating demand rather than just heating in my automation specifically to prevent this, as the heating state turns on/off far too regularly.
My additional feedback and observations are as follows.
I really like that you can now use the Auto and Manual HVAC types to control which type of Passive Mode you want for a room. Given this change, does it make sense to rename ‘Passive Mode Follow Schedule’ to ‘Passive Mode Auto’ and represent that in the Thermostat Card as ‘Passive(A)’ instead of ‘Passive(FS)’? Alternatively, does it even need the brackets in the Thermostat card now, as you can see whether it’s set to Auto or Manual in the card?
An unfortunate side-effect of using the HVAC types instead of no HVAC type, as before, is that the Thermostat Card slider is now either green (Auto) or Orange (Manual Heat), rather than yellow, which makes it harder to see at a glance which rooms are in Passive Mode. I’m wondering if this can be changed? If not, maybe it’s possible using card-mod? I’ve had a quick look to see if I could do it with card-mod, but was unable work out how.
If you have a room set to Passive Manual, when you switch Passive Mode off, it stays in HVAC Manual Heat mode rather than reverting to Auto, which seems like the most logical thing for it to do, to me anyway. I can write an automation to change the HVAC mode to Auto, but it would be nice if there was an option to have the integration do this without the need for an automation.
As well has having the option to adjust the increment e.g. 0.5 as opposed to 1, as discussed previously, it probably also makes sense to provide an option to adjust the interval where it checks and changes it, from (I assume) 15 minutes as I used in my original automation to a different value. As with the increment, when I wrote the original automation I said people may need to adjust both these values to suit their heating systems, as a ‘one-size fits all’ approach will probably work fine for most people, but there may be cases where these values need to be tweaked.
I think that’s everything for now. I will continue to feedback anything else I notice and, as always, thank you for your work on this. 
