You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Only resources for available sensors are registered. /.well-known/core only shows resources that are relevant for this board and only relevant resources are added to the resource directory.
Current behavior
Resources are registered independently of the presence of a sensor. The resources that are registered, are hard coded in saul_coap.c line 44. The registration of the resources takes place in saul_coap.c line 291.
Potential fix
Instead of specifying a resource array, the saul_coap_init() function could start with an empty resource array. It could then iterate over all known saul devices. For every device it could check the device class. If it’s not yet present in the resource array, it could add an entry with a resource path, the context for the handler and resource directory tags (maybe within the context).
What will be used as resource path? This doesn’t really matter, as long as the resource is added with useful tags to the directory. Could be a random character or the saul class id. A prefix (like /saul/class/…) might be useful to prevent a crash with another package.
What will be used as resource tags? The easiest solution would probably be, to use the RIOT internal class id. But this is not human readable. Also it might change in the future and possibly break apps without RIOT code. A different approach would require some sort of stringification of the class id. Either based on a static and hard coded structure (ugly but fast) or based on some generation of string from the device class enum names.
To address the second question, we could still use a hard-coded array for supported resources. Instead of adding every possible device class as resource, the init function could only add supported resources. These could contain a specified tag for each resource.
The text was updated successfully, but these errors were encountered:
Discussed with @MatthiasBraeuer offline.
Expected behavior
Only resources for available sensors are registered.
/.well-known/core
only shows resources that are relevant for this board and only relevant resources are added to the resource directory.Current behavior
Resources are registered independently of the presence of a sensor. The resources that are registered, are hard coded in
saul_coap.c
line 44. The registration of the resources takes place insaul_coap.c
line 291.Potential fix
Instead of specifying a resource array, the
saul_coap_init()
function could start with an empty resource array. It could then iterate over all known saul devices. For every device it could check the device class. If it’s not yet present in the resource array, it could add an entry with a resource path, the context for the handler and resource directory tags (maybe within the context).What will be used as resource path? This doesn’t really matter, as long as the resource is added with useful tags to the directory. Could be a random character or the saul class id. A prefix (like
/saul/class/…
) might be useful to prevent a crash with another package.What will be used as resource tags? The easiest solution would probably be, to use the RIOT internal class id. But this is not human readable. Also it might change in the future and possibly break apps without RIOT code. A different approach would require some sort of stringification of the class id. Either based on a static and hard coded structure (ugly but fast) or based on some generation of string from the device class enum names.
To address the second question, we could still use a hard-coded array for supported resources. Instead of adding every possible device class as resource, the init function could only add supported resources. These could contain a specified tag for each resource.
The text was updated successfully, but these errors were encountered: