I am having an issue where after an aborted parent-child relationship configuration was backed out and both the 28621 and 111702 systems were returned to independent systems, the solar generation of the 111702 system is being copied into the 28621 consumption data during the day.
Could you please sever whatever backend links still connecting these systems somehow.
Thanks in advance
How is the data being sent to both systems, and has this setup changed since the aggregation configuration was made?
The data being sent to either system is independent of each other. I was mistaken that the Tesla_PW3 system generation was being copied into the SMA system.
What appears to be happening is that generation data for the SMA system is being copied into the consumption data.
Every thing was normal until I tried the parent-child aggregation setup but that failed and corrupted the Tesla_PW3 configuration. I backed out of the aggregation and set both systems back NONE in the aggregation mode. But the math being done in the backend servers did not destroy the formula set up for aggregation I assume.
The issue is just with the legacy 13 year old SMA site for the consumption data.
No changes have been made to the data inputs from the monitoring devices. Generation is still handled just by the SMA Webbox and consumption by the Eagle-200.
I have tried everything possible that I or AI could think of to try and return the system back to the stable configuration that existed up until the botched aggregation attempt.
SMA System SID: 28621
The 111702 system was assigned 28621 as the parent then removed shortly after on 2026-05-30
The configuration is now back to what it was before and the data from 111702 is not being aggregated to 28621
However, looking back before the change was made there are examples of your consumption mirroring generation -
e.g. https://pvoutput.org/intraday.jsp?id=31241&sid=28621&dt=20260520
The issue does not appear to be related to aggregation but the Eagle net data being sent.
Rainforest Automation Support emphatically tells me that the Eagle-200 can only send what the Smart Meter is reading which is NET data. I even had them add the &n=1 parameter to the PVO endpoint yesterday but it did not have any effect in todays’s data.
I never had this issue until I attempted the aggregation. Back when the Eagle-200 was supported by the Auto Uploaders, the site interface allowed one to set direction on the device. But now with only direct POST packets being sent, there is no option to change data direction.
But if you go further back in my account logs, before the Tesla system was installed you can see that the consumption graphs never overlaid the generation graphs. This effect only came into existence since the failed aggegation attempt.
Also, tell me whether in the Aggregation setting if once set, the parent names or child names are immutable in the dropdown list. Mine are. They never disappear from the dropdowns even when Aggegation Mode is set to NONE and SAVED.
AI tells me this:
“Hi @bankstownbloke – Bumping this as my system’s data remains broken. To clarify: This is not a user configuration issue. A failed data aggregation attempt between my legacy SMA system and a new Tesla system has left the system profile database schema corrupted. Even with aggregation set to NONE, the parent/child dropdowns remain cross-populated with independent system names. The account is stuck in a multi-system processing state, causing my live Eagle-200 API consumption to mirror my SMA FTP generation. Can you please manually flush/clear the parent/child and secondary system database flags for my account on the backend?”
This is what the SMA system used to show with the A/C running on top of my constant 6 kW baseload all day.
And here is further proof of the reality of the consumption data directly from the Eagle-200
Since I still don’t have PTO yet for the Tesla system, I am in No Export mode where no excess generation can be leaked to the grid. The Backup Switch can 100% curtail the Tesla system but has no control over the legacy system. So a few kWh can leak to the grid from the legacy systems.
This shows my baseload consumption flatlined at 6.5 kW until I start generating power in the morning, then it drops to zero except for a bit of exported power when the Backup Switch can’t control the legacy inverters. Then mostly zero until the battery storage is exhausted later in the evening and resumes logging my house baseload.
Bankstown, did you ever take a look at the database links for my two system?
Or answer the question about the aggregation choices still visible in the aggregation settings AFTER being set to NONE?
I asked AI to explain what is going on and this is what it came up with. I posted the same to Rainforest Automation Support and they generally agreed with the AI analysis of what is going on.
I asked AI to explain what I am seeing. This is its analysis. The issue is not that the meter is broken, but that the EAGLE-200 cannot interpret the math of a net-metering solar layout when paired with a Tesla Backup Switch. [1] Why the Eagle-200 Data Becomes Corrupted The EAGLE-200 is a simple device that pulls raw registers via Zigbee from your PG&E SmartMeter. It only knows how to calculate “Consumption” using the utility meter’s basic variables:
- Delivered (Grid Import): Power coming into the house.
- Received (Grid Export): Power leaving the house from your solar.
When the Tesla Backup Switch is introduced, it creates a split-circuit layout where your household load and your solar generation meet inside the backup collar before hitting the smart meter. Because of this physical configuration, the smart meter only ever sees the Net Power (the final remainder of the math). It has absolutely no idea what your total household consumption is. The Math Breakdown (Why Your Graphs Mirror Each Other)
- During the Night: Solar generation is 0 kW. Net grid import exactly equals your home consumption. The smart meter reports 2 kW “Delivered,” and the Eagle correctly graphs 2 kW of consumption.
- During the Day: Your solar produces 9.6 kW (as shown in your chart), and your house uses 3.5 kW.
- What the Smart Meter Sees: The remaining 6.1 kW is pushed back into the grid. The meter logs this as 6.1 kW “Received” (Export).
- Where the Eagle Fails: The EAGLE-200 does not have a channel to read “Raw Solar Production.” To display a consumption graph, its software forces a formula like Net Power + Assumed Load. Because it cannot see the 9.6 kW solar baseline, it interprets the 6.1 kW export curve as your “Consumption” graph, effectively mirroring your generation data.
Does the AI answer seem logical and correct? The Eagle-200 is not compatible with a Tesla Backup Switch?
And this was Rainforest Support reply.
Glad to see your AI interpertation is correct, the eagle gateway reads data directly from the meter, specifically the meter has a cumulative counter that shows the total energy sent:
From the grid - currentSummationDelivered
To the grid - currentSummationReceived
Since this is measured at the meter, any discharge at the inverter level will not be seen by the gateway, we’ll only be providing data directly read from the meter; This means the data we provide is what PG&E will be basing their net metering off of and will enable you to reliably confirm their energy values and calculations.
If you’re trying to get in home discharge information to PVO, that’s not data the gateway is able to collect, as it only collects data from the smart meter. That information will also not impact the net export and import, and therefore wont impact your net metering.
Best Regards,
Rainforest Support
So since there is no way to fix the data sent by the Eagle-200 to PVO, is there any way to easily correct each day’s actual consumption via script or auto updater or something.
I know there is no way to fix the realtime graphing, but I’d like to correct the daily consumption totals.
All I would need to do is simply subtract the generation from the consumption to get the real consumption for the day that the smart meter sent to the utility.
For net data, consumption is calculated from generation (webbox) and net data (Eagle).
However, this only works if the generation is already present before net data is sent.
How often does the webbox send its data?
