openweather plugin ?

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

[rafale77]

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.

[prophead]

This strategy has proved fruitful. 48 hours with no hangs.

[rafale77]

Interesting. So it could be that your main openLuup installation may have some plugin somehow bogging the luasocket or conflicting with the ecobee plugin?

[prophead]

Donno but my dehang script recorded the ecobee plugin as the last log line before hang every single time. Either getting updates or revisions found