I’ve noticed quite a bit of confusion relating to openHAB and its different ways of installing it. Often, it’s the confusion between openHAB, openHABian, and the Linux installer packages for openHAB, but I also think it can be confusing which repository to go to report a bug.
I’ve been playing around with the idea of showing how the various things made within the openHAB repositories relate to each other. In red(pink?) we have our repositories, in orange we have external dependencies, and in blue(purple?) we have the files/binaries/artifacts produced by them.
I’d like to get a wider opinion of if this will be useful and where it would be most suitable for placement inside the documentation. I’d also like to hear if anyone has any other ideas to solve such confusions.
The map above was made in draw.io, you can edit yourself with the following XML:
I’m a fan of such drawings. Often enough they tell me
ok, i got it right!
ah, up to now i thought this to be different!
what is this?
I’ve been starting on Windows, tried on Synolgy and ended up on RasPi. And yes, i can identify all these platforms an see the how they are related.
For most of the long time users, this might be trivial info. Anyway thight might help in some discussions like openHAB vs opebHABian issue.
Looking at the components we see here, i like the idea of being able to drill down one level to “openhab-webuis” f.e. to see, which are available.
In the docs … hard to say. I’d like to see a chapter named “system architecture”. This would be a good place i think. On the other hand, it could/should be mentioned more often like in Installation Overview -> Plattform Recommendations maybe.
EDIT
First “what is this?” question:
What’s the difference between “openhab-addons” and “[single addon repos]”.
My first thought was the addons in the OH repo vs other addons. But, I understood, all addons included in the distribution were mandated to be in the openHAB repo on GitHub so my guess was wrong somewhere…
I might be wrong, but I don’t think that’s true. The add-ons need to be within the openHAB organisation, but Z-Wave (particularly) and Zigbee are large bindings that are more regularly updated compared to the many in openhab-addons, so makes sense to have them in their own repository. Nonetheless:
as @hmerk said: These are bindings that are separately hosted within their own repository but still in the openhab organisation. BACnet, Zigbee and ZWave are the only ones I can think of, if that’s the complete list I could probably add those directly.
Are there any plans for some sort of community marketplace or organization similar to what Home Assistant does? Not all addons need to be within the distribution, in my opinion.
Well the Eclipse IoT Marketplace still exists for that purpose. Since openHAB 3 is not an eclipse project, that feature will be lost and a replacement is being discussed on GitHub.
These are good points, but we’re straying a little away from where I wanted this topic to go for now. I’m looking to see how the relationship map might help guide users on how openHAB differs by platform or installation method, as well as guiding the user where to go to report bugs in a specific feature etc.
Thanks for the comments @yab! It’s a good idea to put individual elements in, we might need to break it down into sub diagrams though if we add too much detail in.
click on [single addon repos.] to get a view of what’s in there
– click on f.e. z-wave and see, which components the binding is made of (if chris / the responsible / an volunteer makes this available)
— click on one of these components again and see, which other parts of openHAB also use it.
Well, i know this is not a free lunch. I’m trying to transport my thoughts.
From my point of view it will help to show users exactly what you generated it for. Most of the times it would be a matter of pointing users to the drawing. I would not expect a user to know more about the drawing than that it exists once it is included in the - very extensive - documentation. That could mean maybe one out of ?ten? bugs, which would be assigned wrong, will be assigned right then possibly. All others still need the pointer.
I think you are mixing things up - I was required to move HABmin to the openHAB repository.
That’s correct. The ZWave binding used to be part of the addons repo but we moved it a long time ago to a separate repository for ease of maintenance. ZigBee was used by a number of products (not just ZWave, but for example Deutsche Telekom) so it was always a separate binding.
I don’t really want to change the topic, but I would seriously dispute the work “need” - I don’t think any binding “needs” to be in the openHAB organisation. That’s a whole different discussion though, and probably not worth it as I know there’s a drive to keep everything under OH :).
The content looks great to me. For now, I would put it in the Installation Overview page and we can find a new home for it as part of the OH 3 docs rewrite effort that’s yet to be started.
Thank you for bringing this topic as it is indeed quite interesting. I can also explain reason why BACnet binding is separate - cause its licensing is incompatible with project due to underlying dependencies.
Your diagram also shows a particular flaw made intentionally in build relations, which makes it impossible to test webui or single binding alone. It would be possible if openhab-core would create small-ish distribution by taking a bit of work from existing “fat” distro project. By introducing this change we make it possible to install webui with two steps (core -> webui) and not three (core -> webui -> distro).
There are also some reasons why .deb and rpm packages are hosted separately. This is due to lack of good enough package manager who is able to produce both from single definition.
I like these types of diagrams and it may be a more concise amount of space but I’m not sure if everyone will understand it as much as a simple flowchart, I could certainly try to mock something up so we have a basis of comparison!
Agreed! You mentioned to me that the .XML might be easier to put on the docs particularly with Git. Can we embed them directly into the page then?
A valuable thing to do as no doubt openHAB will just get larger!
We want to capture the XML checked in so that others can edit it. But I don’t know how/if the XML/SVG get’s converted to PNG when the docs themselves are built. @Confectrician should have more insight into how that works.
We have got a very old issue somewhere around in the docs repo describing draw.io as main graphics source.
But i am not sure if and how this was set up in the build workflow at any point or if we just collected draw io projects and geenrated fixed graphics after changes.
FYI Asciidoctor allows to inline graphviz stuff. It’s not pretty, but it works. It has also support for other tools which can generate pictures out of text.
