If SNMP doesn’t make the cut to OH 3; I will be very busy trying to find another solution to track phones connecting to my wireless. And before anyone asks about arping, it will not work for my infrastructure as my OH sits in a different subnet from my wireless clients
Happy to test any new developments for a SNMP OH 3 SNMP binding!
@kai, could you please explain why some OH1.x addons are not in the feature.xml?
That’s very simple: Nobody ever has tested it and confirmed that it is working with OH2 (while it is available as a bundle for OH1) and thus it has not been added to the 2.x distro. See https://www.openhab.org/docs/developer/legacy/compatibilitylayer.html#how-to-add-a-successfully-tested-1-x-add-on-to-the-distribution for details.
Thank you, Kai! I’ve included them in the poll now.
It’s in there now!
Vote here, discuss there…
This is fantastic, however I have no idea what to do/how to proceed with these; nothing that needs to go into detail here. I’m gong to do some reading and see if I can figure it out.
Excellent, thanks! The FHT binding now has at least one vote 
Anybody who votes on one of these should make a PR that adds it to the distro!
These could be getting votes from people who are still using them in OH1 though. So, only people using them in OH2 should follow the steps to get them into the distribution.
Would be nice to have a feature to create those statistics from openHAB. Either as a feature to activate or on purpose.
Of course there should be a unique id to be sent with, to prevent miscounting.
But this would mean that data is collected. It’s like the old feature “show openHAB installations on google maps” which disappeared some years ago.
But to be useful, that feature needs to have been already in OH.
Are you volunteering time travel to go back and add it for us? 
Yes for now.
But who can guarantee that OH4 will not break compatibility to OH2 Bindings?
Those people should not really vote here as it does not make a difference for them whether the compatibility layer of OH2 is kept or not. They can continue using those bindings with a 1.x runtime forever 
.
I did not see the Mail Action in the list. Is it possible that such a commonly used Action never was promoted to the compatibility list?
The OH2 Mail binding has a mail action, so the OH1 mail action was marked as legacy. None of the legacy addons were included in the poll.
I still use the old exec1 binding since it is so much easier to handle per-item parameters than the exec binding from OH2.
I wasn’t aware there was a Mail 2.x binding. It appears to be new since the release of 2.4. Cool!
As with MQTT 1 (and the Mail action apparently), exec1 is a legacy binding (i.e. there is an Exec 2 replacement).
For me the statement does not match what you are polling.
I respectfully suggest you post a separate poll that sees which of the 1.x plugins that have a 2.x version are still being used, as those users will be impacted by the current proposal too.
I currently have no plans to move off MQTTv1 as it works and does not cause me any grief. if OH3 is to remove the compatibility layer then I will have to consider long and hard if I want to go to OH3 and if not what is my roadmap for central home automation.
I am finding with all the different controllers around and the number of bindings that are not being maintained that I am already looking over the landscape to see if I want to stay with what I currently have or move on. This could be the shove I need.