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.
https://openhab.ci.cloudbees.com/job/openHAB1-Addons/
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.
I hope that is enough to get you guys started.