May I request some help from someone who understands this process?
I have configured and got running a local server. On port 8091 it shows:
In setting up the Echo Speaks user app, it says the following:
I tap to proceed, and sign into amazon (from my local server), it then says everything is OK and signed in, and a cookie is obtained.
I go back to the app, and I still get the message that I need to login to Amazon to complete the setup.
Anybody know how to prevent this?
In your step one did you click on the "Goto Login Page" and login from there as well?
and then save settings
The first screen should say "Authentication Good" not "Goto Login Page"
Check your private messages.
For me my firewall was the problem. I temporarily disabled it and voila. Actually I put my ESET firewall in learning mode.
You would only have a problem if your firewall prevented outbound connection to Amazon. The Logon/Cookie server must be able to contact Amazon.
Its different on the windows version it keeps defaulting to 0.0.0.0.
and it will redirect to that IP after login or after logon it will send that IP to echo speaks.
You have to add this to the settings. Then reboot I had to reboot several times because even with these settings it would give echo speaks a ip of 0.0.0.0 preventing it from getting the cookie.
--net-alias=192.168.0.xx -p 192.168.0.xx:8091:8091
Im confused why any of this is needed why cant they get a cookie from inside hubitat.
And why is this server so complicated why cant it be straight PHP so it can run on any server.
Sadly Windows does things very differently. I really try to encourage Windows users to acquire at least one small device that can run Linux and serve the increasing number of these "ancillary" locally served apps.
Suffering from the same "wrong ip" problem (on a Synology Docker host).
@tonesto7 Hi, Tony. Is it possible you can force the HE/ES app to use an ip override? I'm thinking that i know the right ip and it never changes, so can I just tell the ES app to use that ip and ignore any other changes? Thanks for your time.
@CAL.hub The address of your HE/ES app is chosen by the DHCP server on your LAN. If you want/require the same address, set a DHCP address reservation for the instance.
Thanks @vmsman . (I've watched a number of your videos and I'm learning a lot although much of it is over my head.) I'm not totally understanding your comment, so I'll just give you an information dump and maybe you can spot my error.
Echo Speaks is running on my Hubitat hub at a static ip of 192.168.1.31. The ES server (old Heroku functionality) is in a Synology Docker container at 192.168.1.77:8091.
The ES app cookie management is going to another ip address:
When I first set it up, ES Cookie Management was the correct ip (192.168.1.77:8091), but something changes it. Now, for me, it gets murky. My best guess is that the Synology has a static ip of 192.168.1.77 for the LAN port and a VPN address of 10.19.112.125. And it refers to the latter for its default gateway.
Note that the Default Gateway is correct at 192.168.1.1. I set this and then, without fail, within a few hours it changes to a 10.x.x.x ip address. My theory is that ES somehow sees the Default Gateway has changed and changes its address to reach 10.x.x.x:8091. But this is where i am over my head and my theory may lack any merit.
But i know that the cookie management works as long as it uses 192.168.1.77:8091 and then it mysteriously changes to a 10.x.x.x:8091 address and then forever fails. This is where i get my simpleton theory/solution that an ip override selectable by me would fix my problem.
Please let me know your thoughts.
@CAL.hub Can I ask you to come by https://chat.scottibyte.com/ so I can ask you more questions?
that looks so like an issue I had. - I switched isp's one day, and their 'bridge' mode was not right - the code in the isp provided device was broadcasting. the generic 10.x subs is commonly found in xfinity equipment. in the end, I turned their device back into a router, enabled nat, and disabled the dhcp. HOWEVER. when the unit lost power, no matter what, the DHCP would re-enable and caused all sorts of havoc. this bug was reported in a detailed writeup to them.
In the end, I set a filter on my lan to stop dhcp packets traversing. a huge pain! ultimately using windows server dhcp I was able to wrest control back and hand out ip's proper. run a dhcp server sniffer too - you can ID if there are multiple dhcp server using net tools. maybe something there?
For now, my quasi-solution is to wait for the cookie to expire, then re-install the Cookie server. This gets the right ip and allows an update.
I'm assuming my issues have to do with the VPN ip that the Synology issues and ES somehow grabs. I've taken the plunge into the @vmsman swimming pool and am going to implement a Minisforum UM350 Ubuntu server to which i will assign the Cookie refresh duties. So i expect my current issue is temporary.
You can just hard code it into your instance of the app source. If your IP is fixed that is a worthwhile hack.
Any hints on where to find the right spot in the code?
Look for the function called "getIPAddress()" and just make it return your IP. On my version it is at line 752
There is also an environment variable you can set that will override the IP detection. I think there is a way you can pass it in the command line when you launch the container. Sorry I dont know the variable name off the top of my head and I am not a docker expert but I just know it exists and have used it. In Docker for Windows it was available in the GUI, I have it documented somewhere in one of the threads.
I'm staring at the index.js source code and I don't see where it uses an environment variable to override the IP.
function getIPAddress() {
let interfaces = os.networkInterfaces();
for (const devName in interfaces) {
let iface = interfaces[devName];
for (var i = 0; i < iface.length; i++) {
let alias = iface[i];
if (alias.family === 'IPv4' && alias.address !== '127.0.0.1' && !alias.internal) {
return alias.address;
}
}
}
return '0.0.0.0';
The app does write config information to a file in your root directory called "es_config.json" so if one were to do this hack more elegantly you could add a variable there and then use it in the getIPAddress() function. I didn't bother since I just wanted it to work. In my case I actually updated the function to return the first IP since that was the correct interface. It was barfing because I have two interface cards and it was returning the second unused one. I'm not using docker so all of this only applies if you are running it as a pure server via PM2 or otherwise.
Looks like it might just a docker specific thing, IPADDRESS if set seems to fix the issue where it gets 0.0.0.0 for the IP. I have my actual server running on PM2 but I played around with Docker on Windows. Docker is very frustrating, I cannot even find where it saves the files!
@brad5 You mean this?
Download the Hubitat app
