Expected Behavior
Gen2/Gen3 devices running a third-party BLE-proxy script (e.g. Home Assistant's Shelly integration installs one to use the device as a Bluetooth proxy) should keep working normally with this binding: unknown script events should be ignored gracefully, and other events in the same NotifyEvent frame should still be processed.
Current Behavior
Such devices emit NotifyEvent frames with event ble.scan_result whose data member is an array ([version, [[mac, rssi, adv, scan_rsp], ...]]). Shelly2NotifyEvent hard-types data as Shelly2NotifyBluEventData (an object — the shape of the binding's own oh-blu.* scanner script), so Gson fails the WHOLE frame in Shelly2RpcSocket.onMessage:
DEBUG ...Shelly2RpcSocket - shellyplugsg3-xxxx: Unable to process Rpc message (Unable to create object of type Shelly2RpcNotifyEvent from JSON (syntax/format error: java.lang.IllegalStateException: Expected BEGIN_OBJECT but was BEGIN_ARRAY at line 1 column 211 path $.params.events[0].data...
Consequences: every event in the frame is discarded (including unrelated ones such as button pushes that share the frame), and the full payload is dumped into the DEBUG log several times per second per affected device. The graceful ignore paths that already exist (blu == null branch, default: case "Event was not handled") are unreachable behind the parse failure.
Observed on an installation where three Gen2/Gen3 devices (Plug S G3 fw 2.0.0, Plus Plug S, Plus 1PM) act as Home Assistant BLE proxies: hundreds of discarded frames per minute.
Possible Solution
Keep data as a raw JsonElement and resolve it lazily into Shelly2NotifyBluEventData only when it actually is a JSON object; skip ble.scan_result explicitly so the flood is neither re-parsed per event nor logged as unhandled. The binding's own oh-blu.* object format parses exactly as before. PR follows.
Your Environment
- openHAB 5.2.1 (openHABian, RPi4), binding reproduced against current
main sources
- Devices: Shelly Plug S G3 (S3PL-00112EU, fw 2.0.0-g87fbfa4), Plus Plug S, Plus 1PM — each running Home Assistant's BLE-proxy script (
script:1)
Expected Behavior
Gen2/Gen3 devices running a third-party BLE-proxy script (e.g. Home Assistant's Shelly integration installs one to use the device as a Bluetooth proxy) should keep working normally with this binding: unknown script events should be ignored gracefully, and other events in the same NotifyEvent frame should still be processed.
Current Behavior
Such devices emit
NotifyEventframes with eventble.scan_resultwhosedatamember is an array ([version, [[mac, rssi, adv, scan_rsp], ...]]).Shelly2NotifyEventhard-typesdataasShelly2NotifyBluEventData(an object — the shape of the binding's ownoh-blu.*scanner script), so Gson fails the WHOLE frame inShelly2RpcSocket.onMessage:Consequences: every event in the frame is discarded (including unrelated ones such as button pushes that share the frame), and the full payload is dumped into the DEBUG log several times per second per affected device. The graceful ignore paths that already exist (
blu == nullbranch,default:case "Event was not handled") are unreachable behind the parse failure.Observed on an installation where three Gen2/Gen3 devices (Plug S G3 fw 2.0.0, Plus Plug S, Plus 1PM) act as Home Assistant BLE proxies: hundreds of discarded frames per minute.
Possible Solution
Keep
dataas a rawJsonElementand resolve it lazily intoShelly2NotifyBluEventDataonly when it actually is a JSON object; skipble.scan_resultexplicitly so the flood is neither re-parsed per event nor logged as unhandled. The binding's ownoh-blu.*object format parses exactly as before. PR follows.Your Environment
mainsourcesscript:1)