[Release] Updated Open Source Ecobee Device Type and SmartApps

Please share your tweaks, @boreddead - if I can general-purpose them, I will!

@krusej23 -

There should not be any problem with these devices showing as “INACTIVE” - they should continue to work properly.

Although SmartThings has said that integrating custom DTH’s with the new activity monitors is not yet “released”, my next update will in fact integrate so as to avoid this issue. It also includes better handling of “offline” thermostats that lost their connected to the Ecobee cloud. I hope to post these updates today or tomorrow (thermostat and sensor devices only).

FWIW, I am referencing the branch I have made from @StrykerSKS’ version, which is available here: [RELEASE] The Best FREE Ecobee DTH and Helper SmartApps - Now with Ask Alexa Message Queue Support, and an Enhanced User Experience!

I’ve had this version of the ecobee3 installed for about a week now, and there are a few things I noticed. Not sure if these issues are specific to me or not, but here goes. When the tile says “heating to…” it is always an inaccurate number. The motion reporting function is always off. I think I saw that already mentioned here, that when there is no motion, it is reported in the app as there having been motion. That being said, the only thing that really frustrates me is the open contacts child app. It flat out doesn’t work, and I really want it to.

@Andy_Armijo -

Since you’re not using my version, I can’t help a lot, but here goes what I can offer:

  1. Not sure what you mean about “Heating to” an inaccurate number. What number does it show, and what number is set in the Schedule/Hold (as seen in the Ecobee App on your phone or on the web)?

  2. “Motion” is weird - it takes up to 15 minutes of activity for the Ecobee sensor to decide it has seen motion (occupancy), and another 15 minutes of inactivity before it decides that motion has stopped. This is the way the sensor works (which is very different from most SmartThings motion sensors).

  3. What is the specific problem with Open Contacts - what are you setting, and what isn’t happening?

Also, are you using iOS or Android?

I’m pretty sure I am using your version, which is why I posted here, unless there is an updated version somewhere that is ridiculous to find throughout all the various versions. The Heating to number is displayed underneath the main number within the device, and for instance it says 68, when the program has it heating to 70. I’m using an iphone, and the open contact sensor is set to turn off hvac after my backdoor has been open for ten minutes. It wasn’t showing anything in the log after those ten minutes, so I tried to uninstall the reinstall. Now it does show up in the log for ecobee, saying “open contacts handler,” but I still don’t think it is adjusting the hvac. I noticed I had that childapp unpublished, vs having the other child apps published. I’m sure I did something wrong there and was just going to check what the documentation says.

This is the thread for @StrykerSKS’ version - my version is discussed over here: [RELEASE] The Best FREE Ecobee DTH and Helper SmartApps - Now with Ask Alexa Message Queue Support, and an Enhanced User Experience!

Just to be sure, in your Ecobee (Connect) SmartApp, scroll down to the bottom…what is the Version number displayed there?

My version number is 1.0.3

For everyone monitoring this - Andy’s problem with Open Contacts is a bug in my version and I think also in @StrykerSKS’ version. My latest v 1.0.2 fixes this issue.

The problem with the temperature display turns out not to be a problem (per se). My version now displays things a little differently than prior versions:

  • If the thermostat is Idle, it will display the temperature at which a Heat Demand will be made - “Heating at 69.5” if the temp is set to 70. By default, this is 0.5 degrees lower than the set temperature, but this delta is configurable.
  • While heating, it will display “Heating to 70.0”…

Andy’s delta setting was for 2.0 degrees with no decimals diplayed, so he was seeing “Heating at 68” and “Heating to 70”…

Future users of my version, please comment/report issues on my Discussion Thread here: [RELEASE] The Best FREE Ecobee DTH and Helper SmartApps - Now with Ask Alexa Message Queue Support, and an Enhanced User Experience!

I’ve read most of the post on this thread, but did not notice this. I have three “Helper” apps set up to change ecobee mode to Away, when my goodbye routine runs, Home when “I’m Back” runs, and Sleep, when Good Night runs. It seems be working as far as the ecobees (I have 2), do change to those modes, but the Smartthings Ecobee (Connect) app shows them as Auto Away.

Heres a quick screen shot from the Ecobee App and Smartthings App. I clicked refresh, closed the app, etc.

Who’s version of the app are you using? I’m guessing you aren’t using my version as the colors of your icons do not match my version.

The problem is that my version and Barry’s version have now diverged so much that it is impossible for me to help users troubleshoot.

I had every intention of merging in his code, but unfortunately there were so many changes made that it was nearly impossible to perform a proper code review. And since he did not fork from my tree, there is no easy way to create Pull Requests.

Ideally, the changes that Barry has made could be contributed back as Pull Requests in discreet chunks so that they can be reviewed and merged properly. This means making ONE (1) functional change per request.

I had started this work and even created a new head branch outside of the SmartThingsPublic tree in order to make it easier to maintain. Hopefully I can find a way for us to get things merged so that we can have a common codebase and a common setup to troubleshoot.

1 Like

Ugg, you’re right. I am using the other version. I posted to the wrong thread. haha. :slight_smile:

@ptdalen -

I’m looking into it now. I’ll send you a PM to further the debugging…

Not sure if anyone else is still following this thread, but I am a complete novice and do not code. However, I bought an Ecobee3 Thermostat with a sensor, and installed the device handlers and smart apps as instructed.

After providing authentication in app, it would NOT resolve to the next step - after clicking “done” to save credentials, I got an “unknown error” message. After leaving the SmartApp and reopening, it went back to the credential screen. I could not close out of the app and re-enter to begin setting up the thermostat.

After 90 minutes of experimentation, I noticed that in IDE a temporary “testing” thermostat and “testing” sensor were added to My Devices. I could not remove them - got an error “cannot invoke method”. After poking around, I found that when these were created, they were NOT ASSIGNED TO A HUB. They were assigned to a location, but not to a hub. I manually edited both testing devices to assign to my hub, and closed, reopened the mobile app. Voila, it’s been running fine since then and generated both correct child devices after I reopened the Connect smart app.

This seems to be an issue with Stryker’s code AND with the stock code as well - it prevents removal of the Connect app and devices, regardless of who wrote it. Assigning to the hub seems a prerequisite for proper function.

Again, no idea if I’m talking nonsense as I don’t code, but hopefully this helps someone. Thanks.

@storageanarchy So why go back and fork @stryker branch and make your changes to his code through Pull Requests on a TESTING branch so you are contributing to the base code the normal way? Then you can stop your thread and just support this main one and you all are working together and not individually. These multiple threads are confusion to all the new users.

Because mine has digressed so much from @StrykerSKS’ version that a merge/pull is pretty much unrealistic.

I have released my version here, and it is running well for many users. You can choose to use StrykerSKS’ version, the stock SmartThings version, my version (linked below) or one of the not-free ones - it’s entirely up to you.


This is an unfortunate example of the down side of open source… a great
concept realized and implemented and then… is it the chicken or the
egg… and who was on first?

I actually beg to differ.

I undertook a near-total overhaul of the existing implementation. From the outset, I knew the result would be radically different from Sean’s. It was also not a collaborative development - I sought to implement things in a manner different from the existing work, intentionally so as to improve the operational efficiency of the implementation, and to support additional features. The existing architecture simply would not have been able to be “incrementally updated” to achieve my objectives.

While Sean did begin the attempt to re-integrate, he quickly found that there weren’t really “modular improvements” that could be added to his code, tested and released…it is more an all-or-nothing overhaul.

So, I took some open source, re-engineered it into a very different implementation, but keeping with the look and feel and operational interfaces as defined by SmartThings and Sean. I don’t see this as a “down side” of open source…rather, the availability of this accelerated my efforts to build a robust alternative to the pay-gate Ecobee DTH offered elsewhere. And I am now well into new enhancements and integrations (Ask Alexa, for example) that further distance this implementation from prior works.

In the end, we have 3 related but not differing implementations: the original from SmartThings, the enhanced version that Sean built on top of that, and the one I’ve built upon the cornerstone of Sean’s work. That they aren’t all “evolutions” within a single GitHub tree is (IMHO) not really all that important…

And FWIW, Sean is free to take the leap of faith and just drop my complete current code on top of his existing version. GitHub will not be able to cleanly identify all the individual changes, and he will lose my evolutionary steps that got me where this is today. Heck, he could even go back and start from the beginning of my branch (which was in fact copied, just not forked, from his implementation), and then roll the last 6 months of evolution into his tree.

Understanding this is both unlikely and unnecessary, I have instead created a separate branch for my own implementation. Use it (for free) if you like, or ignore it…makes no matter to me…

1 Like

Is it the lite model?

Yes, my DTH supports all ecobee models (3, lite and 4), as well as most other ecobee thermostats (smart, smart si and even ems).

Has there been any progress in setting a minimum fan runtime per comfort setting or during a mode change? I’d like to run the fan in sleep mode only a few times a night, but not all day.

Would it be possible to modify the handler to allow another smartapp to toggle the fan? So I could use a schedule to turn the fan on and off outside of Ecobees minimum fan time setting?