My Ecobee Suite does a TON of calculations and string manipulations for every cycle (poll) of the Ecobee servers. On SmartThings, this usually takes between 2-4 seconds; on Hubitat it is more like 5-10 seconds. And there's some sort of "leak" on Hubitat, after about 24 hours of running, the ES Manager cycles will take 25-50 seconds, while SmartThings doesn't waver.
So, I suspect that the CPU's my stuff runs on in Amazon's cloud are bigger/better/faster. I did some looped math testing, and the SmartThings CPUs are consistently 2-3x faster than the Hubitat's processor (doing the same task).
Plus, network traffic from Ecobee to SmartThings (and Alexa to SmartThings, and...) all run "local" within the Amazon cloud, where the routing latencies have long been optimized by all the traffic. Ecobee-to-SmartThings transfers happen thousands of times per second (for all the users - not just my code), but Ecobee-to-my_little_Hubitat are a tiny fraction, and involves routing through several IP routing nodes to get here.
A few milliseconds here, a few microseconds there, and things can really start to slow down.
It's because of this that I'm moving most of my cloud-based services (Ecobee, Echo Speaks, Chamberlain, etc.) back to SmartThings - better performance, and if the network is down, they aren't going to work anyway
Hmm, guess that's a good point. So you could argue running an ST hub (linked to hubitat) with zigbee and zwave disabled (for example) and just use it as a gateway for cloud stuff.
Reported it a couple of times, but since I can't recreate it outside of installing my whole Ecobee Suite, they kinda just let it die...
Can't really turn off ST Z-Wave in any permanent way, so I live with the added "noise" in the system mostly. I turn it off when I'm doing adds/edits...
I got them to pair, but they chew through batteries like crazy, and randomly don't respond. Reliable locks seems hacky at best (and probably why the batteries are draining). Gah... really wanted to be on a single system. =(
Guess I know what I'm doing this weekend. lol. Hopefully I can get the Schlage locks to work without moving other zwave devices over.
And here I was thinking "it wouldn't be THAT expensive to just buy a couple more Yale locks to replace the schlages with" =P
My plan is a pair of Z-Wave Range Extenders that I'll move over to the ST Hub to give it the reach it needs to get to the locks. Hopefully that will be enough. Everything else I need will be connected via HubConnect...
Doesn't matter - Zigbee works fine with ST left on. I actually am using the same network channel for both ST and HE (24) and all 150+ of my zigbee devices are just fine.., on both hubs.
Change line 590 of your Meteobridge Weather Station code to this:
[callback: meteoWeatherCallback, timeout: 20]
Let me know if it improves things, or if you start getting a different error - I'll need to see that error, because I can't reproduce the Read timed out error...
