Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 22

Thread: Home Assistant - Scheduled Temperatures

  1. #11
    Automated Home Sr Member
    Join Date
    Jan 2018
    Posts
    69

    Default

    Quote Originally Posted by lloyd View Post
    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:
    Code:
    python client.py monitor /dev/ttyUSB0 -p
    Which will give you data like this:
    Code:
    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:
    Code:
    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.

  2. #12
    Automated Home Sr Member
    Join Date
    Oct 2020
    Posts
    55

    Default

    Quote Originally Posted by zxdavb View Post
    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:

    Code:
    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

    Code:
    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?

  3. #13
    Automated Home Sr Member
    Join Date
    Jan 2018
    Posts
    69

    Default

    @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.
    Last edited by zxdavb; 22nd November 2020 at 12:51 PM.

  4. #14
    Automated Home Sr Member
    Join Date
    Oct 2020
    Posts
    55

    Default

    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?

  5. #15
    Automated Home Sr Member
    Join Date
    Jan 2018
    Posts
    69

    Default

    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:
    Code:
    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'.

  6. #16
    Automated Home Sr Member
    Join Date
    Oct 2020
    Posts
    55

    Default

    Quote Originally Posted by zxdavb View Post

    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.
    Last edited by lloyd; 22nd November 2020 at 04:29 PM.

  7. #17
    Automated Home Sr Member
    Join Date
    Oct 2020
    Posts
    55

    Default

    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:
    Code:
    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:
    Code:
    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

  8. #18
    Automated Home Sr Member
    Join Date
    Jan 2018
    Posts
    69

    Default

    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!

  9. #19
    Automated Home Sr Member
    Join Date
    Oct 2020
    Posts
    55

    Default

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

  10. #20
    Automated Home Sr Member
    Join Date
    Jan 2018
    Posts
    69

    Default

    Yeah - gottit - thanks!

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •