Confused by binding names

Am I the only one who is loosing the overview, which binding works for what (and oh, is it 2.0 or lower)?

For examples there seems to be three Fritzbox bindings, one actually listed under A (as in AVM), I always get confused which works for what…there are other examples of multiple versions of bindings with the same name (and I am referring to the sidebar in the documentation).
In general, the binding name makes less sense and unless i read the description, how would I have ever found out that SYNOP is a weather report…there is simply no classification for the ever growing list of bindings.
Now I am just worried that I will miss the arrival of the long awaited (by me :slight_smile:) TP-Link switches binding; i believe it is still under code review, but neither would I know when this happens, nor am I sure that I would know under which name it will appear…
Is there any way to add searchable tags to bindings (e.g., wheather, alarm, TTS, etc)? Happy to help classifying, but a coder I am not (sorry :blush:), so maybe it is not place to make these comments.
From my perspective, I am not sure I can keep up with scrolling the list of bindings trying to remember which one is new and what the name actually may mean in terms of functionality and which version of OH it is made for…

This is a problem I have experienced as well. It is best to use the toggles on the main binding page to hide or show the 1.x or 2.x version bindings and then go through the list on the right rather than use the list on the left. When using the list on the left I never know if I’m clicking on the 1.x or 2.x verison of the Exec binding, for example.

I had to look that one up too. And then I got my hopes way up and then had them dashed when I discovered my near by weather stations stopped issuing SYNOP reports.

But your point is well taken. A lot of these bindings assume some sort of prior knowledge to understand what they do and whether one should be interested in them.

When it makes it into a final release (2.2 perhaps) it will be listed among the changes in the new verison. If you want to know when it hits the SNAPSHOT you will probably have to watch the Issue and PR until it gets merged.

There is also a search function at the top of the page. If you search for TP-Link, if there is a page or binding readme that mentions that word it will show up in the results. That will tell you when that binding’s docs are released at the very least. Unfortunately, I’m not sure if we have a policy for when docs are added to the main docs versus the binding being made available.

@ThomDietrich, this is a good topic for discussion. I’m in agreement that the menu on the left side of the page listing all the bindings is almost useless. I wonder if makes sense to drop that massive list of bindings on the left-hand menu entirely and push users to the main bindings page instead. If not, adding a 1.x or 2.x to the name in the left-hand menu would help make it more usable, though I think the menu has grown too big to be useful at all at this point.

As for the categorizations, I’m of two minds. Creating a short list of categories could be helpful to allow users to discover bindings by browsing. If all the weather related bindings are listed together people may discover other ways to get weather information they might not be aware is available, like the Synop bindings.

On the other hand, what set of categorizations would we use? Weather is easy but what category would we put zwave and zigbee into? Would zway be in the same category? What about bindings like Mios and Homekit?

Then there is the problem of how this would be implemented. Right now the bindings docs are automatically compiled and created for the docs from the addon’s repository. Its an automated process and right now a very simple process. How would we tag the bindings into certain categories.

It’s a tough problem.

At this point I’m not sure you should try. Instead:

  • Make sure to read the release notes when a new version of OH is released. This will list all the new bindings added to that version.
  • Use the search function to search for bindings related to something you are interested in. For example, search for “weather” to find all the bindings related to weather. A think all the bindings that provide weather info have the word weather in their page somewhere.
  • Use the filter buttons on the main bindings page to turn on/off the listing of bindings for 1.x and 2.x depending on your interest. Ignore the list of bindings on the left hand side.
  • Subscribe to Issues and PRs for addons that you are interested in keeping up to date on on Github.

Hey guys,

first you should know that the problem with duplicate bindings in the menu is known. See https://github.com/openhab/openhab-docs/issues/401

There are already scripts in place to organize and structure all bindings, e.g see the main view here:
http://docs.openhab.org/addons/bindings.html

You will also find, that most of this metadata is transferred to the top of the markdown article. https://raw.githubusercontent.com/openhab/openhab-docs/gh-pages/_bindings/airquality/readme.md

What needs to be done now is we need to improve the way the menu is generated and on top of that I’d like to improve the template used when presenting ones bindings readme.

I do currently not have the time to look into this. @lipp_markus would you like to look into it? I would be able to give you all needed details…

@rlkoshak @ThomDietrich I much appreciate your feedback and your kind responses.
I know this is just one of the many things that developer think about it, and by no means did I intend to diss the great efforts made.
Just fyi I am using 2.2 snapshot and am always amazed how stable overall the snapshot versions are…

Would love to help, but you really don’t want to see my coding efforts (I am untrained in any and all programming language, some I can read, none I can write…). If there is anything that does not involve coding or at a level that I could pick it up (I have a reasonable abstract understanding of computer science, but no practical skills to speak off), let me know.
Thanks again

I don’t think Thom nor did I take your observations as a criticism.

You don’t need coding experience to work on the docs. There are lots open issues and you can make simple edits right in your web browser.

Just as Rich said.

The docs project is a rather basic web project, so if you are interested in learning HTML, JS and CSS, you could realistically contribute in that area. But you don’t have to. I’m swamped with work and do honestly not have the time to improve the documentation text as much as I want to. If you were willing to help in that area, that would be an amazing help!

If you feel like it, please check out these issues. If you find anything you like, let me know or comment on them directly: https://github.com/openhab/openhab-docs/issues?q=is%3Aopen+is%3Aissue+label%3A"help+wanted"

On top of that I found out that almost all Binding READMEs could use a review. Maybe you realize that one of the Bindings you are using is missing details in its REAME: http://docs.openhab.org/addons/bindings.html
As an example, I’ve recently improved the Amazon Dash Button Binding README: https://github.com/openhab/openhab2-addons/pull/2406/files

1 Like

Both, thanks so much for the encouragement. I will look into how I can contribute.