Receiving content / observe option

[Chris Pearson]

I'm having an issue implementing a CoAP observe option with OpenThread. I haven't had any issues with publishing data to a server with put, nor adding resources on the device and accessing them from another client.

Watching the packets with Wireshark, I see the initial get message from my device to the server, and the server's acknowledgement. My device's response handler for that request is called for this message.

The problem is once there's an update on the server. The server sends a "2.05 Content" message with the updated data, but my OT device sends back a reset message. There is no call to either the message's response handler nor the default handler.

Is there something specific that needs to be configured for content messages? Unfortunately I'm not having any luck finding an example of this.

Thanks

[Jonathan Hui]

Have you taken a look at tests/scripts/thread-cert/test_coap_observe.py? This is a test script that validates the CoAP observe functionality and does so using the OpenThread CLI.

The coap observe CLI command may also be helpful.

--

Jonathan Hui

--
You received this message because you are subscribed to the Google Groups "openthread-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openthread-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/ad8959e3-40c7-4efb-aa7a-73810b6db321n%40googlegroups.com.

[Chris Pearson]

I have looked through the CLI code, and from what I can see I'm doing essentially the same thing as that code does. The only difference between a "regular" get and an observe seems to be the otCoapMessageAppendObserveOption(), and that option is clearly working for me. There is additional code in the CLI's HandleResponse() method for outputting the observe value, but in my case the handler never gets called after the initial acknowledgement.

I suppose my question is: what is the case where the initial acknowledgement from an observe request will lead to the handler being called, but no handler will be called for the 2.05 Content messages?

[Jonathan Hui]

It sounds like the client is not above to match the 2.05 Content message with an existing observer.

Can you provide the pcap file?

--

Jonathan Hui

[Chris Pearson]

Thanks for looking into this! I'm completely at a loss for what is missing here.

Attached are two pcap files. The one named "openthread.pcap" is from my OpenThread test device. The one named "cli.pcap" is from  libcoap's "coap-client" CLI example. Both are talking to the EMQX MQTT broker's COAP plugin. The coap-client example works correctly while the OpenThread example does not, and I don't see any significant differences in the network messages.

For the OpenThread test device, the initial exchange is an unsubscribe, since that is what the OT CLI example does when an observe is asked for. There's a delay before it sends the observe request, and then a bit of a delay until I put in some data to be forwarded to the device.

[Jonathan Hui]

Nothing stands out to me in the pcap files.

One question: how did you build your OpenThread library? Can you verify whether OPENTHREAD_CONFIG_COAP_OBSERVE_API_ENABLE was set to 1 (it defaults to 0).

--

Jonathan Hui

[Chris Pearson]

Thank you! That is exactly what the problem was.

I was quite certain that the setting was configured correctly, but I misunderstood what the Zephyr CONFIG_OPENTHREAD_COAP_OBSERVE was doing when I'm using the native OpenThread library.

Obviously this is another lesson to look at every reason why something might not be working, especially when the code is surrounded in something obviously like #if OPENTHREAD_CONFIG_COAP_OBSERVE_API_ENABLE blocks...

Thanks again for your help here. It's appreciated!

[Jonathan Hui]

Great to hear that it's working now.

--

Jonathan Hui