Enables a tracker to forward log messages to the server, and the server to send the log messages to the UI.

[jabberrock]

1. PROTOCOL_LOG_SUPPORT which determines if the server supports forwarding log messages
2. PACKET_LOG (26) which is the UDP packet that the tracker sends to the server
3. Device.logMessages which is the new field for the UI to receive log messages

Device logs are displayed in the GUI under the specified tracker, because there is no place to put device-specific information, nor is there a good way to separate tracker-specific logs from each other. This means that aux trackers will show the same device logs as the main tracker.

Related PRs:
SlimeVR/SolarXR-Protocol#153
SlimeVR/SlimeVR-Tracker-ESP#361

2024-11-11.12-43-26-00.00.29.546-00.00.48.967.mp4

[loucass003]

It is cool, i mostly dont like how it looks. I would create another block below the tracker settings with a nice title
Device Logs

And put the logs text behind a darker color. Similar to the actual serial console in the server.

[loucass003]

From the look of the code it also looks like all trackers will be sending their logs to the server no matter what. Imo this is not good. The server should only send the logs through the solarxr protocol when needed.

You would need a packet to Start listening for logs from the gui and stop listening.

Also that pose another question. Should the server really be always listening for tracker logs without asking for it. this seem like a lot of packets for a debug feature.

[Eirenliel]

agree, @loucass003

[jabberrock]

Tracker -> Server
Each tracker sends about 30 messages at startup, and then 1 message every minute. I don't think that's going to overwhelm the server. When there's a problem with the tracker, you want to be see what happened in the past.

Server -> UI
Agreed that the UI shouldn't request the logs unless needed. Would requesting the logs when you're viewing a specific tracker be acceptable?

[jabberrock]

I imagine this will simplify debugging problems for customers. It could be super useful for things like calibration. It may lead firmware to put in more logs, e.g. so that customers can figure out why a tracker's acting weird.

[Eirenliel]

Server -> UI Agreed that the UI shouldn't request the logs unless needed. Would requesting the logs when you're viewing a specific tracker be acceptable?

@jabberrock yeah