Hmm, I think you could be right. I did a quick test and it looked like it was working as expected. However, I think it had actually triggered due to an active thermostat switching on. I am seeing the same here when there is no other demand from any other thermostat.
What is the displayed_setpoint attribute for climate.wiser_study showing as in Developer Tools?
Note, if you have changed the minimum value recently I think it’s possible it might take up to 15 minutes before it will update and turn on the heating. This is because there is an automation controlling this behind the scenes, which IIRC is set to check every 15 minutes.
UPDATE: First paragraph updated after some additional testing.
I have also waited about the same and can confirm I am seeing the same as you. It only triggers when there is demand from an active thermostat.
The displayed_setpoint attribute should show the same as what is in the Wiser app.
UPDATE: Hang on! This is how it’s meant to work. Passive Mode only heats when there is a call for heat from an Active thermostat. I’m confusing myself here.
Except maybe it should demand heat when it is below the lower setpoint. The style of the old thermostat card and the new “Wiser styled” card would suggest this should happen.
Edit: the old thermostat card didn’t show heating up to the lower setpoint - so it appears the old card was correct. - the new styling is wrong - maybe …
Not quite. If there is no active room the target temp should be set to the min temp. Therefore if the room is below that it should heat. This heating is controlled by the hub but the integration is defining the min temp.
What is wierd here is that the min is showing on the card as 18.5 but Wiser app is showing 15. Not sure why the app is not showing 18.5.
Let me look through the code tomorrow and see if we have a logic error.
I can’t open a PR (which is probably a good thing as I wouldn’t be able to offer code to fix this). But I would love for this to be either just reverted to the 2 slider icon, or be customisable.
Thanks for all you do for us.
Except it is the wrong colour
I would need to use card_mod to change that which would mean a “work around”.
I used what was given to me and came up with the simplest solution which was just to change that instance rather than build a new entity, as you have done, to do the same thing - except for the colour
However I see you have a good argument, with the visual editor, to make this change.
OK, had a quick look tonight. There is definitely an issue but I am scratching my head as to what the hell is causing it.
It seems that if you lower the lower temp, it updates the hub, but if you increase it, it does not.
So, when you went from 15C → 18.5C, this did not try to update the hub. If you were to set it to 14C (as this is lower than the 15C that the hub is set to), it will update it. But you won’t be able to get it back up again.
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.
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
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.
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.
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.
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:
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.
I’m confusing myself here. 
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.
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.