Is your feature request related to a problem? Please describe.
I am building an app to control Bruce over BLE from a phone, and the main blocker is that command responses come back as plain text. The app has to scrape and guess that text, which is fragile and breaks whenever the wording or formatting changes.
The NUS BLE bridge in #2745 handles the transport, but responses over it are still plain text, identical to the USB console, so parsing is still the problem.
There is currently no way to send a command and get back a response that software can read directly.
Describe the solution you'd like
An optional structured response mode where commands and replies are exchanged as JSON instead of plain text. This is the same idea as an RPC (remote procedure call): the client sends a command, and the device returns a structured result or an error.
Right now a command looks like this over serial or the BLE bridge:
UID: 1D A3 9D 98 10 10 80
Type: MIFARE Ultralight
SAK: 00
ATQA: 00 44
Pages: 64
With a structured mode, the same exchange would look like this.
Request:
{"id": 1, "cmd": "rfid.read", "args": {"timeout": 5000}}
Response:
{"id": 1, "ok": true, "result": {"uid": "1D A3 9D 98 10 10 80", "type": "MIFARE Ultralight", "sak": "00", "atqa": "00 44", "pages": 64}}
Error case, same command when no tag is present:
{"id": 2, "cmd": "rfid.read", "args": {"timeout": 5000}}
{"id": 2, "ok": false, "error": "tag not found"}
A couple more examples:
{"id": 3, "cmd": "device.info"}
{"id": 3, "ok": true, "result": {"firmware": "1.16.1", "name": "Bruce", "battery": 82}}
{"id": 4, "cmd": "wifi.scan"}
{"id": 4, "ok": true, "result": {"networks": [{"ssid": "Home", "rssi": -52, "enc": "WPA2", "ch": 6}]}}
Framing: one JSON object per line, newline terminated. That fits the existing NUS bridge in #2745, and it matches how optionsJSON already returns JSON today. Bruce also already uses ArduinoJson (for example the IRSend and RfSend commands), so the building blocks are already in the firmware.
Starting with the commands that already return data (rfid, ir, subghz, wifi scan, ble scan, files, device info) would be enough to make app integration reliable, and more commands can be added over time.
Describe alternatives you've considered
Menu scraping with optionsJSON and nav. It is fragile, and it can freeze the device on feature screens.
The JS interpreter. Useful, but it only covers part of the features and runs as a foreground script.
Parsing the plain text output, which is what I do now. It breaks whenever the output formatting changes.
None of these give a stable, machine readable response, which is what this is about.
Additional context
This pairs directly with the BLE bridge in #2745, which already handles the connection and is tuned for iOS. The missing piece is structured responses on top of it. I did not find an existing issue requesting this.
Is your feature request related to a problem? Please describe.
I am building an app to control Bruce over BLE from a phone, and the main blocker is that command responses come back as plain text. The app has to scrape and guess that text, which is fragile and breaks whenever the wording or formatting changes.
The NUS BLE bridge in #2745 handles the transport, but responses over it are still plain text, identical to the USB console, so parsing is still the problem.
There is currently no way to send a command and get back a response that software can read directly.
Describe the solution you'd like
An optional structured response mode where commands and replies are exchanged as JSON instead of plain text. This is the same idea as an RPC (remote procedure call): the client sends a command, and the device returns a structured result or an error.
Right now a command looks like this over serial or the BLE bridge:
With a structured mode, the same exchange would look like this.
Request:
Response:
Error case, same command when no tag is present:
A couple more examples:
Framing: one JSON object per line, newline terminated. That fits the existing NUS bridge in #2745, and it matches how optionsJSON already returns JSON today. Bruce also already uses ArduinoJson (for example the IRSend and RfSend commands), so the building blocks are already in the firmware.
Starting with the commands that already return data (rfid, ir, subghz, wifi scan, ble scan, files, device info) would be enough to make app integration reliable, and more commands can be added over time.
Describe alternatives you've considered
Menu scraping with optionsJSON and nav. It is fragile, and it can freeze the device on feature screens.
The JS interpreter. Useful, but it only covers part of the features and runs as a foreground script.
Parsing the plain text output, which is what I do now. It breaks whenever the output formatting changes.
None of these give a stable, machine readable response, which is what this is about.
Additional context
This pairs directly with the BLE bridge in #2745, which already handles the connection and is tuned for iOS. The missing piece is structured responses on top of it. I did not find an existing issue requesting this.