Config storage, Next-Gen rule addon


New to docker containers and OpenHAB and java and that sort of scripting and rule creating. I am leaving my LMCE now and venture what is out there. And despite my fear of java I just couldnt stop thinking about openhab… Feels more like home…

Though I was almost put off by the fact that there was not even a “tool” for creating rules (sunset, sunrise basic stuff) until I found the experimental one :smiley:

I had a few issues just getting openhab seeing my usb port hence you will see that the container I run now is using sudo and two device links.

I also do start the container as a oneliner as I want to make sure I have all the options and switches properly set before letting systemd help me.

My question is where my config that I create using the PaperUI ends up? Especially the rules that I created with the awesome Rule add_on ?
Experimental indeed but I would have assumed they end up in the
“/home/openhab/conf/rules” directory. But there is nothing there… :confused:

I am abit afraid now to do more stuff as I don’t want to loose the progress…
I am running the Ubuntu 18.04 server with “default docker”
sudo docker run --name openhab -p 5080:8080 -p 5443:8443 -p 5081:8081 --device=/dev/serial/by-id/usb-0658_0200-if00 --device=/dev/ttyACM0 -v /etc/localtime:/etc/localtime:ro -v /etc/timezone:/etc/timezone:ro -v /home/openhab/addons:/openhab/addons -v /home/openhab/conf:/openhab/conf -v /home/openhab/userdata:/openhab/userdata -v /home/openhab/.java:/openhab/.java -d -e USER_ID=998 -e GROUP_ID=997 -e EXTRA_JAVA_OPTS="" -e EXTRA_JAVA_OPTS="" --restart=always openhab/openhab:2.4.0

Rules, Things, and Items that are create through the REST API (e.g. using PaperUI) all get stored in $OH_HOME/userdata/jsondb.

It looks like on your host that path would be /home/openhab/userdata/jsondb.

For the serial device issue, the most straight forward approach is to:

  1. create an openhab user on your host machine
  2. add that openhab user to the dialout group which will give it permission to read/write to serial devices
  3. pass the uid/gid of the openhab user into the container like you already are doing.

This is what I did and I did not need to do anything else special to give openHAB access to my serial devices.

NOTE: you may have a problem as I think the second EXTRA_JAVA_OPTS will overwrite the first one. You should use


Indeed there they are. :slight_smile: Though the format is “json” hmm… But I think I can use the thoughts from there and create my own rules.

As eventhough there where Many threads of rules regarding sunset,lights etc I never quite understood the different elements of the rule as such. Like the item, if it was the name, alias or id… I see now it’s the Id…
Need to read up on the design guidelines first. Maybe copy a few of your rules also that you posted :slight_smile:

Regarding the user its strange. Are you running bionic beaver and the included Docker from standard repo? I found one thread or Blog where a guy had my exact issues and he had to change to a different docker as there apparently some bug regarding exposing serials to the container.

To me it seems(I have stopped playing, it works… dont touch haha!) that what made it work was me doing a chmod 777 of the /dev/ttyACM0.
This is really bad I know, though my openhab user belongs to the dialout group.
“openhab : openhab tty dialout audio”
and from what I have read I do specify in my docker run command that the user should be openhab, so it must be that bug.
Though changing docker is not something I will do now. But I think it’s time to make sure this thing starts when the server is rebooted and what not…
Thank you once again for the quick reply!


You’re going to have to understand all of that with the Experimental Rules Engine too. If you plan on hand writing these Rules you will be much better off sticking with Rules DSL or JSR223 Rules.

Definitely read the Concepts section and Items section of the Docs. There is no such thing as an “alias” or “id” in reference to Items. There is only it’s name and that is what you use in your Rules.

I’m using the “official” Image from DockerHub with no modifications. Here is the Ansible task I use to deploy it (it should be easy to map that to the actual docker run command.

- name: Update openHAB docker
    detach: True
      - "/dev/ttyUSB0:/dev/ttyUSB0:rwm"
      - "/dev/ttyUSB1:/dev/ttyUSB1:rwm"
      EXTRA_JAVA_OPTS: "-Xbootclasspath/a:/openhab/conf/automation/jython/jython-standalone-2.7.0.jar -Dpython.home=/openhab/conf/automation/jython -Dpython.path=/openhab/conf/automation/lib/python"
      CRYPTO_POLICY: unlimited
    image: "{{ openhab_version }}"
    log_driver: syslog
    name: openhab
    network_mode: host
    pull: True
    recreate: True
    restart: True
    restart_policy: always
    tty: yes
      - /etc/localtime:/etc/localtime:ro
      - /etc/timezone:/etc/timezone:ro
      - "{{ openhab_data }}/conf:/openhab/conf"
      - "{{ openhab_data }}/userdata:/openhab/userdata"
      - "{{ openhab_data }}/addons:/openhab/addons"
  become: yes

That change will almost certainly become unmade the next time you reboot the machine. Files in /dev/ttyAMCM0 are not “true” files in that they exist somewhere on your hard drive.

Notice above that I do not specify that the user to run under is openhab. I think the that kicks everything off needs to start as root but then it su openhab to actually start openHAB running. That same script also makes sure that the uid/gid of the user it starts openHAB running under matches those passed in as those environment variables. The important thing is that the UID and GID passed in to the container are for a user (doesn’t matter what it’s called) on your host that is allowed to read/write to the serial device files. On an Ubuntu machine that is usually done by adding the user to the dialout group. On an RPi that group may be something else like “tty”.

Just add the --restart=always to your docker run command.

Wow! Thank you! so many new things, “rules DSL” and JSR223 has flown by when scanning the threads, never really thought I would have to dig into that as well :smiley: haha!

Ansible task sounds neat, will google this as the “–restart=always” didn’t do much in the last reboot. Systemd works for my other container but maybe I shall try the ansible. :slight_smile:
indeed, having to change the rights for the /dev/ after every reboot really is suboptimal.