Drayton Wiser Home Assistant Integration

So I’m thinking that with away mode, this should override passive mode. That way, if you have rooms in passive mode and enable away mode, these rooms go into away mode and stop being passive. Then when away mode is disabled, they will return to passive.

If you switch a room to passive mode when away mode is enabled (although you should be enjoying your holiday not messing with HA! :-)), then this effectively does nothing until away mode is once again disabled where it will go to passive again.
WDYT?

Like this.

passive_mode_demo_away_mode

1 Like

That’s what I was suggesting in my message last night and looking to do with an automation. So, yes, totally agree. I think that’s the best, clearest way to handle it and no chance of Passive Mode knocking the temperatures up accidentally.

PS Looking forward to testing the next beta. I think this may be getting close to coming out of beta, by the look of it. :slight_smile:

Yes I think that we should now do this as a release so that those who havent taken the beta versions can benefit from some of the other enhancements/fixes for 3.3.1. Will likely do this tonight.

Thanks for your help on scenario testing and usability!

1 Like

No problem. Looking forward to receiving the notification there is an update available to install, whenever you get round to releasing it. :slight_smile:

OK now available as v3.3.1

That was quick! Downloading and installing now.

Does this release change the Passive Mode target temperature based on heating_demand rather than is_heating as well? Maybe it’s in the release notes. Haven’t looked at them yet. :slight_smile:

Yes but its not in release notes

Super. :grinning: I’ll do some testing and let you have some feedback as and when I have any. Initial impressions though are very good. It’s looking really polished now.

I’ve had to amend the card-mod code for the thermostat colours, to take into account the changes. I assume there is no more efficient way to do this than:

type: thermostat
entity: climate.garage_climate
name: Garage
card_mod:
  style: >-
    {%- if state_attr(config.entity, 'is_passive') and is_state(config.entity, 'auto') -%}
      ha-card {
        --state-climate-auto-color: var(--light-green-color);
      }
    {%- elif state_attr(config.entity, 'is_passive') and is_state(config.entity, 'heat') -%}
      ha-card {
        --state-climate-heat-color: var(--state-binary-sensor-color);
      }
    {%- endif -%}

Yes, I see them several times a day.
In my case the disconnects last for 30 seconds (maybe 1 second either way). Which is the integration polling time. When the entities first become unavailable the hub doesn’t respond to a ping but I don’t know how fast the hub comes back, it could be quicker than 30 seconds (I haven’t had a chance to check).
My feeling is that whilst the new firmware has reduced time the hub is offline it hasn’t solved the real issue that it GOES offline. And it is the hub going offline as nothing else I track on my network goes offline at the same time, in fact it is only the hub that ever goes offline!
I have communicated this to Schneider support when they asked me for feedback on the new firmware.

3 Likes

You dont need to specify the hvac mode so you can just do

type: thermostat
entity: climate.garage_climate
name: Garage
card_mod:
  style: >-
    {%- if state_attr(config.entity, 'is_passive')  -%}
      ha-card {
        --state-climate-auto-color: var(--light-green-color);
        --state-climate-heat-color: var(--state-binary-sensor-color);
      }
    {%- endif -%}
1 Like

It is possible that it is just not reponding quickly enough although the timeout is 10s. If it drops off the wifi i think you will normally see it offline for a few mins. Have you tried using postman to query the hub and see the response time?

1 Like

I agree. However, the new firmware has made the issue far more bearable for me, as it reconnects in five minutes from going offline now, but it does still disconnect with roughly the same regularity, although it might be slightly less frequent. It’s difficult to say for sure as it’s quite random. Sometimes it can go for a week without any disconnection and other times it does it every other day.

I haven’t seen those errors in my log though.

1 Like

Doh! Of course, it’s just clicked. There’s actually no need to test for the HVAC mode, as it can only display one or the other anyway. :laughing: Thanks.

Yes it could be the response time. I hadn’t thought about that, I just assumed the disconnects last for 30seconds according to the wiser cloud sesnor and the log was that was the polling time. I haven’t tried to vary that to test it though.
I don’t see the hub going offline for minutes anymore though.
And no I haven’t tried postman but I will now.
Thanks for the pointers.

Agreed. I don’t have a real issue with this anymore. Its just annoying that I can see the entities become unavailable on the dashboard sometimes.

As I have said it occurs quite regularly since the firmware update but for less time. Although I have not had a period where it hasn’t disconnected for days since the update which I had before. So strange we are seeing different timescales.
I will try Marks suggestions above.

Well I don’t know if it is because I upgraded HA to 2023.3.6, or the wiser integration to 3.3.1, or if it just heard me talking about it and is sulking now, but this problem of the errors in the log and entities going unavailable for a few seconds seems A LOT worse today.

One think i think sounds wierd is that your entities are going unavailable. If the integration cant update from the hub, that shouldnt happen. They should still show available but just raise errors in the log. Do you want to send me a diagnostics file and i will see if anything looks odd. I presume there are no other errors relating to wiser in your logs?

I can second that, the entities are going unavailable on the disconnects in my case as well as the logged errors. The first time I saw it today I manually started a ping of the hub which showed it was still online
However, after playing with this all day, I think the hub can be unresponsive if under load.

Because V3.3.1 was published I re-enabled my wiser integration on my test instance of HA and updated it. The polling interval on my test instance is set at 180secs.
Within minutes I noticed that my production instance was experiencing a lot more wiser hub disconnects.
So I set up a ping sensor for 5 seconds with a count of 2 on my production system.
This showed that the disconnects weren’t coinciding with a wifi drop (in fact I only saw a couple of packets dropped every now and again irrespective of the disconnects) but the disconnects got more frequent however they only lasted a few seconds ( 3 seconds not the 30 seconds I had seen previously).

I then disabled the wiser integration on my test system and the disconnects on my production system reduced in frequency.

Unscientifically I then updated my production system to v3.3.1 and at the same time removed the ping sensor and increased the polling to 35seconds to see if the disconnects time would reflect this.
So on restarting HA using wiser V3.3.1 at around 2pm today I have seen no disconnects at all so I don’t know if the polling frequency change has affected the time the hub disconnects for and I have no errors in the logs. But maybe the polling frequency extended to 35secs has made a difference?
Early days though.

I tried to use postman but I am unfamiliar with it. Can you help me? I can get responses from the Hub but how do I get the response time you asked for?

Many thanks
Mike

It should show on the main screen.