[quote=“rafale77, post:775, topic:174457”]This is odd. Let me look into it though it may not be immediate since I need to sleep and work tomorrow. The logs seem to indicate something very simple. Seems like a variable not properly declared in the code somewhere. I have not seen this on openLuup so it maybe some specific vera syntax.
Edit: I found where I messed up. I updated the repo. You can just download the I_Ecobee1.xml which contains the fix. I also edited v2.1 hoping not too many people downloaded it. The thermostat should work now. Thank you for testing and reporting it.[/quote]
@rafale77, thank you. I just updated and it looks like everything seems to be working now. I will keep your version since I have my own dev key. I really appreciate @watou and your efforts to immediately jump on this and fix it. The Ecobee has become critical part of several of my automations and when they went offline, it broke a lot.
[quote=“denwood, post:779, topic:174457”]Watou, 1.9 works perfectly…many thanks for doing this so quickly!! Will the plugin change potentially affect the daily PIN requests I was having to make? It was only in the last two weeks or so it started to do this…
Rafale, thanks to you as well. Your files just copied into the UI7 setup did get me the home/away functionality that most of my automations use, however GUI changes to temp in Vera did not “reach” the actual ecobee stats. I’ll keep the files tucked away in case we need them :-)[/quote]
Ha… actually I fixed the problem you are describing as well as reported by @niharmehta. Just have to replace one file but there is no fundamental reason to use my version on a vera at this point since Watou updated the mios appstore version.
I don’t see a way to update to 1.9 on “My Apps” on both UI5 & UI7.
However, I do see it lists v 1.9 under “Install Apps” in UI7 (Ecobee is not in the plugin list for UI5 for some reason).
Is there a way to update to the new version without deleting/installing?
I am still getting some communication errors causing the plugin to think that it is disconnected. As soon as you send a second command it shows as reconnected.
@fullmoonguru, instead of a Luup reload, try sending another house mode change. I think it shows reconnected right away. I may look into this error handling so it reports an error instead of an API disconnection when I have time.
FYI, The error I am getting from the API is “Error: create function not permitted: value expected at line 1, column 1”. It is intermittent and is so far always eliminated after a second call. My patch so far as been to write my scene to repeat the call within 5s of the first one. I will look to build it into to the plug-in.
I have one disconnected now. Changing mode didn’t work, but then neither did reloading the engine. So I guess this is the case where it dropped teh token so I’ll have to get a new pit & register with Ecobee. Just wanted to to see if there was something else you wanted me to try.
Not much I can do after the token is dropped. The question is why it would drop the token. I have not observed this in ages but I run the plugin on openluup, not on vera. If I was to take a guess, I would say
internet connection,
Unwanted Luup reload which flushed the memory before the updated token could be saved (that’s most of my event case when I was running it on the vera)
A combination of both (vera rebooting because it lost internet connection somehow)
I am testing a code which retries the API call in case of failure to see if it fixes the problem I observed.
Yeah it might be because of dropping the internet. I have four systems with Ecobees on them & a combination of having to get teh pin again or just reloading the engine to get them back up. The controller on this one sent me an alert earlier that it was down, then back up. Assuming it wasn’t just the Vera bug that’s constantly telling me that when it’s not actually true (ugh), that makes sense.
I asked earlier about how to get notification when the Ecobee drops but I don’t know enough about using lua code to do that. Could you spell that out a little more for me please? I basically need the full code to paste.
[quote=“fullmoonguru, post:791, topic:174457”]Yeah it might be because of dropping the internet. I have four systems with Ecobees on them & a combination of having to get teh pin again or just reloading the engine to get them back up. The controller on this one sent me an alert earlier that it was down, then back up. Assuming it wasn’t just the Vera bug that’s constantly telling me that when it’s not actually true (ugh), that makes sense.
I asked earlier about how to get notification when the Ecobee drops but I don’t know enough about using lua code to do that. Could you spell that out a little more for me please? I basically need the full code to paste.[/quote]
I am doing this on openLuup/Altui. There are multiple ways to do it so let’s take this in steps:
Get a notification service. Do you want to use the native vera one or vera alerts or any other service? You probably want to look it up. I personally use pushover and go through a local notification API I set up on home assistant. Basically vera/cameras/openluup all send their notifications to home assistant which then sends them to my devices through the Pushover service. I used to use the mcv one which requires knowing your user id (I found in my logs) to send customized notification messages through their API. The lack of reliability made me give up on this.
Once you have that notification service, I suppose you would have an url for it or a REST API call to generate the notification which is a constructed http url. Generally a “post” call. If you use VeraAlert, that plugin will do it for you so you may want to look at it.
On the vera create a manually triggered scene which would send this call. I am pretty sure it would make use of a Vera Alert function. For me it is a Lua code to send a message.
create a “luup.variable_watch” with the corresponding function like below in your startup Lua:
luup.variable_watch("ecobeeupdate", "urn:ecobee-com:serviceId:Ecobee1", "Status", k)
function ecobeeupdate (lul_device, lul_service, lul_variable, lul_value_old, lul_value_new)
if tonumber(lul_value_new) == 1 then
luup.call_action("urn:micasaverde-com:serviceId:HomeAutomationGateway1","RunScene",{ SceneNum="**12345**" }, 0) --** scene number of the scene you created to send notification of connection
end
if tonumber(lul_value_new) == 0 then
luup.call_action("urn:micasaverde-com:serviceId:HomeAutomationGateway1","RunScene",{ SceneNum="**123**" }, 0) --** scene number of the scene you created to send notification of disconnection
end
end
If you know the action to send the notification directly without a scene, you can even avoid creating a scene altogether and just post that call instead of the run scene I have suggested. As I said, there are many ways to do this.
So far I have had no event of ghost disconnection with the one retry solution but the error from the API has been too intermittent for me to conclude yet. I will continue to test for a few more days and if successful will release the fix.
The only fix I can think of for those who have the actual key loss is to eliminate luup reloads and vera reboots or better yet, move to openLuup. The loss mechanism I observed is the vera reloading while the API key renewal is occurring and not saving it properly in the user data file. It would then reload with the old expired key and disconnect from the ecobee API server.
I have been having a lot of issues with having to get the PIN once a week. Today I removed 1.8 and installed 1.9. I am in UI5 and the GET PIN button does not work. Will this app still work with UI5? Or is ecobee down right now for getting a PIN?
Sorry I have no way to test ui5 as I have never had any ui5 Vera. When I modded beyond v1.6, it was to make it compatible with UI7. I however made no modifications to Watou?s ui5 files. I suspect that you have a non fixed
If 1.8 was working except for PIN problems, 1.9 is exactly the same except it uses tlsv1_2 instead of tlsv1. It’s at least conceivable that UI5 does not support tlsv1_2, but you might want to find some clear evidence to corroborate that theory. In any case, if you can install 1.8 and it basically works, and 1.9 doesn’t, the TLS change is the only code change between the two versions.
If 1.8 was working except for PIN problems, 1.9 is exactly the same except it uses tlsv1_2 instead of tlsv1. It’s at least conceivable that UI5 does not support tlsv1_2, but you might want to find some clear evidence to corroborate that theory. In any case, if you can install 1.8 and it basically works, and 1.9 doesn’t, the TLS change is the only code change between the two versions.[/quote]
I tried to get pin beforeI I removed 1.8 and it was not working. I thought the update might fix it but it didn’t.
If Ecobee no longer supports TLS 1.0 (can be checked again at SSL Server Test: api.ecobee.com (Powered by Qualys SSL Labs) but last I checked they only supported TLS 1.2), and UI5 does not support TLS 1.2 (needs some research to be sure but your 1.9 experience presents that as a possibility), then it might be that UI5 can no longer be used. If I were you I would try to again remove and install 1.9 just to get a sense that the plugin installation worked, and have a look at your log file.
I just checked the link you provided. Says only 1.2. I guess I need to abandon my temp controlled automation for the garage. Thanks for your feedback.
If Ecobee no longer supports TLS 1.0 (can be checked again at SSL Server Test: api.ecobee.com (Powered by Qualys SSL Labs) but last I checked they only supported TLS 1.2), and UI5 does not support TLS 1.2 (needs some research to be sure but your 1.9 experience presents that as a possibility), then it might be that UI5 can no longer be used. If I were you I would try to again remove and install 1.9 just to get a sense that the plugin installation worked, and have a look at your log file.