official release builds are built from branch master, as the respective
tags point to commits in branch master (only). to check whether or not a
new version is available, we should check branch master for new commits.
checking against HEAD does not work as expected, at least in the
OpenDTU-OnBattery repo, since its default branch is "development", not
"master".
usually, there should be no commits on master in between releases, so we
will now only show "update available" if a new release was made. this is
not foolproof, but should work as long as we keep "master" clean.
for builds from other branches, the comparison is perfomed against the
respective branch. if a user installed a binary built by github actions
based on a development branch, the user will see "update available" if
new commits were added to the development branch since.
for other branches, also pull request builds, the test for updates will
fail as the branch name shown in the system info is not actually a
branch name, e.g., "helgeerbe/OpenDTU-OnBattery/pr1183-202408212043".
* update mqtt subscriptions when topic was changed
* DPL/Huawei: manage MQTT subscriptions in map
---------
Co-authored-by: Bernhard Kirchen <schlimmchen@posteo.net>
previously, we needed VE.Direct enabled to know the
solar charge controller output, which solely decided when
it was "nighttime". since this is now determined by the
wall clock, we can offer this feature to users without a
Victron charge controller connected using VE.Direct.
* backport SPIPortManager from @skippermeister
* adapt to support ESP32 and ESP32-S3 and ESP32-C3
* use logic to work with SPI numbering as in the official
documentation: start with SPI0 and go up to SPI3
* increase Huawei CAN controller stack size to 2000
* increase startup delay for USB_CDC enabled builds to be able to
catch bootlogs over USB
* fix: DPL: start discharging at night logic error
the switch "always start discharging battery at night" would cause to
stop discharging the battery when there was solar power and the battery
was discharged below the start threshold.
this change introduces a nighttime discharging boolean variable, which
is enabled the instant we decide to start a battery discharge cycle due
to nighttime havin arrived. we reset this variable as soon as it is
daytime (solar power available). in that case, we allow discharging the
battery if the start threshold was reached. this can actually be the
case if the battery is charged with cheap electricity during the night.
removed comments as they merely spell out what the if statement already
expresses quite nicely.
* use SunPosition.isDayPeriod() to check for daytime
---------
Co-authored-by: Andreas Böhm <andreas@boehm.cx>
this changeset adds support for parsing the MQTT battery provider's SoC
and voltage topics' payloads as JSON to extract a numeric value at a
configurable path.
* show battery voltage, current, and power in live view header (the "totals")
* show battery current and power in extra card
* use soc and current precision in live view
* BatteryStats: do not knowingly publish invalid data: not all battery
providers know all values the base class manages. make sure to
prevent publishing invalid values.
Co-authored-by: Bernhard Kirchen <schlimmchen@posteo.net>
This breaks existing HASS automation, as entity names and MQTT topics change!
* include dtu-unique-id in DPL MQTT HASS topics to allow multiple DTUs to be controlled
* fix filename "src/MqttHandlVedirectHass.cpp"
* refactor: use values from 'MqttHandleHass', add 'via_device' to all HASS devices
* set step size for power limiter voltage values
Hoymiles inverters allow setting relative limits with a precision of 0.1 %.
this changeset allows to utilize this precision.
* preserve accuracy when decoding power limit
* Web API: process floating point limits
* MQTT: process floating point limits
* use appropriate accuracy for limits in web UI
* HASS: step for relative inverter limit is 0.1 %
we previously used the mutex to protect writing the target variable.
however, we would only do that for the old usecase, where a plain float
value in Watts was expected as the topic's payload.
