Ecobee attribute 'current_temperature' displays control sensor vs. area sensor

[Sudo-Rob]

The problem

The parameter being used for thermostat attribute current_temperature appears to be the temperature of the control sensor being used for regulation. This is what I’m observing:

This plot shows the temperatures being reported by the thermostat and a paired room sensor. At the time the bedroom sensor starts to control temperature, the value of the room temperature sensor replaces the value from the thermostat. During that time, both reported temperatures are identical, effectively making ground-floor temperature unavailable. The request is to display the sensors values rather than duplicating the value of the sensor in control.

To validate the observation, I installed the ecobee iPhone app. Here’s what I see:

The area above 2 Sensors shows some of what’s being displayed on the thermostat. Specifically, it shows the thermostat is set to regulate at 73°F and the temperature has reached the setpoint. Below are the values of the two sensors; the one highlighted is in control. Note they are different.

What version of Home Assistant Core has the issue?

2022.12.8

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant OS

Integration causing the issue

ecobee thermostat

Link to integration documentation on our website

https://www.home-assistant.io/integrations/ecobee/

Diagnostics information

No response

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

I am using the ecobee-3 lite thermostat.

[home-assistant[bot]]

Hey there @marthoc, mind taking a look at this issue as it has been labeled with an integration (ecobee) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of `ecobee` can trigger bot actions by commenting: - `@home-assistant close` Closes the issue. - `@home-assistant rename Awesome new title` Change the title of the issue. - `@home-assistant reopen` Reopen the issue. - `@home-assistant unassign ecobee` Removes the current integration label and assignees on the issue, add the integration domain after the command.

_{^{(message by CodeOwnersMention)}}

---

ecobee documentation ecobee source _{^{(message by IssueLinks)}}

[gittyupcowboy]

This seems to be related to a change I can't seem to source; or maybe it's a different issue, or maybe I'm crazy?

target_temps are reporting null; and "temperature" is now reporting the setpoint... this seems different than I remember but I only just noticed and don't have data retention enough to figure out what update/when that changed.

current states of Ecobee: current_temperature: 68.1 temperature: 66 target_temp_high: null target_temp_low: null

raw_json from Ecobee API:

"runtime": { ...snipped...
"actualTemperature": 681,
"actualHumidity": 41,
"rawTemperature": 681,
"showIconMode": 0,
"desiredHeat": 660,
"desiredCool": 675,
"desiredHumidity": 36,
"desiredDehumidity": 60,
...snipped...
}

API doc ref. for conversion:

The temperature values are all provided in units of 0.1 of a Fahrenheit (℉). For example, our actualTemperature of 711 is actually 71.1℉.

Meaning: "actualTemperature": 68.1, "rawTemperature": 68.1, "desiredHeat": 66.0, "desiredCool": 67.5,

Version:

Home Assistant 2023.3.4 Supervisor 2023.03.1 Operating System 9.5 Frontend 20230309.0 - latest

[Sudo-Rob]

Are you the code owner? I don't recall seeing notification of the closure.

[gittyupcowboy]

Are you the code owner? I don't recall seeing notification of the closure.

I am not; it looks like the issue was closed by sfanous as complete on Feb 27, 2023, 9:50 AM PST in the Pyecobee repo but I don't see any observable changes or explanation.

[issue-triage-workflows[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[Sudo-Rob]

There still seems to be an issue. As recently as June 9th, the behavior has been seen:

[gittyupcowboy]

There still seems to be an issue. As recently as June 9th, the behavior has been seen:

Observing the same as well.

[gittyupcowboy]

As previously mentioned, I've been experiencing the issue where the 'current_temperature' attribute displays the control sensor's temperature instead of the area sensor. Upon further investigation, I noticed that when the thermostat is not in the "heat_cool" (auto) mode, both target_temp_high and target_temp_low are null. Instead, the setpoint seems to be represented by the temperature attribute.

Here's a snapshot of the attributes I observed:

hvac_modes:
  - heat_cool
  - heat
  - cool
  - 'off'
min_temp: 44.6
max_temp: 95
target_temp_step: 0.5
fan_modes:
  - auto
  - 'on'
preset_modes:
  - Home
  - Away
  - Sleep
current_temperature: 71.6
temperature: 71.5
target_temp_high: null
target_temp_low: null
current_humidity: 47
fan_mode: 'on'
hvac_action: cooling
preset_mode: temp
fan: 'on'
climate_mode: Home
equipment_running: compCool1,fan
fan_min_on_time: 55
friendly_name: climate.ecobee1
supported_features: 27

I haven't really had time to try and dive into it, so I over-engineered a work around, still need to double check grafana and make sure it provides the same functionality - but it's a start I suppose.

template:
  - sensor:
    - name: "Ecobee1 Cooling Setpoint"
      unit_of_measurement: '°F'
      state: >-
        {% if is_state('climate.ecobee1', 'heat_cool') %}
          {{ state_attr('climate.ecobee1', 'target_temperature_high') }}
        {% elif is_state('climate.ecobee1', 'cool') %}
          {{ state_attr('climate.ecobee1', 'temperature') }}
        {% else %}
          unknown
        {% endif %}

    - name: "Ecobee1 Heating Setpoint"
      unit_of_measurement: '°F'
      state: >-
        {% if is_state('climate.ecobee1', 'heat_cool') %}
          {{ state_attr('climate.ecobee1', 'target_temperature_low') }}
        {% elif is_state('climate.ecobee1', 'heat') %}
          {{ state_attr('climate.ecobee1', 'temperature') }}
        {% else %}
          unknown
        {% endif %}

    - name: "Ecobee2 Cooling Setpoint"
      unit_of_measurement: '°F'
      state: >-
        {% if is_state('climate.ecobee2', 'heat_cool') %}
          {{ state_attr('climate.ecobee2', 'target_temperature_high') }}
        {% elif is_state('climate.ecobee2', 'cool') %}
          {{ state_attr('climate.ecobee2', 'temperature') }}
        {% else %}
          unknown
        {% endif %}

    - name: "Ecobee2 Heating Setpoint"
      unit_of_measurement: '°F'
      state: >-
        {% if is_state('climate.ecobee2', 'heat_cool') %}
          {{ state_attr('climate.ecobee2', 'target_temperature_low') }}
        {% elif is_state('climate.ecobee2', 'heat') %}
          {{ state_attr('climate.ecobee2', 'temperature') }}
        {% else %}
          unknown
        {% endif %}

This configuration checks the HVAC mode of the thermostat and then decides which attribute to use for the setpoint. It's a temporary solution, but it addresses the issue for now.

---

Ideas on why climate.py and ecobee are no longer playing nice:

1. Attribute Handling: The logic in climate.py might be prioritizing the control sensor over the area sensor when determining the 'current_temperature' attribute. This could be due to how the integration processes data from the Ecobee API.

2. HVAC Mode Handling: The integration might not be handling the different HVAC modes correctly, leading to null values for target_temp_high and target_temp_low when not in "heat_cool" mode.

3. Ecobee API Changes: There could have been changes or updates to the Ecobee API that are not yet reflected in the Home Assistant integration (I'm not sure what those might have been).

What probably needs to be done:

1. Deep Dive into climate.py: A thorough review of the climate.py file, especially the methods related to temperature attributes

2. Debugging: adding debug logs in the climate.py file can help trace how the 'current_temperature' attribute is being set and from which sensor it's pulling the data.

3. Ecobee api check: verify data, compare to climate.py/home assistant.

4. get someone from home assistant to take a look and obtain more insight

[Sudo-Rob]

You've made another observation regarding heat_cool, a mode I seldom use. Perhaps it deserves another issue.

The HA issues might also be traceable to the 3rd-party Python API (pyecobee), which hasn't been update lately. I suppose you've seen the changes in the thermostat firmware and perhaps the frequent updates to the ecobee app on your smartphone. I'm also guessing there could be changes in the API that might need some attention. With only 3.3% of the user base using the integration (present count = 6,412), it might be a stretch to lobby for additional attention to apply to the integration.

Ecobee has a supported API, so if there's internal interest with the HA developers, it would take an agreement to make it happen.

https://www.ecobee.com/home/developer/api/introduction/licensing-agreement.shtml

[issue-triage-workflows[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[Sudo-Rob]

Still occurring:

[rewardone]

I'd argue that this is working as intended.

If you have Follow Me enabled and a comfort profile is only using a specific temperature ... that is the temperature. Reporting a temperature that is not the temperature being actually used for thermostat control would be confusing.

In this case also note that Follow Me is not disabled during Sleep (which I assume is the mode/comfort profile being used) so Ecobee's current temperature is the temperature of your single occupied sensor. If both sensors are included in your sleep profile, you can also test this by triggering occupancy on your other sensor, which will then show the average once again until occupancy is cleared.

If you want area specific temperatures at all times, you can look into disabling Follow Me or use Helper entities (in this case a group) to graph instead.

[Sudo-Rob]

With all due respect, I disagree.

Follow Me is disabled. There are two temperature sensors and substituting one for the other is not representative of of the parameter being recorded. In the above example, the temperature is not being controlled; it's coasting down toward the control temperature. The issue occurs during the nighttime interval when the control sensor is switched.

FYI, I could plot the control temperature. It would be a straight line.

[rewardone]

Can you go into Settings > Devices/Integrations > Enities, sort by Integration and then provide all of the entity_ids provided by the ecobee integration?

Another thought is that there are 3 temperatures and your plot only shows two. Each sensor should have a sensor._temperature entity. The climate.current_temperature is separate.

[Sudo-Rob]

There are only two temperature sensors -- one for the thermostat and one for the remote sensor. Please revisit my original post.

[rewardone]

Indeed. You have one remote temperature sensor and you have the built-in temperature sensor for the thermostat.

The parameter being used for thermostat attribute current_temperature

The temperature sensor entities; however, have no 'current_temperature' attribute. Only the climate entity has current_temperature. The temperature sensors report their exact temperature states. The climate.current_temperature entity reports the average of the current comfort setting temperatures along with any additional modifications (e.g. Follow Me).

The integration should show that you have two separate sensor.<>_temperature sensors, one for the remote sensor and one for the built-in thermostat.

I believe you have chosen to graph your remote sensor and your climate.current_temperature attribute, but is not graphing your second temperature sensor. This lines up with your statement here:

This plot shows the temperatures being reported by the thermostat and a paired room sensor.

The solution would be to 'simply' add your built-in thermostat temperature sensor to your graph. This would give you a constant plot of the exact temperature of each sensor and the current_temperature will be the controlled/average temperature.

It would be helpful for those trying to help troubleshoot to have full context into your environment, which would include listing all sensor entities being provided by your integration and their specific entity_ids.

Separate issue, I do think it's odd that the current_temperature reports only your occupied sensor though you mentioned having 'Follow Me' disabled. With Follow Me disabled, I would expect the current_temperature value to always be the average of all sensors. Typically, the sensor icons are shaded white when the sensor is being used for temperature calculation. In your image, only one sensor is shaded white and it is your occupied sensor.

If your home comfort profile is functioning as expected (e.g. Follow Me is disabled and the temperature is always the average) then I would recommend deleting your sleep comfort profile. Maybe use a custom with 'someone is home' instead of 'sleep'. Provide data for developers to identify if the issue is with the integration, the upstream python library, or is just how Ecobee functions (e.g. working as intended, however frustrating that may be).

[rewardone]

1. Attribute Handling: The logic in climate.py might be prioritizing the control sensor over the area sensor when determining the 'current_temperature' attribute. This could be due to how the integration processes data from the Ecobee API.

There is no logic in ecobee/climate.py for current_temperature. So the debugging would need to be with the Ecobee API. The value reported currently is runtime.actualTemperature

2. HVAC Mode Handling: The integration might not be handling the different HVAC modes correctly, leading to null values for target_temp_high and target_temp_low when not in "heat_cool" mode.

"Correctly" in this case I think is just a matter of design. Your analysis is correct. ecobee/climate.py only considers HEAT_COOL for target_temp_low and target_temp_high. here and here

And target_temperature returns None in HEAT_COOL, but runtime.desiredHeat in HEAT mode and runtime.desiredCool in COOL mode.

3. Ecobee API Changes: There could have been changes or updates to the Ecobee API that are not yet reflected in the Home Assistant integration (I'm not sure what those might have been). What probably needs to be done:
4. Ecobee api check: verify data, compare to climate.py/home assistant.

Specifically, verify that the data being used is as intended per the Ecobee API documents (if any). We are always at the whim of upstream service providers definitions for how they define the data should be interpreted.

[Sudo-Rob]

Here are the entitites:

I am plotting sensor.master_bedroom_temperature and sensor.home_temperature. Note I am not plotting sensor.home_temperature_2. I don't know when the _2 was created, but sensor.home_temperature appears to be without a unique ID (and designated read-only). It's populating the database. I am not using climate.home, which contains a temperature attribute that may have been swapped with the sensor data.

Control is a function of time of day, not occupancy. What I'm seeing in the plots looks algorithmic versus direct sensor outputs. Note that the two temperatures converge prior to control handover rather than take a discontinuous step. My guess is the integration is not providing direct sensor data, as it is virtually impossible for two sensors on different floors to perfectly track.

Perhaps the integration is a bit out of date as well. Here are two links:

https://www.ecobee.com/en-us/developers/ https://www.ecobee.com/home/developer/api/introduction/index.shtml

[rewardone]

I am plotting sensor.master_bedroom_temperature and sensor.home_temperature. Note I am not plotting sensor.home_temperature_2.

Since it is not in your image, how are you plotting a sensor that doesn't exist? Since home_temperature_2 seems to be the temperature entity for your thermostats temperature, why are you not using _2? Can you provide an image showing historical data for the last 24 hours with home_temperature and home_temperature_2 both plotted?

Control is a function of time of day, not occupancy. What I'm seeing in the plots looks algorithmic versus direct sensor outputs. Note that the two temperatures converge prior to control handover rather than take a discontinuous step.

Your intent is for time of day, not occupancy, for sure. Agree that you are seeing an algorithmic plot, which is another indication that Follow Me is affecting you. Follow Me uses a drop-off period of about 30m as it slowly decreases the weight of unoccupied sensors. Ecobee also has a 'Smart Recovery' period between each schedule change.

Other users report similar confusion for this problem. I would describe it as an Ecobee implementation choice vs an issue with the integration, which is correctly providing the data from Ecobee. See here for one example:

You can log into ecobee.com, go to Home IQ, open System Monitor, and look at the Follow Me graph to gain further insight into how Ecobee is choosing to operate with your data.

Perhaps the integration is a bit out of date as well.

The API specifies runtime.actualTemperature as 'The current temperature displayed on the thermostat.'. This is the parameter cimate.py is using, and seems correct. Not out of date.

Remote sensors use 'value' per the API which sensor.py is using.

Another separate issue, it could be a useful enhancement for integrations to expose the 'inUse' property provided by the API so that users can see when a sensor or sensors are being prioritized.

[Sudo-Rob]

Well, I need to fall on my sword. I have no recollection of creating it, but I have a template sensor that points to...

...wait for it...

...a...

...climate...

....home...

...attribute.

What's your favorite charity? I need to make a donation.

[rewardone]

Nobu Casa to keep the lights on or just continue to help others in the community :) I just happened to stroll by when digging into some things of my own. I too have ... too many entities that are referencing each other all over the place. :P

If this is a resolution, please be sure to close the issue.

[Sudo-Rob]

I already make monthly contributions to them.

I'll fix things to continue to feed the database and see what happens over the next few days. Then, I'll close it.

FYI: I'd like to forget I ever submitted this.

Thanks a bunch.