CODEWITHSUNDEEP
iotm2mcoap
TheGribble
TheGribble

Reputation: 25

I'm thinking about running a COAP system backwards, is this a terrible idea?

I'm building a very simple sensor that needs to upload data to a cloud server for storage and I'm looking for a simple protocol to use. I'm running on a PIC chip so I'm pretty seriously constrained on memory so it really will have to be simple.

I've been looking at COAP and it's got some things I really like: the UDP packets are small and simple so it will be easy to implement and cheap in terms of data usage but it feels the wrong way round for what I'm after.

As far as I can see it works by having a server poll all devices it's interested in to collect their readings as required. In my case though the communication is event based, I'll probably be transmitting one reading a week normally but then might be transmitting loads of readings quickly if something happens at the device end. There do seem to be extensions to COAP for allowing notifications but they rely on keeping a socket open to the device and waiting for responses.

I'm thinking about a similar protocol based on small, simple UDP packets where the device just posts data to a web service and gets a response to say it's been acknowledged, with possibly a mechanism for sending data the other way when the client object connects. Does anybody know of anything like that out there already, before I start reinventing the wheel?

Thanks,

Ben.

Upvotes: 1

Views: 109

Answers (1)

en1010
en1010

Reputation: 1300

Will CoAP Observe work for you?

https://www.rfc-editor.org/rfc/rfc7641#page-4

It is not a part of CoAP RFC but the COAP RFC mentions it and most of mature implementations has the "Observe" RFC implemented as well.

You may combine it with the regular way of requesting.

Also, in one project I've introduced a concept of "session".
It is suitable when you may schedule the sessions or periodic connections is suitable for you, or there is some event which can lead to a session initiation.

Device makes PUT "/session" and CoAP server starts a session and fetches data with GETs or putting something with PUTs. When nothing is remaining to do, the CoAP server sends CON-DELETE "/session" and device goes offline. Sure you need a timeout to force the device to go offline if session close request didn't come for the long time.

Please note: in RFCs a client is a endpoint which does request and server is a endpoint which responds. It can make some confusion. In practice, both the embedded device and a server can act as a client+server the same time.

Upvotes: 1

Related Questions