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?
1 Like
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.
2 Likes
I’m using the old Onkyo binding with a serial receiver. I would move to the new version if serial support was added.
You know Paul, that is actually a really good point and germane to this discussion. It is not just users who use v1 binding for which there is no v2 versions who will be affected by compat layer going away.
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)