Results 1 to 10 of 22

Thread: Home Assistant - Scheduled Temperatures

Hybrid View

Previous Post Previous Post   Next Post Next Post
  1. #1
    Automated Home Sr Member
    Join Date
    Oct 2020
    Posts
    55

    Default Home Assistant - Scheduled Temperatures

    Not sure if I should be asking this here or on the Home Assistant forum. If the HA forum is more appropriate, let me know.

    Does anyone know how I can plot the scheduled temperature, as opposed to the temperature being requested by the controller? With optimum start and stop enabled, the requested temperature will start and end before the scheduled ones. I have the Total Connect Comfort (Europe) integration, and also receiving MQTT data from evohome-listener.

    Thanks

  2. #2
    Automated Home Legend
    Join Date
    Sep 2014
    Location
    Scotland
    Posts
    2,308

    Default

    Quote Originally Posted by lloyd View Post
    Not sure if I should be asking this here or on the Home Assistant forum. If the HA forum is more appropriate, let me know.

    Does anyone know how I can plot the scheduled temperature, as opposed to the temperature being requested by the controller? With optimum start and stop enabled, the requested temperature will start and end before the scheduled ones. I have the Total Connect Comfort (Europe) integration, and also receiving MQTT data from evohome-listener.
    When you retrieve the current set points from the Web API (either V1 or V2 API) you can't directly tell if a set point is due to optimal start acting or not - it just reflects the set points currently sent to the HR92's. (You'll notice the phone apps just show the set point as well and don't show an optimal start icon when optimal start is acting)

    However it is possible to retrieve the whole week schedule using the V2 API so that you could possibly calculate what the current set point should be based on the current date and time within that schedule. You can also retrieve the quick action mode (custom, eco/bost, away etc) and apply that to your calculation of what the set point "should be".

    However I'm not sure all the information you need to do this 100% accurately is actually available - for example I don't know whether the programmed offset of the new Eco/Boost mode (which is user adjustable) can be retrieved from the API. Nor what the cold weather boost offset or active/inactive state for a zone is. My guess is probably not.

    So it depends whether you just want the baseline schedule before other offsets like Eco/Boost etc are factored in, or whether you are trying to find the exact set point that would have applied if optimal start wasn't currently active for a zone - which might not be possible with the current Web API.

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

    Default

    I think the effort here exceeds an perceived benefits. So for now I'll leave it on the too difficult pile. Thanks for taking time to reply.

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

    Default

    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.

    You can set up custom sensors for these:
    Code:
    sensor:
      - platform: template
        sensors:
    
          bathroom_actual:
            friendly_name: "Bath Actual Setpoint"
            unit_of_measurement: 'C'
            value_template: >
              {% if state_attr('climate.bathroom', 'status') -%}
                {{ state_attr('climate.bathroom', 'status').setpoint_status.target_heat_temperature }}
              {%- endif %}
    
          bathroom_scheduled:
            friendly_name: "Bath Scheduled Setpoint"
            unit_of_measurement: 'C'
            value_template: >
              {% if state_attr('climate.bathroom', 'status') -%}
                {{ state_attr('climate.bathroom', 'status').setpoints.this_sp_temp }}
              {%- endif %}
    ...and then just graph sensor.bathroom_scheduled, sensor.bathroom_actual, etc.

    Or you could even just graph the difference between the two:
    Code:
    {{ 
      state_attr('climate.bathroom', 'status').setpoint_status.target_heat_temperature
      - 
      state_attr('climate.bathroom', 'status').setpoints.this_sp_temp 
    }}
    This is the relevant HA forum:
    - for evohome, and
    - for evohome_rf

    If you're using evohome-listener, then you have all the kit for evohome_rf, and it may suit you better - check it out!
    Last edited by zxdavb; 15th November 2020 at 12:33 PM.

  5. #5
    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.
    You are right. That was dead easy. Thanks for the info, its taken me a little further up the HA learning curve.
    Last edited by lloyd; 15th November 2020 at 11:59 AM.

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

    Default

    Just to conclude this, here's a graph that clearly shows the scheduled setpoint, and the setpoint sent to the TRVs. Nice to see the optimise start and stop operating - just a shame about the overshoot. But the system has not been in that long, so perhaps it is still learning.

    Capture.JPG

  7. #7
    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?

  8. #8
    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.

Posting Permissions

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