I’m not understanding something about openHAB2. I used the habmin to find and configure most of my ‘things’, but when I look in the config directory on disk, the ‘things’ directory is empty. I was expecting a whole bunch of ‘thing’ things to be there.
Also, it’s unclear how one goes about creating sitemaps and python scripts for actions. Documentation is sparse and the UI is non-intuitive.
The things aren’t automatically populated into files. The Things folder is where you can manually configure things which will appear in Habmin for later use/configuration.
Sitemaps and scripts/rules are the same as in OpenHAB1.x and the wiki for this is much better configured at the moment (however the community is improving the OH2 docs every day).
If you haven’t played with OH1.x then it would probably be better you start there to get an idea of how the software works as the OH2.x install is still very much a beta, and while improving daily, can still cause some serious frustration.
I have an openHAB 1.8.3 setup now. I thought I’d try out openHAB 2, but it seems not to be ready for general use yet.
I was really hoping that openHAB 2 would auto populate items from ‘things’, as that’s one of the more painful parts of 1.x. I want ways of wiring up things using rule based actions without having to deal with the details of managing individual, distinct items. The items are fundamentally attributes of things, so shouldn’t have to be declared separately by hand like they are in 1.x.
Also, it’s critical that there’s some sort of real scripting language. Python, groovy, even javascript (tho people may argue about whether that’s a ‘real’ language). The default scripting syntax in openHAB 1.x is not useable.
I think you have a misunderstanding of how Things, Items, and the relationship between the two work.
Things represent the connection between OH and the “real world.” In OH 1.x a Thing takes care of the stuff you would have put in { } as part of the Item definition.
Items, on-the-other-hand have always represented the abstraction between the real-world and OH. It is upon Items that rules, persistence, and all else inside of OH operate. This is how you tell OH how to interact with the devices. Things can be automatically discovered and configured but Items can not. How is OH supposed to know it needs to represent my z-wave smoke alarm as a Switch as opposed to a Contact? How is OH supposed to know it need to treat my MQTT topic where I publish some temperature readings as a Number and not a String? This is why you will always have to manually define Items.
But with OH 2 and Things, you no longer need to fight with getting the binding configuration correct as part of the Item. In fact, for bindings that support it, Things are automatically discovered and configured for you.
With the JSR233 binding OH 1.x (and OH 2 through the compatibility layer) supports Jython and JavaScript. With OH 2’s Next Gen Rules I believe at least JavaScript is supported, maybe others.
But for the record, while it has its problems, I find the Rules DSL to be a “real” scripting language and very well suited to event based programming such as is required for the Rules DSL.
It’s unclear to my why items are not simply attributes of things. And why would you want to configure your smoke alarm as a switch? Unless, perhaps, you’re treating your smoke alarm as an output device, to turn on the siren? That seems like a rare use case that would require a manual configuration of the otherwise automatic item creation. Why would any standard device not have obvious mappings of its I/O attributes to items for easy use? I don’t understand why this needs to be a manual step for most standard things like switches and sensors and thermostats and such. When a Fibaro motion sensor is detected, I want its temperature, motion, luminosity, battery, tamper alarm, etc. items to get automatically generated… preferably in a namespace under the motion sensor, with automatic tags added to each item for its ‘kind’ of thing (e.g. so that I can make an alarm for all the battery things if any one of them falls below 20% or something).
I was unable to find a JSR223 plugin for OH 2. Can I just drop the 1.x one in there and have it work?
I was unable to get anything other than the most basic of rules to work, and when they did, they ran extremely slowly. In 1.x, I ended up timing similar (simple) logic between jython and the built in DSL… the jython was substantially faster, as well as more powerful.
Richard
Items are what OH operates on. If anything a Thing would be an attribute on an Item. This is how OH and ESH are architected.
And what about Items that don’t correspond to a Thing such as Proxy Items or Virtual Items?
Ultimately there are more rare use cases than standard use cases. Everyone’s home automation is a unique application with its own quirks and problems. But who knows, perhaps the next step is to set up some automatic Item creation. I don’t know the complete ESH roadmap. I can see the initial population of some default configured Items for discovered Things. Not having use OH2 yet, for all I know the hooks are already there.
There are as many if not more devices and services that don’t have obvious mappings. MQTT, Serial, HTTP, Exec, TCP/UDP, etc. all provide String data. Not everything, and perhaps not even the majority of devices and services that OH supports have the ability to provide such a nice mapping between devices and Items. I can certainly see it being nice for those technologies where it is possible doing something like that but one will never be able to completely get away from creating Items entirely.
This namespace is called a Group in OH. And again, they are not automatically generated but they are key to doing what you describe. In fact, if you have not been using Groups, that explains why you were having issues with the Rules DSL. Groups are key to concise and generic Rules.
But automatic generation of Groups provides more challenges than Items. To take your battery level example. As far as OH is concerned it is a Number and there is no obvious distinction between the Battery Level Number and the Light Level Number and the Temperature Number. So while it might be possible to figure those distinctions out within a single technology (e.g. zwave) there will be no way to figure that out across technologies (i.e. OH will not be able to map the battery level from a zwave device with the battery level from a Bluetooth device). So you will still have to manually create and add Items to Groups for that sort of tracking.
Install the OH 1.x Compatibility Binding through PaperUI and then drop the JASR233 binding’s jar into the addons directory and you are good to go. Everything concerning use of the binding is the same as in OH 1.
The DSL does require thinking about the code from a different perspective than most coders are used to who only program using structured programming languages (C/C++, Java, Python, PHP, etc). The Rules DSL is a weakly typed event driven programming language and if I had to assign it to a type it would be an Actor based programming language like Erlang. As such the Rules DSL is as different from Java as Java is from Lisp. They are different paradigms. As such, if you try to program your rules as if they were Python you will run into trouble.
I have some very complex rules. All of them execute more than fast enough for this application. And since the Rules DSL is Turing complete, “more powerful” really isn’t all that meaningful.
I’m not trying to convince you to change back, just explaining that, IMHO, most people’s problem with the Rules DSL stem from trying to use it as if it were some other language (I can code Fortran in any language.). If you like Jython, stick with it. It’s a great language too.
Only in two cases on this forum that I’ve seen so far was the speed boost from Jython needed. Worrying about speed in typical home automation use cases is like putting premium gas in an 1965 VW Bug. It will work but ultimately you are spending a lot more than you need to and getting little to no benefit. Don’t fret about speed until it actually becomes a problem.
Also, when doing timing tests it is vitally important that you are actually testing what you think you are testing. There is a lengthy thread somewhere on this forum where similar timing tests were performed. The initial conclusion was the Rules DSL was really slow at math, but what the test was actually testing was how fast the String “+” operator runs (known to perform exceptionally poorly) when compared to Python’s %s String substitution. Timing tests are really hard to get right so you are comparing apples to oranges.
I’m not sure how much you’ve looked at OH2, but all the above DO show up automatically when you select the thing from PaperUI or Habmin (they care called Channels) as long as the binding supports it. Corresponding items can also be generated automatically (the white dot in the blue circle shows that an item is linked to the channel).
As @rlkoshak says, I also find the DSL of OH2 quite usable for rules once you understand how it works. I have a number of very complex rules - e.g. my locations.rules file which tracks locations for each family member using multiple methods (depending on the type of phone they are carrying) and carries out actions based on location etc is currently some 645 lines long, and works robustly.
As per my first post, it’s entirely possible I’m missing something. I see these channels listed in the UI, but the files in the config directory on disk remain empty. It’s unclear how I should refer to them in scripts.
Is the OH2 language substantially different than the 1.x version? Any chance you could PM me some examples?
Richard
No, the language is the same. Slight differences in implementation in that (a) we now no longer need to import org.openhab.* and (b) the interpreter is a bit less forgiving of sloppy coding (best to use the Designer which will highlight errors etc).
I’ve also pm’d you a rule file.
WRT your query on the channels and the config directory, as per Rich’s earlier post, the conf/items and the conf/things directories are for manually creating items/things. This allows both backwards compatibility for users coming from 1.8, who don’t want to recreate everything from scratch and for those power users that want to have static configurations that they can easily tweak. However, PaperUI based configurations actually write to a mapdb database (in the userdata/mapdb directory). I believe the intent is that OH2 provides a simpler configuration mechanism for new users, who then do not have to worry about item and thing files etc.
The ‘thing’ I have is a wall switch or a sensor or such. These things have various attributes (that OH calles ‘items’) that I care about.
I’m not saying that there should be no custom things. Just that the common case should be handled via autogeneration.
I use manually constructed groups, but they are not namespaces. In fact, I would call ‘groups’ something more like ‘tags’, but somewhat more difficult to use due to the need to define the group before it’s used. Also, the conflation between the model/view abstraction in items is weird, especially with groups.
I think this is one of the core shortcomings. There is a battery level. It means the same thing across all technologies. The home automation framework should unify the bluetooth and zigbee and zwave and whatever battery levels into one type of attribute comparable across technologies. Likewise for motion/door sensors, temperature/humidity/luminosity readings, dimmer levels, color selection, on/off switches, keypads, etc.
In my use case, it was an actual problem. Rules were taking several seconds to execute in the Rules DSL that only took milliseconds when re-coded in jython.
I traced the slowness in my use case to anything having to do with time. If the Rules DSL referenced the current time in any way, it was glacially slow.
Richard
No, the Rules DSL is largely unchanged at this point in OH 2. They did make it so you no longer need to explicitly import certain obvious things like State classes and Joda.
Probably the best place to look for some example rules I’ve written with explanations is my Design Patterns thread. Start at the bottom as I’ve updated some of the patterns as I learned or thought of new things to make them simpler.
Every programming language is really good at something, and the Rules DSL is really really good at looping through members of a Group. Once I realized the power of forEach, filter, and sortBy I was able to drastically reduce the complexity, increase the robustness, and improve the runtime of all of my rules. I quit measuring them but at one point I had reduced my lines of code by around 60%. I don’t think I have a single rule any longer that doesn’t fit on one screen.
I discovered that:
I was able to drastically simplify just about every aspect of my Rules, and the Rules DSL started to make sense. The only thing that got slightly more complex are the Items because now I need to create and apply lots of Groups to Items based on certain behavior but even that has its advantages because I only have to look one place (the Items files) to see and change what gets persisted to which database, add or remove Items from certain behaviors (e.g. to add a lamp to come on in the Morning I just add that Item to gMorningLights and now it will come on), etc.
You should see all of these concepts illustrated in that Design Pattern thread.
After making my first path through my rules applying these concepts, not only did my rules greatly simplify, I eliminated all but one lambda and all of my HashMaps. I simply didn’t need them any longer. And while I’ve not done this yet, know that you can dynamically add and remove Items to/from a Group inside your Rules. The changes won’t last past a restart but that could prove useful to you.
Now all is not completely rosey. I’d love it if I could trigger a Rule only once when one of the members of that Group receives an update (right now one update will trigger the rule N-1 times where N is the number of members of the Group). I’d also love a native way to get at the Item that actually triggered the rule rather than the hack I have in place to accomplish that. Also, I which everything were either a java.util.Date or a org.joda.time.DateTime rather than some places needing one and other places needing the other.
But over all, I think the Rules DSL excels at this sort of processing and will continue to recommend it and defend it. It’s a losing battle I’m sure but I’m OK with that.
Hey @llamahunter,
It is a shame to see you being so negative about openHAB 2 - I hope we will be able to convince you of its ideas.
After all, openHAB 2 is merely an evolution of openHAB 1 with the strong requirement to be as backward compatible as possible. This certainly comes with pros and cons, but I think it is the right decision not to throw the past achievements away.
Because Items always have been the means to describe your “objects” (doors, windows, rooms, christmas tree) and not your “devices” (magnet contact, temperature sensor, outlet). A “Thing” in openHAB 2 is merely a structured syntax to express configuration strings for your binding. You might want to read http://docs.openhab.org/tutorials/migration#understanding-things to understand the details here and especially to learn where this is coming from (being an evolution of openHAB 1).
This is still being worked on: scriptable automation by smerschjohann · Pull Request #1783 · eclipse-archived/smarthome · GitHub
But once it is ready, it will be so much better than any rule engine before in openHAB 
Feel free to join in the discussion, review and testing there - the main reason why it all takes so bloody long is that I am so terribly short on time for so many different topics, so blame me, if something is still missing, which used to work in openHAB 1…
Regards,
Kai
No, these Things are represented as an Item in openHAB. An Item is not an attribute. An Item is a proxy, an avatar, an abstraction, pick your term, of the Thing internal to openHAB. As far as persistence, rules, sitemap, event bus, etc. is concerned, there are only Items, there are no Things. The interface between openHAB and the real world takes place where Things are mapped to Items.
In my experience with my own setup and helping others on this forum, these “custom” things are the common case. And as @smar has indicated, apparently OH already does this to a large extent.
openHAB/ESH is not architected like that. It “unifies” one layer down at the Number layer, not at the “what does this number represent” layer. One can argue about whether or not that was an appropriate design/architecting decision, but that is the way it is. Per the discussion above about Items, a Number is a Number, what that Number represents is not known by openHAB. I’m not sure how easy this would be to implement. This is one of those things that sounds really simple when said but when you start to go into how you make it happen and work it gets really complicated and difficult.
For one thing this would impose a huge amount of work on the binding developers. No longer is it sufficient for them to simply deal with the data type of the information, now the need to maintain a database of all potential devices that the binding can communicate with that maps these individual parameters to what they mean. For something like zwave or zigbee this can be pretty straight forward. For many if not most of the rest this may not even be possible.
Then there is the question of where do these categories stop? Would an infrared and sonic motion sensor be in the same category? Who comes up with them all? Lots to think about…
I would be interested to see that rule. I’ve never encountered a rule that took seconds to run that didn’t have a sleep in it for seconds. I’d like to see why. Even with the speed tests others have run, we are talking about the difference of hundreds of msec Rules DSL to tens of msec Jython. An order of magnitude longer yes, but both are still fast enough for almost any HA use case (except sending “simultaneous” commands to multiple switches)…
How were you referencing Time? Accessing and doing manipulations with Time is vital to many if not most of my rules and I’ve not seen that behavior. Something very weird is going on and it is not necessarily a Rules DSL problem directly.
