mr-manuel / venus-os_dbus-mqtt-pv

This Venus OS driver gets the data from MQTT and displays it as pv inverter.
MIT License
61 stars 13 forks source link

energy_forward flapping between 0 and real value #23

Closed gvzdus closed 9 months ago

gvzdus commented 9 months ago

In my usecase, I only update "energy_forward" on changes. I realized I have to include "power" when sending the data. However, when only "power" is sent, "energy_forward" is set back to 0 (as not present in the MQTT Json structure. This is IMHO because you set the "energy_forward" to 0 instead of None, but check for None here: self._dbusservice['/Ac/Energy/Forward'] = round(pv_forward, 2) if pv_forward is not None else None

Sorry for not suggesting a patch - too bad in Python.

mr-manuel commented 9 months ago

You have to always send all informations, even if they do not change. From where are you sending the MQTT message?

gvzdus commented 9 months ago

I generate them from my smarthome system (FHEM), after collecting & merging different PV generators. If you state "always send everything complete", I would change my configuration. But generally, I try to avoid redundant transmission of unchanged values.

mr-manuel commented 9 months ago

Since in this case it could indeed happen, that the value does not change for hours I adopted the script.

All values need always to be send, since they are chaning constantly except for the energy_forward. The value now remains saved until it's updated. Now the question is how the system behaves, if the driver is restarted and the value for energy_forward initially is set to none. Could be, that it counts then the whole difference from 0 - new value. Can you test that please?

Could you try to reinstall the current version?

gvzdus commented 9 months ago

I tested with the new version, and yes: Total counter is not reset to zero on missing values. However - as you guessed - on restart (svc -d && svc -u) the counter is reset to zero. However, in the victron monitoring portal, the total daily produced kWh remain stable. So, I think the solution is pretty fine - thank you!