Is your feature request related to a problem? Please describe.
When defining a service you can only specify the ushort identifier which will be in the Bluetooth SIG namespace. This is fine when implementing stock services but for anything custom we should be able to provide a full unique UUID.
Describe the solution you'd like
Add an overload to the Service constructor which accepts a Guid or string to provide the full UUID of the service. Retain the existing ushort version too.
Describe alternatives you've considered
There isn't currently a workaround for this as we can only specify a ushort uuid which could potentially clash with future Bluetooth SIG service definitions.
Additional context
The Characteristic constructor currently accepts a string for the full uuid, so we need equivalent functionality for the Service.
DarkNoir
commented
1 year ago
Is your feature request related to a problem? Please describe. When defining a service you can only specify the ushort identifier which will be in the Bluetooth SIG namespace. This is fine when implementing stock services but for anything custom we should be able to provide a full unique UUID.
Describe the solution you'd like Add an overload to the Service constructor which accepts a Guid or string to provide the full UUID of the service. Retain the existing ushort version too.
Describe alternatives you've considered There isn't currently a workaround for this as we can only specify a ushort uuid which could potentially clash with future Bluetooth SIG service definitions.
Additional context The Characteristic constructor currently accepts a string for the full uuid, so we need equivalent functionality for the Service.