This one seems to be related to cookies stored on your browser. Clear cookies associated with your hub, heroku, amazon etc. or all cookies. After that I got by this error.
Jay W
Thank you!!!!
I just deployed the container on my nas, updated the app in hubitat, reset and relogged in and it's working!
The only issue I had was getting it to keep the amazon cookie. I had to log in a few times, restart the container and login again. I'm not sure which worked, but one of them did. 
I have the exact same errors in my logs.
I'm using a Synology NAS and the container network is is HOST mode.
I can manually hit the container page (and configure Amazon login in) with the IP and port of the Synology... But the Echo Speaks APP in Hubitat shows a totally invalid address and I believe this is why the error messages exist.
I'm a docker Newbie and I have no idea how to assign a static IP to a docker container in Bridge mode.
Maybe the issue is in the Hubitat EchoSpeaks App and not the container.
Looking at this Logically, if the Hubitat app would retain the correct local IP address (cause it works in Chrome no problem)... it should be able to reach it and the errors should go away.
I am paying Heroku, that's the most "by the book" setup, and still, the log is full of errors.
Thanks for taking the time to provide guidance. This is all new to me, and probably to many others out there. I'm still not clear with the install options that I've been following on these threads.
From what I've been reading, the main 2 software install options are thru Docker or thru Node.js.
In my case for the hardware options, I have three options: two always on PCs and a Synology: 64bit Windows 10-Home (ryzen 5/2600); 64bit Windows 10-Home (intel I5/2600); Synology DS220+.
For you more experienced users out there- For overall efficiency, stability and ease of install, what software and hardware options above do you think would work best.
For synology users, pay attention to this post by @greglsh , instead of choosing the default bridge network, choose the second one as he describes in his steps and you will get your IP address shown on the hubitat app as opposed to 0.0.0.0:8091.
There lies the issue for me... I'm not getting those results. Its pulling the wrong IP.
On Synology NAS, for networking you have the option of Bridge or Host. Host is what he is talking about in his post.
I have several active Network adapters on my NAS. A Production LAN which uses 2 Bonded NICS in Aggregated mode (10.200.0.x) and a LAN that does not route (10.0.0.x). I use this to direct connect 2 NAS's together for replication traffic. This keeps the replicated data off my prod network and switches.
Somewhere in the setup, The app in Hubitat is calling the container using the wrong network. Its trying to access the 10.0.0.10 IP rather than the 10.200.0.10 IP. I have another container configured in Host mode that is using the 10.200.x.x network in bridge mode with no issue (piHole). I have no idea how to fix this. But I can access the container just fine using 10.200.0.10:8091
I'm having problems getting the @tonesto7 container to work under Windows. My environment is Windows 11 Pro running on a mini-PC that I have running 24/7. Docker Desktop is installed and configured with WSL 2 and Ubuntu. I am a Docker newbie, but have a lot of experience configuring and using VMs.
Here is where I am:
-
The echo-speaker-server container is installed and running. I can hit the web page as you can see:
-
I can configure the local server in the Hubitat app, It got the Amazon cookie, but now I am seeing these exceptions in the log every 15 minutes, when the app tries to ping the local server:
-
As some other users have seen, my app configuration has the local server configured at http://0.0.0.0:8091. That doesn't seem right to me;
-
The docker run command I used to set up the container is:
docker run -dp 8091:8091 --ip=192.168.1.17 --restart=unless-stopped tonesto7/echo-speaks-server:latest
That maps the ports and specifies the host IP. Networking is set to bridge (the default from the docs).
I don't think this is going to be able to update the cookie when that time comes, as the error shows that it can't find the local server. I'm stuck at this point and I'm no Docker expert so I don't know if there is some configuration issue. Any ideas, anyone?
Update: I got it working by using the workaround suggested by @jl0 (below). I pulled down the server sources and I added a line to the DockerFile below the other ENV statements in the file:
ENV ipAddress=192.168.1.17
(substitute the IP address of your container above)
I built the image from the sources and ran a new container and it works! No nasty exceptions in the log and the correct server IP shows up in the app. Note that you can't use the prebuild container because of this workaround, but it is easy enough to build an image and run it.
I was also seeing the 0.0.0.0 issue with Synology - the Echo Speaks server is displaying the correct IP address when you visit it, but when it does the call back through the Hubitat URL to configure the Echo Speaks app it is passing 0.0.0.0 as the IP address for the app to use (though the port is correct). I took a quick look at the Echo Speaks server source and found a quick workaround...in the Docker environment settings (same place useHeroku=false) add ipAddress=10.0.0.1 (using the correct value for your setup). Then go through the config process again and it should work. I think this might help you as well.
2 Likes
I've got two nics as well and it is selecting the second one. I do not know what is causing that, but both of mine are at least on the same subnet.
Problem solved. Thanks!
That worked!
The Habitat echo speaks IP address is now correct.
I'll watch the logs over the next couple days and see if I still have any errors.
Docker Logs...
Applied the update last night. My Echo is still Speaking to me. 
Thanks!
@tonesto7, I can imagine how much you are overwhelmed with so many messages and troubleshooting due to the Heroku issue - rest assured, you’re our hero!
Also, you are probably receiving a lot of suggestions too … but I can’t help and I’d like to give one.
I’m still trying to configure my Docker+ES environment and I can’t find your instructions here - too many posts! So, if you could at least insert, at the very first post here, a link to the post where you give the instructions to do it would be a bless.
Thank you !!!
1 Like
On the 28th when @tonesto7 reported he had put out the server update, but stated you didn't really need to update if your current local server was up and running I checked my cookie refresh status to make sure all was well. All was not well, my cookie showed it had not been updated in 7 days, I was pretty sure it had been updating every 5 days. I watched it pretty close for the first month or so after I got the local server up and running. So I tried to log into my RPi but I got nothing, looks like it died, I hooked up a external monitor so I could see what was happening and it does nothing at power on. I have ordered another but It's going to be a couple of more days before I get it.
There is a manual cookie update option in the Echo speaks menus, but I assume that won't work unless my server is up and running, correct? I still show I am logged in so it's still working for now, the last refresh was 9 days ago. I am hoping it makes it until I can get my new Rpi up and running. Nothing I can do manually to refresh?
Is your rPi booting from an SD card? If so that would be my first suspect, and one of the cheapest fixes.
1 Like
Yes, but I can read the SD card, also the SD card is brand new. As I mentioned I hooked up an external monitor and I get nothing on the screen at turn on. If I remember correctly even with no SD card I would get the RPi logo and other info when it powered on. I used another power supply as well so it appears the RPi died. I bought it in 2019 and I used it my shop one summer before I had added air conditioning. I guess if it urns out to be the card it won't hurt to have a spare Rpi.
Been several years since I set up a new rPi, but I thought that the logo didn't load until the boot loader on the SD card was read and the instructions contained therein began interrogating the hardware. Like I said it's been a while so my memory may be inaccurate.
Same here, I thought I remembered that but maybe not. It's only been a few months since I set this one back up to run the local Echo speaks sever, but I really can't remember either.
Maybe I will dig up another SD card and load it up and see if it will show anything.
