Drayton Wiser Home Assistant Integration

Third party integrations
2039

Just tried upgrading to the latest version from the last beta version and not going well….

I don’t actually know if it’s installed okay, HACS is telling me it’s the latest version however when I enter the config menu it is still saying the enable automations is beta? I have tried deleting the integration but still the same.

Issues are that I still can’t load on/off schedules from a yaml file, same error I reported a few weeks back;

Logger: homeassistant.components.websocket_api.http.connection
Source: components/websocket_api/connection.py:150
Integration: Home Assistant WebSocket API (documentation, issues)
First occurred: 02:37:17 (3 occurrences)
Last logged: 02:47:55

[1684546728] Error handling message: Error setting schedule from yaml file - Error converting to Wiser schedule: bad operand type for abs(): ‘str’ (unknown_error) from 192.168.1.68 (Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.0.0 Safari/537.36 Edg/109.0.1518.78)

Didn’t notice before but can’t save an on/off schedule using the schedule card, error is listed as;

Logger: homeassistant.components.websocket_api.http.connection
Source: custom_components/wiser/websockets.py:423
Integration: Home Assistant WebSocket API (documentation, issues)
First occurred: 02:45:37 (3 occurrences)
Last logged: 02:56:33

[1466043456] Error handling message: Unknown error (unknown_error) from 192.168.1.68 (Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.0.0 Safari/537.36 Edg/109.0.1518.78)
File “/usr/local/lib/python3.10/site-packages/aioWiserHeatAPI/schedule.py”, line 140, in _convert_to_wiser_schedule
schedule_day = self._convert_yaml_to_wiser_day(sched)
File “/usr/local/lib/python3.10/site-packages/aioWiserHeatAPI/schedule.py”, line 641, in _convert_yaml_to_wiser_day
time = -abs(time) if time != 0 else -2400
TypeError: bad operand type for abs(): ‘str’

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File “/usr/local/lib/python3.10/site-packages/aioWiserHeatAPI/schedule.py”, line 407, in set_schedule_from_ws_data
schedule = self._convert_to_wiser_schedule(schedule_json)
File “/usr/local/lib/python3.10/site-packages/aioWiserHeatAPI/schedule.py”, line 158, in _convert_to_wiser_schedule
raise WiserScheduleError(f"Error converting to Wiser schedule: {ex}")
aioWiserHeatAPI.exceptions.WiserScheduleError: Error converting to Wiser schedule: bad operand type for abs(): ‘str’

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File “/usr/src/homeassistant/homeassistant/components/websocket_api/decorators.py”, line 27, in _handle_async_response
await func(hass, connection, msg)
File “/config/custom_components/wiser/websockets.py”, line 423, in websocket_save_schedule
await schedule.set_schedule_from_ws_data(new_schedule)
File “/usr/local/lib/python3.10/site-packages/aioWiserHeatAPI/schedule.py”, line 415, in set_schedule_from_ws_data
raise WiserScheduleError(
aioWiserHeatAPI.exceptions.WiserScheduleError: Error setting schedule from websocket data - Error converting to Wiser schedule: bad operand type for abs(): ‘str’

Rolled back to R3.2.2 just to check and both worked fine there.

2040

Just trying out the new release and especially passive mode - seems great so far. Only one question or potentially a suggested improvement. In my use case I would like to leave passive mode on in a couple of the less used rooms/bathrooms but I would still like the ability to boost using the physical controls on the TRV head/ room thermostat. What would be the best way to achieve this? Listening for a boost event?

2041

Srorry @nofuse i forgot to look at this. Can you please log as an issue on our github repo so i remember and will look this week.

2042

I’ll have to have a play with this. Does it boost when you use the physical control? The passive mode automation may override any boost with each hub update and set it back to a diff temp. We may be able to detect if boosted and not run passive mode code if so. Log on our github issues and i’ll have a look.

2043

Just a note for all. Passive mode is still very much beta, so happy for any feedback on improvememts.

1 Like
2044

Yes, boosts gets overridden by passive mode almost instantly (will open issue on GitHub). Fantastic work on passive mode. Seems to work pretty perfectly from my testing so far.

2045

@TimC , not really sure I understand the question. Firstly, I presume you are using the aioWiserHeatApi?

If you look at our integration code, you will see the option to advance schedule and how we have done it (in climate set_preset).

The _handle_coordinator_update is called after a hub update to ensure new data from the hub is used in the entities. When you send a command to the hub, you need to update from the hub again and if using a data controller to manage this, the _handle_coordinator_update will get called after the update from the hub by the controller.

Does that help? It may help to see a link to your code. However, I would say that if there is some functions that are not supported by this integration, it maybe better/easier to add them to this than write another custom component.

2046

@msp1974 , thanks for the response.

I’m playing with some code to predict when to turn the heating up to achieve the scheduled temperature by the scheduled time. (Wiser claims to have a comfort mode that does this, but in practice seems to have no effect.) Needs to look at sensors from the heat pump integration as well as the Wiser integration, so does not really belong in either. It uses the Wiser integration rather than trying to replace it, so does not call the aioWiserHeatApi directly. The Wiser integration has been working fine through its various versions for a year or so.

I looked at your code to find the async_set_preset_mode method and the climate. set_preset_mode service you mention. Either of these has the expected effect when called in Jupyter. My code adds a sensor for each climate entity in Wiser, updated from a data update coordinator. My code, in a simplified version, is as follows:

    @callback
    def _handle_coordinator_update(self) -> None:
        ontime = self._planned_sched_change - timedelta(minutes = self.state)
...            
        if self.state > 0 and ontime < datetime.now() and self._control_state != HEATING:
            ....
            self.coordinator.hass.services.async_call("climate", "set_preset_mode", {"preset_mode":"Advance Schedule"}, False, None, None, {"entity_id": <Wiser climate entity id>})
...
        self.async_write_ha_state()

The ellipses are for local data updates that happen as expected. The service call was copied from the Jupyter test. I have also tried calling the Wiser climate method directly.

2047

I love the idea of ‘passive mode’ implementation.

Can I ask about the range 14-18c. Is there a way this can amended? I have some rooms (conservatory) where I am fine with the temperature being anywhere from 11-13 degrees. However when I activate passive mode it pushes up the set point to 14 which crazily enough is too high. Can we change the range of the passive mode?

Thanks

2048

The 14-18 is just the initial default. You need to add a thermostat card which then allows you to change this range. It will save the range for future.

1 Like
2049

@msp1974 just another thought that could be another future enhancement to passive mode. It would be cool if there was an option for the top end of the passive mode range to track the schedule which is applied to that room. You do such a fantastic job at developing this integration that I don’t want to give you more work but just a thought for something that could be a useful addition.

2050

Nice idea, but I’m sure how that would work. Let’s say you have your room set between 17-19.5 and overnight, the schedule drops the temperature to 16, the max setting would then be below the min setting.

1 Like
2051

Very true, hadn’t thought of that scenario! I guess you could have some sort of condition whereby if the schedule temperature <= target_temp_low then it doesn’t apply.

2052

Could you have an offset? Eg the Lowpoint is 5*C lower than the Highpoint/Scheduled target

2053

This could be useful for temporary target increases or boosts possibly?

2054

The use of schedule temp as the max does initially seem like a good idea but I think we may be constrained a little due to the nature of how we do this and the fact the hub does not support. The more complex we make passive mode, the harder it will be to explain to someone what they are seeing.

I think we can get over the schedule temp being lower than min by having the min as a fixed point and the max being temps over that. Ie if min is 17 and scheduled is 16 then range will be 17-17.

However, what happens when someone changes the max temp in HA. What would this do? It won’t change the scheduled temp. It isn’t a boost. You can’t really ‘override’ passive mode temps. And what should the code do on next update if you have changed it? It doesn’t know if schedule has just changed so doesn’t know if it should change it to schedule or leave it.

I’ll think some more but think that maybe passive mode is just that, passive. We will add boost support as that make sense if using the physical control and this is a true time based override to passive mode. If you then want to be able to control the temp more specifically, you need to use auto mode (ie follow the schedule).

Welcome thoughts.

2055

Fair point on overriding/boosts. My idea was to have a separate switch entity that allows you to turn on following a schedule in passive mode. This mode wouldn’t allow manual overrides other than boosts until the ‘follow schedule’ switch is turned off. Just an idea. Maybe too complicated and not worth implementing.

2056

Agreed. It is a workaround to emulate a passive TRV given that the hub does not support it and I believe it is still essentially using the automation I wrote to acheive this, coupled with the API that I couldn’t leverage. Adding too many variables to the automation could make it very complex, very quickly. The (unpublished) automation I arrived at after posting the original had increased in complexity at least two-fold within a day, as I tried to take into consideration possibilities of moving TRVs between schedules etc. This was before @msp1974 built it into the integration, of course, which deals with it in much simpler way than I was able to acheive with the automation alone. Personally, I feel passive mode should probably be mostly decoupled from the schedules as it’s exactly that, passive. However, if it’s an option that is acheiveable without compromising reliability, then I’m all for that too. :slight_smile:

1 Like
2057

Interesting (and somewhat depressing) development on the hub issues this morning - I’ve been one of the many who have random wifi disconnects on the hub but my hub is located in the loft with my boiler so I don’t generally rush up there to power cycle it to get it back.
I noticed it dropped off a few nights ago and thought this morning i’d go and reconnect it - I was greeted with the usual solid red light on the hub.

  • tried the usual double press of the setup button - nothing
  • tried to power cycle the hub itself - after the usual orange/green flashing, back to the solid red light
  • tried to re-setup the wifi via press of the setup button and using the app… go through the connect to wiser AP dance, set my wifi password, get a tick to say it’s connected and I can see the hub settings (temps etc) - but the hub is still flashing green and my phone is still connected to the temporary wiser AP
  • then disconnected from the hub and went back to my home wifi - can’t connect
  • power cycled the hub again, and back to solid red…

I can see on my router logs that the hub is actually on the wifi network as I see my router doing a DHCP offer to it, but something in the hub seems to fail and it never gets an IP (can’t ping it) - I see the DHCP offer every few minutes.

Not sure if there has been any firmware update for the hub, or if mine has just given up totally… but I can’t get it back on the wifi at all now.
Ticket has been raised with the wiser support people which I suspect may end up in a full reset and having to reconnect and configure everything again :tired_face:

2058

Have now managed to get this running by generating an event in my code with the Wiser climate entity id as payload, which is caught by a Hass automation and used to generate a climate.set_preset_mode service call. Would be nice to understand why the direct approach doesn’t work though.