openweather plugin ?

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

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