As I wrote in issue 3235 on Github, etcd has an easy-to-use HTTP interface, and it’s very easy to poll for changes across an entire subtree, making it most suitable for storing current or intended device state.
Basic idea: some client writes “ON” to /home/intent/some/where/light/state, OpenHAB monitors /home/intent, sees that entry, turns on the light (no matter which tech), then writes “ON” to /home/current/some/where/light/state. Or the other way 'round, to attach some external interface OpenHAB can’t yet talk to.
Why not simply use MQTT? Well, as a user (or as a program that doesn’t run all the time) I’m interested in my system’s current or intended state; messaging is simply a means to that end. Thus ideally I want to directly set or query the state I’m interested in, and let the back-end (OpenHAB or otherwise) handle the rest.
In time I imagine there will be bindings for this stuff (along with CoAP, confd, ZooKeeper etc, etc) since they’re all doing basically the same thing… persisting something in a manner for later retrieval by another [potentially unrelated] component.
If you have a compelling need for it now, you can prototype parts of it using something from the HTTP Actions collection. You’d have to poll periodically for changes (etc), but it’s not complex to get something basic up and running. There are tons of examples on the forums here for using JSON etc.
Alternatively, I’d imagine it’d only take a few lines of Python to write a MQTT <> etcd bridge.
If you went that route you could use MQTT within openHAB, and have it sync with your etcd as needed. It’s a few more moving parts overall, but it’d get you a quicker prototype.
I did that recently to bridge in my Energy-Monitoring device, since it’s easier to have “less bindings”, and the Python was a ton easier to write than the equivalent in Java.
