v1.0.20

Full Changelog: v1.0.19...v1.0.20

v1.0.19

Full Changelog: v1.0.18...v1.0.19

v1.0.18

Full Changelog: v1.0.17...v1.0.18

v1.0.17

Full Changelog: v1.0.16...v1.0.17

v1.0.16 - fix initial poll command for KL/BTG devices

Fix: correct initial poll command for KL/BTG656 devices

The initial poll sent after connecting used bb9ae065ee (9ae0), which is the KHF page's command. The KL/BTG page hardcodes bb9aa90cee (9aa9).

The 9aa9 checksum 0x0C is a device-specific magic constant — it does not follow the normal BCD checksum formula (which would compute 0x10). This is why it must be hardcoded rather than generated.

Both commands appear to work on the BTG656, but this uses the correct one. Combined with 1.0.15, the packet log now shows WRITE:bb9aa90cee confirming the right bytes are sent on each connect.

v1.0.15 - write logging improvements

Diagnostic improvement: write operations now visible in logs and packet log

After v1.0.14 it wasn't clear whether the initial poll and capacity writes were actually being sent, because all write operations were logged at DEBUG level (invisible without debug mode) and sent bytes weren't recorded anywhere.

Changes:

• Connect/disconnect events now log at INFO
• All write operations (initial 9ae0 poll, b0 capacity preset) log at INFO with the exact hex bytes sent
• Sent frames are recorded in the rolling packet log as WRITE:<hex> entries, alongside the received OK:, BAD:, and RAW: entries — so the "Last Raw Packet" diagnostic sensor now shows the full BLE conversation history

Status as of 1.0.14: Voltage (c0) is working — packet log analysis confirmed 82 c0 packets in the most recent 200, voltage reading 13.1V. The fix in 1.0.14 is correct. This release is purely diagnostic improvement.

v1.0.14 - fix missing voltage sensor

Fix: voltage (and other fields) showing as Unavailable after connect

Root cause: The Junctek app sends a writeData("9ae0") command 1 second after subscribing to BLE notifications. This causes the device to emit a complete data flush, including c0 (voltage). Without this request, the device sends an incomplete set of fields spontaneously and voltage is never transmitted.

Evidence: Packet log analysis showed 183 consecutive packets with zero c0 (voltage) frames after upgrading to v1.0.13. The v1.0.12 b0 write was not the cause — it worked correctly (device echoed back the ack) — but the missing initial poll meant voltage never appeared.

Fix: After start_notify succeeds, a background task waits 1 second then sends bb9ae065ee (the framed 9ae0 poll command) to the write characteristic. This mirrors the app's behaviour exactly.

Note: Temperature (d9) remains Unavailable unless an external NTC probe is physically connected — that is correct and unchanged.

v1.0.13 - write capacity to device; fix current/power sign

Two changes in this release

1.0.12 — Write battery capacity preset to device on connect

On every GATT connection the integration now writes the user-configured battery capacity to the device's b0 register via the write characteristic (0000fff2-...). This keeps the device's own remaining-time calculation in sync with the capacity configured in HA. Write failures are logged as warnings and do not interrupt the connection.

1.0.13 — Fix current/power sign inconsistency

Power sign was inverted relative to current. Both now use the same convention:

• Negative = charging
• Positive = discharging

Previously power was positive while charging and negative while discharging, which was the opposite of current.

v1.0.11 - d7 is internal resistance, not temperature

Fix: Internal Resistance sensor; temperature now only from external probe

Root cause (APK analysis): d7 is not temperature — it encodes battery internal resistance in mΩ (d7 / 100). The Junctek app labels it "IntRes" on the KG-F page. The KL/BTG656 page does not display it at all. Previous versions misidentified it as temperature because d7 / 100 fell in a plausible range (~15–40°C) during testing.

Changes:

• d7 is now exposed as an Internal Resistance (mΩ) diagnostic sensor, not temperature
• Temperature sensor (d9) only has data when an external NTC probe is physically connected to the monitor — shows Unavailable otherwise (correct behaviour)
• d0 relabelled from cur_soc to relay_state (it encodes relay/output state on KL/BTG devices, not SOC)

See PROTOCOL.md for the full field reference.

v1.0.10 - fix temperature bogus fallback

Bug fix: temperature still showing ~63°C after v1.0.9

Investigation: 129 live proxy packets analyzed. Zero `d9` (temp) packets received in this session. Zero unknown tag bytes — every non-BCD byte is a known field tag. The device is simply not sending temperature continuously.

The `d7` values seen (n≈6300–7200 → 63–72°C via n/100) are clearly not temperature — the reference sensor reads ~30°C. `d7` appears to encode a non-temperature measurement on this device (its values track proportionally with `d6` / mins_remaining with a ~3.34× ratio).

Fix: Cap `temp_d7` at 55°C. Values above this threshold are discarded. When no valid temperature source is available (no `d9`, no plausible `d7`), the sensor correctly shows Unavailable instead of a wrong reading.

Devices like the BTG656 that genuinely use `d7` for temperature (reporting 20–45°C) continue to work. `d9` temperature continues to take priority when the device sends it.