Does anyone know what this error is about.
2021-03-21 14:44:30.644 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler PigpioRemoteHandler of thing gpio:pigpio-remote:c4f39c377e tried updating channel GarageDoor1Sensor although the handler was already disposed.
Thanks
that looks a little like a bug to me
this is in the OpenHAB logs right? (because core.thing.binding.BaseThingHandler) maybe describe situation when WARN log entry is thrown and maybe head over to github and ping Nils
Problem solved. It seems to have not liked being called a contact. As soon as I changed it to a switch, the handler error went away. So now I will just have to do some transformation to show the garage door OPEN instead of OFF.
Thanks
I did it the same way, but created a rule for cron to run it every 10 minutes. Works great.
Thank you for contributing this binding, glad to see this will be included in the 3.1 release!
I have managed to install the binding on OH 3.01, created a thing, and then two items (as switches) (setting both up through text files, not the UI) to read two input pins. But trying to read them through OH, things do not go as expected. I am not sure whether this is an issue with the binding, my circuit, or just me not understanding well enough gpio.
For context: I have a setup that worked well under OH2 with the old GPIO binding. Basically two sets of window contacts, one for each floor, which I feed from the 3.3V pin of the Pi and then read each through a simple circuit with a pull down resistor connected to pins 17 and 18. That circuit definitively continues to work, as eg pigs r 18 will show me the correct state of the window contact, and changes when I open or close a window.
Now, after configuring the thing and items, that seems to work in principle, as the item does sometimes get a state assigned. However, more often than not it does not (the state is NULL), and it does definitively not update states when windows are opened or closed. Also, the pigs r 18 command now ceases to work as expected, ie it will report 0 regardless of whether the window is open or not. In order to get back to the expected behavior of the pigs read command I had to reboot the Pi with the gpio contact; eg restarting the pigpiod service alone did not help.
I have tried this both on the raspi 4 on which OH is installed, as well as on a seperate raspi 3; same behavior in both cases.
I am increasingly thinking this might have much to do with my circuit. There is a lot of wiring in there, basically about ten windows on each floor; so the voltage coming back to the Pi might not be that much. But given this worked well with the OH2 binding, I was thinking perhaps the new binding is perhaps too aggressive in rapidly polling the gpio pins? Is there perhaps a way to significantly slow that down?
I know this is difficult to diagnose remotely, but any thoughts or input would be much appreciated.
Digging into this a bit more, I’ve noticed the binding / pigpiod seem to be changing my pin configuration.
This is what raspi-gpio get gives me after fresh restart of the Pi, and OH GPIO binding disabled. As expected, pins are configured for input and reading pin states works.
GPIO 17: level=0 fsel=0 func=INPUT
GPIO 18: level=1 fsel=0 func=INPUT
After starting the OH binding and connecting the thing, the pin configuration changes to output pins, and obviously reading state does not work anymore.
GPIO 17: level=0 fsel=1 func=OUTPUT
GPIO 18: level=0 fsel=1 func=OUTPUT
For completeness, here’s my thing configuration
Thing gpio:pigpio-remote:raspberrypi1 "GPIO Raspberry Pi 1" [host="192.168.178.57", port=8888] {
Channels:
Type pigpio-digital-input : fensterEG "Fensterkontakt EG" [ gpioId=18]
Type pigpio-digital-input : fensterOG "Fensterkontakt OG" [ gpioId=17]
}
I was already wondering whether I had fundamentally misunderstood thing configuration for this binding and tested configuring channels as pigpio-digital-output; and while that left pin configuration on the Pi in input mode, as it should for reading pin state, the items in OH did not pick up state but rather remained NULL.
Still as puzzled as I was before…
Did you ever get this working? When I create an item type Switch it’s working. But when I add a profile it’s not updating anymore. This is my .map file
key=value
ON=Closed
OFF=Open
=default
I have not pursued this any further. I do know that they have to be switches or it will not work.
I just wanted to report that I successfully enabled your new binding and have had zero problems. It works flawlessly. Thank you so much!
I’m using this on a RPi 3B controlling GPIOs on an RPi zero. I followed the advice found on this page to get it working. I can’t thank you more!
Do your inputs also change when editing the thing? My system is working but I have te set the pins to input after every edit.
My inputs change to reflect the settings I have in OH binding / channel. It’s been working really well!
I only use them as an output and as switches.
My inputs change also, but I have a rule that runs every 10 minutes resetting them through and EXEC. I also add the the commands to the config.txt so that they are set at boot.
I just upgraded from 3.0.1 to 3.0.2 and had to go back in and re-install through the console again.
bundle:install
bundle:start
But it still works fine.
“glad to see this will be included in the 3.1 release!”
Does it mean the standard GPIO binding is now back available in the 3.1.0.M4 (Milestone) distribution?
I mean, i’m not targeting to use the pigpio-remote binding as I prefer the simple items file containing direct access to the pin:
Contact Knop_IN04 “Schakelaar 01 [%s]” { gpio=“pin:3 debounce:10 activelow:yes” }
I tried this and it worked as a charm. However, I am not able to invert the switches. The property is not working as expected. Also, is there any way I can bind the state of the GPIO Pin to the switch. For example, if I switch on and refresh the page the Site Map shows the switch in off state. Is there any way I can bind the actual status of the GPIO Pin (Either On or Off) to a switch?
After restart of RPi, the invert flag started working. However, still not able to set the state of the device while opening the UI. Can someone help me in this? Is there any way we can bind two channels to the same item?
Seems everything is working now. I just removed autoupdate=false flag from my things file and the state is now persisting with the switch value.
Thank you for implementing this in OH 3. 
Loved this piece of work.
@sjoerdtakken I created commit from your proposal and created pull request also with few of my improvements [gpio] Added parameter for pull up/down resistor and other improvements by SloCompTech · Pull Request #10782 · openhab/openhab-addons · GitHub.
Thanks for this helpful information!
However I get this error in the log: [ERROR] [internal.handler.ScriptActionHandler] - Script execution of rule with UID ‘a78e6b9d6f’ failed: executeCommandLine("/etc/openhab/scripts/set_Input.sh")
The script file exists. Can anyone please help me figuring out why this happens? I use OH 3.1.0.M4.
Thanks in advance!
Hi
With your description not everything is clear, the text behind the error message is important, for insufficient permissions to run the script by the system:
… Cannot run program “/etc/openhab/scripts/set_Input.sh”: error = 2, No such file or directory …
Reasons why the script is not run automatically by the system during startup may be more, version of Openhab you are using (3.0.x or 3.1.x?) or version of Java or HW / OS on which Openhab is running or other …
Try the following:
If nothing helps, try placing the script file in another directory:
Main UI change path:
Here’s how to run a script in the Main UI:
If nothing helps with this, copy and send more information from your log file, or more information about your system …
I believe you can do it … 