Home / Knowledge Base / Battery & Energy Storage

How to Fix JK/JBD BMS RS485 CRC Errors in Solar Assistant

PROTOCOL: MODBUS RTU Applies to: Solar Assistant, JK BMS, JBD BMS, Server Rack Batteries
⚡ TL;DR Diagnostic Quick-Card
Symptom:
One battery fits perfectly. As soon as you daisy-chain 2 or more batteries to the same USB-to-RS485 adapter, the connection drops at random.
Diagnostic Log:
CRC check failed | Corrupt data frame received
Root Cause:
Multiple BMS boards are hardcoded with the exact same Modbus Slave ID (usually ID: 1 or ID: 3). They are trying to reply simultaneously, causing an electrical collision on the bus.
↓ Step 1: Software/DIP Switch Fix ↓ Step 2: Hub Isolation for Locked IDs

A single DIY server rack battery (equipped with a JK or JBD BMS) usually communicates flawlessly with Solar Assistant via RS485. But once you daisy-chain two or more batteries in parallel to the same USB-to-RS485 adapter, the connection turns unstable, drops often, and fills the logs with CRC Errors.

Solar Assistant / MQTT Broker Log
2026-06-15 08:12:04 [INFO] Sending Read Holding Registers to Slave ID: 1
2026-06-15 08:12:04 [WARN] Error: CRC check failed. Expected 0x4A, received 0x00.
2026-06-15 08:12:05 [WARN] Corrupt data frame received. Connection dropped.
2026-06-15 08:12:10 [INFO] Attempting reconnection...

When we’re talking about Modbus RTU, a CRC (Cyclic Redundancy Check) error is when the data packet was received but the math doesn’t add up. The CRC bytes added at the end of the frame do not match the checksum calculated by the Raspberry Pi. While cheap USB adapters can cause this, when dealing with multiple BMS units, the issue is almost always a physical bus collision.

The Root Cause: Hardcoded Slave IDs

Modbus is a strict Master/Slave protocol. The Master (Solar Assistant) calls a specific Slave ID, and only that ID is allowed to answer. The problem is that many BMS manufacturers ship their units with a hardcoded, default Modbus Slave ID (usually ID: 1 or ID: 3).

The Electrical Collision Trap

If you have 3 batteries all with “ID: 1” on the same RS485 bus, Solar Assistant will send out a request for “ID: 1” and all 3 batteries will respond. All three BMS boards will believe the message is for it and reply simultaneously. Their electrical signals overlap and crash into each other on the copper wires. Solar Assistant receives a garbled mess of voltages, which fails the CRC check.

Step 1: The DIY Software Fix (Changing Slave IDs)

The solution is to handle each battery individually in the RS485 daisy-chain. Before buying any more hardware try the following:

  • Use the Bluetooth App: Connect to each battery individually using the official JK or JBD mobile app. Go to the communication setting and look for “Device Address” or “Modbus ID”. Change battery #1 to ID 1, #2 to ID 2, etc.
  • DIP Switch Configuration: If your server rack battery has physical DIP switches on the front of the unit, use the manual to set each unit to a unique binary address.

Note: Some older or specific firmware versions of JK/JBD BMS boards don’t allow changing the Modbus ID or they revert back to the default ID upon reboot. If you cannot provide unique ids then you have a hardware problem.

Step 2: The Hardware Fix (Address Isolation)

If your BMS IDs are locked, or if you are running a large number of batteries where sequential polling causes timeouts in Solar Assistant, you cannot wire them directly in parallel.

To resolve hardware-locked collisions, engineers use an active RS485 Smart Hub. Instead of wiring the batteries together, each battery gets connected to its own dedicated, isolated channel on the hub. The hub acts as a middleman: it independently polls each battery on its specific channel (ignoring the duplicate IDs), caches the data, and presents it to Solar Assistant as a clean, unified dataset with virtual IDs. This completely eliminates electrical collisions and CRC errors.

❌ Passive USB Daisy-Chain
  • All batteries share the exact same physical wire.
  • If BMS IDs are firmware-locked, collisions are 100% inevitable.
  • High probability of ground loops across multiple server rack chassis.
✅ Active RS485 Smart Hub
  • Each battery receives a dedicated, physically isolated RS485 port.
  • Virtual ID Mapping: The Hub reads “ID: 1” from all ports but dynamically translates them to ID: 1, 2, 3 for Solar Assistant.
  • Optocouplers physically block noise and ground loops.

Dealing with locked BMS IDs or ground loops?

Stop fighting dropped connections. Keep your ESS telemetry rock solid with physical channel separation, native data caching, and virtual ID re-mapping from Valtoris Isolated RS485 Hubs.

View Caching Hubs Ask an Engineer

Troubleshooting knowledge base provided by Valtoris Engineering.
Feel free to bookmark and share. If republishing this diagnostic guide externally, please attribute with a link back to Valtoris.com.