Update tesla-history with retry handling on errors

[mcbirse]

Hi Jason,

This PR includes various updates for the Tesla-History script and Docker Compose environment. Currently for the Solar-Only Dashboard #183 but with plans to migrate into the main project all going well.

I have not committed my own changes or merged this PR as the new tesla-history script will need to be pushed to the Docker Hub account please when you can.

Updates and improvements to tesla-history script:

• add retry handling on errors, which should resolve issues noted by @youzer-name in #356
• add signal handler to exit gracefully on SIGTERM, similar to #353 noted by @rcasta74
• always set config/variables from environment if defined (instead of just when in daemon mode)
• the "--remove" option no longer requires login to Tesla account to be used
• update setup script to always restart tesla-history container, since existing config could be modified when re-running setup
• change to Dockerfile to fix issue with missing build dependencies (i.e. gcc) when building & pushing container to Docker Hub

Docker Compose config changes:

• Update powerwall.yml to use variables for "user" and "ports" in containers, per #357 and #360 noted by @hulkster
• Updated compose.env.sample with explanation of latest supported options
• Proposing change to powerwall.yml to use "unless-stopped" as the default restart policy for containers going forward (testing/research shows this may be a better choice, happy to discuss/explain my reasoning)

@jasonacox - Please push the latest tesla-history script to Docker Hub by running upload.sh

Please note, I struck some issues while testing this in my dev environment.

First issue - my docker buildx environment no longer worked for some reason (something broken with latest buildx failing with cgroup errors).

I found a workaround which was to install a different buildx driver, as below:

# Install fixed buildx instance using rootless driver image
docker buildx create --name fixed_builder --driver-opt 'image=moby/buildkit:v0.12.1-rootless' --bootstrap --use

I'm not sure if you will need to do the same for your environment.

Second issue - note the "RUN" command in Dockerfile has been been updated.

The build was failing due a dependency requiring gcc to be built. I found a nice solution which was to install alpine linux's "build-base" package (includes gcc) before running "pip install", and then it deletes the package afterwards, which keeps the container size small. Works a charm.

Please note this PR is the first with some more to come. I am working on merging the entire solar-only offshoot into the main project.

I have some preliminary changes in the works, with a more modular approach to how we handle the required docker containers, which will be determined during the setup/install process based on the user choosing a configuration option (default or solar-only).

The containers which will be installed/run are then defined by using the profiles feature of Docker Compose. Testing so far looks promising, but this is still a work in progress at the moment.

[hulkster]

Thanks for all your work @mcbirse

I'm wondering if maybe worth adding a comment in compose.env.sample along the lines of: "Setting IP to 127.0.0.1 (or ::1 for IPV6) will prevent these services from being exposed outside of your local machine" This makes it a little more clear what you can use that for and why.

[jasonacox]

I'm wondering if maybe worth adding a comment in compose.env.sample along the lines of: "Setting IP to 127.0.0.1 (or ::1 for IPV6) will prevent these services from being exposed outside of your local machine" This makes it a little more clear what you can use that for and why.

Perhaps list an example? e.g.

# Use 127.0.0.1 (or ::1 for IPV6) to prevent services from being exposed outside of 
# your local machine - ex. INFLUXDB_PORTS="127.0.0.1:8086:8086"

[mcbirse]

I'm wondering if maybe worth adding a comment in compose.env.sample along the lines of: "Setting IP to 127.0.0.1 (or ::1 for IPV6) will prevent these services from being exposed outside of your local machine" This makes it a little more clear what you can use that for and why.

Perhaps list an example? e.g.

# Use 127.0.0.1 (or ::1 for IPV6) to prevent services from being exposed outside of 
# your local machine - ex. INFLUXDB_PORTS="127.0.0.1:8086:8086"

Great suggestion @hulkster and @jasonacox - I have updated the compose.env.sample file and added the example.

[jasonacox]

@mcbirse - Build and Push jasonacox/tesla-history to DockerHub

Version: 0.1.3

• VERIFY jasonacox/tesla-history:latest Platform: linux/amd64 Platform: linux/arm64 Platform: linux/arm/v7

• VERIFY jasonacox/tesla-history:0.1.3 Platform: linux/amd64 Platform: linux/arm64 Platform: linux/arm/v7

Thanks @mcbirse !

[mcbirse]

Thanks Jason!