Debug screen that can be published to from anywhere. Long press some button could bring it up for example. Could display last X logs maybe?

[jakkra]

No description provided.

[vChavezB]

A subsys logger could be added for this purpose. See the backends available at

https://github.com/zephyrproject-rtos/zephyr/tree/main/subsys/logging/backends

Sometime ago I made a BLE Backend to get Zephyr logs over BLE. If you want to display the last "X" logs you would need to save them through the backend and then in the ZSWatch app you can recall them for display in a screen.

For further reference check the docs for logging subsys backend and the backends source code.

[jakkra]

I checke the source code of GadgetBridge and it will log everything sent to the phone to a file, this file can be read and shared from the app.

All data sent from the watch to GadgetBridge not properly formatted according to the protocol will just be discarded (BUT LOGGED) so I think we can eventually just send the logs directly to GadgetBridge using NUS :)

But we need a custom logging backend, We can probably base it very much on the one in Zephyr linked before, but using it out of the box will not work as it defines the NUS service again.

[Kampi]

@jakkra maybe use the external Flash memory for logging (10-20k maybe), so the logging can be used without BLE enabled. We can limit it to faults or errors, so the memory will not get flushed with normal stuff. We can use BLE to download the log file.

[jakkra]

@jakkra maybe use the external Flash memory for logging (10-20k maybe), so the logging can be used without BLE enabled. We can limit it to faults or errors, so the memory will not get flushed with normal stuff. We can use BLE to download the log file.

I was thinking of how to do this stock GadgetBridge, hence my proposal is as it is. Of course a better way is what you suggest, but would require custom tools. It's nice if it just works out of the box with gadgetbridge.

Of course we could store it in flash, and then when you press a button somewhere in the UI or something send all the logs to gagdetbrigde at once. That would work too.

A good first step is my proposal I think at least.

[vChavezB]

All data sent from the watch to GadgetBridge not properly formatted according to the protocol will just be discarded (BUT LOGGED) so I think we can eventually just send the logs directly to GadgetBridge using NUS :)

What BLE GATT service does Gadgetbridge require to log data. Do you ahve info or a link to the source/docs about this?

[jakkra]

All data sent from the watch to GadgetBridge not properly formatted according to the protocol will just be discarded (BUT LOGGED) so I think we can eventually just send the logs directly to GadgetBridge using NUS :)

What BLE GATT service does Gadgetbridge require to log data. Do you ahve info or a link to the source/docs about this?

Nordic NUS
Protocol we use:
https://www.espruino.com/Gadgetbridge#messages-sent-to-bangle-js-from-phone

It will log anything sent to it over NUS (normal protocol is NUS also).

Edit: Here it adds anything it receives to the log, even if it's invalid packets.
https://codeberg.org/Freeyourgadget/Gadgetbridge/src/branch/master/app/src/main/java/nodomain/freeyourgadget/gadgetbridge/service/devices/banglejs/BangleJSDeviceSupport.java#L1016

[vChavezB]

Ok I understand now. Yes, then the easiest solution would be to just create a ble backend logger similar to the one I mentioned

Just consider to increase the MTU size and check if it plays nicely with concurrent access from other ZSwatch apps that use the NUS service and the priority of the logger subsys.
Example
Logger queue: [0.0.001 ] My Log with a very long message that has to be splitted over MTU
ZSwatch app: {\tmusic\n: my song} \n"

So something as the following could be recieved by GadgetBridge
[0.0.001 ] My Log with a
{\tmusic\n: my song} \n"
very long message that has to be splitted over MTU

[jakkra]

Ok I understand now. Yes, then the easiest solution would be to just create a ble backend logger similar to the one I mentioned

Just consider to increase the MTU size and check if it plays nicely with concurrent access from other ZSwatch apps that use the NUS service and the priority of the logger subsys. Example Logger queue: [0.0.001 ] My Log with a very long message that has to be splitted over MTU ZSwatch app: {\tmusic\n: my song} \n"

So something as the following could be recieved by GadgetBridge [0.0.001 ] My Log with a {\tmusic\n: my song} \n" very long message that has to be splitted over MTU

Yeah was thinking of the same issues. Bumping the MTU and always crop log messages to max that length could be a simple way to handle it. Otherwise some outgoing NUS queue could be implemented perhaps here https://github.com/jakkra/ZSWatch/blob/main/app/src/ble/ble_transport.c#L81 and make sure all NUS traffic goes through this function.

Thanks for some good input :)