Getting Thread+CoAP Google Cloud IoT Example working with Californium

[thread_yoda]

Didrik Rokhaug Continuing the discussion that was documented here: 

https://devzone.nordicsemi.com/f/nordic-q-a/64691/how-to-use-the-latest-version-of-californium

1) I modified the resources a bit to better reflect our use case. However, can you give some pointers on what's the proper use of the arguments for the nRF5 console java client? What I received from the cf-secure output is the following

19:45:32.504 INFO [MessageTracer]: DTLS([fe80:0:0:0:d832:d8c5:ecf5:6a8a%10]:5694,ID:A5AA854700) ==> req CON-PUT MID=29594, Token=3436423F656D00B0, OptionSet={"Uri-Path":["tempsensor","temp,"], "Content-Format":"text/plain"}, "30"
19:45:32.511 INFO [ServerMessageDeliverer]: did not find resource /tempsensor/temp, requested by /fe80:0:0:0:d832:d8c5:ecf5:6a8a%10:5694
19:45:32.516 INFO [MessageTracer]: DTLS([fe80:0:0:0:d832:d8c5:ecf5:6a8a%10]:5694,ID:A5AA854700) <== res ACK-4.04 MID=29594, Token=3436423F656D00B0, OptionSet={}, no payload

How do I use PUT and GET using Nrf5xConsoleClient?

PUT coaps://[fe80::d832:d8c5:ecf5:6a8a]:5684/tempsensor/temp, 30

Is this correct for PUT?

2) Can you give some pointers to get the Thread+CoAP Cloud IoT example in the nRF5 SDK for Thread working with Californium? Is it better to start with the github repo for the CoAP Proxy demo? But I think this was using an old version of Californium. Not sure how to reconcile the two.

Thanks!

[thread_yoda]

Ok thanks for the tips. After removing the comma PUT works like a champ and i was also able to verify GET works as well. Cool!

Now if we can figure out how to tie this in with the Thread+CoAP example this will be great.

[Marjeris Romero]

Hi thread_yoda,

Perhaps it would be easier to start with the Simple CoAP Client example: https://infocenter.nordicsemi.com/index.jsp?topic=%2Fsdk_tz_v4.1.0%2Fthread_client_server_example.html&cp=7_3_2_10_4_2_2&anchor=thread_client_server_example_coap-server

You will then need to implement a similar functionality the as thread_coap_utils_unicast_light_request_send function, but entering the correct address and URI paths for your Colifornium server.

BR,

Marjeris

[thread_yoda]

Hi Marjeris, thanks for your reply but I am not sure this is the correct place to start since it is a different paradigm from the simple coap client + server model. I want to POST updates which is going to cause a resource to be created on the Californium side I believe. This is how it is supposed to work with the Thread+CoAP Google IoT example. Please advise.

[Jørgen Holmefjord]

Hi,

As far as I can see, the CoAP specifications does not specify that the resource will be created for either PUT or POST, it depends on the server implementation:

"The POST method requests that the representation enclosed in the request be processed. The actual function performed by the POST method is determined by the origin server and dependent on the target resource. It usually results in a new resource being created or the target resource being updated."

"The PUT method requests that the resource identified by the request URI be updated or created with the enclosed representation. The representation format is specified by the media type and content coding given in the Content-Format Option, if provided. If a resource exists at the request URI, the enclosed representation SHOULD be considered a modified version of that resource, and a 2.04 (Changed) Response Code SHOULD be returned. If no resource exists, then the server MAY create a new resource with that URI, resulting in a 2.01 (Created) Response Code. If the resource could not be created or modified, then an appropriate error Response Code SHOULD be sent."

You are correct that the Google Cloud example uses POST, and this may lead to the resource being created in the server.

I have created a modified version of simple_coap_client for you that supports both PUT and POST message types. You need to specify the IPv6 address of the server as a string in the top of the main.c file (coap_post_peer_address_string variable) for unicast messages to work. Press button 1 on the DK to send a unicast POST message to the specified address, button 2 to send a multicast PUT message, and button 3 to send a unicast PUT message to the specified address.

7673.simple_coap_client_post_put.zip

I tested this towards the simple_coap_server example, by modifying light_request_handler in thread_coap_utils.c to accept both POST and PUT messages:

if (otCoapMessageGetCode(p_message) != OT_COAP_CODE_POST &&
    otCoapMessageGetCode(p_message) != OT_COAP_CODE_PUT)
{
    break;
}

This sniffer trace shows all message types working well:

Best regards,
Jørgen

[Achim Kraus]

If you refer to the gcloud-iot-coap-proxy then please obey, that a "proxy" forwards the request, it doesn't really process them. That proxy maps coap-requests (check the client in that tutorial) to the gcloud iot-core - gcloud iot http API. It supports, AFAIK, the bearer token handling, a POST publishEvent, a POST setState, and a GET config. But it doesn't really implement these request, it converts the coap-requests into http requests. It does this in a special way, required by the gcloud iot http API. Therefore it's not directly possible to use it for other clouds, e.g Azure. If the device want's to sent other requests as supported by the proxy, I guess it will fail. You will also not be able to execute other http requests, which are not supported by the API of the service.