Home Assistant - Scheduled Temperatures

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
  • lloyd
    Automated Home Guru
    • Oct 2020
    • 160

    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
  • DBMandrake
    Automated Home Legend
    • Sep 2014
    • 2361

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

    Comment

    • lloyd
      Automated Home Guru
      • Oct 2020
      • 160

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

      Comment

      • zxdavb
        Automated Home Guru
        • Jan 2018
        • 106

        #4
        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; 15 November 2020, 01:33 PM.

        Comment

        • lloyd
          Automated Home Guru
          • Oct 2020
          • 160

          #5
          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; 15 November 2020, 12:59 PM.

          Comment

          • lloyd
            Automated Home Guru
            • Oct 2020
            • 160

            #6
            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

            Comment

            • DBMandrake
              Automated Home Legend
              • Sep 2014
              • 2361

              #7
              Originally posted by lloyd View Post
              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.

              [ATTACH=CONFIG]1673[/ATTACH]
              I see you are graphing the measured temperature from both HR92's in the zone - is the zone configured as a single room zone or a multi-room zone ? If the former, which one is configured as the sensor ?

              Comment

              • lloyd
                Automated Home Guru
                • Oct 2020
                • 160

                #8
                Originally posted by DBMandrake View Post
                I see you are graphing the measured temperature from both HR92's in the zone - is the zone configured as a single room zone or a multi-room zone ? If the former, which one is configured as the sensor ?
                Multi-room. Its a bedroom with a dressing area, so I thought this was the best approach.

                I have a number of zones with more than one HR91 in. All of them are set up as multi-room - in my mind this is almost the default. I can't see the downside to it (but I'm sure there must be one). 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.

                Comment

                • DBMandrake
                  Automated Home Legend
                  • Sep 2014
                  • 2361

                  #9
                  Originally posted by lloyd View Post
                  Multi-room. Its a bedroom with a dressing area, so I thought this was the best approach.

                  I have a number of zones with more than one HR91 in. All of them are set up as multi-room - in my mind this is almost the default. I can't see the downside to it (but I'm sure there must be one). 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.
                  The downsides to multi-room zones are:

                  1) You can't use a remote sensor like a DTS92E, only the built in sensor in the HR92's. (If you add a remote sensor to the zone it will just provide a temperature for display on the controller but won't actually affect the HR92's which will merrily keep using their built in sensors) If you have a room that really needs remote sensors this is a big downside.

                  2) If you make an override directly on the HR92 it will not propagate to the other HR92's in the zone which will remain at the scheduled set point. IMHO in a single room this is a disadvantage, but in a true multi-room zone where the HR92's are in different rooms this is by design and is an advantage. However if you change the set point from the controller it will propagate to all HR92's in the zone.

                  3) Local overrides made at HR92's don't show up on the controller or phone app at all, which will still indicate the normal scheduled set point. One consequence of this is you can't cancel an HR92 initiated set point override from the controller, or even know it exists for that matter.

                  Comment

                  • lloyd
                    Automated Home Guru
                    • Oct 2020
                    • 160

                    #10
                    Originally posted by DBMandrake View Post
                    The downsides to multi-room zones are:

                    2) If you make an override directly on the HR92 it will not propagate to the other HR92's in the zone which will remain at the scheduled set point. IMHO in a single room this is a disadvantage, but in a true multi-room zone where the HR92's are in different rooms this is by design and is an advantage. However if you change the set point from the controller it will propagate to all HR92's in the zone.

                    3) Local overrides made at HR92's don't show up on the controller or phone app at all, which will still indicate the normal scheduled set point. One consequence of this is you can't cancel an HR92 initiated set point override from the controller, or even know it exists for that matter.
                    I have not found the need to use local overrides, and I've not told the wife they exist . I think with HR92s their status might be obvious, but I have HR91s, and to some degree you are flying blind as to their status. If I do set an override, its not obvious to me how I cancel it, especially as you say its not reflected on the controller.

                    Comment

                    • zxdavb
                      Automated Home Guru
                      • Jan 2018
                      • 106

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

                      Comment

                      • lloyd
                        Automated Home Guru
                        • Oct 2020
                        • 160

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

                        Comment

                        • zxdavb
                          Automated Home Guru
                          • Jan 2018
                          • 106

                          #13
                          @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; 22 November 2020, 01:51 PM.

                          Comment

                          • lloyd
                            Automated Home Guru
                            • Oct 2020
                            • 160

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

                            Comment

                            • zxdavb
                              Automated Home Guru
                              • Jan 2018
                              • 106

                              #15
                              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'.

                              Comment

                              Working...
                              X