Plug-in for ecobee thermostats in development

Other Devices & Integrations Climate Control & Temperature Sensors
861

This is unfortunate but also completely understandable. What is interesting is that over the last month, the latest plugin has been completely stable for me. I have not seen any server issues from my side. Not saying that problems did not occur when I was not watching, but at least the plugin seemed to have gracefully handled it. Very much appreciate that you brought it this far.

Hopefully the other plugin stays supported and if needed I move to that, or I may be eventually forced to go the same direction as you have. The ecobee plugin is critical to several of my automation logic.

862

please disregard my post

the plugin is working fine
i had another plugin that was malfunctioning
causing a luup reload every 5 minutes
this was somehow causing ecobee plugin to drop connection

863

[quote=“charettepa, post:862, topic:174457”]please disregard my post

the plugin is working fine
i had another plugin that was malfunctioning
causing a luup reload every 5 minutes
this was somehow causing ecobee plugin to drop connection[/quote]

Thank you for the update. That’s good to know.

864

@charettepa’s experience is completely consistent with the longstanding Vera bug that does not save to disk device variables before exiting Luup, thereby repeatedly causing the refresh and access tokens to be lost. If only Vera provided reliable device variable storage, retrieving a new PIN would probably never, ever be required.

865

One more step to take in the direction of going all cloudless… Nest is having massive server outages now too which completely disables my nest protect smoke detectors. So ecobee is no longer the only one having problems… Lesson learned…

866

It was only a matter of time, I’m afraid.

One wonders what liability there would be if someone died during an outage.

C

867

The bigger problem is to find a good alternative… In the US, there are all kinds of waivers which come with the product so… yeah, not much liability. This was practically the last wifi/cloud device of importance I had left. I thought it had google behind it so server uptime would be less of a risk. So much for this idea.

868

Even with Google or AWS, the systems are so vast that network failure, hardware failure, load balancing/failover software failure, application software failure or simple human error can take a cloud service down for an indeterminate period. That’s not supposed to be the case, but…

869

Yeah, I’m not surprised by the waivers, but with your guy’s legal system :slight_smile:

We were seriouly impacted by the Azure outage last year. No one is immune.

C

870

It’s not just an issue of the legal system. Cloud vendors are dependant on the global internet for connectivity, even if they’re AWS or Google. The waivers are to separate out responsibility. I have a business internet account with a major US MSO, and I get certain guarantees for uptime and performance that cover the parts of the network that the ISP owns. That’s actually quite a lot, as this ISP operates top-tier backbones in addition to metro networks. But, if I can’t reach a particular site due to a disruption that’s not on their network, I’m out of luck. It’s quite correctly not their problem. The Amazon S3 problem from 2017 demonstrated just how many websites depended on S3 to function properly.

871

Sorry, this is drifting a little off topic but I am loving the conversation. Being European and living in the US for quite some time, I can see the big difference in the legal mentality. That being said… to come back closer to the original topic… Indeed, nobody is immune to cloud service outages and there is a very obvious drift of services and functionalities going into the cloud with little to no value added. The ecobee and nest, both deciding not to provide a local API access are extreme examples. The Vera with their ridiculous “secure mode” is another milder one. With computing power being as cheap as it has become, we have to balance the value of the feature added by the cloud functionality with its reliability. For home automation and control… the value added is near zero. Companies are better off selling slightly more powerful hardware to process everything locally rather than try to cheap out and rely on unreliable cloud services… That’s the ST vs. Homeseer model.

872

Totally agree, sir. But wary of drifting the thread even more :slight_smile:
C

873

I have two different homes with two different Ecobee thermostats, and both are linked to the same Ecobee account. I also have a VeraPlus controller installed in each home.

I’m trying to figure out how to handle the second home. If I go into the second Vera controller and install the Ecobee plugin, I’m prompted to “get PIN” again. But if I then go into my Ecobee account, even switching to my second home, the Vera app already shows as installed and I can’t install it again to add a second PIN code.

How is this best handled? Surely I don’t have to create two entirely separate Ecobee accounts and manage them completely separately, do I? (That will be frustrating for things like controlling both homes from my Ecobee app or using my Alexa to control both properties.)

874

I noticed the aforementioned “-400 / +400 Setpoint(s)” issue this morning, while monitoring that ecobee thermostat value using a Reactor expression.

Seems the Heat and Cool setpoints are slammed to these extremes after setting the Thermostat (either manually in the home, or using the ecobee.com website UI) to “Vacation” mode. For example, “Leaving now, and returning (in an hour, say).”

Once the Vacation ends, things return to normal, and the underlying

getstate( 103, "urn:micasaverde-com:serviceId:HouseModes1", "HMode" )

variable resumes its previous value (e.g. “62”), and the appropriate ‘Home’, ‘Away’ or ‘Night’ annunciator turns green again under the plug-in’s “Thermostat Mode” section of the Vera UI.

What’s interesting is that during the Vacation phase, (a) ecobee plug-in continues to show the “normal” setpoint value (of “62”), and (b) never highlights the ‘vacation’ annunciator on the Vera UI (instead, all of them get the gray background color). Likewise, the ecobee website never shows a different Setpoint value (it, too, remains “62”).

So this would leave the average Vera user unaware that those extreme temperature values were lurking behind the scenes. Yet the values DO affect such things as Reactor’s Conditions and Expressions, so could very easily cause unexpected results.

I don’t know if @watou is still on the Forum, but if so, I’m tagging him for comment.

  • Libra

EDIT: Having digested more of this lengthy thread, I realize now that @rafale77 had a hand in maintaining a version of this plug-in (should I have switched to it??) so may provide guidance, too.

875

Sorry, I have no idea what this problem is and it is pretty old to me now. I did port this plugin to openluup and continued its maintenance for a while but as I mentioned a few post above, I stopped because I decided to go local after a few cloud outages too many and launched me on a rampage to eliminate every cloud dependent device in my house. (ecobee, nest, skybell, ring were the first victims) I would recommend to install the version on my repo which is the latest. I made a few changes to improve reliability of the cloud connection.

876

Hi Libra,
I don’t have the ability to run the plugin any more, but I recall that those values 400 and -400 have special meaning in the Ecobee API as invalid setpoints. So if your automation sees them, they should not be treated as valid for any kind of scalar comparisons.
I had received a request from Vera regarding them taking over the plugin quite awhile ago and I wrote back a long email but never heard another thing. Maybe they should fold this into their platform and support it, too.
All the best,
watou

877

@watou, agree wholeheartedly that Vera should take over the ecobee integration.

@Sorin, is that still a possibility?

@rafale77, please share the URL to your repo, as I have come up empty whilst reviewing this thread (mea culpa).

UPDATE: The repo URL is GitHub - rafale77/vera-ecobee: Vera Plugin for ecobee Thermostat

THANKS, ALL!

878
1 Like
879

Uh-uh, after installing @rafale77’s ecobee 2.2 plug-in from Github, and doing all the requisite steps to get it operational on my Vera Plus, things were going GREAT. Pasted my API key, refreshed the PIN, all good. Even made sure all my existing Reactor scripts run OK.

However, when I clicked on “Vacation” under the “Thermostat Mode” device, I noticed some warning text in blue kept popping up, saying:

ecobee: Error: 11: Function error. invalid holdClimateRef parameter value, smart1. Referenced climate must be a existing and valid ..
Function: setHold

Another press of “Vacation” yielded the warning below:

vera_blue_text
vera_blue_text1106×37 4.31 KB

For the sake of heading back toward a clean slate, I decided to uninstall the old ecobee 1.9 app that was still installed, so I clicked UNINSTALL next to it. Then a “Error performing task” type message was displayed. AND THAT’S WHEN A BAD THING HAPPENED…

This white screen with a dreaded green spinner appeared, and I let it spin for at least 20 minutes, but it would not populate no matter how many Ctrl-F5 (in Chrome) refreshes I tried.

vera_spinning
vera_spinning1218×750 25.6 KB

Happily, power cycling my Vera unit got me back to UI7, where I see ecobee 1.9 remains installed.

Any way for me to get rid of the old version??

UPDATE

My second attempt at simply doing an UNINSTALL on version 1.9 succeeded. Of course, that also removed all thermostat-related devices and the “Thermostat App” from the UI.

My plan is to go remove all D_ecobee* and I_ecobee* files (many of them evidently duplicated) from the main storage directory – using WinSCP as before – then reupload them from the ecobee 2.2 repo, as instructed above. And then to recreate the devices from it (noting that the specific steps for doing so seem not to appear in the accompanying README.MD file).

WISH ME LUCK!

I will leave this post up temporarily pending any constructive input by others. (If not, will remove ASAP.)

880

@Ioana :sweat_smile:

1 Like