schlimmchen
commented
1 week ago Is it correct that changing config values by issuing MQTT commands still entails writing to the flash memory (and thereby increasing the 'config save count')?
Yes, except for the mode, which is not a config value at all, so the config is not written when changing the mode.
A development goal is to keep and reflect (at some other place than the DPL settings menu) these changes independent of the flashed values?
Yes, exactly. We need some kind of "DPL state" class, separate from the current PowerLimiter.cpp, like PowerLimiterState.cpp. This class shall initialize itself from the configuration struct. Its variables shall be modifiable by MQTT commands. When saving the DPL setting from the web UI, this class shall reload the settings from the configuration struct. The DPL shall use the state from this new DPL state class, and not use the configuration struct (at least for the state which is part of PowerLimiterState.cpp).
The next step would be to add even more state into this class, specifically values coming from the DPL calculations/decisions, like the calculated target power limit for the inverter. All of this then needs to be transported to and displayed by the web UI in a new card.
Thank you for this PR! I saw you also updated the wiki for your last contribution. Awesome! :heart:
As suggested in https://github.com/helgeerbe/OpenDTU-OnBattery/pull/1047#issuecomment-2170469378 TargetPowerConsumption can be set by sending a power value to topic 'powerlimiter/cmd/target_power_consumption' via MQTT and be read from topic 'powerlimiter/status/target_power_consumption'.
Is it correct that changing config values by issuing MQTT commands still entails writing to the flash memory (and thereby increasing the 'config save count')? A development goal is to keep and reflect (at some other place than the DPL settings menu) these changes independent of the flashed values?