The problem with Ecobee (and other cloud integrations) that create devices is that async calls are a nightmare for updating devices in real-time. Sure, you can do it, but it's a pain if you are using said cloud device as a trigger for rules.
While I don't disagree that the async model is almost always the model to go with, it always add some complication to real-world events.
then maybe give the ability to adjust timeouts for synchronous calls....
I think that's already there though and where we might be seeing the issue (at least in regards to Ecobee).
totally. maybe it just needs to be adjusted.
Stupid ecobee API is giving problems right now as I type. Am working some ecobee code and the http calls are timing out. In this part of the code I wanted to use sync http for authentication but it can hang for 10s each call. If you have multiple calls queued up this could add up.
I wouldn't rule out the ecobee app. But without seeing the code I can't say for sure.
And people wonder why I ripped out all my Ecobee gear.... 
Joking aside, I really needed local communication to my hub for reliable automated vent management, and the Ecobee cloud bull**** just wasn't cutting it.
If I wasn't doing that, and didn't need the reliable hub integration, I would have kept the Ecobee.
Is there anything within HE to mimic remote sensor heating ? So the thermostat focuses heating up one specific room based off a temp sensor like Ecobee ?
Nothing built for that. So I just made a user app to handle that the way I want.
With my app I can control off of any temperature I want by biasing the thermostats temperature reading to match my selected zwave/zigbee/other temperature in Hubitat.
Not every zigbee/zwave thermostat can programmatically adjust the temperature calibration/bias though. That's why I went with the GoControl model I use (it does allow it).
Do you plan to release this app to the wild?
I think it is posted in a thread on here somewhere... Or maybe that was just the vent balancing part... I would share it, though - it is pretty simple (custom code often it - it is making it generic/foolproof that makes code long.hard to write).
That said, it isn't super useful as-is for general use at it is specific to my needs and specific to the GoControl thermostat using my user driver (the built-in driver doesn't expose the temperature calibration attribute).
But it could be useful as a go-by for someone else.
My HE is plugged directly into my router, an Asus RT-AC68U. My laptop is also plugged directly into the same router. I have a couple of switches in the house (DLink), but I unplugged the connection to those so that I only had the HE and my laptop on the router. Same thing.
Woke up this morning, the ecobee site and servers were down. Throughout the day servers would randomly stop responding. Servers are down again right now.
Its amazing how bad it goes. But I only really notice it because I'm watching logs and working on an app. Otherwise I probably wouldn't even notice.
Yes, it is still down now . I don't why Ecobee server has so many outages since last year.
The replacement for my apparently-defective HE works great.
Are you on the latest build? Iām finding 2.0.9.132 is very responsive. Look for devices throwing a lot of errors. That will definitely affect performance.
Its been better for me ever since I disabled the Ecobee app. I did have the Zigbee radio go offline once or twice but it has been much less frequent. There has been also a lot of updates with the hot fixes, so I need to let things settle down.
I still though see very large spikes during the maintenance period.
That is to be expected. Is it consistently as high as 45seconds?
Mine spikes every night at 2am but it rarely goes above 20 seconds.
Yeah I do expect it to be higher during the maintenance, it just seemed higher then most others that have posted their results.
Usually its around 25-30 seconds on average.
Yup.
I assume you are using the perfMon through node-red. Are you also collecting logs and events through NR and if so, are you using the Maker Api calls to fill in gaps?
I had to spread out my timers in NR so that the Maker Api calls didn't coincide with the Performance Monitor calls becasue it ended up creating huge spikes....especially if they occured during maintinence.
I have a flow setup to write the events to my InfluxDB and a flow that refreshes the devices. Both of these use websockets though, not the maker-api.
I am not collecting logs either.
Download the Hubitat app
