Honeywell CH/DHW via RF - evohome, sundial, hometronics, chronotherm

Share your Projects!
911

Should be OK now - please test.

912

It seems indeed to work now.

There was a strange occurrence where the eco -> auto resulted in away. Donā€™t know if it was a single event or reproduceable, still trying to capture all the steps that where taken.

913

Just send your packet log - may have been a corrupt packet.

914

Packet log shared through message

915

just upgraded to the latest version:

Logger: homeassistant.components.websocket_api.http.connection
Source: custom_components/evohome_cc/climate.py:383
Integration: Home Assistant WebSocket API (documentation, issues)
First occurred: 19:40:49 (1 occurrences)
Last logged: 19:40:49

[139778802225792] 'EvoController' object has no attribute 'svc_set_zone_mode'
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 141, in handle_call_service
    await hass.services.async_call(
  File "/usr/src/homeassistant/homeassistant/core.py", line 1488, in async_call
    task.result()
  File "/usr/src/homeassistant/homeassistant/core.py", line 1523, in _execute_service
    await handler.job.target(service_call)
  File "/usr/src/homeassistant/homeassistant/helpers/entity_component.py", line 204, in handle_service
    await self.hass.helpers.service.entity_service_call(
  File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 642, in entity_service_call
    future.result()  # pop exception if have
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 681, in async_request_call
    await coro
  File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 679, in _handle_entity_call
    await result
  File "/usr/src/homeassistant/homeassistant/components/climate/__init__.py", line 446, in async_set_preset_mode
    await self.hass.async_add_executor_job(self.set_preset_mode, preset_mode)
  File "/usr/local/lib/python3.8/concurrent/futures/thread.py", line 57, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/config/custom_components/evohome_cc/climate.py", line 383, in set_preset_mode
    self.svc_set_zone_mode(HA_PRESET_TO_TCS.get(preset_mode, SystemMode.AWAY))
AttributeError: 'EvoController' object has no attribute 'svc_set_zone_mode'
916

Iā€™m assume this issue I have is related to this:

917

I have identified, fixed & pushed a commit to fix this bug

1 Like
918

The hint is in the docstring:

def set_preset_mode(self, preset_mode: Optional[str]) -> None:
    """Set the preset mode; if None, then revert to 'Auto' mode."""
    self.svc_set_system_mode(HA_PRESET_TO_TCS.get(preset_mode, SystemMode.AWAY))

A fix has been pushed.

919

Just tested it going from ECO -> None(Auto) results in ā€œDay Offā€, some mapping going wrong?

920

This mapping is complex & you see I havenā€™t tested it a lot!

( I have people who do that for me :rofl: )

921

Here I see a mapping issue:

1 Like
922

@phdelodder Thatā€™s a nice spot - Iā€™m not sure how long that would have taken me to find!

Itā€™s the following line that reveal the bug:

SYSTEM_MODE_LOOKUP = {v: k for k, v in SYSTEM_MODE_MAP.items()}

Which maps SystemMode.AUTO to SYS_MODE_DAY_OFF_ECO instead of SYS_MODE_AUTO

1 Like
923

For me with the latest commit b119afa itā€™s running fine. All the functions/services I use are working like intended.

924

The same here! itā€™s running fine!

925

I am afraid Iā€™ll be refactoring the mode/preset code, which may introduce new bugs (this is for code quality, with a view to becoming an official integration).

In addition, I will be adding all the native mode to the state attributes, e.g., for the controller:

{'system_mode': 'auto', 'until': None}

ā€¦ so will be be able to do things like:

{% if state_attr('climate.my_home', 'status').system_mode.system_mode== "away" %}
  The system is in Away mode
{% else %}
  The system is not in Away mode
{% endif %}

ā€¦ and, for zones (and similarly for DHW):

{'mode': 'follow_schedule', 'setpoint': 20.0}

I strongly recommend people use the native service calls to set System/Zone/DHW modes - the schema imposed by HA is a bit limiting - it has no concept of ā€˜FollowScheduleā€™, for example.

926

The option change schedule is not gonna be an option? Or do i donā€™t understand your message?

927

I am talking about something else.

Evohome Zones can be in any of three modes:

  • follow_schedule
  • permanent_override
  • temporary_override (revert to follow_schedule after a while)

In addition there are other modes accessible to us via evohome_rf, mainly:

  • advanced_override (revert to follow_schedule set next setpoint)

HA has several modes, including:

  • HVAC_AUTO (follow_schedule)
  • HVAC_HEAT

HA has no way of distinguishing between the 2/3 overrides (temp/perm/advance). So when you change temp on a zone via the HA UI, you clearly intend to move from a mode (it may be follow_schedule) to one of the 2/3 override modes, but which one?

Iā€™ll give you another example;

  • HVAC_OFF

ā€¦ which applies to the Controller (heat_off), but not the Zones.

928

Perhaps this is planned for somewhere further down the line, but some form of persistence or assumed state between restarts would be good.

Invariably my HA instance gets restarted at least once a day, for various updates, so itā€™s rare that I ever have a complete ā€˜availableā€™ states for things like battery, open window, etc :slight_smile:

929

I like the way it currently is, eg:

When changing a setpoint through HA UI it set it self to temp override, if I want it permanent Iā€™ll change the preset to permanent. Additional if I want a specific duration I can use the evohome_cc.set_zone_mode

Hope it doesnā€™t change to much.

Can this modes info be added to the services.yaml for the call(s) that has the option available?

930

This is planned - it is a non-trivial problem.

1 Like