Just to provide a bit more detail and some insight for how we got to where we are and where we are going…
If you do it in PaperUI you can’t touch it in ESHD. If you do it in ESHD, you can see it in PaperUI but you cannot modify it there.
Many people, myself included, use PaperUI to manage automatically discovered Things only and all Items, Rules, etc are managed in the text files configurations using ESHD.
The /var/lib/openhab2/userdata folder is Karaf’s “working” directory. Changes made using the UIs as well as persistence data stores and runtime configuration (e.g. logging config) end up here. Parsed versions of the stuff in the conf directory end up here as well.
The text based config, the stuff that ESHD deals with, reside in /etc/openhab2. This is the only directory ESHD can deal with.
Those instructions should be updated to make it more clear that the /etc/openhab2 or <openHAB2 Home>/conf folder for manual install is what is meant.
Now for where is all of this going. PaperUI is in the process of undergoing rapid development. The intent seems clear that eventually it is intended to be fully feature complete so one need never mess with the text files or ESHD if they do not want to. Clearly PaperUI has a ways to go in this regard but if you had seen it only three months ago you would see how far it has come.
That being said, PaperUI is not required. Theoretically one can do all the configuration and management of everything using the text based files (I say “theoretically” because the syntax to manually define Things for zwave are not documented but even in those cases you can manage the automatically discovered Things in the Karaf console).
This means that the main focus of the developers appears to be on improving the functionality and capabilities of PaperUI and ESHD is not getting a lot of attention. Couple that with the eventual goal to do away with ESHD in favor of a web based editor suite and the continued development of the Experimental Rules lead me to believe that we will probably need to plan on limping along with this bifurcated config approach and a slightly broken IDE until all of these things mature.
This is a time of transition for OH and there are a lot of things that are transitioning.
Right now, ESHD is the only game in town. Use the 0.8 version for now. @ThomDietrich, clearly that issue has not been fixed yet and it seems like it might be awhile. Perhaps removal of that line recommending using the nightlies should be removed until that issue gets fixed.
There is no tool that will test logic. ESDH does check syntax and, assuming you are using text file defined Items, it is Item aware (so if you have a typo in your Item name in a Rule it will detect that).
Finally I’ll leave you with a warning. The Rules DSL is challenging for a lot of developers to get their head around. In particular, the Rules DSL is very unsuited for developing in an OO or procedural style. It doesn’t provide easy ways to set up data structures. And it unfortunately does not provide meaningful errors in many cases. When you start working with Rules I recommend stepping back and looking for another way to code something if it feels like the language is fighting you. Look at the Design Pattern postings for some good canonical approaches to solve some common problems. And hopefully soon the JSR233 Binding will finish migrating to OH2 which will let you code Rules using Jython or JavaScript.
Personally, despite its flaws, I find the Rules DSL to be particularly well suited for home automation and when one leverages all parts of OH in the Rules (store state in Items, use Groups for data structures, Expire Binding, and Persistence) one can make very short and clear rules.