[OBSOLETE] .. Updated Open Source Ecobee Device Type and SmartApps

Okay, I’ve updated the app so that it is now possible to use external devices to drive the watchdog and polling. Time will tell if that will make things better or not.

To activate the option (after updating the code of course), you:

  • go into the SmartApp → Preferences
  • Then scroll down and select “Monitor external devices to drive watchdog events?”
  • Click “Done”
  • You should now see a new section called “Watchdog Devices”
  • Click the link to go to the configuration page

You can choose from any of the following capabilities to trigger:

  • capability.battery
  • capability.relativeHumidityMeasurement
  • capability.illuminanceMeasurement
  • capability.motionSensor
  • capability.switch
  • capability.temperatureMeasurement

I also fixed a typo in one of the watchdog handlers that might have been causing some unnecessary watchdog rescheduling. So this should make things a little more stable. (Although I’m seeing severe scheduled events issues tonight where even the first scheduled event isn’t even firing for me sometimes.)

And to test this, I added the SmartWeather Station Device to my setup. This gives me an external source for temperature, humidity and illuminance that can then trigger updates.

Sweet. This is just getting damn fun now! Too bad I have to go to work, but I will be all over this tonight. If I can get a valid run signal inside 3 minutes this code will be worth it’s weight in gold. Just to be clear, is the polling call the exact same as physically pushing the refresh button while on the screen?

You da man!

Dave

Hey guys, I’m having a problem with my EcobeeRemoteSensorInit app which I assume is a problem with the smartthings scheduling being crappy.

How are you handling the ecobee remote sensor calls to get around the scheduling problem, I might switch to your solution if that portion is more stable.

Cheers,

Matthew

It is essentially the same. It actually has a shorter path.

In the Thermostat device, if you hit refresh, it calls the refresh() function in Thermosat, that calls thermostat.poll(), which then calls the Connect SmartApp pollChildren which ultimately calls the poll() function in the SmartApp.

This method goes to an event function (userDefinedEvent) which then directl calls the SmartApp poll() function.

Hi Matthrew,

I can only speak to my current experiences that I’m having.

I’m still seeing really bad ST platform behavior when it comes to timers. I’m also seeing bad behavior in the way that the token refresh is being handled. Both of which I think are related to the backend.

Even with all of the watchdogs I’ve put in, I’m seeing a disconnect about once every 48 hours on average, but some times it is either longer or shorter (like last night I had a disconnect after only about 2 hours). Now keep in mind that I’m really stressing the system with the development and testing I’m doing on the app, so I might be an exception case, others might be seeing better stability.

As you can see from the thread, I’ve been actively working on ways to work around the platform instabilities and will continue to do so until I find the right balance. In fact, I just started working on a side application that will focus on just testing out the Token Refresh methods to see if I can pinpoint what is causing that process to breakdown.

The refresh token from Ecobee has a validity period of 1 year, so even if the Auth Token expires due to platform scheduling we should always be able to recover. However that is not the behavior I’m seeing, so I want to figure out why and then fix it!

I’ll let other end users jump in to tell their experiences so that you can judge for yourself if you want to give it a try or not.

Btw, in my solution, there is no separate apps needed for sensors, they are handled as part of the main SmartApp that does the setup and install.

Sean,

I haven’t had to enter credentials for several days, maybe a week. You’ve done a great job with the watchdogs. The app is looking sharp also. At some point along the way while running the beta code I collected an app called “ecobee routines”. Is that still required?

Bob

It is required if you plan to be able to change the thermostat Programs based on the SmartThings Modes (Routines). For example, if you wanted to automatically change your Ecobee to “Away” when the house changes to “Away” then you would set that up in the ecobee Routines child app. You can access the child app through the main Ecobee (Connect) SmartApp. And then all of the different versions you setup (Away, Home, etc) will all be accessible in one place as children.

Otherwise you don’t need it.

When did you do that? I asked about a week ago or so and was told I had to use the setThermostatProgram commands using the advanced functions in Rule machine to fire the comfort settings off of proximity to house. Oh well that method works great.

Oh yea, no disconnects since I installed RC8, a few days ago.

I added it 15 days ago as part of the beta releases:

Sean,

There is no logic to drive the call as far as I can tell. In other words, I set everything up, selected the vent temperature as the watchdog device to fire the pull request, but never got to set the > operation and trigger temperature. This is already all in Rule machine , so I could just create a virtual switch and have the logic flip that switch while having you monitoring that virtual switch. Let me know though because I can’t see how you can trigger with just temperature unless your triggering every single change temp change? oh and what is that fancy play button now on the smart app?

The way I have it setup is that ANY change to any of those devices will trigger a poll().

I have other checks and balances in place to make sure that we don’t actually do an API request any more frequently than once per minute (which is still within guidelines that are allowed from Ecobee).

Play button??? What play button???

This play button:

And check this out. Polling data multiple times per minute now. Should I switch to rule machine to define the call event, or were you planning to add?

I went back and set up the pull request off a virtual Ecobee Watchdog Request switch that I fire in Rule Machine now when the temperature gets above 95 in the vent (e.g. system running). I think this is going to work pretty well, depending on how quickly the vent heats up (e.g. how much delay do I have before I even know the system started), as I can’t set the temperature too low or it won’t cool down that far in-between heating system cycles to reset the switch. it would be great if somehow you were able to set off the differential or rate of change of temperature, now that would be sweet. Anyway, if the system is running well on the polling, then you may get lucking and hit the normal poll before you even fire the request, but if your like 5 minutes away from the next poll, hopefully I can drop down to about 2-3 minutes or so. Overall, this should work pretty well.

I just need to add a rate limiter in the event handler. Not a big deal to add that. Then it won’t go all the way to polling.

Okay, I figured out what the play button is for. I subscribed to the “app” event, which appears to create this button to allow for a “touch” event to be passed to the app. In my case, this calls the watchdog function. I think I’ll remove it though as it will only lead to confusion!

@StrykerSKS Just wanted to say I have been using your code and been loving it and all the constant improvements. Thanks for all the hard work, excellent results and making it available to the community for free. I donated to @yvesracine for his code but had continual issues (not his fault but ST) which you seem to have address better with your watchdogs that auto fix. Your code opens up everything I need. PLUS for the first time I got to use IDE GitHub integration based on your excellent instructions and the experience has been great. I am so thankful for all the developers like you that contribute. :+1:

4 Likes

Thanks @dalec!

I have been doing some more side testing on the token issues and think I’ve found an almost bullet proof method. In fact, I see that the latest updates to the official device type from SmartThings is going down the same path I discovered.

I’m hoping to have some time to incorporate those changes this weekend. With those changes and some other cleanup, I hope to be able to do a full 1.0 release very soon (time permitting) that I think will be much more stable!

Also, now that SmartThings is releasing an updated version of their device types that will have better support for Ecobee 3, I’m planning to contribute back as much as they are willing to accept into the official release base. (I suspect my icon set wouldn’t make the cut, but I’m hoping other aspects can be incorporated.)

Ultimately I’d love for the official Device Type to be fully functioning for our basic needs and then provide other value added SmartApps only if needed for things that ST might not be interested in adding (e.g. Alerts, vacation modes, etc).

Time will tell how that will work though.

2 Likes

Unsure what version I should be using.

I had been utilizing v0.8.0-RC1: Beta version with support for fan mode control for almost a month. The utilization of fan control has been working great. Question - how do I recognize if there is an updated version, where would I find it, and is there anyway to identify if I can come off a beta version?

Post #168 is where the links to v0.8.0-RC1 was linked.

Sorry for the stupid question - not sure where to go from here.

Not a stupid question at all!

Are you using the GitHub integration method?

If the answer is yes, then you can check in the IDE for any new versions automatically. You should be able to safely move off of the beta track and back onto the main StrykerSKS-Ecobee3 branch as well.

If you are using the manual install method, just follow the links at the very top of the thread, pull the code from the main branch and put it into the IDE.