gcoap: features required to wrap SAUL

miri64 commented 4 years ago

While trying to expose a boards actuators and sensors via gCoAP, I noticed, that it is not yet as easy and as it could be using SAUL. There are several features missing for that:

[x] Adding a dynamic list of resources to a gCoAP listener: While SAUL manages its resources in a linked list to allow for extensions from basically anywhere (heterogenous drivers), gCoAP has uses fixed-sized arrays to manage the resources of a listener. A way to deal with this could be to have "wildcard resources" that can be expanded by the resource handler. A way to add those .well-known/core would be to have a special handler for those kind of resources.
[x] phydat de-/serializer so that the data read from a device can be converted into JSON, CBOR, etc. and vice-versa (see https://github.com/RIOT-OS/RIOT/pull/7271)
[ ] "reactive" SAUL to implement events that trigger a CoAP OBSERVE notification

kb2ma commented 4 years ago

Does the Server path matching section in the nanocoap doc provide the wildcard you're after?

miri64 commented 4 years ago

Does the Server path matching section in the nanocoap doc provide the wildcard you're after?

If the sub-tree is then also advertised via .well-known/core, yes.

kb2ma commented 4 years ago

I agree that a phydat de-/serializer is a good idea. It's not specific to gcoap though, is it? I'm actually implementing a serializer for temperature for Wakaama in the temperature app in RIOT-OS/applications#66. Maybe this could be generalized further.

miri64 commented 4 years ago

I agree that a phydat de-/serializer is a good idea. It's not specific to gcoap though, is it? I'm actually implementing a serializer for temperature for Wakaama in the temperature app in RIOT-OS/applications#66. Maybe this could be generalized further.

No, as this is about interfacing, I see this tracking issue as both for SAUL and gCoAP. In this case, this is more specific to saul / phydat.

maribu commented 4 years ago

maribu closed this 42 seconds ago

Sorry, big fingers on small screen.

If I remeber correctly, the handler for .well-known/core in nanocoap is just a regular callback, with a default implementation for that for you to pick. So you could provide your own handler that would construct the discovery response from the SAUL endpoints. Both the handler for the SAUL resources and the extended .well-known/core handlers would be good candidates for a utility module to nanocoap, as this seems a common use case.

kb2ma commented 4 years ago

I also agree that it would be useful for an event in some other module to propagate through gcoap to emit a notification. I don't know how much of this mechanism belongs in gcoap itself though.

It seems like you're describing one use for an application protocol like LwM2M. Ironically, I'm wondering myself what it would take to build a more resource constrained implementation of LwM2M based on gcoap. :-)

miri64 commented 4 years ago

[…] I don't know how much of this mechanism belongs in gcoap itself though.

Again: this issue is not solely about gcoap, but also SAUL.

miri64 commented 4 years ago

What I envisioned as an end product would be an optional module that maps SAUL resources to gcoap resources (let's call it gcoap_saul) and provides a gcoap listener for them. The list above points out the features missing in both gcoap and SAUL to make this kind of possible.

kb2ma commented 4 years ago

If I remeber correctly, the handler for .well-known/core in nanocoap is just a regular callback, with a default implementation for that for you to pick.

Right you are, @maribu! See Resource list creation in the gcoap doc.

kb2ma commented 4 years ago

What I envisioned as an end product would be an optional module that maps SAUL resources to gcoap resources (let's call it gcoap_saul) and provides a gcoap listener for them.

Totally makes sense and timely, @miri64.

miri64 commented 4 years ago

If I remeber correctly, the handler for .well-known/core in nanocoap is just a regular callback, with a default implementation for that for you to pick.

Right you are, @maribu! See Resource list creation in the gcoap doc.

Ok, I guess gcoap then provides everything I need and I was just too lazy to read the doc :-D.

miri64 commented 4 years ago

Mh, but wait... I thought that handler only encodes the link-format of a particular resource (at least that's how I interpret its usage in examples/gcoap). Or am I missing something? Can I just append more resources (logical CoAP resources, not physical gcoap resources) there? What I want is that the output of .well-known/core is extended by resources "hiding" behind a matched prefix. E.g. if I have a resource saul/ that is matching to saul/sense/light and saul/sense/mag, I want both the links for saul/sense/light and saul/sense/mag to show up at .well-known/core.

kb2ma commented 4 years ago

Yes, you could add more resources to the list as you describe. The gcoap example uses the default implementation gcoap_encode_link() to write the link and then only appends attributes. However, you could ignore the default implementation if you don't want the top level link (<saul>) on its own, and then write whatever you want.

miri64 commented 4 years ago

Ok, then for now all we need to kick-off a gcoap_saul module is a phydat serializer :-). Maybe, if I find some time this weekend I write one up for JSON.

Citrullin commented 4 years ago

Great, this sounds like the feature I need for the wot implementation I want to create.

jue89 commented 4 years ago

"reactive" SAUL to implement events that trigger a CoAP OBSERVE notification

I think #14121 could be a solution for this requirement.

miri64 commented 4 years ago

Mhhh, if I understand #14121 correctly, it is more about providing a reactive alternative to SAUL. In my mind I was more thinking about extending the SAUL API for this.

jue89 commented 4 years ago

Mhhh, if I understand #14121 correctly, it is more about providing a reactive alternative to SAUL. In my mind I was more thinking about extending the SAUL API for this.

I intend to extend SAUL - so I called it Extended Sensor Actuator Uber Layer ;) Of course, this requires additional code by the SAUL sensor / actuator since it knows best when its state has changed significantly.

The user of the SAUL library doesn't have to know whether its a SAUL device or a eSAUL device. It just won't receive change notifications by the SAUL devices and, thus, won't send OBSERVE notifications.

Have thought about how to extend SAUL to meet the stated requirement? I'd love to hear about it to come up with a sustainable solution for this problem.

miri64 commented 4 years ago

I intend to extend SAUL - so I called it Extended Sensor Actuator Uber Layer ;)

Ok, then maybe the fact that you gave it a new name (eSAUL) confused me. I would just stick with extended SAUL ;-) (mind the capitalization).

RIOT-OS / RIOT

gcoap: features required to wrap SAUL #13154