I keep seeing that there are misunderstandings about how openHAB actually works exactly. At the end of the day, everyone has an individual setup. This is also due to the different items. My idea would be that I openHAB therefore represented in a block diagram. I’ll explain various things and ask a few questions.
Often the event bus is represented as follows.
What I like about this representation is that you can see that different protocols are used in how the binding communicates with the device.
What I personally miss is that I have to create one or more Things from the Binding first. These Things are needed to create items. The communication between items and things takes place via channels.
There is another similar representation:
What I like is that you can see what is physical and what is virtual. Also good is the representation of item registry.
What I don’t like is that it says Hue, Samsung and Sound at the bottom.
And something else bothers me. For example, the REST API. Can it now directly trigger a command on the event bus or does this go through the item registry? Do changes to items through rules or through the UI then only have the way via the item registry? I think the arrow from REST API with commands to the Event Bus is too much, because the REST API is bidirectional to the Item Registry.
Also, the arrow with status updates to the Persistence Service bothers me. In my opinion, this should also be done via the item registry. What also bothers me here is that there is no arrow in the opposite direction. I mean something like restoreOnStartup.
Perhaps one would have to write with some arrow to the fact that this would be done only with certain configurations or in special cases so.
I have one more representation:
Granted, this is still for openHAB 2.x. What is again good is the representation that a binding refers to hardware or network service. In this representation, Rules appear to have direct influence on the Event Bus, and so do the UI and REST API. What I like is that there are multiple UIs that would be displayed. Since some fall out for openHAB 3.x.
The important question remains. Does everyone now communicate via the item registry and this results in changes to the event bus or vice versa, does one communicate with the event bus and this in turn results in the item registry adapting?
I have one more representation:
I think here you can ignore a large part. If you look at the first two graphics shown and now look at this one, it is confusing what is meant by openHAB Repository. You might think from the first to the second figure that this would be the Item Registry, REST API and Persistence.
Let’s finally get to the last graphic I brought:
I would almost be inclined to make the Item Registry larger. Just draw in some items there. These of course have an arrow coming from a Thing. So quasi: The item registry has several items. I can also draw an Unbound Item (Virtual Item) there as an example.
So, that I expand the second figure.
Also I would have to create one or more Things from the Binding first. And also here the correct representation would be as a rule that I would have to represent different Things. Let’s go to the Philips Hue Binding as an example. I would have a Thing for the Philips Hue Bridge. My Hue lamp would have a reference to the Bridge. And this Thing would have more precisely several references via Channels to different Items, which would be stored in the Item Registry. On the hardware side, I would also have to draw in the bridge first and behind the bridge are different lamps accordingly.
For Automation Rules, I could of course also subdivide into DSL and JSR223. There also exemplarily a .rules, a .py, a .js file etc. represent.
For User Interfaces I could also list different User Interfaces. According to my understanding, MainUI, BasicUI, HABPanel and HABot should be listed there.
Now I see openHAB as a program running on a server/computer. So I would draw openHAB in a big box and around it the computer. For various reasons. Because bindings communicate with locally installed programs or via different interfaces of the computer.
An example would be the MQTT binding. For this to run, an MQTT broker can be installed on the computer (or on another computer). Definitely, however, an MQTT client must be installed. The binding communicates with another program (client) and this in turn communicates with another (broker). And from there everything goes to the network interface.
Another example would be the Exec Binding. With this I execute commands locally on the computer outside of openHAB. I would therefore represent the console as a block. Over it a Python, C, C++, Java or whatever program can be executed. This would remain local. Or I execute ssh over it, which would be another block and this then goes out over the network interface and possibly to another computer, where I draw in that something is executed there.
Then I have both Zigbee and Z-Wave, soon also LIRC and Bluetooth. There the binding should go to the USB interface of the computer. So I would have to draw in that, for example, a Zigbee device then communicates through it and the binding accesses one of several USB ports.
Philips Hue also goes out via the network interface. I’ll take HomeMatic as another example. Up to the gateway (CCU3) the communication from the binding also goes over my classic network. From here, of course, I must then also draw in that the HomeMatic gateway to a HomeMatic device communicates via a radio standard.
I still use HABApp, which I would have to draw in as another program. This accesses the REST API.
A difficult use case for me will still be the representation of the openHAB Cloud. And the connection to Amazon Alexa.
I took a closer look at the diagram and I think something is wrong. Or rather, it is presented in a very idealized way. It also feels like you are promised more than really works in my experience. But it may be that if I create my own server with the cloud software, that would actually add more than just the IFTTT integration.
I am irritated by the Device Connector. I think the devices are not connected via the cloud but via openHAB. And other inconsistencies.
I don’t want to digress too much here. The question would rather be the representation of the two bindings. The cloud connection takes place via a Thing. A secret is used here and so on. The only thing that happens in my opinion is that the cloud is then allowed access to the REST API and can query all items, things, sitemaps, etc. and thus display them. If I understand the Amazon Echo Control Binding correctly, then the binding goes directly to the Amazon Cloud also via login data, but the data flow comes from the openHAB Cloud. So for this I would have to make an arrow from the Amazon Echo Control Binding to the openHAB Cloud, which would be a kind of gateway and from there just continue to the Amazon Cloud? The login data would ultimately also have to be passed on via the REST API. In other words. The openHAB Cloud mirrors my REST API.
I am unfortunately ill, otherwise I would have already sketched a first draft and uploaded it. But I’m collecting ideas for possible representations. Maybe you can think of other things that should be considered for a correct and detailed presentation.
Many thanks in advance.