Revo2 Basic SN misparsed as Revo1AdvancedTouch, breaking auto-detect and Modbus control

[TannerGilbert]

• SDK version: bc_stark_sdk 2.0.2
• OS: Ubuntu 22.04 / Linux 6.8
• Device: Revo2 Basic, S/N BCMTR2027J25xxxxx, FW 1.0.20.U

What I observe

get_device_info() returns hardware_type=Revo1AdvancedTouch for a Revo2 Basic hand:

DeviceInfo: {"sku_type":"MediumRight","hand_type":"Right","hardware_type":"Revo1AdvancedTouch","serial_number":"BCMTR2027J2500001","firmware_version":"1.0.20.U","hardware_version":""}

The SDK appears to derive hardware_type from the serial-number string. The S/N BCMTR2027J2500001 (which the product manual and packaging list as a Revo2 Basic) is being matched against the Revo1AdvancedTouch rule.

Downstream effects

1. auto_detect_modbus_revo2(...) rejects the device — even when given the correct port — because the Revo2-specific detector sees Revo1AdvancedTouch and discards it. Users have to bypass autodetect entirely and hardcode port/baud/slave.
2. Modbus control commands route to the wrong register set. Any GUI/example that trusts get_device_info().hardware_type (e.g. python/gui/connection_panel.py, python/revo2/revo2_utils.py) sends commands that the hand silently ignores.

Workarounds I'm using

• Call set_hardware_type(slave_id, Revo2Basic) after get_device_info() instead of before.
• For the GUI's Modbus path, same post-call override (see gui/connection_panel.py).

Requests

• Could you check the SN-to-model mapping for the BCMTR2027J25xxxxx batch? If the SN was burned correctly, the parser table needs an entry for this format; if the SN was burned wrong, an end-user-reachable factory tool to reflash it would help.

Happy to share revo2_cfg.py console output if useful — autodetect logs show the SN-based decision clearly.

[Yongle-Fu]

Thanks for the detailed report. Your diagnosis and workaround are correct.

The serial number BCMTR2027J25xxxxx starts with BCMTR2, which is currently matched by the SDK as Revo1AdvancedTouch. For a device that is actually Revo2Basic, this causes both the incorrect DeviceInfo.hardware_type and the Revo2-specific auto-detection rejection you described.

As a temporary workaround, bypass auto_detect_modbus_revo2() by opening the known port directly, then override the hardware type after calling get_device_info():

client = await libstark.modbus_open(port_name, baudrate)
device_info = await client.get_device_info(slave_id)
await client.set_hardware_type(
    slave_id,
    libstark.StarkHardwareType.Revo2Basic,
)

The order matters because get_device_info() performs SN-based detection internally and can overwrite a hardware type set beforehand. Code that displays or retains the original device_info object should also treat its reported hardware_type as overridden.

This workaround restores correct command routing after the connection is established, but it does not fix auto_detect_modbus_revo2() itself because that function rejects the device before a caller can apply the override. A complete fix therefore needs either an updated SN-to-model mapping in bc-stark-sdk or an explicit hardware-type override in the auto-detection path.

We still need to confirm internally whether this batch uses a valid new Revo2 serial-number format or whether the serial number was programmed incorrectly.