Top 10 of bindings having the most of open issues

[lolodomo]

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]

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

• @FStolte @gerrieg @mdicke2s for homematic
• @kaikreuzer for knx
• @marcelrv for miio
• @markus7017 for shelly
• @andylintner @yfre @ccutrer for homekit

[lolodomo]

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

• jsscripting
• amazonechocontrol
• astro
• avmfritz
• bluetooth
• chromecast
• daikin
• deconz
• enocean
• gardena
• goecharger
• hue
• influxdb
• keba
• loxone
• miio
• modbus
• netatmo
• openwebnet
• paradoxalarm
• rrd4j
• smartmeter
• somfytahoma
• tr064

[markus7017]

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

[yfre]

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]

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]

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]

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]

Regarding JS Scripting: I am working on #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]

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]

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]

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

[hmerk]

@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]

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]

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]

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]

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]

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]

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]

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]

@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]

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]

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 openhab/openhab-core#2276.

[Skinah]

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]

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?

[lsiepel]

@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 #14124

[andrewfg]

@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]

@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]

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]

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]

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]

TOP 40:

[DELETE THE LIST AS IT WAS FAULTY]

[marcelrv]

@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]

@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]

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]

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]

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]

^
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]

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

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]

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

[J-N-K]

@lolodomo Can you update the list?

[lsiepel]

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]

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

[lolodomo]

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]

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

[J-N-K]

@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]

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

[lsiepel]

List as of 25-11-2024:
Shelly really needs some work i guess.
shelly 30
homematic 14
mqtt 11
telegram 11
homekit 11
amazonechocontrol 10
tradfri 8
avmfritz 8
rrd4j 7
jsscripting 7
modbus 7
enocean 7
dsmr 6
somfytahoma 6
hue 6
tesla 6
kostalinverter 6
miio 6
hueemulation 5
jdbc 5
luxtronikheatpump 5
network 5
http 5
sonos 5
mihome 4
loxone 4
knx 4
icalendar 4
freeathome 4
deconz 4
yeelight 4

[andrewfg]

Apropos Hue binding .. just so you know .. none of the mentioned issues are actually actionable (just read them yourself please) and I am therefore definitely not planning to take any actions.

[hmerk]

Same applies to many of the Shelly issues. Nearly half of them are enhancements request and a couple of bugs are awaiting feedback.