DPL Voltage Features #679

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 helgeerbe#654.

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.

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.

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.

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 helgeerbe#573.

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 helgeerbe#655.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

DPL Voltage Features #679

DPL Voltage Features #679

Commits on Feb 18, 2024