when changing the security settings (disabling read-only access or
changing the password), existing websocket connections are now closed,
forcing the respective clients to authenticate (with the new password).
otherwise, existing websocket clients keep connected even though the
security settings now expect authentication with a (changed) password.
with ESPAsyncWebServer 3.3.0, the setAuthentication() method became
deprecated and a replacement method was provided which acts as a shim
and uses the new middleware-based approach to setup authentication. in
order to eventually apply a changed "read-only access allowed" setting,
the setAuthentication() method was called periodically. the shim
implementation each time allocates a new AuthenticationMiddleware and
adds it to the chain of middlewares, eventually exhausting the memory.
we now use the new middleware-based approach ourselves and only add the
respective AuthenticatonMiddleware instance once to the respective
websocket server instance.
a regression where enabling unauthenticated read-only access is not
applied until reboot is also fixed. all the AuthenticationMiddleware
instances were never removed from the chain of middlewares when calling
setAuthentication("", "").
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
* 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)
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
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 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.
* update mqtt subscriptions when topic was changed
* DPL/Huawei: manage MQTT subscriptions in map
---------
Co-authored-by: Bernhard Kirchen <schlimmchen@posteo.net>
previously, we needed VE.Direct enabled to know the
solar charge controller output, which solely decided when
it was "nighttime". since this is now determined by the
wall clock, we can offer this feature to users without a
Victron charge controller connected using VE.Direct.
* backport SPIPortManager from @skippermeister
* adapt to support ESP32 and ESP32-S3 and ESP32-C3
* use logic to work with SPI numbering as in the official
documentation: start with SPI0 and go up to SPI3
* increase Huawei CAN controller stack size to 2000
* increase startup delay for USB_CDC enabled builds to be able to
catch bootlogs over USB
* fix: DPL: start discharging at night logic error
the switch "always start discharging battery at night" would cause to
stop discharging the battery when there was solar power and the battery
was discharged below the start threshold.
this change introduces a nighttime discharging boolean variable, which
is enabled the instant we decide to start a battery discharge cycle due
to nighttime havin arrived. we reset this variable as soon as it is
daytime (solar power available). in that case, we allow discharging the
battery if the start threshold was reached. this can actually be the
case if the battery is charged with cheap electricity during the night.
removed comments as they merely spell out what the if statement already
expresses quite nicely.
* use SunPosition.isDayPeriod() to check for daytime
---------
Co-authored-by: Andreas Böhm <andreas@boehm.cx>
this changeset adds support for parsing the MQTT battery provider's SoC
and voltage topics' payloads as JSON to extract a numeric value at a
configurable path.
* show battery voltage, current, and power in live view header (the "totals")
* show battery current and power in extra card
* use soc and current precision in live view
* BatteryStats: do not knowingly publish invalid data: not all battery
providers know all values the base class manages. make sure to
prevent publishing invalid values.
Co-authored-by: Bernhard Kirchen <schlimmchen@posteo.net>
This breaks existing HASS automation, as entity names and MQTT topics change!
* include dtu-unique-id in DPL MQTT HASS topics to allow multiple DTUs to be controlled
* fix filename "src/MqttHandlVedirectHass.cpp"
* refactor: use values from 'MqttHandleHass', add 'via_device' to all HASS devices
* set step size for power limiter voltage values
Hoymiles inverters allow setting relative limits with a precision of 0.1 %.
this changeset allows to utilize this precision.
* preserve accuracy when decoding power limit
* Web API: process floating point limits
* MQTT: process floating point limits
* use appropriate accuracy for limits in web UI
* HASS: step for relative inverter limit is 0.1 %
we previously used the mutex to protect writing the target variable.
however, we would only do that for the old usecase, where a plain float
value in Watts was expected as the topic's payload.
