MIgration to OpenHab2

Tags: #<Tag:0x00007f433e68e218>

Hi, I am trying to migrate to OH2 from OH1 but I am in the dark,literally.

  1. Downloaded openhabian
    2: Wrote image to SD card with win32 image writer
  2. Plugged it in and went to bed
  3. went to my router to find ip in the dhcp client list(XXX.X.83)
  4. Used putty to log on to the pi, with the pi user, should I rather log on with the openhabian user??
  5. Sudo openhabian-config, enable samba
    7.went to \OPENHABIANPI and copied over, sitemap,items,persitance,transforms and rules
  6. changed the name of the sitemap to _defualt.sitemap and edited first line to sitemap _default label=“Little China”
  7. sudo reboot
  8. Went to http://XXX.XX.1.83:8080/classicui/app Everything is there except of icons for lights
  9. Went to and enable GPIO binding

But my GPIO items does not work, all my items shows up in the items… Howeverr no things shows up:

I also tried to add the user to the GPIO, see below
9:00:24] pi@openHABianPi:~$ sudo adduser openhabian gpio
[sudo] password for pi:
adduser: The user openhabian' does not exist. [09:00:56] pi@openHABianPi:~$ sudo adduser openhab gpio adduser: The groupgpio’ does not exist.

First I’ll direct you to:


Next, the GPIO Binding is a 1.9 binding. Only 2.0 bindings use Things. All 1.9 bindings are configured and used just like they were for openHAB 1.x, no Things.

I’m not sure why the GPIO group doesn’t exist. Perhaps with the minimal install openHABian doesn’t set up the GPIO related groups. @ThomDietrich, can you shed any light on openHABian and GPIO?

1 Like

THanks @rlkoshak, So is prefered instalation of GPIO binding not using the paper UI, but rather download the jar and drag it over to addon folder or the last method add it to the comma seperated list in the config file.

I followed your great tutorial:

Now select “Extensions” from the left and browse or search for each of the bindings and add-ons you currently use. Make note of those that do not appear in the list. Do not install any binding that has a version 2.0. If there is not a 1.9.0 version we will install the binding manually (see below).

I also noted that nothing apeared in the service folder for GPIO or NEtatmo binding(only for the dmx binding)

Once a binding or add-on is installed, it will create a <openHAB 2 conf>/services/.cfg

But for GPIO no change of default setting is needed, however I made it explicit…
################################### GPIO Binding ######################################

# Optional directory path where "sysfs" pseudo file system is mounted, when isn't
# specified it will be determined automatically if "procfs" is mounted

# Optional time interval in miliseconds when pin interrupts are ignored to
# prevent bounce effect, mainly on buttons. Global option for all pins, can be
# overwritten per pin in item configuration. Default value if omitted: 0

Furter on my /etc/default/openhab is empty, shouldn’t this contain java and group settings??

the first thing I want to mention is what can be found in this and other threads: The GPIO bindings doesn’t seem stable and often not working as expected. I would recommend to not use it. If you want to interact with gpios, an alternative approach is an external application and the exec binding.

With openHABian (so more precisely with a minimal Raspbian) there is no gpio group. What would you need it for? Last time I checked the gpio pins belong to root. Please check openHABian hassle-free openHAB Setup
You will need to do some testing, I can only help as much.

The binding is installed. Rich was just telling you that (because it is a 1.x binding) you will not see any Things in the inbox. Just start configuring your items in config files as you know it from openHAB 1.8 / as described in the wiki article.

There is no openhabian user and non is documented in the openHABian instructions.

Samba is enabled by default.

This is not needed.


The binding config (if you want to create it) has to be called /services/gpio.cfg and inside you need to in return remove “gpio:” from all config lines.

No. What makes you think that?

OK, Was a bit unsure what of all the menu in openhabian-config that was enabled or not so I ran it again,( same for karaf…) (Maybe add a note on the menu item behind the item such as"(default)" for those that does not need to be rerun, differs from mqtt etc that are not installed on first run…

http://docs.openhab.org/tutorials/migration says clearly you need to change it in case you want it to autorun in classic UI

If you previously used default.sitemap as your file name so you could skip the ?sitemap= part you must now rename the file to _default.sitemap and change the very first line of the file to read sitemap _default label="<sitemap name>.

I think there is no gpio in any config file except of gpio.cfg, the question is this file needed at all? Since I am not doing any changes to defaults value(debounce and sys location)

On the wiki for GPIO :

Linux-based OS with GPIO driver loaded (check whether exists directory /sys/class/gpio), usually it's compiled into the kernel for all recent boards which exposes GPIOs
Yes RPI does

Mounted sysfs pseudo file system, the mount point can be:
Automatically determined if procfs is mounted under path /proc, this is the default path in almost all configurations

Yes RPI does

Manually set in openHAB configuration file, key gpio:sysfs

Root privileges, openHAB should be run under "root" account.
Have no idea about how openhabian is run…

Alternatively you can add the user "openhab" to the usergroup "gpio", if your distribution (like rasbian) does have such group.
sudo adduser openhab gpio 

Done that

So the question is do I need to do this?

  ` Some manual configuration may be needed. The following edit to /etc/default/openhab may be necessary (see discussion above in Prerequisites section). If needed, set:`

The JAVA_ARGS edit may not be necessary, and could cause OpenHAB to crash. If it does, simply undo the edit and restart OpenHAB.

If you chose above to add the openhab user to the gpio group, then you shouldn't make the changes below to run as root. If you did not add openhab to the gpio group, make a further edit to /etc/default/openhab:

And then edit /usr/lib/systemd/system/openhab.service and set the following:


So basically I just want my GUI to show up as in 1.8:

and not like this

I guess this is due to the fact the netatmo binding is in version 2.0 and does have things unlike the gpio and dmx binding(I only use those three for the moment…)

Good point. Will look into that.

Ah I see, there is “your problem” / my misunderstanding. ClassicUI is a relic from openHAB 1.8 and will not stay in openHAB 2 long. If I remember correctly it will be removed before the release of openHAB 2.0 final. You should concentrate on BasicUI, the new and in many ways better UI.

You do not need the gpio.cfg file if you stay at defaults, yes.

Regarding all the gpio stuff: I have no personal experience with it and can not help there. If you want openHAB run as root you can configure that in /usr/lib/systemd/system/openhab2.service. In order to set additional JAVA_ARGS, please follow: http://docs.openhab.org/installation/linux.html#privileges-for-common-peripherals
Still I would not recommend going this way.

The last screenshot tells me that you are not looking at the right sitemap. Your rooms etc. should be there, even if the items are not yet connected to hardware.

Thanks, in habmin they both show up, whats the url to the _defaultOne?

However I started to remake the UI, do you recommend to use habmin, basic UI or any other?

My guess:

I’m using BasicUI and am pretty happy with it. However, my home automation is mostly concentrated on automation and the UI is mostly there to be shown to guests :stuck_out_tongue_winking_eye:
If you are looking for something more fancy, I believe HABPanel is the way to go. I have no experience with it.

No, installation through PaperUI, or adding it to addons.cfg, or installation through the Karaf console are the preferred methods of installation. But once installed it works just like it did in OH 1.x with the one minor difference that it now has its own cfg file rather than everything going into openhab.cfg.

Personally, until they finish fixing the problem where all bindings need to be reinstalled after an upgrade I’d recommend using the addons.cfg file.

If you had to put something into openhab.cfg to configure either of these bindings (some bindings do not have any required global configs with everything being defined in the Item) then create the file (i.e. gpio.cfg and netamo.cfg) and copy the parameters for that binding that you have in openhab.cfg into the appropriate file. Then remove the first part of the parameter. For example, gpio:someParameter=foo becomes someParameter=foo in gpio.cfg.

Since none are required then that is probably why it didn’t create a file for you. If you pasted in the contents of your gpio.cfg file, you need to remove the gpio: part of the parameters.

I don’t know the answer to this. It is possible that OH 2 works differently in regard to defaults.

Or MQTT :slight_smile:

Actually for some time (at least since the tail end of weezy, certainly since jessie) raspbian has added a gpio group so you no longer need to be root to access the pins. There is also an spi and i2c group for access to the pins in those ways.

but it is convenient to avoid having to set the default sitemap in the UIs. Though after the last update I’m not certain that works any longer (i.e. renaming the sitemap to _default so Basic and Classic pick it up instead of the bigo list of Items default).

OH 1.x used to put stuff in there and it was one way users could change the default ports and whatnot.

Per my comment above, I’m in the process of running some experiments to see if that instruction has become incorrect with the latest builds. That used to work at least up to build 600 but something went wrong the last time I updated and it no longer worked. Once I figure out what the deal is I’ll open an issue and update it accordingly. Sadly, the perennial problem is the docs lag behind the implementation, particularly with a beta product.

If you have no changes to make you don’t need this file, though it is useful to have it there with the parameters commented out or set to the default so later on if you do need to change something you won’t have to research what to put there.

It is run as the openhab user.[quote=“skatun, post:6, topic:17469”]
I guess this is due to the fact the netatmo binding is in version 2.0 and does have things unlike the gpio and dmx binding(I only use those three for the moment…)

Actually this is related to and confirms my suspicion that naming your sitemap _default.sitemap no longer works for making it the default.[quote=“ThomDietrich, post:7, topic:17469”]
If I remember correctly it will be removed before the release of openHAB 2.0 final.

Why? I can understand stopping development on it but it is perfectly serviceable as a UI. Seems a shame to just throw it away. Though I do agree, Basic is in many ways much better.

In my opinion Habmin is more of an administration UI and less of a user UI so, like @ThomDietrich, I’d recommend using Basic or HABpanel for the every day user interface.

That’s fixed

No not completely. The content just moved. As I said earlier:

EXTRA_JAVA_OPTS will be added to JAVA_ARGS in a subsequent script.

Yes. The exec binding and MQTT are both great ways to reach software or hardware outside the openHAB ecosystem. Your sensorRepeater looks great! I didn’t know which level it reached over time. :thumbsup:

Fact is, this is no default in the minimal system I am using as the base for openHABian. I could however add this to the setup script. I would need to know the exact definitions from a raspbian system for that…

I’ve been experimenting with sitemap names once myself. At least for BasicUI or the connection with the Android client, I can tell you for sure, that you can name the sitemap just as you want. The Android App remembers your selection and for BasicUI you just need to set the default sitemap to the name of yours in basicui.cfg. Now I saw that @skatun doesn’t have such a file in his services folder. Strange. You should add it: https://github.com/openhab/openhab-distro/tree/master/features/openhab-demo-resources/src/main/resources/services

I believe he meant to say HABPanel as he also posted screenshots of it. I agree that Habmin is no usage UI and therefor unfitting for the asked purpose.

After rethinking this, I agree that we need a solution for this problem. I can think of a solution in both openHABian or in the gpio binding itself. Everyone, please take part in the discussion at https://github.com/ThomDietrich/openhabian/issues/39#issuecomment-264148885

for time being untill we are able to fix the gpio issue i tried doing this without succsess:

Switch Light_Module1 “Module 1” (Group_LivingRoom,Lights,Group_LightLogging) {exec=“OFF:sudo sh -c ‘echo “1” > /sys/class/gpio/gpio12/value’”}

shouldnt that have worked since it work in cmd prompt?

Well, because OH is running as the openhab user there is a whole host of things that could have gone wrong.

  • openhab is not a member of sudoers
  • openhab is not configured to be allowed to sudo that command without a password
  • openhab only uses the default path and may need the full path to echo
  • the Exec binding sometimes requires spaces be replaced with @@
  • OH or the Exec binding is interpreting the “>” to mean something else so the full command isn’t making it to the shell

I highly recommend moving the call to a Rule using executeCommandLine so you can print any error messages that may result to the logs.

val results = executeCommandLine("cmd", 5000)
logInfo("test", results)

This will often point you straight to the problem.

being not so brilliant with linux, how can I log onto the openhabian with putty and the user openhab, I always get accsess denied when typing in habopen as password. I think this will help me/us to find out if the openhab user have the right gpio permissions.

I think we might have to unexport all gpio on startup of oh2, just an idea from what the log says:
23:34:52.894 [ERROR] [ab.binding.gpio.internal.GPIOBinding] - Error occured while creating backend object for item Contact_BedroomL, exception: /sys/class/gpio/export

You can’t. The openhab user is purposely configured to be a non-privileged/limited user. This is a best practice for all services/daemons that run on Linux because if for some reason the software runs amok or it gets hacked into the amount of damage that can be done is greatly limited.

In short, the openhab user does not have a shell so you cannot log into it.

However, you can run:

sudo -u openhab /bin/bash

This will give you a shell running as the openhab user. However, this shell will not be the same as the environment that openHAB is running in so anything done there may/may not bear any relation to your actual problem.

That being said, as openHABian is configured right now, I can tell you that you need to run openHAB as root in order to access the GPIO pins. There was some discussion a week or so ago about making openHABian work more like default raspbian and adding a gpio group and adding openhab to that group but I’d be surprised if that has been acted upon yet.

So, you will have to edit /etc/systemd/system/openhab2.service and change the user to root if you want to use the GPIO binding.

Personally I prefer to use something external to OH to interact with the GPIO. I find this approach cleaner and better able to expand to support remote Raspberry Pis in a consistent manner.

Yeah, I am working together with Tommy to see if we can get gpio to work without running as root, so i added openhab to the gpio group, but still struggle with permission to export it. Do you have an example of how to use ur python script. I suppose you skip the gpio config in item files, copy the python file into script catalog and that i need to rewrite and add some rules:

rule "Update bathroom light when button pressed"
    Item Contact_BathroomR changed from OPEN to CLOSED or 
	Item Contact_BedroomR changed from OPEN to CLOSED
if(Light_Bathroom.state == ON){
		//LogInfo("Kitchen", "Switching to OFF")
	else {
		//LogInfo("Kitchen", "Switching to ON")

My particular script is a server in its own right which publishes GPIO state changes using MQTT or using the OH REST API. It also receives commands from OH using MQTT to toggle or change the state of a GPIO pin.

You will need to set up MQTT if you want to control the pins and change your Items to use MQTT. Look at the default.ini file for how to configure sensorReporter.

If you want something more lightweight and direct, you can look at the files that start with rpi for how to interact with the GPIO pins and use the Exec binding to call some new scripts you write using those as an example.

I forgot to mention that I am currently running gpio with root and that works just fine.