openHAB 1 addon compatibility overview with openHAB 3

[Hilbrand]

This issue contains an overview of all openHAB 1 add-ons and how/if there is an openHAB 3 version.

Disclaimer: This list is not a planning or to do list. It just gives an overview of the status of migrations or known other new versions bindings. If you want to know if a binding will be available in openHAB 3 and it's not mentioned on the list ask on the openHAB forum. Use the comments to report new or changed entries to the list.

There are 3 tables. The first table contains the openHAB 1 add-ons with no (official) openHAB 3 version, but have been voted on in the poll or are being worked on. The table contains the links to the work-in-progress if known. The second table is with unsupported openHAB 1 bindings that have not be voted on. These bindings have potential very few users and therefor the chance someone will migrate it to openHAB 3 is very low. The third table is with openHAB 1 add-ons that have a known openHAB 3 replacement. When an openHAB 1 binding from the first 2 tables has been migrated it's moved to third table.

In the lists the persistence add-ons are not included because separate work has been done: PR #5275.

The column supported in the table means if the add-on was officially supported in openHAB 2. This means it's included in the feature file and known to work with openHAB 2 and show up in PaperUI when legacy mode is activated. If not supported it still might work, but it needs to be installed manually.

The poll results are from the (closed) poll from the openHAB forum: poll-which-oh1-x-addons-do-you-use. Some add-ons have no poll results because those have an openHAB 2 variant and were not in the poll.

The column Java LOC is the number of Lines of Code of the add-on. This can give an indication on the complexity of the binding.

The column Feature Compatible in the last table mentions if the openHAB 3 bindings lacks some features that where part of the openHAB 1 binding.

This information is compiled to have an overview of the differences and compatibility of different openHAB add-on versions. If something is missing or changed please comment or update this list. If you have or use an openHAB 3 binding but it doesn't have the same features as the openHAB 1 version please also report.

Add-ons to Migrate

Add-on	OH3 Add-on	Supported in OH2	Poll results	Java LOC	Notes
Actions	=====	=====	=====	=====	=====
mios	~PR #2283~	supported	7	183	PR closed
openwebif		unsupported	2	479
pebble		supported	4	215
tinkerforge	Issue #85	unsupported	1	129
weather		unsupported	9	73
Bindings	=====	=====	=====	=====	=====
asterisk		unsupported	5	373
cardio2e		supported	1	6540
cups	yes?	unsupported	1	225	Renamed as ipp? PR #164
davis		unsupported	0	2307
ddwrt		unsupported	1	456
dmx.artnet	?	unsupported	1	62
dmx.lib485	?	unsupported	0	51
dmx.ola	?	unsupported		69
ebus		supported	1	2876
fatekplc		supported	1	1437	Forum topic 113085
fht		unsupported	2	745
freeswitch		supported	0	637
fritzaha		unsupported	1	1257
fs20		supported	2	343	Depends on cul transport. Supported via RFXCOM binding?
garadget		supported	4	752	Can be replaced by MQTT
gc100ir		supported	0	1079
heatmiser		supported	0	1053
horizon		supported	1	371
intertechno	Supported via RFXCOM binding?	supported	1	519	Supported via RFXCOM binding?
isy	Branch isy-binding-new	unsupported	3	1078	No PR, but this branch seems to contain work on this binding
jointspace		supported	2	445
k8055		supported	0	352
koubachi		supported	0	656	Koubachi service no longer exists. Will not be ported.
lightwaverf		unsupported	1	3717	Forum topic 92264
maxcul/transport.cul	PR #9732	supported	4/1	2396 /1299	Forum topic 112897
mios	~PR #2283~	supported	7	1923	PR is named vera. Mios seems to be rebranded to vera? PR closed
mochadx10		supported	1	828
mystromecopower	~PR #2756~	supported	1	639	PR Closed
openenergymonitor		supported	5	791
openpaths		unsupported	1	507
owserver		supported	3	424
panasonictv	PR #11559	supported	8	214
piface		supported	0	634
plex	PR #12135	supported	27	1804	Issue #4949, Forum topic 111487, Branch: plex
samsungac		supported	0	1145
sapp		supported	0	1942
smarthomatic		unsupported	1	2162
sonance		supported	0	444
stiebelheatpump	~PR #3483~	unsupported	0	3228	PR Closed
swegonventilation		supported	1	804
tcp		supported	25	3528
tinkerforge	OH2 repo theoweiss	unsupported	4	91952	No PR, See also: ThinkerForge Forum/(#85).
ucprelayboard		supported	0	543
wago	Supported via the modbus binding	unsupported	0	626	Supported via the modbus binding
weather		supported	31	3337
withings	~PR #9154~	unsupported	2	783	PR Closed
IO	=====	=====	=====	=====	=====
caldav		supported	24	181	See the icalendar binding
gcal		supported	12	932
harmonyhub		unsupported	11	591
multimedia.tts .freetts		unsupported	1	54
multimedia.tts .speechdispatcher		unsupported	0	134
transport.xpl		unsupported	1	73	This protocol is dead. Will not be ported.

Unused Add-ons

This is the table with all openHAB 1 add-ons that have no openHAB 3 replacement, are not part of legacy and had zero votes. It's uncertain if these bindings are still used. If they are used they belong in the table above.

Add-on	OH3 Add-on	Supported in OH2	Poll results	Java LOC	Notes
Actions	=====	=====	=====	=====	=====
ciscospark		unsupported	0	189
xpl		unsupported	0	118
Bindings	=====	=====	=====	=====	=====
akm868		unsupported	0	367
configadmin		unsupported	0	245
diyonxbee		unsupported	0	519
ehealth		unsupported	0	432
em		unsupported	0	316	No readme
hms		unsupported	0	198
mcp3424		unsupported	0	342
octoller		unsupported	0	243
panstamp		unsupported	0	816
plcbus		unsupported	0	932
powerdoglocalapi		unsupported	0	532
primare		unsupported	0	1774
rpircswitch		unsupported	0	336
s300th		unsupported	0	305
sallegra		unsupported	0	377
wr3223	Code wr32243	unsupported	0	1776	frami/org.openhab.binding.wr3223
xpl		unsupported	0	267	This protocol is dead. Will not be ported.
zibase		unsupported	0	613

Migrated Add-ons

This is the table with all openHAB 1 add-ons that have an official openHAB 3 version.

Add-on	OH3 Add-on	Feature Compatible	Poll results	Java LOC	Notes
Actions	=====	=====	=====	=====	=====
astro	yes		34	131
dscalarm	yes		4	111
ecobee	~PR #6823~		8	293
harmonyhub	yes		15	126
homematic	yes		4	82
mail	yes			187
mqtt	yes			112
prowl	~PR #10967~		2	129	Forum topic 111478
pushbullet	yes			466
pushsafer	~PR #10790~		1	184
satel	yes			187
squeezebox	yes		8	434
telegram	~PR #5677~		47	369
twitter	~PR #10241~		2	319
xbmc	yes		10	72	Replaced by Kodi Binding
xmpp	yes		3	443
Bindings	=====	=====	=====	=====	=====
alarmdecoder	~PR #7189~		3	890
anel	yes		3	907
astro	yes			2563
autelis	yes		0	300
bticino	~PR #6213~	no	0	2521	Name: openwebnet, Misses Temperature Control and CEN commands
benqprojector	~PR #10341~		1	605
bluetooth	yes		5	398
caldav-command	~PR #6453~	no	23	469	Implemented as iCal, which offers similar features, but read-only
caldav-personal	~PR #6453~	no	32	606
comfoair	~PR #7052~	yes	9	3100
cups	yes?		1	377	Renamed as ipp? PR #164
daikin	yes		1	1553
denon	yes		9	5233
digitalstrom	yes		0	1826
dmx	yes			3368
dscalarm	yes		3	1581
dsmr	yes			2121
ecobee	~PR #6823~		9	6181
ecotouch	~PR #10010~	supported	2	1308
ekey	~PR #10996~		0	374
energenie	~PR #6461~		2	482
enigma2	~PR #7514~		3	520
enphaseenergy	~PR #9883~		2	438	Renamed enphase Forum topic #44449
enocean	yes			509
epsonprojector	~PR #9021~		5	1853
exec	yes	no		745
freebox	yes		0	625
fritzboxtr064	~PR #8523~		52	1870
gpio (io)	~PR #1334~		18	494 (795)
harmonyhub	yes		14	786
hdanywhere	yes		0	360
homematic	yes			450
http	~PR #8521~		95	995
hue	yes		18	4651
iec6205621meter	yes		1	732	smartmeter binding
ihc	yes			878
insteonhub			1	1246	Replaced by OH1 insteonPLM
insteonplm	~PR #6911~		13	6637	New binding is called insteon. PR merged
ipx800	~PR #5457~		1	1397	Renamed to GCE
irtrans	yes			2724
km200	yes		2	855
knx	yes			2272
lcn	~PR #7509~		1	6384
lgtv	yes	no	7	3131	LGWebOs and LG Serial OH3 bindings use a different protocol, so might not be compatible
mailcontrol	yes		3	1936
maxcube	yes		2	634
mcp23017	yes		0	2853
milight	yes			342
modbus	yes			892
mpd	~PR #7870~		2	869
mqtt	yes	no		12830
mqttitude	yes			1083
myq	~PR #9347~		7	757	Fullname is ChamberlainMyQ
neohub	~PR #5952~		0	467
nest	yes			415
netatmo	yes			2282
networkhealth	yes			3053
networkupstools	~PR #6192~		26	244
nibeheatpump	yes			190
nikobus	~PR #6021~		9	1109
novelanheatpump	~PR #9669~		1	1060	Renamed to luktronik Forum topic 70743
ntp	yes		12	1929
oceanic	yes		0	179
omnilink	~PR #8922~		2	2293
onewire	yes			820
onkyo	yes	no		1769	OH3 binding doesn’t support serial connection like in OH1 binding
opensprinkler	yes		5	1515
pilight	~PR #9744~		2	1161
pioneeravr	yes		2	277
plclogo	yes		1	1266
plugwise	yes			2189
powermax	yes			3553
pulseaudio	yes		2	3829
pushover	~PR #8586~		30	669
rfxcom	yes		4	1281
rme	yes		0	8382
rwesmarthome	yes			448
sagercaster	~PR #4754~		0	5542
samsungtv	yes		13	2094
satel	yes			847
serial	~PR #8851~		24	636
snmp	yes		21	2979
sonos	yes		7	668
souliss	~PR #11083~		1	2729
squeezebox	yes		8	4150
squeezeserver	yes		0	1168	Supported by squeezebox
systeminfo	yes			393
tacmi	~PR #7768~		1	469
tellstick	yes			776
tivo	~PR #9302~		1	120
upb	~PR #6742~		0	744
urtsi	yes			1658
vdr	~PR #9947~		1	620	Issue #9931
velux	~PR #2531~		9	8494
wemo	yes		4	480
wol	~PR #8336~		42	147	Part of network binding
xbmc	yes		11	1998	Replaced by Kodi Binding
yamahareceiver	yes		5	577
zwave	yes			18948
IO	=====	=====	=====	=====	=====
multimedia.tts.googletts	yes		3	229
multimedia.tts.macintalk	yes		0	35
multimedia.tts.marytts	yes		2	70
transport.mqtt	yes		46	604
Other	=====	=====	=====	=====	=====
expire	~PR openhab/openhab-core/pull/1803~		95	239	Added as core framework feature

[udo1toni]

squeezeserver is covered by squeezebox. I'm not aware of a special squeezebox2 action but only squeezebox1 action.

[Hilbrand]

@udo1toni Thanks for reporting. I've updated the table and moved squeeseserver to the 2nd table.

I'm not aware of a special squeezebox2 action but only squeezebox1 action.

Do you mean the action is supported in the squeezebox2 binding or if there is still some functionality missing in the squeezebox2 binding?

[mvalla]

For v1 [bticino], a new openHAB 2 version is being finalized, called [openwebnet]. See #5195

[wborn]

That's an impressive table! I don't think the poll result can be mapped directly to user value. Otherwise we would know what migrations would yield the most value given the complexity. ;-) It does give some sort of idea though.

[udo1toni]

Do you mean the action is supported in the squeezebox2 binding or if there is still some functionality missing in the squeezebox2 binding?

afaik there is no action with squeezebox2. But there is a squeezebox1 action.

There are 3 oh1 jar files, action.squeezebox binding.squeezebox and io.squeezeserver. The io was needed to use the binding and/or the actions. So squeezeserver is part of squeezebox2.

[Hilbrand]

@mvalla Thanks for reporting. I've updated the table and also added oh1 migration label to the issue.

afaik there is no action with squeezebox2. But there is a squeezebox1 action.

@udo1toni I checked to documentation of both 1 and 2 and it seems the actions of 1 are covered by the 2 version. By using item directly and an AudioSink implementation. So I assume the OH2 version is feature compatible.

[J-N-K]

What is missing in MQTTv2?

[Hilbrand]

@J-N-K I thought I'd seen something about not being able to use mqtt binding connect to openHAB instances as an eventbus: https://www.openhab.org/v2.3/addons/bindings/mqtt1/#event-bus-binding-configuration. But I might be wrong about this.

[udo1toni]

At least mqtt2 has some restrictions to mqtt1, for example there is no option to send different topics for different commands of the same channel (you'll need this to control tasmota 6.6.015+ roller shutter feature)

[davidgraeff]

espeasy has adapted its mqtt usage. I remember that I have talked to the tasmota guys as well. mqttv2 should not support broken mqtt usage patterns imo.

[udo1toni]

I'm completely on your side ;) @davidgraeff

[jaywiseman1971]

Guys,

Ecobee has an action 1.x binding also; not seeing it in the Action section/column.

Best, Jay

[clinique]

There's a replacement for IPX800 v1 binding : PR 5457

[Hilbrand]

@jaywiseman1971 The Ecobee action is mentioned in the first table. Did I miss anything?

@clinique Thanks for mention it. I've updated the table and added the oh1 label to the pr.

[jaywiseman1971]

Hi @hilbrand,

I thought the 2 tables were broken out as addon and addon action bindings. Just wanted to make clear that ecobee has 2 different bindings.

Sorry for the confusion.

Best, Jay.

[hmerk]

@Hilbrand PR #3890 has nothing to do with the openHAB 1.x energenie Binding, unfortunately similar names. But I have nearly finished an energenie Bining for openHAB 2.x, running in my test environment since yesterday. We might be able to get it into 2.5 Release, so another migration done.

[pavel-gololobov]

XMPPClient Binding (https://github.com/openhab/openhab2-addons/tree/master/bundles/org.openhab.binding.xmppclient) is replacement for OH1 xmpp action.

[wborn]

Please don't press the X on these issues because it will unpin them and then no one will see them @markus7017. They aren't dismissable like cookie popups. :wink:

[mhilbush]

FYI I updated the table to include PR #6823 for the Ecobee binding.

[boehan]

Could someone include PR #7052 for the ComfoAir binding?

[bobadair]

Updated table to add new PRs for comfoair and alarmdecoder.

[bobadair]

Updated the table with the following changes:

• alarmdecoder merged
• ecobee merged
• enigma2 new PR #7514
• epsonprojector new PR #7370
• insteonplm merged
• sagercaster merged
• velux merged

[bobadair]

Updated the table again to add new PR #7509 for LCN.

[PaulL1]

For the MAXCul binding, I think the only equivalent binding (at least that I can find) in OH2 is the Max binding. However, they're not equivalent - the Max binding requires a gateway in order to work (a Max Cube), whereas the MaxCul binding can connect directly to the individual Max heating thermostats.

These aren't cheap devices, relatively speaking, so in moving to OH3 (i.e. losing the OH1 compatibility layer), I'd need to buy 14 devices for around 30 euro each....about $500 euro, plus shipping to NZ is fairly expensive too. I'd probably move to the Homematic IP devices I guess, which do have an OH2 style binding.

Ultimately, it'd be preferable for the MaxCul binding to be upgraded/ported. I suspect it also needs the serial IO ported to support the CUL USB stick. Is that on someone's radar, or realistically this functionality is going to become deprecated?

[hmerk]

@PaulL1 This is not completely correct. The MaxCUL Binding does not communicate directly with the devices, it uses the CUL, which can be seen as an aequivalent to the CUBE. With openHAB 2.x, You can use a combination of running homegear/homematic binding, so there is no need for anything else. But feel free to start porting the MaxCul binding to V2.

[PaulL1]

Thanks @hmerk - Homegear is an external set of software it appears, and will use the CUL. But I can't see any suggestion that it supports the Max protocols, it looks like it supports Homematic as well. So that comes back to my point - I don't think they're the same thing, so I don't think it's correct to mark the MaxCul module as having an equivalent in OH2.

Yes, I could start porting the binding myself, thanks for that suggestion. My question started at the baseline - is it known that they aren't the same thing, am I missing something, is someone already doing something about it? No point in me doing something if someone's already doing it and it's already known.

[PaulL1]

Sorry, I stand corrected. This page: https://doc.homegear.eu/overview/ has no indications of support for Max. However, this page: https://ref.homegear.eu/devices/ looks like it reports at least some support for Max.

So effectively I think you're saying, in your view at least, that the path into the future is that OpenHab no longer supports CUL, but that it can be replaced by installing Homegear, which can use the CUL to communicate with Max devices, and presumably exposes those devices back in a similar way to Homematic devices.

I accept that the Max devices are pretty low volume and probably becoming less common over time since Homematic has replaced them, and so if this is a sensible path (basically saying that we'll rely on Homegear to support them, rather than building our own) then I can understand that. My questions though are:

1. Do you know if anyone has tried that - i.e. is that a matter of "I see no reason that wouldn't work" or is it "it's been done and it works fine"?

2. Is it possible that we could better document that that is the path - I presume I'm not the only person using Max devices? It certainly wasn't intuitive from the documentation that the recommended path for Max devices is to use Homegear to bridge to the CUL/Max setup

3. I think the other path is to just keep an OH1 install, which is what I have at the moment, and I connect over MQTT to my Openhab2, with all the rules living in the OH2. My concern had been that eventually the OH1 would stop working or have dependency problems, so I should look to see if there's a path into the OH3 world

For me, it's certainly plausible that I migrate the two RPIs that have CULs to Homegear, and then connect to that from the RPI that is running OH2 and holds all the rules etc. And if nobody has done it before and/or it needs documenting, I can probably write a tutorial on how to actually get that going and convert from the OH1 syntax. Again, before I spend that time I'd like to know if any of this material is already in existence, so I can build on what's gone before rather than reinventing it.

[Hilbrand]

@PaulL1 I've moved the maxcul binding in the list above to the table of bindings not yet migrated. From this list at least 4 people seem to have indicated to use this binding as was queried in the poll last year on the forum. So there might be more people using it.

I haven't looked at the difference between the max and maxcul binding, but if it targets the same devices it might be feasible to add a new bridge to the max binding to support cul. That way it will be easier to support.

To see if other people are using it you can best ask on the forum. And you always have the option to offer a bounty (and see if you can get other people to join). If that is a serious bounty other developers might be inclined to do the migration and it might be economically cheaper in the end.

[hmerk]

@PaulL1 I do run homegear together with a reflashed CUBE (CUNx) to control my Max devices. Heomegear definitely supports the Max family. Their website has documentation for setup, and you will also find information in our community. I myself wrote a tutorial for reflashing the Cube and do the setup in openHAB.

[PaulL1]

Thanks for the information. I think my path will likely be to the Homegear solution, and I'll document that migration. I think it makes more sense long term for Openhab to leverage an existing and well supported solution rather than spend effort providing support for what is already a relatively low volume platform, and over time will become lower volume still (the devices have been replaced by Homematic). I do also note that it looks like Homegear gives access to more information and options than the Maxcul binding ever did, which is also useful.

For my use at least it should work fine, as I was already federating multiple openhab instances using MQTT, it's not a big deal to shift to using Homegear on the remote pis. For others this may mean needing to install both Homegear and Openhab, and may lead to some users just moving to using Homegear instead.

[bobadair]

Updated table to reflect recently merged PRs for comfoair (#7052), mpd (#7870), and upb (#6742).

[mvalla]

@Hilbrand, regarding bticino1 binding in table 3, it's not true that it's feature compatible with the v2 binding (openwebnet) yet. The former supports Temperature Control and CEN commands, not yet supported in the latter. Maybe it's worth opening issues for these features to be supported in the new binding.

[Hilbrand]

@mvalla I've updated the table to reflect it's status of not being fully compatible. Yes it is worth opening an issues. If you open an issue I'll update the table to link to the issue(s).

[Rossko57]

Regarding WAGO binding 1.x I'm pretty confident that all the necessary functionality to support WAGO devices is present in the Modbus 2.x binding. WAGO PLC are a bit odd (even for Modbus) but over the last couple of years v2.x Modbus binding has been able to be configured for every use case.

Executive summary - "Abandon WAGO"

[PaulL1]

Minor update for future people who may visit this thread. I've moved from using legacy 1.x Openhab for MAX, to using Homegear. The migration was relatively smooth, and Homegear is an order of magnitude faster and cleaner operating than the old Openhab addon was. Previously I had large numbers of retried messages, and therefore running out of credit a lot. With Homegear basically every message is going every time, and I got access to more information from the devices (including signal strength).

The only element that I can't get working is switching wall thermostats to show current temperature, which I'll raise elsewhere.

[CWempe]

I just want to clarify that the onewire binding does not cover the owserver binding.

The later is a binding that reads values via http from a device that does all the 1-wire work, like a gateway.

You might argue that you can simply replace this proprietory device with a Raspberry PI or an Arduino and use MQTT. But me (and probably other users) would be happy we would not have to change our hardware because of a new software version of openHAB. 😉

Maybe @cdjackson or @teichsta can say something about this binding. It looks like they were the main developers.

[gabek1866]

Are there any plans to incorporate the omnilink binding into the OH3 baseline? I believe there was work on an OH2 version of this binding that was working pretty well from the IOT Marketplace.

[fapgomes]

Hi,

And for binding cardio2e? There are any plans? What is needed to migrate to OH3, maybe I can help.

Best Regards, Fernando Gomes

[Hilbrand]

@gabek1866 See the list. There is a new pr to get the omnilink into openHAB 3.

@fapgomes If there is notihing of the list here it's probably unknown if someone is working on it. You might ask on the forum if someone is working on it. Related to the work that needs to be done. For migrating OH1 bindings it's not much different to migratie to OH2 or OH3. The most work is for both the same: To introduce things and rewrite the code handling. I've posted a guide on the forum to get people started on the migration.

Edit: updated the post with link to guide

[fapgomes]

@Hilbrand Can you share the link?

You're talking in the OH forum right? I already posted here: https://community.openhab.org/t/cardio2e/108260 , that points me to this link.

[Hilbrand]

@fapgomes The topic for migrating is here: https://community.openhab.org/t/tutorial-migrating-oh-1-addon-to-oh-2-preparing-1-x/ Ah. You already posted on the forum. So I think we can assume noone is working on it.

[hmerk]

@Skinah Please don‘t unpin issues.

[Skinah]

Sorry don’t know how it happened, maybe from scrolling on phone I pressed something but I have not been on this issue recently.

[Flole998]

@Hilbrand I think we should list issues that are related to non-feature-compatible bindings in your post, for example #5886 is a reason why the exec binding is not feature-compatible at the moment. That makes it easier to track when they become feature-compatible.

[Hilbrand]

@markus7017 Why do you keep unpinning this topic?

[delid4ve]

Has somebody or can somebody point me to the last release version of the lightwaverf v1.x binding. Although it’s listed still, the binding is actually missing. I have a working v2.x binding which I will upgrade to 3.x but need to add backwards compatibility for old hardware which is still used by many (different api).

[hmerk]

@delid4ve are you looking for this ? https://github.com/openhab/openhab1-addons/tree/master/bundles/binding/org.openhab.binding.lightwaverf

[delid4ve]

Thanks - don’t know why I just couldn’t find it, GitHub not my strong point for sure 😂 Why is it not included in the latest builds? (2.5)

[hmerk]

What do you mean, is it not installable in openHAB 2.5.11 ? Or are you looking in openHAB-addons repo? If last, you won‘t find any oh1 bindings there, they reside in openhab1-addons repo.

[delid4ve]

What do you mean, is it not installable in openHAB 2.5.11 ? Or are you looking in openHAB-addons repo? If last, you won‘t find any oh1 bindings there, they reside in openhab1-addons repo.

Its not been installable since about 2.4, still in the docs though and no idea why not. Last time I looked I couldn’t find it in v1 repo either, but the link you gave me shows me it is there now 🤔