Grafana issue on Synology NAS
jaydkay opened this issue · 72 comments
Hi,
I tried setting up the Powerwall-Dashboard with Docker on a Synology NAS. I'm not sure if this is even supposed to work, but the setup script is running fine and three containers seem to start up okay. Only grafana keeps shutting down with the following entries in the docker log:
GF_PATHS_DATA='/var/lib/grafana' is not writable.
You may have issues with file permissions, more information here: http://docs.grafana.org/installation/docker/#migration-from-a-previous-version-of-the-docker-container-to-5-1-or-later
mkdir: cannot create directory '/var/lib/grafana/plugins': Permission denied
Any idea what is causing this or how to get grafana running?
Best regards,
Jochen
Hi @jaydkay - When grafana starts, it attempts to install the required plugins as indicated by the error. It uses user 1000 group 1000 for this directory. The link you pasted talks about this as being a user permission issue. Some ideas I have:
Is it possible you already had grafana (older version) installed? Try removing it and re-install:
# stop and remove
docker stop grafana
docker rm grafana
# reinstall
docker-compose -f powerwall.yml up -dI have seen permission error if you run thesetup.sh as root. If you did this, try to remove the Powerwall-Dashboard folder and reinstall using the local user. You will need to make sure your local user has docker permissions:
# Add your user to docker group
sudo usermod -aG docker $USERIf that wasn't the case, you could try to change the permission manually:
# run a shell in grafana interactively
docker exec -ti --user root grafana /bin/bash
ls -la /var/lib/grafana/
chown 1000:1000 /var/lib/grafana/Dear @jasonacox,
thanks for your quick reply. I tried following your suggestions, alas, no success so far...
Is it possible you already had grafana (older version) installed? Try removing it and re-install:
No, it's a completely new installation from scratch. In fact, it's my first contact with docker.
I have seen permission error if you run thesetup.sh as root. If you did this, try to remove the Powerwall-Dashboard folder and reinstall using the local user. You will need to make sure your local user has docker permissions:
Yes, I needed to start ./setup.sh via sudo - it seems that on Synology DSM, docker is typically not available for the normal user. Command usermod also doesn't exist, but there are corresponding commands, so was able to add the current user to the docker group and start docker with a standard user account. Unfortunately, the error remained the same. Additionally, now also Telegraf refuses to start with the following log entry:
I! Using config file: /etc/telegraf/telegraf.conf
E! [telegraf] Error running agent: Error loading config file /etc/telegraf/telegraf.conf: open /etc/telegraf/telegraf.conf: permission denied
Finally, I also tried your final suggestion:
If that wasn't the case, you could try to change the permission manually:
That didn't work either, because the container already refuses to start, so the command you suggested complains about grafana not yet running (but it never will):
Error response from daemon: Container ac20100690faff31b7c2df6bcb6fa9079eea9a496efdbbcf2fed6b8144731aae is restarting, wait until the container is running
If you have any more suggestions, please let me know. Thanks a lot again for your help!
Since you originally used sudo the file permission are likely in bad shape. I suggest removing the Powerwall-Dashboard directory and reinstall from scratch now that you have your local user in the docker group:
# remove the old install
rm -fr Powerwall-Dashboard
# git clone or pull down the repository again
git clone https://github.com/jasonacox/Powerwall-Dashboard.git
# run setup
cd Powerwall-Dashboard
./setup.shThanks for the feedback on this. Hopefully we can figure this out for anyone else using a Synology NAS to host their dashboard. :)
Dear @jasonacox,
after a few more tries and errors, I guess I finally got it working! Here are the steps that were required - at least in my case:
Log in via SSH to Synology DSM. Create a usergroup docker:
sudo synogroup --add docker
Change ownership of docker to this group:
sudo chown root:docker /var/run/docker.sock
Make the user a member of the newly created group:
sudo synogroup --member docker <user>
Finally, edit file powerwall.yml and change the line
user: "1000:1000"
in the section grafana to the uid of the user on the Synology. I got that by running id while logged in via SSH.
After this, I was able to issue ./setup.sh, finish setting it up and all containers are starting up.
So far it seems to be working, although I didn't do much more beyond starting it up, yet.
Awesome!! Nice job @jaydkay ! Thanks for posting the helpful instructions. I'll reference that in the troubleshooting tips.
Hi @jasonacox, @jaydkay,
I've just run into either the same problem or a closely related one while setting up Powerwall-Dashboard under a rootless docker. I was getting the same messages as Jochen GF_PATHS_DATA='/var/lib/grafana' is not writable. and mkdir: cannot create directory '/var/lib/grafana/plugins': Permission denied.
It took a while for me to track it down - as far as I can tell for the rootless version, it comes down to the fact that grafana runs with user:group ids of 472:0 in the rootless container, and this results in name space mapping issues when creating/writing files on the host machine (this explanation isn't quite right, but is probably close enough to the truth allow resolution of the problem).
I found two possible solutions:
-
The first solution is probably safe in a rootless system, but I really wouldn't recommend it as a) only probably safe and b) if you ever switch to a normal docker, it becomes very not safe. It's simple - run the rootless container as "root" by changing the grafana user line in
powerwall.ymltouser: "0:0". This works as docker rootless maps root to the user running the docker installation. Again, I would really not recommend this approach - I'm just including it as someone else may find this step useful in their own troubleshooting. -
The second solution is somewhat cleaner, although I'm pretty sure this is still just a work around for a limitation on name space mapping for rootless docker.
-
Change the grafana user line in
powerwall.ymltouser: "472:0"(you may be able to delete it altogether - haven't tried this). -
Get the subuid entry for the user
xxxxrunning docker from/etc/subuidon the host machine. In my case it isxxxx:100000:65536- from this, we can calculate the uid mapping of the container uid grafana user to a subuser user id on the host machine as: first number in the subuid (100000) + 471 (0 offset of the grafana uid) - so for me this is100471. -
Change the ownership of the grafana directory in Powerwall-Dashboard on the host machine to this subuid:
sudo chown 100471 ./grafana(Fails without sudo, but this is a subuid in thexxxxuser name space, so has the same privileges asxxxx- effectively no change in permissions)
Running ls -ld ./grafana should result in:
drwxr-xr-x 6 100471 xxxx 4096 Sep 21 10:54 ./grafana (where xxxx is the username running docker - same as the subuid file).
- Kill the current container and restart.
docker stop grafana
docker rm grafana
docker compose -f powerwall.yml up -d
I hope this saves someone else a day or so of digging in the future. Picking up docker this way was definitely a baptism by fire.
Finally, @jasonacox, thanks again for the time you have put into a great monitoring tool!
Thanks for this great information, @BuongiornoTexas ! Is this on a Synology NAS or something else?
Is this on a Synology NAS or something else?
Raspberry Pi 4B - so quite the journey getting docker running at all even without dealing with getting it rootless and the grafana permissions issue.
Dropped in here as the error is identical to Jochen's and almost certainly related, but if you want to include it as a tip, I'd put it in a section on grafana permissions and/or rootless docker.
Thanks @BuongiornoTexas !!!- I'm running on a Raspberry Pi as well (Raspbian GNU/Linux 11 bullseye). Can you cat /etc/os-release for anyone following this?
For my setup, I had to run something like this:
# Install docker
curl -fsSL https://get.docker.com/ -o get-docker.sh
sudo sh get-docker.sh
sudo apt install -y docker-compose
# Add your user to docker group
sudo usermod -aG docker $USER
# Set docker to start on boot
sudo systemctl enable docker.service
sudo systemctl enable containerd.service
# install docker-compose
sudo pip3 install docker-composeI wonder if I can add notes or setup.sh instructions to help.
Like you, I'm on bullseye (64 bit).
PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
NAME="Debian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=debian
I think the difference between our installs is that I'm running docker as a non-privileged (rootless) user. So I don't have a docker group at all.
The process for setup is a bit messier, but works pretty well. It's detailed at: https://docs.docker.com/engine/security/rootless/
The steps I took were:
-
Use
apt -qq list yyyto check for the following pre-req packages, and if not, installed them.uidmap dbus-user-session fuse-overlayfs slirp4netns (0.4 or later) -
Run the Without packages install script
curl -fsSL https://get.docker.com/rootless | sh. At which point docker engine is installed. -
Added the two environment lines at the end of the script to my .bashrc:
export PATH=/home/username/bin:$PATH
export DOCKER_HOST=unix:///run/user/1000/docker.sock
-
Installed v2 of docker compose manually per the process at
https://docs.docker.com/compose/install/linux/(there are binaries for arm64 on github now,aarch64file identifier fromuname -m!) :DOCKER_CONFIG=${DOCKER_CONFIG:-$HOME/.docker} mkdir -p $DOCKER_CONFIG/cli-plugins curl -SL https://github.com/docker/compose/releases/download/v2.11.0/docker-compose-linux-aarch64 -o $DOCKER_CONFIG/cli-plugins/docker-compose
I think everything was running after this.
Thanks @BuongiornoTexas ! This is a great 'get starting' for anyone wanting to run docker as a non-privileged (rootless) user. I'll capture this in the troubleshooting section for anyone else wanting to do the same.
Thank you!
No probs. One more step I forgot - I created a file called docker-compose in ~/bin containing:
docker compose "$@"
And ran chown +x ~/bin/docker-compose. An alias that emulates v1 with v2.
Alternatively, users can just run docker compose manually.
I had the same permission error on a Pi4 running Ubuntu. The only way I could fix it was to change the grafana user line in powerwall.yml to user: "0:0", as noted by @BuongiornoTexas.
The only way I could fix it was to change the grafana user line in powerwall.yml to user: "0:0",
Is this on a standard docker install? If so, something doesn't sound quite right there - the problem I had was because docker was missing some of the privileges from a standard install (I think you have effectively given your grafana instance root privileges in the docker container, which shouldn't be needed at all).
One quick thought is your user id 1000? If not, that would break the setup.
Yes, it is standard. My user id is 1001. I change powerwall.yml to user: "1001", killed the current container and reinstalled. It is now working as expected.
I change powerwall.yml to user: "1001", killed the current container and reinstalled. It is now working as expected.
Excellent. You may want to make the powerwall.yml entry 1001:1001 so that it also has the correct group permissions.
Hi all - i am also trying to install this on my Synology NAS.
This is what I have done so far:
- I created a shared folder called Powerwall
- Followed the instructions above:
- Log in via SSH to Synology DSM. Create a usergroup docker:
sudo synogroup --add docker
Change ownership of docker to this group:
sudo chown root:docker /var/run/docker.sock
Make the user a member of the newly created group:
sudo synogroup --member docker
-
installed from github: git clone https://github.com/jasonacox/Powerwall-Dashboard.gi
-
ran the ./setup.sh from the directory Powerwall-Dashboard:
-
Backupadmin@BackupStation:/volume1/powerwall/Powerwall-Dashboard$ ./setup.sh
Now I am getting this error back:
Powerwall Dashboard (v2.8.0) - SETUP
ERROR: docker is not available or not runnning.
This script requires docker, please install and try again.
Docker is running on the Synology. The user "BackupAdmin" is a member of the "docker" group:
Is there anything else I can check to figure out what the issue is ?
Thanks so much for your help.
HI @marcbaier - I hope our community can chime in on this. I guess I need to add a "Synology NAS" to my test suite (currently MacOS, Ubuntu Linux, Win 11 WSL and Raspberry Pi). 😄 What model are you using?
ERROR: docker is not available or not runnning.
What do you get when you run docker ps or docker info?
I get this when running docker ps:
Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get "http://%2Fvar%2Frun%2Fdocker.sock/v1.24/containers/json": dial unix /var/run/docker.sock: connect: permission denied
docker info:
Client:
Context: default
Debug Mode: false
Server:
ERROR: Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get "http://%2Fvar%2Frun%2Fdocker.sock/v1.24/info": dial unix /var/run/docker.sock: connect: permission denied
I am trying to run this on a DS1513+ running DSM7.1.1. I could also try it on a newer DS1019+ but I would presume that I would get the same issue there as well.
Thanks @marcbaier - that helps a lot! Your local user does not have permission to run docker. Check the permissions of the socket:
ls -l /var/run/docker.sockAlso, just to confirm, you did run these?
sudo synogroup --add docker
sudo chown root:docker /var/run/docker.sock
sudo synogroup --member docker $USER
DS1513+ running DSM7.1.1.
Thanks! I'll see if I can find one.
This is what i get back when I run the docker.sock command above:
srw-rw---- 1 root docker 0 Feb 4 09:02 /var/run/docker.sock
Interesting. That should work if your local user is part of the docker group. I have seen it "not take" until I log out and log in again or reboot the host (on Linux, not a Synology). You can also try this (a common 'fix' mentioned on the docker helps):
sudo chmod 666 /var/run/docker.sockThat worked ! Now I was able to install the whole ./setup.sh. I am now stuck at the grafana setup. The IP Address of my Synology Nas is 192.168.86.58 and I wanted to use the browser on my iMac to access: http://192.168.86.58:9000, but I am getting an "this site can't be reached" error.
looks like grafana is not running. I went and looked into the docker install and this is what I see:
When I try to restart grafana I am getting these errors, as I think others on here also got:
GF_PATHS_DATA='/var/lib/grafana' is not writable.
You may have issues with file permissions, more information here: http://docs.grafana.org/
mkdir: cannot create directory '/var/lib/grafana/plugins': Permission denied
Did you follow the hints in my post at the beginning of this thread?
#22 (comment)
This part in particular:
Finally, edit file powerwall.yml and change the line
user: "1000:1000"in the section grafana to the uid of the user on the Synology. I got that by running id while logged in via SSH.
After this, I was able to issue ./setup.sh, finish setting it up and all containers are starting up.
You probably need to stop, delete and re-create the containers after doing this change to take effect.
I did follow your instructions and replaced the uid with mine. however, I did not delete and re-create the containers. How would I do that ? directly in docker and then run the ./setup.sh again ?
ok so i did the following:
- stop and delete all the containers
- check the powerwall.yml file and change the value to 1029
- (uid=1029(Backupadmin) gid=100(users) groups=100(users),101(administrators),65536(docker))
- executed ./setup.sh again
- in the docker app on the synology I still see the grafana and telegraf containers restarting.... so i guess nothing has changed.
ah - think i found the issue. I did not correct the user: value in the grafana section... stupid me. Now that I've done that, the containers are not restarting anymore and I am not getting an error message either.
thanks so much
You‘re welcome.
@marcbaier did you get the Grafana dashboard running?
FYI - some interesting endpoints you could test:
- http://192.168.86.58:8675/vitals - Powerwall vitals
- http://192.168.86.58:8675/stats - pypowerwall stats
- http://192.168.86.58:8676 - weather411 current conditions
Yes I got it all running fine on the NAS but I don't seem to be getting any weather data. The bottom panels are empty:
I agree, it doesn't look like weather411 is running.
Try http://192.168.86.58:8676/ - weather411 current conditions
Also try:
# check logs
docker logs weather411
# restart weather411
docker restart weather411When i click on the link above, I get a "this site can't be reached" error.
docker logs weather411 returns this:
Backupadmin@BackupStation:~$ docker logs weather411
Weather411 Server 0.1.2
ERROR: No config file. Fix and restart.
The error remains after doing a restart.
The weather411 configuration is missing. Run this:
./weather.shSee the instructions here:
You will need to include your location (Latitude and Longitude) and your OpenWeatherMap API Key. To get a Key, you need to set up a free account at openweathermap.org. Make sure you check your email to verify account. API keys can take a few hours to activate.
Hi Jason - I thought I had already gone through this process during the regular setup. So I did it again using the code above. Here is the whole process:
Backupadmin@BackupStation:/volume1/powerwall/Powerwall-Dashboard$ ./weather.sh
Weather Data Setup
-----------------------------------------
Weather data from OpenWeatherMap can be added to your Powerwall Dashboard
graphs. This requires that you set up a free acccount with OpenWeatherMap
and enter the API Key during this setup process.
Do you wish to setup Weather Data? [y/N] y
Forecast looks great! Proceeding...
Existing Configuration Founded
[Weather411]
DEBUG = no
[API]
# Port to listen on for requests (default 8676)
ENABLE = yes
PORT = 8676
[OpenWeatherMap]
# Register and get APIKEY from OpenWeatherMap.org
APIKEY = xxxxxxxxxxxxxxxxxxxxxxxxxxx
# Enter your location in latitude and longitude
LAT = 47.4140132
LON = 8.2375113
WAIT = 10
TIMEOUT = 10
# standard, metric or imperial
UNITS = metric
[InfluxDB]
# Record data in InfluxDB server
ENABLE = yes
HOST = influxdb
PORT = 8086
DB = powerwall
FIELD = weather
# Leave blank if not used
USERNAME =
PASSWORD =
Overwrite existing settings? [y/N] y
Removing old file weather/weather411.conf.
Set up a free account at OpenWeatherMap.org to get an API key
1. Go to https://openweathermap.org/
2. Create a new account and check your email to verify your account
3. Click on 'API Keys' tab and copy 'Key' value and paste below.
Enter OpenWeatherMap API Key: xxxxxxxxxxxxxxxxxxxxxxxxxxx
Enter your location coordinates to determine weather in your location.
For help go to https://jasonacox.github.io/Powerwall-Dashboard/location.html
Enter Latitude: 47.4140132
Enter Longitude: 8.2375113
Enter the desired units: M)etric, I)mperial or S)tandard where:
M)etrics = temperature in Celsius
I)mperial = temperature in Fahrenheit
S)tandard = temperature in Kelvin
Enter M, I or S: m
Units selected: metric
NOTE: The OpenWeatherMap key can take up to 2 hours to be valid.
You may see errors or no data until it is fully activated.
Running Docker Compose...
influxdb is up-to-date
pypowerwall is up-to-date
grafana is up-to-date
weather411 is up-to-date
telegraf is up-to-date
Weather Setup Complete
Backupadmin@BackupStation:/volume1/powerwall/Powerwall-Dashboard$
I stopped and deleted the old weather411 container before I did the above. When i look at the newly created weather411 containers log, i still see this:
Ok, wow, that's confusing! The python script can't find the ./weather/weather411.conf file (which for you should be /volume1/powerwall/Powerwall-Dashboard/weather/weather411.conf).
When you set up the containers (ran setup.sh or compose-dash.sh), did you run them from the /volume1/powerwall/Powerwall-Dashboard folder?
TODO for me is to add a more helpful error message to Weather411. It should list the config file it is trying to load.
Possible workaround:
Edit the powerwall.yml and edit the weather411 section to set a full path in the "source" for the volume mapping:
weather411:
image: jasonacox/weather411:latest
container_name: weather411
hostname: weather411
restart: always
user: "1000:1000"
volumes:
- type: bind
source: /volume1/powerwall/Powerwall-Dashboard/weather
target: /var/lib/weather
read_only: true
ports:
- target: 8676
published: 8676
mode: host
environment:
- WEATHERCONF=/var/lib/weather/weather411.conf
depends_on:
- influxdbRestart:
./compose-dash.sh up -dhi Jason - i did make the changes to the powerwall.yml file. I stopped and deleted the weather411 container and executed the command you provided. however still no change:
Thanks for trying to get this to work and your troubleshooting steps. It just occurs to me that the NAS may not be allowing access to user 1000. Let's check the ownership of that file:
# see what it has right now to confirm this could be the issue
ls -l /volume1/powerwall/Powerwall-Dashboard/weather/weather411.confIf it doesn't match user 1000 or is not world readable:
# change owner
sudo chown 1000:1000 /volume1/powerwall/Powerwall-Dashboard/weather/weather411.conf
# or change permission
sudo chmod a+r /volume1/powerwall/Powerwall-Dashboard/weather/weather411.conf
# restart
docker restart weather411
docker logs weather411 -fOK I did this. When I now check the owner I get:
-rwxrwxrwx 1 1000 1000 534 Feb 11 23:30 /volume1/powerwall/Powerwall-Dashboard/weather/weather411.conf
restarted, but the logs still show:
Let's shell in to the weather411 docker container to see what it sees - try this from the command line (ssh):
docker exec -it weather411 sh
ls -l /var/lib
ls -l /var/lib/weather
set | grep WEATHER
# you may also try this just to make sure it can read the file
cat /var/lib/weather/weather411.confHere is what I see on my system:
$ docker exec -it weather411 sh
/app $ ls -l /var/lib
total 16
drwxr-xr-x 2 root root 4096 Aug 9 2022 apk
drwxr-xr-x 2 root root 4096 Aug 9 2022 misc
drwxr-xr-x 2 root root 4096 Aug 9 2022 udhcpd
drwxr-xr-x 3 1000 1000 4096 Feb 9 07:03 weather
/app $ ls -l /var/lib/weather
total 68
-rw-r--r-- 1 1000 1000 153 Feb 9 07:02 Dockerfile
-rw-r--r-- 1 1000 1000 4660 Feb 9 07:02 README.md
drwxr-xr-x 3 1000 1000 4096 Feb 9 07:02 contrib
-rw-r--r-- 1 1000 1000 13181 Feb 9 07:02 dashboard-weather411.json
-rw-r--r-- 1 1000 1000 18131 Feb 9 07:02 server.py
-rwxr-xr-x 1 1000 1000 725 Feb 9 07:02 upload.sh
-rw-r--r-- 1 1000 1000 535 Feb 9 07:03 weather411.conf
-rw-r--r-- 1 1000 1000 531 Feb 9 07:02 weather411.conf.bak
-rw-r--r-- 1 1000 1000 531 Feb 9 07:02 weather411.conf.sample
/app $ set | grep WEATHER
WEATHERCONF='/var/lib/weather/weather411.conf'
Don't know if this might help, but on my Synology system, the respective config-file weather411.conf is owned by the current user (admin) and is not an executable:
admin@ds:~$ ls -l Powerwall-Dashboard/weather/weather411.conf
-rw-r--r-- 1 admin users 532 Feb 11 16:45 Powerwall-Dashboard/weather/weather411.conf
Looking into the container, it looks like this:
admin@ds:~$ docker exec -it weather411 sh
/app $ ls -l /var/lib
total 0
drwxr-xr-x 1 root root 0 Aug 9 2022 apk
drwxr-xr-x 1 root root 0 Aug 9 2022 misc
drwxr-xr-x 1 root root 0 Aug 9 2022 udhcpd
drwxr-xr-x 1 1024 users 250 Feb 11 15:45 weather
/app $ ls -l /var/lib/weather
total 64
-rw-r--r-- 1 1024 users 153 Feb 11 15:43 Dockerfile
-rw-r--r-- 1 1024 users 4660 Feb 11 15:43 README.md
drwxr-xr-x 1 1024 users 32 Feb 11 15:43 contrib
-rw-r--r-- 1 1024 users 13181 Feb 11 15:43 dashboard-weather411.json
-rw-r--r-- 1 1024 users 18131 Feb 11 15:43 server.py
-rwxr-xr-x 1 1024 users 725 Feb 11 15:43 upload.sh
-rw-r--r-- 1 1024 users 532 Feb 11 15:45 weather411.conf
-rw-r--r-- 1 1024 users 531 Feb 11 15:45 weather411.conf.bak
-rw-r--r-- 1 1024 users 531 Feb 11 15:43 weather411.conf.sample
Btw, 1024 is the uid of the current user (admin) on my system.
Thanks @jaydkay ! It did strike me odd that @marcbaier 's system shows that file with the executable flag "x" for all. Also, when you set this up on your Synology, do you recall any problems with weather411 or did it just work?
@marcbaier let us know what your system shows. Technically the permission on your system (and on @jaydkay ) should allow anyone to read that file including the weather411 python script. I suspect something else is off like the file system is not getting namespace mapped into the docker container correctly.
It just worked out of the box. The only things I adjusted during setup of the Powerwall-Dashboard were the ones I mentioned in one of the first posts of this thread, see here.
Hi Jason - here we go:
/app $ ls -l /var/lib
total 20
drwxr-xr-x 2 root root 4096 Aug 9 2022 apk
drwxr-xr-x 2 root root 4096 Aug 9 2022 misc
drwxr-xr-x 2 root root 4096 Aug 9 2022 udhcpd
drwx------ 3 1029 users 4096 Feb 11 22:30 weather
/app $ ls -l /var/lib/weather
ls: can't open '/var/lib/weather': Permission denied
total 0
There's the problem! The weather directory does not permit access. It should look like what @jaydkay posted:
drwxr-xr-x 1 1024 users 250 Feb 11 15:45 weather
See if you can fix it - ssh in and run:
ls -l /volume1/powerwall/Powerwall-Dashboard/
sudo chmod a+rx /volume1/powerwall/Powerwall-Dashboard/weather
ls -l /volume1/powerwall/Powerwall-Dashboard/ok i did that and here is the result:
drwxr-xr-x 3 Backupadmin users 4096 Feb 11 23:30 weather
I then restarted the weather411 container and here is the log:
Weather411 Server [0.1.2]
- Configuration Loaded [/var/lib/weather/weather411.conf]
- Weather411 - Debug: False, Activate API: True, API Port: 8676
- OpenWeatherMap - Key: ********************, Wait: 10, Units: metric
- OpenWeatherMap - Lat: 47.4140132, Lon: 8.2375113, Timeout: 10
- InfluxDB - Enable: True, Host: influxdb, Port: 8086, DB: powerwall, Field: weather
- Starting threads
- fetchWeather thread
- apiServer thread - Listening on http://localhost:8676
I guess this means success ? If yes, you deserver a virtual beer ;)
Great news, @marcbaier ! Congratulations, you did it! ;)
Check your dashboard and you should now see weather data showing up in your graphs. You can also visit the weather411 dashboard here: http://localhost:8676/ (replace localhost with the address of your NAS).
I guess this means success ? If yes, you deserver a virtual beer ;)
Haha! I'll take it! Or better yet a virtual cider or Oeil-de-Perdrix... 😂
In all seriousness, I do think we need better documentation or a setup.sh that better accommodates a Synology NAS hosted stack.
Hey all, I'm installing the powerwall dashboard on my Synology NAS. Reading through this has helped me over the hurdles you all have encountered. I ran the quick start version (option 1) and was able to get all containers running. I am running into an issue that I have not seen mentioned. I am stuck on the Grafana setup portion. When adding the InfluxDB as a data source, I receive "error connecting influxDB influxQL" after I click Save and Test.
I confirm the influxdb container is running along with everything else. Am i doing something wrong?
influxdb log.txt
Hi @panderson87 - thanks for opening this.
Did you happen to record or remember the main steps you took? It would be good to have that for others following the same path. 🙏
But more important, let's see if we can get your setup working!
InfluxDB Issues
This error could mean InfluxDB is not really listening - This would be evident in the "telegraf" logs:
# check logs of telegraf
docker logs telegrafErrors would look like:
2023-02-20T05:37:00Z W! [outputs.influxdb] When writing to [http://influxdb:8086]: database "powerwall" creation failed: Post "http://influxdb:8086/query": dial tcp 172.23.0.3:8086: connect: connection refused
2023-02-20T05:37:10Z E! [outputs.influxdb] When writing to [http://influxdb:8086]: failed doing req: Post "http://influxdb:8086/write?db=powerwall&rp=raw": dial tcp 172.23.0.3:8086: connect: connection refused
2023-02-20T05:37:10Z E! [agent] Error writing to outputs.influxdb: could not write any address
2023-02-20T05:37:20Z E! [outputs.influxdb] When writing to [http://influxdb:8086]: failed doing req: Post "http://influxdb:8086/write?db=powerwall&rp=raw": dial tcp 172.23.0.3:8086: connect: connection refused
2023-02-20T05:37:20Z E! [agent] Error writing to outputs.influxdb: could not write any address
Docker Networking Issues
The error you see could mean Grafana is unable to resolve the name "influxdb" which docker compose should handle. Option 1 (setup.sh) uses docker-compose to get this running (including setting up the 'network powerwall-dashboard_default' to handle the lookup and communication). To test that all of this is set up correctly try this:
# take the stack down
./compose-dash.sh down
# rebuild the stack
./compose-dash.sh up -dIt should show something like this:
Try to set up the database again in Grafana after restarting.
Thanks for the quick reply. So in checking the telegraf container, it was not fully started. Logs showed
"error loading config file /etc/telegraf/telegraf.d/local.conf: open /etc/telegraf/telegraf.d/local.conf: permission denied"
So, I deleted the container, updated the powerwall.yml file and under telegraf, changed the user from 1000:1000 to match the uid/group of my Synology installer account (I initially did this for all of the other "user" entries in the file except for this one.) Reran setup and was able to get the past the issue with the influxdb powerwall database.
10 minutes in, I am monitoring the Powerwall Power Flow dashboard and only see Weather reporting in so far. All other graphs are currently showing "No Data." I will give it more time.
I'll also type up my steps i took to get this installed later this evening.
Thanks!
Thanks @panderson87 !
error loading config file /etc/telegraf/telegraf.d/local.conf: open /etc/telegraf/telegraf.d/local.conf: permission denied
For anyone else who has that problem, it is an easy to fix with:
chmod 644 telegraf*
docker restart telegrafAll other graphs are currently showing "No Data." I will give it more time.
You should see data from telegraf immediately so this is not a good sign. Telegraf is likely still having an error. Check docker logs telegraf and if you see the permission denied issue, try the above steps.
If you look at the directory (ls -l telegraf*) it should look similar to this (notice -rw-r--r-- permissions):
Looks like plugin errors.
Ran the commands above just to double-checked permissions, and they look ok. Restarted container but not working still
The errors indicate that pypowerwall is not running correctly (see what docker logs pypowerwall show).
Also, did you start the containers using ./compose-dash.sh up -d? I ask because docker-compose needs to build the networking to allow the containers to talk to each other. Restart would be:
./compose-dash.sh down
./compose-dash.sh up -dSorry, I restarted the containers all manually from the Docker Gui in Synology. Just rerun the commands in ssh and issue persists.
In checking the pypowerwall logs it looks like a login issue and/or network issue. it's currently on wifi and it tends to drop off the network even though the AP is literally on the other side of the wall, i should get it hardwired.
Receiving this message when trying to log into the powerwall as a customer.
Error: API Limit Reached (Api Limit reached for this endpoint).
Here were the logs but I'm sure the API limit is the issue.
pypowerwall.txt
are you sure you don't have an authorization issue ? you should be seeing data immediately once grafana is running. did you use the last 5 digits from your tesla gateway and not the whole password ?
are you sure you don't have an authorization issue ? you should be seeing data immediately once grafana is running. did you use the last 5 digits from your tesla gateway and not the whole password ?
Yes, I am positive but will need to double-check that I don't have a typo. I changed the default password and have been using HomeAssistant to tap into the solar/powerwall's production data Energy.
@dsf01 Yes, same issue here. Either the page does not respond, which a handful of mesh reboots will fix that, or now in this case, I'm getting the API limit error. I wonder if the HomeAssistant integration is having something to do with it.
@panderson87 - Your powerwall dropping off wifi may be an ARP problem - more specifically, the powerwall may still be on the network, but ignoring ARP requests.
For me the symptoms were:
- I could access the powerwall web interface immediately after rebooting my router.
- After a couple of hours, it disappeared from the network, and I had to use the app to "reconnect" to the wifi.
- Powerwall-Dashboard worked fine until the server machine needed a reboot, after which it lost the powerwall data feed.
If your problem is similar, you could try adding a static ARP entry - worked like magic for me (and saved several hundred dollars for the hard wiring).
Does sound like my issue (I also tried the 2.4GHz trick without success) - if the static ARP works, I've got a couple of cheat sheets for permanent static ARPs for windows and systemd setups. Let me know if you want either of them.
Congrats on getting it to work @panderson87 !
It did end up being the wrong password, somehow it got reset back to default!
I've seen that before. I don't know what triggers it, but have seen firmware updates reset the password in the past. The "Error: API Limit Reached" is the result of multiple bad password attempts.
On the WiFi conversation, I gave up on that after always getting drop-outs (even though it would reconnect after 5-10m) and just ran a hardware. Zero issues for past year because of that. But any WiFI pro tips @BuongiornoTexas would be great for our community. :)
I had a thought... while the issues seem to be more prevalent for Synology users, we seem to have an increasing number of users having setup problems. Most are related to some odd file ownership or permission setting (or even auth issue like this one for @panderson87 ). We spend a lot of time going back and forth doing basic troubleshooting steps to see what part of the stack isn't working correctly. It would be super amazing if we had a simple verify.sh (or troubleshoot.sh) script that basically tests all of the components for health and reports exactly which parts of the stack are working correctly or where it sees errors. I may take a stab at it today if I have time. I feel like it would help users find problems and get their setup working faster.
But any WiFI pro tips @BuongiornoTexas would be great for our community. :)
Well, I did the ARP fixes around December 2022 and haven't had any issues since, so it definitely worked for my problem. @jasonacox, your issues sounds a little different - the failure to respond to ARP takes a bit longer than 5-10 minutes to appear.
I'm going to save myself a bit of time - here is the write up I did for whirlpool. https://whrl.pl/RgxRzh
Here are the steps that I took to get this working on my NAS. I'm a github and noob so sorry if the formatting is not correct.
Make sure Docker has been installed in Package Center and SSH is enabled in Terminal & SNMP on your Synology NAS
- On Synology NAS, in Control Panel>Shared Folder> Create a shared folder named powerwall
- On Synology NAS, in Control Panel>User & Groups, select your user and edit. Under Permissions, make sure your user has read/write permissions to the powerwall share you created.
- On your computer, from a browser, navigate to https://github.com/jasonacox/Powerwall-Dashboard.git
- Download zip file and extract source code.
- From your computer, in Windows Explorer, navigate to \YourNasIP\powerwall then copy and paste the extracted source code into the powerwall share. Confirm both files AND folders are there.
- Use your favorite SSH tool and log in to your NAS (I used Putty) and log in as your install user (not root.) type in “id” and press enter to find your uid and gid.
Back on your NAS, edit the powerwall.yml file located in the powerwall share. Find all lines that say:
user: "1000:1000"
and replace with your uid and gid and save.
In my case, mine now says user: "1026:101"
I changed this for pypowerwall, telegraf, Grafana, and weather411. - Back in SSH navigate to the Powerwall share where the source code is extracted to and run the command ./setup.sh and follow the steps in the interactive setup.
If the setup does not run due to docker errors, refer to https://github.com/jasonacox/Powerwall-Dashboard#docker-errors
Wow! Thanks @panderson87 !
In my case, in addition to the steps regarding file ownership of docker and the usergroup settings mentioned in this post, I've only changed the user setting for grafana in compose.env. I did not need to change the user settings for all other containers, i.e. pypowerwall, telegraf and weather411. Don't know if it is important, just thought I should mention it.
Thanks @jaydkay - I'll keep this open to remind me to combine this insight into a guidance doc and FAQ for Synology users (unless someone else is willing to do that and submit a PR 😉 ).
I did not need to change the user settings for all other containers, i.e. pypowerwall, telegraf and weather411
Correct, they only read from the file system so as long as their user has read permission, it will work. Grafana needs to write to disk for its settings.
I got this working following this comment by @jaydkay, but I wanted to clarify how to update the user in case it'll help someone else. After ssh'ing into the Synology NAS and running id, you will see this:
uid=1026(Daniel) gid=100(users) groups=100(users),101(administrators),65538(docker)
Open powerwall.yml and change every place where user: appears to the uid and group of your user, e.g. user: "1026:1026". There should be 4 places: under pypowerwall, telegraf, grafana, and weather411. The grafana entry will be user: "${GRAFANAUSER}", but just change it to user: "1026:1026". Of course, use the your own uid, not mine :).
Thank you, Daniel!