Not impatient, just prefer to run things locally. Getting the notice from Heroku just got me off my butt to try again. Fully understand the "local server" that we are debating on setting up and with some success is just transient.
1 Like
To each their own I suppose!
The new server will be a complete rewrite along with how it interacts with the ES Hubitat app
16 Likes
Thanks for all you work @tonesto7 . Really appreciate all your contributions! We just love your apps so much (anxiety felt when there is even a hint that we may have to go without them, LOL).
1 Like
I noticed that the callback url provided by ES window is the cloud endpoint, would it work if we provide the local IP endpoint of the hub?
lol. I am waiting and in no rush 
…but still reading the thread to keep up to date.
1 Like
@tonesto7 I agree with you. Thus, my previous comments in this post. I did cut over to a dorker setup. However, I do see some functionality issues that I wasn't seeing before. I'm happy to test and I agree we have three months to sort this out. I'm probably going to flip back to the original server. And retest to make sure that all the functions work again. Thank you again for all your help and effort with this solution. I know many people appreciate your efforts all across this platform.
@moh my previous response regarding the authentication was response to the general thread not to a particular person. There are many people having authentication issues and I wanted to present that as a alternative possible concern/solution that they might be running into.
I'll wait! But I have been looking to set up an rPi with docker anyway. You just gave me a reason.
1 Like
I wonder what API or functionality is needed in Hubitat so that the echo-speaks-server could be written in groovy. Some sort of general purpose key-value store for saving the cookie/token, perhaps.
1 Like
Honestly, I'm hoping it never goes there. My hub is already pitching a fit about too many events, so I find it much better to offload as much responsibility as I can.
1 Like
I keep a Mac running to host Homebridge and will likely just use this to run the new local server. I’ll probably wait for Tonesto7’s server update, but I may get impatient because right now my Heroku server is crapping out every 10 days, forcing me to manually re-deploy it. Did you use the information here to configure yours?
It's not crunch time yet but I do need to sort out the best way to keep this running.
Based on how we do things at work we only have two sprints left and one of them is for dark deploy and defect identification and test while in dark deploy. I miss the days when it would be ready when it's ready. 
4 Likes
@tonesto7 - on another note, is there a reason you just "speak" notifications rather than using the Alexa Device Notification functionality (that persists with the yellow ring)?
The API which is available does not allow us to send device notifications like you are mentioning. Unless something has changed in the last year.
It's likely a different API, but maybe similar?
The functionality is mentioned here: Notifications API | Alexa Smart Properties
Yeah, that's the Alexa Skills API.
With all due respect, I don't think it is the Skills one. It's a REST API that looks to be for interfacing a hotel's "wake-up call" system (or other automated message) with Echo devices in the rooms.
Looking at line 2136 of this: https://github.com/tonesto7/echo-speaks/blob/master/drivers/echo-speaks-device.groovy
it appears you're already doing something to remove notifications... shrug
Right, I didn't expect the same API. I expected that a notifications endpoint for one API tool would work similarly to the notifications endpoint for another API tool from the same vendor.
I can't find where the documentation would be for the API you're using -- is it documented? I'm happy to peruse that to see if I can find what I'm looking for...
