Oh, thanks, didn't notice the implementation in GPS server, that's great so I can start with that. Was trying to implement time syncing for raspberry pi - it does not have RTC so it syncs time from network at boot time, was thinking about syncing from smartwatch with this service if network is not available. So thanks to the gps server the server side is easy, querying it in startup script on the Pi (via bluetoothctl,hcitool or gatttool or something) will be harder - not sure if scan response is easier to get via bluetoothctl then actually doing connection and reading the characteristics via gatttool (that will work for sure but could be slower).
As for advertising those characteristics 16bit uuid data - it is not standard and typical CTS client won't search for it but I guess it won't break anything and could be there for those clients searching for it.
BTW having the 10 byte current time in scan response could be better as both for more space there and also for freshness of the time value, in theory the time could be filled when scan response is requested. Could I hook some js or native code into generating scan response? I guess it is set statically now and would be quite tricky to add this? The response array could be still statically prepared but just passing the byte array to some optional (native) callback method to update the array on the fly could work - similar to how setWatch can call native code with irq:true flag.
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
Oh, thanks, didn't notice the implementation in GPS server, that's great so I can start with that. Was trying to implement time syncing for raspberry pi - it does not have RTC so it syncs time from network at boot time, was thinking about syncing from smartwatch with this service if network is not available. So thanks to the gps server the server side is easy, querying it in startup script on the Pi (via bluetoothctl,hcitool or gatttool or something) will be harder - not sure if scan response is easier to get via bluetoothctl then actually doing connection and reading the characteristics via gatttool (that will work for sure but could be slower).
As for advertising those characteristics 16bit uuid data - it is not standard and typical CTS client won't search for it but I guess it won't break anything and could be there for those clients searching for it.
BTW having the 10 byte current time in scan response could be better as both for more space there and also for freshness of the time value, in theory the time could be filled when scan response is requested. Could I hook some js or native code into generating scan response? I guess it is set statically now and would be quite tricky to add this? The response array could be still statically prepared but just passing the byte array to some optional (native) callback method to update the array on the fly could work - similar to how setWatch can call native code with
irq:true
flag.