Embedding a CoAP server in openhab?

I’m building some devices for use in my home that use the Thread protocol for their wireless communication. The devices are being built with partical.io mesh dev boards, which use CoAP.

So, I need CoAP endpoint support in OH2.

I’m taking my inspiration from the work done by @David_Graeff for the MQTT binding.

I have only done one OSGi project, an eclipse plugin several years ago.

My initial research has me looking to embed Californium https://www.eclipse.org/californium/
It is OSGi based java implementation of CoAP.

I have the eclipse add-on dev environment setup and generated a new binding shell.

Maybe the MQTT binding could be extended? Abstract the Things/Items for MQTT thing/Device implementations and CoAP Thing/Device implementations?

I look forward to feedback.

Hmmm… Tradfri binding uses Californium 1.0.7 to communicate with the Tradfri gateway.
Californium 2.0 is soon to be published.

One difference is that I will be communicating directly with the devices via ipv6, no hub involved. The Thread border router would be transparent to OH2. @kai, do you have any thoughts?

I did a coap binding skeleton as well back then and did actually extend the californiums dtls implementation for this purpose at that time. But didn’t come to finish the binding.

Would be super sweet to have coap next to mqtt, discovery could be implemented for some of the common OCF and lwm2m things. Back then I wrote an xml transformation to create OH Thing files from the lwm2m registry.

Cheers, David

@David_Graeff do you have your incomplete coap binding skeleton somewhere? like Github?

@David_Graeff
I’m modeling my design off your MQTT design

An instance of a CoAP server will be represented by a Bridge Thing
A CoAP device will be Thing associated with a CoAP Bridge thing
Support an OH embedded Californium server as a CoAP Bridge.

The MQTT binding is dependent on a OH core bundle, org.openhab.core.io.transport.mqtt.
Is this a legacy of OH 1 MQTT binding? Can CoAP be completely implemented in the add on binding?

Core offers so called “transports” that should encapsulate external libraries into an OH API. That allowed for example to recently replace the paho mqtt library. The idiomatic way is to also have a transport for coap, but to be honest that’s not really necessary. The ikea tradfri binding is using californium directly.