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:
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):
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:
No wonder this is confusing 
But… but… Hmm… I dont get it 
Why should a newer version of the same binding not support the same functions? (makes no sense, unless its functions no longer in use). I would have thought a new enhanced development would add new/better support of functions and stability, rather than to remove and beeing less stable.
If a newer version fails I believe this calls for a fix, and just a question of time? Same regarding the robust. If 1.x is more robust than 2.x there are work to do for the 2.x.
It seems like keeping 1.x can become a abstraction for developing a better 2.x. Which in the long term lack the development of the whole core. I doubt thats very usefull to anyone.
You better not remove anything for the next 3.0 IHC binding 
Probably because it’s not the same binding… I suspect that quite often OH2 bindings are rewritten - they aren’t the same binding from OH1 since there is a lot of difference in the way bindings work. The may mean that not all features are implemented in the new binding (it does make sense ) - nothing is being removed - it’s just not implemented.
Certainly this was the case for the ZWave binding - it had to be largely rewritten for OH2.
I believe this is a question of words, and believe in the binding is the same despite of different versions.
I wonder how many people actually feels the same, if it was a function of an OS like Windows, and Microsoft said - “The function used to be, is not removed - It´s just not implemented”.
I have a slight feeling, this is not going to be a popular answer
No - it’s NOT just a difference in words. At least for the ZWave binding, the binding for OH2 started from scratch. It was completely rewritten. This means that if there are features missing in OH2 that were in OH1, they were not removed - they just were not written in the new code.
I think your example of Windows is irrelevant - it probably has evolved over time and was not written from scratch as I’m trying to explain to you here! It is a very different situation.
I’m not saying that this is the case for all bindings, but it’s quite likely, and is certainly the case for ZWave.
I wouldn’t say that. Maybe my tendency to not be assertive is getting in the way. The stated purpose of the poll is to prioritize the work in creating 2.x versions of 1.x bindings that do not yet have them.
From the OP:
The intent of this poll is to get information into the hands of developers to help in making a decision on which migrations would be most beneficial to the community.
I think that is pretty clear. It is to tell those developers who are ready and willing to migrate some 1.x bindings to 2.x prioritize their efforts.
It’s not listed because it’s already migrated. There is an MQTT 2.x binding. Therefore it’s out of scope for this poll.
The poll is driving the creation of 2.x versions of bindings that do not already have a 2.x version. MQTT1 and Exec1 are out of scope because there already is a 2.x version for those bindings. The goal is to prioritize the efforts to create new 2.x versions of bindings that only exist in a 1.x version.
The impact to users who wish to continue to use 1.x version bindings despite the existence of 2.x replacements is out of scope for this poll.
The best way to guide the developers on this is to file issues on the 2.x version bindings to have the binding implement any feature you find that exists in the 2.x version of the binding but not in the 2.x version of the binding. Sadly, “the 2.x version of the binding is too complicated” isn’t going to likely be acted upon. There are differences in how 2.x version bindings work and how they are used that makes some things you can easily do in a 1.x binding (e.g. the MQTT event bus) that are not allowed or impossible in the 2.x version binding. Also, the 2.x version often has more capability than the 1.x version binding which is going to add some complexity. For example, you have more flexibility in triggering the Exec binding, you can get the return code, and see when a script is running, none of which was possible with the Exec1 binding.
I think they are all in the Misc tab.
That was one I asked about. Indeed, there is now a Mail 2.5 binding. Instead of Actions being a separate add-on, Actions are not included in the binding so the replacement for the Mail 1.x Action is in the Mail 2.x Binding. I’ve moved over to this new Binding (as a result of learning about it in this thread) and it works perfectly.
The poll is about the use of 1.x add-ons *that do not already have a 2.x version replacement."
Many people use OH 2.x with a 1.x add-on. If you use the Expire binding or HTTP binding you too use openHAB 2.x with a 1.x binding. This is the subject of this poll. It’s to identify those OH 1.x bindings that do not have a 2.x replacement that are still used by the most users so the developers can prioritize their efforts.
Many people continue to use legacy 1.x bindings even when there is a 2.x replacement for a lot of reasons:
It’s listed in PaperUI and it’s a 1.x version binding that does not yet have a 2.x version so it is relevant for this poll. Frankly, if it’s listed in the poll, it’s relevant. The creators of the poll did some work to come up with the list above.
If the compatibility layer goes away in OH 3, the Velux 1.x binding will stop working regardless of how you install it.
At this point, since PaperUI is being replaced in total, I don’t know if a request issue is worth while. You can monitor the development of the replacement in the openhab-uis repo and file an issue if the way the new UI is built doesn’t include this information.
No, the purpose is to prioritize the effort of those developer who are willing to build 2.x replacements for 1.x bindings that do not have a 2.x replacement yet. How you install the 1.x binding is irrelevant. Even if you manually install it by putting the jar file in addons, it will stop working when/if the 1/x compatibility layer goes away.
Your use of the Velux binding 1.x is relevant. Unless you don’t care that it will stop working in OH 3.
It is relevant because this isn’t about whether it is listed in PaperUI for install or not. This has to do with whether or not the binding will even work in OH 3 if the 1.x compatibility layer goes away. Each and every binding you see that has a 1.x version will no longer work regardless of how it is installed.
Because it takes a complete rewrite of the binding to go from OH 1.x to OH 2.x. And the “modeling” for 2.x bindings is completely different. Though it’s worth mentioning that often that new more complicated modeling is the result of adding significantly more capabilities (e.g. Exec2 compared to Exec1).
Going from 1.x to 2.x isn’t just a few minor tweaks. It is often a “back to the drawing board” activity.
And yet Microsoft does just this all the time when they go from one major version to the next (e.g. from Windows 7 to Windows Vista). But Microsoft has 130k employees (I don’t know what percentage of those work on Windows). It is unrealistic to expect the same level of backwards compatibility for an effort that has 20 or so developers (total WAG, I have no idea how many active developers there are on OH).
Maybe this is due to me not beeing an developer. But I honestly dont understand it. Ofcouse if there were reasons in the code itself, for functions not beeing possible, then I would understand. Or like I said, functions no longer beeing used. I also understand, if it´s functions which havn´t been implemented yet. I suspect thats just a matter of time then?
Can you explain which functions is no more in the zwave binding, and why? Perhaps it would be make it more easy for me to understand it.
I meant for the purpose of the poll.
I care for anything regarding openhab and it´s development, wether its usefull for myself or not.
I wouldn´t know, cause I´m not a developer. I´m a user.
In general, if I use a software, and a new version doesn´t support the same functions which I use, I would find myself beeing forced to stay with the older version, which means, from my point of view, there would be no reason to continue to develope the software.
And they get blamed hard every time as well. (They even get blamed for functions not missing, but just changed… People dont like changes I guess ).
Mentioning Microsoft was just an example. In general it will be a drawback, if a software loose functionality in a newer version (if its functions beeing used though)… At least thats my opinion. New users may find it usefull, but for old users, the development would be waste of time.
Again, it´s very important to notice, I speak of functionality which is beeing used, which I believe is the main purpose with the poll. If no one use a specific 1.x binding, and no one has any request for it, I see no reason to even try to continue the development for this specific binding. Like you said, it would be better to spend time on those bindings which is requested and in use.
How about this. If you have a 5 bedroom house, and you knock it down and build a new house with 4 bedrooms and an indoor pool, you no longer have 5 bedrooms - even though the first house did. It’s the same - if I start writing software from scratch, I need to add every feature - from scratch.
I honestly don’t think this should be too hard to understand 
I didn’t say that functions were not possible. I said if I start from scratch and write something, it may simply not contain all the same features.
No - I never said that there were functions that are no longer in the ZWave binding! I said that the ZWave binding was rewritten for OH2 and therefore it is possible that not everything that was in the OH1 binding is in the OH2 binding, or that things are implemented differently.
This in a nutshell Kim is the purpose of this poll
And so do I.
My point is the poll is to find out which bindings will stop working when the 1.x compatibility layer goes away that the most users are actually using. Whether you install it manually or through PaperUI is irrelevant. OH 1.x bindings will no longer work no matter how they are installed when the 1.x Compatibility layer goes away.
Which is your right as a user. And we still have people running OH 1.6 to OH 1.8 from time to time popping up on the forum. That comes at a cost to you as a user but you don’t have to upgrade, ever. Costs include:
This is the disconnect. We are not talking about continuing the development of 1.x bindings. We are talking about re-implementing 1.x bindings into 2.x bindings. As a non-developer you may not care or understand the distinction, but understanding that distinction is key to understand much of the discussion here.
Given the number of developers, amount of code, and drastic difference between OH 1.x and 2.x, it is frankly unreasonable to expect 2.x bindings to be exact clones of the legacy 1.x bindings in every case and in every way. Consequently there will be features which perhaps no longer make sense and there may be additional complications added which enable new features which were likely impossible in the OH 1.x binding. Or there may be some obscure feature that got missed in the rewriting of the binding. Hopefully, if it was an important or useful feature, someone will have filed an issue to have that feature readded, if adding it is possible. As I said above, there are some features that are simply not possible or not allowed in 2.x bindings that were allowed in 1.x bindings.
But thats the choice you make as the constructor (developer).
I doubt you´ll do the same, if there was a need of the 5 rooms, and no pool, right?
I think you miss my point. I´m speaking of functions, not how something is developed.
Okay, my mistake then. I thought thats what you said.
Ofcouse, if the binding no longer function after a certain time of periode, I would care. But as I said, I believe most manually installed bindings are under “work in progress”, which means, it´s just a matter of time before they´re added to the system itself. Ofcouse if there is no more development going on for this binding, it will never reach to the system itself… But then, why care… No one can do anything about it, if no one continue the development.
Ofcouse… Like I said - People dont like changes, (or some people I might say).
It´s their freedom of choice. They´re probably not complaning either, (and if they do, they´re wrong, except if it´s due to missing functions. Then its a matter of needs).
Re-building (or re-implementing if you like) is a sort of developing. Specially if you´re re-implementing to a newer core/OS/stage/whatever because it´s required. Which is exacly what I meant is important, if the addons (binding) in questions is still beeing used.
And as I said, I believe this IS the purpose of the poll to tell which 1.0x bindings is still beeing used and therefore needs to be re-implemented/re-build/developed futher. But if you re-implement and remove functions of a 1.0x binding, because the polls shows its beeing used, it makes no sense to me. The the poll would have to focus on function level insted. (which functions in a 1.0x binding is beeing used). I guess this require a new and a pretty huge poll then.
From the functionallity aspects, the re-implemented binding has to support the the needed and used functions. Otherweise there is no reason for re-implementing it to a newer core/system, except for new users, who may not need the old and missing functionality.
Those who use the “old” binding because they need it functionallity, they will not upgrade the core.
Those who needs the re-implemented binding due to upgrading the core, but need the “old” functionality, would be facing a dilemma. They simply cant use the binding. They will be forced to use the old core system insted. Or go without their needs.
So where does it leave the binding. Or even worse, where does it leave the core system and the users?
Lets try another example, a more “inside” one.
If Pauli stops development of the IHC binding, and re-implementing is required to be used in openhab 3 (and future version), it will put me into a huge dilemma, cause I need the IHC binding, (and I will probably hunt him down for the rest of his life ).
I got two options. Either hope someone else continues from Pauli work or someone making a new binding (with the same functions ofcouse). Otherweise I´ll be left behind with openhab2, which means I can not support openhab3 and any future versions. Maybe I´ll even have to abandon openhab because of this.
There is a rather specific reason why backward compatibilty is important. You can start all over from scratch leaving out functionality. But you´ll have to face the fact, that it may result in users leaving or not following the development of the core system, if they are in a need of the functionality. A user not following development means a loss for the core system itself, in my opinion. Many windows 7 users havn´t upgraded to windows 10, because the applications they use and need, havn´t been updated to work in Windows 10. This is a loss for Microsoft/Windows 10, and noone else, in my opinion.
I dont think I can explain this any better.
Yes, if we sat down with a full list of requirements from the original development and engineered a solution that implemented all such functions on the new development, they would be compatible. We do not have such a list, and therefore there are no guarantees that the same features will be available in the new development - that’s the point.
I don’t disagree that backward compatibility is important, but it requires considerable work to engineer the requirements as mentioned above. This is a community project - there are no such requirements. Different people add features, so unfortunately there is just no guarantee.
Clearly you do not wish to try and understand this so I give up.