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!

[Didrik Rokhaug]

Hi,

 

How do I use PUT and GET using Nrf5xConsoleClient?

 You can run  the client without any arguments to get some documentation and examples on how it can be used.

Your suggestion is almost right, but the arguments are separated by a space, not a comma. So unless you try to put something to 'temp,', you should remove the comma.

 

2) Can you give some pointers to get the Thread+CoAP Cloud IoT example in the nRF5 SDK for Thread working with Californium?

 I haven't used Thread much myself, so I will need some time set this up and test myself.

Best regards,

Didrik

[thread_yoda]

Thanks for the pointers! I'll play with that and see how far I get and will keep you posted. 

I have another ticket describing my experience with the Thread+CoAP Cloud IoT example here if you're interested in getting some additional context: https://devzone.nordicsemi.com/f/nordic-q-a/62893/losing-connection-with-thread-coap-google-cloud-example

The CoAP proxy demo repo I was referring to that is leveraged by GCP is here: https://github.com/GoogleCloudPlatform/community/tree/master/tutorials/cloud-iot-coap-proxy

We are interested in the Californium technology but want to see how to deploy that in an Azure (or other public cloud) environment which is the genesis for this exercise.

[Achim Kraus]

Just to mention: there different kinds of "coap-http-proxies", and the one, which is developed for the gcloud tutorial is a special reverse proxy, implemented to co-operate with gcloud-iot. If you want to use a proxy for Azure, I guess you will need to implement a different special reverse proxy for the Azure API you want to use. Or do you just want o ensure, that Californium can run on Azure? If so, what do you expect / want to ensure? Simple CoAP/DTLS server? Load-balancing cluster? HA-cluster? AFAIK, the first should work on Azure. The second one depends on you network considerations. Using DTLS Connection ID is under develop, using other approaches (static client ips, frequent handshakes) you may consider the upstream project eclipse/leshan. HA-cluster requires either patience or very deep knowledge of DTLS. So, the main question is, what do you really want to exercise?

[thread_yoda]

Achim KrausThanks! I might take a look at the Leshan LWM2M server as that might be a better starting point. The user documentation around that seems to be a bit limited as well though. We just want to start reporting sensor data upstream and have the data be available for a web application via RESTful Web Interfaces so the web app does need to understand CoAP. So I think a CoAP/HTTP proxy is definitely needed.

[Achim Kraus]

Again, please, what do you really want to test?

- simple coap endpoint

- load-balancer cluster

- ha-cluster

leshan was just a link for load-balancer based on static client-ips.

[thread_yoda]

It is an on-premise system so a cluster I don't think is necessary so I guess it would be a simple coap endpoint. 

[Achim Kraus]

Thanks!

From my experience that works on clouds according their UDP support (you need 5683 (coap) or/and 5684 (coaps)). With k8s it should be no issues, if you use a recent version (1.19). Starting with a simple coap-server should result in fast success (e.g. you may use the cf-secure server you already used, or any other)

For more functions, especially calling other http-cloud-APIs, keep in mind:

A forwarding proxy translates your coap-request into a http-request. To use that, you need to check, if the http API of the services you want to use match that standard translation (see RFC 7252 - 10. Cross-Protocol Proxying between CoAP and HTTP).

The gcloud proxy does some "special stuff for you", mainly they handle the device's bearer token. Therefore, it's not a forwarding proxy, it's a special reverse proxy (and will mainly work for gcloud-iot).

So, if you want to use a other Cloud HTTP API using Californium's Proxy, you may need also some "special stuff.