If your JK BMS reboots, the Detail Log records it as a Boot row. Most of those rows are harmless: you pressed the power button, or the app switched the BMS off and on. A few are not, and the log lets you tell them apart without guessing.

Here is how to tell expected restarts from unexpected ones and why a MOS can be off. For the file itself and how to export it, see how to export and read the JK-BMS Detail Log.

What a Boot row means

A Boot row means the BMS started up. The first row after a start appears to be written before anything has been measured, so the cell voltages, pack voltage, current and temperatures are all zero. Only the capacity counters carry over, because they are stored. In the example log, a Boot row shows CHG OFF and DSG OFF, zeros everywhere, and remaining capacity 197.9 Ah out of 200.0 Ah.

Do not read those zeros as a deep discharge or a sensor fault. The numbers are simply missing. The next ordinary row has real values again.

When you connect the JK app after a restart, it sets the clock, and a Time calibration row follows. That row marks your own session. It is not a second problem.

Expected versus unexpected JK BMS reboots

A Boot is expected when it comes a few seconds after a row that switched the BMS off. These rows qualify:

Button to turn it off and the emergency button rows
APP to turn it off
Shutdown
Enter sleep

The analysis page counts a Boot as expected when the row right before it is a power-off, button, emergency, shutdown or sleep row less than 60 seconds earlier. Any other Boot is counted as unexpected, except one on the very first row of the file, which has nothing before it to judge by.

The example log has 7 Boot rows and 2 unexpected ones. Five of them come 7 to 37 seconds after Button to turn it off, which is what a power-button restart looks like. The other two have no such row in front of them:

A Boot at 23:53, about 20 minutes after a protection release and an app command to close charging. Nothing else sits near it.
A Boot at 00:21 on the next test day, about 70 seconds after the app closed charging and discharging. App switch commands do not count as a power-off, so this Boot is unexpected whatever the timing.

The log does not say why either restart happened, and neither does the analysis. Treat the count as a prompt to look.

Typical causes to check, in no particular order and none of them confirmed by the log alone:

A supply dip. The BMS powers itself from the pack, so an almost empty pack or a heavy load spike could briefly drop its own supply.
A loose or corroded B- or power lead.
A firmware watchdog reset. This one is visible: the log contains a Reset Watch-Dog message, which the analysis files under faults.
The smart sleep setting, if the BMS goes to sleep and wakes again. Look for Enter sleep before the Boot.

Why charging or discharging stopped

The CHG and DSG columns show whether each MOS was on in that row. A MOS that is off is not always a fault. Common reasons, from the rows around it:

The app, RS485 or CAN switched it off. These appear as rows such as APP close charge or RS485 discharge off. An inverter or charger that controls the BMS over RS485 or CAN can do this too.
A protection tripped. The trip row names the protection, and the release row is usually followed by the MOS turning on again. A long off period with no release row means the protection was still active.
A temperature protection or the heater state. Low-temperature charge protection keeps charging off until the pack warms up.
Power-off voltage or sleep: the BMS switched itself off.
A Boot row: both MOS show OFF in that row.

On the analysis page, the State lane draws CHG, DSG, balance and heater as bars on a timeline. Lining a gap in the CHG lane up with the event list underneath usually shows which of the cases above applies. For the meaning of each message, see JK BMS log messages explained.

High MOS temperature

The BMS has its own MOS over-temperature protection. When it trips, you get a MOS over-temperature row and the MOS switches off. See JK BMS parameters explained for the related settings.

The analysis also raises a separate "MOS gets hot" warning when the MOS temperature reaches 70 °C and no MOS over-temperature trip is in the log. That is a hint that the MOS ran hot without protecting itself yet. It usually points at a long high-current session or poor cooling, and it can be a reason to look at the current limits.

What to do

For expected reboots, nothing. A power-button restart is the BMS doing what you asked.

For unexpected ones:

Open the rows just before the Boot. Look at the current and the lowest cell voltage in the last row before it. A large current or a very low cell points at a supply dip or an overload.
Check the wiring on B- and the power input for loose or heated connections.
Compare the Boot time with your inverter or charger log, if it keeps one. A restart at the same moment as an inverter event often has the same cause.
Look at the smart sleep and power-off voltage settings in the parameter reference.
If a Reset Watch-Dog message is present, note the firmware version and treat it as a firmware question.

If an inverter turns the MOS off, check its BMS settings and how it handles the charge voltage requests, which come from the RCV and RFV values.

Check it with the log

Load your detaillogs file on the log analysis page. The reboots tile shows the Boot count and how many were unexpected. Switch the family filter to power to see only Boot, shutdown and sleep rows, and open the State lane to see where each MOS was off. If a restart is not the only thing going on, the Detail Log guide explains the other message groups. You can also connect your BMS or open a settings file in the editor to review the power-off and sleep values before you change them.

JK BMS Reboots and Charge MOS Off: Reading Power Events in the Log