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.
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).
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.
* update mqtt subscriptions when topic was changed
* DPL/Huawei: manage MQTT subscriptions in map
---------
Co-authored-by: Bernhard Kirchen <schlimmchen@posteo.net>
* 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 %
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.
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).
* 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.
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.
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.
