I don’t think removing and re-adding the integration would be any different from re-downloading it, but if you’ve tried that already I think this would have to be the next step to continue to troubleshoot it.
You would have to edit your configuration.yaml file to change the recorder. It’s not something you could do by accident I don’t think.
Yes, my hot water entity displays a different name. This is only because I have renamed most of my entities from the defualts to make more logical sense to me.
Sounds like it’s all fixed now anyway after updating HA Core and following @Duke_box advice regarding editing the automation?
Wouldn’t changing the sensor to binary mean the domain changes too?
At the moment using the entity in a Glance card for example, it shows as a radiator which is either on or off with a colour change if heating.
like this;
So is that the what you mean by this?
As it is at the moment, this is done automatically by the frontend. So whilst it wouldn’t be a too onerous task to change my 4 dashboards and 6 views, I don’t see any benefit to this idea. Or am I missing something as well?
BTW JLR is Jaguar Land Rover - Yes I had to google it!! 
Yes, it would mean changing domains, although technically those sensors that only have an on/off state should be binary sensors anyway.
That is weird. I do not use the Glance card, as I make extensive use of the Entities card, so I had to create a Glance card to check this to see if it were any different from the Entities card. It isn’t, for me anyway. I do not get state coloured sensors for On/Off states unless it is a binary sensor, which led me to create template binary sensors from those provided by the integration. As you can see, it works fine for the climate entities though.
Ah, Jaguar Land Rover. 
I fibbed, I use a card-mod piece in my glance card for the sensor.wiser_heating colour change.
like this
show_name: true
show_icon: true
show_state: true
type: glance
columns: 4
entities:
- entity: sensor.wiser_heating
name: Heating
tap_action:
action: navigate
navigation_path: /lovelace/heating_info
card_mod:
style: |
:host {
--paper-item-icon-color:
{% if states('sensor.wiser_heating') == 'On' %}
#ff5722
{% else %}
var(--state-icon-color)
{% endif %}
;
}
Sorry 
Ah, that makes sense now. I was wondering why the difference. Here’s the same card with the template binary sensor in the middle, which highlights when on as it’s a binary sensor.
Basically, I was suggesting that those sensors really ought to be provided as binary sensors by the integration to avoid workarounds such as both yours and mine.
The main reason for mentioning it in the first place was that it does, as I suspected, correct the issue in the Automation Editor UI, where the on/off states are not selectable, that you pointed out.
template:
- binary_sensor:
# Wiser Hub Heating binary sensor
- name: Wiser Hub Heating
icon: >-
{%- if is_state('binary_sensor.wiser_hub_heating', 'on') -%}
mdi:radiator
{%- else -%}
mdi:radiator-disabled
{%- endif -%}
state: "{{ states('sensor.wiser_hub_heating') }}"
UPDATE: The binary sensor does indeed fix the problem in the Automation Editor UI, where the on/off states are not selectable. I’ve just tested this with my template binary sensor vs the default standard sensor provided by the integration and updated the last paragraph above to reflect this.
@msp1974 Now we know this, I would say this is a fairly good reason to make the change as it’s actually a bug fix. It’s also interesting that I was not the only one looking for a way to get state colours to display for these entities. @Duke_box and I just went about it differently. This makes me wonder how many others have made workarounds for this. 
Hi, first of all thank you for the great integration! I think minimum temperature logic for passive mode stopped working a while ago. I didn’t have time to upgrade HA and integration for a while, but done it yesterday and issue persist on latest versions.
As can be seen from screenshots minimum value is set to 18.5C but that doesn’t result in integration bumping manual demand value in Wiser and therefore heating doesn’t start
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.
After 40min of waiting I’ve gone to Wiser app and updated demand temperature there hence starting of heating demand
I’ll get attributes from
Developer Tools tomorrow when can replicate scenario again
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.
That is exactly what I was going to say 
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 …
1 Like
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.
2 Likes
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.
I too, wonder how many people, this would affect?
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.
Bear with me, I’ll work it out and fix it!
2 Likes
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