search

davidrapan / ha-solarman

⚡ Solarman Stick Logger integration for 🏠 Home Assistant
MIT License
115 stars 25 forks source link

Today and total loss sensors show non-monotonic growth #75

Closed sofkaski closed 3 months ago

sofkaski commented 3 months ago

I noticed the following log entries:

2024-08-11 16:35:10.679 WARNING (Recorder) [homeassistant.components.sensor.recorder] Entity sensor.inverter_total_losses from integration solarman has state class total_increasing, but its state is not strictly increasing. Triggered by state 305.3 (305.4) with last_updated set to 2024-08-11T13:30:14.321651+00:00.

2024-08-11 17:05:10.590 WARNING (Recorder) [homeassistant.components.sensor.recorder] Entity sensor.inverter_today_losses from integration solarman has state class total_increasing, but its state is not strictly increasing. Triggered by state 1 (1.1) with last_updated set to 2024-08-11T14:00:31.043815+00:00.

The formula for today's losses:

Today(Daily) losses = Today(Daily) Energy Import(Bought) + Today(Daily) Production + Today(Daily) Battery Discharge - Today(Daily) Energy Export(Sold) - Today(Daily) Battery Charge - Today(Daily) Load Consumption

When looking from the history the values of registers used in the calculation are growing monotonically around these times, but the calculated value does not.

last_changed today_energy_bought today_production today_battery_discharge today_energy_sold today_battery_charge today_load_consumption today_losses
2024-08-11T13:45:00.000Z 3.5 24.3 0 19.2 0 7.6 1
2024-08-11T13:50:23.091Z 3.5 24.3 0 19.3 0 7.6 1
2024-08-11T13:50:23.092Z 3.5 24.3 0 19.3 0 7.6 1.1
2024-08-11T13:50:23.094Z 3.5 24.5 0 19.3 0 7.6 1.1
2024-08-11T14:00:31.043Z 3.5 24.5 0 19.7 0 7.7 1
2024-08-11T14:00:31.044Z 3.5 24.9 0 19.7 0 7.7 1
2024-08-11T14:10:08.361Z 3.5 24.9 0 20 0 7.7 1
2024-08-11T14:10:08.362Z 3.5 24.9 0 20 0 7.8 1

Looking at longer history of losses it seems that the value typically oscillates one decimal up and down while growing over a longer period. Could this be related to timing of register reads compared to when the inverter updates these values? E.g. some registers are updated with new values in the inverter and rest are 'old' values.

Inverter configuration:

Versions:

davidrapan commented 3 months ago

Hi @sofkaski, it's simply cause the inverter itself is giving those values "out of sync", it's bad but there is nothing we can do about it.

And it's for sure not cause of wrong requesting. Those sensors are designed in a way so all those values are always requested in single call.

I was experimenting with longer timings but it had no apparent effect.

What i think is happening is that precision of those values is not enough. It proly requires at least 2 decimals. And the rounding in the device f*cks that up.

sofkaski commented 3 months ago

Yep. I agree with your analysis. We are in the mercy of the inverter here. Closing this issue.

davidrapan commented 2 months ago

Hey @sofkaski I attempted to do something about it in feat: Experimental ensure_increasing property and it works so far for me, but if you could also "test" it with me would be awesome! Thanks. 😉

Edit: Additional improvements of this feature in feat: Implemented RestoreSensor

sofkaski commented 2 months ago

@davidrapan I'll have a look and give it a go in my system and let you know how it goes.

sofkaski commented 2 months ago

@davidrapan:

Unfortunately this seems not to work in my setup (deye_sg04lp3.yaml). Inverter Today's Losses is stuck to 0 and Inverter Total Losses to some non-zero value (336.9) to which the sensor grew during previous versions. To understand better what is going on I added some temporary debug messages in the dev branch of my clone.

The following log snippet is from validation:

2024-09-09 15:24:24.486 DEBUG (MainThread) [custom_components.solarman.parser] do_validate: key: Today Losses, value: 0, rule: {'default': 0, 'min': 0.1} 2024-09-09 15:24:24.487 DEBUG (MainThread) [custom_components.solarman.parser] do_validate: key: Total Losses, value: 336.7000000000003, rule: {'default': 0, 'min': 0.1}

And from the set_state log I can see:

I checked using register values that the algorithm for today losses really produces 0 currently. The sensor sensor.inverter_power_losses shows still some spikes so there should be non-zero energy values coming at some point:

image

What is comes to losses calculation I suppose that we would need to include also any energy consumed from UPS outputs. I suppose that is not available from the inverter as energy units (kWh), but only as instantious power (W). So that would need e.g. a template sensor with Riemann sum integral to produce energy consumption over a period. But as discussed here the UPS power values are a bit dodgy. For example currently I don't have anything connected to UPS output and yet there is 44 W power flowing (from sensor.inverter_load_ups_power and that verified also from inverter registers).

sofkaski commented 2 months ago

Btw, @davidrapan Unrelated, but I added also one commit that adds key value 'true' to yaml.

The original code works ok in this case when it checks the existence of the key and interprets it as true. The interpretation of an 'empty' value could also be null and thus False. Also having the value there is a bit more documentary. To be really robust my code would still need an amendment where the value is compared against 'true' and 'false' before accepting it (and logging if it is neither of them if the key exist)

davidrapan commented 2 months ago

The changes does not touch Power losses in any way, just Today's and Total. This is how they "look" in my case and it's working fine for several days already, mon-growth_today_losses mon-growth_total_losses Would love to know what exactly is happening in your case that it does not works for you. 🤔

What is comes to losses calculation I suppose that we would need to include also any energy consumed from UPS outputs.

No we don't. Registers from which it calculates the losses already includes that.

Also having the value there is a bit more documentary. To be really robust my code would still need an amendment where the value is compared against 'true' and 'false' before accepting it (and logging if it is neither of them if the key exist)

Code only checks if the property is present and does not look at the value. So the values are irrelevant. 😉

sofkaski commented 2 months ago

The changes does not touch Power losses in any way, just Today's and Total.

Yep. My point was that since power losses show some values one would expect that energy counters would also show some more than 0. This is an inverter side issue.

This is how they "look" in my case and it's working fine for several days already,

Mine is showing flat zero for today's losses. This may be some inverter firmware version issue.

What is comes to losses calculation I suppose that we would need to include also any energy consumed from UPS outputs.

No we don't. Registers from which it calculates the losses already includes that.

You are right. I made a test where I connected a known 1 kW load to UPS L1 circuit. The inverter seems to add that power to the total load power (and then it gets included to corresponding energy counter from there).

Here you can see evidence of that:

image

At 12:47:30 both powers jumped about 1 kW up. I rest my case.
:smile:

sofkaski commented 1 month ago

Mine is showing flat zero for today's losses. This may be some inverter firmware version issue.

@davidrapan FYI: I noticed today that now my system shows correct values for sensor.inverter_today_losses. I don't know what has changed since the previous discussion. Only thing I can think of is that the inverter has been reset once when I returned the battery pack into use.