Vera-openLuup Ecobee Plugin
-
The older units do not have homeKit
-
I had been exchanging messages with @prophead for over a month because of openLuup hanging. Several times I had asked for this to be discussed in open forum, but it did not happen. This is such a shame because
- It doesn’t leverage the collective power of the forum
- It makes it seem like there is less forum traffic
- It takes longer to surface any root cause
I’m now switching to a policy of not discussing technical issues on an individual basis, unless, of course, there’s a good reason for it.
-
Thanks @akbooer, I agree with you. Thus, me posting here.
@prophead, you are correct that the first gen ecobees did not have HomeKit support. This was not a solution for you as I will still be making the change to an async in the next couple of days (sorry, I've been busy compiling some other things) but it was a more general idea for ecobee. I was one of the very early adopters and a strong advocate for them but eventually their cloud only API just killed it for them and I switched to a much cheaper and reliable solution with zwave but I thought the bypass through HomeKit interesting. -
I just tried it, this is what I saw in the logs:
2020-06-02 20:22:55.374 luup_log:13: ecobee: debug: Fetching revisions...
2020-06-02 20:22:55.375 openLuup.context_switch:: ERROR: [dev #13] ./openLuup/http_async.lua:174: bad argument #1 to 'gsub' (string expected, got nil) -
This is the line:
local host = string.gsub(reqt.authority, "^.-@", "")
so it looks like a miising
authority
field in the request headers? -
Do the PnP variables work on AltUI?
-
In what way, exactly?
-
Likely it is missing from the original plugin call. I will look at it and update. Sorry about this. I didn't know the async module required it and thank you @akbooer for pointing it out. I am a bit swamped with work but will get to it.
-
Thanks guys
-
@prophead, I posted an updated version on GitHub. Please let me know if it works.
@akbooer, I was wondering if this header could be made optional. I looked at the API docs and it doesn't appear to me that they actually require this field in the header. They use a token for authorization using another field. -
I tried it, same result:
2020-06-05 20:31:47.669 luup_log:13: ecobee: debug: Fetching revisions...
2020-06-05 20:31:47.670 openLuup.context_switch:: ERROR: [dev #13] ./openLuup/http_async.lua:174: bad argument #1 to 'gsub' (string expected, got nil)
2020-06-05 20:31:47.670 luup.delay_callback:: function: 0x185ca10 ERROR: ./openLuup/http_async.lua:174: bad argument #1 to 'gsub' (string expected, got nil) -
Ok try this again.
-
well a little different this time, but can't get PIN code:
2020-06-06 12:11:22.004 luup_log:13: ecobee: debug: Attempting to getPin...
2020-06-06 12:11:22.004 luup_log:13: ecobee: task: Trying to getPin
2020-06-06 12:11:22.004 luup.task:: status=2 ecobee : Trying to getPin
2020-06-06 12:11:22.004 luup.variable_set:: 13.urn:ecobee-com:serviceId:Ecobee1.TSK was: Error: nil: no valid JSON value (reached the end) now: Trying to getPin #hooks:0
2020-06-06 12:11:22.042 luup_log:13: ecobee: Error: nil: no valid JSON value (reached the end)
2020-06-06 12:11:22.042 luup_log:13: ecobee: task: Error: nil: no valid JSON value (reached the end)
2020-06-06 12:11:22.042 luup.task:: status=2 ecobee : Error: nil: no valid JSON value (reached the end)
2020-06-06 12:11:22.042 luup.variable_set:: 13.urn:ecobee-com:serviceId:Ecobee1.TSK was: Trying to getPin now: Error: nil: no valid JSON value (reached the end) #hooks:0 -
Hmm this is a different problem indeed. I may need to move the authorization call to not be asynchronous. Sorry it is more complicated than I initially thought.
-
Well the authorization is done attended so thats no big deal. I’m more concerned about it hanging when it’s unattended.
-
I am somewhat biased towards trying to find a way to prevent openLuup from hanging on a socket wait rather than working plugins one by one to circumvent this. I just had an event today which I think was due to some network problems causing my pioneer plugin to wait for a response from the receiver. This plugin uses the io module and lua socket directly and is not an http request so the problem is definitely deep in the lua socket...
-
Got sick of ecobee plugin hanging my openluup box so I built a new pi just for the ecobee plugin and a scene which pushes values onto my main openluup box.
-
I'd be curious to see if the new box hangs too... Even when the cloud service had problems, I don't remember having these issues but I indeed had other cases of openLuup hanging only up to recently.
-
This strategy has proved fruitful. 48 hours with no hangs.