Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Synology: Can't Access Web Interface #108

Closed
speedxibit opened this issue Aug 21, 2019 · 32 comments
Closed

Synology: Can't Access Web Interface #108

speedxibit opened this issue Aug 21, 2019 · 32 comments

Comments

@speedxibit
Copy link

Completely new to this but just did a fresh install on a Synology NAS. I can access Grafana at port 3000 but can't access the Web Interface at port 4000.

I can see all 4 containers in Docker and they are all running. Was there anything I needed to change other than the VIRTUAL_HOST IP address in the docker-compose.yml file?
@adriankumpf
Copy link
Collaborator

What do you see in the logs of the teslamate container?

@speedxibit
Copy link
Author

"waiting for postgres at 127.0.0.1:5432"

@adriankumpf
Copy link
Collaborator

Do you use the docker-compose.yml to run everything? If so, make sure the DATABASE_HOST variable is set to db.

@speedxibit
Copy link
Author

Yes, I used the docker-compose.yml to run everything. I only changed the IP address and timezone in an attempt to get it working thinking that I'll change more settings and redeploy later on.

Screen Shot 2019-08-21 at 1 50 29 PM

@adriankumpf
Copy link
Collaborator

Look's good to me. Which steps did you take to get it all started? And is

"waiting for postgres at 127.0.0.1:5432"

really the only thing showing up if you run

docker-compose logs teslamate

@speedxibit
Copy link
Author

To get started, I created the docker-compose.yml file and copied over to my docker folder. Then I used the docker-compose up -d command to pull all the containers to run them.

If I issue the docker-compose logs teslamate command in the ssh terminal, the response is:

Attaching to docker_teslamate_1
teslamate_1 | WARNING: no logs are available with the 'db' log driver

This is the log in the Synology Docker Packgage:
Screen Shot 2019-08-21 at 3 11 53 PM

@adriankumpf
Copy link
Collaborator

Hmm. You've probably already tried to restart with docker-compose restart?

I'm not familiar with the Synology Docker Package ... @natrlhy can you help out here?

@adriankumpf
Copy link
Collaborator

adriankumpf commented Aug 21, 2019 •
edited

Actually, it should print waiting for postgres at db:5432 (2sec). Some environment variables seem to be missing.

What do you see if you issue the command: docker-compose config? Does it help to restart? If the above mentioned command did not work try docker-compose down && docker-compose up.

@speedxibit
Copy link
Author

Restarting and reinstalling didn't help. However, uninstalling and rolling back to an earlier version of Docker seemed to have made an impact.

The log now does show "waiting for postgres at db:5432 (2sec)"

Any insight on these new errors that I'm seeing?

Screen Shot 2019-08-26 at 4 14 12 PM

@adriankumpf
Copy link
Collaborator

There seems to be an issue with the database user / role. You could try do to start completely fresh by removing all volumes (this will delete all data, e.g. logged drives if there are any!):

# stop everything and delete volumes:
docker-compose down -v

docker-compose up -d

@bahree
Copy link

bahree commented Aug 30, 2019

OK, I suddenly started having the same issue. I tried the docker-compose down -v and got the following results, and now when I want to navigate to port 4000 don't get anything.

Below is what I got:
# docker-compose down -v Stopping docker_db_1 ... done Stopping docker_mosquitto_1 ... done Stopping docker_grafana_1 ... done Stopping docker_teslamate_1 ... done Removing docker_db_1 ... done Removing docker_mosquitto_1 ... done Removing docker_grafana_1 ... done Removing docker_teslamate_1 ... done Removing network docker_default Removing volume docker_teslamate-db ERROR: An HTTP request took too long to complete. Retry with --verbose to obtain debug information. If you encounter this issue regularly because of slow network conditions, consider setting COMPOSE_HTTP_TIMEOUT to a higher value (current value: 60). root@whs:/volume1/docker# docker-compose down -v Removing network docker_default WARNING: Network docker_default not found. Removing volume docker_teslamate-db WARNING: Volume docker_teslamate-db not found. Removing volume docker_teslamate-grafana-data Removing volume docker_mosquitto-conf Removing volume docker_mosquitto-data root@whs:/volume1/docker# docker-compose up -d Creating network "docker_default" with the default driver Creating volume "docker_teslamate-db" with default driver Creating volume "docker_teslamate-grafana-data" with default driver Creating volume "docker_mosquitto-conf" with default driver Creating volume "docker_mosquitto-data" with default driver Creating docker_teslamate_1 ... done Creating docker_mosquitto_1 ... done Creating docker_grafana_1 ... done Creating docker_db_1 ... done root@whs:/volume1/docker#

And whilst the Grafana dashboard on port 3000 loads, it cannot see anything. I am on Synology too where everything was running fine.

Any suggestions?

@bahree
Copy link

bahree commented Aug 30, 2019

And I tried with the beta too as suggested for another issue and it is broken. Any suggestions?

@adriankumpf adriankumpf mentioned this issue Aug 30, 2019
Closed
@adriankumpf adriankumpf changed the title Can't Access Web Interface Synology: Can't Access Web Interface Aug 30, 2019
@drklain
Copy link

drklain commented Aug 30, 2019

Pulled the docker logs for the db as well. Here's what I see:
teslamate

I agree with you that there is something funky between your 1.6.2 software and the 1.7.0 beta software but it is odd since we are just talking interpreting what kind of car it is using a different variable. Kind of sucks because now I can either live with the wrong range data (because 1.6.2 thinks my Model S 90D is a Model 3 or nothing since 1.7.0 doesn't seem to work...

I'm happy to try to assist you in troubleshooting but not sure what else I can give you to help.

@adriankumpf
Copy link
Collaborator

adriankumpf commented Aug 30, 2019 •
edited

I'm actually pretty sure that this is not related to v1.7. Your previously posted screenshot (#123 (comment)) shows that is tries to connect to 127.0.0.1:5432. However, it should read the DATABASE_HOST=db variable from your docker-compose. This was probably triggered by restarting Teslamate and it would've happend with 1.6.2 too.

@drklain
Copy link

drklain commented Aug 30, 2019

Would you recommend running docker-compose up -d again? Or something else?

@adriankumpf
Copy link
Collaborator

adriankumpf commented Aug 30, 2019 •
edited

Well, I'm running out of ideas to be honest ... It all looks like Teslamate is not the issue here so I cannot help really. Can you rollback to the previous Docker version like @speedxibit did? Or do you have a spare Raspberry Pi lying around that could run Teslamate instead?

@drklain
Copy link

drklain commented Aug 30, 2019

Well I tried a complete wipe out. Deleted everything including docker. Reinstalled docker and then installed teslamate using the docker-compose.yml file. grafana runs but teslamate does not so no way to put in information about my car. teslamate log shows it is looking for postgres at 127.0.0.1 vice looking at db (same issue reported by @speedxibit above). Kind of a bummer because at this point I have no way to use Teslamate (even with the wrong range on 1.6.2) and I have no idea how to get it working again.

I saw a reference to rolling back to an earlier version of docker (as opposed to Teslamate) but have no idea how to do that. I just uninstalled it on the synology then reinstalled the package via the package manager...

@adriankumpf
Copy link
Collaborator

Just did a quick google search and found this: https://www.synoforum.com/threads/updated-docker-package-18-09-0-0505-available.1354/ It confirms the bug all of you are seeing.

@telos: you might revert to the latest 17.05 release. When the container is created with docker-compose or docker stack deploy, the environment variables are missing in the resulting container.

Oddly, containers created before the update, still keep their environment variables.

Container started with docker run -e or from the Syno-Docker-UI are not affected.

@drklain
Copy link

drklain commented Aug 30, 2019

Adrian - you are a stud! Was able to get things working again (although a bit painful and I lost all my old data). There may be a way to do this without losing all the data, but here's what I did (for a synology install).

  1. Download the old (working) Docker version 17.05.0. Download it from https://usdl.synology.com/download/Package/spk/Docker/17.05.0-0401/ and save the .spk file to your computer.
  2. Go to the Package Center and click the installed tab. Click on the docker package (not the open button but around there). It will open up the package and you have a button with a drop down arrow...click the arrow and select "uninstall". This deletes everything.
  3. In the package center at upper right is a button for "Manual Install". Click that. In the file folder, point it to the .spk file you saved in step 1. It will now install the older version of Docker.
    WARNING -- ONCE INSTALLED, SYNOLOGY WILL TELL YOU THERE IS A NEWER VERSION AND GIVE YOU AN "UPDATE" BUTTON. DO NOT DO THIS AS IT TAKES YOU TO THE NEW (BROKEN) VERSION OF DOCKER.
  4. Once Docker is installed, install Teslamate per the instructions at Idiot's guide to getting this working on a Synology NAS #113.

You should be up and running in a few minutes!

@adriankumpf - thank you so much for your assistance in getting this running. Finding that link that the issue was a newer version of docker on synology was the key and it never occurred to me since Teslamate was working fine on the new version of docker since I had installed it on the OLD version of docker... One question -- I installed the 1.7.0 beta. Right now the degradation tab is still showing a range of 351 miles but presumably the system should be recognizing I'm a Model S 90D and have a lower range. I'm not sure if that will change if I drive the car for a bit, but wanted to let you know that range still appears to be wrong.

@bahree
Copy link

bahree commented Aug 30, 2019 •
edited

OK let me try this - but the question I have - is there a way to save/keep the data so I don't loose that? Any way to backup the db and then restore it or even script it out in terms of a data dump?

Thanks.

@speedxibit
Copy link
Author

Adrian, thanks for putting together this wonderful package and for the the support! It's an amazing asset especially given Tesla's shenanigans with all the recent updates.

Just to confirm what @drklain has stated, mine is also working on 17.05.0-401 of Docker. All my issues seemed to revolve around the fact that I was using a newer version. Once I rolled back, and deleted the volumes per Adrian with docker-compose down - v, everything started working. Deleting the containers within Synology was not sufficient.

I've only had 1 hiccup since getting it going was that Teslamate lost connection to the car. The timing seems to link up with driving the car when it was attempting to go to sleep but I'm not sure if that was the cause. In any event, restarts wouldn't work but deleting the volumes and reinstalling has resolved it.

I'm also seeing inflated range values. I haven't checked what the car states but I wonder if that variable is tied to the "Ideal Range" rather than "Rated Range".

@adriankumpf
Copy link
Collaborator

OK let me try this - but the question I have - is there a way to save/keep the data so I don't loose that? Any way to backup the db and then restore it or even script it out in terms of a data dump?

Thanks.

@bahree, having a backup is never a bad idea ;) Not sure if there are incompatibilities between both Docker versions or if uninstalling the package also deletes the volumes but in theory downgrading and restarting is all that is necessary. Purging the db volume is not required.

@drklain, awesome! Glad it works. Like I said earlier, the vehicle detection has nothing to do with the range. What's more important to me right now is, that it actually detects you have a S 90D.
Regarding range: it's rated range vs ideal range. Is that maybe a difference between EU and US cars? Here, I always want to see the ideal range. It matches what the app displays. So feel free to update the dashboards where necessary. Maybe someone will send in a PR that makes the range configurable ...

@speedxibit Great! Yeah, that's probably because the logging was suspended when you started driving. Check the logs for more information.

@drklain
Copy link

drklain commented Aug 30, 2019 via email

@adriankumpf
Copy link
Collaborator

Currently, that can be only done by checking the database. The final v1.7 will display that on the web interface.

@bahree
Copy link

bahree commented Aug 30, 2019

For me to deprecate I had to uninstall the previous version and blow away all the data and then start all over again.

@bahree bahree mentioned this issue Aug 30, 2019
Closed
@drklain
Copy link

drklain commented Aug 30, 2019 via email

@adriankumpf
Copy link
Collaborator

adriankumpf commented Aug 30, 2019 •
edited

V1.7 was just released :) You can safely switch to that. The web interface now shows the model below the car‘s name.

@drklain
Copy link

drklain commented Aug 30, 2019 via email

@normalfaults
Copy link

in order to update go to the directory where docker-compose.yml file is located, assuming you didn't hardcode versions in docker-compose.yml file you can run the following ...
docker-compose pull
docker-compose up -d

@drklain
Copy link

drklain commented Aug 30, 2019 via email

@adriankumpf
Copy link
Collaborator

Perfect. Thanks!

@IMgoRt
Copy link

IMgoRt commented Sep 1, 2019

For those unaware, you can close the 4 docker containers and then enter the parameters that have been missed (about 10 in total across the 4)and restart, only takes a couple of minutes, no data lost.
Pending an actual fix from Synology.

@IMgoRt IMgoRt mentioned this issue Sep 2, 2019
Closed
@adriankumpf adriankumpf pinned this issue Sep 2, 2019
@adriankumpf adriankumpf unpinned this issue Sep 3, 2019
@dyxyl dyxyl mentioned this issue Jun 9, 2020
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@normalfaults @bahree @adriankumpf @speedxibit @IMgoRt @drklain