Recently, I wrote a post regarding an issue with my seemingly working (but invisible) Insteon PLM binding (Insteon PLM recognized but not available as a Binding). Since then, I’ve been working on integrating other aspects of my home automation (alarm, hue lights, MyQ garage door opener, etc), and I’ve come up with a more basic question. Are those bindings (and many others) supposed to appear on the Things page? Or anywhere else?
If I install Z-wave or Hue bindings, they immediately appear as types of Things that can be detected/installed/ But when I install bindings for MyQ, Honeywell Alarms, Insteon, and others, no such thing happens. At first I assumed they needed to be configured properly first, and they are. Then I thought perhaps they work by some other means than via the Things menu, but that doesn’t seem to be the case. Perhaps it’s my unfamiliarity with the UI, but I’m getting the sense that only Z-wave, Hue, and Pioneer extensions are going to show up as available Things…
Others will confirm, but what I understand are native 2.0 bindings will appear in Paper UI but 1.0 based will not and have to be configured through configuration files.
That definitely seems to correspond with what I’m seeing. I should probably re-install 1.x and understand how that works first, as I don’t quite understand what I would do after setting up the config files for these bindings. I had previously set up a 1.x VM to play with as well, but it seems that a bunch of things in 1.x have been broken in the cause of making them work with 2.0, and I wasn’t able to get it running properly.
As a first-time user, OpenHab 2 (though still in beta) and its bindings, perhaps looked more finished than they really are. I had gone into it with the assumption that using 2.0, I would be able to weave together my disparate automation systems and set up some rules/macros for them. But that may be a bit further off from this place whether neither 1.x or 2.x are entirely functional.
Like what? I’m unaware of anything that has been broken in 1.0 for the sake of 2.0 (except for one minor thing in the weather binding when creating the webview and even that was mostly a change in API to get at the available values).
OH 1.x is still moving along and still stable with updates being made to the addons and judging from the forum postings I’d say at least half of active OH users, myself included, are still on OH 1.x.
That is indeed exactly what both OH 1.x and OH 2 are intended to do. What in specific do you not find functional?
@rlkoshak I’ll have to spin up the 1.0 VM and get back to you on that one, but basically upon installing it, all the bindings were spitting out errors and I couldn’t get as far as I could with 2.0. I read through some relevant Github issues and community discussion, and when considering modifying the binding myself ran into discussion (InsteonPLM support for 2477SA1 Insteon Load Controller Relay) about the 1.x build tree not being viable any longer, which led to me definitively move to 2.0.
The 2.0 UI would only seem to work with Hue, Z-wave, and Pioneer bindings (that I’ve tried so far). But my issues with 2.0 aren’t really functional so much as my understanding of the interface, or the lack thereof. If it’s the case that I need to use 1.0-style configs for most of the bindings, do I add devices manually in a flat file? Even then, I’m not sure I have any concept of how I would interact with them (command line?). Hence my comment about going to 1.0 to learn how that worked originally. To me, the modalities used in 2.0 are not comprehensible with my lack of 1.0 experience (which may be a prerequisite to even thinking of using 2.0 betas).
But with @RHINESEL’s clarification about the config file requirement, perhaps my re-re-reading of the 1.0 and 2.0 docs will be more fruitful. I just can’t seem to get past having the binding properly configured in its config file. It’s not at all clear what, if anything, OH is capable of doing for me with that step complete.
I think some of the confusion is with Paper UI itself. It’s not a control area so much as an admin ui. You add the items here but still have to use one of the other UI’s (Basic, Classic, ect.) to see your sitemaps and control your items.
Habmin 2.0 no longer does sitemaps so you have to build those manually via text (basically the main reason I ditched 2.0 and installed 1.0 as I had no clue how to do sitemaps).
OT… skip if you don’t care…
In my humble opinion… For the “non programmer”, OpenHab 1.0 is barely an option in HA. 2.0 is out of the question. Scattered information all over the internet (although getting better with 2.0 Documentation push), confusing UI, multiple “admin” spots (Paper UI, Habmin, config files directly), multiple parts of bindings to install (binding and actions). Graphically creating rules not the greatest. I see where they are going with 2.0 but it isn’t anywhere close yet for a casual consumer let alone someone that barely knows what they’re doing.
My progress has been this with OH:
Install 2.0- 2 hours
Install 1.0- 20 hours only to run into stumbling blocks (persistence, a RPi issue) Ditched project since I just didn’t have the time to invest.
Months later…
Install 2.0- 2 hours. Find out Habmin 2.0 doesn’t do sitemaps, no idea where to start
Install 1.0- about 10 hours invested so far. System running fine, now just moving most of my devices from Vera to Aeon Labs ZStick.
OH is simply not plug-and-play. Will it ever be? I don’t know. But most people don’t/won’t want to invest the time like we have.
I’m not sure what specifically the issue was there. The latest nightly build of the openHAB 1 bindings on cloudbees was last night. So the binding builds are not broken as far as I can tell. I don’t do dev on OH yet so I can’t really comment as to what problem they were having but I do know that the OH 1.9 bindings are still receiving some bug updates and still being built nightly.
Yes. You create name.items files where “name” is whatever you want. See the Items wiki page, OH 2 Concepts docs for OH 2, and the specific OH 1.x binding wiki page for details.
OH 2 has/will have the ability to link Items to Things through PaperUI but those only work for OH 2 native bindings and they do not live in a flat file. But if you are using OH 1 bindings you must put them in .items files.
OH 2 is definitely a work in progress. Its intent is to make it easier for newcomers to get up and running but it is only at the first half step in that direction. There is ton left to do towards that goal. It also lacks complete documentation which is another stumbling block. The developers are all aware of this and working diligently to address these concerns.
The end to end config is something like this:
Install the binding jar (OH 2 through PaperUI, in OH 1.8 use apt-get or copy the jar file to the addons directory).
Configure the binding (OH 2 through name.cfg, in OH 1.8 in openhab.cfg)
At this point OH has the ability to communicate with whatever technology the binding supports. The ability to communicate does not mean it knows how to do so. You need Items for that.
On OH 2 with native OH 2 bindings that have auto-discovery you will have a lot of Things in your inbox. These Things can be mapped to Items (see http://docs.openhab.org/concepts/index.html). In OH 1.x and OH 1.x bindings there is no concept of Things. You must manually create Items in a .items file. Part of defining the Items is the Binding Config (stuff between {} at the end.
Now that you have Items you have essentially mapped the “real world” (e.g. light bulb, physical light switch, etc.) with an OH concept (Color, Switch, Contact, etc.).
To define behaviors you must create rules. Rules are defined in .rules files. See the Rules wiki page for OH 1.8 and the OH 2 Automation Documentation for OH 2. Rules are event based. When an event occurs (a time based on a cron based trigger, an Item receives an update or command, etc.) the logic in the Rule executes. The default rule’s language is a Domain Specific Language based on Xtend bearing the most resemblance to Xtext, but with the JSR233 binding on OH 1.x and Next Gen Rules Engine on OH 2 you can use Jython or Javascript. Rules are Turing Complete so if can be done by a computer, it can be coded in Rules. But no matter what is done (graphical, high level, etc) Rules will always be coding.
To create a display one creates a sitemap. See the Sitemap wiki page. In OH 2 you install Basic UI or Classic UI through PaperUI. See the OH 2 Sitemaps Docs. All of these get configured from the same .sitemap file. You place this file in the configurations/sitemaps folder. This is where your manual control switches, sliders, charts and such appear.
You may want to restore some or all of your Item’s state when OH reboots, save historic states for analysis, and, or put charts on your sitemap you use persistence which saves the states to a database.
@rlkoshak Thanks! I think that, along with @RHINESEL’s clarifications, provide a jumping-off point. I hadn’t understood what OH’s “persistence” component was doing until reading your comment. I had also let the fact that a binding could be installed via Paper in 2.0 make me think that it was really a 2.0-compliant binding (which some kinda-sorta are). And I had assumed that Paper was more than just an administration panel for some select 2.0 bindings currently. The multiple UI’s are more than just a change in window-dressing, which was unclear when I first booted OH up.
EDIT: Beta 4 now includes HabMin, which shows insteonplm as a v1 binding. In theory, it may still be compatible with v2 via the v1-formatted flatfiles, but I’ve not been able to get that to work at all.
I’ve had the insteonplm binding (version 1.9) working when installed via Habmin. By creating a xxx.items file in the conf/items folder. I do still have issues with this set-up.
After using Habmin to install the insteonplm binding it picks up the items in my .items file and for the most part it works, but if I shut down and restart the console, the log file indicates that the plm is connected, but none of the items seem to be actually connected to the binding ( even though they were prior to the shut down). the items exist in the console (smarthome:items), but my motion sensor will not trip and lights do not work via the Basic UI as they did prior to shut down. To get it working I have to uninstall the binding via Habmin, then reinstall it again. Naturally this will only work until the OH2 console is shut down again.
Although the insteonplm binding works for the most part, not everything works as advertised, so in order to attempt to see why, I want to enable the debug mode of the binding, but I do not understand how the logback mechanism works in OH2. The docs for the binding provide a code snippet to copy to the logback.xml file, but I can’t figure out how to implement this in OH2. Any help would be appreciated.
