[DEPRECATED] Updated Ecobee Suite, v1.4.0 (Free)

Yes, I think that you are using the Routine to change the temps in the morning, and it is making 2 calls (one for heat, one for cool). The Ecobee API requires both to be provided, so I think I am picking up the old/incorrect heat temp when setCoolingSetpoint is called. I think I have the fix for it already - just wanted to verify what you are seeing is what I am fixing.

That said, consider this: instead of having the ST Routine change the temps, why not have the thermostat change to “Home” or “Morning” instead? You can accomplish this with the Routines/Mode/Program Helper app I provide in the suite. Remove the temp settings from the Ecobee Wake routine, and instead set up the Routine Helper to change the Thermostat Program to Home (or whatever) when the Ecobee Wake routine runs. More reliable, and gets your thermostat into the correct program, instead of a Temperature Hold.

This feature is actually one of the primary reasons I invested in this Suite in the first place - I really want to keep my thermostat programs in sync with my SmartThings mode (Home, Away, Night/Sleep, etc.)

2 Likes

I guess the main reason is that it isn’t as wife friendly. She was going into the settings and mucking up the modes. So I deleted all the modes and just handle the temp changes under my smartthings automations. This is also nice because it puts everything in one spot, versus having my mode temps set on thermostat and then changing the mode via a smartapp that is deeper into smartthings. My wife is familiar with the “My Home” and “Automations” tab, but once you start diving into smartapps and what they’re doing she gets lost. If I ever have to replace an ecobee, factory reset, etc. this will help that issue too since I don’t have to worry about any data on the thermostats.

If you are picking up the old/incorrect values, wouldn’t this be easily reproducibile? I.E. I should be able to set the automation for a different temp than what the current one is, run the automation, and I should see it fail right away? This doesn’t seem to be the case, or am I missing something?

Gotcha. WAF is the most important metric, and if that works for you then so be it…

My apologies - I was just asking for you to give me a little more info about what was going on in your specific case. The trick is to generate the setCoolingSetpoint quickly, like right after the setHeatingSetpoint, and the only code I know taht does this is the SmartThing Routine that you are using. I don’t have this configured in my own home, so if it was easy for you, I was hoping to verify what I think is the problem.

I’m going to try to fix it tonight…

My specific case is pretty simple. I have two automations, one for sleep and one for wake. Each sleep and wake automation just sets the heating/cooling temp. Sometimes when the automations fire, the “heatHoldTemp” is not sent correctly. I don’t think I’ve had the “coolHoldTemp” not be set correctly, but that one is not as important right now as it’s still in the 20s (Fahrenheit) here. When the automations fire, it seems that “heatHoldTemp” is set to what the previous automation set it at. So if I have my sleep automation set to 66/74 and the wake automation set to 68/76, when the wake automation fires by itself it usually sets it the thermostats 66/76 (heatSetPoint is same as sleep automation, but the coolSetPoint is not).

I understand what you’re seeing - I’ll post an updated thermostat device as soon as I can (I’ve spent much of today trying to get my FiOS upload speed over 2Mbps…still not fixed, so I’ll post it no matter how long it takes, as soon as I can).

PS: the setHeatingSetpoint and setCoolingSetpoints are apparently called in that order, and when the coolingSetpoint is changed, it picks up the wrong heatingSetpoint. This is what I am fixing.

NB: Both setCooling… and setHeating… will enforce the delta configured on the thermostat (minimum between heat and cool). In setHeatingSetpoint, it will raise the cooling setpoint if the delta isn’t large enough, while setCoolingSetpoint will lower the heating setpoint to accommodate the configured delta. Depending upon your settings at the thermostat, this could be why you are seeing weird numbers. Or not…

My thresholds on all thermostats are 3 degrees and 68-74 falls well within this range. Also the setpoints seem to mostly work, it’s just sometimes that they don’t get set correctly. It’s not an issue that happens 100% of the time

Yep - it’s a race condition where the call to setCoolingSetpoint() is made before all the effects of setHeatingSetpoint() have completed, which is only an issue if the heating setpoint was changed.

In any event, I have a fixed version ready, if you’d like to test it for me tonight/tomorrow - I just need you to PM me an email address that I can send the file to as an attachment…

Strange indeed. Sounds like something’s wrong with the Android app, although I haven’t heard about this from anyone else. SmartThings support probably won’t help either, they don’t generally help out on 3rd party device handlers.

Is anyone else seeing this?

Can the smart mode helper also take into account if the ecobee is currently cooling for the if temperature is at or lower x temp; vice versa for if the ecobee is currently heating for the if temperature is at or greater temp x condition.

Maybe branch this helper to Smart Seasonal Mode…two cents.

Thanks for your reply Barry. Now I know what a Shard is. :grin:
It states in this post that I should be directed automatically to the correct Shard.

In any case, I followed your directions and the Apps are in the Device Handlers page, just “not published”

What am I missing?

Cheers

1 Like

@storageanarchy
I think I got it figured out. I had to click on the device handler as if I was going to edit it and then click the Publish button up in the top right corner. They are now published :+1:

Cheers

1 Like

Oh, sorry - I may have sent you on a wild goose chase (an American colloquialism :slight_smile: ).

To Publish apps:

  1. If you are using the github integration approach, there should be a “Publish” checkbox on the page that lists the repository files, but you may have missed it, so on to the manual approach:
  2. Go to My SmartApps in the IDE, and click on the file name of each of the SmartApps (each starts with “Ecobee Suite”). This will open them in the editor. Top Right you will see a button “Publish” - click that, then select “For Me”. Repeat for each of the SmartApps. Then go do the same thing for the two Devices under My Device Handlers.

Then, go to your mobile device, SmartThings App, MarketPlace, SmartApps, My Apps, and click on Ecobee Suite Manager - this app will guide you through the rest of the installation.

1 Like

UPDATE NOTIFICATION

As of 3:45pm EDT on March 20, 2018, Ecobee Suite Thermostat has been updated to version 1.4.05, and Ecobee Suite Manager has been updated to version 1.4.13

Changes in this release:

  • Fixed a race condition where consecutive calls to setHeatingSetpoint() immediately followed by setCoolingSetpoint() would result in the wrong heatingSetpoint being set. This situation can occur when using SmartThings Routines to set specific temperatures (instead of using the Helper SmartApps to change the thermostat Program). Thanks to @tscan for finding this one.

  • Optimized so that a call to setThermostatProgram() requesting Program change to Hold: XXX while the thermostat is already in Hold: XXX does not execute a redundant resumeProgram() followed by setting the Program to Hold: XXX again. Thanks to @ssilence for this suggestion.

  • Accelerated the display of updates to heating and cooling setpoints

  • Fixed an innocuous bug in a specific call to sendJson()

This update is recommended for all users, and both files should be updated together for the optimal result.

3 Likes

So unfortunately my automation that ran this morning did not set the house correctly again. The automation is set to 70/75, the coolingHoldTemp set correctly but the heatHoldTemp did not for some reason. I took some screenshots of the what the thermostat was sending when the automation ran this morning. I also took some screenshots of when the automation ran last night (11:30PM), and you can see that the wrong coolHoldTemp value is sent (760), but then right after the correct value is sent (800). When I ran the automation manually this morning, the correct heatHoldTemp and coolHoldTemp values were sent. Screenshots attached.

What are you using to set the temperature? Are you using a routine or one of the Helper Apps? I would greatly recommend not using the routine natively and set it with one of the helper apps. Plus, why are you setting the temp manually? Why not use the comfort setting programs? If you just want to set the temp manually you could buy a much cheaper and easier to implement “dumb” z-wave thermostat with no programming.

I am using a routine, just personal preference and WAF. I have different automations for different things. Sure these ones are just on a timer, but I have others for when we leave/arrive/etc. I had modes on the thermostat and people would mess with it and muck up the modes. I may just end up reverting back to the modes and putting an access control on the thermostat but I’d really like this to just work.

Okay. If you aren’t using the thermostat as intended then maybe you have to look for a different DTH.

What are your scheduled settings?

ResumeProgram would kick in your scheduled temperature Settings not sure if there’s a conflict.

Also which specific helper are you using?

He’s not setting the comfort settings. He’s setting hold temp through routines in ST.

I have two thermostats and have smartthings set to put them in away when we leave house, and resume schedule when we return. But for some reason when we return it doesn’t always put them both back on schedule, for some reason one of them is often still stuck in away mode. Not always, but enough to be annoying.

Any ideas? Or is this smart app not meant to handle two?