this change allows to support overscaling for all inverters, as the configuration of
inputs (which one is part of a particular MPPT) is now provided from withing the
code. this information is used to implement overscaling for any of the inverters
(which are generally compatible with OpenDTU(-OnBattery)).
if a page uses the reload button, it had only 1 column of space, and
only if the viewport was at least "sm". this is not the case for typical
smartphones, in which case the reload button would appear on its own row
instead of to the right.
we now limit the heading to 10 columns if and only if the reload button
is to be used, otherwise the heading uses all 12 columns, regardless of
the viewport size. the reload buton uses two columns -- if it is
displayed at all.
the font size of the icon is increased slightly.
as the font size of h1 headings changes with the viewport size, we need
to center both the heading and the button vertically.
developed by myself, this feature was now merged from upstream, and the
required changes are made to use the config write guard, which enforces
synchronized writes to the configuration struct.
fixes an annoying warning (visible in the browser console):
[Vue warn]: Extraneous non-emits event listeners (reload) were passed to
component but could not be automatically inherited because component
renders fragment or text root nodes. If the listener is intended to be a
component custom event listener only, declare it using the "emits"
option.
on small viewports, the icon and the inverter label would be displayed
in two lines. this change keeps the icon and the label tied together in
any case, and the icon is centered vertically around the label.
the removal of console and debugger statements by esbuild even when not
building for production seems to be a regression, as these were
definitely working in the past.
this change uses the command parameter to configure esbuild to either
keep or indeed remove the respective statements. they are only kept if
command is not "serve".
to avoid having to indent everything in defineConfig() by one block, the
return statement and closing curly brace were added "inline".
long forms, when scrolled to the bottom, would leave no space between
the bottom of the viewport and the buttons, which is unpleasent.
short views would still createa large (high) body, for apparently no
reason.
the top border of the card was breaking the design of the tabs, where
the active tab would be "visually connected" to the content. also, the
rounded border at the top did not blend in with the navbar's bottom
border.
on a desktop browser, this approach allows to display all categories at
once. we also increase readability as the values are much closer to
their label. previously, the values were far to the right of the screen
and it was unpleasent to read which value belonged to which setting. the
grouping of values per category was also not very well conceived.
by using cards, we also avoid some styling issues, namely the use of
rowspan, which caused a spurious table cell border at the end of the old
table layout.
* remove empty container for device profile links. if a device profile
has no links, no buttons are generated, but a row was still part of
the DOM, adding spurious space between the select and the alert with
the hint.
* "float" the buttons to the right, as we always place these kinds of
buttons to the right.
the total cards have been trimmed at the bottom as the card's last child
has its margin-bottom removed (set to "auto"). that is desired as it
places the text in the middle of the cards. however, the battery total
cards are different, as they show two values each, which are arranged by
div.flex-fill containers, which are the children of the cards rather
than the h2 tags as in all other totals cards.
avoids inline style and removes right padding such that the value and
its unit move closed together, replicating the design of the inverter
channel info tables.
in the settings view we hide the "login with cert" setting while TLS is
disabled, so we should also hide that info in the info view when TLS is
disabled.
if we hide elements (which is done using style="display:none;"), they
are still part of the DOM and mess with CSS rules that shall apply to
the last element of a card or the last row of a table.
if the last child in a card (div.card > div.card-body) adds bottom
marging, we don't want the card to add more space through its
padding-bottom. most cards have children that add sufficient space
at the bottom anyways.
avoid hidden (but existing) or simply redundant DOM elements from
messing with the style sheet, which uses :last-child in particular to
fix up the margin on the bottom of cards.
when using v-if on a div element, the div will be part of the DOM in
case the condition is true. if we group elements to use v-if on the
group, we shall use a template element, so the group elements appear
as siblings of the other elements.
in particular, these spurious div do not mess up our CSS patch that sets
the bottom margin for the last child in a card to "auto".
it would be nice to have this in the header of the accordion, which is
hard, but doable. however, clicking the button then also toggles the
accordion, which is unacceptable. preventing that seems non-trivial, as
the @click.stop() is not enough. also, nesting interactive elements is
simply bad practice. the button can also go to the right of header, with
reasonable effort, but the corner radii are then messed up and would
need to react interactively (accordion collapsed or not), which is also
a pain.
we now "float" the reset button to the right, add a nice icon, and give
the button some space so it at least looks like it belongs there.
the cards in all information views still used a div.card-body around the
table, which added a margin on all sides of the table. to achieve a
unified look, these cards and tables now look the same as the inverter
channel cards.
we don't need a margin at the bottom of tables in general. not sure why
this is even a thing in bootstrap. this change, in particular, makes the
space between a table and a parent card symmetric on all sides.
this change tries to achieve a pleasing look of input forms by
right-aligning the texts of labels. the input form now looks similar
to a table, achieving a cleaner look, especially for forms where the
labels have varying text lenghts.
the absorption and float voltage setting is retrieved from connected
Victron Ve.Direct MPPTs using the HEX protocol. the values are
displayed in the live view, published to MQTT, and added to Home
Assistent auto-discovery.
This changes the custom current limit so the custom limit is only
applied when any of:
- SoC is valid and not ignored and SoC < threshold
- Voltage is valid and Voltage < threshold
- Voltage is invalid
Independently, if "Use Battery-Reported limit" is enabled and valid, it
is applied (unless a lower custom limit already was applied).
a battery temperature value measured by a Victron smart battery sense
and communicated to a connected Victron MPPT charge controller will now
appear in the live view card.
If the default type is an int, setting to a fractional value is not possible.
Presumably this is because in
`target.DischargeCurrentLimit = source["discharge_current_limit"] | BATTERY_DISCHARGE_CURRENT_LIMIT;`
the JSON library uses the default to force the expected type and on type mismatch the default is used.
As per https://arduinojson.org/v7/api/jsonvariant/or/:
`defaultValue: the value to return if the JsonVariant is null or incompatible with the requested type.`
* Allow scaleValue() for 32bit values
* Victron: Implement CAN message 0x360
This one-byte message is set to 0xff to request charging below a
certain SoC threshold (10% in my tests).
* Pytes: Add support for native CAN protocol
The recently added PytesCanReceiver.cpp implements the Victron CAN protocol.
This change additionally adds support for the native Pytes CAN
protocol messages.
Features only supported in Pytes protocol:
- High-resolution state of charge / full and remaining mAh
- Charge cycle counter
- Balancing state
Features only supported in Victron protocol:
- FW version
- Serial number
Note that the only known way to select the native Pytes protocol is
via the serial console (Cisco-compatible cables work):
```
login config
setprt PYTES
logout
```
to return to Victron protocol use:
```
login config
setprt VICTRON
logout
```
to return to DIP-switch based protocol setting:
```
login config
setprt DIP
logout
```
when upgrading to cpplint 2.0.0, C-style casts are flagged. since many
of them are in libraries, we will use version 1.6.1 until we figure out
whether we shall ignore C-style casts or if we will replace them.
This implements RFC5424 version of the protocol.
Don't use https://github.com/arcao/Syslog since the protocol itself
is trivial and most of the libraries functionality is not needed here.
The library also doesn't support setting the PROCID field, which is set
to a random id to indicate a reboot here.
Add UI for syslog configuration to network admin view.
I noticed that these are missing while looking at dissassembly of the
Pytes implementation of the protocol. I also found Pylontech sample
CAN messages] which match the Pytes implementation [1]:
```
CAN ID – followed by 2 to 8 bytes of data:
0x351 – 14 02 74 0E 74 0E CC 01 – Battery voltage + current limits
^^^^^ discharge cutoff voltage 46.0V
0x355 – 1A 00 64 00 – State of Health (SOH) / State of Charge (SOC)
0x356 – 4e 13 02 03 04 05 – Voltage / Current / Temp
0x359 – 00 00 00 00 0A 50 4E – Protection & Alarm flags
^^^^^ always 0x50 0x59 in Pytes implementation
^^ module count (matches the blog article image)
0x35C – C0 00 – Battery charge request flags
^^ two possible additional flags (bit 3 and bit 4)
0x35E – 50 59 4C 4F 4E 20 20 20 – Manufacturer name (“PYLON “)
^^^^^^^^^^^^^^ Note: Pytes sends a 5-byte message "PYTES" instead
padding with spaces
```
The extra charge request flag is "bit4: SOC low" (Seems to be SoC < 10%
threshold for Pytes), I haven't bothered adding that as it provides
little value.
[1] https://www.setfirelabs.com/green-energy/pylontech-can-reading-can-replication
the workflows running unconditionally for each push and each PR are run
twice when pushing to a branch that is to be merged by a PR and if that
branch is a branch local to the repo (rather than in a fork).
if the package.json file changes, we must trigger building the web
application, as in particular, a completely different version of yarn
could be required.
we need to change the working directory to the webapp directory such
that corepack installs and uses the expected version of yarn. otherwise,
corepack installs a copy of yarn into the repository root directory.
we added shell=True so that on Windows, yarn would be found. however,
using the list syntax to define the command and its arguments to
Python's subprocess is broken on GNU/Linux by shell=True. instead, use a
single string (command and arguments), which works on both Windows and
GNU/Linux.
this allows us to fix the version of yarn, the Node.js package manager,
to a particular version. using corepack is the recommended way to use
yarn these days.
the "Yarn Linting" action causes a warning to appear about a deprecated
Node version. switch to actions/setup-node@v4, which is already in use
by the action building the web app for the firmware, to avoid this
warning.
it seems this action has not been run for nealry a year. it has only
been run twice at all. it is not maintained, as it uses older Node.js
in particular. also, it seems to be redundant to build.yml, which
already builds firmware for every commit.
we need shell=True as on Windows, path resolution to find the yarn
"exectuable" (a shell script) is only performed by cmd.exe, not by
Python itself. as we are calling yarn with fixed arguments, using
shell=True is fine.
* explicitly disable NRF24 when using CMT + W5500. fixes#1257.
* explicitly disable CMT when using NRF + W5500
* added missing LED mapping for W5500 profiles
* implements UI to configure battery discharge limit
* adds support for discharge limit to MQTT battery provider
* add option to hide `issues` section from battery live view (for MQTT battery)
disabled as uploading the changed gist failed repeatedly. maybe the
token in secrets.GIST_SECRET has expired? need help from repo owner
@helgeerbe to fix this.
If the string contains control characters for some reason, the browser
will reject the json with the error `bad control character in string
literal`.
This adds a setManufacturer function that validates the string is ASCII
and will cut off the string at the first non-ascii character.
Pylontech: `PYLON` (50 59 4C 4F 4E 20 20 20)
Pytes: `PYTES` (50 59 54 45 53)
Deye: `DY001` (44 59 30 30 31 03 E8 03)
See https://github.com/helgeerbe/OpenDTU-OnBattery/discussions/1226#discussioncomment-10566898
add pre-script to check if webapp was compiled or sources changed and auto compile.
---------
Co-authored-by: Bernhard Kirchen <schlimmchen@posteo.net>
Commit accc70dea0 added the battery SoC to
the live view header. But due to getSoC() returning an int,
the precision was limited.
This changes getSoC() to return float so when a source with higher
precision is available, the respective precision is shown.
we must not reset the configuration switch value in this context. this
leads to solar passthrough being disabled once the DPL is disabled. when
re-enabling the DPL, solar passthrough is suddenly off, even though the
user configured it to be on.
the configuration switch can stay on. the DPL will still sanity-check
whether or not solar-passthrough can be used (checks if VE.Direct is
enabled) or it is irrelevant since the DPL is disabled.
value 100 is not accepted by the webapp as inputs for full
solar-passthrough start and stop volages. 66V is the documented
value to be used if one wants to disable full solar-passthrough
(while keeping (non-full) solar-passthrough).
we are running out of level 1 interrupts on ESP32-S3 boards. for that
reason, until this prooves to be another sort of problem, we allocate
the TWAI's interrupt for the battery CAN implementation at level 2.
the stack size was already increased by Andreas Boehm in df53f34b51 in
the context of #1144 (SPI port manager). this change aligns the stack
size to a power of two and adds comments. the commit also serves to
place this change more prominently as a fix in the changelogs.
this allows us to add a valid Authorization header to each but the first
GET request, saving us from performing two GET requests every time we
want to perform the GET request. we still need a new client nonce and we
need to increase the nonce counter, so we also need to calculate a whole
new response, as we cannot just reuse the previous Authorization header
(that would be a replay attack).
the MD5 scheme should still be widely deployed, even though it is
deprecated. it is also still the default if not specific algorithm
is requested by the server.
we previously performed a whole new GET request when doing digest
authentication. it seemed beneficial to reuse the TCP connection to
perform the second GET request, which includes the authentication
tokens. however, if the server sends "Connection: close" we must not
requse the TCP connection for another HTTP request.
this broke authentication against Shelly devices (at least those with
original firmware).
now we explicitly set "Connection: keep-alive" in our request, and reuse
the TCP connection only if te server replies with "Connection:
keep-alive" as well.
the SMA power meter implementation did not announce that it received a
new datum, such that the power meter data age was never reset. this made
the power meter values outdated and hence invalid, even though new
values were received and processed.
the original implementation of the isDataValid() method worked by
returning false if any of the charge controllers had invalid data. if no
charge controllers were configured, this function then also needed to
also return false.
the logic was changed in 415c767d such that if at least one charge
controller had valid data, the function would return true. this would
have required to adjust the default return statement as well, but it was
not.
if the user enabled VE.Diret and configured at least one charge
controller in the pin mapping, but this controller never delivered any
data, the function would now errorneously return true, because the
container is not empty.
however, if no controller has valid data, this now means we exit the
loop and then the return value must be false, which is also desired if
the container is empty.
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
disabled as uploading the changed gist failed repeatedly. maybe the
token in secrets.GIST_SECRET has expired? need help from repo owner
@helgeerbe to fix this.
* 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.
make the MQTT power meter pre-selected when editing power meter settings
for the first time. the MQTT power meter is the most efficient and hence
preferred power meter implementation.
enabling the HTTP+JSON power meter without enabling at least one value
makes no sense, so value 1 has always been treated as "always enabled".
while doing the power meter refactoring, however, a regression was
introduced that would hide the settings for value 1 in the web UI until
the power meter settings would be saved, which they cannot be due to
missing settings for value 1.
when performing a test request using the web UI, we need to init() the
respective power meter, but we do not want to start the polling task.
hence we move initialization of the polling task to the poll() function.
it will return if the task is setup already, otherwise setup the task.
implement a function which allows to reset the SML decoder. this new
function is used after a datagram ends. for the SML HTTP power meter
this is simple: after all bytes from the request's answer have been
decoded, we reset the decoder. for the SML serial power meter, we
perform the reset after a datagram ended based on timing (no new bytes
have been received for a specific amount of time).
cache the values decoded in the SML datagram and only copy them to the
local stash of values if the checksum of the SML datagram matched. also
makes sure that values from incomplete SML datagrams are not used.
moreover, we now only publish values to the MQTT broker that we actually
decoded (successfully) from an SML datagram (we previously published 0.0
as values to topics we never decoded a value for).
the comparison is part of the original library code, but the compiler
rightfully complains that the comparison byte <= 0xFF is always true,
since byte is uint8_t. the comparison was commented out, and is now
removed.
* when printing a message, tell the name of the derived class.
* print total power only when state SML_FINAL reached.
* tell if a checksum verification error occurred.
a 9600 baud serial interface does not need a hardware UART. these
changes switch the SDM power meter implementation to use a software
serial instance instead. this is desirable as hardware UARTs are scarce
and users need them for JK BMS and VE.Direct interfaces.
the destructor will block for way too long if we keep holding the
polling mutex while performing a transcation with the SDM power meter.
when reading, we now release the lock. afterwards, i.e., in between
transactions, we check the stop flag so the task terminates in a timely
manner once asked to do so.
a 1-phase SDM power meter does not know about power or voltage of phase
2 or 3. do not publish values to the respective MQTT topics when using a
single phase SDM power meter.
avoid problems with chunked transfer encoding when using the client's
stream to parse a JSON document. fixes the HTTP+JSON power meter to work
with shelly and hichi (Tasmota).
the MQTT power meter can now process the messages published at the
respective topics as JSON and extract a power value using a JSON path
(same as in HTTP+JSON power meter). additionally, selecting a unit for
the power value as well as an option to invert the value's sign was
added as well, similar to the HTTPS+JSON power meter.
instead of reading the main config's powermeter struct(s), the
individual power meters now are instanciated using a copy of their
respective config. this allows to instanciate different power meters
with different configs. as a first step, this simplifies instanciating
power meters for test purposes.
all power meter providers now have their own configuration struct
defined. a respective method to serialize and deserialize the provider
config is implemented for each provider.
apply all config values from the webfrontend, then perform one polling
cycle. display values seperately in the result, and show the resulting
value as well.
this new class uses the newly introduced HttpRequestConfig and performs
HTTP requests using this config. it will be reused for other power
meters (SML over HTTP(S)) and may be reused by other features in the
future (battery provider, solar power provider, etc.).
the extractUrlComponents method did extract username and password
from the URL and encoded it for basic authentication. however, the
respective result string was never used. we only perform basic
authentication if the auth type is "basic" and if username and
password were supplied through the respective inputs.
the parameters to peform an HTTP request by the HTTP(S)+JSON power meter
have been generalized by introducing a new config struct. this is now
used for all values which the HTTP(S)+JSON power meter can retrieve, and
also used by the HTTP+SML power meter implementation. we anticipate that
other feature will use this config as well.
generalizing also allows to share serialization and deserialization
methods in the configuration handler and the web API handler, leading to
de-duplication of code and reduced flash memory usage.
a new web UI component is implemented to manage a set of HTTP request
settings.
avoid additional conversions and avoid double for the fact that
calculations on type double are implemented in software, whereas
float is handled in hardware on ESP32.
this new class handles SML data. it uses the SML lib to decode values
and manages those. this de-duplicates code as the class is applicable
to all power meters that collect SML data.
this setting was not used. the baud rate for the SDM is set to 9600 in
the source code. until the baud rate being customizable is actually
required by somebody, we remove the setting altogether.
"powertotal" is always published and it is published by the base class
directly. other values are still published by the derived classes, but
use a base class method, which takes care that a common base topic is
used in particular.
instead of iterating a map with subscriptions, we now bind the target
variable to the callback, which is executed once a message is arrived.
this way, the target variable is already linked to the respective topic
when the callback is executed.
lock the mutex when writing the variable, as the MQTT callback is
executed in a different context (MQTT task) than the main loop task,
which otherwise accesses the variables.
it is important to separate the capabilities of each power meter
provider into their own class/source file, as the providers work
fundamentally different and their implementations must not be
intermangled, which made maintenance and improvements a nightmare
in the past.
this only changes line endings. inspect this commit with command `git
show <commit-sha> --ignore-space-at-eol` and it will tell you that the
commit appears to be "empty" (since all changes are whitespace changes
near the end of a line, which are ignored in that git show command).
the files to be changed were found and updated using this command:
find lib src include webapp/src -type f | \
xargs grep --binary-files=without-match --files-with-matches \
$(printf '\r\n') | xargs dos2unix
the following files were restored afterwards, as they are using CRLF
line endings in the upstream as well:
- lib/CMT2300a/cmt2300a_defs.h
- lib/README
- include/README
this updates the partition scheme for devices with 4 MB of flash memory
to have only a single app partition, doubling its size, but sacrificing
their OTA update capability. the replacement environment for
"generic_esop32" is called "generic_esp32_4mb_no_ota".
the new default partition scheme is targeted for devices with at least 8
MB of flash memory. the previous two app partitions are merged into one,
and one additional app partition of the same new size is added to the
back of the table. the change preserves the littlefs partition (position
and size), allowing for upgrades without loosing the configuration.
another new environment is added, called "generic_esp32_8mb", which uses
the new default partition layout.
environment "generic" is removed. it was merely a variant of
"generic_esp32" with some pins pre-defined. we want users to install a
pin_mapping.json and use the generic firmwares.
environments for boards that have no version with at least 8 MB of flash
memory are setup using the 4 MB partition layout (no OTA updates).
all users must flash the factory.bin for their respective environment
using esptool (or compatible software) using the USB port of their
board. in other words: updating to the new partition scheme using an OTA
update is NOT possible.
hint: the ESP32-S3 builds have a smaller code footprint. this means
ESP32-S3 boards can be updated using OTA without updating the partition
layout on the devices for some unspecified time longer, i.e., until
their firmware binary actually becomes too large for the old sketch
partition size.
the non-factory binary for generic_esp32_4mb_no_ota is NOT collected as
an artifact. going forward, users must update using the factory binary
and using the USB connection to their boards.
these fail due to the overflowing sketch partition. we can re-enable CI
build for these environments once we decided on how to handle ESP32 with
only 4MB of flash.
the "serial console" over USB would be garbled badly after switching to
"platform = espressif32@6.7.0". this did not happen to the upstream
version of MessageOutput. we used Serial.flush(), which seemed to be
good in the respective context. however, the changes in
github.com/espressif/arduino-esp32/pull/9462
made flush() detrimental. we remove the use of flush(), as it seems not
to be required (in particular, the upstream project does not use it).
broke in be41e6b9. was unusable as the complete type of DummySerial has
to be available in the JK BMS controller header when defining the
unique_ptr managing the dummy instance. this problem is solved by moving
the whole dummy class into its own header.
all total cards at the top of the live view go into the same row.
bootstrap will line-break after every third column/card, as the row
is row-cols-3.
the battery icon to the right of the project name in the header shall
have marging to said project name.
the rows in the live view now use class mt-0 to counteract bootstraps
negative margin for individual rows.
instead of hard-coding the use of hardware UART 2, the SDM power meter
instance now asks for a free hardware serial port to use and
instanciates the respective HardwareSerial object using said port.
get rid of particular compile-time designations by UART index. just hand
out the next free index of hardware UARTs, or indicate that none is
available any more.
use names as keys to register and free UARTs.
only on ESP32-S3-USB. this fiddles with the available hardware UARTs to
make it possible to use a third Victron MPPT. if three MPPTs are defined
int the pin mapping, you will not be able to use the SmartShunt and JK
BMS battery interfaces.
note that using a second MPPT will also conflict with the SDM power
meter, and that conflict is not detected, yet.
this implements accessing array members in an ArduinoJSON object
following the FirebaseJson syntax. the FirebaseJson lib was previously
removed to save flash memory, and logic was implemented to find a JSON
node using the FirebaseJson path syntax, restoring the functionality.
however, array access was not implemented.
this change also addresses leading and trailing and double forward
slashes in the path expression.
moreover, much more expressive error messages are now generated in case
the path could not be resolved.
this implements accessing array members in an ArduinoJSON object
following the FirebaseJson syntax. the FirebaseJson lib was previously
removed to save flash memory, and logic was implemented to find a JSON
node using the FirebaseJson path syntax, restoring the functionality.
however, array access was not implemented.
this change also addresses leading and trailing and double forward
slashes in the path expression.
moreover, much more expressive error messages are now generated in case
the path could not be resolved.
mbedtls is already integral part of the firmware. use it in favor of
rweather/Crypto library to calculate a sha256 checksum of a string, as
used in the HTTP power meter implementation.
we used this library solely to interpret the answer of an HTTP web
server as JSON and find a particular value using a path expression in
the HTTP power meter implementation.
since we ran out of flash memory on non-S3 ESP32, we need to cut some
corners. removing FirebaseJson is the last low-hanging fruit that we
currently know of. we can get rid of it by using ArduinoJson (which is
already integral part of the firmware) and implementing a custom logic
to extract a value based on a path expression.
other than the FirebaseJson path "finder", the new implementation
only knows how to access sub-keys delimited by a forward slash. in
particular, accessing array members is not supported any more. I am
hoping that this is simply not an issue. if so, we will have users
complaining and we can add this functionality in a later release.
when calculating efficiency, we need to take into account that the load
might also sink a significant amount of current and power, which adds to
the total output of the charge controller.
merge upstream tag v24.4.12, resolve conflicts (helgeerbe), fix eslint errors (schlimmchen) and adopt new web api method to save code duplication (schlimmchen).
this allows to use two VE.Direct interfaces, as there is no conflict
regarding HW serial port 2 after making the battery interfaces use
serial port 0 on devices with USB CDC. on those chips HW serial 0 is
free to be used since serial messages are written through the USB
interface directly.
we found that the inverter sometimes stops responding to commands,
especially to the "start producing" command. we now count the number of
consecutive timeouts when trying to send a new limit or power state
commands. after two timeouts were recorded, every additional timeout
will send a restart command to the inverter.
as a last resort, if the counter keeps climbing, the DTU is restarted.
notice that this only targets unresponsive inverters which are
reachable. unreachable inverters are not restarted and do not cause a
DTU reboot. this is important for solar-driven inverters, which are
unreachable during the night. the DPL will not calculate a new limit and
hence the updateInverter() method will do nothing while the target
inverter is unreachable.
publish the timeout counter to MQTT for monitoring purposes.
avoid performing a calculation based on a (slightly) outdated power
meter reading, which was aquired just before the limit was actually
applied by the inverter, but which was received by OpenDTU-OnBattery
after the inverter stats.
without a power meter configured, the DPL now sets the base load as the
inverter limit if the battery charge allows it. it also takes
solar-passthrough into account, i.e., if the battery is in a charge
cycle but the solar output (Victron MPPT) is significant, the solar
power will be used up until the base load. if the battery reaches the
full solar passthrough threshold, the DPL will match the inverter limit
to the MPPT solar output.
on power meter issues (usually a timeout), keep the inverter enabled and
make it produce the configured base load limit if the battery can be
discharged. that should be okay since the base load config value is
expected to be small and a little less than the actual household base
load, i.e., if this amount of power is produced, the household will
consume it in any case and no energy is fed into the grid.
makes the value match its description. since most values in the top part
of the live view are related to the AC side of the system, it makes
sense to use the correct value rather than to change the description.
* process "IL", "AR" and "MON"
* discard "BMV" and (unsolicited) History Data
* simplify isDataValid()
* veMpptStruct, veStruct: new, verbose variable names, including units,
and replace floats (save values with original integer precision)
* comment on rollover situation in isDataValid()
1. makes the DPL use the power generated by all connected charge
controllers for calculations based on solar passthrough.
2. makes the network total DC power appear as "MPPT Total Power" in the
live view at the top.
3. shows the network total DC power in the VE.Direct live data card.
* show charge controller temperature in live view
* send hex requests right after decoding a frame. this seems to have the
best chance of getting an answer to all requests.
* deem 0xFFFFFFFF value of network total DC power as invalid indicator.
neither network state, nor network info, nor network mode seem to
indicate that the charge controller is part of a VE.Smart network. for
that reason, we revert to always querying the network total DC power
value, but testing it for max(uin32_t) value, which seems to indicate
that the charge controller is not part of a VE.Smart network.
* improve (verbose) logging, e.g., use _logId, and print names of
response codes and known registers, always print error messages,
add additional tests to prevent overly verbose messages.
* move hex protocol definitions to VeDirectData.h header
and use enum classes
* define register addresses in enum class
* move values retrieved through hex protocol into main MPPT data struct
* do not send HEX requests if the serial interface cannot send data
* detect whether smart battery sense temperature is available
* web app: make all VE.Direct sub-cards iterable. this makes addind more
values much simpler and saves a bunch of code in the web app.
* make VeDirectFrameHandler state a type-safe enum class
* unindent MPPT controller loop()
* whitespace cleanup
double precision floating point numbers are not needed to handle
VE.Direct values. handling double is implemented in software and hence
*much* more resource intensive.
queue every text event until the frame was checked by it checksum. then
process the data directly into the buffer struct. do not clear the
buffer struct, so it will always include the most recent value of a
particular data point.
if only a single request was made (switch "Individual HTTP requests per
phase" is off), the user could still enable phase 2 and phase 3 config
and configure a respective JSON path. however, the value was never
extracted from the successful HTTP request for phase 1.
closes#637.
users are manipulating the DPL using HTTP POST requests. often they are
requesting the current settings using HTTP GET on the respective route,
then change a particular settings, and send all the data back using HTTP
POST. if they failed to remove the metadata node from the JSON,
OpenDTU-OnBattery would not be able to process the JSON due to its size.
the web app does not submit the metadata.
to avoid problems, the metadata is now split from the configuration
data.
this method calls the overflowed() method on the respective
DynamicJsonDocument and prints a respective message if not all
data could be added to the DynamicJsonDocument.
in case the user defines the respective pins, an MPPT controller will be
setup and the websocket would previously publish its invalid data even
if no data at all was received. this lead to using an invalid index and
to publish a useless card. instead, skip those controllers.
if the connection to a controller breaks, it will always present as a
card in the live view with the respective serial number and the last
known data.
PLLIMIT would not (always) be part of the JSON string transmitted to the
web application and trip it. with the help of the ArduinoJson assistant,
new values to use in the response size calculation were introduced.
also, importantly, a constant offset was added for the DPL status and
the JSON structure sourrounding the MPPTs.
* updating the SoC or value shall also update the general timestamp, as
the latter is defined as "any value changed", which includes SoC and
voltage, of course.
* if the last update is not a valid timestamp at all, the
updateAvailable method must always return false, obviously.
on the "main" live data websocket this can happen if no
OnBattery-specific data is available to sent but the empty
JSON document is still sent, which trips the web application.
publishing null in the battery live data websocket also trips the web
application, which rightfully assumes a valid object if data is received
through the websocket.
determine the amount of controllers actually in use dynamically,
especially to avoid indices which are invalid, causing an error
to be printed, even though the user did not do anything wrong.
in your pin_mapping.json, add a powermeter object like this:
[
{
"name": "My Board",
...
"powermeter": {
"rx": <num>,
"tx": <num>,
"dere": <num>
},
...
}
]
the SML power meter requires the rx pin to be set. the SDM power meter
requires the rx and tx pins are set. the "dere" pin pin is optional and
if set, this pin controls the driver enable and receiver enable pins of
the RS485 transceiver. the SDM library handles this pin.
closes#771.
* remove/comment unused variables to avoid compiler warnings
* cleanups: fix indention and style, make variable private, implement
getters in header and make const.
* optimize message output: respect verbose logging setting. prefix
output with SMA_HM.
* use newly introduced mutex in PowerMeterClass also for SMA HomeManager
* refactor code for readibility, unindent where possible.
the SDM power meter (among others) writes the power consumption of three
phases in multiple steps. this change helps to prevent getTotalPower()
reading intermediate values, e.g., reading a new value for phase 1 but
old values for phase 2 and 3 since phase 2 is currently read.
cache the values, and write them all at once, protected by a mutex,
later.
closes#732.
this changeset refactors the web application's DPL settings view. the
DPL settings can be complex, and they shall be presented in a way that
allows users to comprehend their meaning. irrelevant settings are now
hidden or displayed dynamically based on the influencing settings.
* group SoC thresholds into their own card
* hide battery SoC thresholds if battery disabled. if the user did not
even enable the battery interface, battery SoC values will not be used
for DPL decisions. in that case we completely hide the respective
settings from the DPL admin view. this reduces the amount of settings
for new users and especially users who don't even have a battery in
their setup or have no BMS connected.
* group voltage thresholds and improve label texts
* fix load correction factor unit
* fix header (wording)
* group solar-passthrough settings in new card
* group inverter-related settings
* hide solar passthrough settings if VE.Direct is disabled. closes#662.
* completely disable form if any requirement is not met
* list available inverters by name and type. this makes it much more
convenient to select the right inverter, especially since the order of
the inverters in the web UI is decoupled from their position in the
internal array, which was used to select them previously. care was
taken that old configs select the same inverter after an update.
when editing the DPL settings, the selects an inverter from the newly
created drow-down list, and the respective old inverter is
pre-selected.
* disable form if no inverter is configured (config alert)
* make inverter input selection dynamic. adjust selection to actual
amount of channels for selected inverter. skip selection altogether if
inverter has only one channel, or if it is solar powered.
* web app: wording adjustments
* group meta data into new property and exclude from submission. saves
memory when evaluating the submitted settings.
* hide irrelevant settings if inverter is solar-powered
* move restart hour setting to inverter card. translate setting which
disabled automatic restart.
* simplify "drain strategy" setting into an on/off toggle. care was
taken that existing configs work the same after an upgrade. the
respective drain strategy is translated into the new setting when
reading the config. once the config is written, the new setting is
persisted and the old is not part of the config any more.
* show more configuration hints, depending on actual configuration
* replace inputs by InputElement components where possible
* 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.
* make efficient use of available display area
fix calculation of the text baselines, using getAscent() in favor of
getMaxCharHeight(), which includes ascent and descent. this moves the
first text up and allows to insert margin between the lines until the
display area is fully utilized.
on large displays, if the small diagram is selected, keep the first line
rather low to avoid collision with the diagram y-axis label. in this mode,
there is still more space between the text lines as before, allowing for
improved readability.
* Feature: show power grid usage on display
if the power meter is enabled, the display will use two of three out
of every three-second time slot to show the grid consumption.
closes#620.
the DPL is interested in the battery's voltage to make decisions about
draining the battery or letting it charge (if the user opts to use
voltage thresholds rather than SoC thresholds). using the DC input
voltage reported by the inverter under control has disadvantages:
* the data might be quite old due to the communication protocol
implementation. more inverters being polled means even more lag. the
connection being wireless makes this even worse, due to the need
to retry the occasional lost packet, etc.
* the data is not very accurate, since the DC input of the inverter is
actually some cabling and a couple of junctions away from the actual
battery. this voltage drop can mostly only be estimated and is worse
with higher load. the load correction factor is there to mitigate
this, but it has its own problems and is cumbersome to calibrate.
instead, this change aims to use more accurate battery voltage readings,
if possible. the DPL now prefers the voltage as reported by the BMS,
since it is for sure the closest to the battery of all measuring points
and measures its voltage accurately regardless of the load (the voltage
reading will still drop with higher loads, but this will be only due to
the battery's internal resistance, not that of cabling or junctions). if
no BMS voltage reading is available, the DPL will instead use the charge
controller's voltage reading, as it is available with much higher
frequency and is assumed to be more accurate as it offers a resolution
of 10mV. only if none of these two sources can be used, the inverter DC
input voltage is assumed as the battery voltage.
closes#655.
the Victron SmartShunt communicates the SoC value in permille. this
should be displayed in the web UI accordingly. this is a good excuse to
fully move ownership of the SoC value to the BatteryStats base class and
add a precision indicator variable. this is required to be set each time
a derived class (a battery provider) wants to update the SoC value. the
precision is then used when populating the JSON data for the web UI
(live view).
related to #573.
in the respective context, the DPL only needs to be sure that the SoC
value is not outdated. it should not even care about other values
reported by the battery interface. hence, the isValid() method shall be
concerned with the SoC value timestamp only. the method is renamed for
clarity.
this extends the MqttBattery implementation by an additional topic which
allows to subscribe to receive battery voltage readings through the MQTT
broker. similar to the battery SoC topic, this allows to import a
critical battery data point for the DPL, in case the user chooses to use
voltage thresholds rather than SoC thresholds to control the DPL. if an
otherwise incompatible BMS is available which publishes the battery pack
voltage through MQTT, this can now be used to feed accurate voltage
readings to the DPL.
the BatteryStats base class shall be able to tell the total battery pack
voltage. for that reason, and to avoid code duplication, the voltage is
now handled in the base class and treated as a datum that is common to
all battery providers.
unfortunately, the battery SoC values reported by battery BMSs are
unreliable, at least for some users, or at least without regular
(manual) full charge cycles to calibrate the BMS. it offers great
advantages to connect OpenDTU-OnBattery to a BMS (MQTT publishing of
values, Home Assistent integration, etc.), but previously the users
were then forced to configure the DPL by SoC values.
this change allows to configure the DPL such that SoC values are
ignored. instead, the voltage limits are used to make DPL decisions, as
if no SoC was available in the first place.
the SoC related setting are hidden from the DPL settings view if SoC
values are configured to be ignored.
closes#654.
* pylontech HA integration: remove unused method/variable
* make MqttHandlePylontechHassClass::publishConfig() private.
there are no outside users of that method.
* rename to MqttHandleBatteryHass
* battery HA integration: merge methods and bring back forceUpdate().
even though the forceUpdate() method was not in use before, it makes
sense to implement it and use it when the battery config changes.
rather than controlling a separate flag, it now changes the _doPublish
flag of the class, which also triggers publishing the device config to
Home Assistant when an MQTT connection problem was detected. since
both situations are now handled similarly, we can merge the loop() and
publishConfig() methods.
* battery: provider specific sensors for HA
* move Battery MQTT loop to BatteryStats
the BatteryStats class should handle the MQTT publishing, including the
interval. for the calculation of a reasonable Home Assistent expiration
value this class now also knows the maximum publish interval.
* JK BMS: fix publishing values for Home Assistent
Home Assistent values expire, because we set them to expire after three
MQTT publish durations. for that reason, we need to re-publish all
values after our self-inflicted full publish interval.
* define JK BMS sensors for Home Assistent
closes#482.
previously, the Pytlontech Home Assistent class implementation had an
init() method, that was never called, as it did nothing. the class
relied on its loop() method being called from the main loop(). after
switching to the TaskScheduler approach, the Pylontech Home Assistent
class init() method was adjusted to register a task that calls the
loop() method periodically. however, the init() method was still not
called.
There is no convenient way to access arrays of Json objects and nested keys such as testarray/[2]/myvalue using ArduinoJson. It would at the very least to split the path into a number of individual strings and then access the value like json[testarray][2][myvalue] More details in https://arduinojson.org/v6/doc/deserialization/ . Conclusion: too complicated.
currently the whole SmartShunt data structure is copied to the
BatteryStats instance in every loop, even though the data cannot
possibly have changed. this is quite an expensive task to do in every
loop. this change tracks the last update timestamp and only does the
copy operation if an actual updated data structure was received from
the smart shunt.
the TaskScheduler runs in the context of a FreeRTOS thread/task. there
are other such threads (MQTT client and web server in particular). to
allow changing TaskScheduler task properties from different threads, we
need to enable the use of a mutex to protect the TaskScheduler.
this change adds the values of ESP.gteMaxAllocHeap() and
ESP.getMinFreeHead() to the prometheus metrics and the system
information object. the web UI uses these values to diplay the size of
the largest free contiguous block, calculate a rough estimate for the
level of fragmentation, and the maximum usage of heap memory since boot
in absolute and relative amounts.
OpenDTU console gets spammed with "WifiGeneric::hostByName() error when first trying to resolve the hostname via DNS. So reverse order: first try mDNS, if that fails try DNS. Also ensure that https bool is passed correctly to HTTPClient::begin(). Lastly, concatenate strings for building Digest authorization using "+" and not via snprintf.
this change utilizes some of the features from library "frozen", which
was included upstream for the grid profile parser. to improve code
maintainability, a couple of std::maps mapping strings to values or the
other way around were introduced in OpenDTU-OnBattery-specific code at
the expense of some flash and computing overhead.
library "frozen" offers constexpr versions of map and string, which
saves initialization code and offers slightly faster lookups. this
brings the binary size down by ~25kB and should provide a small
performance improvement at runtime.
Added ability to deal with local host names (mDNS), remove use of FirebasedJson to save ~20kB build size, some changes to PowerLimiter to avoid setting new inverter power limits when not needed (=current limit as reported by inverter is within hysteresis)
this battery provider implementation subscribes to a user-configurable
MQTT topic to retrieve the battery SoC value. the value is not
re-published under a different topic. there is no card created in the
web app's live view, since the SoC is already part of the totals at the
top of the live view. that is the only info this battery provider
implements.
closes#293.
relates to #581.
MQTT message callbacks are executed in the MQTT thread context. when
processing topics that control the DPL, we must avoid executing methods
that are not thread-safe. this change binds the methods to be called to
the respective parameters and executes them in the TaskScheduler
context, such that they no longer need to be thread-safe.
* bind the callback to a topic (enum value) such that there is no need
to tokenize the full topic (string) to find out what value is being
processed. tokenizing is expensive.
* get rid of using the config in the callback, which improves
thread-safety since the MQTT callback is running in the MQTT thread.
* prefer C++ method stof to convert MQTT value to a float, which saves
us from using new and delete for a buffer in particular.
* prefer switch statements over if-else-trees.
* split long lines.
* get rid of topic #defines.
* fix indention.
MQTT message callbacks are executed in the MQTT thread context. when
processing topics that control the huawei AC charger, we must avoid
executing methods that are not thread-safe. this change bound the
methods to be called to the respective parameters and executes them
in the TaskScheduler context, such that they no longer need to be
thread-safe.
there are more interesting values available to display in the live view.
however, adding them made the list of values very long. this can be
mitigated by using a new column/card, which uses the available screen
space nicely on bigger screens.
the upstream project introduced a new Vue component "FormFooter", which
is used to end an input form, namely all settings forms. we should not
only use this component as well, but the save button on our forms
actually broke since the text dtuadmin.Save is replaced by base.Save.
also replace the use of dtuadmin.Seconds with base.Seconds, such that an
upstream change to dtuadmin.Seconds will not break the battery admin an
AC charger views.
this commit re-introduces the changes from #418, which were effectively
reverted with d49481097 (merge commit introducing TaskScheduler).
these adjustments are important to guarantee unmangled log messages and
more importantly, to guarantee that all messages from a particular
component are printed to the web console, which most people use to copy
messages from when reporting issues.
* use dynamic memory to allow handling of arbitrary message lenghts.
* keep a message buffer for every task so no task ever mangles the
message of another task.
* every complete line is written to the serial console and moved to
a line buffer for sending them through the websocket.
* the websocket is always fed complete lines.
* make sure to feed only as many lines as possible to the websocket
handler, so that no lines are dropped.
* lock all MessageOutput state against concurrent access.
* respect HardwareSerial buffer size: the MessageOutput class buffers
whole lines of output printed by any task in order to avoid mangling
of text. that means we hand over full lines to the HardwareSerial
instance, which might be too much in one call to write(buffer, size).
we now check the return value of write(buffer, size) and call the
function again with the part of the message that could not yet be
written by HardwareSerial.
the updateSettings method is called from the web server's context and
therefore accesses _upProvider in a different context than the
TaskScheduler. the lock_guard needs to protect _upProvider.
* Optimize Sun data calculation
* Remove not required enum
* Split config struct into different sub structs
* Feature: Allow configuration of LWT QoS
* Made resetreason methods static
* Feature: Implement offset cache for "YieldDay"
Thanks to @broth-itk for the idea!
Fix: #1258#1397
* Add Esp32-Stick-PoE-A
* remove broken LilyGO_T_ETH_POE config, use device profile instead
* Feature: High resolution Icon and PWA (Progressive Web App) functionality
Fix: #1289
* webapp: Update dependencies
* Initialize TaskScheduler
* Migrate SunPosition to TaskScheduler
* Migrate Datastore to TaskScheduler
* Migrate MqttHandleInverterTotal to TaskSchedule
* Migrate MqttHandleHass to TaskScheduler
* Migrate MqttHandleDtu to TaskScheduler
* Migrate MqttHandleInverter to TaskScheduler
* Migrate LedSingle to TaskScheduler
* Migrate NetworkSettings to TaskScheduler
* Migrate InverterSettings to TaskScheduler
* Migrate MessageOutput to TaskScheduler
* Migrate Display_Graphic to TaskScheduler
* Migrate WebApi to TaskScheduler
* Split InverterSettings into multiple tasks
* Calculate SunPosition only every 5 seconds
* Split LedSingle into multiple tasks
* Upgrade espMqttClient from 1.4.5 to 1.5.0
* Doc: Correct amount of MPP-Tracker
* Added HMT-1600-4T and HMT-1800-4T to DevInfoParser
Fix#1524
* Adjusted inverter names for HMS-1600/1800/2000-4T
* Add channel count to description of detected inverter type (DevInfoParser)
* Adjust device web api endpoint for dynamic led count
* Feature: Added ability to change the brightness of the LEDs
Based on the idea of @moritzlerch with several modifications like pwmTable and structure
* webapp: Update dependencies
* Update olikraus/U8g2 from 2.35.7 to 2.35.8
* Remove not required onWebsocketEvent
* Remove code nesting
* Introduce several const statements
* Remove not required AsyncEventSource
* Doc: Added byte specification to each command
* Feature: Added basic Grid Profile parser which shows the used profile and version
Other values are still outstanding.
* Optimize AlarmLogParser to save memory
* Add libfrozen to project to create constexpr maps
* Feature: First version of GridProfile Parser which shows all values contained in the profile.
* webapp: Update dependencies
* Apply better variable names
* Remove not required casts
* Add additional compiler flags to prevent errors
* Add const statement to several variables
* Replace NULL by nullptr
* Update bblanchon/ArduinoJson from 6.21.3 to 6.21.4
* Add const keyword to method parameters
* Add const keyword to methods
* Use references instead of pointers whenver possible
* Adjust member variable names in MqttSettings
* Adjust member variable names in NetworkSettings
* webapp: Update timezone database to latest version
* webapp: Beautify and unify form footers
* Feature: Allow setting of an inverter limit of 0% and 0W
Thanks to @madmartin in #1270
* Feature: Allow links in device profiles
These links will be shown on the hardware settings page.
* Doc: Added hint regarding HMS-xxxx-xT-NA inverters
* Feature: Added DeviceProfile for CASmo-DTU
Based on #1565
* Upgrade actions/upload-artifact from v3 to v4
* Upgrade actions/download-artifact from v3 to v4
* webapp: add app.js.gz
* Gridprofileparser: Added latest known values
Thanks to @stefan123t and @noone2k
* webapp: Fix lint errors
* Feature: Add DTU to Home Assistant Auto Discovery
This is based on PR 1365 from @CFenner with several fixes and optimizations
* Fix: Remove debug output as it floods the console
* Fix: Gridprofileparser: Add additional error handling if profile is unknown
* webapp: add app.js.gz
* Fix: Offset cache for "YieldDay" did not work correctly
* webapp: update dependencies
* webapp: add app.js.gz
* Fix: yarn.lock was outdated
* Fix: yarn build error
* Fix: Reset Yield day correction in combination with Zero Yield Day on Midnight lead to wrong values.
* Fix: Allow negative values in GridProfileParser
* Correct variable name
* Fix#1579: Static IP in Ethernet mode did not work correctly
* Feature: Added diagram to display
This is based on the idea of @Henrik-Ingenieur and was discussed in #1504
* webapp: update dependencies
* webapp: add app.js.gz
---------
Co-authored-by: Thomas Basler <thomas@familie-basler.net>
Co-authored-by: Pierre Kancir <pierre.kancir.emn@gmail.com>
* add more values to web app live view. this should add all interesting
values for the web app live view. those include important values and
values that change frequently.
* add more interesting JK BMS dummy messages: one has 0% SoC and an
alarm (discharge undervoltage) set. the other has the undertemperature
alarm set.
* add alarms and warnings to live view
* publish alarm and status bits through MQTT individually
* publish cell voltages to MQTT broker
* remove trailing spaces in BatteryStats class
* VE.Direct: return non-nullptr as a fallback
the changed return statement was supposed to return a shared_ptr to a
new and valid MPPT data struct as a fallback. however, it did return a
new shared_ptr that was initialized to nullptr.
* VE.Direct: make liveview total use total MPPT values
this change makes the call to VictronMppt.getData() obsolete, which in
turn will therefore not cause an error message on the console if
VE.Direct (MPPT) is not enabled. this change also takes care that once
multiple VE.Direct MPPT charge controllers are supported, the sums of
the respective total values are used in the web app totals.
* introduce VictronMpptClass
this solves a design issue where the loop() method of a static instance
of VeDirectMpptController, which is part of library code, is called as
part of the main loop() implementation. that is a problem because the
call to this loop() must be handled differently from all other calls:
the lib does not know whether or not the feature is enabled at all.
also, the instance would not be initialized when enabling the feature
during normal operation. that would even lead to a nullptr exception
since the pointer to the serial implementation is still uninitialized.
this new intermediate class is implemented with the support for multiple
Victron charge controllers in mind. adding support for more charge
controllers should be more viable than ever.
fixes#481.
related to #397#129.
* VE.Direct: move get.*AsString methods to respective structs
those structs, which hold the data to be translated into strings, know
best how to translate them. this change also simplifies access to those
translation, as no parameter must be handed to the respective methods:
they now act upon the data of the instance they are called for. adds
constness to those methods.
* VE.Direct: simplify and clean up get.*AsString methods
use a map, which is much easier to maintain and which reads much easier.
move the strings to flash memory to save RAM.
* DPL: use VictronMpptClass::getPowerOutputWatts method
remove redundant calculation of output power from DPL. consider
separation of concern: VictronMpptClass will provide the total solar
output power. the DPL shall not concern itself about how that value is
calculated and it certainly should be unaware about how many MPPT charge
controllers there actually are.
* VE.Direct: avoid shadowing struct member "P"
P was part of the base struct for both MPPT and SmartShunt controller.
however, P was also part of the SmartShunt controller data struct,
shadowing the member in the base struct.
since P has slightly different meaning in MPPT versus SmartShunt, and
since P is calculated for MPPT controllers but read from SmartShunts, P
now lives in both derived structs, but not in the base struct.
* VE.Direct: isDataValid(): avoid copying data structs
pass a const reference to the base class implementation of isDataValid()
rather than a copy of the whole struct.
* VE.Direct: unify logging of text events
* VE.Direct: stop processing text event if handled by base
in case the base class processed a text event, do not try to match it
against values that are only valid in the derived class -- none will
match.
* VE.Direct MPPT: manage data in a shared_ptr
instead of handing out a reference to a struct which is part of a class
instance that may disappear, e.g., on a config change, we now manage the
lifetime of said data structure using a shared_ptr and hand out copies
of that shared_ptr. this makes sure that users have a valid copy of the
data as long as they hold the shared_ptr.
* VE.Direct MPPT: implement getDataAgeMillis()
this works even if millis() wraps around.
* VE.Direct: process frame end event only for valid frames
save a parameters, save a level of indention, save a function call for
invalid frames.
avoid staleness in case the same power limit is calculated over and over
again, hence no new power limit value is calculated and hence no power
limit command is sent to the inverter. staleness occurs in this case if
the first power limit command to establish the respective limit was not
received by the inverter. one can easily simulate a situation where the
same power limit is caluclated over and over again: with a battery above
the start threshold, set a very low upper power limit for the inverter
(DPL setting). that value will be used as the limit as long as the power
meter reading is larger than that.
we could also check the limit reported by the inverter. however, that
value is in percent of the inverter's max AC output, and is often not
the same value as we requested as the limit, but slightly off. we then
would have to decide how much deviation is okay, which is unreasonably
complicated.
closes#478.
* VE.Direct MPPT MQTT: remove trailing whitespace
* VE.Direct MPPT MQTT: publish P, IPV and E to MQTT
those values are calculated by OpenDTU-OnBatery and are part of the web
application live view, but were previously not published through MQTT.
closes#376.
* Move Mppt logic to subclass
* Added Definitions for Shunts and restructering
* First integration of SmartShunt data into Web Interface
* Code cleanup
* VE.Direct: whitespace cleanup
* VE.Direct: manage HardwareSerial in unique_ptr
* VE.Direct: _efficiency is only needed by MPPT
* VE.Direct: keep as many members private as possible
* VE.Direct: use int8_t for pins (as before)
* VictronSmartShunt: _verboseLogging is not used
* VE.Direct: OR (off reason) is MPPT specific
it also applies to Phoenix inverters and Smart BuckBoost, but since
there is no support for those, the code is moved to the MPPT controller.
* Added Shunt alarms to liveview
Changed from double to int for several readings
* Update build.yml to allow manual builds
---------
Co-authored-by: Philipp Sandhaus <philipp.sandhaus@cewe.de>
Co-authored-by: Bernhard Kirchen <schlimmchen@posteo.net>
for the MQTT integration, JkBms::DataPointContainer::updateFrom() was
changed such that the data points timestamp reflects the last change of
the data point value. that timestamp was used to set the SoC last update
timestamp. however, that timestampt must reflect the last time the SoC
was successfully received from the JK BMS so we could make sure the
value was up to date.
* JK BMS: avoid trailing whitespace in debug output
* JK BMS: publish data points through MQTT
* JK BMS: updateFrom: skip data points with equal value
this changes the interpretation of the timestamp in data containers that
are merely updated from other data containers: this is the oldest
timestamp known where the value was as recorded by the data point in its
respective container.
the data container constructed from an answer will -- naturally -- have
the timetamps of its data points set to the time they were constructed.
* JK BMS: only publish changed values to MQTT broker
all values are still published once every minute if the MQTT retain flag
is NOT set. otherwise, the constant values are only published once on
startup.
* JK BMS: avoid trailing whitespace in debug output
* JK BMS: publish data points through MQTT
* JK BMS: updateFrom: skip data points with equal value
this changes the interpretation of the timestamp in data containers that
are merely updated from other data containers: this is the oldest
timestamp known where the value was as recorded by the data point in its
respective container.
the data container constructed from an answer will -- naturally -- have
the timetamps of its data points set to the time they were constructed.
* JK BMS: only publish changed values to MQTT broker
all values are still published once every minute if the MQTT retain flag
is NOT set. otherwise, the constant values are only published once on
startup.
this avoids the debug buffer being overrun if verbose logging is
disabled in particular. that would happen because the buffer would
only be reset if verbose logging was enabled but filled in any case.
* thread-safety and dynamic memory for MessageOutput
* use dynamic memory to allow handling of arbitrary message lenghts.
* keep a message buffer for every task so no task ever mangles the
message of another task.
* every complete line is written to the serial console and moved to
a line buffer for sending them through the websocket.
* the websocket is always fed complete lines.
* make sure to feed only as many lines as possible to the websocket
handler, so that no lines are dropped.
* lock all MessageOutput state against concurrent access.
* MessageOutput: respect HardwareSerial buffer size
the MessageOutput class buffers whole lines of output printed by any
task in order to avoid mangling of text. that means we hand over full
lines to the HardwareSerial instance, which might be too much in one
call to write(buffer, size). we now check the return value of
write(buffer, size) and call the function again with the part of the
message that could not yet be written by HardwareSerial.
* VE.Direct: reset state machine on timeout
there will never be a large gap between two bytes of the same frame.
if such a large gap is observed, reset the state machine so it tries
to decode a new frame once more data arrives.
this is helpful in case of corrupted data that prevents the state
machine of transitioning to the final state even though the VE.Direct
data producer is done sending bytes that belong to the same frame.
* VE.Direct: print problems to MessageOutput
this includes the web console in particular, where many users have
access to while the serial console is not attached or monitored.
* VE.Direct: collect serial input into buffer and print
should help debug issues for users.
* VE.Direct: implement and use verbose logging switch
* add Icons for Battery and Victron device sensors in Home Assistant
overriding the boring default icon for many sensors
Signed-off-by: Martin Dummer <martin.dummer@gmx.net>
* fix: homeassistant autodiscovery topics
homeassistant autodiscovery topics contain not allowed characters, which
are now fixed.
Sidenote: when autodiscovery messages were retained, the badly formatted messages
must be removed from the mqtt server manually. Otherwise the error
messages in homeassistant will persist.
Closes: https://github.com/helgeerbe/OpenDTU-OnBattery/issues/378
Signed-off-by: Martin Dummer <martin.dummer@gmx.net>
* Fix: some homeassistant autoconf messages are wrong
Misc fixes for HA autoconfiguration:
* Entity sensor.panel_yield_today now uses state class "total"
* Entity sensor.panel_yield_yesterday now uses state class "total"
* Entity sensor.mppt_day_sequence_number_0364 now shows correct value
* sensor.panel_power duplicate removed
Closes: https://github.com/helgeerbe/OpenDTU-OnBattery/issues/379
Signed-off-by: Martin Dummer <martin.dummer@gmx.net>
---------
Signed-off-by: Martin Dummer <martin.dummer@gmx.net>
* DPL MQTT handler: modernize
* there is no need to tokenize and check the topic of a received MQTT
message if we only subscribe to a single topic. all messages will be
for that topic. avoid testing the topic in the callback alltogether.
* use std::string and std::stoi over allocating and deleting a buffer
and copying charactes around.
* use a switch statement to process the actual payload.
* break a long line.
* DPL: fix getMode() return value
getMode() returned a bool. probably its return type was not adjusted
when the third mode was introduced. this lead to mode 2 being cast to
true implicitly, which in turn was used to construct a String, such that
"1" was published as the DPL mode when in fact it was 2.
make the mode an enum class to avoid such problems in the future.
inline getMode() and setMode().
fix indention.
the size allocated for the HTTP request response was too little, while
the size for the buffer of the websocket output was increased already.
add a new member variable and use it in both context, such that
increasing the buffer size to accomodate more space (for the JSON data
in particular) will benefit both contexts in the future.
instead of hiding views, we can also avoid adding them to the DOM. this
has a couple of advantages:
* no HTTP request for data is sent and no websocket connection is
established for disabled features.
* JavaScript that causes errors due to incomplete or incompatible data
of features that are disabled anyways do not trigger the browser
debugger.
* DPL: improve verbose logging
* shorten DPL log prefix
* canUseDirectSolarPower() was printed two times
* _batteryDischargeEnabled was printed two times
* convert boolean values to human-readable strings
* add units where possible
* split messages into block "before calculating new limit" and "after
calculating new limit", as the latter cannot rely on _inverter being
available.
* order messages such that variables whose value is derived from other
variables are printed later than their dependencies.
* merge output into blocks (one instance near "Printout some stats")
* remove more redundant info (produced in functions outside loop())
* print target grid consumption
* DPL: inhibit solar passthrough while stop threshold reached
* DPL: implement and use isBelowStopThreshold()
we only want to inhibit solar passthrough if the SoC is *below* the stop
threshold, not if it is equal to the stop threshold. otherwise, when
discharging, we would discharge until the battery reached the stop
threshold, then we would also inhibit solar passthrough, until the
battery is charged to the SoC stop threshold plus one percent.
processing a published valued on a subscribed topic is currently running
in a task that is not the task executing the main loop(). that's because
the espMqttClient(Secure) was constructed without arguments, which
selects the constructor with two arguments priority and core, both of
which have default values. that constructor selects
espMqttClientTypes::UseInternalTask::YES, causing a task to be created
in which context the MQTT client loop is executed.
MQTT subscribers assume they are running in the same context as the main
loop(). most code assumes exactly that. as the scheduler is preemptive
and very little (none at all?) code is interlocked, we have to make sure
to meet the programmer's expectations.
this changeset calls the MQTT client loop in the context of the main
loop() and enforces the use of espMqttClientTypes::UseInternalTask::NO.
* MQTT verbose logging: fix typo
this typo caused that verbose logging was always disabled for MQTT and
could not be enabled.
* webapp status: show MQTT verbose logging setting
* PowerMeter: gracefully handle non-float MQTT values
* PowerMeter: update _lastPowerMeterUpdate conservatively
update the timestampt only if the topic actually matched any
subscription and if the value could be parsed as a float.
* PowerMeter: unsubscribe before subscribing
* PowerMeter: organize subscriptions in a map
this allows for a slightly more elegant code and reduced amount of code
overall.
* PowerMeter: clean up header
* move private methods to private section of class declaration.
* remove unused member variable.
* DPL: implement verbose logging switch
* MQTT: implement verbose logging switch
* power meter: implement verbose logging switch
* Hoymiles lib: implement verbose logging switch
* cpp linting: "final" makes "virtual" and "override" redundant
... however, using only "final" is not as verbose.
adjust window-title and header from OpenDTU to OpenDTU-onBattery
Additionally change orientation of battery symbol to vertically centered
(looks nicer)
Signed-off-by: Martin Dummer <martin.dummer@gmx.net>
When OpenDTU has a Pylontech CAN Bus Battery connected and enabled, this
patch adds the discovery routine for Home Assistant
Signed-off-by: Martin Dummer <martin.dummer@gmx.net>
if the new calculated power limit is below the minimum power limit
setting, the inverter is shut down. the shutdown() function is called
every time this condition is detected, which is also true if the
inverter is kept shut down for longer. that happens while the battery
is charging in particular (solar passthrough off). there are other
cases.
in such cases we still want to get into the DPL status "stable". to be
able to determine this stable state, we must know if the call to
shutdown did actually initiate a shutdown or if the inverter is already
shut down.
we then can forward this "changed" or "not changed" info up the call
chain, where the loop() will know that the system is actually stable.
* fix another fixable "passtrough" typo
the typo in the config's identifier is not changed to preserve
compatibility while not spending the effort to migrate the setting.
* webapp language: prefer SoC over SOC
* DPL: implement solar passthrough loss factor
in (full) solar passthrough mode, the inverter output power is coupled
to the charge controler output power. the inverter efficiency is already
accounted for. however, the battery might still be slowly discharged for
two reasons: (1) line losses are not accounted for and (2) the inverter
outputs a little bit more than permitted by the power limit.
this is undesirable since the battery is significantly drained if solar
passthrough is active for a longer period of time. also, when using full
solar passthrough and a battery communication interface, the SoC will
slowly degrade to a value below the threshold value for full solar
passthrough. this makes the system switch from charging the battery
(potentially rapidly) to discharging the battery slowly. this switch
might happen in rather fast succession. that's effectively
trickle-charging the battery.
instead, this new factor helps to account for line losses between the
solar charge controller and the inverter, such that the battery is
actually not involved in solar passthrough. the value can be increased
until it is observed that the battery is not discharging when solar
passthrough is active.
In Home Assistant, when Home Assistant MQTT-Auto-Discovery is active,
almost all Sensors of the auto-discovered Victron device in Home
Assistant become "unavailable" after a short time - except those
Sensors with frequent changes like battery voltage or panel voltage.
This patch introduces regular mqtt updates for all VE.Direct sensors
when MQTT-Auto-Discovery is enabled.
Signed-off-by: Martin Dummer <martin.dummer@gmx.net>
* DPL: wait for valid time information
we know that the Hoymiles library refuses to send any message to any
inverter until the system has valid time information. until then we can
do nothing, not even shutdown the inverter.
* DPL: wait for device info to be ready
a calculated power limit will always be limited to the reported
device's max power. that upper limit is only known after the first
DevInfoSimpleCommand succeeded. wait for that information to be
available.
* DPL: fix initial calculcation backoff
if the calculation backoff is initialized to zero, the backoff will be
doubled to zero until a new, different power limit was calculated for
the first time. this lead to the DPL recalculating a power limit
hundreds of times without a backoff after startup.
* VE.Direct: remove polling interval
the polling interval was meant to limit the amount of MQTT updates.
however, that is already controlled by the global MQTT publish interval.
the removed interval was instead used to limit polling of the VE.Direct
UART for incoming data.
the Victron device sends data unsolicited. the VeDirectFrameHandler does
not implement any polling mechanism. no data is ever sent to the Victron
device.
what the removed polling interval did was cause a buffer overrun of the
HardwareSerial class, since the incoming data was not processed in time.
so every five seconds, we read a whole valid VE.Direct frame, plus some
old data, which was not a whole frame, leading to VE.Direct error
messages to pop up.
with the polling interval removed, no framing errors are reported, and
instead we gain new data from the charge controller approximately ever
two seconds -- for free.
* VE.Direct: change texts to correct VE.Direct capital letters
* VE.Direct: improve "UpdatesOnly" switch labels
especially since the publish interval setting is gone, the label makes
it hard to comprehend what the switch does. update the texts to better
explain what the switch is used for.
use the same text on the VE.Direct info view.
* VE.Direct: use StatusBadge on info view
there were custom badges to indicate the VE.Direct settings. replace
those by the common StatusBadge to make then look the same as the other
badged on the info views.
the requested newPowerLimit was indeed limited to the configured maximum
inverter output and the result was stored in effPowerLimit. later,
however, effPowerLimit must be scaled up (if necessary), not
newPowerLimit. the latter variable is not respecting the configured
maximum inverter output.
* DPL: use VeDirect.isDataValid()
in case the communication to the Victron charger is disrupted, the
respective values in VeDirect.veFrame are not invalidated such that we
would notice a problem. instead, isDataValid() should be used to make
sure that the Victron charger is actually alive and that we can trust to
use the reported values.
* DPL: simplify canUseDirectSolarPower return statement
a new status is needed to communicate that no update was sent to the
inverter because its power limit is still valid. in this case,
calculating a new power limit is delayed by an exponentially increasing
backoff. the maximum backoff time is ~1s, which is still plenty fast.
the backoff is actually necessary for another reason: at least
currently, a lot of debug messages are printed to the console. printing
all that information in every DPL loop() is too much.
the unconditional solar passthrough mode, configured using MQTT, works
differently than the normal mode of operation. it is also independent
from the power meter reading. if this mode is active, a shortcut is
taken to a function that implements the actions for this mode. this is
convenient since we don't have to consider special cases in the code
that handles normal mode of operation.
the DPL already took care to shut down the inverter if anything fishy
was going on, mainly to make sure that the battery is not drained.
however, some cases were missed:
* if the configuration changed such that another inverter is now
targeted, the one the DPL controlled previously was not shut down.
* if the configuration changed such that another inverter (different
serial number) was configured at the same index, the previous one
was not shut down.
this change corrects these problems by making the DPL keep a copy of the
shared_ptr to the inverter. the shared_ptr is only released once the DPL
shut the respective inverter down.
this implementation checks all requirements for a new power limit to be
calculated, one after the other. if any requirement is not met, a
respective status is announced.
status messages are communicated on the (serial) console. these can also
be displayed easily on the web app in the future. the status texts
explain clearly what the DPL is currently doing, which aids
understanding how the DPL works. the status is only announced if it
changes, or after a fixed interval.
as each requirement is checked individually, the code readability is
improved as well. previously, all the respective conditions had to be
checked as well, but the statements were more complex.
the DPL loop is now executed with high frequency, i.e., it does not wait
for a fixed timespan to pass before checking requirements. it always
aborts on the first unmet requirement. this should improve responsiveness,
as the DPL checks all requirements more often.
the DPL now waits for all power commands and power limit updates to
complete. when that is the case, a settling time elapses. after the
settling phase, the DPL waits for a new update from the inverter and
from the power meter. now it can be assumed that the values are in sync.
it then makes sense to calculate a new power limit immediately, which
the DPL then does.
the defaults for solar passthrough voltage thresholds shall be floats,
so the user can store float values to the config. otherwise, float
values can and will be stored, but when reading them, the defaults will
be applied as the defaults are of an incompatible type.
* add calculated values to VE.Direct data
solar current, battery output power, and the charger's efficiency can be
calculated from the values reported by the charger. the efficiency must
be taken with a grain of salt. it seems that the solar power value and
the battery output voltage/current are not always in sync. for that
reason a moving average is used to smooth out the calculated efficiency
value.
* show calculated VE.Direct values in web live view
order the values and translations similarly for the input and output,
starting with power at the top, then voltage, then current as the last
of these three.
* VE.Direct live view: use 'd' as unit for days
'd' is the SI unit symbol for days and does not need translation, which
is desirable as units are not translated throughout the project.
* refactor VE.Direct live view
* move Dynamic Power Limiter data into its own type.
* split VE.Direct data into three types: "device", "input", and
"output". hence all input and output values are now ValueObject, which
allows to iterate over them using a loop without typing issues.
* generate the tables with input and output values using a loop, rather
than defining each row individually.
* localize numbers using $n (vue method), which fixes switching the
number format (dot vs. comma) when switching the language.
* use no decimal point for power values (they are integers), three
decimal points for kWh values (charger only reports two decimal
places, but three are easier to read since the unit is *kilo* Wh), one
decimal point for the efficiency, and two for voltage and current.
* update language tokens to avoid mapping JSON keys to language keys
(use the JSON keys to access the language tokens).
* re-structure language tokes so the brief keys took over from
VeDirectFrameHandler always make sense (nest into "input" and
"output").
* order values similarly from top to bottom: power, then voltage, then
current. this is following the order of the inverters' details.
* group values by type/unit (yield and max. power) and order them
"newest" to "oldest" from top to bottom.
* increase the DynamicJsonDocument as it was too small to hold the newly
added data.
* update webapp_dist to include VE.Direct live view refactoring
there is no need to assume and hardcode a fixed efficiency for the
Victron solar charger. the charger reports the voltage and current at
its battery terminal, which can be used to calculate the charger's
actual power output.
the fallback to 100% for the efficiency of the Hoymiles inverter, in
case it is not producing power, is too optimistic. this commit proposes
to use 96.7% as the efficiency for that case, which is the peak
efficiency for many (all?) Hoymiles inverters as per datasheet. that
value should be closer to the real efficiency that will be achieved once
the inverter is turned on.
In addition to the cyclic query of the power meters, they will be queried on demand when total power is requested and last update is older than 1 second.
Webinterface change to set full solar passthrough values
Adding webapi and config changes to enable full solar passthrough over certain battery Soc
inital version of full solar passthrough in power limiter
Passthrough mode can be enabled via MQTT
translations
re-enable comment
remove unused variable
* add support for energy & power readings on SML based power meters, taking OBIS 16.7.1 for power (using mod. SML Parser lib. by olliiiver)
* switched SML read to use software serial
* made total power meter response controled by meter source to obtain either the sum of phase powers or explicit total power provided by meter
* made mqtt subscriptions to power meter topics meter source dependend
* simplified SML read loop and OBIS handler registration, + minor refactoring
* minor cleanup/style changes and optim. PowerMeter
* fixed build, add SOURCE_SML == 4
* removed optional usage of HW serial for SML power meter
* switched to usage of _powerMeter1Power for SML power reading to allign better with existing code
---------
Co-authored-by: helgeerbe <helge@erbehome.de>
* Power limiter: Use the actual AC power for limit calculation
instead of the last set limit.
In order support setups without battery connected (sources that don't exhaust the limit)
* adding data age to battery data
* Add battery enabled flag
* Webapi and websocket api for Battery
* Webinterface for battery
* fixed bug due to naming inconsistencies
* cleaned up rounding
* dist update
* change typename to uppercase
* reverting to original file
That is, something you believe affects every single user of OpenDTU, not just you. If you're not sure, start with one of the other options below.
value:|
### ⚠️ Please remember: issues are for *bugs*⚠️
That is, something you believe affects every single user of OpenDTU-OnBattery, not just you. If you're not sure, start with one of the other options below.
- type:markdown
attributes:
value:|
#### Have a question? 👉 [Start a new discussion](https://github.com/tbnobody/OpenDTU/discussions/new) or [ask in chat](https://discord.gg/WzhxEY62mB).
#### Have a question? 👉 [Start a new discussion](https://github.com/helgeerbe/OpenDTU-OnBattery/discussions/new/choose) or [ask in chat](https://discord.gg/WzhxEY62mB).
#### Before opening an issue, please double check:
disabled while "create release badge" action is broken, see .github/build.yml

If you are upgrading from a version before 15.03.2023 you have to upgrade the partition table of the ESP32. Please follow the [this](docs/UpgradePartition.md) documentation!
OpenDTU-OnBattery is a fork of [OpenDTU](https://github.com/tbnobody/OpenDTU),
which adds support for battery chargers, battery management systems (BMS), and
power meters on a single ESP32. Its Dynamic Power Limiter can adjust the
inverter's power production to the actual houshold consumption. In this way, it
is possible to implement a zero export policy.
## Background
## Getting Started
This project was started from [this](https://www.mikrocontroller.net/topic/525778) discussion (Mikrocontroller.net).
It was the goal to replace the original Hoymiles DTU (Telemetry Gateway) with their cloud access. With a lot of reverse engineering the Hoymiles protocol was decrypted and analyzed.
See the documentation to learn [what hardware](https://opendtu-onbattery.net/hardware/)
to acquire, how to [initialize](https://opendtu-onbattery.net/firmware/) it
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.