Thanks for these suggestions. I took a look at the Logbook and scrolled back several pages. I could see no errors. I then cleared the history of both sensors. Initially the history card said there was no history but later went back to the “blank” state as before (as least showing the history had been cleared). Finally I tried renaming the Wiser Hot Water to Wiser Hot Waterr but no change. I will now bight the bullet and try reloading the integration. Incidentally I can confirm I have tried a restart of HA in the past. Fingerscrossed!! I will report back later.
So I tried to reload but got the following message:
Silly me should have thought of this before!! I have updated HA to the latest version and reloaded the Wiser integration and all is well. Well that is, the history card shows history. However when I try to use Wiser Hot Water state in an automation, using the visual editor, the only states I am offered is “unavailable” and “unknown”. I can not use “on” or “off” as I can if I use Wiser Away Mode where these are offered options. Is there a difference in the type of entity between Wiser Hot Water and Wiser Away Mode? Its most likely finger trouble on my behalf and I can work round it for Hot Water by using LTS Hot Water and testing for 100% or not. But its much more difficult with Wiser Heating because I am not at all sure at what %age the boiler fires. HA is a steep learning curve so I fighting my lack of ability too!!
We should have asked what version of HA you were on. doh!
OK, I don’t normally use the visual editor for scripts or automations. I do however use it to get a skeleton which I then edit in YAML.
I have found the “improvements” in the use of the UI not very novice friendly contrary to what the devs say.
So I tried a really simple automation using the visual editor to trigger Alexa to say the heating is on when the heating changed from off to on.
It was impossible using the visual editor as the option to select the trigger state from off to on wasn’t offered. This is exactly what you are saying.
It is possible to just type in the states though and when you choose to edit in YAML you see it has been accepted and is syntax correct.
So you are experiencing a bad implementation of a UI
Here is the UI where I overrode the options.
Here is the YAML it produced.
And here is the options offered by the UI - clearly wrong!
1 Like
OK thanks so much for your work on this. Originally I had tried both the visual editor and the yaml and could not get it to work so I assumed that if I just tried it with the visual editor that would be good enough - you know what assume did…! I will have a go in yaml. Odd though that Wiser Away Mode works just fine.
The hot water entity is a sensor and the away mode a switch. However, whilst not available in the drop down, you can just type into the box. So just type ‘On’ or ‘Off’ (without quotes). Same for heating.
Thanks. Again originally I had tried to force the option in the visual editor but could not get it to work with and without quotes so had assumed that it just would not work. I will have a go later and report back.
Anybody noticing the preset icon on the stock thermostat card, when in passive mode, is now a large dot? Previously it was the 2 sliders as it is in any of the non passive states.
I see this in the release notes for 2024.2.x
So is this something the wiser integration has to provide now?
(sorry @msp1974 )
I am getting very tired of all these front end changes (some not even documented at all).
I have spent weeks on making the new thermostat card look like it used to and to my liking (with help from @msp1974 and @robertwigley ).
I have spent days on a broken card-mod theme caused by 2024.2.x because the overflow menu has been replaced with a pencil icon if the browser window is wide, but is shown if it is narrow!
And now this change to a stock icon for a feature in the stock thermostat card.
I have better things to do than spending my time fixing things that weren’t broken.
Ok rant over - but is this something we can change individually because I can’t see how.
1 Like
Yes, ive read about this and can add an icon file to set icons for each preset mode. It is on the list but I have some work to complete on my JLR integration first and then to look at some stuff for @LGO44 which he has been very patient for. Happy for a PR from anyone on this.
2 Likes
@msp1974 I’ve always wondered why these on/off sensors were not actually binary sensors in the integration? I’ve created template sensors from them to make them into binary sensors (so I can have them hightlight when on in the UI), but it seems like it would make more sense for the integration to expose them as binary sensors in the first place rather than just sensors? Maybe I am missing something and there is a good reason they are exposed this way?
I haven’t updated to 2024.2.x (so again a version behind) yet for a few reasons where I suspected things were going to break again. 
This being one of them. Even though there is a fix in there for SwitchBot Curtains that I opened as an issue in GitHub a few months ago, that I would like to have applied, I decided the benefits weren’t worth the risks until I have time to deal with anything that it breaks. I used to regularly update at the beginning of every month, but I am far more cautious and calculated these days. Once bitten, twice shy as they say.
Thanks. This is what I tried alright, but still getting the same error
No good reason. I have considered changing them but concerned that it will break some peoples automations. And i dont want a @Duke_box rant! 
Just a legacy thing then by the sounds of it. I understand your thoughts here regarding minimising breaking changes. However, I think people are generally fine with small breaking changes as long as it’s clearly communicated including what’s needed to fix them, although this may just be my take on it.
I do agree with @Duke_box regarding what seem like a lot of unnecessary breaking changes recently in HA Core.
In this instance, changing e.g. sensor.wiser_hot_water to binary_sensor.wiser_hot_water is a two minute job in Studio Code Server using find and replace on the YAML file(s) and updating sensors to binary sensors can be done in the same way for dashboards by accessing the raw YAML and doing a find and replace on that too.
It is only my opinion, but I have always felt these sensors, that only ever take a binary value, should technically be binary sensors. It doesn’t really matter much either way though. I have a workaround to template them out to allow state highlighting to be reflected in the UI. I was only really raising it, due to the apparently incorrect states that are showing in the UI automation editor and wondered if changing this may fix that? I write all my automations in YAML, but it may help avoid the confusion that newcomers are experiencing using the UI to create their automations. Just my two cents. 
PS Just out of interest, what’s the “JLR” integration you’re working on?
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