Help, I'm ready to give up

[rlkoshak (Rich Koshak)]

@ThomasBrodkorb

To add one “thing”, I have to edit at least three files:.items file.rule file.sitemap file.

These are three very distinct things.

As a programmer you will understand this simili.

Think of your .items files as your .h

Think of your .rules files as your .c

Think of the .sitemap as the user interface code which, if you are following MVC is separate.

So to turn around your question “In C why do I have to declare a bunch of stuff in a .h file and write functions in a .c file and what’s with all that code over there that runs the UI?” Its because they serve a different purpose.

@ThomasBrodkorb

Everybody explains how to “discover” things so you get it into paper UI- Great. It’s there!!! What is the purpose of having it there?

http://docs.openhab.org/concepts/index.html
http://docs.openhab.org/tutorials/migration.html#new-concepts-things-and-channels

If you are coming from OH 1, Things and Channels replace the config stuff you used to put between { }. This needed to be abstracted to enable autodiscovery and management of everything through the UIs.

@ThomasBrodkorb

Why isn’t it possible to just have ONE kind of object for a “thing definition”.It should contain the config, the rules, the items, the sitemap (fragment).

How would you propose to mix the functionality across them? For example, create behavior that triggers based on events from multiple sources? If all my zwave stuff is stuck located together, how can I let ym zwave stuff control my MQTT stuff and vise versa?

The primary reason d’etre of OH is to act as a kind of universal translator between multiple (over 150 at this point) technologies and APIs. As such it used the common architecture of layers of abstraction. If you compare it to the OSI networking model you will find a lot of parallels.

Application  Sitemap
Presentation Sitemap
Session      Rules
Transport    Items
Network      Channels   
Data         Bindings/Things
Physical     Dongles/APIs

Obviously the simili above is not perfect but I hope it is at least illustrative. These things build upon each other and the layers of abstraction allow, for example, Rules to work with any Item with no knowledge of what that Item represents nor how that Item communicates with the device it represents.

@ThomasBrodkorb

There is a rule set which allows me to charge my car with exactly the current I calculate which I do not consume elsewhere in the home.This should be packaged in a nice way to provide this to others (in an easy way).

This is in the works and one of the main reasons for the Experimental Rules Engine.

@ThomasBrodkorb

It is also not possible to have input/output parameters (which I have seen at Loxone) where I can define logical switches for On/off based on conditions.

Design Pattern: Unbound Item (aka Virtual Item)

Problem Statement Sometimes one needs to create a flag, control, switch, or some other control that is not bound to a device or channel. For example, a Switch to override presence detection. Concept Create an Item that does not have a binding configuration. Simple Example Switch VirtualItem "label" <icon> (groups) // No binding config See the Sensor Aggregation Design Pattern for a more complicated example. The Virtual Item is Override_Presence in that example. Advantages and Limitations V…

@ThomasBrodkorb

What we should have is a set of LEGO bricks which we just put together to produce a nice home automation.

And this is what the Experimental Rules Engine is intending to create. However, even with this you will still have a layer of abstraction between Items and Rules because a Rule should not know nor care what technology or device an Item is attached to.