Is it a THING?

I am trying to wrap my head around OH2 and have a question regarding things…

My whole house lighting system (vantage) can be controlled via IP…is this a THING? I OH1 my items had the IP address and the mapping in the switch…should the Vantage controller now be a THING?

There is some really necessary nomenclature documentation needed for this.



What in particular do you find deficient with the writeup here:

The Things section is about half way down the page. If this writeup misses the mark or is unclear we need to know so it can be updated and expanded in appropriate ways.

Things are not really all that different. A Thing + Channel replaces the stuff that you put between the { } in your OH 1.x Items. That is all there is to it.

A Thing represents a device or “thing” that OH interfaces with. Many devices offer more than one data or way to communicate with it. For example, I have a light switch that can also be a dimmer so that Thing has two channels, one for the switch and one for the dimmer. So to link an Item with a Channel you just put {channelId="ID of the channel"} in your Item definition where you used to put {zwave="some complicated zwave specific configuration string"}.

The concept of Things and Channels were added to enable autodiscovery and autoconfiguration of devices.

However, be aware that Things and Channels only exist for 2.0 version bindings. 1.9 SNAPSHOT version bindings still use the same old Item definitions in .items files.


Rich -

I appreciate the link to the documentation and your further explanation…

Can you answer my original question? I think that answer will help me get my brain around it…

Is my vantage controller a THING? And why is it or isn’t it?

Try this…

Or this:

I’m guessing that if one link didn’t help clear this up, two more won’t necessarily change that.

I could be well off the mark here, but I guess a simplistic way to look it at is a thing is something that if you took it away, that part of your system wouldn’t work. So in your case, the vantage system and its attached lights. If you took away one of the lights, the other lights would still work, so that single light isn’t a thing, it’s an item. But if you took away the vantage controller, then none of the lights would work. So that means it must be a thing.

I guess perhaps the issue is that, in my understanding, OH2 is supposedly meant to be to more accessible to non-technical users. But the description of what a thing is that you linked to includes terms such as JSON, Java and Xtext-DSL, which if you are a non-technical user is unlikely to help your understanding.

I appreciate that it is still vert much under construction, but perhaps a jargon-free very simple explanation in the beginners tutorial section of the documentation would be of use? I’m sure there are many users who just want to set up openhab and add some hue lightbulbs and a sonos player or the like who may be put off by the complexity of the general documentation? I think OH2 is very good for this type of user and with a little encouragement many non-technical users would be able to set up a simple working system.

I didn’t answer your specifics because the answer depends on how the binding that connects to the binding works.

For example, in zwave one creates a serial binding connection Thing for the Controller. But other bindings may not use Thing for the controller. It really comes down to how the developer implemented the binding.

As a general rule, if you would have created an Item for the controller in OH 1 you would have a Thing for it in OH 2.

This explanation is not accurate. Typically there would be a Thing for each light. To provide a concrete example, I have a Zwave controller, several outlets and a light switch. All of these are represented by a Thing.

That is the goal and great strides have been made to achieve this. The creation of the concept of Things and Channels is no small part of achieving the huge usability gains achieved thus far. But we are not there yet. And frankly, OH is always going to be a tool requiring technical skill. It will never be made simple enough to remove the need to technical skills and still maintain its ability to be as flexible and capable as it is.

I completely agree with that. And the link I provided is the OH 1 to OH 2 migration document which, given its audience, is able to assume more familiarity with these terms and concepts than someone new to OH entirely. The links provided by MikeD and Kai provide a less technical explanation. Given that KidSquid has been around while I assumed he has been using OH 1 and therefore probably familiar with the technical terms and concepts.

Th documentation is undergoing heavy development and we would welcome any changes and additions you could provide.

1 Like

I appreciate everyone’s comments on this…

I think @guttois74 really hit my thoughts dead on…if OH2 is desired to be non-programmer friendly then stupid-simple explanation of concepts and getting started guides are a must. The fact that most responses were RTFM will simply turn away many who want to learn and embrace this technology. Now I know that online communities such as this are not paid support sites and everyone tries to contribute to the further knowledge of those who are new to OH.

I know that many who participate here are the ones who write custom bindings and extended OH to new heights. But if the desire is to broaden the scope of OH, expanding the base of users must be kept top of mind - and that expansion needs really to explain difficult concepts in simple language. Making no assumptions of the reader. By expanding the user base you will naturally create a large chorus of evangelist who will bring even more users to the OH family.

Unless I missed it, I still can’t figure out how to create a thing out of my vantage controller or the controller and the lights I want to control. I am a fairly technical person and I want to a make OH a part of my household.

This is not a bitch or a rant…just my thoughts as a user who has spent many hours trying to dig through this community and the associated docs frustrated that such a great concept and product is so damn difficult to get off the ground.

I think there is a fairly simple answer: You cannot. Checking the supported technologies, I cannot find anything about a vantage lighting system.
So openHAB is simply not for you. If you were a programmer, you might ask “ok, but how can I add support?” and then you come across questions like “what is a thing?” and “how do I map my vantage system best to a thing?” and we gave you answers to those questions, assuming you were tech-savvy and wanted to head this way.
As a regular user, you do not need to have a deeper understanding about the internal Thing concepts - what you can find in a dictionary about “Thing” will do. They pop up in your inbox and that’s it…

Wow…way to tell a fan of the product to pick up his toys and go play somewhere else.

Let me rephrase it: If you expect OH2 to allow non-tech-savvy people to hook up your vantage system in a more user-friendly way than OH1 (where you apparently had to fiddle with the TCP-binding, so probably nothing you would consider “user-friendly”) then the expectation is simply wrong and it won’t help if anyone gives you a perfect documentation or best explanations - your only chance to use openHAB 2 with your system is to use it exactly the same way as you did in openHAB 1, that’s my message.

@KidSquid, Kai can be curt but I don’t think he meant it to come across as it reads. We are dealing with text based communication with I would venture to say a majority of non-native English speakers. I think what he was trying to get across is because the Vantage system uses the TCP binding, by definition it is not something that will ever be non-technical user friendly. There are a certain set of bindings (Exec, TCP, Serial, HTTP, GPIO, etc.) that by their very nature are so low level that they require a technical user to get working. For most other OH 2 bindings, all the non-technical users should need know about Things is that they show up in their Inbox.

And I agree. Anyone who thinks their grandma will ever be able to configure automation for something that requires a TCP binding through openHAB is going to be very disappointed.

I’ll break it down a bit further for you to explain a bit about the answers you are receiving and why they are not helpful to you because I think there is a major miscommunication going on here.

You asked specifically about a Vantage lighting system in relation to Things. Now I’m a bit pressed for time these days so I didn’t do my due diligence to look and realize that the way you would integrate this system with OH is using the TCP binding. I just assumed that there was a Vantage binding and there was a 2.0 Vantage binding to boot because you were talking about Things.

It wasn’t until right now with Kai’s most recent post that the light bulb went off in my head.

So here is the tl;dr. Things are irrelevant to you when it comes to Vantage. The TCP Binding is a 1.9 binding. Things only exist for and are valid for 2.0 bindings. 1.9 bindings, even in OH 2, work IDENTICALLY to how they did in OH 1. No Things.

I think the source of your and my confusion and why the help we tried to provide didn’t make much sense is that you are trying to figure out how to create a Thing for a binding that doesn’t support Things.

I’m also aware of the deficiencies in the documentation. We all are. And it is more than a little frustrating to receive post after post after post after post of people all saying the same thing:

“OH is too hard for non-technical people and the docs are too complex and incomplete. openHAB will never be a tool for non-technical users until YOU fix it.”

We know! We are trying to fix it and to make it better. But when I keep seeing these “the docs suck” postings I can say, at least for me, it feels a whole lot like being stuck on the side of the road fixing a flat tire while someone stands there and watches me work saying over and over “hey, did you know you have a flat tire?” I’m sure they think they are being helpful, but I already know the tire is flat and it would be a whole lot more helpful if they actually pitched in and did something to help.

But realize this:

  • this entire effort is completely supported through volunteer efforts
  • pretty much everyone who currently volunteers their time are highly technical and/or developers of the product
  • few if anyone who does volunteer are technical writers (i.e. the kinds of professional writers who create user manuals)
  • almost no one likes to write documents
  • there is no way to force people to work on what they don’t want to work on

Hence the current state of the docs for OH and just about every other open source project out there.
<end rant>

But, if you are not in a position to pitch in and write or edit documents there are lots of way you CAN help. Above I asked “What in particular do you find deficient with the writeup here?” I wasn’t being flippant or dismissive. We genuinely want and need concrete and actionable recommendations. Broad “the docs are too technical” comments are not helpful. “I don’t understand term x, y, and z” or “I don’t understand how to create a Thing using binding X even after reading the provided links” are both helpful.


Hi Rich -

Thank you for your time and your well thought out response. I truly do appreciate that everything here is volunteer and that the folks responding definitely have a much higher level of technical expertise than I do when it comes to ObenHab. If you re-read my follow up post I acknowledge that…I’m not trying to gripe I was attempting to illustrate the disconnect there is between the higher end developers and a larger base of users…this larger base is the one that will bring attention to the project and more eyes to the project. I want OH to succeed and for that to happen in my eyes there needs to be some more straight forward getting started guides (not ranting, explaining my thoughts) When looking at OH2 it becomes confusing right off the bat - for example once I’ve installed OH2 and loaded up the initial URL I am presented with 4 Ui’s from which to begin. It takes a bit of detective work to figure out that Paper UI is only for Admin work and that you can’t add sitemaps and items to it. Maybe it’s just a nomenclature thing…instead of calling it by it’s framework maybe it should be Admin Tools or something similar…I know I’m not the only one who has faced this as I read through the post in the OH community…It seems like some assumptions are being made about the typical user and their familiarity with Eclipse Smart Home and the like and what you really have are home automation geeks who may never have written a line of code but have a collection of automated components in their home that they are looking to find a central point of control for. Again this is not a bitch but observations from the other side.

You were immensely helpful for me when I first came to OH and was looking to control my lighting system with OH1. You provided insight and guidance which once the veil was lifted I was able to make great strides on my own and even helped others in the community when my limited OH skills would be helpful.

This perfectly illustrates part of the problem…there needs to be a more clear definition of what the heck a thing (and other OH2 components) is and what it isn’t. How was I to know that there will not be a thing for TCP|EXEC|SERIAL etc??

This is certainly nothing that would ever come out of my mouth…this is technology and technology has a learning curve. Heck if I can program Crestron I should be able to tackle this. What I think the frustration is on my part and from some others (if I can speak for them) is that the basic fundamentals needs to be put together in a consolidated location and take the user through what is and what isn’t…beginning construction of items, links, channels, etc.

If you provide the somewhat techie users like me with a window into the basics you’ll immediately expand the army of folks who can respond to the new newbies that come to the board and that will free up the experts (like yourself) to develop more great code and answer the more complex questions that arise.

I want to grow my knowledge of OH and make it work in my home and others…I just think we need to provide a layer of basics to the masses to get over the initial hump.

Sorry if I rambled I just wanted to get my thoughts out before I head home.

I think we are in complete agreement. I don’t think anyone is satisfied with the docs for OH 2 as they currently exist. The beginners area of the docs are a travesty. And there is a plan and an outline to bring the docs up to where they need to be and lots of people are working them, myself included (I sheeny the weekend transcribing and editing the migration tutorial to be posted to the official docs). But right now I’ve only a few hours in front of a computer a week that I have to split between working my own ha deployment, writing on the docs, and answering the more technical posts. The rest a steal some time here and there to respond on my phone. So, in short, if we wait on me these docs will be finished around the same time OH 3 comes out. Thom is doing a lot and has taken a leadership role, but he is also developing openHABian. Lots of others are helping out too by progress is slow. So we really do need more help.