Best practice for monitoring multiple sites that are really one location

[dcgibbons]

Problem Description
My home has two electrical panels and two Tesla Backup Gateways, with 3 Powerwall 3 units split between them. The solar array is also likewise split. This seems to be the common installation pattern for homes with larger electrical loads.

Tesla support seems to be configuring this setup as two different Sites, even though they keep mentioning it should function as one. (Now that mine is fixed) I see two sites in mine, each with completely independent metrics.

For the dashboard, am I able to configure it so that there are two collection containers going into the same graphs (e.g. merging the two sites), or do I need to setup two different monitoring stacks - one for each stack?

[jasonacox]

Hi @dcgibbons - you'e not alone! Thanks for opening this.

Right now, you need two stacks. We are seeing more Tesla owners with this condition (either multiple sites or multiple gateways). I'll flag this as an enhancement for us to look at. In the meantime, you would have to set up two separate stack (if they are on the same box, you would need to change the ports) or if you are tech savvy enough, help us figure out a good way to combine them. :-)

[youzer-name]

Hi @dcgibbons - you'e not alone! Thanks for opening this.

Right now, you need two stacks. We are seeing more Tesla owners with this condition (either multiple sites or multiple gateways). I'll flag this as an enhancement for us to look at. In the meantime, you would have to set up two separate stack (if they are on the same box, you would need to change the ports) or if you are tech savvy enough, help us figure out a good way to combine them. :-)

@jasonacox, I was looking at the config files and trying to figure out how to do this, and here's a general outline of what I came up with as the easiest path to do it without needing multiple stacks (which still wouldn't solve the issue of viewing all the data at once)

• Use powerwall.extend.yml to add a second pypowerwall to the stack, call it "pypowerwall2", and a second telegraf to the stack, call it "telegraf2"
• Add a pypowerwall2.env file with the details of the second gateway
• In the extend file, set pypowerwall2 to use pypowerwall2.env
• Add a telegraf2.conf file, under output plugins set 'database="powerwall2"' and set the inputs.http URLs to "http://pypowerwall2..."

That should be all that's needed to get the data. I'm not sure how much you could automate that in the install script.

The bulk of the work is in modifying the dashboards to use both databases:

• In Grafana, add a data source for the powerwall2 database
• In Grafana, duplicate all of the relevant queries. Modify the copies to use the powerwall2 influxDB data source
• Totals can be displayed either by stacking data (i.e. stacking powerwall.solar and powerwall2.solar) or using Grafana expressions (adding query results like "$A + $B")
• Export the dashboard config as 'dashboard-dual-gateway.json and make it available to download

The bulk of the work here is in the initial Grafana dashboard setup and syncing future changes from the default dashboard.json to dashboard-dual-gateway.json. Since the rest of the customization is in the extend file and the new env/conf files, I don't think this would have much impact on anything else in the project.

[BuongiornoTexas]

here's a general outline of what I came up with as the easiest path to do it without needing multiple stack

• and a second telegraf to the stack, call it "telegraf2"

I'd agree you probably need an additional pypowerwall, but I think it should be possible to use a single telegraph instance to pull from two sites and use name overrides to distinguish them. (Arguably, you could extend pypowerwall to proxy both, but that sounds like a lot more work).

I take it when you are talking about both databases, you actually mean writing to a the same influxdb instance as used for the first powerwall site? (not so much databases as datasets within the database?). Otherwise aren't you proposing a parallel stack for each site/gateway with one grafana instance to visualise across the stacks?

The other comment I have about this is that some users might find scalabilty useful - e.g. in aged care facilities in the future my need to manage multiple gateway/solar/battery systems for their residents. I'm pretty sure neither tesla nor PWD are well adapted for this kind of scenario.

[dcgibbons]

I had success tonight by adding a 2nd pypowerwall container, and updating telegraf.conf to poll from both pypowerwall containers with different tags. By default, this seems to combine the raw data on the dashboard, which may or may not be what I'd want (sometimes yes, sometimes no). But at least now it should be configurable within grafana using tags in the queries.

The extra weird step I had to do was my Tesla Cloud config. After authorization, I copied .auth to .auth1 and .auth2 subdirectories, and made sure the Site ID inside of each directory was correct for which gateway I wanted to monitor. That's a bit hacky but it seems to work fine.

Snippet from my changed powerwall.yml:

    pypowerwall1:
        image: jasonacox/pypowerwall:0.7.12t44
        container_name: pypowerwall1
        hostname: pypowerwall1
        restart: unless-stopped
        volumes:
            - type: bind
              source: .auth1
              target: /app/.auth
        user: "${PWD_USER:-1000:1000}"
        ports:
            - "${PYPOWERWALL_PORTS:-8675:8675}"
        environment:
            - PW_AUTH_PATH=.auth
        env_file:
            - pypowerwall.env

    pypowerwall2:
        image: jasonacox/pypowerwall:0.7.12t44
        container_name: pypowerwall2
        hostname: pypowerwall2
        restart: unless-stopped
        volumes:
            - type: bind
              source: .auth2
              target: /app/.auth
        user: "${PWD_USER:-1000:1000}"
        ports:
            - "${PYPOWERWALL_PORTS:-8677:8675}"
        environment:
            - PW_AUTH_PATH=.auth
        env_file:
            - pypowerwall.env

And then a snippet from telegraf.conf:

[[inputs.http]]
        urls = [
                "http://pypowerwall1:8675/aggregates",
                "http://pypowerwall1:8675/soe",
                "http://pypowerwall1:8675/strings",
                "http://pypowerwall1:8675/temps/pw",
                "http://pypowerwall1:8675/freq",
                "http://pypowerwall1:8675/pod"
        ]
        method = "GET"
        insecure_skip_verify = true
        timeout = "4s"
        data_format = "json"
        [inputs.http.tags]
          influxdb_tag = "Powerwall_150"

[[inputs.http]]
        urls = [
                "http://pypowerwall2:8675/aggregates",
                "http://pypowerwall2:8675/soe",
                "http://pypowerwall2:8675/strings",
                "http://pypowerwall2:8675/temps/pw",
                "http://pypowerwall2:8675/freq",
                "http://pypowerwall2:8675/pod"
        ]
        method = "GET"
        insecure_skip_verify = true
        timeout = "4s"
        data_format = "json"
        [inputs.http.tags]
          influxdb_tag = "Powerwall_200"

I'm not 100% sure the influxdb_tag's are workin correctly just yet. I can see them in queries in grafana, but it isn't clear to me yet if the data points are tagged properly.

[youzer-name]

I take it when you are talking about both databases, you actually mean writing to a the same influxdb instance as used for the first powerwall site? (not so much databases as datasets within the database?). Otherwise aren't you proposing a parallel stack for each site/gateway with one grafana instance to visualise across the stacks?

Yes, I was talking about a second database in the same instance. I think databases is the correct term in InfluxDB terms. If you issued the command "show databases" you would see both powerwall and powerwall2 listed, so they are considered separate databases, each with their own retention policies, CQs, and measurements.

I hadn't considered putting everything in one database and using tags. That seems like an even cleaner solution. The hesitation I have is that InfluxDB and InfluxQL have so many weird limitations that the only way to be sure it will work is to update all of the visualizations to use tags and see if everything works as expected.