* fix compiler warning in SerialPortManager.cpp: function must not
return void
* clean up and simplify implementation of usesHwPort2()
* make const
* overrides are final
* default implementation returns false
* implement in header, as the implementation is very simple
* rename PortManager to SerialPortManager. as "PortManager" is too
generic, the static instance of the serial port manager is renamed to
"SerialPortManager". the class is therefore renamed to
SerialPortManagerClass, which is in line with other (static) classes
withing OpenDTU(-OnBattery).
* implement separate data ages for MPPT charge controllers
* make sure MPPT data and live data time out
* do not use invalid data of MPPT controlers for calculations
* add :key binding to v-for iterating over MPPT instances
this change adds support for a second Victron MPPT charge controller
using a second serial connection.
* Add device configuration for a second victron mppt
* Update VedirectView for second victron mppt
* Update MqttHandleVedirect for second victron mppt
* Update MqttHandleVedirectHass for second victron mppt
* Handle nonexisting victron controllers with optionals
* Add bool-function to Battery and inherited classes, if uart port 2 is
being used
* Introduced a serial port manager. In order to prevent the battery and
the Victron MPPT to use the same hw serial ports, this class keeps
track of the used ports and their owners.
* remove duplicated #defines. this is most probably a merge error from
2024-01-16, as evidenced by 63205f88b, which added these duplicates.
* sort values by upstream and downstream projects. add a comment which
tells us in the future where OpenDTU-OnBattery-specific values start.
now that users can tell the DPL that their inverter is not powered by a
battery but powered by solar panels, we shall not restart inverters to
reset the daily yield value, if they are solar powered. these inverters
will reboot every night by themselves.
currently this is only supported by the Pylontech battery provider, as
it reports a "charge battery immediately" alarm. this will also be
implemented by the JK BMS provider, and possibly also by the smart shunt
provider.
the method will be used to determine whether or not to start charging
the battery using the (Huawei) charger.
* fix logic in HomeAssistent handler
* also publish voltage thresholds (not just SoC thresholds)
* do not publish irrelevant thresholds to MQTT. if the inverter is
solar-powered, no thresholds are effectively in use by the DPL and it
therefore makes no sense to publish them to the broker. similarly, if
no battery interface is enabled or the SoC values are set to be
ignored, the SoC thresholds are effectively not in use and will not be
published to the broker.
* make HA auto-discovery expire. this makes auto-dicovered items
disappear from Home Assistent if their value is no longer updated.
changes to settings which cause other thresholds to be relevant will
then be reflected in Home Assistent even if some thresholds are no
longer maintaned in MQTT.
* force HA update when related settings change enabling VE.Direct shall
trigger an update since solar passthrough thresholds become relevant.
similarly, enabling the battery interface makes SoC thresholds become
relevant. there are more settings in the power limiter that also
influence the auto-discoverable items.
* break very long lines
the allocated memory to create the JSON with onBattery-specific totals
for the live view was too little to contain all values, which are sent
regularly.
avoid shutting down the inverter at all if the calculated power limit
falls below the lower power limit or if the power meter value is
outdated. do this only if the inverter is setup to be solar powered.
by default and until this change, we assumed that the inverter
controlled by the DPL is powered by a battery. not all users have a
battery in their system. they still use the DPL to achieve net-zero
export. those users can now tell the DPL that their inverter is powered
by solar modules rather than a battery and the DPL will behave
accordingly.
do not scale limit if inverter is not producing, as DC channel power is
expected to be close to zero anyways.
do not scale limit if current inverter limit is small, such that
channels might produce very little power exactly because the limit is so
low.
move the calculation out of setNewPowerLimit and into a new function, so
that we can make use of return statements there.
the update frequency of Victron MPPT charger data, the battery Soc, the
huawei charger power, and the power meter differ from one another, and
differ in particular from the inverter update frequency.
the OnBattery-specific data is now handled in a new method, outside the
upstream code, which merely call the new function(s). the new function
will update the websocket independently from inverter updates. also, it
adds the respective data if it actually changed since it was last
updated through the websocket.
for the webapp to be able to recover in case of errors, all values are
also written to the websocket with a fixed interval of 10 seconds.
This change makes the build runner switch to a meaningful branch name, which will then appear as the "Firmware Branch" in the System Info of the web application. This helps users testing pull-request builds identify that they are actually using the changes from the respective pull request.
we previously only called commitPowerLimit() if the desired limit
changed such that the change was bigger than the hysteresis. we found
that if the limit update was not received and the desired limit would
not change much, the limit of the inverter was wrong for a long time.
to mitigate this, we introduced re-sending the limit update every 60
seconds, regardless of what the limit reported by the inverter was at
that time.
if the power-up command was not received, we also would repeat it only
once every 60 seconds.
this leads to a new kind of staleness and the actual inverter state was
still not matching the desired state.
this new approach effectively adds an additional control loop at the
start of the DPL loop(). that new function compares the requested
inverter state to the actual reported state. it sends updates (limit
update or power on state) until the desired inverter state is reached,
or until a (hard-coded) timeout occurs.
this approach also allows us to send power-up, power-down, and limit
update commands independent from one another and in a particular order.
this should make sure that the inverter is in the desired state even if
conditions change slowly and commands were not received as expected.
