Drayton Wiser Home Assistant Integration

I have added the UOM in and my graph completely fails to display with it set.

I will keep an eye on it, but so far unavailable seems to be working. I doubt it would have worked before the change to history (when this was originally written).

Just in case it’s configuration of the card, here’s an except of the code I am using for my graph:

graphs:
  - type: line
    entities:
      - entity: sensor.living_room_climate_temperature
        name: Temperature
      - entity: sensor.living_room_climate_target_temperature
        name: Target Temperature
        lineMode: stepped
        color: orange
      - entity: sensor.living_room_heating_graph
        name: Living Room Heating
        color: rgba(205,62,62,0)
        fill: rgba(205,62,62,0.5)

Sorry Mark. I know you’re trying to clear them and they seem to be getting opened as fast as you’re closing them today. :laughing:

I can’t see a reason for it not being available under Passive Mode either. I also can’t remember a reason for it being removed and would also assume you can advance the schedule still. I’m not able to test it though, as the option is not available to do so.

I’ll open an issue then. It’s certainly not urgent. :slight_smile:

Ive just had a moment of clarity. You cant have advance schedule in passive mode as it is not a real function but sets an override of the target temp to the next schedule temp. Passive mode will then just override this.

1 Like

Hi

So this is what my graph looks like with the template {% else %} set to unavailable

image

And this is what it looks like with undefined

image

Caveat: the first is running on HA 2024.2.5, wiser v3.4.5. the second is running on HA 2024.2.5, wiser v 3.4.3

I know that the Conservatory wasn’t calling for heat all the time it shows it was in the first image.
And here is the stock history graph that shows the same period.

image

Here’s my code snippet which isn’t much different to yours.

graphs:
  - type: line
    entities:
      - entity: sensor.conservatory_target_temp
        lineMode: stepped
        color: darkorange
      - entity: sensor.conservatory_temp
        color: rgb(0,0,255)
        fill: rgba(30,144,255,0.075)
      - entity: sensor.conservatory_heat_graph
        fill: '#f08080

EDIT: replied to myself which was dumb!

Even if Passive Mode is set to Scheduled/Auto? I would have thought you could advance the schedule still then, but not when in Manual.

This is making me think it was changed before the option to have Passive Auto/Scheduled was added? As it makes sense for Passive Manual.

I may be misunderstanding, but I’m not sure you are you able to change this for something that’s already recorded in history and would have to wait for it to record the new data. So I’m not sure how you are able to compare the two same time periods?

Maybe because they are on 2 different instances of HA?

My test instance and my production instance. Although they are on different versions of Wiser there is no other difference to core

Ah, OK. That makes sense now. :slight_smile: I will keep an eye on mine and see if I see the same. I’ll let you know once I have more data.

1 Like

just a quick update, here is my unavailable version as of now

image

And hers is my undefined for the same.

image

I’m not sure if it’s possible, without being a moderator, but maybe we should split this off into a new topic, or open a new topic if it’s not possible? I’m very aware we are are clogging this up with discussion that’s not based around the integration itself, that others may not be interested in. Otherwise we can discuss via PM. I will need to gather more data before I can work out what’s going on though.

1 Like

So, when you select advance schedule, it looks up the next scheduled temp and sets an override temp to that value. This then runs as an override until the next schedule event. The current scheduled temp is sill the same.

When the passive mode automation runs (whatever mode) on each update, it is setting a temp override in exactly the same way to manage not calling for heat or calling for heat with other active rooms.

Thus as soon as you select advance schedule, the automation will run and reset the target temp based on whether any active rooms or what the current room temp is.

You can test this by calling the set preset service and set Advance Schedule and you will see it wont do anything (it may for a second or 2 while automation and updates run)

1 Like

I totally agree.

PM me when you are ready

1 Like

Let me gather some more data and do some investigation. I’ll PM you, or open a new topic and link it here if I can’t see a way to split this off like the mods do, when I have a bit more to go on.

1 Like

Thanks for the explanation. Does this mean that the other options are also redundant, other than maybe Cancel Overrides? Basically what I am asking is are the boosts not also overrides?

No the boosts work and override passive mode. Boost is actually a hub function whereas advance schedule is not.

1 Like

This is making sense now then. I bet if we looked way back up the thread, and I think I am semi-remembering now, we had a similar conversation before Passive Auto was added. I think the fact that you can have Scheduled Passive Mode is what’s clouded the issue somewhat

I did not realise (or don’t remember if you’ve said this before) Advance Schedule was not a native Wiser feature.

Damn, I have not read this topic for a while and there are almost 2000 new posts here. One of the most active topics on the whole community forum.

I have a bit technical question regarding a quirk of the TRVs which I am looking for a solution, or some idea if anybody has experienced it and has some stop gap solution.

I have two TRVs which are sitting idle and closed all the time. Recently I even set them to “Off”, hoping that the situation will get better, but unfortunately no change.
The problem which I am facing, that this two TRVs tends to get open by themselves, without showing any sign in the change of “request to heat” or anything, and they stuck in this open state/position. The only thing what I can relate, that they tend to have a battery percentage drop at the time when they open, but nothing else. The situation is usually noticed from the temperature as it changes, rises, as the radiator gets hot/warm and it stay that way open.

It is unclear for me, why the TRV opens the valve and why not closes back fully, as it supposed to be. And of course, why is it not recognising that the valve is actually open. It is also unclear what triggers this change. Is it a firmware upgrade, or the battery is weak and it just moves a bit the motor or something, I don’t know. Or the spring inside the valve is far too strong and the TRV is just too weak for it.

Has any of you had similar issues like that? How did you solve it?

I am tagging @jamiebennett, as he might have some special idea, knowing the system more than any of us, if he is still with Wiser.

Another question to @msp1974 and @Angelo_Santagata. Is there a way to valve reset a TRV from the integration? That would solve partially my problem posted above. Now I just tell my wife to remove batteries and place them back once the issue happens, and that does the valve reset. But would be better, if I could leave her out from the story. Just to improve WAF.

I have no exact solutions for you, but I have had issues with non-compliant TRVs. In my case this was a sticky valve on the rad. I found this issue by swapping this TRV with another TRV from a rad I had no issues with. Its a ball ache, but was the quickest way I found if it was the rad or the TRV
What is your zigbee network like and do you have any features set like window open or passive mode set?

2 Likes

Window open is set but I have no idea about the passive mode. Do you mean Eco mode by any chance? Then the answer is no.