The solar feed is available in the panel data but not accessible through the integration

[cayossarian]

For those folks who cannot read their solar inverter directly capturing solar generation data is a laborious process prone to error. Basically one has to add all the circuit power in use and subtract the aggregate from sensor.current_power while excluding some "power" circuits, check for returning to grid values, etc. A bit error prone and unnecessary since the raw data exists in the SPAN API already.

Circuits 30/32 are used in many installations as the solar inverter feed. Like any other circuit they have instant power readings for the two legs which if added together gives the total solar generation from the inverter but since these circuits are not user managed they are excluded from the sensor list.

Partial output from http://{}/api/v1/panel ..., { "id": 30, "relayState": "CLOSED", "instantPowerW": 236.1874237060547, "importedActiveEnergyWh": 14047.5234375, "exportedActiveEnergyWh": 32.411373138427734 }, ..., { "id": 32, "relayState": "CLOSED", "instantPowerW": 235.91111755371094, "importedActiveEnergyWh": 13990.48046875, "exportedActiveEnergyWh": 33.48377990722656 }

I'd like to suggest an enhancement to add these circuits to the exposed panel sensor data (like "Current Power", perhaps keyed like: key = "instantSolarInverterPowerW" name="Solar Inverter Power"

or one for each leg if that's better.

I'd be happy to take a stab at this change if we can agree on the approach.

[sargonas]

I was struggling with doing a lot of complex formulas and helpers to solve this exact problem, before I found a custom version of the Tesla integration that will work with an inverter that does not have a power wall negating my need to keep exploring this. As a result I never finish diving into a more elegant solution to this, so it looks like you got ahead of me there! I actually think your idea is not a terrible one myself, and I think a pull request with these changes, if you're willing to take a stab at them, would be super helpful to get us started along the way.

If you need help testing let me know, HACS just released an update this week that now allows you to download not only specific versions directly, but also specific branches. This means moving forward testing custom versions should be getting a lot easier without having to push hole releases.

[cayossarian]

I have a working prototype that directly exposes those solar values (power, consumed, produced) and also addressed the warnings about deprecated constants for WATT and WATT_HOUR.
Yes, it's dark and stormy in California but the power figure agrees with the SPAN app solar.

Just reading the SPAN docs I see that ANY breaker can be used for solar. I don't see any user accessible data that indicates which circuits are being used for solar but since the app is measuring solar I assume there is something in the installer's configuration that identifies a particular circuit as the solar feed. We just can't access that information.

One solution is to have a configuration in the integration that the user would fill in to identify the legs, e.g., 30/32. Obviously it would be better if the SPAN API told us which circuit was solar.

[sargonas]

Just reading the SPAN docs I see that ANY breaker can be used for solar. I don't see any user accessible data that indicates which circuits are being used for solar but since the app is measuring solar I assume there is something in the installer's configuration that identifies a particular circuit as the solar feed. We just can't access that information.

Yeah I think the panel by default treats the last 2 on the bottom right for that... and during install another set can be defined as well, and whatever is set just shows up as the solar source in the Panel? That's my educated assumption... Matthew can maybe swing through and set us straight.

[gdgib]

@cayossarian would appreciate a PR or link when you have a mo. I'm trying to get to 0.0.9 this week.

[joergbattermann]

Just reading the SPAN docs I see that ANY breaker can be used for solar. I don't see any user accessible data that indicates which circuits are being used for solar but since the app is measuring solar I assume there is something in the installer's configuration that identifies a particular circuit as the solar feed. We just can't access that information.

One solution is to have a configuration in the integration that the user would fill in to identify the legs, e.g., 30/32. Obviously it would be better if the SPAN API told us which circuit was solar.

FYI, we have an Enphase system with REC panels and batteries and we have -no- individual breaker inside the Span Panel for the solar side of things (or batteries for that matter). The breakers for those are actually inside the Enphase system.. I want to say inside the Combiner.

Anyway, the way Span reads the Solar production and Battery Charge/Discharge values is via its Remote Meter Kit which comes with some control wiring between the Span Panel and the Enphase system and production & consumption CTs for the batteries and solar circuits. You can have a breaker for solar inside the Span panel, but both variants are supported, see https://drive.google.com/file/d/1azZMj2ww1UKzfaFDoisYf9KMErOqWpNs/view

[cayossarian]

@joergbattermann in your case then you read solar data from an Enphase integration (as opposed to getting that information from the HA SPAN integration?

[joergbattermann]

I sort of do, yes. The HA Enphase Envoy integration provides (solar) production values, see "Current power production" (gray afternoon with sun behind the hills already):

For us however, the Span panel and its remote meter kit's way of reading specifically the battery (dis)charge rates and 'assumed' ?state/levels of charge is highly flawed currently - the battery values inside the Span app diverge significantly from the actual state of charge (this morning by a good 60%) and also the (dis)charge rates are off by a couple hundred watts any given moment in time (and probably hence the watts-counting per their CTs doesn't work properly to assume the (in)correct state of charge), so I couldn't really use the Span integration anyway BUT I just wanted to provide the info that solar isn't necessarily having its dedicated circuit/breaker inside the Span panel for all system/installation variants the Span ecosystem supports.

[gdgib]

I'm tagging this with 0.0.10 for now. Not because I don't care, but because I want to focus on hard errors, and connection problems in 0.0.9, and leave measurement issues until after those are fixed.

[cayossarian]

The sensors provided in the pull request are enabled and mapped to circuits in the integration configuration options where scan frequency is found. The default is disabled. If enabled three sensors are created:

sensor.solar_inverter_instant_power (watts) sensor.solar_inverter_energy_produce (Wh) sensor.solar_inverter_energy_consumed (Wh)

Disabling the inverter sensor removes these specific sensors. No reboot required to add/remove inverter sensors.

Adding your own integration sensor like so converts to kWh:

sensor
    - platform: integration
      source: sensor.solar_inverter_instant_power
      name: Solar Inverter Produced kWh
      unique_id: sensor.solar_inverter_produced_kwh
     unit_prefix: k
     round: 2

[cayossarian]

This pull for the solar is waiting on the unit_of_energy pull request

[cayossarian]

If you need help testing let me know, HACS just released an update this week that now allows you to download not only specific versions directly, but also specific branches. This means moving forward testing custom versions should be getting a lot easier without having to push hole releases.

@sargonas, if you want to test this change before the repository gets a pull request, you can find it here (the readme is also updated)[ https://github.com/cayossarian/span/tree/solar_inverter

This change is dependent on the deprecated constants pull request I submitted so I'll wait until that gets picked up to submit another

[gdgib]

@cayossarian would you kindly go ahead and submit the PRs, each one including more than the last? It's easy enough for me to review the stack, and that'll make sure we get them all together in the next release. I REALLY appreciate you separating the PRs, through for all of our sanity.

[sargonas]

@cayossarian currently out of town traveling to San Francisco for game developers conference this week, but as soon as I'm back home this weekend, I'll load all this up on my test/integration instance and put it through its paces!

(Also a +1 on thanks for being awesome and breaking down the PRs, it makes things so much saner in the long run!)

[gdgib]

Thanks for testing, @sargonas. I definitely am not prioritizing measurements right now, just focused on controls for a bit longer.