Special Considerations for Moving PD to another host?

[MattMake]

I tested this on one PC, and love it. I'm looking to move to a permanent micro-PC running ubuntu / docker, but wanted to know if there was anything specific I should look out for when moving the docker images. Thanks in advance!

[jasonacox]

Hi @MattMake, you can install using the setup.sh on your new host and then copy over the database. Something like this:

# on old host
cd Powerwall-Dashboard
# stop influxdb to ensure nothing is being written
docker stop influxdb
# create archive
sudo tar -zcvf snapshot.tgz influxdb 
# start influxdb back up
docker start influxdb
# copy snapshot.tgz to new host

# on new host - after setup, shut down stack
cd Powerwall-Dashboard
./compose-dash.sh stop
sudo tar -zxvf snapshot.tgz 
./compose-dash.sh up -d

[MattMake]

I found influxdb on the influxdb image, but there must be multiple. Total size of tar file was 4kb, which seems light for several months of data. Can you point me to the location for the influxdb file?

[jasonacox]

Hi @MattMake

The Powerwall-Dashboard directory is created when you first set up the dashboard (see setup https://github.com/jasonacox/Powerwall-Dashboard/tree/main#setup):

git clone https://github.com/jasonacox/Powerwall-Dashboard.git
cd Powerwall-Dashboard
./setup.sh

That contains the influxdb directory which houses the influxdb config and database. If you are trying to find the database files WITHIN the influxdb container itself, you would need to navigate to:

/var/lib/influxdb

This is because the local file systems is mapped as a volume into the container via the powerwall.yml compose file:

services:
    influxdb:
        image: influxdb:1.8
        container_name: influxdb
        hostname: influxdb
        restart: always
        volumes:
            - type: bind
              source: ./influxdb.conf
              target: /etc/influxdb/influxdb.conf
              read_only: true
            - type: bind
              source: ./influxdb
              target: /var/lib/influxdb
        ports:
            - target: 8086
              published: 8086
              mode: host

[MattMake]

Excellent, that was super helpful. I was able to find it and tar/export the file to usb stick. I'm not local to the new machine yet, but I'll give that a go soon. Thanks!

[MattMake]

That was perfect. Here's what I did:
In Windows Docker Desktop, I went to the influxdb image, terminal. As per your instructions, went to /var/lib and ran this:
tar -zcvf snapshot.tgz influxdb

Then I switched to PowerShell and ran this (to copy the file to host PC:
docker cp influxdb:/var/lib/snapshot.tgz c:\snapshot.tgz

Then I ran your original commands on the new ubuntu device after copying snapshot.tgz to the Powerwall-Dashboard directory:
cd Powerwall-Dashboard
./compose-dash.sh stop
sudo tar -zxvf snapshot.tgz
./compose-dash.sh up -d

All the prior data is now on the new box.

Much appreciated on the assist, and for this app. It's fantastic! I only wish Tesla had a way to pull string data from the Tesla Inverters (pre-PW+ inverters). Then it would be perfect!

[jasonacox]

Awesome! Thanks @MattMake ! 🙏

Agree on the string data request for pre-PW+ inverters. I know many have looked at this and it seems that this data is simply not being recorded or at least not made available for access. If anyone figures it out, let us know!

[MattMake]

I know this is a long-shot, but I was attempting to back up the influxdb and I think I overwrote it with a prior save. Any chance of this data in another location or restore from log file or something?

[MattMake]

Ok, looking at this closer, it seems to be a data issue. If I highlight the area that shows on the graph, it shows some outrageous numbers. I wish I could generate this much in a day. I'm thinking values are showing, but are too small to see in the graph?

Maybe I should purge all the data and re-import?

[mcbirse]

I have seen a similar issue happen once before for someone else, however we never worked out what caused it. There was an easy fix though in that case, that may also work for you.

Try the Fix Month Tags Tool and make sure to use the --rebuild option with that tool.

Although the tool was written for another purpose, it can still be used to correct data issues like this when using the --rebuild option (month tag issues shouldn't be a problem any more with new installs of Powerwall-Dashboard).

I added the rebuild option specifically to correct/rebuild the analysis data, which is where the issue is with your data.

Worth a try before going down the path of purging everything and re-importing.

[MattMake]

That sorted out the majority, but left a few gaps. They are not too bad, so I may just leave it. Thanks for the pointer!

[MattMake]

I identified the gaps, and re-ran the tesla-history tool to fill them. Have a nice, full graph now to look at in awe of :)

[hulkster]

[Moved comment here where the reply should have gone]

FYI FWIW @MattMake that I encountered what MAY have been a similar issue to yours ...

I did the restore of 30+ days from data from one machine to another. The backup/restore process is pretty straightforward (hats off to the developers) but I was confused why I had some missing days of data in the last week or so. After trying a couple of times, I wondered if it might be because I was doing it around Midnight (plus on the first of the Month) - i.e. perhaps some sort of time-zone sync issue despite it being configured identically the same on both.

I checked this morning and there was still the dropout ... so I did exactly the same restore this morning, using the same .tgz file that was created last night ... and BOOM ... everything is filled-in and they graphs look identical going back 30 days including weather data.

Seems strange, but just passing on in case others encounter this.

P.S. Since I'm "solar-only", in backup.sh, I set DASHBOARD="/home/user/Powerwall-Dashboard/tools/solar-only since influxdb under there (not the top-level) is where the data is stored.

I also needed to create /home/user/Powerwall-Dashboard/tools/solar-only/backups since that is where it tries to create the .tgz file. On the receiving end, I did a "cd /home/user/Powerwall-Dashboard/tools/solar-only/" and had to use sudo when I untarred it (as noted, you need to run backups.sh as root).

GREAT advice from @mcbirse - "Make sure to do a test restore after setting up your backups, to e.g. a fresh install of Powerwall-Dashboard on a different host. No point having backups unless you know they work and you can actually restore the system."

[hulkster]

Any chance you could share your backup cron script, maybe with some general instructions? I'd love to get an automated backup going, especially to save myself from myself.

Ditto here! ;-)

[mcbirse]

I'm just using the example backup script that Jason wrote - it works perfectly well for me.

You can find that in the backups folder of Powerwall-Dashboard, along with instructions.

All I've done to set this up on my system is basically copy the script, modify the paths, and add it to cron to run daily (NOTE: the script must be run as root, so should be added to cron of the root user).

Modify the script to set paths for your environment and your backup folder. I store my backups directly to a shared folder on my NAS.

Make sure to do a test restore after setting up your backups, to e.g. a fresh install of Powerwall-Dashboard on a different host. No point having backups unless you know they work and you can actually restore the system.