lol, you put too much faith in me... I could look at it but the problem is I am a Google Assistant guy and don't own any Alexa device...
2 Likes
The expertise needed isn't really an Alexa/Google one but just figuring out a way to get the cookie into HE. Unfortunately you will need an Alexa account to get the cookie so I guess we will have to keep waiting. No faith lost though @gparra.
1 Like
I'm curious as to whether an Alexa skill can push TTS, avoiding all this cookie stuff.
The reason these workarounds exist is because at the moment, you really can't (assuming you mean "TTS on demand"--any Alexa skill can do TTS when you ask for it, since speech is the primary interface on most Alexa devices). You can work around it by making something happen than an Alexa "routine" can use (e.g., speak something when a contact sensor is opened), but aside from even that type of sensor not working with Hubitat's integration at the moment, it's a bit more limiting (and may require a proliferation of virtual devices to do what you want). Only Amazon's own features have the ability to produce TTS on demand at the moment.
I also hope for a day when that changes and we won't need either type of workaround or unofficial support anymore. 
@ogiewon what do you think about port this to Groovy? Seems that v2 with OAuth Proxy works exactly as Amazon Mobile App, so cookie could be renewed forever..
I'm a novice with Groovy (more skilled with C and C#), but someone here maybe could do it?
1 Like
First off mad props to @ogiewon for making this work in the first place. While likely not the hardest thing in the world for the experienced, I find the attention to detail to make this sort of thing work really hurts my head.
That being said with all the framework in place, I have just had a successful POC call from @ogiewon's driver and triggered a Alexa Routine. The call is indeed very similar to the TTS.
Automating it is another story. Some data has to be parsed out similar to how the deviceid's and such are parsed. I will slowly plug away at it, JSON is however not a first, second or third language for me. Nor is groovy or any other programming language so it is slow going for sure.
There are a ridiculous amount of features that can be added. If anyone wants to help let me know. I will post the code up. Currently it is not usable unless you have access to a lot of the said JSON info already.
I have been playing with this on my pi. The refresh on the cookie works great for me. I am actually torn between using the node server setup he has and making a driver for it as it is capable of being a setup and leave kind of thing or working on this driver that so nicely works with just the hubitat hub.
I've made some tests too and it's working very well. I'm already building (POC is completed, I just need few minor tweaks) a small NodeJS service that can be used in Hubitat app to automatically refresh the cookie.
Obviously if it could be integrated everything in Hubitat will be better but my Groovy knowledge it's too limited.
1 Like
This is awesome news, I was thinking about this route as well. It makes feel better about spending several hours crossing my eyes, staring at various bits of codes trying to figure out how it all works.
@gabriele and @cwwilson08 - You guys are awesome! Keep up the development and I am sure it will pay off. Adding features like the ability to trigger Alexa Routines would be very useful! And if we can get the automatic cookie renewal feature working on a RPi (or similar), with a typical RESTful API, we can easily add an optional feature to the Parent App to allow users to enable this feature based on either the code detecting an expired cookie or upon a scheduled trigger like every 12 days. This would be a big win for users! Thank you both for finding ways to improve the Alexa TTS App!
@ogiewon: do you know if there is a way to increase timeout on groovy httpPost call?
That's the last thing that prevent cookie renew to working fine..
Thanks
1 Like
This would be a question for @chuck.schwer.
Another option might be to break the cookie up into smaller pieces that the Alexa TTS App could request in smaller bite-size chunks.
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?
