Ah ok, I have worked it out. It made no sense as I think I must have already found this issue and fixed it my dev version but never pushed to prod. Will issue an updated version to fix this.
2 Likes
OK, released v3.4.3 which fixes this passive mode lower temp issue.
I also fixed the annoying warning on the logs about supporting turn on/off after HA2024.2
Can you let me know if this solves it @RolandLT.
2 Likes
Technically it’s the right colour, as it’s a binary sensor. 
I guess it’s not the colour you want thought, so, yes, if you wanted it to be orange, you would still need to use card-mod.
I had not used card-mod at the time, so creating a binary sensor seemed like the solution.
I think the main argument for changing it, and the reason I mentioned it, is due to the Automation Editor UI bug. The secondary argument is that it’s technically incorrect not being a binary sensor and it should show it’s state colour without any tinkering for anyone.
However, it’s not causing me any problems, so I guess it’s down to the community and ultimately @msp1974 to decide on this.
1 Like
This is still behaving the same for me with 3.4.3.
Maybe I am misunderstanding though. Are you saying that it should only heat when all rooms are set to Passive Mode and there are no Active thermostats? Although I am not sure why you would have that configuration, it does make sense that it should call for heat at the minimum temperature in that scenario.
Maybe it should call for heat at the minimum temperature regardless? I honestly can’t remember if this is what it was intended to do or not now without going back through the original design specifications.
It should always maintain the min temp set when in passive mode and only heat toward the high temp when active rooms are heating. It was doing this (this is the original design) but there was a bug in the logic that set this min temp on the hub and would only change it if it decreased, so if you increased the min temp, it would ignore it and keep the previous until it had been through an active room/no active room cycle. If like me, you rarely change the min temp, you should not have noticed an issue.
1 Like
Thanks for the clarification.
Yes, this does makes sense. In that case I don’t think 3.4.3 has fixed it from my intitial test anyway. I will test more tomorrow, as it’s very late now.
I don’t ever change the temperatures, Passive Mode is either on or off in either Manual or Automatic in those rooms I use it in, so I certainly hadn’t noticed a problem.
V3.4.3 has fixed it but i had a blonde moment and didnt push the dev branch before releasing. Redownload it and you should find it is actually v3.4.3 now.
@msp1974 I can confirm it is working as expected now. Thank you Mark!
Btw, my use case is heating study passively while I’m working there as I’m not too fused about exact temperature. However, sometimes especially when it is sunny rest of the house is not demanding heat enough and I bump minimum temperature for study so it demands heat on it’s own.
Ah. Glad its fixed. You know, you could always boost your study (boost will override passive mode) and that way it will revert to normal settings afterwards.
1 Like
I’m not able to download 3.4.3 now as I’m running HA Core 2024.1.6 still and it has a minimum requirement of 2024.2.x. Never mind. I’ll get the update when I get round to updating HA.
Ah yes. To be able to fix the warning message showing in 2024.2 you have to set values that are only available in that version, so afraid its now forced to be that.
Hi all those who have helped with this, it is much appreciated. I have tried pretty much all of the suggestions but to avail. Here is the Yaml of a simple automation using an Input Boolean as binary input:
description: See if Wiser Hot Water state is testable.
trigger:
- platform: state
entity_id:- input_boolean.ipboo
from: ‘off’
to: ‘on’
condition:
action:
- input_boolean.ipboo
- service: switch.toggle
metadata: {}
data: {}
target:
entity_id: switch.sonoff_1001dca4c2
mode: single
and it worked just fine, toggling the relay each time it from Off to ON. I then replaced the Input Boolean with Wiser Hot Water as shown:
alias: Test Wiser Hot Water
description: See if Wiser Hot Water state is testable.
trigger:
- platform: state
entity_id:- sensor.wiser_hot_water
from: “off”
to: “on”
condition:
action:
- sensor.wiser_hot_water
- service: switch.toggle
metadata: {}
data: {}
target:
entity_id: switch.sonoff_1001dca4c2
mode: single
and the relay does not toggle. I have checked the traces and the ON to OFF is never detected. I think I have hit the proverbial wall 
In trying to get this to work I have learnt heaps. Also thanks to MarkP not just for his work on this integration but for his very interesting article on Helper for Template Sensors. I have a work around for the Hot Water using the Wiser LTS Hot Water Demand - a bit clunky but it works - and at least the history stuff works fine now and thanks again for your help.
Are you able to create a template binary sensor from the standard sensor provided by the integration using the YAML from my post here?
This mimics the state of the standard sensor. Given what we are seeing in the Automation Editor UI, I suspect using this will fix it and it will give us an idea of whether this is being caused by a sensor being used in the integration instead of a binary sensor.
Then use the new binary sensor you created as your trigger.
But this sensor does not use Wiser Heating or am I missing something?
Change sensor.wiser_hub_heating to sensor.wiser_heating. I’ve renamed mine.
For your/standard setup:
template:
- binary_sensor:
# Wiser Heating binary sensor
- name: Wiser Heating
icon: >-
{%- if is_state('binary_sensor.wiser_heating', 'on') -%}
mdi:radiator
{%- else -%}
mdi:radiator-disabled
{%- endif -%}
state: "{{ states('sensor.wiser_heating') }}"
Without getting @robertwigley on his soap box again about binary sensors, you need to change your off and on to Off and On.
And yes, I know!!
4 Likes
Good spot!
P.S. I’ve updated to HA Core 2024.2.5 and installed 3.4.3 and can also confirm the fix for minimum setpoint is working as intended.
1 Like
Hey guys, THANKS. The On/Off works, as I expect the created sensor will too. Thanks again.
So, all I need feedback on best solution for an issue.
When you set a room to off, the actual target temp reported by the hub is -20C. We used to just show that but had complaints that is caused poor visuals on graphs as it dropped significantly negative.
We now set this to off. However, as HA and other integrations have developed, this is now causing an issue in that Off is not a valid temp value and certainly does not have a UOM.
So, what should we do with this? My suggestion is maybe set it to 0C but wanted to guage feeling.
I think if you set it to undefined it will not register anything and not show anything on graphs. I am using undefined for some template sensors for graphs and it is an invisible state/value. However, unfortunately I don’t know whether that will be a valid value either. All I know is it works in a template sensor that I use for creating the fill when heating under the current temperature in the History Explorer card:
# Living Room Heating Graph sensor
- name: Living Room Heating Graph
icon: >-
{%- if is_state('binary_sensor.living_room_heating', 'on') -%}
mdi:radiator
{%- else -%}
mdi:radiator-disabled
{%- endif -%}
state: >-
{%- if is_state('binary_sensor.living_room_heating', 'on') -%}
{{ states('sensor.living_room_climate_temperature') }}
{%- else -%}
undefined
{%- endif -%}
If undefined doesn’t work in this context, and from a quick test in Developer Tools it doesn’t look like it will, then probably setting it to 0C makes sense. It’s better than the -20C reported by the hub at least.
Alternatively, what about setting it to the target temperature of the schedule, or the last state it was before switching off?
Sorry if it’s a stupid question, but what is a UOM?