CW20 BLE integration is broken: invalid sample format, incorrect await usage, missing fields, and BLE lockups #338
Description
Hi. After updating to the latest Batmon release with CW20 BLE support, the integration appears to be non-functional. The device connects, but sampling fails continuously with several critical issues. The full log is attached: /mnt/data/2af0a32d_batmon_2025-11-21T07-45-46.062Z.log
CW20 BLE returns a data format that the parser does not support
CW20 provides fields such as voltage, current, cycle_capacity, energy, temperature, power and battery_charging.
Batmon, however, expects a field called battery_level, which is not present. This results in repeated KeyError and “invalid ble_bms sample” exceptions. The parser clearly does not match the actual CW20 BLE output.
CW20 BLE code attempts to await a dict
The logs repeatedly show: “object dict can't be used in 'await' expression”.
This means part of the CW20 BLE implementation is incorrectly using await on a normal dict object. This breaks the data retrieval flow entirely.
BLE operations get stuck with BlueZ errors
As soon as CW20 errors start, BlueZ begins returning “Operation already in progress”. This indicates multiple BLE scans/connections are triggered in parallel, leading to lockups and preventing other devices (like JBD BMS) from working.
CW20 sends empty samples, breaking the sampling loop
Whenever parsing fails, CW20 returns an empty sample {}, which causes Batmon to throw ValueError repeatedly and disrupt the entire sampling cycle.
Suggested fixes:
• Add correct field mapping for CW20 BLE (the device does not provide battery_level, so SOC must be read from another field or derived).
• Remove incorrect await usage on non-awaitable objects.
• Ensure CW20 BLE operations do not run concurrently with other BLE scans.
• Prevent empty samples from propagating to the main sampling loop.
The issue is reproducible immediately after enabling CW20 BLE support. If needed, I can provide additional logs or test builds.