Let me dig in the API to see if that information is passed in the API calls. If it is, it wouldn’t be that hard for me to extract it and pass it upstream. Testing, however, might be a problem as I am not using a two stage cooling on my thermostat.
But this is a very creative way to reuse what you’ve got!
The good news is that there is data that tells which stage was running (energized) in the 5 minute interval. The bad news is that I’ll have to request an extra object set to get at that data, thus dumping a whole lot more data through the API calls.
The last three 5 minute HVAC Mode reading. These values indicate which stage was energized in the 5 minute interval. Values: heatStage10n, heatStage20n, heatStage30n, heatOff, compressorCoolStage10n, compressorCoolStage20n, compressorCoolOff, compressorHeatStage10n, compressorHeatStage20n, compressorHeatOff, economyCycle.
Let me look at it with fresh eyes, not sure if I’ll be able to do it over this weekend though. I’m really trying to focus on getting my current development branch ready for some Beta testing. I’m very hopeful that this version will clear up the majority of the connectivity (disconnectivity) issues we’ve all had (some worse than others).
My test stub has been running without any failures since the 16th (of Feb). And my full implementation has been running since yesterday (harder to get a true count there since I often cause failures just from the development work).
Could you perhaps put in a feature request in the Issues page on Github for me? Then I’ll remember to come back to this?
Thanks for looking at it Sean! I really do appreciate it. Your device has been super stable for me as a whole so absolutely put this way back on the low priority list please. I have my fan working with Rule Machine so I was just pondering out loud about using my ecobee3 algorithm. I don’t want you messing up the code you have so I’ll enter it on the feature request of GitHub but it seems to me that this request needs to go way WAY down as noncritical.
I think instead efforts toward a standalone smartapp controlling a 3-speed ceiling fan as much more useful to the community as a whole whereas my request is only for those with ecobee.
You never know what someone might come up with for uses of the data! Besides, once I suck in the new data element I can expose any of the data points in there. They are all read-only anyway so I wouldn’t have to do a whole lot of “setX” types functions.
But that whole ceiling fan discussion has got me interested in looking at a controller. I don’t think it will work for my living room fan as it has an integrated light kit (instead of separate switch) but it would work in my bedroom. (which is where my Ecobee is)
FYI: My ceiling fan has an integrated light kit. I posted pictures in this other thread. In that first picture you can see my ecobee3 on the wall.
Continuing the discussion from Control 3-speed Ceiling Fan and Light Kit
If we ever get this working I have another ceiling fan in my bedroom where my second sensor is and I would love to see if ecobee3’s “Follow Me” function that works great with the heating would also do as well with the ceiling fans in two locations.
I’m having two problems. I’m using the StrykerSKS-Ecobee3 branch and Android devices.
For about the last week, whenever I go into the SmartApp on my phone (LG G4) and select Done, I get a “You appear to be having issues with your network. Please check…”. This is on WiFi. If I do the same on other Android devices (Fire 7 tablet or a Samsung SIII with WiFi access only), it works just fine.
Secondly, for the first half of this week I had no dropped authentication tokens. However, in the last 3 days it’s been getting lost about twice a day. I’m using a number of watchdogs (temp, humidity, switches, SmartWeather lux). Is this happening to other people? If not, what’s the best way I can debug this?
Try backing off on the number of watchdogs. Also be sure not to choose any that will change too often. Turns out that there is too much of a good thing sometimes. I had about a dozen added on mine right after I added the feature and was getting disconnected about every 2 hours. Now the only one I’m using is SmartWeather temperature.
If my current authentication fixes work I may even remove this feature (or revamp it a bit).
No idea what would cause that, I don’t have anything in my code that prints a message like that so it must be coming directly from the SmartApp application.
It is coming straight from the Android App. It happens whenever it drops a connection (including when the SmartThings servers are overloaded). It’s just that it happens so regularly on my G4, and occasionally on the Fire. Nothing odd comes out in the logs when it happens, and in fact any changes I’ve made seem to all have been saved successfully. If no one else is seeing it, it must be something on my setup.
##[RELEASE] v0.9.13 now available for testing and general use
I have spent the majority of the last month focusing on finding a way to make the API Authentication more stable. After initial moderate success using watchdog timers, etc I realized that a completely different approach was needed. Digging around the Ecobee APIs and developer community I believe I have the right approach for the task.
My test stub that I developed to solely test the authentication model has been running without fail since February 16 (Timestamp: 2016-02-16 23:49:16 CST) with continuous polling and re-authentication taking place over that entire period (including simulated testing of failed scheduled events).
I have taken the learning from this test and incorporated them into the main SmartApp. It has been running smoothly for me now for over a week on my development branch (so much so that the wife even commented that the notifications had stopped!)
You can find these updates in the main Ecobee3 branch. If you are using GitHub integration simply update (don’t forget to update both the SmartApps and the Device Handlers). If this testing goes well I plan to release this more broadly as a 1.0 release hopefully by next weekend.
I just released a big updated. Included in that update is the ecobee Routines Child SmartApp that can now do both Modes and Routines. So if you only want to make the switch when one of these is triggered you can now do it natively from with the Ecobee SmartApp (in the Child SmartApp menu).