I’m using the 82-mini as a streaming camera, and props to you guys for the Web sockets demo. I’ve figured how to modify the htdocs files, have things generally working very well, but on the serial monitor, I see:
23:57:23.630 ->
Processing command: {"cmd":"stop_model","param":["yolo4t","retinaface","mobilenetface","yamnet","object_tracking","palm_detection","hand_landmark"]}
23:57:23.630 ->
Received stop_model command
23:57:23.630 ->
Process stop_model command
23:57:23.662 ->
stop_model called
23:57:23.662 ->
[wsfs_echo] received message (32 bytes, opcode=1)
23:57:23.662 ->
Processing command: {"cmd":"start_model","param":[]}
23:57:23.662 ->
Received start_model command
23:57:23.662 ->
Process start_model command
23:57:23.662 ->
start_model called
23:57:23.662 ->
[wsfs_echo] received message (45 bytes, opcode=1)
23:57:23.662 ->
Processing command: {"cmd":"get_model_meta","param":["classify"]}
23:57:23.695 ->
Received get_model_meta command
Why is a streaming webcam demo doing ANYTHING with a classification model? Where are these commands coming from? Doesn’t look like anywhere in the example code.
I’m looking for smoothest possible stream, don’t want it wasting a cycle on a classifier: I’m not using that stuff at all.
These commands are not coming from the example C code.
They come from the browser page and they spend zero cycles on classification.
Where the commands are actually sent
Your board serves an HTTP page (htdocs.bin from websocket_viewer_web_source.zip). That page’s js/ai_player.js opens a WebSocket back to the board and has
an onopen handler that runs on every connect — automatically, whether or not you asked for any AI. So the start_model / stop_model / get_model_meta messages you see in the serial log are just the page doing its standard “AI handshake”, so it always sends these regardless of what the firmware actually supports. Nothing in example_websocket_viewer.c calls them.
Do they waste a cycle on your stream? No.
On the device these all land in the dispatcher in component/application/websocket_viewer/web_service.c, and the handlers are empty stubs:
get_model_meta isn’t even registered in the command table — it just prints “Received … command” and is dropped. No model is loaded, nothing runs at runtime; only a
couple of printfs happen once at connect time. Your H.264 encode → WebSocket send path is completely untouched.
What to do about the log noise
Fix the page (permanent): in ai_player.js, delete the stopModel/startModel/getModelMeta lines from onopen (~line 1528), or just call startVideo() there.
Silence on device (quick): remove the three stubs from app_cmd in web_service.c — streaming still works fine, you just lose the “Received …/Process …” prints for them.
Is there any already-created way I can reach into the browser DOM or have the browser’s Javascript ask for data to write into it?
I’d like to be able to set the unit-dependent data (WiFi creds, manual exposure, and browser window title) with info pulled up from an SD card, which lives, of course, on the Arduino side of things. I can have the Arduino “know” what the browser title should be, but I’m interested in whether there’s an API pipe into the Javascript for passing info back.
The 8081 WebSocket is bidirectional and the page already has a generic JSON handler (CommandLink.onmessage, switch on obj.type).
What’s missing is the device side: the FreeRTOS SDK exposes wsfs_connection_send_text(), but the current example’s firmware never calls it, every command handler (including get_version) is a print-only stub. So the pipe is there, the simplest fix is to add one command handler in web_service.c that reads your per-unit data from SD and replies with {"type":"unit_info","result":{...}}, then add one case “unit_info”: in ai_player.js that sets document.title / fills the exposure and WiFi fields. After changes have been made, you might need to compile libwebsocket_viewer.a to replace packages\realtek\hardware\AmebaPro2\<version>\variants\common_libs\libwebsocket_viewer.a
Alternatively, add a dynamic HTTP endpoint like the existing /fw_ver and fetch it with the updateText() helper. Either way the browser pulls the data; the device can’t inject into the DOM unilaterally.
Thanks for posting!