Closed shadow2810 closed 3 years ago
Do you have access to the docker command line to be able to troubleshoot? Without this, and with no logs, there's really not much to go on. By far the most common issue is that the token needs to be regenerated and passed in the environment variable again. Usually this is caused due to the persistent storage not really being persistent across updates of the docker image.
This issue is, it clear works for most people as there are already 1000+ downloads and trust me, I'd be flooded with issues if the problem was widespread. The addon uses the very same docker images, there's nothing special about the addon vs running docker manually, other than the scripts do a few things slightly differently.
Now, I'm not saying there's not a problem of course, I did had one other similar reported issue with 4.5.7, but then, that user couldn't get the 4.5.5 image to work again either, which is unchanged, so it didn't really seem to be related to any changes.
Regardless, the issue is very difficult, if not impossible, to troubleshoot with no logs or valid error message. If you have access to docker via shell we can try manually getting a shell and running the scripts to see what happens, or we can make sure we are getting 100% of the logs.
Also, is the Synology x86 based? I've personally tested the Docker image on a RPi running Ubuntu, and I run the addon on both a RPi and an x86 based VM, so I've personally tested the Docker image on three platforms, but I haven't tested running under standalone Docker on x86, although I can fairly easily.
Also, if you revert to 4.5.5, does it work?
I can run docker command line, let me know which command should I try
My synology is 64bit, from what I understand:
Also, if you revert to 4.5.5, does it work?
I have tried 4.5.5 and it didn't work
Thanks
If 4.5.5 also doesn't work that reinforces the theory of a bad token or something else that has nothing to do with the new image itself since the 4.5.5 image is unchanged from when it was pushed months ago.
The command you ran above is nowhere near enough for ring-mqtt to be successful, unless you are using MQTT on localhost with no authentication. You should be able to get more detail if you enable debug using -e DEBUG=ring-mqtt on your docker command line.
So I misunderstood the document. I thought I could leave env RINGTOKEN
blank and on first run, the container will create a authentication page on port 55123
.
I ran the command sudo docker run -it --rm --entrypoint /app/ring-mqtt/node_modules/ring-client-api/ring-auth-cli.js tsightler/ring-mqtt
manually to generate a token and assiged it to the container, it's running now. Thanks!
Yep, the internal web server auth is only used for the addon or standard install methods, although these days I could probably enable it for Docker as well. The main reason I didn't is because there are so many ways to run Docker networking it opens a can of worms I wasn't really interested in trying to deal with it. Well, that and the fact that in the early days there was no support for using persistent storage in the Docker image. You can only leave it blank if the token is stored on persistent storage so after the first run. These days it's matured a lot and I probably should enhance this but, as 95% of users are using the addon, it's not been a pressing issue. Heck, at this point even I've finally switched to the addon.
Glad you got it working. I think I'm going to make DEBUG mode default in the next version.
I'm running docker on synology
Here is my configuration:
Whenever I tried to start the container, it ran for few seconds then threw an error
docker container ring-mqtt stopped unexpectedly
Checked the log, there was only "Running ring-mqtt..." message
I cannot use addon since I'm also running HA on synology and it doesnt support the supervisor build...