Openhab-addons: openHAB 1 addon compatibility overview with openHAB 2

[Hilbrand]

This issue contains an overview of all openHAB 1 addons and how/if there is an openHAB 2 version.

There are 3 tables. The first table contains the openHAB 1 addons with no (official) openHAB 2 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 are very unlikely to be supported in openHAB 3. The third table is with openHAB 1 addons that have a known openHAB 2 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 addons are not included because separate work has been done: PR #5275.

The column supported means if the addon is officially supported. This means it's included in the feature list and know 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 addons 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 addon. This can give an indication on the complexity of the binding.

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

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

| Addon | OH2 Binding | Supported | Poll results | Java LOC | Notes |
|--------------|---------------|-------------|--------------|----------|------------------|
| Actions |=====| =====| =====| =====| =====|
| mios | ~PR #2283~ | supported | 7 | 183 | PR closed |
| openwebif | | unsupported | 2 | 479 | |
| pebble | | supported | 4 | 215 | |
| prowl | | supported | 2 | 129 | |
| pushsafer | | supported | 1 | 184 | |
| tinkerforge | Issue #85 | unsupported | 1 | 129 | |
| twitter | | supported | 2 | 319 | |
| weather | | unsupported | 9 | 73 | |
| Bindings | =====| =====| =====| =====| =====|
| anel | | supported | 3 | 907 | |
| asterisk | | unsupported | 5 | 373 | |
| benqprojector| ~PR #4063~ | unsupported | 1 | 605 | PR Closed |
| cardio2e | | supported | 1 | 6540 | |
| cups | yes? | unsupported | 1 | 225 | Renamed as ipp? PR #164|
| ddwrt | | unsupported | 1 | 456 | |
| dmx.artnet | ? | unsupported | 1 | 62 | |
| dmx.lib485 | ? | unsupported | 0 | 51 | |
| dmx.ola | ? | unsupported | | 69 | |
| ebus | | supported | 1 | 2876 | |
| ecotouch | | supported | 2 | 1308 | |
| ekey | | supported | 0 | 374 | |
| enphaseenergy| openHAB-addons of HentschelT | supported | 2 | 438 | Forum post #44449 |
| fatekplc | | supported | 1 | 1437 | |
| fht | | unsupported | 2 | 745 | |
| freeswitch | | supported | 0 | 637 | |
| fritzaha | | unsupported | 1 | 1257 | |
| fs20 | supported | supported | 2 | 343 | Depends on cul transport. Supported via RFXCOM binding? |
| garadget | | supported | 4 | 752 |Can be replaced by MQTT |
| gc100ir | | supported | 0 | 1079 | |
| gpio | PR #1334 | supported | 18 | 494 | |
| 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 | |
| lightwaverf | Supported via RFXCOM binding? | unsupported | 1 | 3717 | Supported via RFXCOM binding? |
| maxcul/transport.cul | | supported | 4/1 | 2396 /1299 | |
| mios | ~PR #2283~ | supported | 7 | 1923 | PR is named vera. Mios seems to be rebranded to vera?
PR closed |
| mochadx10 | | supported | 1 | 828 | |
| myq | ~PR #4911~ | supported | 7 | 757 | Fullname is ChamberlainMyQ, PR Closed |
| mystromecopower | ~PR #2756~ | supported | 1 | 639 | PR Closed |
| novelanheatpump | | supported | 1 | 1060 | |
| omnilink | PR #8922 | unsupported | 2 | 2293 | |
| openenergymonitor | | supported | 5 | 791 | |
| openpaths | | unsupported | 1 | 507 | |
| owserver | | supported | 3 | 424 | |
| panasonictv | PR #9024 | supported | 8 | 214 | |
| piface | | supported | 0 | 634 | |
| pilight | PR #8469 | supported | 2 | 1161 | |
| plex | Issue #4949 | supported | 27 | 1804 | |
| samsungac | | supported | 0 | 1145 | |
| sapp | | supported | 0 | 1942 | |
| smarthomatic | | unsupported | 1 | 2162 | |
| sonance | | supported | 0 | 444 | |
| souliss | ~PR #4945~ | supported | 1 | 2729 | PR Closed |
| 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). |
| tivo | PR #9302 | unsupported | 1 | 120 | |
| ucprelayboard| | supported | 0 | 543 | |
| vdr | | unsupported | 1 | 620 | |
| wago | Supported via the modbus binding | unsupported | 0 | 626 | Supported via the modbus binding |
| weather | | supported | 31 | 3337 | |
| withings | PR #9154 | unsupported | 2 | 783 | |
| IO |=====| =====| =====| =====| =====|
| caldav | | supported | 24 | 181 | See the icalendar binding |
| gcal | | supported | 12 | 932 | |
| gpio | PR #1334 | supported | 10 | 795 | |
| 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. |

This is the table with all OH1 addons that have no OH2 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.

| Addon | OH2 Addon | Supported | Poll results | Java LOC | Notes |
|--------------|---------------|-------------|--------------|----------|----------------------------------- |
| Actions |=====| =====| =====| =====| =====|
| ciscospark | | unsupported | 0 | 189 | |
| xpl | | unsupported | 0 | 118 | |
| Bindings |=====| =====| =====| =====| =====|
| akm868 | | unsupported | 0 | 367 | |
| configadmin | | unsupported | 0 | 245 | |
| davis | Meteostick? | unsupported | 0 | 2307 | Meteostick? |
| 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 | | unsupported | 0 | 1776 | |
| xpl | | unsupported | 0 | 267 | This protocol is dead. Will not be ported.|
| zibase | | unsupported | 0 | 613 | |

This is the table with all addons that have an official openHAB 2 version.

| Addon | OH2 Addon | 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 |
| pushbullet | yes | | | 466 |
| satel | yes | | | 187 |
| squeezebox | yes | | 8 | 434 |
| telegram | ~PR #5677~ | | 47 | 369 | |
| xbmc | yes | | 10 | 72 | Replaced by Kodi Binding
| xmpp | yes | | 3 | 443 |
| Bindings |=====| =====| =====| =====| =====|
| alarmdecoder | ~PR #7189~ | | 3 |890 |
| astro | yes | | | 2563 |
| autelis | yes | | 0 | 300 |
| bticino | ~PR #6213~ | no | 0 | 2521 | Name: openwebnet, Misses Temperature Control and CEN commands |
| 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 |
| energenie | ~PR #6461~ | | 2 | 482 |
| enigma2 | ~PR #7514~ | | 3 | 520 |
| enocean | yes | | | 509 |
| epsonprojector | ~PR #9021~ | | 5 | 1853 | |
| exec | yes | no | | 745 |
| freebox | yes | | 0 | 625 |
| fritzboxtr064| ~PR #8523~ | | 52 | 1870 |
| 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 | | 7 | 3131 |
| 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 |
| 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 |
| ntp | yes | | 12 | 1929 |
| oceanic | yes | | 0 | 179 |
| onewire | yes | | | 820 |
| onkyo | yes | no | | 1769 | OH2 binding doesn’t support serial connection like in OH1 binding
| opensprinkler | yes | | 5 | 1515 |
| pioneeravr | yes | | 2 | 277 |
| plclogo | yes | | 1 | 1266 |
| plugwise | yes | | | 2189 |
| powermax | yes | | | 3553 |
| pulseaudio | yes | | 2 | 3829 |
| pushover | ~PR #8586~ | supported | 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 |
| squeezebox | yes | | 8 | 4150 |
| squeezeserver | yes | | 0 | 1168 | Supported by squeezebox
| systeminfo | yes | | | 393 |
| tacmi | ~PR #7768~ | | 1 | 469 |
| tellstick | yes | | | 776 |
| upb | ~PR #6742~ | | 0 | 744 |
| urtsi | yes | | | 1658 |
| 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.