How to export and read the JK-BMS Detail Log

The JK-BMS Detail Log is a long list of events, each with a snapshot of the pack at that moment. It tells you when the BMS cut off charging or discharging, which cell caused it, and what the voltage, current and temperature were. Export it from the JK app as a text file, then read it by hand or open it in the log analysis page, which pairs trips with releases and points at the likely cause.

What the Detail Log is

The app exports it as a file named like detaillogs-20261001171819.txt, with the export date and time in the name. Despite the extension it is a CSV. The first row holds the column names and every other row is one event.

An event row has the time, the message (for example "Cell 01 over charge protection"), the state of the charge MOS, discharge MOS, balancer and heater, the numbers of the highest and lowest cell, their voltages, the pack voltage, the current, the remaining and full capacity, the temperatures and the heater current.

Older firmware keeps a short event list of about 50 entries that rolls over, and PC monitor programs record their own data. The Detail Log is a separate, longer record written by the BMS itself, so it covers days or weeks without anything connected.

Exporting it from the app

1. Connect to the BMS in the JK app over Bluetooth.
2. Open the device screen and find the logs section. Menu names differ a little between app versions.
3. Choose the Detail Log and export it. The app saves a .txt file.
4. Send the file to your computer or open it on the phone. Nothing here needs the BMS to stay connected.

Reading the columns

A few details are easy to get wrong.

• Cell numbers in the message text start at 1, so "Cell 01" is the first cell. The max and min cell columns start at 0, so add 1 to compare them. The two do not always agree: the snapshot can lag the event, so the cell named in the message is not always the one the column shows at that moment. In the example, rows that say "Cell 01" show 0 in the max-cell column on only 366 of 1083 rows, and other rows show cells up to 7.
• Boot rows carry zeros in the voltage and current columns. The BMS had not measured anything yet when it wrote them.
• Time calibration rows appear when the app connects and sets the clock. They mark your own sessions, not a fault.
• Rows dated before 2021, usually 2020-01-01, mean the clock was not set yet. They are real events with an unknown time, so the analysis leaves them out of timing and durations.
• Voltages with only one decimal place, found in some old exports, are too coarse to judge a cell spread.
• The analysis page accepts files up to 10 MB and drops duplicate rows that fall within 2 seconds of each other.

Message families

The messages fall into a few groups.

• Protection trips and releases: over-voltage, under-voltage, charge and discharge over-current, short circuit, charge and discharge over-temperature or under-temperature, and MOS over-temperature. Each trip normally has a matching release row.
• User and app actions: the power button, an emergency switch, the app turning the BMS off.
• Remote switches: the app, RS485 or CAN turning charging or discharging on or off.
• Power events: Boot, shutdown and sleep.
• Faults: abnormal states such as a wrong cell count, a coprocessor error or a MOS failure. These are not ordinary protections and deserve attention.

Over-voltage and under-voltage trips name the cell. That is the most useful detail in the whole file.

Protection episodes

One trip and its release make an episode. The time between them is how long the protection held. The time from the release to the next trip of the same kind is the re-arm time.

Episodes explain why one problem can produce a thousand rows. If a charger keeps pushing a cell over the limit, the BMS trips, releases after a pause, and trips again. Each loop adds two rows. It is one problem repeating.

A Boot row closes any open episode, because the BMS lost its state. A trip with no release before the end of the file stays open.

Common diagnoses

These are the patterns the analysis page looks for, with the numbers it uses.

Charger above the cell limit (charger voltage too high). The example log has 1090 over-voltage trips, 1083 of them on cell 01, with a spread between the highest and lowest cell mostly under 10 mV. That means the cells are in balance and the charger holds the pack too high; why cell overcharge protection keeps tripping has the figures and the fix.

Weak cell on top. If at least 80% of the trips name one cell and the spread is 50 mV or more, that cell is the problem. Check the spread first, since the named cell alone can mislead. Review the balance settings and check the cell and its wiring. For the pattern in the data, see finding a weak cell in the log.

Under-voltage. The same split applies at the bottom. One cell far below the rest points to a weak cell. A tight spread points to an empty pack, often an inverter cut-off set too low. Compare Cell UVP and SOC-0% voltage with where the inverter stops.

Cycling. Ten or more over-voltage trips with a median re-arm under 60 s is reported as cycling. Cell OVP recovery and Cell RCV are the fields to look at.

Temperature and short circuit. Temperature trips show the peak value reached. A MOS temperature of 70 °C or more without a trip is flagged as a warning. Any short circuit trip is critical. Check the load, the wiring and the delay setting described in overcurrent and short circuit settings.

Unexpected reboots. A Boot row that does not follow a power-off or shutdown row within 60 s counts as unexpected. The example has 7 boots, 2 of them unexpected, because the other five follow a "Button to turn it off" row. Check the power supply and the wiring to the BMS, and see reading reboots and power events.

Capacity changes. If full capacity changes in the log, for example from 200 Ah to 334 Ah, someone edited the capacity setting. See SOC calibration for how the BMS tracks remaining capacity.

Analyse your log in the browser

Open the log analysis page and drop in the .txt file. It is read in your browser and never uploaded. You get the episodes, the per-cell trip counts and the findings above.

You can also attach a .jkcfg export of the same BMS. The page then draws your thresholds as lines on the charts and cross-checks the log against them: trip voltage against Cell OVP, cell count, capacity, the charger setpoint against cells × Cell RCV, peak current near the overcurrent limits, and MOS temperature near the MOS limit. Fix what it finds in the editor, ideally by writing the changes over Bluetooth, and see JK BMS sending failure if the BMS rejects an imported file.