So, I will disagree with this. This works for me currently every day, but it's also the only current automation I have setup in the Apple Home app, and I am wanting to consolidate everything to HE. I do have a Homebridge so I can tie into TP-Kasa and turn on the light. Ecobee has a QR code so it can be added to Apple Home. Apple can use 3 things from the sensor: temp, motion, and occupancy. There is a corresponding automation that will turn off the light when "no occupancy" is detected. I have not timed this, but, yes, maybe it can take 30 minutes (I don't care).
Sigh!
Yes, these WILL work using Apple Homekit, because Homekit is able to directly communicate with the Ecobee thermostat, using an API that is not available on Hubitat.
On Hubitat, it does also work, but responses are delayed by the Cloud API.
As always, YMMV!
1 Like
Sigh!
This is very unfortunate. Thanks for the clarification!
Do I have to install all the extras when I install via Package manger on my Hubitat? I seem to remember something about installing everything and not picking and choosing. I have read so much on the Ecobee over the past week that I am not sure if this was this package or some other one. Any help appreciated. Thanks
Yes, please install everything, even if you don't plan on using them all.
I am looking for a way to add/remove the Ecobee Thermostat "Sensor (built in)" function to/from Programs Settings.
I know I can add a stand-alone Echobee Sensor in the Hubitat Device using the Command "Add Sensor to Program". Also, I can remove a Echobee Sensor in the Hubitat Device using the Command "Remove Sensor to Program." Those attributes being respectively addSensorToProgram and removeSensorFromProgram.
However, I don’t see a command to accomplish this for the Ecobee Thermostat "Sensor (built in)". Is there a way to accomplish this?
Yes - just turn on the preference option to use the thermostat as a separate sensor, then you should be able to add/remove it to programs…
@storageanarchy, thanks for the response. I am looking at the Thermostat device in Hubitat and I do not see that option under Preferences. All I see is Hold Type, Hourly Hold Time, Smart Auto Temp Adjust. What am I missing?
myVersion: Ecobee Suite Thermostat, version 1.8.25 on Hubitat
All preferences are set in Ecobee Suite Manager/Preferences. Turn on Include thermsotats as a separate sensor?
@storageanarchy, thanks for the response.
So, it looks like the devil is in the details. “Include thermostats as a separate sensor”, is found under the Hubitat Ecobee Suite App by selecting Ecobee Suite Preferences. Not under the Ecobee Thermostat Hubitat device preferences, as I would have thought it would be.
However, there is another item one must select, that is “Sensors” under the Hubitat Ecobee Suite App and add the Thermostat as a sensor, so it appears as a separate Hubitat Device.
I have included these details in case someone else is looking for this type of functionality.
I have an Ecobee Enhanced arriving this weekend as well as a couple sensors, and have to choose which integration to use with it, between yours and the stock HE integration. (Oh yes, the pressure is intense. 
)
Is there a brief summary of the most significant differences between your integration and the built-in HE integration?
I've been using UES since it first came out on SmartThings (before Barry took it over).
Back when Ecobee had cloud issues, this (Universal Ecobee Suite aka UES) kept the login working while the stock one (in SmartThings) would constantly disconnect. This hasn't been a problem for years now.
UES has many additional helper apps that you might want to utilize. (I never used any of them).
UES exposes all the controls available in the cloud API. There is a staggering amount of information and control available. This is an Ecobee thermostat in the native integration (all of it) vs. UES (1/3 of it):
The difference is true for remote Ecobee sensors. This is native vs. UES:
The Ecobee thermostat uses and reports the average temperature of all your sensors active for the current mode. This is the value at on the thermostat. You don't need all of your sensors active in all modes, for instance. I have 8 sensors on my Main Floor tstat, but only 6 are actively used. The thermostat also acts as a sensor itself (showing the temperature at the thermostat). A nice feature of the UES is that you can expose the thermostat sensor separately from the thermostat (which shows the average temp).
This last feature is the reason I still use UES on my 2nd hub; I then send that device back over to my main hub via Hub Mesh.
Truly, I never used the Ecobee integration to do more than know what my Ecobees were doing and reporting (e.g., I have a rule that alerts me if I have windows open when either thermostat runs). I never utilized any of the extra features of UES.
UES consumes very much more resources than the native integration. This is not surprising considering all the data it digs out and makes available. App stats on my main hub running the native vs. UES on my 2nd hub, similar uptime:
FWIW, I've also setup a RaspPi running Home Assistant and used that as a HomeKit controller to talk to my two Ecobee thermostats (and my other Ecobee devices). This has the advantage of using local communication to get all the data from my Ecobee, completely bypassing the cloud. I'm exposing the all of the Ecobee devices on HA to Hubitat via the HADB (you can see it in the App stats). My intention is to soon only use this and turn off both the cloud integrations to Ecobee.
3 Likes
Wow...OK, thanks very much for all the details, appreciated. 
Regarding going to a Pi...I've done that for other things and removing the cloud requirement would be nice. I do worry that the more I complicate my setup the more my wife will want to kill me again after I die. But I assume in your setup that if the Pi/HADB disappeared suddenly that the Ecobee would hum along on its own, right?
I've also set up the home kit controller on Home Assistant and tied that into HE with HADB as well so that I can get "pushed" instead of "polled" equipment status.
However, as of right now I don't plan on uninstalling UES. What I did instead was modify UES to give the option of disabling scheduled polling which tremendously reduces "busy time" on HE. I use refresh command in the UES thermostat through rules when I need it to be updated.
There are some features of UES that can't be duplicated with the home kit controller in HA since the local API doesn't expose what the cloud API does. Custom comfort settings (only Home, Away and Sleep on HA), adding and removing sensors from comfort settings, exposing temp of thermostat as a separate sensor to name a few.
It goes without saying I suppose that I don't use any of the helper apps. These definitely won't function without scheduled polling. I've only been using this hybrid setup for about a week but so far so good.
I've been using UES since the Smarthings days as @jlv has. Amazing app!
Perhaps @storageanarchy will consider working in ability to disable polling officially making it an option for those who venture down the HA homekit controller path like some of us.
Making Ecobee truly "smart" is an adventure for sure.
2 Likes
As I said, I've never done anything to control my Ecobee thermostats from Hubitat nor do I plan to. I just use the integration to monitor and make the Ecobee sensors available to the rest of my automation platforms.
I use Ecobee's built-in schedule and comfort-settings to let the thermostats do all their own autonomous, local processing. If my Hubitat or Pi went away, my thermostats would continue to do exactly what they've been doing for the last 7+ years.
4 Likes
If UES doesn't poll, it cannot report current status nor execute commands...
Issuing a command forces a poll from what I've found in viewing logs. I can send a command and the UES info updates within a second or so. It's the scheduled polling that I made optional. It's definitely working without it. I wasn't sure that it would either but I wanted to try it.
In simplest terms, I'm using UES to issue the commands and HA and home kit controller to view system status, sensor temp and motion all via push updates which appear within seconds rather than waiting for the next poll in UES.
The only problem I ran into was if someone makes a change on the thermostat, how could I force UES to poll. With a few virtual switches in HE which I exposed to HA and a few automations on the HA side, I was able to set up a rule in RM using those switches as triggers to have it check if a refresh command needed to be sent to UES Thermostat. That's working as well.
The advanced command ability of UES and the push updates from HA homekit controller. Bottom line...near instant updates on status, no overhead of scheduled polling.
Pretty nifty, but definitely over the heads of the casual user.
FWIW, you'd get almost the same effect if you set the poll interval to 30 minutes...
1 Like
You're probably right. That was my plan "B".
Anyhow, I submitted a pull request on github if you wanted to check it out. As long as "Disabled" isn't selected for a polling interval, it functions like normal. I've tested it both ways.
