I’m also using Splatch’s Bacnet binding which is V1. A V2 Bacnet binding with discovery would be brilliant.
I do not see the persistance binding in the list. Is there a stream to convert them to 2.0?
Check the first post.
And what stops either of you of creating such a poll? Usually the excuse is ‘I’m not a programmer’ but for this no coding is required. I’ve already compiled the list for you.
1 Like
simple as we are not in a position to influence the outcome, by a simple poll, a developer with people like Kai and other sustaining members can force through what ever the current set of developers want. and the rest of the members really have little choice but to leave and go elsewhere if there are not onboard with the direction.
If you really want a fair view of what is used and to what degree it is immaterial if there is a v2 of the plugin. If the new plugin has not gained support over the older version then there is still work to do.
Not sure what the plan is exactly or how the reall vote should be handled, but if it is what plugins to drop, enhance or develop then you need all of the v1 plugins in the mix to give the full picture.
I have looked at where I would go and so far I would stay on 2.x until I could come up with an alternative for the AmazonEchoControl plugin as that is THE most important one for me I can get pretty much all the other stuff from any other controller system.
I am not trying to be offensive its just a ten minute think and check around, it was a surprise to me too when I looked at what was important.
@Kai, can you advise if normal members are able to help with the direction how we go about doing this?
Regards
Paul
But that’s already a 2.x version binding and there is no legacy version of that binding. So that binding is under discussion because it will already be supported.
So far the only legacy binding you’ve listed is MQTT but you’ve not sighted any specific capability gaps, just that might be capability gaps. To the contrary as far as I’m aware, everything that the MQTT 1 binding could do the MQTT 2 binding supports as well, though per usual, how it supports it might be pretty different. For examples:
- REGEX Filter: MQTT 2.5 M1+ How to implement the equivalent to MQTT1 REGEX filters
- Event Bus: Marketplace MQTT Event Bus
- Generic MQTT Things cover the rest.
All of the major bugs and problems with the MQTT binding have to do with Homie and HA automatic discovery which are features the MQTT 1 binding does not and could not support.
So, unless there actually is some capability in MQTT 1.x that is not supported by MQTT 2.5 then what the argument really boils down to is “I want the maintainers to do and continue to do work in supporting 1.x version bindings so I don’t have to do any work to upgrade.” That isn’t a very compelling argument.
If you do know of a capability that is missing from MQTT 2.5, then please file an issue.
The above poll was created by one of the active developers on OH and there have been replies from several other active developers on the openHAB project. From what I can tell, they are using this poll to prioritize their efforts to make sure that the minimal number of users are impacted with a loss of capability when/if the 1.x compatibility layer is dropped. It is not a goal to ensure that there is no work that needs to be done by users to upgrade their 1.x bindings to 2.x versions. The architecture and how 2.x works is fundamentally different. Of course there is going to be some work.
The best way is to file issues.
1 Like
That is true if a person is not able/capable to actively contribute to the code, otherwise the best way is to make PRs.
Don’t you think it will be much easier to convince any developer into a certain direction when you have the facts and figures to backup you claims? Figure out why people prefer to use a 1.x binding when a 2.x binding is available. What essential features are missing in the 2.x binding. Are there already issues open for these missing features and if not create new issues for them. All these kind of things can all be figured out by anyone.
Why would I invest my free time to develop something for you for which I don’t have a need when you obviously are not willing to invest any of your free time? The time you spent writing your reply would have been much better spent if you had used it to create your poll.
1 Like
I may have misunderstood something with this poll.
I answered for using org.orpnhab.io.multimedia.googletts but the one I´m using is not really a 1.0x addon… In paperUI is says 2.5M1.
The same goes for the org.openhab.binding.hue. But this also says 2.5M1 in PaperUI.
Now I wonder… how to tell if a binding is OH1.0x?
1 Like
The versions of addons included in the distribution are displayed in Paper UI> Add-ons. Addons that have been installed manually (copying into the /addons/ directory) are not shown here, which would be the case for all addons not in the distribution. For these, you should be able to tell from the name of the jar file, but you can also run list -s in the console to get the version.
Don’t worry about the poll… I’ll clean yours up in the tally. I’m sure there are plenty of others that made the same mistake, but this is just to get a rough idea of what’s in use.
There are a number of ways. Perhaps the easiest is to look in PaperUI. If it says 2.something it’s a 2.x version binding:
If it says 1.something, it’s a legacy binding.
If looking in the docs, the 1.x bindings will end with a 1 in the URL.
https://www.openhab.org/addons/bindings/mqtt1/, ends in a 1 so it’s a 1.x version binding.
https://www.openhab.org/addons/bindings/network/, no 1 so it’s a 2.x version binding.
Hopefully any non-official bindings that you may use will be clear in their docs what version they are using. If you downloaded a jar file from where-ever the nightlies get built these days it will have the version number in the jar file name.
afaik bindings with a 1 at the end of the name are legacy bindings, e.g.
squeezebox1 1.14.0 <- legacy binding, only listed if legacy bindings included
squeezebox 2.5.0 <- v2 Binding
http 1.14.0 <- v1 Binding, but not legacy, as there is no http2 binding yet.
There are also non-legacy 1.x versions of the addons visible in Paper UI. These and the 1.x addons that are not included in the distro and don’t have 2.x versions are the addons relevant to the poll. Another way to look at it…
Flavors of 1.x addons:
- Included in the distribution (visible in Paper UI)
- Have a 2.x version (Legacy)
- Don’t have a 2.x version (Non-legacy and relevant to the poll)
- Not included in the distribution (not visible in Paper UI and need to be manually installed)
- Have a 2.x version (not legacy until the 1.x version is included in distro, which would likely never happen)
- Don’t have a 2.x version (relevant to the poll… but nobody has made the effort to get them into the distro)
So the actual purpose is not clear to you either?
I guess I jumped to a conclusion without any evidence. Can we have some clarity on what this poll is about and how it will be used?
I have voted for a few 1.x bindings the only one that I cam across that I still continue to use 1.x that was not listed was MQTT hence my question that led me to think about what is the purpose of this poll.
I guess I still have bad memories from Christmas with MQTT so not excited to go there.
I am well aware that the AmazonEchoControl binding is a 2.x addon, my point was it is the only thing that ties me to Openhab, this is a great addon and currently its features are quite unique. Its only down side is the number of error that plague it, many are not the plugins fault but amazon changing things at their end. I will close this part of the thread as I have ventured off topic I feel.
Regards
Paul
I am not attacking but certainly feel your attack.
I would like to understand the purpose of the poll, I queried the rationale to not include all 1.x bindings as all users of 1.x binding would impacted if the compatibility was removed, although it is not clear what the poll will drive.
I have completed the poll and would like to understand more about the purpose, if I crewated a poll would it have any weight is the next question I asked. If I am going to create one and then even if it got responses they would not be considered then yes I would truly be wasting my free time. Hence my question about if standard members can also guide.
I am not trying cause friction but it seems I must have put the villain outfit on this week.
If it was a tone issue in my previous post then please accept my apologies.
Regards
Paul
I just went through the list again and saw that there are some listed as io e.g. org.openhab.io.harmonyhub where do I fing the io category in paper ui I know I have seen it previously but cannot locate it currently.
I also noticed that actions we’re included, when I look through paper ui mail is a 1.x action but I could not see it here, did I miss it, or does it have a 2.x equivalent I should be using?
Regards
Paul
This poll has its origin in a suggestion from Bob in the Removal of the OH 1.x Compatibility Layer topic where it became a little off-topic so Rich split it into its own topic: OH 1.x add-on assessment.
Thats what I figured.
The confusing part is, the poll is about the use of 1.0x addons, and then it list addons without version. I just discovered the same addon can be either 1.0x or 2.x. (like the org.openhab.io.multimedia.googletts). Maybe this is just odd to me, but I wonder who would use openhab 2.xx with an 1.0x addon, if there is a 2.xx version of the same addon. I would assume there should be very specific reasons for making this choice, or? Without these reasons, I see no reason for openhab2.xx to even support these addons anymore.
I do use one manually installed 1.0x addon, (Velux binding by @gs4711). This is simply because there isn´t a 2.xx version yet… I believe Gunther is working on that part. But since it´s manually installed, I guess it´s rather irelevant for this poll, right?
Btw… A small sidenote regarding binding/addons versions.
Wouldnt it be a good idea, if PaperUI->Configuration->Bindings listed the installed (and active) version and not just the author?
I know… “File an request…” is the answer 
But this just popped into my mind as I wrote the above.
I suspect this poll is wether to continue or develope the 1.0x addons, which hasn´t been updated to 2.x in some way. I dont think manually installed bindings should be part of poll then. As I mention above, I use the Velux binding 1.x. But this one of those bindings which has a specific reason for use.
Thanks 
I just figured that… I scanned through the list in the poll, and when I reach a binding I knew I was using, I pressed the button, because I thought there would be 1.0x only.
Regard the topic (or maybe the original topic about continuning 1.0x bindings support). I dont think manual installed addons should be part of this poll… The author of the binding should work on getting in public released insted. Often (I may be wrong on this) manual installed bindings are under development and waiting to get added into the public release. At least this is how I use manual installed bindings.
Just to clarify:
There are at least six different categories of Bindings (but let’s call them addons):
- official OH2 addon. Is listed in Paper UI with a Version > 2
- official OH1 addon, which is compatible due to the compatibility layer (and there is no OH2 addon yet). Is listed in Paper UI with a Version < 2
- official OH1 addon, which is not listed as compatible. These addons have to be installed manually and aren’t listed in Paper UI at all.
- official OH1 addon, which is compatible due to the compatibility layer (and there is also an OH2 addon). Is only listed in Paper UI with legacy Bindings ON, with a Version < 2, the Name of the addon ends with “1”
- unofficial OH addons which are installed manually. These won’t apear in Paper UI at all.
- unofficial OH addons which come from market place. As Marketpalce is OH2 only, there can’t be an OH1 addon in the market place.
In OH1, there were different types of addons: ui, io, transport, binding, persistence, action. you will have to install more than one file for some of the bindings, as the communication is split from functionality. e.g. for mqtt there is a transport and a binding and an action. if you don’t need the action, just install transport and binding. if you only need the action, don’t install the buinding but transport and action.
Couple of reasons why someone might still use 1.x add-on even 2.x is available:
- 2.x doesn’t support all functionality which 1.x supports
- 2.x thing modelling have failed, meaning 1.x binding is much more easier to use
- 1.x is more robust that 2.x