Calculating Solar export - spurious values

[richardcastle]

I'm a recent adopter of a SolarEdge setup with inverter, two batteries, solar panels and an E/I meter all hanging off modbus.

The modbus-multi just worked, out of the box. Pretty amazing so kudos to the developer for the efforts to get to this point.

Using information from the other SolarEdge Modbus wiki, I was able to create a template sensor to calculate solar production by simply subtracting the combined battery power delivery from the overall inverter power output. For the most part this works however I seem to suffer from odd spurious solar production data - little spikes of solar production which I know aren't right (it's dark!).

I'm only in my second week, so I'm sure I've got lots to learn. It seems to happen most when there is a step change in power consumption in the house. In these scenarios, the inverter needs to ramp up/down production and there is a little lag. At these times, I tend to get a solar productio spike.

I'm using pure modbus data in my calculation, so I'm guessing that there is a lag in one of the sensors. In one particular instance, battery was delivering 1400w, however inverter power delivery was 2751w. This resulted in the template sensor showing solar consumption which I knew wasn't right.

I'm polling every 3 seconds.

I don't think my configuration is particularly unsual, so wondering if anyone has experienced the same fluctuations?

Here is the template for reference:

• sensor:
  • name: "Solar Export Watts"
    unit_of_measurement: "W"
    device_class: power
    state_class: measurement
    state: >
    {% if ( ( states('sensor.solaredgemod_i1_dc_power') | int + states('sensor.solaredgemod_b1_dc_power') | int + states('sensor.solaredgemod_b2_dc_power') | int ) | round(0) ) > 0 %}
    {{ ( ( states('sensor.solaredgemod_i1_dc_power') | int + states('sensor.solaredgemod_b1_dc_power') | int + states('sensor.solaredgemod_b2_dc_power') | int ) | round(0)) }}
    {% else -%}
    0
    {% endif %}

[WillCodeForCats]

That's a good question: I don't know what the internal update or response rate of the inverter-battery communication is.

I know that for site limit response is 3 seconds and "virtual" meters (meters from calculated values) are 10+ seconds. Assuming these are similar for other responsive functions of the inverter, I would try some longer polling times first.

[richardcastle]

Thanks for the quick response. I have tried to back off the polling frequency to 15 seconds, but it doesn't seem to have made much difference.

For the time being, I've applied a template filter (outlier) and excluded entries when sun below horizon which seems to have dampened the worst of the spikes.

Keen to hear if anyone else has come across the same problem and how they've approached the challenge.