Do you get any messages in openhab.log to say that the pins are being allocated at boot? My messages are one per pin
2016-09-26 12:37:18.083 [INFO ] [penhab.io.gpio.linux.GPIOLinux] - registering pin with number '26'
The item for this is
Switch DoorBell { gpio="pin:26 activelow:no" }Hi Kevin,
Sorry for late reply but I was out of town for a few days.Thank you for your help.
Here is what I have in my logs with the default bindings (those that come with Openhab package)
22:25:05.512 [DEBUG] [o.o.b.g.i.GPIOBindingActivator:30 ] - GPIO binding has been started.
22:25:05.812 [DEBUG] [i.internal.GenericItemProvider:341 ] - Start processing binding configuration of Item āPB_GF_Garage (Type=ContactItem, State=Uninitialized)ā with āGPIOGenericBindingProviderā reader.
22:25:05.828 [DEBUG] [i.internal.GenericItemProvider:341 ] - Start processing binding configuration of Item āLD_GF_Garage (Type=SwitchItem, State=Uninitialized)ā with āGPIOGenericBindingProviderā reader.
But nothing else after so i guess the assignment of the GPIO binding did not work properly (or never ended).
Kind regards
Putting mine into debug and rebooting I get
10:19:11.684 [DEBUG] [o.o.b.g.i.GPIOBindingActivator:30 ] - GPIO binding has been started.
and then
<<<<one message per GPIO Item like the one below>>>>
10:19:11.734 [DEBUG] [i.internal.GenericItemProvider:341 ] - Start processing binding configuration of Item 'DoorBell (Type=SwitchItem, State=Uninitialized)' with 'GPIOGenericBindingProvider' reader.
and then
<<<<one message per GPIO Item like the one below, and not in the same order as the messages above>>>>
10:19:12.762 [INFO ] [penhab.io.gpio.linux.GPIOLinux:270 ] - registering pin with number '26'
<<<<many messages like the one belowrest of the GPIO Items, one message each>>>>
The next question is what version are you using of the Bindings? You need TWO files, my working ones are called:
org.openhab.binding.gpio-1.9.0-SNAPSHOT.jar
org.openhab.io.gpio-1.9.0-SNAPSHOT.jar
I suspect you may have only one of these present
Hi Kevin,
Unfortunately, I have both in my addon folder:
org.openhab.binding.gpio-1.8.3.jar
org.openhab.io.gpio-1.8.3.jar
Same result if I change with version 1.9.0.
What is strange is that generally, I read many people had problems with only the Contact but at least the Switch were OK. In my case none of them works.
To answer your question about my version, I have
java version ā1.8.0_65ā Javaā¢ SE Runtime Environment (build 1.8.0_65-b17)
Linux version 4.4.22+ (dc4@dc4-XPS13-9333) (gcc version 4.9.3 (crosstool-NG crosstool-ng-1.22.0-88-g8460611) )
What do you get from the command
cat /etc/*-release
I get
PRETTY_NAME="Raspbian GNU/Linux 8 (jessie)"
NAME="Raspbian GNU/Linux"
VERSION_ID="8"
VERSION="8 (jessie)"
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL=āhttp://www.raspbian.org/RaspbianBugsā
Iām on the exact same version of Java
Hi Kevin,
Apparently, we have exactly the same version. This is what I get:
PRETTY_NAME="Raspbian GNU/Linux 8 (jessie)"
NAME="Raspbian GNU/Linux"
VERSION_ID="8"
VERSION="8 (jessie)"
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL=āhttp://www.raspbian.org/RaspbianBugsā
I guess the only things left are either permissions, or something outside Openhab holding the GPIO Pins, or a hardware fault.
I run Openhab as Root which might be worth temporarily trying. I also installed Jessie as a new install, maybe its worthwhile getting a new clean image of Jessie + Java + OH and seeing if that works. A quick google suggests there may be permissions issues with GPIO after upgrading to Jessie from Wheezy.
If I had this problem Iād get a new SD Card and create my own image of Jessie, then test GPIO, then add Java & OH 1.8 then test again. Interestingly enough there is work being done elsewhere on the forum creating OpenHabian openHABian hassle-free openHAB Setup and the last post asks about getting GPIO to work so perhaps there is an issue that is about to be documented on that thread.
Hi,
Iāve had the same problem, I copied the 1.9.0 files into the addons folder and it works until one or two switching, but after that it stops displaying the value. I used the pin 17.
After I changed the pin to 27 and removed the debounce option and now it works.
HTH,
Szabolcs
Iāve found the debounce option to be tricky to get right with contacts. The devices on PIN 23, 24 & 25 have been my tricky ones, debounce is globally set to 100 which seems to be a good compromise. Havenāt had any problems with the outputs as long as I reset the items to OFF on boot before I apply power to the relays
I installed the 1.9.0 files and set the debounce globally to 100. The contacts work now, but not reliable. Sometimes the signal is missed and the status in openhab is not correct. The command gpio readall shows the correct readout. So the solution with 1.9.0 is not reliable yet.
Thatās interesting, what are your actual contacts?
I use the locking mechanism on my uPVC doors to complete a circuit so that could be causing multiple bounces as the locking mechanism slides. We are heading into summer around here, so this will become more noticeable if its unreliable. If it does I will investigate further and put an oscilloscope on the output to see what is going on. I may well end up putting a capacitor across the contact GPIO pins for each door to get rid of any bouncing, although that may cause problems at the point when it switches from logic 1 to logic 0.
I wonder if the Openhab 2 binding is better
I use Pin 17 and 18, 27, 22, 23 and 24. All have the same problem. The readout of GPIO readall is allways correct, so it must be a timing problem in the driver. I think it reads the status only once.
Are you planning to try openhab 2?
I also tried GPIO:wait=xx on several values, but no improvement.
If the status readout is wrong, and I make the change the contact again form High to low, it will follow again. It is only sometimes, 10 % of the time, that the status is not correct. So it is not reliable at this moment.
Are all your pins exactly the same? Just wondering if one of them has a different contact bounce profile that makes it worse.
I will try Openhab 2 eventually. My 2 OH 1.8 instances are highly developed and working well. As they control pretty much everything in the house I need OH2 to be just as reliable as OH 1.8 with an easy upgrade path to limit disruption before I make the move. I also need to have sufficient spare time to do the changes and rollback if everything doesnāt work out.
Currently there is an issue with running OH2 on the read only image I use on my main system too which needs to be solved before I can migrate - details here Trying to install OH 2 beta 4 on OpenEnergyMonitor image
I donāt have this problem on OH1.8 as I manually installed it into its own read write folder
Having looked at this over the last couple of days Iād say mine is at least 90% reliable which is different to your 10% reliable
No it is the same. 10% of the time the status is not correct. I call that unreliable.
As a workaround I wonder if its possible to read the status of the GPIO contact Pins every few seconds from outside Openhab using executeCommandline and then update them? Unfortunately this goes beyond my knowledge of Python / Linux / Java so Iām not sure where to start.
Yes Kevin. I could do that in Python, it is realy easy to that, but I think the GPIO binding is a basic function in openhab on a Raspbarry pi, so it needs to be fixed.
Since I did not get any input from my PIR but could turn on an LED on my Raspberry Pi from OpenHab, I wrote a short Python script to monitor the pin to make sure that the PIR actually worked. It did. I doubt that it would be particularly difficult to send a REST command to oneās OpenHab server in response to such a change. You donāt need to poll it, you can wait on the interrupt. Here is my [hacky thrown together] script:
#!/usr/bin/python
#+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
#|R|a|s|p|b|e|r|r|y|P|i|-|S|p|y|.|c|o|.|u|k|
#+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
# Based on a script by:
# Author : Matt Hawkins
# Date : 21/01/2013
# Import required Python libraries
import RPi.GPIO as GPIO
import time
import datetime
# Define GPIO to use on Pi
GPIO_PIR = 4
GPIO_LED = 24
def motionChange(pin):
Current_State = GPIO.input(GPIO_PIR)
now = datetime.datetime.now()
print now.isoformat() + ": Motion state = ", Current_State
if Current_State == 1:
GPIO.output(GPIO_LED, True)
else:
GPIO.output(GPIO_LED, False)
def main():
# Use BCM GPIO references
# instead of physical pin numbers
GPIO.setmode(GPIO.BCM)
print "PIR Module Test (CTRL-C to exit)"
# Set pin as input
GPIO.setup(GPIO_PIR,GPIO.IN) # Echo
GPIO.setup(GPIO_LED,GPIO.OUT)
Current_State = 0
try:
print "Waiting for PIR to settle ..."
# Loop until PIR output is 0
while GPIO.input(GPIO_PIR)==1:
print "Waiting..."
GPIO.add_event_detect(GPIO_PIR, GPIO.BOTH, callback=motionChange)
print " Ready"
# Loop until users quits with CTRL-C
while True :
time.sleep(1)
except KeyboardInterrupt:
print " Quit"
# Reset GPIO settings
GPIO.cleanup()
if __name__ == "__main__":
main()
However, before you go to the trouble of figuring out how to add REST calls to the script, I was able to get the GPIO working with OpenHab @AlejandroGuirao two jar files. OpenHab 1.8 Raspberry Pi running Jessie and without the -Djna.boot.library.path environment variable. Big thanks to @AlejandroGuirao.