Home Assistant - Scheduled Temperatures

[zxdavb]

And graphing the data like this did alert me to the fact that a zone I thought was setup as multi-room was single room.

You could try this:

python client.py monitor /dev/ttyUSB0 -p

Which will give you data like this:

Schema[01:145038] = {
  "controller": "01:145038",
  "system": {
    "heating_control": "13:237335",     "orphans": []
  },
  "stored_hotwater": {
    "hotwater_sensor": "07:045960", "hotwater_valve": "13:081807", "heating_valve": "13:163733"
  },
  "ufh_controllers": {},
  "zones": {
    "00": {
      "heating_type": "radiator_valve",
      "sensor": null,
      "devices": ["04:189078"]
    },
    "01": {
      "heating_type": "radiator_valve",
      "sensor": "34:092243",
      "devices": ["04:056057", "34:092243"]
    },
    "02": {
      "heating_type": "radiator_valve",
      "sensor": "12:010740",
      "devices": ["04:056059", "12:010740", ...

... and this:

Params[01:145038] = {
  "system": {"mode": {"system_mode": "auto", "until": null}, "language": "en", 
  "heating_control": {"tpi_params": null, "boiler_setpoint": null}}, 
  "stored_hotwater": {"dhw_params": {}}, 
  "zones": {
  "00": {
    "name": "Main room", 
    "mode": {"mode": "follow_schedule", "setpoint": 20.0}, 
    "zone_config": {"min_temp": 5.0, "max_temp": 35.0, "local_override": true, "openwindow_function": true, "multiroom_mode": false
  }
},

... and so on.

[lloyd]

No, you should persist - it wont be that difficult.

HA's evohome integration already tracks the current setpoint (called temperature, and/or: status.setpoint_status.target_heat_temperature), and the scheduled setpoint (status.setpoints.this_sp_temp). Have a look in Lovelace (the Web UI); Developer Tools; States, and select one of your zones (e.g. climate.bathroom), and you'll see them.

So it appears to me that there may be a bug in the integration, but before I raise in on github, thought it worth running it past you experts first.

If I go into the developer tools in HA, and in the states select climate.room as the entity, this should give me that latest state as read via the api?

I can get the latest state by forcing an update in the services tab by calling EVOHOME.REFRESH_SYSTEM?

So what I should see in the states tab should reflect what is on my controller, and what I see in the mobile app. But sometimes it does not. I know I have the lastest data from the controller because before the refresh call I tweak the temperature on the controller, and it is reflected in the data received. At the moment I'm seeing this:

hvac_modes:
  - 'off'
  - heat
min_temp: 5
max_temp: 35
preset_modes:
  - none
  - temporary
  - permanent
current_temperature: 18.3
temperature: 13.5
preset_mode: none
status:
  setpoints:
    this_sp_from: '2020-11-22T08:30:00+00:00'
    this_sp_temp: 19.5
    next_sp_from: '2020-11-22T19:30:00+00:00'
    next_sp_temp: 16
  zone_id: '5164558'
  active_faults: []
  setpoint_status:
    target_heat_temperature: 13.5
    setpoint_mode: FollowSchedule
  temperature_status:
    temperature: 18
    is_available: true
friendly_name: Study
icon: 'mdi:radiator'
supported_features: 17

But my controller and app show

09:30 18 degrees
12:10 13:5 degrees
16:30 16 degrees
22:30 12 degrees

The scheduled setpoints are completely wrong (but would be correct on Monday-Thursday). What am I missing?

[zxdavb]

@lloyd - I think the system is behaving as expected.

Note that in the HA integration, schedules are treated differently to the rest of the data because they are: a) big, and b) don't change often (unlike say, room temps).

The controller is the authority - what is displays on its screen is 'truth', although you may be waiting for it to update a device (e.g. a TRV has a different setpoint because it hasn't updated with the controller yet) / to be updated by a device (e.g. receive an updated temperature from a DHW sensor).

The controller is in constant conversation with the vendor's web servers - this information will suffer from convergence & will often be a little dated (?minutes, ?seconds, ?less - dunno).

The HA integration does not speak directly with the controller, only the vendor's website (was Honeywell, now Resideo).

The HA integration polls the vendor's website every unit time (300 seconds by default - you can reduce it to 60 seconds), so by default, the data in HA will be 150 seconds out of date, on average.

If you ever require the absolute latest data available from the website (not the controller - although I think they're tightly convergent), you can call evohome.refresh_system, although there is usually no need to do so.

Note that the HA integration will automatically call evohome.refresh_system:
- every SCAN_INTERVAL (as described above), and
- after a change is made via the HA integration (e.g. changing a target temperature)

( I was thinking of adding another option to the above, but felt it wasn't necessary: immediately after a scheduled change to the setpoint (status.setpoints.next_sp_from )

For schedules, they are updated only when a refresh (for any reason) is happening and when status.setpoints.next_sp_from is in the past.

With all that in mind - if you're still having a problem, then let me know. I could add a evohome.refresh_schedules, but I think you'd have to submit a bug report first.

[lloyd]

Thanks for the quick and comprehensive reply. It confirmed the way I thought it operated and added a couple of extra useful details.

But I still don't see why the displayed schedule is completely wrong? The dates for setpoints.next_sp_from and setpoints.this_sp_from are todays dates, but they have setpoint times and values associated with them that belong to other days. The schedule being displayed has never existed for a Sunday, so where does it come from?

[zxdavb]

Looks like a bug then. You can submit is via https://github.com/home-assistant/core/issues & I'll have a look at it.

Three things:
1) the HA devs are pretty strict - having an issue will make it easier to have the corresponding bug fix PR accepted
2) it looks like one of those bugs where I'd probably need access to your system to fix (i.e. you grant my account access to your TCC system)
3) I'm a bit busy, presently, and I doubt any other dev would take on 1)

Having said all that, how about posting a copy of the corresponding schedule from the HA log. Change configuration.yaml:

logger:
  logs:
    homeassistant.components.evohome: debug
    homeassistant.components.climate.evohome: debug
    homeassistant.components.water_heater.evohome: debug

and look in home-assistant.log for 'Schedule'.

[lloyd]

Having said all that, how about posting a copy of the corresponding schedule from the HA log. Change configuration.yaml:

OK, I'll turn logging on. Where is it stored so I can export it?

[EDIT] - forget the question, I just remembered I'm running in docker -hence not being able to find in local fileystem.

[lloyd]

Having looked at the log, I suspect the issue may be that day 0 is being taken as Sunday, when it should be Monday.

I've set a different time for one SP for each day of the week. Today (Monday) is using Tuesday's data. Tomorrow will confirm if this the case.

Data from log:

2020-11-23 19:32:17 DEBUG (MainThread) [homeassistant.components.evohome] Schedule['Study'] =
 {'DailySchedules': [
	{'DayOfWeek': 0, 'Switchpoints': [{'heatSetpoint': 19.5, 'TimeOfDay': '08:30:00'}, {'heatSetpoint': 16.0, 'TimeOfDay': '19:30:00'}, {'heatSetpoint': 12.0, 'TimeOfDay': '22:00:00'}]},
	{'DayOfWeek': 1, 'Switchpoints': [{'heatSetpoint': 19.5, 'TimeOfDay': '08:30:00'}, {'heatSetpoint': 16.0, 'TimeOfDay': '19:20:00'}, {'heatSetpoint': 12.0, 'TimeOfDay': '22:00:00'}]},
	{'DayOfWeek': 2, 'Switchpoints': [{'heatSetpoint': 19.5, 'TimeOfDay': '08:30:00'}, {'heatSetpoint': 16.0, 'TimeOfDay': '19:10:00'}, {'heatSetpoint': 12.0, 'TimeOfDay': '22:00:00'}]},
	{'DayOfWeek': 3, 'Switchpoints': [{'heatSetpoint': 19.5, 'TimeOfDay': '08:30:00'}, {'heatSetpoint': 16.0, 'TimeOfDay': '19:00:00'}, {'heatSetpoint': 12.0, 'TimeOfDay': '22:00:00'}]},
	{'DayOfWeek': 4, 'Switchpoints': [{'heatSetpoint': 19.5, 'TimeOfDay': '08:30:00'}, {'heatSetpoint': 16.0, 'TimeOfDay': '17:00:00'}, {'heatSetpoint': 12.0, 'TimeOfDay': '22:00:00'}]},
	{'DayOfWeek': 5, 'Switchpoints': [{'heatSetpoint': 15.0, 'TimeOfDay': '09:00:00'}, {'heatSetpoint': 17.0, 'TimeOfDay': '17:00:00'}, {'heatSetpoint': 15.0, 'TimeOfDay': '19:30:00'}, {'heatSetpoint': 12.0, 'TimeOfDay': '22:30:00'}]},
	{'DayOfWeek': 6, 'Switchpoints': [{'heatSetpoint': 18.0, 'TimeOfDay': '09:30:00'}, {'heatSetpoint': 13.5, 'TimeOfDay': '12:10:00'}, {'heatSetpoint': 16.0, 'TimeOfDay': '16:30:00'}, {'heatSetpoint': 12.0, 'TimeOfDay': '22:30:00'}]}]}

And output from dev tools:

hvac_modes:
  - 'off'
  - heat
min_temp: 5
max_temp: 35
preset_modes:
  - none
  - temporary
  - permanent
current_temperature: 18.8
temperature: 16
preset_mode: none
status:
  setpoints:
    this_sp_from: '2020-11-23T19:20:00+00:00'
    this_sp_temp: 16
    next_sp_from: '2020-11-23T22:00:00+00:00'
    next_sp_temp: 12
  zone_id: '5164558'
  active_faults: []
  setpoint_status:
    target_heat_temperature: 16
    setpoint_mode: FollowSchedule
  temperature_status:
    temperature: 18.5
    is_available: true
friendly_name: Study
icon: 'mdi:radiator'
supported_features: 17

[zxdavb]

Well *that's* a schoolboy error - I am sure I triple-checked this at the time!

The code is >1y old, and no-one else has complained since (mind you, you're the first person I know of who's found a use for that data) - let me know how you get on!

[lloyd]

Todays schedule confirmed the error, so I've raised an issue on GitHub. Watch out for incoming

[zxdavb]

Yeah - gottit - thanks!