Thanks. What comes to mind is that would require me learning new things? 
Like, can I call a IFTTT function from within webCoRE? I think I can, but I would have to educate myself. (Think old dog ... new tricks). I am willing to go there if the functionality is not built into the integration in the near future. Until then, my current setup does work, even though it does require maintenance as it loses authentication.
IFTTT takes a lot less mind share to learn than webCoRE. It's literally, if THIS happens (click on the word "this" and select a Hubitat trigger, such as a switch turns on), then THAT should happen (click on the word "That" and select the Ecobee action, such as resume program for example). Not hard at all.
Just to communicate my wish list, what I am hoping for is a single thermostat tile that includes current temp, heat and cool setpoints, and mode settings. would be fine if mode was through a pop up, and would be fine if the tile would need to be set as double wide and or height. I would really like to be able to set background tile color on if the unit is currently running.
Use case
I have one ecobee4 downstairs, and another ecobee 4 to control upstairs. I envision each thermostat having a thermostat tile on my dashboard. It would be nice to be able to look at my wall mounted ipad from a distance with dashboard running, and be able to tell which zones are currently kicked on by tile background color. I would also like to be able to adjust either thermostat from the dashboard.
2 Likes
Okay. I took the 10 minutes to study up on IFTTT and activating from webCoRE. You were correct in that it was not as big a deal as I was thinking it was. I created separate IFTTT recipes to switch ProgramMode to Away/Sleep and Resume (Home). I added those into my webCoRE pistons in place of the ST ported driver calls. We will see how it works. One thing I was doing before was checking the ProgramMode state of the thermostat before sending a command to change it (in case it was already set there). I have no way to query the thermostat for ProgramMode with the current integration so I cannot do that check before I change the ProgramMode. Not a big deal (I hope).
If it works, I will be able to remove the ported ST Ecobee apps/driver. Thanks for suggestion.
1 Like
This! I was about to setup the Ecobee app for this very use case and realized this cannot be done. Controlling Home and away is really the primary use case I need to integrate my thermostats with HE. The ecobee app is very feature rich and I use it to make adjustments to temp but automating the programming mode is important.
@mike.maxwell are there any plans to allow program mode changes with the stock app and driver?
2 Likes
How has this worked out for you as a temporary alternative until native integration of these features?
Unclear at this time. It did not appear to work as expected on Friday. I went back in and reset the IFTTT webhook string and copied that to webCoRE and added the IFTTT integration into HE (I had not done that part and I think that was my problem). It does look like it functioned as I expected last night (switched the ProgramMode to 'Sleep' and then back to 'Home' based on conditions). Not enough activity (everyone leaving or someone returning to an empty house) to determine it if is effective, yet. I will know better after a few more days of observations.
1 Like
+1 for setSchedule('away/home/sleep/etc'), so I can do a custom command from RM. That's how I've always done Ecobee automation (with ST), using the program modes.
Plus the set temperature isn't working properly from RM. It always sets to the maximum allowed temperature.
Right now if I try to use the setSchedule capability in the driver I get the following error if I send a string. Either I'm sending the wrong content for this action or it doesn't work. If the former, please point me to some instructions.
[dev:353](http://REDACTED/logs#dev353)2018-08-06 15:38:53.159:errorgroovy.lang.MissingMethodException: No signature of method: EcobeeThermostat.setSchedule() is applicable for argument types: (java.lang.String) values: [ANYTHING I PUT HERE] Possible solutions: setSchedule()
I can't figure out what sort of json it's looking for, or if it just doesn't work.
I'm also getting the following using the resumeProgram call
[ev:353](http://REDACTED/logs#dev353)2018-08-06 15:35:04.999:warnsetSchedule() is not supported by this Ecobee Device
For now, IFTTT will have to do. It's just a PITA to setup.
ACK! I was so excited when I saw this is supported, installed the app, found the devices, polled them and everything looks awesome. Then, went to create a rule to put Ecobee in away mode when life 360 says everyone is away. No option to set the ecobee into away mode (or to resume programming) through rule manager.
PLEASE add this. This is the only thing I use the Ecobee integration for. Currently, I rely on IFTTT, which works okay, but it is a bit slow to react.
Thanks for the Ecobee integration! Being able to control the thermostat based on different sensors around the house was one big reason I went ahead with buying a Hubitat!
That said, I'm encountering a single issue at this time. Trying to set the "Fan" to "On" through Hubitat (or changing the fan state in general) just results in my thermostat being placed into "Home" mode. (As if I had tapped on "Home for Now" on the ecobee UI.) In addition to this, the Fan's mode isn't modified at all. (It remains on Auto) Is it safe to assume this isn't the expected (or rather, intended) result?
I only tested turning the fan off with via my Nest Protects! Never tested my rule that is supposed to turn them on. I get the same thing, just goes into Home and Hold.
Glad the fan off rule is working. Guess I'll use homebridge for the fan on rule for the time being.
+1 on being able to adjust from a single tile. ActionTiles approach would work great in my opinion.
Any updates on this? Any effort being put forth to make the native Ecobee interface allow the changing to thermostat modes? Like others, I only need to set away mode, and resume schedule.
2 Likes
Resume is available now. I setup a Custom Command in RM to make it available to my rules. I set the Heating Set Point and Cooling Set Point due to the programMode not being available to mimic my AWAY and NIGHT (SLEEP) modes then I use Resume to go back to HOME mode. Not as elegant as setting the programMode directly, but I have found it effective. One thing I have not been able to overcome without setting up way too many RM rules is that I have two thermostats and I have their AWAY and NIGHT (SLEEP) set points set up differently. If programMode was available I could set those in each thermostat separately, then just change to programMode I want once for both thermostats.
4 Likes
Just curious. Do you have Sonos?
No.
I have some Fabriq Riffs, but they are not currently apart of the HE system, due to the problems I've been having.
I see. Just wondered if something like that might be causing issues on the network. I visited a client today where I had installed a 6 node Linksys Velop system. Recently they added a Sonos speaker and their company tech that supports their IP phone system said they were experiencing severe packet loss that was affecting their phone call quality. He disconnected the node that just happened to be closest to the Sonos, and said their issues stopped. The node they disconnected happened to also be the master.
i researched the issue and found several people reporting issues with Sonos WIFI interfering with not just Linksys Velop, but also Orbi WiFi. So I tested their system with and without the Sonos plugged in and sure enough it was causing the issue. I reconfigured it to use ethernet and disabled its WiFi and the issue seems to be resolved.
I think you said you had Orbi and so I just wondered if you might have a device on your network that you hadn't considered, which might be causing unexpected issues.
This is the wrong thread for this discussion, but since my other thread was closed...
I wiresharked the network and didn't see anything unusual after I removed the DLNAPlayer driver. I don't have a managed port I can sniff, at home (the Orbi is a consumer device). And I know wireshark doesn't see everything from it's vantage, so it's still possible, but I'm dubious.
Once DLNA PLayer was eliminated, I continued to have problems. However, I can report that I've been running without a crash for 2 days and nights now. After the first night I didn't crash, I noticed the DB had gone from 31mb to 6.5mb and a device I was having trouble keeping in the HE zwave tables was back and stable.
I can't say what's the solution, or if it will or will not return. But it seems to be indicative that the db shrank so dramatically. The staff says it was nothing they did, joking that the hub will be on it's best behavior because they were watching so closely. 
Still no explanation why the dB size when down so much?
