Vera-openLuup Ecobee Plugin

[rafale77]

Latest Vera Ecobee Plugin:

GitHub - rafale77/vera-ecobee: Vera Plugin for ecobee Thermostat

Vera Plugin for ecobee Thermostat. Contribute to rafale77/vera-ecobee development by creating an account on GitHub.

[rafale77]

According to @prophead, there seem to be some issues with the ecobee plugging locking up openLuup likely because the ecobee cloud server is not responding. I will be looking at making the plugin poll asynchronously but it made me think of something I read on the home-assistant forum: Someone actually managed to control the thermostat locally by going through HomeKit. Home-Assistant has a component to bridge into homekit and control homekit devices.

Apple's Homekit unlike Amazon and Google is processing automation and control locally through apple TV or maybe some other apple devices and is therefore does not rely on cloud to cloud communication, bypassing the ecobee cloud. It might be of interest to create a bridge for openLuup.

[prophead]

The older units do not have homeKit

[akbooer]

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

1. It doesn’t leverage the collective power of the forum
2. It makes it seem like there is less forum traffic
3. 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.

[rafale77]

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.

[rafale77]

@prophead

Please try the github openLuup_test branch. There should be only the L_Ecobee1.lua file to replace. I have no way to test this but I think it should work.

[prophead]

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)

[akbooer]

This is the line:

        local host = string.gsub(reqt.authority, "^.-@", "")

so it looks like a miising authority field in the request headers?

[prophead]

Do the PnP variables work on AltUI?

[akbooer]

In what way, exactly?

[rafale77]

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.

[prophead]

Thanks guys

[rafale77]

@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.

[prophead]

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)

[rafale77]

Ok try this again.

[prophead]

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

[rafale77]

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.

[prophead]

Well the authorization is done attended so thats no big deal. I’m more concerned about it hanging when it’s unattended.

[rafale77]

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...

[prophead]

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.