AndreasBoehm
commented
2 weeks ago I got the CAN Protocol from @PeterDietr and compared it with our Pylontech and Pytes implementation. Sadly it does not match either of them.
They follow the same principal, basic values use the same ID across all brands, but as soon as we go more into detail with data we can't reuse existing implementations. The most annoying part is that they use the same ID for the same data, but put them in different bits -> we think we already parse the values but actually we mixed the bits up...
I though about checking the 'manufacturer' to decide how we parse data but as we already know you can switch the protocol of a pytes battery but you won't be able to see that difference on the 'manufacturer' field.
Let me have a think.
Adminius
Is your feature request related to a problem? Please describe.
Following the discussion in #1226. DEYE batteries are mostly supported when using the "Pylontech using CAN bus" battery provider. However, not all data points in
PylontechBatteryStatsare actually received/decoded.Describe the solution you'd like
Use
std::optional<...>to have optional values inPylontechBatteryStats. Do not publish these values in MQTT and exclude them from the live view if the values have not been set as no respective CAN message was received/decoded.This should allow us to make support for DEYE batteries explicit without too much trouble: "Skip" values that we know we don't receive from DEYE batteries, instead of publishing and showing default-initialized values.
We shall do something similar for warning and alarm bits: If we don't decode the respective CAN message, do not publish any warning/alarm bit values to the broker (maybe even delete them by publishing an empty string?) and show a message "Issues not supported" in the live view. If we do decode the respective CAN message after all (DEYE firmware update?) and know the warning/alarm bits, we can process them again.
Describe alternatives you've considered
No response
Additional context
No response