Freddy99: I have seen this happen intermittently in the past on the vera. I remember fixing it by running a luup reload to get the plkugin restarted. It is caused I believe by some corruption or timing issues from the very quirky vera. I have never observed it since I moved to openLuup with the exact same code.
I believe that @rafale77 is correct that the fix is to overcome a race condition where the plugin makes the request before the Vera is ready to respond properly (as it does by the time you tried it manually). The fix I was trying to think of was one of the two @rafale77 mentioned: reloading the plugin (probably described in some old message).
Thanks again guys,
Is the Luup reload done using http://ip_address:3480/data_request?id=reload ?? or luup.reload ()
or how would I use OpenLuup to load the code ?
It can be done either way. It is also hidden in the UI in the zwave/advanced menu and in the apps/advanced menu.
Openluup is something different: It is an entirely separate controller which many of us use to offload CPU and memory off of the overloaded vera. I recommend you go read the openLuup section in this forum if you are interested.
Freddy99, if you are wanting to reload Vera to bring teh Ecobee back online, you can create a scene which does that. That’s what I have done and it brings Ecobee back up most of teh time. If it doesn’t I have another scene that sends me an alert so I can go in & get another pin.
Just create a scene but instead of choosing a device to control, have it run this Luup code:
luup.call_action(“urn:micasaverde-com:serviceId:HomeAutomationGateway1”, “Reload”, {}, 0)
So I’ve been reading through the thread and doing searches and I’m sure this has been answered before, but I can’t find it. We have older ecobee SmartSi thermostats. Are these just not useable with the app due to the security profile? If not, is there any workaround (through altui or some other workaround?)
ETA, it looks like this is what we have, so maybe not old after all? It’s a new to us home, so trying to get up to speed on what they’ve installed.
https://www.smarthome.com/ecobee-eb-smartsi-01-smart-si-zigbee-compatible-wi-fi-thermostat.html
I’m unable to retrieve a pin.
[quote=“tb001, post:846, topic:174457”]So I’ve been reading through the thread and doing searches and I’m sure this has been answered before, but I can’t find it. We have older ecobee SmartSi thermostats. Are these just not useable with the app due to the security profile? If not, is there any workaround (through altui or some other workaround?)
ETA, it looks like this is what we have, so maybe not old after all? It’s a new to us home, so trying to get up to speed on what they’ve installed.
https://www.smarthome.com/ecobee-eb-smartsi-01-smart-si-zigbee-compatible-wi-fi-thermostat.html
I’m unable to retrieve a pin.[/quote]
There ought not be anything about the plugin that allows or disallows this particular model, since the plugin does not talk to the thermostat directly, but instead only to the API servers. I used this model for years with the Vera plugin and I’ve not seen any information from Ecobee that it’s no longer supported by them and their API. A possible problem would exist if you were using a Vera that does not support TLSv1.2, since older ways of supporting https: are no longer supported (like SSL3 and TLSv1.0 and 1.1). So it’s possible that security concerns have eclipsed your particular Vera, and I think a list of supported Veras was recently posted.
Others might have more current info though.
watou
[quote=“watou, post:847, topic:174457”][quote=“tb001, post:846, topic:174457”]So I’ve been reading through the thread and doing searches and I’m sure this has been answered before, but I can’t find it. We have older ecobee SmartSi thermostats. Are these just not useable with the app due to the security profile? If not, is there any workaround (through altui or some other workaround?)
ETA, it looks like this is what we have, so maybe not old after all? It’s a new to us home, so trying to get up to speed on what they’ve installed.
https://www.smarthome.com/ecobee-eb-smartsi-01-smart-si-zigbee-compatible-wi-fi-thermostat.html
I’m unable to retrieve a pin.[/quote]
There ought not be anything about the plugin that allows or disallows this particular model, since the plugin does not talk to the thermostat directly, but instead only to the API servers. I used this model for years with the Vera plugin and I’ve not seen any information from Ecobee that it’s no longer supported by them and their API. A possible problem would exist if you were using a Vera that does not support TLSv1.2, since older ways of supporting https: are no longer supported (like SSL3 and TLSv1.0 and 1.1). So it’s possible that security concerns have eclipsed your particular Vera, and I think a list of supported Veras was recently posted.
Others might have more current info though.
watou[/quote]
Ahhhh, thank you. I just realized I’m using a vera3 and not veraplus. That would be the culprit, as so clearly laid out in the previous page. I had it totally stuck in my head that I was on the plus, so didn’t think to double check that. Glad I’ve only added a few devices. Much easier and cheaper to get a new vera vs buying a ton of new ecobees!
Yup, I went as far as trying to see if it is possible to upgrade the kernel on Veras but I found out that the linux kernel is not even included in the firmware upgrades and the memory layout is very customized so I wouldn’t even be able to create a custom firmware to upgrade the vera… sorry
I?m just glad you figured it out! I?m just setting up the new house, so relatively painless to upgrade now. Only have a few devices on the network so far.
The Ecobee server has been down for the past few minutes. Can’t even access accounts. It is not the plugin…
This is making me want to get rid of all my cloud API devices and take everything local. My Plantlink system likewise has gone down because they apparently got sold and the new owner is no longer maintaining the server. A good reminder that cloud and Home automation don’t mix well.
100% agree. Noticed that the Ecobee servers went down and cleared my auth token to vera. I am tempted to move back to Zwave Tstats. Although not as nice looking, they seemed far more reliable than depending on the whims of the vendor maintaining their cloud service.
It seems like I have finally found a fix to the API errors. The API seems to send a ?cannot create function? error with a code which is not documented by ecobee after some period of idle (i.e without any action commands). Once a command has failed, the API seems to work correctly for some time until the next long period of idle (It seems a couple of hours at least)
My initial retries were done within too short of an interval and I now gave it 2 seconds. I will test it another week before releasing it.
The condition also seems to come and go for no particular reason so I want to be 100% sure…
ecobee servers today seem to be going through some serious outages and reboots. Their website isn’t working again either. Just FYI for those jumping to ask why the plugin is disconnecting.
Updated the plugin to 2.12.
Only change is the addition of a retry loop to improve on the server reliability issues.
Thanks as always for your work here Rafael. Should the app be updateable or does it need approval still?
What did you discover with respect to the API and retry errors over your week of testing?
I released my version of the app on the alt Appstore. Watou still owns the one on Mios and it is a slightly different flavor. I don’t know whether he will implement my fix.
Mine was sourced from his and ported to openLuup and UI7, And subsequently improved. So far he has been pretty good at following up and updating his version with my changes in spite of not using the plugin anymore since it shares most of the same code.
What I found was that after some idle period without command sent to the ecobee API server, the ecobee server would send back a strange undocumented error code which the plugin would not know how to handle. The plugin would appear disconnected as it got error but would reconnect itself at the next poll without any intervention. If the same command is sent within a ~1s, the same error is sent back from the server.
My retry loop gives an interval of 2s before the next retry and appears to have resolved the issue. The server, it seems, once it spit the error once seems to reactivate and will not error for some time… until it does again. It seems very random and the only occasional correlation I found was the lack of commands sent to the server.
ah…my bad. I was a bit confused there for a minute 
Ecobee seems to be going through some serious server issues over the past couple of weeks. They may be victims of their own success and can’t keep up… This is only encouraging me to clone their logic with the remote sensors and bring the whole thing into local processing…
So I ended up doing it. I have replaced the ecobee3 and its 6 remote sensors with a remotec ZTS-500. It does not have a fancy lcd screen but has a similar style in black. I wrote a customized plugin to fully integrate with my house in terms of room windows, occupancy, temperature sensors, vents and energy savings through air cycling, technically outsmarting what the ecobee was doing. I already had a number of Zooz/Vision/Monoprice ZP3111-5 in the house so all this did was remove redundancy.
Conceptually, I wanted to be less cloud dependent and the lack of local API from ecobee combined with the recent server outages just pushed me over the edge.
The result is that I will have a hard time supporting this plugin from hereon since I am no longer using it…