[Release] Updated Open Source Ecobee Device Type and SmartApps

Fixed. My Android OS was not update and was preventing app updates.

1 Like

I’m with that new version and it is crap. It has issues that it didn’t have before - like for example very often when the screen contains a list of items that don’t fit on it and I try to scroll down it shows me the bouncy animation like I have reached the end of the list. I have to try scrolling up and then down for it to allow me to see the items down.

1 Like

Temperature for me since this is primarily for a thermostat

For those of you on Windows phones and want to try a modified version of UI that doesn’t use the multiAttributeTile, I’ve added some hooks in the Thermostat Device Handler to allow you to switch over. In the code there is the following:

details([
// Use this if you are on a fully operational device OS (such as iOS or Android)
“tempSummary”,
// Use the lines below if you can’t (or don’t want to) use the multiAttributeTile version
// To use, uncomment these lines below, and comment out the line above
// “temperature”, “humidity”, “upButtonControl”, “thermostatSetpoint”,
// “currentStatus”, “downButtonControl”,

If you follow the instructions there to uncomment the last two lines there and comment out the “tempSummary” line, you will get an alternative to the multiAttributeTile. It isn’t as pretty but it should be functional and allow to have the same functions as the rest of us.

Sean,

Can you explain the polling to me? When it misses a poll by sometimes 2x or more, is it the ST platform, Ecobee portal or both? Trying to do some very simple stuff with Keen smart vents and it requires knowing when the system is running, but with the 5 minute polling it is off sometimes by 100%. In other words it says the system is idle when it is running and running when it is idle. Some of the delay is on the Ecobee side, but to be honest I have seen the Ecobee connect app read motion way before the native app on the iPhone reports it. I really don’t need the temperature to be realtime, but I am thinking a lower poll time might be needed to be more in sync with the actual unit.

Is there anyway you can have 2 different poll time settings, one that you switch to off of a permissive? For instance I only run this zone logic when the basement sensor is occupied. If that is true, run 2 minute poll time, else 5 minute. I think 2 values would be fine or just a lower value? Or maybe instead of polling everything quicker you could just poll state and temp quicker?

Any other thoughts? I think others who have tried this just gave up and used a separate motion detector/temp sensor but not sure how to get faster run notification. Basically it means when you look at system status in ST it has as much chance of being totally wrong as right on a number of variables without hitting refresh.

Dave

Let me see if I can shed some light on your questions.

This is really the ST platform having issues. Whenever a Scheduled Event for polling fails to run then it is only when/if one of the watchdogs that I’ve put in place that it is able to recover. There are a few things that will trigger the watchdog: the authentication token scheduled event, the watchdog scheduled event, sunrise, sunset or a “manual” poll event. Those are the only things (right now) that can trigger the watchdog (I use manual in quotes since it could also come from an outside event such as an IFTTT type trigger, Pollster or even Rule Machine).

I could try to get more aggressive on the watchdog events and increase the frequency, but I don’t think that will help much since the watchdog scheduled event also frequently fails. So the scheduled events all kinda depend on each other to get them back on track. Having one fail too quickly would likely mean that it won’t ever recover.

From everything I’ve read so far in the forums, doing any kind of polling faster than 5 minutes is likely to cause trouble. And using a Scheduled Event to facilitate that likely won’t work for very long. If you really want to try it, however, you can use Pollster to give it a try (https://community.smartthings.com/t/pollster-a-smartthings-polling-daemon/3447). You will note, though, that even the Pollster thread warns against polling faster than 5 minutes.

A “poll” to the Ecobee API is really just one request that returns everything, so polling for just motion and temperature doesn’t really change anything.

What I have been considering, is allowing for other outside events to be used to trigger a poll rather than just using the scheduled events. This would allow for more frequent polls or to poll immediately on certain actions. I could either add that to my code or you can actually already do it today using Rule Machine. Just pick some sensor you have that changes based on an event: a switch is turned on (or off), a motion detector is tripped, a door is opened, a temperature changes, etc. It could be any combination of them. These event based triggers can also allow the system to recover more quickly if a scheduled event fails.

But at the end of the day, if you really want real-time motion type control then the Ecobee sensors will never give you that. They have a delay on providing their status and once on they are active for 30 minutes.

There is possibly some hope coming in the future as Ecobee is testing a push API that could send us events if something changes. Unfortunately, they have not published that API so I don’t know how easy it will be to integrate yet.

Thanks for the time to give such a detailed explanation. I think the push API would work amazingly as you really just need to know when the system starts running and do the update at that time. Also you could push the sensor data on 1° temperature changes or on motion status change. This would lower the amount of data flying back-and-forth for sure and give you a reasonable response time. The motion sensor slow enable is really not a problem as all I want to do is open the vents automatically when I am in the basement and close them when I leave, which is really not that time dependent. The bigger issue is that the vent control software is only working when the system is running, but with a short cycle time, it is very possible to find out the system ran way after it has already stopped. I was running at over 7 minutes sometimes from when the system started to when ST knew about it running.

Don’t have any good ideas yet on a physical sensor trigger. Maybe I can use the temperature sensor in the vent itself, that gets polled or pushed every minute. It picks up to a pretty high temp in less than 1 minute, so maybe that could poll the system to pull the request. Let me know how to trigger the request with rule machine as this might work.

How about this, I’ll just add the functionality directly into the app to let you select temperature sources to monitor for changes. Then I’ll trigger on those events.

Either way, I set up a test that when the temperature in the vent gets over 88 to trigger an event. Only issue is I hope it cools down enough between cycles to reset. In summer I will just need to read a less than temp.

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?