I just set up OH2 (latest official docker image) after having some time off from home automation since I last played with OH1 two years back. I have several z-wave devices around the house and found it a bliss to get up and running in a short time with PaperUI and automatic discovery of things and items.
The PaperUI does, however, lack a lot in the rules/scripting department, so when I had all devices working I decided to expand my configuration options by employing the Eclipse SmartHome Designer which I assumed would be very familiar to how OH1 was administrated.
However before I got to that I discovered, to my surprise, that the openhab/conf directory was virtually empty. None of my auto-discovered things/items nor test-rules definitions were there, just a bunch of readmed.txt placeholder files. As it turns out they are all stored in the (new to me) jsondb.
Quickly after that, I also discover that the SmartHome Designer works only with files in the openhab/conf folder, not the jsondb were PaperUI puta it’s things.
So…
PaperUI has a low bar to get started, but too limited rules editor
ESHD supports my rule needs, but all manual config of bindings, etc
I don’t require PaperUI nor ESHD, I just want discovery like in PaperUI items and a proper rule editor like ESHD.
I just want the good of both, but right now it seems that I have to pick between 2 half-solutions.
Does anyone have a solution to that?
I found this post which suggests that no (or not much) development effort is going into ESHD anymore, and that PaperUI is the future.
But right now PaperUI does not match ESHD when it comes to advanced configuration.
Is there any kind of workaround for this, or is OH2 in a kind of limbo when it comes to auto discovery and rules?
No. OH 2 is in a transition period moving away from a lot of OH 1 text based files way of doing things and towards a PaperUI based way of doing things. It is being worked but progress is not as fast as many would like.
You can look at the Experimental Rules Engine for a more integrated way to write rules in an editor that is aware of all the stuff in the JSONDB and HABPanel which is quite mature already and highly recommended as an alternative to sitemaps. I think you still have to configure persistence using .persist files. Also, if you use any 1.x version bindings, you are stuck defining those items in .items files as well. But the Experimental Rules Engine should be fully aware of those Items as well as those in the JSONDB.
Now I will say that you are not required to use PaperUI at all. You can do discovery and management of Things in Habmin (alternative UI), the REST API, and through the Karaf console if you don’t want to use any UI at all.
You also might be interested in the JSR223 add-on which would let you write rules using JavaScript, Jython, or Groovy and utilize the editor/IDE for your language of choice. I’m not sure that those will be Item aware though.
But to summarize, the Experimental Rules Engine is where all the work is being done. ESH Designer is not likely to receive too many updates going forward. There is a Visual Studio plugin that is pretty good, but lacks strict syntax checking.
I think what most people do these days (myself included) is let PaperUI or whatever do the autodiscovery of your Things, define all Items in a .items file, and use ESH Designer for rules development. Or you can just ignore the errors when you refer to an Item that is in the JSONDB instead of a .items file. Or switch over to the Experimental Rules Engine.
