jasonacox / powerwall-dashboard Goto Github PK

The latest Powerwall upgrade (22.26.1-foxtrot 4d562eaf) may have resulted in the animation to stop/flash and may require pypowerwall to be restarted:

# restart pypowerwall
docker restart pypowerwall

It also renders something different. It now has a "compliance" text link in the graphic:

An issue has been opened to see if this can be addressed in the pyPowerwall Proxy: jasonacox/pypowerwall#24

What's the best way to change the settings for cost savings? I buy energy at ~$0.12 and sell it back at ~$0.05.

I noticed today that the tesla imbedded powerflow grid was showing 51% full on backup battery and when I switched to the powerwall default panel with the gradient powerwall the backup battery was reading 48%. I have 3 powerwalls and I was not sure if the value provided by pypowerwall was 1 specific battery or an average of all of them. Is there any reason why the numbers would be different?

Upgraded using upgrade.sh. It failed, had to run it again and then weather.sh and tz.sh. Imported new animation dashboard, not seeing it. Downloaded dashboard from repository and imported it same result

Been running this setup for 5 days now and i noticed my solar saving values and self powered values being zero or negative in the savings graph.

Not sure if a bug or a configuration error

Hi-

The new version of Powerwall-Dashboard isn't working properly for me and telegraf has a bunch of these errors. Pypowerwall looks to be working correctly.

2022-04-19T14:29:30Z E! [inputs.http] Error in plugin: [url=http://pypowerwall:8675/freq]: invalid character 'E' looking for beginning of value

2022-04-19T14:29:35Z E! [inputs.http] Error in plugin: [url=http://pypowerwall:8675/freq]: invalid character 'E' looking for beginning of value

2022-04-19T14:29:35Z E! [inputs.http] Error in plugin: [url=http://pypowerwall:8675/temps/pw]: invalid character 'E' looking for beginning of value

In Grafana, would it be possible to add a panel that would look at historic maximums? This would be very useful for monitoring system performance over time.

Like a table that would show the date and time of the max production of each string in the last 12 months and then also show the date and time of the max production of each string for all time.

Maybe just a misunderstanding on my part, but I am not understanding how this chart works:

Does this use the TOU rates that I have loaded in the Tesla app? Why does the combined value exceed the sum of solar and battery?

I am very unfamiliar with Docker. Is there a folder I can backup periodically that would basically contain the entire working system and database? This way I could restore to a new system if needed down the road.

@jasonacox, this issue may just be my inexperience with git, but I can't figure out how to test the upgrade.sh script without changing the hard coded path to the master repo, and even then, I have no idea how to make this work from a branch I'm testing (i.e. how can I force the upgrade to pull updated files from the branch I'm testing rather than the master?).

This is in relation to updates from #96. If there is no obvious short term fix, I will raise the PR without testing upgrade.sh and will highlight that in the commit notes - there are relatively few changes and it should be straightforward to review these.

On a related note - the upgrade.sh script runs a git stash before doing a rebase pull, but never refers to the stashed elements again. Is this deliberate?

Open issue for Greg Rhan

Thanks for putting together your [Powerwall Monitor] - looks great!
I'm trying to get it set up and it looks like your pypowerwall container may not be built for arm (I'm on a M1 Mac and Raspberry Pi v3b+). Any chance you could update the docker image to support linux/arm64 & linux/arm/v7 in addition to amd64? Thanks in advance.

From my Pi
$ docker logs pypowerwall
standard_init_linux.go:228: exec user process caused: exec format error
standard_init_linux.go:228: exec user process caused: exec format error
standard_init_linux.go:228: exec user process caused: exec format error

From my M1 Mac

From: #54 and #55

Python Error for pyPowerwall

Running setup.sh on a Raspberry Pi running Raspbian GNU/Linux 10 (buster) works successfully but the pypowerwall container fails to start. Running docker logs pypowerwall shows errors in the log:

Current thread 0xb6f3c390 (most recent call first): <no Python frame> 
Fatal Python error: pyinit_main: can't initialize time 
Python runtime state: core initialized 
PermissionError: [Errno 1] Operation not permitted

The Cause

This is caused by a bug in libseccomp2 related to docker container images based on Ubuntu and Alpine. The container for pypowerwall used an Alpine Python 3.8 container base.

This error shows up for several python projects using docker running on Raspbian Buster (as I discovered via a google search). See https://blog.samcater.com/fix-workaround-rpi4-docker-libseccomp2-docker-20/ and also https://docs.linuxserver.io/faq in section "My host is incompatible with images based on Ubuntu Focal and Alpine 3.13 and later. This only affects 32 bit installs of distros based on Debian Buster."

The Fix

Obviously, the first fix would be to upgrade your OS to the latest Raspbian (bullseye) but I understand that may not be possible and is a bit involved.

There are several other ways to get the fixed libseccomp2 installed. The best approach seems to be using the backports (where the libseccomp2 code is backported to legacy OS versions like Buster):

# Get signing keys to verify the new packages
sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 04EE7237B7D453EC 648ACFD622F3D138

# Add the Buster backport repository to apt sources.list
echo 'deb http://httpredir.debian.org/debian buster-backports main contrib non-free' | sudo tee -a /etc/apt/sources.list.d/debian-backports.list

sudo apt update
sudo apt install libseccomp2 -t buster-backports

# I recommend you restart and see if that corrects the problem

If the above didn't work, there is a brute force way to get the libseccomp2 upgrade from debian.

wget http://ftp.us.debian.org/debian/pool/main/libs/libseccomp/libseccomp2_2.4.4-1~bpo10+1_armhf.deb
sudo dpkg -i libseccomp2_2.4.4-1~bpo10+1_armhf.deb

Attempting to upgrade to version 2.6.2 everything upgraded except for Grafana.env error "cp: cannot create regular file 'grafana.env': Permission denied"

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

Somehow the database occasionally records some time entries where all the data fields are 0 / NULL. (Perhaps from network or API timeouts?)
Can the default dashboards filter these out so they are ignored/omitted in the graphs?
If not, any suggestions on how to manually modify the database?

I had good feedback from a reddit thread to add Powerwall Charge metrics and a graph to monitor the degradation of the Powerwall capacity over time. I have updated the project to now include this for the dashboard-animation.json dashboard. It would be easy to port this to the other dashboards or your custom dashboard by copying the panel JSON.

To upgrade, you will need to upgrade the telegraf config and add a downsampling job to influxdb. The upgrade.sh script will do most of this for you but older upgrade.sh did not include a telegraf upgrade so follow the steps below. It's always a good idea to backup your setup before changing.

# remove existing telegraf config
docker stop telegraf
docker rm telegraf

# upgrade setup
bash upgrade.sh

I am currently using the backup script I am using the default 5 days however i've noticed that the backup has stopped deleting the older versions. Let me know what details you need and I can provide it to assist with troubleshooting.

From vatxag8 on Reddit

It took me a bit to get the dashboard working as I had to search for instructions on resetting the powerwall password as the passwords on the stickers in the powerwall+ weren't working. It could be useful to others to add instructions on how to set/change the PW email/password in your readme file.

Otherwise it's awesome and I can't wait to watch all the graphs! Thanks for making that available to the masses!

Firstly @jasonacox great project! I have been running the Powerwall-Dashboard for a month now and it's fantastic.

I have also been using a shell script I had written for about a year to monitor my Powerwall and send e-mail alerts based on various events (e.g. grid outage, firmware updated, etc.). I had been thinking about modifying it to log additional data until I found this - thanks! I may change to Grafana e-mail alerts since I notice the grafana.env has been externalized now which is nice... however not sure about alerts on firmware updates though, so for the moment my shell script is still handy too... 😊

Anyway, back on topic. I have noticed what appears to be an issue with the Current State panel in the dashboards?

If you change the time range selection in Grafana to, for instance "Yesterday", then the Current State panel will show data based on the last value of that time range, and not the "Current State".

I assume the intention with the Current State panel would be to always show what is happening right now, regardless of the time range selected?

If so, I think the select query needs to be modified so it does not end with the standard WHERE $timeFilter

I have corrected this in my dashboard by manually editing the query in text edit mode, and changing it to WHERE time >= now() - 30s like below:

SELECT last("load_instant_power")  / 1000 AS "Home", last("solar_instant_power")  / 1000 AS "Solar", last("battery_instant_power")  / 1000 AS "Battery", last("site_instant_power")  / 1000 AS "Grid" FROM "raw"."http" WHERE time >= now() - 30s

So the query would only ever return the last 30 seconds of data, regardless of the time range selected.

CAUTION: I noticed a bug(?) in Grafana - if you click the pencil icon again to exit text edit mode, the where clause will get replaced by WHERE $timeFilter again, so it should be left in text edit mode to save correctly.

I also noticed sometimes my Current State data for Battery or Grid was sometimes showing "No data" when I was not using any battery or grid power.

This is displayed when null data is returned, however when checking the values returned they appeared to be "0" - not null? I wasn't sure how to fix this and ended up changing the "Null Handling" to simply show the "Idle" text and colour format instead - is there a better way to fix this perhaps?

Isn't this going to force the timezone to LA instead of pulling from the environment variables?

Delete: echo "PW_TIMEZONE=${TZ}" >> ${ENV_FILE}
Add: echo "PW_TIMEZONE=America/Los_Angeles" >> ${ENV_FILE}

Hi
setup.sh seemed to work fine while installing on a RPi4; however, when I pull up Powerwall Power Flow dashboard, the Power Flow window shows "Unable to connect" to localhost:8675. If I point a browser to that port, I get a similar message about site can't be reached.
Any suggestions? Note, my powerwall+ and solar was just installed, but the inverter has some issues and so the system is in standby as they try to troubleshoot that. However, if I log into the gateway it shows the Tesla graphic with power being supplied by the grid. So that's working.
Thanks!

These errors happened for several hours and then resolved on their own. Any ideas?

2022-05-24T15:10:54Z E! [inputs.http] Error in plugin: [url=http://pypowerwall:8675/aggregates]: Get "http://pypowerwall:8675/aggregates": context deadline exceeded (Client.Timeout exceeded while awaiting headers)

2022-05-24T15:10:54Z E! [inputs.http] Error in plugin: [url=http://pypowerwall:8675/freq]: Get "http://pypowerwall:8675/freq": context deadline exceeded (Client.Timeout exceeded while awaiting headers)

2022-05-24T15:10:54Z E! [inputs.http] Error in plugin: [url=http://pypowerwall:8675/temps/pw]: Get "http://pypowerwall:8675/temps/pw": context deadline exceeded (Client.Timeout exceeded while awaiting headers)

2022-05-24T15:10:54Z E! [inputs.http] Error in plugin: [url=http://pypowerwall:8675/soe]: Get "http://pypowerwall:8675/soe": context deadline exceeded (Client.Timeout exceeded while awaiting headers)

2022-05-24T15:10:54Z E! [inputs.http] Error in plugin: [url=http://pypowerwall:8675/strings]: Get "http://pypowerwall:8675/strings": context deadline exceeded (Client.Timeout exceeded while awaiting headers)

2022-05-24T15:10:59Z E! [inputs.http] Error in plugin: [url=http://pypowerwall:8675/strings]: Get "http://pypowerwall:8675/strings": context deadline exceeded (Client.Timeout exceeded while awaiting headers)

2022-05-24T15:10:59Z E! [inputs.http] Error in plugin: [url=http://pypowerwall:8675/freq]: Get "http://pypowerwall:8675/freq": context deadline exceeded (Client.Timeout exceeded while awaiting headers)

2022-05-24T15:10:59Z E! [inputs.http] Error in plugin: [url=http://pypowerwall:8675/aggregates]: Get "http://pypowerwall:8675/aggregates": context deadline exceeded (Client.Timeout exceeded while awaiting headers)

2022-05-24T15:10:59Z E! [inputs.http] Error in plugin: [url=http://pypowerwall:8675/soe]: Get "http://pypowerwall:8675/soe": context deadline exceeded (Client.Timeout exceeded while awaiting headers)

2022-05-24T15:10:59Z E! [inputs.http] Error in plugin: [url=http://pypowerwall:8675/temps/pw]: Get "http://pypowerwall:8675/temps/pw": context deadline exceeded (Client.Timeout exceeded while awaiting headers)

2022-05-24T15:11:00Z E! [inputs.http] Error in plugin: [url=http://pypowerwall:8675/aggregates]: Get "http://pypowerwall:8675/aggregates": EOF

2022-05-24T15:11:00Z E! [inputs.http] Error in plugin: [url=http://pypowerwall:8675/soe]: Get "http://pypowerwall:8675/soe": EOF

2022-05-24T15:11:00Z E! [inputs.http] Error in plugin: [url=http://pypowerwall:8675/freq]: Get "http://pypowerwall:8675/freq": EOF

2022-05-24T15:11:00Z E! [inputs.http] Error in plugin: [url=http://pypowerwall:8675/temps/pw]: Get "http://pypowerwall:8675/temps/pw": EOF

2022-05-24T15:11:00Z E! [inputs.http] Error in plugin: [url=http://pypowerwall:8675/strings]: Get "http://pypowerwall:8675/strings": EOF

Hi @jasonacox,

I've just upgraded to the latest version via upgrade.sh and hit a couple of issues on the way - most of them due to modifying my own configuration and doing some preliminary development work. Based on these, I came up with a couple of very low priority quality of life enhancements. If you see value in any of these, I'm happy to work up PRs to gradually address them after I've got the first pass cumulative kWh PR in place.

• Could we add implement a user generated addition to telegraf.conf in setup and upgrade scripts - maybe appended from a telegraf.local file, which I think works OK with TOML? This would be helpful for maintaining personal customisations such as my three phase power monitoring, and may also be useful when developing new functionality.

• I was hit with my rootless docker and grafana permissions issue again. It would be good if we could customise powerwall.yml to replace the default user for grafana (maybe by environment variable)? This problem is mostly mine at the moment, but it'd be nice to sort out.

• Minor issue: Should there be a dashboard.json in both the root folder and in the dashboards folder? The one in the root folder has the latest changes to the temperature and sun and moon.

• Closed in latest update. Very minor issue: I got hit with a repeated UID error when importing the new dashboard json while keep the old dashboard in place for comparison. It may be worth changing the UID when new versions of the dashboard are released.

• Moved to new issue. On dashboards, I haven't had time to figure out library panels in detail, but maybe they can be used to provide clean up updates to small elements of the dashboard, and maybe allow easier roll-your-own dashboards?

• On to do list already I think the influxdb.sql import raised errors about CQs already existing - maybe these should be dropped before re-adding?

I'm trying out the new animation dashboard, but the Power Flow panel is just black. Is there something special needed to get this new dashboard working?

Everything else on the dashboard is working.

Ran both setup methods and getting an error with pypowerwall. System is Ubuntu 21.10. Hostname not set?

During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "server.py", line 66, in
pw = pypowerwall.Powerwall(host,password,email,timezone)
File "/usr/local/lib/python3.7/site-packages/pypowerwall/init.py", line 114, in init
self._get_session()
File "/usr/local/lib/python3.7/site-packages/pypowerwall/init.py", line 121, in _get_session
r = requests.post(url,data = pload, verify=False, timeout=self.timeout)
File "/usr/local/lib/python3.7/site-packages/requests/api.py", line 117, in post
return request('post', url, data=data, json=json, **kwargs)
File "/usr/local/lib/python3.7/site-packages/requests/api.py", line 61, in request
return session.request(method=method, url=url, **kwargs)
File "/usr/local/lib/python3.7/site-packages/requests/sessions.py", line 529, in request
resp = self.send(prep, **send_kwargs)
File "/usr/local/lib/python3.7/site-packages/requests/sessions.py", line 645, in send
r = adapter.send(request, **kwargs)
File "/usr/local/lib/python3.7/site-packages/requests/adapters.py", line 519, in send
raise ConnectionError(e, request=request)
requests.exceptions.ConnectionError: HTTPSConnectionPool(host='hostname', port=443): Max retries exceeded with url: /api/login/Basic (Caused by NewConnectionError('<urllib3.connection.HTTPSConnection object at 0x7fde0e77cad0>: Failed to establish a new connection: [Errno -3] Try again'))

running host os ubuntu 22.04 everything installed, working, docker, etc - setup script executes,
but gets stuck Running Docker-Compose...

pypowerwall is up-to-date
influxdb is up-to-date
grafana is up-to-date
weather411 is up-to-date
telegraf is up-to-date

Waiting for InfluxDB to start...
..........................................................................................................................................
It's still trying - after 24 hours I've blown the vm away and tried again, same issue ? might it be permissions ?

Some thoughts:

• Docker-compose is working fine, the step stage is to wait for InfluxDB to start.
• I recommend that you run docker logs influxdb to see what errors it is throwing.

I am noticing that string A is correctly scaled on the chart with the y-axis. It appears the other strings, although the values are right, plot out at a much higher wattage on the Y-Axis.

I will see if I can figure this one out on my own.

I had previously installed on an older RPi 2B and all was well. Purchased a new RPi 400 (solid purchase, btw) and set up everything the same way, but now only the Live Monitoring "Energy Usage" panel is showing data. InfluxDB appears to be functioning. Here's what I get for an error:
Invalid interval string, expecting a number followed by one of "Mwdhmsy"

The only difference I can think of was I was running a headless config before, and I'm running a desktop on the RPi 400.

I hadn't upgraded my setup since a much earlier version and found a few upgrade.sh issues.

Script should check for errors during steps, in my case I ran out of disk space during execution(good ole Rasp pi tiny SD cards), and the script just keeps executing after failures..oops.
You could use 'set -e' to error out on any failure, or just check return codes from critical steps.

Script should be made aware of old powerwall.yml user config prior to pypowerwall.env creation.
If the "pypowerwall.env" doesn't exist, it should check for the user environment settings already in the "powerwall.yml", and read the values to propagate them to the env file
Or, at a minimum, prompt for them to create the env file(clearly nicer to just pull them out of the yml).

BTW you might want to add a description in the readme of the various dashboards now that there are several options.

Enhancement: Temperature line on Live Monitoring graph

Temperature is extremely relevant to power usage if you have/use Air Conditioning. It would be great to see a line graph of that on the live monitoring graph as another data input.

Hi @jasonacox and others who may be interested,

I've been looking at the various kWh production and consumption metrics, and I think there may be value in moving to a new method for calculating these.

The current approach is to integrate instantaneous power values over intervals e.g. influxdb generates home load kWh data using integral(home)/1000/3600, and the grafana configuration uses similar queries for for kWh data.

As far as I can tell, the integrals are approximations of the cumulative data available in the following aggregate metering fields:

site_energy_exported
site_energy_imported
load_energy_imported 
load_energy_exported # Should be zero, but a misconfigured meter can result in load exports. Ask me how I know :-(
solar_energy_exported
solar_energy_imported # small values accumulate on this - I suspect from inverter start up and shut down
battery_energy_exported
battery_energy_imported

The advantage to using these measurements is that total power over any interval is the difference between the last reading in the interval and the last reading of the previous interval, or for a long interval, approximately the difference between the first and last reading in the interval - which is a radically simpler calculation than the integral (which also suffers numerical drift - see below) and appears to also be the same data source as the Tesla app (so it is easy to do reconciliation and debugging).

I've put together a proof of concept for the grafana power meters, where I've added a second reading based on differences from the cumulative data:

This was my consumption up to about 1:15pm today. My corresponding app readings were 7.5, 15.9, 5.5 (from solar abs and solar percentage), 1.4, 6.3 and 1.8. The close match between the app readings and the difference readings has been pretty consistent in my testing - differences appear to be tied to when the Tesla database updates (15min-ish) and possible small rounding errors.

The grafana queries for home usage by integral and difference look like:

Similar queries apply for the other meters. If you want to try it your self, the data will only go back three days as I'm taking values from the raw data set, which is only retained 3 days.

I'd like to propose switching to usage based on the cumulative data based on the following benefits:

• It aligns usage data with the Tesla app and the data reported from the gateway.
• It's much simpler to calculate power usage over an interval and over multiple intervals (use Difference() or Difference(Last()) queries.
• I think it may allow elimination of the hourly, daily and monthly cqs, as these can be rebuilt extremely quickly from the cumulative data.
• More efficient calculations - calculating production over a long period is the difference of two numbers rather the integral of many short periods (which induces the drift seen above).
• It is much more robust to downtime in the logging system - if your database is out for many hours or days, the cumulatives keep accumulating on the gateway and can be pulled in after the database comes back up (may result in odd reporting spikes, but totals remain correct).

If you think this is worth following up, I'm happy to take on the first pass PR - let me know what you think. If there is no interest, I'll let this drop, as I don't want to be maintaining a parallel fork.

One final thing to note - I'm not sure that it will be possible to preserve historical data. Assuming @mcbirse is successful with his historical import, this may not be an issue, and another alternative would be to export all data ahead of making changes, doing appropriate transforms and reimporting.

I am seeing the following errors in Telegraf log:

$ docker logs -f telegraf
2022-02-20T05:02:11Z I! Starting Telegraf 1.21.4
2022-02-20T05:02:11Z I! Using config file: /etc/telegraf/telegraf.conf
2022-02-20T05:02:11Z I! Loaded inputs: cpu disk diskio http kernel mem processes swap system
2022-02-20T05:02:11Z I! Loaded aggregators:
2022-02-20T05:02:11Z I! Loaded processors: date (2x)
2022-02-20T05:02:11Z I! Loaded outputs: influxdb
2022-02-20T05:02:11Z I! Tags enabled: host=telegraf
2022-02-20T05:02:11Z I! [agent] Config: Interval:5s, Quiet:false, Hostname:"telegraf", Flush Interval:10s
2022-02-20T05:02:11Z W! [outputs.influxdb] When writing to [http://influxdb:8086]: database "powerwall" creation failed: Post "http://influxdb:8086/query": dial tcp 172.22.0.2:8086: connect: connection refused
2022-02-20T05:02:21Z E! [outputs.influxdb] When writing to [http://influxdb:8086]: failed doing req: Post "http://influxdb:8086/write?db=powerwall&rp=raw": dial tcp 172.22.0.2:8086: connect: connection refused
2022-02-20T05:02:21Z E! [agent] Error writing to outputs.influxdb: could not write any address

However, I am seeing data getting updated in InfluxDB as well as in Grafana. The log above stops at that point and then does not move.

I see the following in the InfluxDB log and it keeps moving:

[httpd] 172.22.0.5 - - [20/Feb/2022:05:16:01 +0000] "POST /write?db=powerwall&rp=raw HTTP/1.1 " 204 0 "-" "Telegraf/1.21.4 Go/1.17.7" 31a367b2-920c-11ec-8172-0242ac160002 12960
[httpd] 172.22.0.5 - - [20/Feb/2022:05:16:11 +0000] "POST /write?db=powerwall&rp=raw HTTP/1.1 " 204 0 "-" "Telegraf/1.21.4 Go/1.17.7" 37999496-920c-11ec-8173-0242ac160002 25396
[httpd] 172.22.0.5 - - [20/Feb/2022:05:16:21 +0000] "POST /write?db=powerwall&rp=raw HTTP/1.1 " 204 0 "-" "Telegraf/1.21.4 Go/1.17.7" 3d8f7af5-920c-11ec-8174-

Similarly I see the following in the pypowerwall log:

172.22.0.5 - - [20/Feb/2022 05:17:10] "GET /aggregates HTTP/1.1" 200 -
172.22.0.5 - - [20/Feb/2022 05:17:10] "GET /soe HTTP/1.1" 200 -
172.22.0.5 - - [20/Feb/2022 05:17:10] "GET /strings HTTP/1.1" 200 -
DEBUG:Found 17 devices.

Not sure what is going on here.

Hi there,

Thanks for the great work with this package.
I wonder if it would be possible to upgrade it with a more recent Grafana version.
The docker file uses version v6.5.1 which is a fairly old one, the current major version is 9.

Cheers, Sebi

It would be nice to have some representation of the grid outage directly on the main energy usage graph to be able to quickly look at information during outage periods.

unable to populate the powerflow iframe.
note my install in non-standard. the docker pypowerwall.yml did not work for me (firewall and VLANs) so I installed each container manually in bridge mode, and edited the telegraf hostname to the ip of the influx and pypowerwall. everything is working except the iframe.

pypowerwall_ip:8675 shows the powerflow image
pypowerwall_ip:8675/stats = {"pypowerwall": "0.5.0 Proxy t16", "gets": 5554, "errors": 0, "timeout": 0, "uri"

can i get manual steps to getting the iframe working (ie: what do i need to modify to make it work, where to put my custom ip, etc)
thanks

This is a great project! I am using powerwall-dashboard in docker. It seems that I have gaps in my data.

Checking the logs from pypowerwall I see this...

Traceback (most recent call last): File "/usr/local/lib/python3.8/socketserver.py", line 683, in process_request_thread self.finish_request(request, client_address) File "/usr/local/lib/python3.8/socketserver.py", line 360, in finish_request self.RequestHandlerClass(request, client_address, self) File "/usr/local/lib/python3.8/socketserver.py", line 747, in __init__ self.handle() File "/usr/local/lib/python3.8/http/server.py", line 427, in handle self.handle_one_request() File "/usr/local/lib/python3.8/http/server.py", line 415, in handle_one_request ������� method() File "server.py", line 172, in do_GET vitals = pw.vitals() File "/usr/local/lib/python3.8/site-packages/pypowerwall/__init__.py", line 262, in vitals stream = self.poll('/api/devices/vitals') File "/usr/local/lib/python3.8/site-packages/pypowerwall/__init__.py", line 193, in poll payload = r.raw.data File "/usr/local/lib/python3.8/site-packages/urllib3/response.py", line 303, in data return self.read(cache_content=True) File "/usr/local/lib/python3.8/site-packages/urllib3/response.py", line 544, in read raise IncompleteRead(self._fp_bytes_read, self.length_remaining) File "/usr/local/lib/python3.8/contextlib.py", line 131, in __exit__ self.gen.throw(type, value, traceback) File "/usr/local/lib/python3.8/site-packages/urllib3/response.py", line 446, in _error_catcher raise ReadTimeoutError(self._pool, None, "Read timed out.") urllib3.exceptions.ReadTimeoutError: HTTPSConnectionPool(host='10.XX.XX.XX', port=443): Read timed out.

Looking at the doc from the pypowerwall do you think that turning on the proxy might solve this issue?

I found someone using a heatmap to chart solar data over time. Thought something like this would be a great addition to the dashboard.

https://enlighten.enphaseenergy.com/pv/public_systems/3J9a932010/overview

I have looked - but can't see anything, so forgive me...

I have a time of use tarrif so would like to be able to see cost of energy per day.
I'd obviously have to enter my peak and off peak pricing, and also my generation prices,

I run as much as possible off peak overnight, and hope to survive of solar and storage until the end of the day...

Here in the uk we are likely to experiment with incentives to not use power during the evening peak, so having the ability to have a few customisable TOU pricing windows would be helpful -

I noticed that upgrade.sh now includes a section for upgrading telegraf, but I'm wondering if it's missing something. I've run the newest upgrade.sh version and my telegraf is still on 1.22.0 when the latest is 1.22.4. Does the upgrade.sh script need something like this?

docker images | grep telegraf | awk '{print $3}' | xargs docker rmi -f

The panel size for the animation is causing the animation to scroll which can hide or clip the Solar generation data at the top:

I see that the alert tab shows up on the new grid status panel. How would one go about adding an alert tab to the powerwall percentage panel?

This morning I noticed my Powerflow animation is just flashing on the dashboard. I checked my firmware version, and it looks like I got updated to 22.18.6. Is anyone else noticing this issue?

Navigating to port 8675 shows the same behavior. The page just keeps reloading making the animation "flicker"

It seems the DB is populated from the time of install?
Any way to pull in all the history?

Hi @jasonacox,

not sure if this is an actual issue or if I just don't understand how the dashboard actually works: I installed and set up the dashboard the usual way via ./setup.sh. This included setting the correct timezone, Europe/Berlin in my case. I checked that tz.sh acually changed the timezone in the four referenced files.

But when I look at the values of the dashboard, e.g. Solar Energy and click on Edit, the TZ shown in the following settings menu fr this signal is America/Los Angeles. This is also true for every other value on the dashboard. This is not obvious from todays values, but correcting the timezone right inside the dashboard for every signal shown slightly changes the values e.g. for the bar graphs in the monthly analysis.

Is there some problem with the definition of the signals inside dashboard.json or is this working as intended?

This was so timely. I have 2 PW+ and just set up the dashboard last night. Originally I noticed that only one PW was supported and then magically support for additional PW appeared by the time I got to doing this. I had made local changes to add the CQ for additional strings but then discarded them once I saw this. I have A, B, A1, B1 strings active and showing nicely on the dashboard.

Oh, one more thing. The setup.sh failed for me when it tried to substitute the PW ip and password. Unfortunately I do not have the output of the script. I am running on RPI 4b+.

Also, I was previously running the mihailescu2m version and I was able to seamlessly migrate to this dashboard without losing my historic data.

Originally posted by @nhasan in #2 (comment)

** Message from @jaffro2k using Windows 11 **

Very impressed with this dashboard mate – its awesome.

Had a few challenges to get it all running as I’m not really a dev – more of a lifetime tweaker with a Wintel background but a bit of Un*x – and haven’t really dabbled in Docker before (but thought it might help others if you were interested):

• Installed Docker Windows
• Installed Git Windows

Ran the setup.sh under a bash shell – received an initial error:

Using Australia/Melbourne timezone...
-----------------------------------------
Running Docker-Compose...
Starting pypowerwall ...
Recreating influxdb  ...
Starting pypowerwall ... done
Recreating influxdb  ... done
Recreating telegraf  ...
Recreating grafana   ...
Recreating telegraf  ... done
Recreating grafana   ... done
-----------------------------------------
Waiting for InfluxDB to start...
. up!
Setup InfluxDB Data for Powerwall...
**the input device is not a TTY.  If you are using mintty, try prefixing the command with 'winpty'**

Used Notepad++ to edit the setup.sh file and add winpty to the docker exec line – then received this error:

Setup InfluxDB Data for Powerwall...
ERROR: open C:/Program Files/Git/var/lib/influxdb/influxdb.sql: no such file or directory

I got stuck here initially as for the life of me I couldn’t provide the correct path – but then thought I could run the command within the container itself – so started a CLI from the influxdb container in Docker Desktop – found the file in the correct path and run the influxdb command there.

And BINGO – started working.

My thoughts are that there is something to do with the path or winpty getting access to the container path correctly? Seems to prefix the Git path and fail. Could do a bit more troubleshooting but am enjoying the dashboard too much atm.

Anyway - thought this might help others if you wanted to put onto the page or you probably can fix up the setup script in 2 seconds anyway.

I've noticed what seems to be an issue with tagging of data by month/year, in that it seems to tag the data points in UTC regardless of the tz('your/timezone') used in the CQ query.

Here's an example, where you see the "month" tag of my data is changing month at 10am, since my timezone is +10 (at the moment) 😞

You can see the issue if you query the InfluxDB directly.

Three query examples below:

1. First showing query using time format in my timezone (for start of Sep, note month tag shows "Aug")
2. Second query is the same, but used time format in UTC and added tz() just to ensure same data is output
3. Third query shows data returned for time from 9:55am to 10:05 am - you can see this is where the month tag changes over to "Sep"

InfluxDB shell version: 1.8.10
> SELECT * FROM autogen.http WHERE time >= '2022-09-01T00:00:00+10:00' AND time <= '2022-09-01T00:05:00+10:00'
name: http
time                from_grid          from_pw            home               host month percentage         solar              to_grid            to_pw url year
----                ---------          -------            ----               ---- ----- ----------         -----              -------            ----- --- ----
1661954400000000000 7.636363636363637  316.3636363636364  318.34090909090907      Aug   56.326253953908726 -8.818181818181818 1.0909090909090908 0         2022
1661954460000000000 3.909090909090909  317.27272727272725 313.6818181818182       Aug   56.281066425666516 -8.909090909090908 7.909090909090909  0         2022
1661954520000000000 8.363636363636363  302.72727272727275 299.6818181818182       Aug   56.23587889742431  -8.727272727272727 2.272727272727273  0         2022
1661954580000000000 14.090909090909092 294.54545454545456 296.8863636363636       Aug   56.19069136918211  -8.818181818181818 1.9090909090909092 0         2022
1661954640000000000 9                  298.1818181818182  303.77272727272725      Aug   56.1455038409399   -8.636363636363637 2.5454545454545454 0         2022
1661954700000000000 9.818181818181818  300                299.52272727272725      Aug   56.09278505799066  -8.636363636363637 0.6363636363636364 0         2022
> SELECT * FROM autogen.http WHERE time >= '2022-08-31T14:00:00Z' AND time <= '2022-08-31T14:05:00Z' tz('Australia/Sydney')
name: http
time                from_grid          from_pw            home               host month percentage         solar              to_grid            to_pw url year
----                ---------          -------            ----               ---- ----- ----------         -----              -------            ----- --- ----
1661954400000000000 7.636363636363637  316.3636363636364  318.34090909090907      Aug   56.326253953908726 -8.818181818181818 1.0909090909090908 0         2022
1661954460000000000 3.909090909090909  317.27272727272725 313.6818181818182       Aug   56.281066425666516 -8.909090909090908 7.909090909090909  0         2022
1661954520000000000 8.363636363636363  302.72727272727275 299.6818181818182       Aug   56.23587889742431  -8.727272727272727 2.272727272727273  0         2022
1661954580000000000 14.090909090909092 294.54545454545456 296.8863636363636       Aug   56.19069136918211  -8.818181818181818 1.9090909090909092 0         2022
1661954640000000000 9                  298.1818181818182  303.77272727272725      Aug   56.1455038409399   -8.636363636363637 2.5454545454545454 0         2022
1661954700000000000 9.818181818181818  300                299.52272727272725      Aug   56.09278505799066  -8.636363636363637 0.6363636363636364 0         2022
> SELECT * FROM autogen.http WHERE time >= '2022-09-01T09:55:00+10:00' AND time <= '2022-09-01T10:05:00+10:00'
name: http
time                from_grid          from_pw home               host month percentage        solar             to_grid            to_pw              url year
----                ---------          ------- ----               ---- ----- ----------        -----             -------            -----              --- ----
1661990100000000000 0.6363636363636364 0       392.74999999999983      Aug   65.5294472059045  5994              631.9090909090909  4960.909090909091      2022
1661990160000000000 0                  0       408.56818181818164      Aug   66.09429130893206 5899.909090909091 582.2727272727273  4904.545454545455      2022
1661990220000000000 2.272727272727273  0       372.4318181818182       Aug   66.58382286488929 6012.727272727273 1212.5454545454545 4420.909090909091      2022
1661990280000000000 0                  0       387.5681818181818       Aug   67.15619822262389 7179.272727272727 1797.3636363636363 4992.727272727273      2022
1661990340000000000 4.363636363636363  0       381.74999999999994      Aug   67.72857358035849 6794.363636363636 1478.8181818181818 4934.545454545455      2022
1661990400000000000 0                  0       387.1136363636362       Sep   68.28588642867902 6869.181818181818 1483.8181818181818 4992.727272727273      2022
1661990460000000000 2.5454545454545454 0       375.24999999999983      Sep   68.79048049405031 5788.454545454545 822.9090909090909  4585.454545454545      2022
1661990520000000000 5.909090909090909  0       389.9318181818181       Sep   69.33273083295677 5745.818181818182 814.1818181818181  4557.272727272727      2022
1661990580000000000 6.545454545454546  0       368.81818181818176      Sep   69.80719987949993 4919.727272727273 289.6363636363636  4255.454545454545      2022
1661990640000000000 9.909090909090908  0       369.70454545454544      Sep   70.2440126525079  3786.181818181818 9.545454545454545  3417.2727272727275     2022
1661990700000000000 5                  0       375.6590909090908       Sep   70.65070040668775 5927.909090909091 1192.2727272727273 4366.363636363636      2022

Because of this issue, grouping by month/year tags seems completely pointless and useless, unless you live in UTC timezone and do not have daylight savings!

Is anyone else seeing this issue, or is it just a problem with my setup/system?

I have done some further digging to understand where the month/year tags come from, and I think this is configured in telegraf.conf?

[[processors.date]]
	tag_key = "month"
	date_format = "Jan"

[[processors.date]]
	tag_key = "year"
	date_format = "2006"

Checking docs for telegraf, and I discovered the below:

Configuration

# Dates measurements, tags, and fields that pass through this filter.
[[processors.date]]
  ## New tag to create
  tag_key = "month"

  ## New field to create (cannot set both field_key and tag_key)
  # field_key = "month"

  ## Date format string, must be a representation of the Go "reference time"
  ## which is "Mon Jan 2 15:04:05 -0700 MST 2006".
  date_format = "Jan"

  ## If destination is a field, date format can also be one of
  ## "unix", "unix_ms", "unix_us", or "unix_ns", which will insert an integer field.
  # date_format = "unix"

  ## Offset duration added to the date string when writing the new tag.
  # date_offset = "0s"

  ## Timezone to use when creating the tag or field using a reference time
  ## string.  This can be set to one of "UTC", "Local", or to a location name
  ## in the IANA Time Zone database.
  ##   example: timezone = "America/Los_Angeles"
  # timezone = "UTC"

I wonder if this is the problem, and telegraf.conf should be including a timezone value in the [[processors.date]] section to ensure tags for month/year are localized?

This is a really neat tool. Thank you for making it. I received PTO last week and wanted to see more about how my system was setup. I have 2 powerwall+ each with a 7.6kW inverter. I have three arrays and three strings. I am supposed to have a 12.4kW system but I have not seen more than 8kW yet.

The problem I am seeing is that if I add the power value for string A and string B I get 5,091W. But my system shows that it is generating 6.09kW on the dashboard and in the app. I am pretty sure the dashboard is not pulling data for my third string. Is this something I need to fix in a config file?

This is an enhancement proposal to allow for community developed dashboards and panels to be available in an easy to browse and use way.

Objectives (please comment):

• Project will always default to a main default dashboard and panels (dashboard.json)
• Community contributed options will be in /dashboards "marketplace" with images and instructions for users to browse, download and install
• Easy to follow (and simple) instructions and process to use dashboards and panels

Reference: #96 @BuongiornoTexas @youzer-name

Node Red JSON. Adapted from original here: https://forum.pvoutput.org/t/nodered-home-assistant-uploader/2472

[{"id":"24befeed.0cb5f2","type":"tab","label":"pvoutput","disabled":false,"info":""},{"id":"ab922e29.c77f7","type":"api-current-state","z":"24befeed.0cb5f2","name":"Daily Solar (Watt hours)","server":"cbbf6ce3.4f5eb","version":3,"outputs":1,"halt_if":"","halt_if_type":"str","halt_if_compare":"is","entity_id":"sensor.pvoutput_daily_solar_energy_wh_v1","state_type":"str","blockInputOverrides":false,"outputProperties":[{"property":"payload","propertyType":"msg","value":"","valueType":"entityState"}],"for":0,"forType":"num","forUnits":"minutes","x":360,"y":130,"wires":[["eca1effa.95a05"]]},{"id":"48a83575.9c7a9c","type":"join","z":"24befeed.0cb5f2","name":"","mode":"custom","build":"object","property":"payload","propertyType":"msg","key":"topic","joiner":"\\n","joinerType":"str","accumulate":false,"timeout":"","count":"12","reduceRight":false,"reduceExp":"","reduceInit":"","reduceInitType":"num","reduceFixup":"","x":760,"y":50,"wires":[["99438705.c661e8"]]},{"id":"eca1effa.95a05","type":"change","z":"24befeed.0cb5f2","name":"V1","rules":[{"t":"set","p":"topic","pt":"msg","to":"v1","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":580,"y":130,"wires":[["48a83575.9c7a9c"]]},{"id":"17526967.a07137","type":"api-current-state","z":"24befeed.0cb5f2","name":"Total Solar Power (Watts)","server":"cbbf6ce3.4f5eb","version":3,"outputs":1,"halt_if":"","halt_if_type":"str","halt_if_compare":"is","entity_id":"sensor.pvoutput_solar_now_watts_v2","state_type":"str","blockInputOverrides":false,"outputProperties":[{"property":"payload","propertyType":"msg","value":"","valueType":"entityState"}],"for":0,"forType":"num","forUnits":"minutes","x":360,"y":180,"wires":[["21c59578.da1c0a"]]},{"id":"a50a6ebe.4e214","type":"api-current-state","z":"24befeed.0cb5f2","name":"Daily Consumed (Watt hours)","server":"cbbf6ce3.4f5eb","version":3,"outputs":1,"halt_if":"","halt_if_type":"str","halt_if_compare":"is","entity_id":"sensor.pvoutput_daily_load_energy_wh_v3","state_type":"str","blockInputOverrides":false,"outputProperties":[{"property":"payload","propertyType":"msg","value":"","valueType":"entityState"}],"for":0,"forType":"num","forUnits":"minutes","x":370,"y":230,"wires":[["6363034f.3ac2ec"]]},{"id":"f6d9d089.0c42d","type":"api-current-state","z":"24befeed.0cb5f2","name":"Consumed Power (Watts)","server":"cbbf6ce3.4f5eb","version":3,"outputs":1,"halt_if":"","halt_if_type":"str","halt_if_compare":"is","entity_id":"sensor.pvoutput_load_now_watts_v4","state_type":"str","blockInputOverrides":false,"outputProperties":[{"property":"payload","propertyType":"msg","value":"","valueType":"entityState"}],"for":0,"forType":"num","forUnits":"minutes","x":360,"y":280,"wires":[["853e698f.ac7f88"]]},{"id":"7fd1ce58.84e1a","type":"api-current-state","z":"24befeed.0cb5f2","name":"Temperature","server":"cbbf6ce3.4f5eb","version":3,"outputs":1,"halt_if":"","halt_if_type":"str","halt_if_compare":"is","entity_id":"sensor.weewx_out_temp","state_type":"str","blockInputOverrides":false,"outputProperties":[{"property":"payload","propertyType":"msg","value":"","valueType":"entityState"}],"for":0,"forType":"num","forUnits":"minutes","x":320,"y":330,"wires":[["5580eb68.666464"]]},{"id":"e5e9e6d9.dd8f38","type":"api-current-state","z":"24befeed.0cb5f2","name":"Battery Flow","server":"cbbf6ce3.4f5eb","version":3,"outputs":1,"halt_if":"","halt_if_type":"str","halt_if_compare":"is","entity_id":"sensor.pw_battery_now_watts","state_type":"str","blockInputOverrides":false,"outputProperties":[{"property":"payload","propertyType":"msg","value":"","valueType":"entityState"}],"for":0,"forType":"num","forUnits":"minutes","x":320,"y":380,"wires":[["4e6cb33e.56467c"]]},{"id":"21c59578.da1c0a","type":"change","z":"24befeed.0cb5f2","name":"V2","rules":[{"t":"set","p":"topic","pt":"msg","to":"v2","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":580,"y":180,"wires":[["48a83575.9c7a9c"]]},{"id":"6363034f.3ac2ec","type":"change","z":"24befeed.0cb5f2","name":"V3","rules":[{"t":"set","p":"topic","pt":"msg","to":"v3","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":580,"y":230,"wires":[["48a83575.9c7a9c"]]},{"id":"853e698f.ac7f88","type":"change","z":"24befeed.0cb5f2","name":"V4","rules":[{"t":"set","p":"topic","pt":"msg","to":"v4","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":580,"y":280,"wires":[["48a83575.9c7a9c"]]},{"id":"5580eb68.666464","type":"change","z":"24befeed.0cb5f2","name":"V5","rules":[{"t":"set","p":"topic","pt":"msg","to":"v5","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":580,"y":330,"wires":[["48a83575.9c7a9c"]]},{"id":"4e6cb33e.56467c","type":"change","z":"24befeed.0cb5f2","name":"V7","rules":[{"t":"set","p":"topic","pt":"msg","to":"v7","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":580,"y":380,"wires":[["48a83575.9c7a9c"]]},{"id":"99438705.c661e8","type":"function","z":"24befeed.0cb5f2","name":"Set API key here 1","func":"msg.action = msg.payload;\nmsg.headers = { \n 'X-Pvoutput-Apikey': 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx',\n 'X-Pvoutput-SystemId': 'xxxxx',\n 'Content-Type': 'application/x-www-form-urlencoded'\n};\n\nreturn msg;","outputs":1,"noerr":0,"initialize":"","finalize":"","libs":[],"x":840,"y":110,"wires":[["d19b860d.981778"]]},{"id":"d19b860d.981778","type":"function","z":"24befeed.0cb5f2","name":"Set up data","func":"msg.action = msg.payload;\n\nmsg.url = \"http://pvoutput.org/service/r2/addstatus.jsp\";\n\n\n\nreturn msg;\n\n","outputs":1,"noerr":0,"initialize":"","finalize":"","libs":[],"x":840,"y":160,"wires":[["172a0ac0.cd35c5"]]},{"id":"172a0ac0.cd35c5","type":"http request","z":"24befeed.0cb5f2","name":"Post","method":"POST","ret":"txt","paytoqs":"ignore","url":"","tls":"","persist":false,"proxy":"","authType":"","senderr":false,"x":820,"y":230,"wires":[["ea2bee87.e3fec"]]},{"id":"ea2bee87.e3fec","type":"debug","z":"24befeed.0cb5f2","name":"headercheck","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","targetType":"full","x":840,"y":300,"wires":[]},{"id":"cebb4284.5ca53","type":"moment","z":"24befeed.0cb5f2","name":"Date","topic":"d","input":"","inputType":"date","inTz":"America/Phoenix","adjAmount":0,"adjType":"days","adjDir":"add","format":"YYYYMMDD","locale":"en_US","output":"payload","outputType":"msg","outTz":"America/Phoenix","x":580,"y":50,"wires":[["48a83575.9c7a9c"]]},{"id":"82eeed4d.79b77","type":"moment","z":"24befeed.0cb5f2","name":"Time","topic":"t","input":"","inputType":"date","inTz":"America/Phoenix","adjAmount":0,"adjType":"days","adjDir":"add","format":"HH:mm","locale":"en_US","output":"payload","outputType":"msg","outTz":"America/Phoenix","x":580,"y":90,"wires":[["48a83575.9c7a9c"]]},{"id":"5c728c9391f35fc7","type":"change","z":"24befeed.0cb5f2","name":"V10","rules":[{"t":"set","p":"topic","pt":"msg","to":"v10","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":580,"y":530,"wires":[["48a83575.9c7a9c"]]},{"id":"dadd8e0b80625855","type":"api-current-state","z":"24befeed.0cb5f2","name":"Grid Flow","server":"ab5c60b7.4683c","version":3,"outputs":1,"halt_if":"","halt_if_type":"str","halt_if_compare":"is","entity_id":"sensor.pw_grid_now_watts","state_type":"str","blockInputOverrides":false,"outputProperties":[{"property":"payload","propertyType":"msg","value":"","valueType":"entityState"}],"for":"0","forType":"num","forUnits":"minutes","override_topic":false,"state_location":"payload","override_payload":"msg","entity_location":"data","override_data":"msg","x":310,"y":530,"wires":[["5c728c9391f35fc7"]]},{"id":"d755097002895038","type":"api-current-state","z":"24befeed.0cb5f2","name":"Battery Charge","server":"ab5c60b7.4683c","version":3,"outputs":1,"halt_if":"","halt_if_type":"str","halt_if_compare":"is","entity_id":"sensor.nr_pw_battery_adj_charge","state_type":"str","blockInputOverrides":false,"outputProperties":[{"property":"payload","propertyType":"msg","value":"","valueType":"entityState"}],"for":"0","forType":"num","forUnits":"minutes","override_topic":false,"state_location":"payload","override_payload":"msg","entity_location":"data","override_data":"msg","x":330,"y":480,"wires":[["d9d8d95b45d1ed96"]]},{"id":"d9d8d95b45d1ed96","type":"change","z":"24befeed.0cb5f2","name":"V9","rules":[{"t":"set","p":"topic","pt":"msg","to":"v9","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":580,"y":480,"wires":[["48a83575.9c7a9c"]]},{"id":"ee44f8ec9909a834","type":"cronplus","z":"24befeed.0cb5f2","name":"5 minute schedule","outputField":"payload","timeZone":"America/Phoenix","persistDynamic":false,"commandResponseMsgOutput":"output1","outputs":1,"options":[{"name":"schedule1","topic":"topic1","payloadType":"date","payload":"","expressionType":"cron","expression":"20 5,10,15,20,25,30,35,40,45,50,55,59 * * * *","location":"","offset":"0","solarType":"all","solarEvents":"sunrise,sunset"}],"x":140,"y":40,"wires":[["cebb4284.5ca53","82eeed4d.79b77","ab922e29.c77f7","17526967.a07137","a50a6ebe.4e214","f6d9d089.0c42d","7fd1ce58.84e1a","e5e9e6d9.dd8f38","d755097002895038","dadd8e0b80625855","7c1f84d1cfb8005b","5d6915d164e92aa8"]]},{"id":"7c1f84d1cfb8005b","type":"api-current-state","z":"24befeed.0cb5f2","name":"Home Load","server":"cbbf6ce3.4f5eb","version":3,"outputs":1,"halt_if":"","halt_if_type":"str","halt_if_compare":"is","entity_id":"sensor.pvoutput_load_now_watts_v4","state_type":"str","blockInputOverrides":false,"outputProperties":[{"property":"payload","propertyType":"msg","value":"","valueType":"entityState"}],"for":0,"forType":"num","forUnits":"minutes","x":320,"y":430,"wires":[["2534d64b99a4b06f"]]},{"id":"2534d64b99a4b06f","type":"change","z":"24befeed.0cb5f2","name":"V8","rules":[{"t":"set","p":"topic","pt":"msg","to":"v8","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":580,"y":430,"wires":[["48a83575.9c7a9c"]]},{"id":"5d6915d164e92aa8","type":"api-current-state","z":"24befeed.0cb5f2","name":"Solar Gen","server":"ab5c60b7.4683c","version":3,"outputs":1,"halt_if":"","halt_if_type":"str","halt_if_compare":"is","entity_id":"sensor.pvoutput_solar_now_watts_v2","state_type":"str","blockInputOverrides":false,"outputProperties":[{"property":"payload","propertyType":"msg","value":"","valueType":"entityState"}],"for":"0","forType":"num","forUnits":"minutes","override_topic":false,"state_location":"payload","override_payload":"msg","entity_location":"data","override_data":"msg","x":310,"y":580,"wires":[["da639c2d641674b1"]]},{"id":"da639c2d641674b1","type":"change","z":"24befeed.0cb5f2","name":"V12","rules":[{"t":"set","p":"topic","pt":"msg","to":"v12","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":580,"y":580,"wires":[["48a83575.9c7a9c"]]},{"id":"cbbf6ce3.4f5eb","type":"server","name":"Home Assistant","version":2,"rejectUnauthorizedCerts":true,"ha_boolean":"y|yes|true|on|home|open","connectionDelay":false,"cacheJson":true,"heartbeat":false,"heartbeatInterval":30},{"id":"ab5c60b7.4683c","type":"server","name":"Home Assistant","version":2,"addon":true,"rejectUnauthorizedCerts":true,"ha_boolean":"y|yes|true|on|home|open","connectionDelay":true,"cacheJson":true,"heartbeat":false,"heartbeatInterval":30}]