[SOLVED] Are there equivalents binding in OH2?


I am using openHAB 2.4 (docker) and I currently use the following OH1 bindings:

  • http1
  • expire1
  • wol1
  • serial1

Are there equivalents bindings for openHAB2 (PaperUI shows only OH1 version and I am wondering if I missing something here)?


For http, I have seen a pull request to create a OH2 version (not sure if it is already merged, and “http” is pretty hard to search for in the github PR list :slight_smile: )

For the expire “binding” there is discussion that this thing is really really needed in OH2, and Kai pitched in saying that it should be a core feature and not a binding. It was wrongly modeled in OH1.

There currently are no equivalent OH2 bindings, but one of them is on the way:

http: https://github.com/openhab/openhab2-addons/pull/4342

But not merged!

  • http1: Already mentioned. Will be merged by OH2.5 probably.
  • wol1: Will be part of the network binding for OH2.5
  • serial1: There is core support for serial communication, but not exposed as a separate binding. Instead there is a USB binding for OH2. (So you need to basically use a usb-serial converter, I guess. Haven’t looked into that). But I do assume that there will never be a 2.x version, the interface is just too old.
  • expire1: See my Paper UI NG design study: https://davidgraeff.github.io/paperui-ng/schedules.html. Scheduled tasks will be a core feature for 2.5 or 3.0. Will be different to configure than “expire” of course. Based on item meta-tags I can imagine that we can come up with a solution that is kind of similar though.


There are many adapters, like Bluetooth, Zwave, Zigbee, that still need a “virtual” “serial” (although they are connected via USB) and of course older devices with serial interface. Some of them could be replaced with a “serial to ip converter” or “serial to usb converter” but not sure if all old devices are running with this (or the corresponding binding supports communication via IP or USB at all!)

EDIT: A lot of OH2 bindings need org.openhab.core.io.transport.serial not the serial1 binding itself.

But e.g. the “official bluetooth binding” in combination with a BlueGiga adapter (on Windows !), is only running when I install serial1, too!

@David_Graeff (And the others :slight_smile:)

Thx for the detailed response. Good to know that in 2.4 I don’t need to do any changes for now. In future versions I will probably change to new bindings (as I did with MQTT) , unless it will be too complicated and I will than use secondary openHAB deployment just to bridge old binding (easy when you are using dockers).

This is why I think to use secondary old openHAB deployment just as a bridge to the old bindings.


What will you recommend users using their “old devices” with serial interface only? “Buy an USB converter (or Serial to IP converter) or whatever, wait until corresponding binding is customized and hope it is running?” Or: “Throw away your old device because the interface is too old and buy a new one?”

Both options are fine. An adapter costs $10. The interface is very low-level as well. We have no binding to manipulate memory bits as well, to provide an analogy. So there better is a separate process running that translates to a higher level interface, like sockets, tcp, mqtt etc. The serial transport bundle in core is also using a c++ library internally.

But it is central for many users who connect to random stuff like alarm systems or stereo receivers.

I don’t see what would prevent a developer, should they choose, to develop a Serial binding that uses the central service to provide access. As with all the 1.x bindings, it would require a developer willing to do the work, but I don’t see any technical reason why it can’t happen.

1 Like

Unfortunately, that didn’t happen. :unamused: Will it be released with OH 3.0 or even earlier?