I believe that is what i am missing the volume path.
Docker containers are based on immutable images. Every time you recreate or update a container it and all of the data inside gets destroyed and replaced with the image.
For persistent data you need to mount volumes or directories that live outside of the container and therefore are not affected by container itself being wiped.
i think WORKDIR has more to do with creation of the image and the path of the app within the container, but a volume path still needs to be defined for persistent storage.
worth a shot to try at least. i dont know if the path endpoints actually matter, or just that they're called out. here's some potential modifications to your scripts:
docker run -v ./data:/es-data -e ipAddress=X.X.X.X -p 8091:8091 --name echo-speaks-server --restart=unless-stopped -d tonesto7/echo-speaks-server
docker run
--network host \
--name echo-speaks-server \
-v ./data:/es-data \
-e ipAddress=X.X.X.X \
--restart=unless-stopped \
-d tonesto7/echo-speaks-server
I can tell you that with a regular docker install those are not needed, I can reboot my entire machine and the data is kept. Cannot attest to any of the other setups. If that can be confirmed to solve the issue in some cases I can certainly add it as an optional parameter with other platforms.
testing the echo and dots and not working, all i see in the log is
dev:10052023-01-24 02:24:55.240 PMerrorEcho (v4.2.2.0) | postCmdProcess Error | status: 400 | Msg: null
Well yes its not working because you have not gotten the server working correctly yet....
I looked at the docs you posted for TrueNAS, it does not appear to have a way to just run the container from a command line, you have to use the UI. You probably need to set some sort of persistent storage in their wizard thing but I have no idea what to do for that.
Looks like maybe you could use a preconfigured yaml file, possibly maybe, not sure because their docs are confusing and it looks like they just want to you do everything point and click in UI. Gross.
I searched around if there is a way to just launch it from a terminal using docker run but I cannot find anything useful, sorry.
Aaaaand.... one more reason to hate docker.
I got pass the docker, i have no error in the app, i am able to see all my echo, but they are not talking.
+1, same here.
Container on Qnap, working fine a few days ago, yesterday I found the server not running on qnap Container station, I had to restart.
@Dical you need to set a restart policy of 'unless-stopped'
If you have access to command line you can do it with this (assuming your container is named echo-speaks-server)
docker update --restart=unless-stopped echo-speaks-server
If not you will have to poke around in the UI to see if its a setting you can change.
Hi,
thank you for your feedback. I will have a look whether I can send terminal commands via the Qnap interface. I am not very familiar with this specific procedure and with containers in general.
What I did set for sure is the automatic restart option via the UI, but I assume we are talking about two different things here.
Thank you and I will let you know.
Cheers.
@tonesto7 Any plans to add support for Echo Show devices? Such devices can support showing text, images, slideshows, and videos.
Being able to show images and text would open up so many new features:
What challenges are there for a hub-only option? A limitation of the software or hardware? Eventually the current hub will be replaced with a newer version and so the old one will be open for new and dedicated uses!
@tonesto7 have a few suggestions for a future version if you are willing.
Dunno how I missed the reply. But after changing the restart policy like jtp10181 mentioned above, I haven't logged in to find the container stopped again.
FWIW, I'm running a qnap with container station. I have to change that setting via portainer. Simply turning on auto start in container station didn't do the trick.
What a mess I see with containers etc, wouldn't it be easier for you to pay 5 dollars like me and stop going crazy?
It’s really not that bad. I had been meaning to switch over to a local server for quite a while.
Heroku going from free to draining my wallet of 5 bucks every month forever was just enough motivation to get it done.
Good tip, for anyone else wondering I was able to get mine to work by adjusting the callback URL from the one provided.
Replace the start of it (keeping the ending part the same)
https://cloud.hubitat.com/api/YOUR-HUB-ID/apps/
With This:
http://LOCAL.SERVER.IP/apps/api/
my time is worth much more than 5 dollars a month!!
I didn't bother with a container. I had it running on my Linux box inside of about 10 minutes.
Avoiding Heroku's $5 charge is more than just the charge... it's the principle of the matter. And ensuring you're in control of your own ecosystem (that's Hubitat's major sales pitch - reduced cloud dependence).
Honestly, if the choice was between paying $100 for a local instance and paying Heroku $5/mo indefinitely, I'd choose the local instance any day. That it strips Salesforce of additional customer count / revenue is a nice bonus.
Fair enough, mine is too. But learning a little bit about Linux and docker containers for this and other home automation or server tasks is part of the hobby aspect of all this for me.
To be clear, I have absolutely no background in computer coding or IT.
You are seeing only the problematic aspects here when people ask for help. It’s much harder to say what % of people get it working without a hitch or with minimal hassle.
From what I can tell, where things go sideways for people is often related to the quirks of how docker containers on various platforms interact with the network, which can differ slightly or even greatly.
And as @doctorkb just mentioned, sometimes running the server without docker (there are step-by-step instructions for that here too) is easier and meets the same need.
ETA: but in the end, there’s nothing wrong per se with paying a subscription charge to host this server if that’s what someone decides provides the most value to them. But obviously this is a crowd that, all other things being equal, generally prefers a locally run option to anything in the cloud.
I just wish we had a different topic for those discussions. This topic is completely hijacked by Docker issues by now. I am on heroku and see contant exceptions in the logs, but my call for help was burried in container issues in a matter of minutes. Oh, well.
Download the Hubitat app
