Hi there, I only recently started to fiddle around with OpenHab but I am neither new to development or home automation. I’m currently trying to understand the reasoning of some of OpenHab features to customize OpenHab to my needs ( I like tinkering with Arduino and similar “things”). Are their any architectural resources about OpenHab and specifically which Item Types are supported and why others are not?
Furthermore I would like to know if there are best practices for Bindings for OpenHab 2 besides existing ones.
Thanks in advance
Tobias
The architecture of OH2 is not yet well documented but I believe much of the overall concepts and architecture are the same so the wiki is probably a good place to start.
Thanks for the links. I already read them in advance, yet I’m struggling to understand the reasoning. Just to give an example: Why are the Item types limited, when are the advantages overweighing the rules.
I’m using Philips Hur at home and I find it rather strange to declare 3 different item types per light bulb to support all its features. Is this solved solely through grouping? Although I understand the need for abstraction, it seems odd to not use typical smart home “types” like e.g. “Lamp” which can specify support for dimming, color, switch.
I don’t intend to sound rude, there is probably good reasons for these decisions but I haven’t found such explanations yet.
I don’t know that there is anything documented that describes the reasoning for why things are designed a certain way. Perhaps @kai, @teichsta or one of the other project leads can correct me if I go wrong here.
If you look at all of the Item types there is one thing that they have in common: they all have only one state. This makes many things in the architecture across the board simpler and more consistent and IMHO it is an elegant abstraction. But this means if you have a device that has more than one state you need to create a separate Item to represent/control each state. Honestly, the only place where I’ve seen it be much of a problem is when dealing with bulbs that support color.
You should only have to define two: Dimmer and Color. A Dimmer can accept Switch commands. However, if you want to control your light three ways from your sitemap (Dimmer, Switch, and Color) you do indeed need to have three elements (unless you set a flag on the setpoint element that lets a click be treated as switch and use a long press to set the dimmer value), one for each control though you should be able to use the Dimmer Item for both the Switch and the Setpoint sitemap elements. And admittedly needing to have two rows for each light is a little clunky.
But at the end of the day, a color controllable bulb has two states so you will always need two controls for each one. So the quibble really becomes that you can put both controls on the same line in the sitemap.
I envision a new piece of documentation that explains all the item and data types: which data types can be used to set the state of which items, and which commands can be sent to which item types. Further, each binding document would concisely describe the item types it supports.
Bigger picture:
There is a growing need to further evolve the openHAB documentation, to make it clearer and better organized. Also, a proper, top-down view would accommodate areas that are specific to 1.x vs. 2.x. To be done right, this is a big project that needs a proper “vision” for where it’s headed. 2.x documentation has been done differently (checked into source control as markdown files), so a number of factors need to be considered before a documentation plan could be declared “good.” (And personally, I would love to see @rlkoshak have a role in all of that!)
Is there a thread on the Eclipse SmartHome forum to discuss this? Kai tried to start one here i think but i think he said in the sand breath that he wanted to hold off on too much focus on documentation until the move to Karaf was complete, which i presume is done in the beta.
I do not even see a problem there - a ColorItem inherits from Switch and Dimmer and thus you only need the one and only item for your light. For the UI, you can define where you would like to see a switch, a slider or a color picker and for different pages you can use different widgets, all being associated to the same item.
until the move to Karaf was complete, which i presume is done in the beta.
Yes, although I have not foreseen that Karaf will break a lot of existing functionality and I know have to find solutions for these problems asap; so my time to discuss documentation is pretty limited
But nonetheless you are right: We need to come up with a good new structure for the documentation - I would also welcome if @rlkoshak would take a leading role in this; I’d suggest to start a new dedicated topic where we can start exchanging ideas.
Hi thanks for the replies. If I understand this correctlz ColorItem isn’t really about atomic operations as mentioned before?
One question still remains. Can a Binding define a new Item Type or is this done only by the core ? And what would make a new Item type in the core a reasonable request?
Just to be clear, I simply try to understand the communities idea and thinking about these thinks…
Apparently a ColorItem is a Switch and a Dimmer so you can define one item and use different types of controls on your sitemap to control it the three ways. I didnt know that.
The item types are absolutely something implemented in the core. Adding a new type would cause changes across not just core but existing bindings would need changes as well. Not something to be taken lightly.
If someone had a compelling reason why you cannot do something without adding a new item type, a feature request could be submitted. But given the impact such a change would require, the reason would have to be really good and explain how you cannot use existing item types. And given the pretty comprehensive coverage the existing types provide, it would have to be something truly different and unique.
Hi @rikoshak,
I stumbled across this post while playing around with Openhab 2.4.0. I was trying to display the state of the switch item (for Hue Bulb) with only read access in the control tab. A simple solution would be to have a different item type with only read access to the switch state but I couldn’t find examples of somebody using the “String” item type either.
I think this is useful when somebody just wants to share the state of the device while integrating 3rd party service or maybe allowing access to only one command on the device e.g., only allowing lock but disabling unlock.
I’d appreciate if somebody posted a link to tutorial which tries to accomplish similar functionality. I’m new to Openhab and I might be misunderstanding the architecture design itself.
I guess you are talking about PaperUI here? This is an administrator’s UI. It’s not intended to be ‘customer’ facing, and so there is no provision for controlling what is displayed nor how it is displayed/controlled.
The core user UI would be BasicUI where you control presentation using sitemaps.
When using sitemaps, you would use the ‘Text’ widget to display any Item you like with no user control possible.
As rossko57 indicated, you have no control over the Control tab.
To achieve this in basicui you would use a Text element on the sitemap. I believe habpanel had a similar element.
This is something else entirely. There is in fact a read only"switch". It’s called a Contact. But you can only link a Channel to a Contract if the building supports it and far too often the bindings only allow Switches, even when a Contact is more appropriate. So for this use case, not a very common one I might add, one would use a Proxy Item and Rule to synchronize the Switch with a Contact and expose the Contact with the outside service. But keep in mind that few outside services will support a Contact either so even then it may not work like you want it to.
