It's not a chunks problem: the Alexa NodeJS service from Apollon77 takes around 40/50 secs to complete the entire procedure, so I have to wait for it before send the response back to Hubitat.
Seems that Hubitat has a timeout of 30 secs.
Could it be made into two calls?
-
The first call the pi to refresh the cookie -> store on disk somewhere.
-
Second call to simply retrieve the contents of the file?
1 Like
I'd prefer to avoid it because the service could be potentially hosted also on some cloud service if there isn't a Node server in the local network.
In that case for security reasons will be better to don't save anything locally but use the cloud just as "proxy"
1 Like
We do not provide a way to adjust the timeout. Perhaps a websocket endpoint or is it possible to implement the calls in groovy instead of nodejs?
1 Like
I've tried to port it to groovy but it's too complex (it involves a proxy for Amazon webpages too).
Do you have an example of websocket client implementation in groovy?
Ask, and you shall receive! Here is an example of Hubitat's new webSocket implementation that I used for local LAN communications with Harmony Hubs.
With Alexa cookie, Hubitat should be the websocket client that receive messages, in your example Hubitat seems to act as server sending websocket commands to Harmony.
Is there something else similar?
Sorry to bother you, but I cannot find any documentation about Hubitat websocket..
Websockets may not be the best method. What you can do is use web services. I've included a link below. Its actually pretty easy once you get your head around it.
You can send off the command to the alexa proxy and let its do its thing. When its done it will call back to the hub and pass along the cookie so you can work with it. That way you don't have to wait around for it to complete.
I think its very similar to the maker api, but this will allow you to build it right into your app and do what you want with the code that is passed back.
This is mainly how I pass back data from my nodejs servers back to my apps for processing.
https://docs.smartthings.com/en/latest/smartapp-web-services-developers-guide/tutorial-part1.html
Hmmmm... sine the Harmony Hub is actively listening on a specific port for a webSocket connection, wouldn’t that make it the server?
It really is not very different than a RESTful server that sits and listens on a port. The big difference is that the webSoCket connection is persisted between the two devices, thereby allowing a full duplex conversation. So, the Hubitat hub would initiate the connection and request a new cookie. The Alexa Cookie Server would then respond with something like “OK, Ikm working on it for you.” 30 to 40 seconds later, after the New cookie is obtained, the Alexa Cookie Server would send an unsolicited message to Hubitat with the new cookie over the active webSocket.
Question for @chuck.schwer - Does the webSocket interface work in an App? Or only in a Driver?
Driver only. If it has to be an app, I think @gavincampbell's suggestion of a callback is a better idea.. basically setting up a webhook.
1 Like
Thank you @gavincampbell for the webhook suggestion, but as already explained, the webservice could be potentially hosted on a cloud hosting if a Node server is not available in local network, in that case it will be impossible to connect to Hubitat from Node.
@chuck.schwer it's really impossible to have timeout as parameter? We are trying to go around it but simplest solution are generally the best ones too.. It could be useful for someone else too, if added to both httpPost and httpGet
In case it won't be possible, I'll save the cookie locally on the Node server, but this will prevent to use the service on a cloud server (or at least I won't use it, if someone wants to use it anyway, it's at his own risk)
Should still work. I believe the callback url would just be different in that case. You would use a cloud callback url that connects to the hub. Similar to how the maker app had cloud url's as well.
Yep, I haven't considered Cloud API.
Seems anyway more tricky than a simple POST, let's wait if devs can add a simple timeout option
How about this... Have the NodeJS server support two calls. The first would be a request to create/refresh the alexa cookie. This would then be stored within the NodeJS server (memory resident, local disk, etc...) but with some sort of time to live. If that amount of time expires, the NodeJS server would delete the cookie data. If a 2nd call comes in before the cookie TTL expires, the cookie would be returned and then the local cookie cache would be deleted.
Just trying to brainstorm ideas...
I'm not sure how long you are prepared to wait. You can put in a feature request, but we would have to prioritize it for implementation. At this point I think your best bet is to use one of the workarounds suggested in this thread.
I don't know what there is behind httpPost() function, but I think that it's just a "shortcut" for a groovy library to handle this and timeouts should be already available.
Seems that Hubitat has a timeout of 30 secs, while SmartThings from documentation it's 10 secs, so some changes has already been done from "pure" Groovy.
I know that everyone has his priorities, but this it's really a few minutes job, we (and you) have probably lost more time speaking about possible workarounds than expose a parameter for this.
I anyway understand your reasons so I'll try something different in the meanwhile.
Guys, finally we have it 
Let me know if you found any problem, suggestions are welcome!
AlexaCookieNodeJs service with instructions:
To download as zip (only hubitat/AlexaCookieNodeJs/AlexaCookieNodeJs folder it's needed, maybe I can use Github releases later) use this link https://github.com/gabriele-v/hubitat/archive/master.zip
Updated Alexa TTS App for Hubitat:
6 Likes
This looks awesome! I'll try testing it tonight. Thank you!
Testing now...seem to be in an infinite loop in the HE app. ;(
[EDIT] Found my issue(s). It would be good to modify the username/password objects not to be the same as what HE uses. My autofill seems to keep placing my info into those fields constantly.
Works good overall btw! Will wait 6 days to see if refreshed.
1 Like
Hi, object names are unique (they are called alexaRefreshUsername and Alexa Refresh Password), so I think is the browser that matches the hubitat URL and password type field and it autocompletes.
I don't know how to solve it on app side, I can set password as normal input type but then it will be visible.
