I’ve added my thermostat to Hubitat as a sensor in addition to the thermostat device itself. That way I have a lighter weight device to hub-mesh to other hubs to use temperature readings in the room where my thermostat is.
However, today I noticed that the sensor’s temperature is different than the thermostat’s temperature. Mind you, this isn’t a Lil Bee, but the exact same physical device. When I go to the ecobee app on iOS, I can see the same readings: 70 for my thermostat’s temperature, and 64 for the corresponding sensor. So it would seem this is not an ESM issue. On the physical thermostat, it says 70 degrees.
How could this be? Maybe I’m misinterpreting what a “sensor” is?
Question about Smart Circ helper logic: how specifically does the outside/temp diff adjust the base recirculating times?
I understand that recirc times are periodically adjusted based on the variability of temp across selected sensors. What’s less clear to me is how the recirc timing changes if the temp or humidity diff criteria is satisfied.
Multiple of my Keen home vents are failing after a few years. And I've been unable to order replacements. Does Ecobee Suite (ES) support Flair smart vents? I see in the ES Smart Vent Helper that Keen Home vents are supported, but Flair is not an option. Do they work as "Generic Vents" or via some other mechanism?
Or maybe the broader question is what smart vents have people tested that work well with ES?
If you are looking at what the native ecobee app reports and/or what is displayed on the thermostat proper is the "aggregate" of all the sensors that are active for that mode. For example I have 7 sensors plus the thermostat sensor. I have the thermostat ignore the 2nd floor during cooling cycles during the day and then bring them in for the "sleep" mode. Normally during the day rooms on the first floor are usually 77 for my office and 75 for the family room. The thermostat is in the family room and it displays 76 degrees. About the time the recovery starts for sleep the thermostat now averages in the upstairs sensors and it jumps to 78 degrees while some of the sensors are as low as 75.
You can see the chart on Ecobee's web site in "My Home" graph. at 9:00 pm my temp displayed jumps up and then at awake were I exclude upstairs it now shows an immediate drop.
That’s a very helpful start point. What I’m really trying to understand is why a given thermostat’s sensor device in HE would show a different temperature than the thermostat HE device itself.
Based on your insights, it would seem that the thermostat temp is the average of all sensors, and the thermostat’s sensor’s temp is the reading at the thermostat location only.
Sorry to be a nudge...Just curious if the above functionality (changing the fanSpeed property of Settings Object: ecobee API) is something that could/would be added? Trying to figure out a way to achieve the result and see if Ecobee is what I stay with or look for a zwave/zigbee stat that provides the ability to control the fan and/or staging directly.
So I posted this over a year ago and just kind of let it go. You stated that you thought due to the polling of the API the run time would be off considerably. Since the email from the Ecobee seemed to work, I didn't worry about it. A couple of months ago, however, I didn't get an email when the filter time was passed. I very seldom open the Ecobee app so I never saw the filter change notification there. I had got complacent and not checked it and the filter time went over by about 100hours before I looked at it. I realize its not a problem with your app but I decided to implement the method I listed above of monitoring runtime myself withing HE. Just wanted to see how inaccurate it was. I set the polling to 1 minute, I had it at 3 minutes. Was worried that might cause issues, but not so far.
I have been using the HE method now for a few months and it works pretty well. The runtime I get usually is greater than what Beestat shows, but only by a few hours. Now that I have a variable in HE that keeps track I can send my self push notifications and announce it on my Echo devices during the day. So when I get a notification if it is not quite time yet I can just put the Beestat time in my HE variable and wait a bit longer. Now with the local notifications and echo announcements forgetting the filter shouldn't happen again.
tldr; Could the ability to update the filter change date be added within your app? It's not a attribute that I see but maybe it can be added?
I noticed a possible bug with Resume Program using the Mode/Switches/Program Helper Application. I have a switch called "Resume Downstairs". I have tried two methods to implement resuming my Ecobee program - via a RM rule (which runs resumeProgram() ) and via the Mode/Switches/Program Helper Application.
If my system is off and I choose to turn Fan On, clicking on Resume Program on the thermostat device page sets the system back to what it's programed to do (i.e. resumes the program). If I use RM it also resumes the program. However, the Helper Application does not resume the program from the Fan On state (it works for other states).
Could anyone possibly tell me what the number represents in the
weatherSymbol : 103.
I tried searching for it Ecobee weatherSymbol but looking at the Ecobee site API it only talks about WeatherForecast Object and the numbers do not match up, in other words there is no 103.
What I am hoping to do is capture the number or numbers that indicate rain and use them in a WebCore.
@terminal3 thanks for the info. I what mine most of Sunday and it did change. I'm still not sure what the 103" was but now I have seen 3 and 0 which matches the API definitions.
In the Open Contact Helper app, is there a way to delay adjusting the setpoint after a contact opens? The delay options are a bit confusing, because even though I did not select to turn off the HVAC, the option to delay turning off the HVAC is still there. Would setting a delay here delay setpoint adjustment? Consider this a feature request if this is not possible. Thanks!!
