Do you really want to spend time debugging home automation that didn't function because the Ecobee or other remote servers are down again? I'm tired of wasting minutes of my life on that, and that's why I bought a HE.
The only reasons to connect an Ecobee to the web at all are:
remote access from a phone (when their servers are up),
collection of data for the pretty graphs (only works some months),
integration with other home automation gadgets (sometimes works),
software updates every few years.
If you don't need those things often, just disconnect it from the net and keep it offline entirely, and it functions just fine as a thermostat. Same reason as buying a Hubitat - things work much more reliably that way. Simplify, people - don't make things unnecessarily complicated, unless you actually like fixing broken stuff - don't use a computer when a simple switch will do the job.
While all local would be ideal this is just not possible with HE and Ecobee at the moment. Personally like I said a great alternative would be using only comfort modes. This lets the T-stat work with a schedule which is not reliant on the cloud but still gives the ability for HE to change the comfort mode in case someone is home on a day that the house is normally vacant. If it doesn't work because the cloud is down no big deal I can always then just manually adjust. I always use temporary holds anyways so my Ecobee will always go back to my normal schedule.
This is still a way to keep it simple/reliable and yet have some automation.
So, you're saying don't have your thermostat integrated with your home automation at all? Just because once in a while it doesn't work? I'm sorry, that's kinda of like throwing away your cell phone because it occasionally drops calls.
If the service is unreliable then yes, what's the point of automation if the cloud service that it's reliant on is down or has problems every 3-4 days.
No, I'm saying that independently operating thermostat and vents works fine, and far more reliably than integrating the two, because they are not relying on remote servers managed badly somewhere on the Internet.
I hate debugging HVAC at 3AM on a cold night when vents do not operate correctly due to an Ecobee or Keen Home server outage, and I've had both of these happen far too often to want to do it ever again. When the Keen Home servers drop out, the vents close and you cannot operate them from your phone.
Ecobee works fine with or without the Internet. Keen vents with Hubitat operate fine on their own. Hook them up together, and the vents only operate correctly 90% of the time, due to server outages on one or the other system.
Run them separately and they both remain reliable.
Your choice.
If Ecobee does not want to provide local control because it offers a "better" experience by using cloud infrastructure, then it needs to be reliable. It would be one thing if once in a while there was issues, but this is not the case. Just look at the Ecobee status page, it's literally multiple times a week over months.
This was the single biggest reason why I switched from Smartthings to HE, their cloud reliability just kept going down hill, just as Ecobee has more recently.
The go control thermostat doesn’t appear to support humidity control.
Man, I’d like to move off this cloud solution too, but I need two main functions. One where I can heat based if remote temp readings, and secondly a way to control the humidity in the house....
Ecobee does the first and can do the latter based on the humidity sensor in the thermostat (but not remote sensors).
HE can easily do the second if more granular control is needed.
No cloud necessary for operation of either.
I have 3 Ecobee thermostats (wall units, not room sensors) in my house. If 1 of the 3 goes to smart home/away I have the hub mirror that to the other 2. I'm planning to add something to compare the temperatures between the 3 bees and their room sensors, and if there's a large difference, run the fan on 1 or more thermostats to even things out without running the A/C, but I haven't started that one yet.
For those interested in exploring other neat things you can do with Ecobee and Hubitat, yesterday I released my full Ecobee Suite for Hubitat. It includes a Suite of helper apps that can handle mode/program changes, turning the HVAC on/off based on open/closed windows and doors, and even automated Thermal Comfort settings. You can even access pretty much ALL of the Ecobee settings programmatically (e.g. Rule Machine) for even more customization!
Previous versions were used by hundreds of SmartThings users, and the adoption rate is accelerating on Hubitat now that it is out of Beta.
Said simply, the Thermal Comfort helper first guides you through the factors that will arrive at temperature setpoints that you think are comfortable RIGHT NOW (based on your current humidity and the settings you choose). Once you find settings that match your comfort given the selected conditions, you essentially "lock in" all the parameters except Current Relative Humidity. As RH changes, the Thermal Comfort Helper will re-calculate what should be "comfortable" at the current RH given the parameters you've chosen - and if necessary it will adjust the setpoint(s) of the current program/schedule/climate.
Play with it - when you go to set it up, you can play with all the parameters to see how they effect the target setpoint...
@storageanarchy I'd rather understand in the case of the house temp than suffer through experimentation. When choosing an item in PMV in [X] mode - am I telling the system how I want to feel? For example, when Typing, with Typical Summer indoor clothing, I want to feel Cool?
If the settings "Typical Summer indoor clothing" and I want to feel "Cool" gives you an answer close to your current setpoints, and it feels good to you, then that's what you want.
I really can't explain it such that you have a simple answer - the whole idea is that there is a temperature given the current settings and humidity that feels good to you - and hopefully, once you choose the parameters, as the humidity changes, your setpoints will continue to feel good to you.
It's all so subjective that you really do have to experiment with it. Or ignore it altogether - nothing says that computers are really able to read your mind !!!
I accomplish something that pretty much does the same thing as this with 2 simple rules in rule machine and a virtual switch. One rule takes the humidity readings from 2 motion sensor values and when one goes above a set humidity value it triggers the virtual switch, and when the virtual switch is triggered and cues this rule to run
I'm pretty sure your rules will make a lot more adjustments than Thermal Comfort.
Basically, it appears that your rule says "As long as the humidity is higher than X when humidity changes, then set a temporary hold that reduces the target temp by -1°"
Seems like you could get to coolingSetpoint = 50°F pretty quickly on a humid day.
Here's the differences that I can see:
Yours does nothing in the winter, where higher humidity makes you feel warmer - Thermal Comfort works year round...
Thermal setpoint's algorithms won't blindly lower the coolingSetpoint lower and lower and lower - it usually takes maybe something like +/- 5°F before the setpoint changes +/- 1°
changing the program setpoint is persistent over days - your approach will restart the -1°F cycle every time the Thermostat changes programs
Thermal Comfort can change the setpoints for ALL your programs/climates/schedules persistently for each program...
That said, if you like yours, there's no requirement that you have to stop using it...I offer options, not rules!
NO, because if you read the rule it only adjust -1 degree for when the condition is true, and when the condition becomes false it adds +1 degree.....It's a conditions based rule not a trigger rule
Same rule applies in heat or cool mode.
And neither will this as a true condition only adjusts 1 degree, and doesn't adjust any further no matter how long the condition remains true, it ONLY adjusts 1 degree BACK when becoming false.
No my approach is triggered by humidity readings at which the sensors configuration isn't set to even report unless there is a 5% change from the previous report.