Change in Feed Through behavior in 2.0.x?

[daking13]

Was there an intentional change in how Feed Through entities behave with the 2.0.x upgrade? This entity used to just give power and energy for my attached (dumb) subpanel, but now it appears to be returning all power / energy for the whole panel, including negative power values that shouldn't be happening, as there are no energy producers attached to the feed through lugs.

Here is a snapshot of my Feed Through Power metric before and after my 1.3.x to 2.0.x upgrade

[cayossarian]

No intentional change, but could be an inadvertent or conscious change in the underlying API. Let's work through it if you are able to use the MQTT Explorer to look at the underlying Homie MQTT data. It appears that the sub-panel is being treated like the grid where power leaves the SPAN panel is treating as negative.

You're the first to report this which is surprising but maybe you are the only one looking at it.

I don't have a sub-panel so my readings are not a good indicator. If possible look at the raw data and provide me with a screen shot of the MQTT data. MQTT Explorer

Provide me with a screenshot of just the lugs-upstream / lugs-downstream topics expanded like this:

[daking13]

Thanks for the quick response! Here are those topics

[daking13]

now that i am watching this data closely, it looks as though it may have been just using the lugs-downstream values previously, and in 2.0.x it is including lugs-upstream as well. Downstream tracks closely to my typical subpanel usage

[cayossarian]

The integration is simply reading the downstream lug data, we aren't manipulating it.

Can you tell if that power reading is in agreement with the subpanel consumers? The energy values clearly appear to be erroneous and we should file a defect with the API but I'd like to get your read on the viability of the downstream lug value.

If the energy is erroneous I'd suggest disabling those sensors in the interim. When the firmware gets fixed we can take a look again and see if there is something in the span-panel-api that needs work.

@dcj may have some input.

[daking13]

Power doesn't look correct right now either. When i looked last night, it appeared correct, as that dumb subpanel runs about 200-300W most of the time. When i look at history, sometimes it looks correct and other times its way off. I just looked again via MQTT and downstream lug power showing ~2800W. Impossible that is coming from the subpanel, and it seems to be including some of the main panel usage when running a heavy consumer.

All the spikes on this graph from the last 24 hours correspond to when I was running an electric dryer, which is a circuit on the main panel, not the subpanel. But its only a subset, the dryer circuit on its own is reporting 5.3kW. I have other examples where the spike on the feed through was from another main panel circuit. definitely seems like a bug in the SPAN firmware

[dcj]

Thanks for reporting this. We've confirmed the issue — the lugs-downstream power and energy values from the eBus MQTT API are using the wrong internal data source, resulting in incorrect readings.

Tracked at spanio/SPAN-API-Client-Docs#13. Fix is in progress.

In the meantime, the v1 REST API feedthroughPowerW and feedthroughEnergy fields are still correct if you need a workaround.

[cayossarian]

Much appreciated, Don. I'm going to opt to use the existing snapshot to calculate the downstream to avoid the polling in v1 REST.

@daking13 if possible try the beta for v2.0.7b5 by going to HACS and redownload, select the version specifically, then restart, give the reading once cycle to update and provide your findings in the issue #234