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.
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?
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
gpio:sysfs=/sys
# 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
gpio:debounce=0
Hey,
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.
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.
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…
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)
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:`
JAVA_ARGS=-Djna.boot.library.path=/usr/lib/jni
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:
USER_AND_GROUP=root:root
And then edit /usr/lib/systemd/system/openhab.service and set the following:
User=root
Group=root
So basically I just want my GUI to show up as in 1.8:
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…)
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.
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
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
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…)
[/quote]
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.
[/quote]
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.
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.
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.
ok,
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"
when
Item Contact_BathroomR changed from OPEN to CLOSED or
Item Contact_BedroomR changed from OPEN to CLOSED
then
if(Light_Bathroom.state == ON){
sendCommand(Light_Bathroom,OFF)
//LogInfo("Kitchen", "Switching to OFF")
}
else {
sendCommand(Light_Bathroom,ON)
//LogInfo("Kitchen", "Switching to ON")
}
end
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.
