Manually Installling OH3 - filesystem

  • Platform information:
    • Hardware: armv7l
    • OS: Linux raspberrypi 4.9.41-v7+ #1023 SMP Tue Aug 8 16:00:15 BST 2017 armv7l GNU/Linux
    • Java Runtime Environment: openjdk version “11.0.3” 2019-04-16 LTS
      OpenJDK Runtime Environment Zulu11.31+16-CA (build 11.0.3+7-LTS)
      OpenJDK Client VM Zulu11.31+16-CA (build 11.0.3+7-LTS, mixed mode)
    • openHAB version: 3.1.0 - Release Build

Hey, I’ve installed OH3 manually (Didn’t have an option to flash my SD card at that moment) and everything works well, I’m able to control my lights, add rules, items, etc,… HOWEVER, whenever I see a guide that requires code, it always points to non-existing files for me. I don’t have the env variables OPENHAB_CONFIG or any other, all my files are located based on this information: openHAB on Linux | openHAB

Although everything seems to work, and the file locations seem to be at the right place (using the manual installation paths), I never found the .items files, .rules files nor other files described in all of the guides.

Am I missing something?

Thanks a lot for any help!

Since you have created our items and rules via MainUI you won’t have/ need such files.
The .items files were used to create items before OH3. In OH3 you can copy the content of an (old) .items file to create your items, however they are not stored that way.
The same goes for the .rules files, they were used before OH3 for the DSL rules. In OH3 you can still use the old files, however new rules ( created via MainUI using any of the supported language) are not stored in such files.

Thanks! So if I understand you correctly, the files do NOT exist in those places anymore, BUT if I see an older guide using actual code to define items/groups/rules/etc I could just follow along with the guide and create those files manually and expect the mainUI to update accordingly?

You could…However, why creating an deprecated file at all? Creating items via MainUI you’re assured to have no syntax errors!
As for .items files, they are not read by the system, however there is a sub page on MainUi onto which you can paste the CONTENTS of an .items file.

just wondering, why are you referring, that using files is as a deprecated approach, any kind of link to the documentation would be appreciated.

None of the textual configuration files are depreciated. They all still work in OH3 just as they did with OH2 and many people have successfully transferred over from one version to the next and kept their textual configuration.

As opus has said, there is little NEED to do any of the configuration via text files anymore, the MainUI can handle nearly everything and those few things it can’t there are reasonable alternatives. There are several places where mixing of text-based configurations and MainUI configurations causes some problems, so it is probably best to just pick one method and stick with it unless you really know what you’re in for and how to work around those known issues.

All those textual configuration files are stored in individual directories within the /conf directory which should be in root directory of your manual install. If you are looking for where the configurations created by the MainUI are stored, those are not stored in the same location. Those can be found in the /userdata/jsondb folder. It is occasionally instructive to open those files and look at them but be careful NOT to edit them directly except under the direst of circumstances and with the greatest of care.


That’s really informative! So in order to follow older guides, I can simply combine those 2 methods or approaches. It looks like there’s no better alternative yet right?

I’ll try to be more direct here… I’m trying to follow this awesome guide: Magical light scenes but it seems that I have to edit some files in order for it to work, is that true?

Better than combining MainUI and textual config (again there are place, particularly with items where that actually causes some known bugs) is just to understand how to convert what you see in the textual based guides into the MainUI configs.

For example: all the DSL rules that you see in docs and on the forums can be easily entered in via the MainUI. The rules look like this:

rule "Rule Name"
    Some Event
    Do something
    Do something else
    Don't for get to log the results

In the MainUI when you create a rule, the “Rule Name” goes in the Name field (there’s no need to change the UID unless you have a specific pattern or use for it). Then “Some Event” part of the When is configured separately by using the Add Trigger field under teh When heading. And finally you come to the Then. This is the part that trips up many new users. When you click on the Add Action field you can either configure some actions (simple item changes, effects on other rules, audio events, etc.) or you can run a script. When you select run a script it gives you the change to select the language (in this case we’re talking about DSL, but you have to be careful if you’re reading guides on the forums as there are several other options as well). When you select the DSL option you are taken to a simple text editing popup and there you can paste in the line ONLY from the THEN section of the rule (you’ve already accounted for the other parts).

The specific guide you’ve linked to is a particularly complex one but you can still do all the config via the UI once you understand the equivalences.

1 Like

I was able to convert some of those textual based commands to UI based but some, I could not, for onstance: scene selection items, where I want to select a specific scene that is defined in the philips hue app.

IMHO, I think the code and the UI should be able to live together. + If the code was not actually code but a configuration file, for example, YAML/JSON file for each item/channel, etc,… it would be super easy to add plugins/widgets/whatever.

Of course, the UI should be able to save and read those configuration files to keep the UI and the FS updated.

I have mixed methods before (binding devs are expected to test and provide examples in documentation) and it does work, however it is far more complex and it is not for everyone. For the reason of getting help on the forum and troubleshooting it really is not a good idea to mix them IMHO but it does work from what I have tested.