Need advice for monitoring solar + powerwall

Energy Monitors Powerwall
#1

i’ve got an existing solar plant which i’ve been monitoring with PVO for 5 years successfully.

the other day i added a couple of powerwalls. of course now the existing solar monitoring is really confused because there’s a source/sink of energy that’s not accounted for.

assuming i can grab the energy flow into/out of the battery, is there a way for me to integrate this info in my existing setup? the math would, i think, have to happen on PVO’s end since my monitor exports the solar production to PVO and separately an eagle 200 uploads the meter data. without locally capturing the eagle data i can’t compute the home load. is it possible for PVO to take into account battery flow on its own?

i know i can switch to the python script which uses the monitoring inside the powerwall to sort all this out, but then i lose a lot of stuff that the inverter can report (panel voltage, inverter temp, etc.)

alternately, is there a way to somehow add the inverter data of interest to a system based on the powerwall python script using a parent/child setup?

thanks for any ideas!

#2

and as a followup question, if i were to set my original system to “testing” and perhaps stopped pushing the eagle data there, then set the system i created to test the powerwall python uploader script as operational, could i have both systems running without screwing up global or personal statistics (meaning, would my generation be counted only once with one system in testing?)

that way i can still log/save the inverter data i want to keep around rather than trying to make a hybrid system.

#3

The battery information may be sent to an Extended Parameter (v7-v12) but there isn’t a way to use extended data to update standard generation/consumption (v2/v4)

The powerwall gateway should have generation, consumption load information. Your script can be modified to extract this information or use the PVOutput Integration Service

#4

Ladder statistics are associated with individual systems, if the original system stopped reporting and a new system created then original stats will not be carried over to the new system.

If you wish to retain old stats then create a new system for testing the powerwall, then once confirmed it is running correctly stop eagle reporting to the original ‘sid’ and point the powerwall uploads from the new sid to the old sid.

#5

thanks, that makes sense. i was hung up on all the extended data - on my old SID they mean things like inverter heatsink temp and mains frequency/voltage.so i’m not sure what happens if i suddenly start uploading what looks like nonsense. i’d have to change the extended data schema but then it would look like nonsense for dates prior to powerwall installation.

would this work? i modify my inverter upload script to not upload v2, turn off the eagle, and have the powerwall script only upload v2/v4 - both reporting to the old SID. the only problem i see here is that i am currently reporting cumulative v2 with my script and the powerwall script is reporting interval v2. will PVO be OK with the change from cumulative to interval?

if that works, i could run another instance of the powerwall python script which only reports the extended data to the new SID. is it OK for a system to only have extended data and no v2/v4 data?

i guess my original question boils down to: if i were to just turn off the eagle on the original SID and use a new SID for the powerwall incarnation of this system, is there a way to have PVO ignore the generation on the original SID? for instance if i set to “decommissioned” would PVO still let me upload generation and extended data to that system? i just didn’t want the generation to be counted twice.

probably the approach of continuing the original SID makes most sense, assuming the switch from cumulative to interval generation would be successful.

thanks,

rob

#6

ok i think i figured out the minimum change - i just turned off the eagle and started a new powerwall python script that only sends the “pvConsumption” value as v4 to the old SID. this is the value that the powerwall reports as “load power” averaged over 5 minutes. the original uploader continues to send the solar generation and other inverter data.

so as far as the 2nd system i created that has all the powerwall-related extended data - is it appropriate to just leave it in the “testing” state forever? i just want it to look at the extended data page from time to time. or should i remove the generation and import data from that one?

also, would it be OK to have the powerwall python script that reports into the old SID upload a little more frequently than every 5 minutes? i see some “holes” in the consumption data which i guess could be caused by samples that don’t fall exactly into a given 5-minute bucket on PVO.

#7

ok i settled on something:

  1. continue to report “virtual” grid load into the original system to keep all the history going.
  2. keep the “testing” system to show all the PW extended data
  3. add a consumption-only system and report the eagle data there.

#1 is great but it can’t accurately report the cost since PVO just has no idea when generation/load is sunk/sourced from the powerwall and what the cost of that electricity was. however, the cost reported on this system is what it would be without the powerwalls doing load shifting. i did also change the averaging and reporting interval to 2.5 minutes on this one to avoid the gaps.

#3 tells me what the cost is with the powerwall, since in theory it’s the same as what the utility is charging me. so then i can see on a daily basis how much money the PWs have saved me, which is another statistic i was after.

edit: looks like for the consumption only system i need to spoof generation in the amount of export to get the credits even though the model is set to gross…

#8

Cumulative v2 is v1, switching from v1 to v2 won’t make a difference, PVOutput will calculate the missing value from the uploaded value. If both are sent then both will be recorded and no calculation is made.

Its possible to upload extended data only, however the graph can’t be displayed since it currently relies on at least one of the (v1-v6) same timestamps to be available.

The workaround here is to send v4=0 along with the extended data.

The API won’t block uploads from being recorded based on the system status. The only way to stop this is to don’t upload.

Leaving it in ‘Testing’ state is fine, but see answer above on Extended Data without standard data, v4=0 should be sent for this to work.

Frequency doesn’t matter as long as it is within API rate limits from all upload sources. Timestamps are rounded to the nearest 5-minutes.

#9

thanks for all the help.

what i’ve done is to cons together my own python script to get the consumption from the eagle every 5 seconds, average it over 2.5 minutes, and then send the info to PVO. if the consumption is negative, this is reported as generation with 1W consumption. if the consumption is positive, it is reported as consumption with no generation sent at all. this lets me calculate how much money i’ve paid (or received from) PGE on a daily basis. the eagle is no longer reporting anywhere except rainforest’s own cloud system.

i guess my main question is, right now i’ve got 2 SIDs that contain the same generation and home consumption data, and a 3rd SID with “export-only” generation data. what i was wondering is if setting a system to “decommissioned” or “testing” would prevent those systems from appearing in your global generation/consumption statistics, or does it even matter to you? i just didn’t want to pollute the stats with 2.whatever x the actual data if possible.

#10

Decommissioned / Inactive systems will be hidden from some functions, but generally the statuses are for your own purposes.

1 Like