Feedback for I/O board binding dev

Hi all:

I’m developing a binding for a PCI I/O board. Before I get too deep, I’d like some overall feedback to ensure I’m doing things correctly.

The hardware is a PCI card with 96 pins, grouped in “ports” of 8 pins for a total of 12 ports. The I/O direction is selectable on a per port basis. Interaction with the card is accomplished through comedilib written in C.

Pins are connected to simple sensors such as reed switches on doors and relays around the house.

Most items I plan on adding to the openHAB setup will be directly tied to one pin, although some will require a bit of logic involving multiple pins (implemented in rules).


  • The binding implementation I’m shooting for is essentially the same as the GPIO binding’s, only it does not read /sys/class/gpio/… but rather uses comedilib and some bit masking to read/write to each pin. Since the GPIO binding follows the v1 model, I don’t think it will be as copy-pasting and making mods.
  • First, write a java wrapper for comedilib to initialize the card as well as read and write to the ports (8-bit values).
  • Each port will be represented as an openHAB channel. Each pin will be represented by an Item whose state will be changed based upon the port’s value. Each sensor/system around the house will be represented by an Item. Rules will implement the logic between “pin Items” and “house Items”.
  • The binding will have one configuration parameter per port to define its direction (input or output).


  1. General feedback: does the model above make sense? Are there better ways of going about anything?
  2. I was hoping to be able to associate things to card pins in the .items file through some syntax similar to that of the GPIO binding, for instance Switch frontLight “Pin 12” { comedi=“pin:12 activelow:yes initializeValue:high” }. Is this compatible with the one channel per port model described above? I believe this can be accomplished similarly to processBindingConfiguration in (GPIO binding). Which file in the v2 skeleton should this be implemented?

Many thanks in advance.


I don’t know how well OH supports JNI but have to believe this is not the only binding that is reliant on a C library.

  1. The model seems reasonable, though to me it makes more sense to make the input/output config be a parameter on the Thing instead of in the overall binding config.

  2. In an OH 2 style binding that isn’t how it works. You link Items to Channels on Things. That’s it. The association to the pin is managed at the Thing. The Thing represents the device. The Thing has Channels to represent the individual sensor data or actuators (each pin in this case). Items link to the Channel. Beyond the link, there is nothing else at the Item level beyond the link. That’s the part of the point of Things in the first place.