search

openhab / openhab-addons

Add-ons for openHAB
https://www.openhab.org/
Eclipse Public License 2.0
1.9k stars 3.59k forks source link

Top 10 of bindings having the most of open issues #13706

Open lolodomo opened 2 years ago

lolodomo commented 2 years ago

Here is the top of binding having at least 8 open issues / requests for change (2023 July 23):

  1. mqtt (43)
  2. homematic (18)
  3. homekit (13)
  4. telegram (11)
  5. http / jdbc / tesla (10)
  6. knx / shelly (9)
  7. mihome / tradfri (8)

These 11 bindings are the source of 26% of the currently open issues.

Maintainers of these bindings or new volunteers are encouraged to check these issues, propose fixes and close some of them if they are no more valid.

lolodomo commented 2 years ago

Maybe maintainers of the bindings could look at the issues to see if they are all still relevant ?

lolodomo commented 2 years ago

Other bindings which are below the top 10 but with a certain number of issues:

markus7017 commented 2 years ago

re Shelly: I closed some issues from previous PRs some more will be closed by the pending PR

yfre commented 2 years ago

regarding homekit - I could close some old and obsolete tickets, waiting for feedback for one more. remaining 6 are valid feature requests and bugs.

mvalla commented 2 years ago

what about feature requests that are valid but not implemented yet? I do not think is useful to close them, as they may get addressed in the future

lolodomo commented 2 years ago

what about feature requests that are valid but not implemented yet? I do not think is useful to close them, as they may get addressed in the future

Yes but at the same time, if a feature request is there since several years and generate no developer interest, we could consider it is time to close it? Maybe after two years for example?

mvalla commented 2 years ago

honestly I see this as just a loss of information. What is the practical drawback of keeping these feature request issues? In case it's decided to close them, is there any way to tag them to be able to recover them quickly? (e.g. tag "closed-stale" or something better)

florian-h05 commented 2 years ago

Regarding JS Scripting: I am working on https://github.com/openhab/openhab-addons/issues/12577, I’ll also have a look at the other open issues. FYI: I’ve already reduced the number of open issues to 6.

lolodomo commented 2 years ago

honestly I see this as just a loss of information. What is the practical drawback of keeping these feature request issues? In case it's decided to close them, is there any way to tag them to be able to recover them quickly? (e.g. tag "closed-stale" or something better)

Ok, I think we can keep them. Anyway, I am not deciding.

lolodomo commented 2 years ago

Thank you for your efforts, I will update the top during the weekend. homekit and jsscripting will leave this top and miio is also about to leave it.

lolodomo commented 2 years ago

Maybe @ZzetT could have a look for the telegram binding, @kaikreuzer for the chromecast binding, @lujop for the influxdb binding

hmerk commented 2 years ago

@lolodomo Great to see your effort here. Please keep in mind that some of the listed bindings have moved to smarthome/j so might not get updates here anymore. We really need to find a solution for that. Either somebody can take the effort and import the changes back, like i did for the mail binding, or we should remove them here to not have 2 different versions with different codebase.

Perhaps this would be worth an AC discussion. The one I started is stale.

lolodomo commented 2 years ago

Please keep in mind that some of the listed bindings have moved to smarthome/j so might not get updates here anymore.

Why such anarchy / nightmare for the final user was introduced ? :( The marketplace was created to develop non official bindings or beta versions of existing bindings, not to make some alternatives to the official bindings, I think this is clear in the rules of the marketplace.

We really need to find a solution for that. Either somebody can take the effort and import the changes back, like i did for the mail binding, or we should remove them here to not have 2 different versions with different codebase.

A solution has to be found, that is clear !

What are the bindings concerned ?

Perhaps this would be worth an AC discussion.

Probably. This is limited to only few members ? I am not sure I have an access...

What disappointment for me to read that ! @kaikreuzer for information

J-N-K commented 2 years ago

Please keep in mind that some of the listed bindings have moved to smarthome/j so might not get updates here anymore.

Why such anarchy / nightmare for the final user was introduced ? :( The marketplace was created to develop non official bindings or beta versions of existing bindings, not to make some alternatives to the official bindings, I think this is clear in the rules of the marketplace.

This is not true. The rules have ben adjusted to this version AFTER the marketplace was introduced. Anyway, even without the marketplace (or any other add-on service): you can't force people to develop within the openHAB organization. There always have been add-ons not included in the distribution and there always have been modified versions of add-ons.

florian-h05 commented 2 years ago

you can't force people to develop within the openHAB organization. There always have been add-ons not included in the distribution and there always have been modified versions of add-ons.

I am wondering why one doesn't want to develop within the openHAB organization.

If there is a reason/problem, we maybe can discuss and solve it, because having forks of official add-ons is type of confusing for the end users.

ZzetT commented 2 years ago

Hi @lolodomo thanks for letting me know that there are several open issues for the telegram binding. I have to admit that I don't use openhab as my smarthome system any longer (for quite some time already). Thats why I lost a bit of interest to look at these issues. Not sure if you can find any other lead developer for that. Otherwise I have to try to setup a new development environment first to try to work on that issues. The binding itself uses the java-telegram-bot-api internally and only acts as a bridge between the openhab system and that Java library. So any feature that is supported by that library already, shouldn't be too difficult to add to the binding. Sorry for that....

lolodomo commented 2 years ago

I am wondering why one doesn't want to develop within the openHAB organization.

I am sure the following discussion will irritate me and disappoint me. Can we please avoid to discuss about that in THAT topic. The object of that topic is just to have a picture of bindings with lots of issues/requests for enhancement and to motivate maintainers to check them.

ccutrer commented 2 years ago

I am wondering why one doesn't want to develop within the openHAB organization.

Can we please avoid to discuss about that in [THIS] topic.

The object of [this] topic is just to have a picture of bindings with lots of issues/requests for enhancement and to motivate maintainers to check them.

While I'm normally as annoyed by not focusing on the topic at hand, I think it could be relevant. Though I do want to focus my comments on resolving issues, and hopefully without offending any involved party, since that's not my intent. Anyhow, I think that having this discussion is on topic, since resolving it will allow cleaning up large chunks of issues, which is the core ask for THIS original topic.

I don't know the full history here, since I haven't been involved with openHAB for as long as others. But I have worked with and committed to all three repositories (openhab-core, openhab-addons, and smarthomej/addons) within the last few months. I'd agree with @lolodomo that it can be confusing and frustrating to an end user when an official plugin has issues, and then you find out there's a different version that's more well maintained. On the flip side, I also agree with @J-N-K that it's impossible to prevent someone from maintaining an alternate version of a binding outside of this repository -- being able to easily fork, improve, and share your improvements in whatever manner is what makes open source great.

So how do you reconcile those two things? It seems there are a few choices:

  1. The status quo. You don't. The official addons bitrot, and continue to ignore that smarthomej versions exist.
  2. The official addons continue to bitrot, but at least add a note in their READMEs that acknowledge the existence of and links to smarthomej. Not a great experience, but at least makes it more possible for an end user to discover smarthomej, instead of getting frustrated at brokenness and apparent non-maintenance of an addon that might be critical to them, and losing them from the openHAB platform altogether.
  3. Smarthomej (or at least those addons that duplicate official addons, but maybe all of them) merges back into the official repo. Sounds like there's history here that may make this difficult.
  4. openhab-addons admits that their version of these bindings have been abandoned, and that better versions are available in the community. Just remove them completely, possibly at least leaving their readmes in place on the openHAB docs website pointing to smarthomej.

Putting myself in the shoes of an end user unfamiliar with the situation, option 3 would obviously be best. Option 4 also wouldn't be so bad - and would add even more weight to OpenHAB officially endorsing "there are community addons that we don't officially maintain or endorse individually, but do endorse other community member's freedom to maintain and distribute addons that may not be fit to be in the main distribution." Option 1 definitely seems like the worst of the 4.

So... please! Can we at least move away from option 1?!

florian-h05 commented 2 years ago

I agree that the status quo is not great. The confusion we put on the end users by having multiple forks of some addons, and, as ccutrer stated out, the risk that users are

getting frustrated at brokenness and apparent non-maintenance of an addon that might be critical to them, and losing them from the openHAB platform altogether.

shouldn‘t be accepted here. I am aware that there is some history that lead to forked addons, and I personally welcome that there are addons developed somewhere else, as this is open source, but I‘d be happy if come to a decision here (or in another thread).

Coming to the choices that ccutrer listed:

  1. Please not this way
  2. If don‘t come to a better solution, we should at least choose this way. FYI: HomeAssistant also mentions community forks of their integrations in their docs (see https://www.home-assistant.io/integrations/influxdb/).
  3. The best option, as the addons then directly come with the openHAB distribution. But for some addons, the problem is the relatively long release cycle of openHAB. Those addons provide support for APIs with many breaking changes in short time periods. Anyway, for the addons that don‘t use such APIs, we‘d need some changes to the rules to make this happen.
  4. Also an option, as it gives the user well-maintained add-ons and, as ccutrer stated, adds more weight to the community aspect of openHAB. If the community addons aren‘t maintained anymore at some point future, openHAB could still backport them into the official distribution to maintain them there, or don‘t maintain them, as this issue shows :-(
lolodomo commented 2 years ago

@wborn @kaikreuzer : do you know how to move all the messages about openHAB vs smarthomej elsewhere (separate issue?) to continue that interesting discussion not in this issue ? I would like to keep the positive feeling in this issue with all the maintainers that made the great effort to look at open issues.

lujop commented 2 years ago

I'm sorry, I've been not able to dedicate time to the addon, and in the short term, I don't expect that to change. If some one can help with the issues will be heavily appreciated, if not I won't be able to attend to them at the moment.

wborn commented 2 years ago

do you know how to move all the messages about openHAB vs smarthomej elsewhere (separate issue?) to continue that interesting discussion not in this issue ?

I don't think there is any built-in functionality for that in GitHub. The closest thing would probably be to split it off manually by creating a separate issue and then copy/paste/quote all comments from this issue to that issue and delete them here. E.g. by imitating the bot in https://github.com/openhab/openhab-core/issues/2276.

Skinah commented 1 year ago

Thanks for taking the time to compile the list and also all that you do here @lolodomo I can probably take a look at some of the telegram issues over the Christmas break.

Wanted to raise that some of the people marked as the code owner / maintainer may no longer be part of this project (unless this has been looked at recently), I suspect this is the case with telegram and also mqtt which feature in your top 10 list. Perhaps getting new people that make decent PR in recent times as the new codeowner may help reduce the workload.

lsiepel commented 1 year ago

Thanks @lolodomo for this list. Just created a new issue to proceed that discussion about the bindings developed elsewhere. So hopefully we can get back to this topic. :-)

Do you have a simple tool to generate these statistics? Maybe worth spending a bit of time on the github api to automate a monthly report or per milestone release update of this top 10 list?

lolodomo commented 1 year ago

Do you have a simple tool to generate these statistics? Maybe worth spending a bit of time on the github api to automate a monthly report or per milestone release update of this top 10 list?

No, it is done and updated manually. The initial search was time consuming, the updates are less (mainly clicking on each existing link). I will update it today for the new year.

adisD commented 1 year ago

@lolodomo I do really appreciate your initiative with highlighting erroneous add-ons. However it looks like not much happened regarding closing those. What it normally takes to fix #13692 like in my case deconz add-on. I must stay with OH 3.2 as none of my zigbee sensors (all my sensors are zigbee) get registered. best regards

lolodomo commented 1 year ago

@lolodomo I do really appreciate your initiative with highlighting erroneous add-ons. However it looks like not much happened regarding closing those.

Maintainers already helped to reduce the number of issues/RFC for certain bindings, thank you to them. It of course evolves less for the bindings for which we don't have any more active maintainers/contributors.

lsiepel commented 1 year ago

@lolodomo I do really appreciate your initiative with highlighting erroneous add-ons. However it looks like not much happened regarding closing those. What it normally takes to fix #13692 like in my case deconz add-on. I must stay with OH 3.2 as none of my zigbee sensors (all my sensors are zigbee) get registered. best regards

Because there are 550+ issues and new ones appear while old ones get closed, it might not be very visible. But yeah many issues have been resolved, closed or validated. I'm still chasing the older issues and it seems many of htem have been fixed. You are right about deCONZ, that is a 'special' case, please check https://github.com/openhab/openhab-addons/issues/14124

andrewfg commented 1 year ago

@lolodomo your statement that Hue has 10 open issues is actually a bit unfair; a couple of the issues refer to the Hue Emulation binding, and one refers to the Deconz binding. But nevertheless many thanks for the issue tracking.

lolodomo commented 1 year ago

@lolodomo your statement that Hue has 10 open issues is actually a bit unfair; a couple of the issues refer to the Hue Emulation binding, and one refers to the Deconz binding. But nevertheless many thanks for the issue tracking.

No, I really counted only hue. We have now 11 for hue.

adisD commented 1 year ago

Please keep in mind that some of the listed bindings have moved to smarthome/j so might not get updates here anymore.

Why such anarchy / nightmare for the final user was introduced ? :( The marketplace was created to develop non official bindings or beta versions of existing bindings, not to make some alternatives to the official bindings, I think this is clear in the rules of the marketplace.

This is not true. The rules have ben adjusted to this version AFTER the marketplace was introduced. Anyway, even without the marketplace (or any other add-on service): you can't force people to develop within the openHAB organization. There always have been add-ons not included in the distribution and there always have been modified versions of add-ons.

I am not new to OpenHAB although not engaged as a code maintainer. I am missing to see how spread of add-on install bundles helps to end users. I had to downgrade to OH 3.2 since "standard" deconz addon suddenly got broken. Recently learned the hard way that there is smarthome/j where solution may be. It still remains for me to find whether smarthome/j is really providing deconz add-on compatible with OH 3.4. What is smarthome/j? Another home automation platform?

jlaur commented 1 year ago

Recently learned the hard way that there is smarthome/j where solution may be. It still remains for me to find whether smarthome/j is really providing deconz add-on compatible with OH 3.4. What is smarthome/j? Another home automation platform?

This topic has moved to #14129. See also #14124 which is specific to your case.

lsiepel commented 1 year ago

Created a very basic script that can help automate the list creation. It is based on the Github API. Just insert your personal API KEY and it logs the issue count per binding.

https://playcode.io/1245173

Let me know if you think it can be of any help and/or if we can improve it. I hope this can add some value to reducing the issue count / bugs / enhancements.

lsiepel commented 1 year ago

TOP 40:

[DELETE THE LIST AS IT WAS FAULTY]

marcelrv commented 1 year ago

@lsiepel nice job. seeing the count for miio binding, seems there is dome double counting or something. At least when I manually count for miio I come to 7 as opposed to the 11 in the list

clinique commented 1 year ago

@lsiepel nice job. seeing the count for miio binding, seems there is dome double counting or something. At least when I manually count for miio I come to 7 as opposed to the 11 in the list

Yes, the result of the script holds data from issues "mentioning" bindings apparently. I observed the same with Netatmo.

lsiepel commented 1 year ago

Ah, it also includes pull requests. I have updated the script to filter those out of the query. And altered it a bit so it generated markup that can be copy/paste here immediate with url to details.

List of all addons with 5 or more issues:

  1. mqtt 20
  2. shelly 19
  3. homematic 15
  4. openwebnet 15
  5. knx 13
  6. homekit 13
  7. telegram 10
  8. http 10
  9. mihome 8
  10. tradfri 7
  11. hue 7
  12. amazonechocontrol 7
  13. tesla 7
  14. somfytahoma 7
  15. netatmo 7
  16. influxdb 6
  17. smartmeter 6
  18. loxone 6
  19. hueemulation 6
  20. jdbc 6
  21. avmfritz 6
  22. gpio 6
  23. miio 5
  24. deconz 5
  25. rrd4j 5
  26. chromecast 5
andrewfg commented 1 year ago

it also includes pull requests

And it includes issues where there is a pull request already available to solve the issue, but nobody is willing to review the pull request, and thus solve the issue specifically, (and probably solve other issues too)

lsiepel commented 1 year ago

it also includes pull requests

And it includes issues where there is a pull request already available to solve the issue, but nobody is willing to review the pull request, and thus solve the issue specifically, (and probably solve other issues too)

Don’t think it is a matter of not willing to review. It’s rather a lack of time. But that’s somewhat off topic. The list consists of open issues and is meant to engage and solve issues. Let me know if there are issues or improvements needed to the supplied snippet.

andrewfg commented 1 year ago

^ My point is that it is a waste of time trying to engage binding developers, if reviewers are not engaged to receive their efforts. IMHO.

lolodomo commented 1 year ago

Here are all the commits since one year (https://github.com/openhab/openhab-addons/graphs/commit-activity) image 297 since the beginning of 2023.

37 Pull requests merged the last week. https://github.com/openhab/openhab-addons/pulse 106 Pull requests merged the last month. https://github.com/openhab/openhab-addons/pulse/monthly

Of course more reviewers would be welcome and appreciated. But do not discourage contributors.

markus7017 commented 1 year ago

I updated / fixed most of the open issues, they will be closed with the next PR merge.

J-N-K commented 1 year ago

@lolodomo Can you update the list?

lsiepel commented 1 year ago

State as of 21-05-2023: shelly 22 mqtt 21 homematic 18 homekit 13 openwebnet 11 telegram 10 http 10 knx 9 tesla 9 mihome 8 jdbc 8 hue 7 amazonechocontrol 7 tradfri 7 smartmeter 7 ipcamera 7 loxone 6 hueemulation 6 gpio 6 somfytahoma 6 avmfritz 5 miio 5 rrd4j 5 chromecast 5 netatmo 5 gardena 5 velbus 5 goecharger 5

Skinah commented 1 year ago

Any chance that the MQTT issues can be sorted further? Separate into mqtt.homie mqtt.espmilighthub mqtt.homeassistant etc....

lolodomo commented 1 year ago

Updated top:

  1. mqtt (43)
  2. homematic (18)
  3. homekit (13)
  4. telegram (11)
  5. http / jdbc / tesla (10)
  6. knx / shelly (9)
  7. mihome / tradfri (8)
Skinah commented 1 year ago

Guessing this was accidentally unpinned? Have done it myself when scrolling on a mobile's tiny screen.

J-N-K commented 9 months ago

@lolodomo The http binding has only 4 issues, the other issues are related to other bindings. Maybe you need to grep for [http] instead of http.

lsiepel commented 9 months ago

shelly 29 homekit 20 mqtt 19 homematic 17 telegram 12 tesla 9 jdbc 8 amazonechocontrol 8 tradfri 8 sonos 7 rrd4j 7 openwebnet 7 ecovacs 7 avmfritz 7 somfytahoma 6 velbus 6 netatmo 6 mihome 5 hueemulation 5 knx 5 gpio 5 kostalinverter 5 smaenergymeter 5 dsmr 5 unifi 5 modbus 5 miio 5 icalendar 5 jsscripting 5 boschshc 5

Used the shared playcode snippet from before to generate this