[Release] Updated Open Source Ecobee Device Type and SmartApps

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?

I know you directed your questions to @StrykerSKS, but I thought I would mention that my version includes a Smart Circulation helper app that can be configured to accomplish what you want, including different cycle times for different ST Modes or Ecobee Climates/Programs. Just set the min and max to your desired minutes per hour (same value for both), choose the Mode/Program, and you should be good. Let me know if that doesn’t work for you. You can find the latest info on my Ecobee Suite here: [DEPRECATED] Ecobee DTH and Helper SmartApps


Thanks, I will give it a try. Do I need to remove all of Stryker Ecobee Connect apps and start clean or can I just add Smart Circulation helper to my existing setup?

Most users report that you don’t need to remove Stryker’s, but you do need to install (overwrite, save, and publish) my entire package on top of your existing Device Handers and SmartApps. See the instructions on my GitHub for the list of files, and the repository linkage info for the SmartThings IDE.

ALSO - your install will likely throw errors until you publish all of the DTHs and Apps - run Ecobee (Connect) when you are done updating and double-check your preferences, re-authenticate (even if it says you don’t need to), then hit Done to re-initialize everything internally. Then you should be good to go…

Given the chaos of the two versions and the lack of time on my part to reverse engineer every change that was made, I basically gave up trying to merge the two.

I wish that a true fork had occurred and that we could have collaborated. Instead, we now have the two different versions.

Since the momentum is now with Barry’s version I’ve pretty much stopped working on my version.

My original plan was to enhance the stock version but SmartThings was completely unresponsive in taking updates even after they were reviewed by their engineers. So it felt like a complete dead end from that perspective as well.

I’m even considering shifting my entire focus over to a truly opensource project where the entire platform is opensource and all the contributions are centralized and maintained.

1 Like

First, thanks to @StrykerSKS for his significant investment into this platform - I would never had undertaken my overhaul without the strength of the base that Sean had built.

Second, Yes, I made massive changes to the implementation, necessitated to change from the heavy full-data polling to the new, lightweight changes-only model. And thanks again to Sean - he steered me away from mistakes I wouldn’t have known about without his insight.

Third, I certainly made changes at a very rapid pace, a pace that would have overwhelmed most anyone trying to maintain a centralized clearing house for the code base.

So, all that said, I don’t know how many user/devs would want to engage in a collaborative effort, but if someone has the time to manage such an open source collaboration, I happily submit my version as the starting foundation.

I myself cannot provide the necessary oversight, and I have no interest in preventing others from extending what I’ve built over the past 6 months. With the recent addition of Ask Alexa messageQ integration, my Backlog is basically complete…

Thanks again, Sean!!!