Default GPIO PIN state after openHAB reboot with Docker

Setup, Configuration and Use Items & Sitemaps
,
1

Hi everybody,
I have to control a door triggering a zero level activation relay for a short period (700ms).
With “zero level activation relay” I mean that the relay is excited when Raspberry voltage is zero volts on a certain GPIO PIN.
I’m running openHAB 5.0.0 stable via Docker on a Raspberry Pi 4 model B 8GB with Raspberry Pi Os Lite (based on Debian v12).

Below you can find the code that I’ve written; once openHAB has finished its boot, this code works perfectly.
With any configuration of the outputConnectAction attribute in gpio.things, when I restart openHAB, at the end of the restart, the relay remains constantly excited (PIN voltage detected: zero volts) or it receives an “ON” signal which opens the door (which is wrong).
Only after having sent the first impulse (clicking on the item on the UI), the relay switches off and from this moment, the operation is regular.

What should I set or how should I change the configuration in order to reach the behaviour that, in absence of commands, the relay remains off during and after the restart of openHAB (the state of the GPIO2 must remain constant at 3.3V throughout the bootstrap period)?

Thanks in advance

default.sitemap

sitemap default label=“Test” {
    Switch item=DoorSwitch label=“Door” mappings=\[ON=“CLICKME”\]
}

default.items

Switch DoorSwitch  {channel=“gpio:pigpio-remote:sample-pi-1:door-command”}

gpio.things

Thing gpio:pigpio-remote:sample-pi-1 “Local GPIO” \[host=“::1”, port=8888,
    heartBeatInterval=10000,
    inputConnectAction=“REFRESH”,      /\* REFRESH,NOTHING /
    inputDisconnectAction=“NOTHING”,   / SETUNDEF,NOTHING /
    inputReconnectAction=“REFRESH”,    / REFRESH,NOTHING /
    outputConnectAction=“NOTHING”,     / ALLOFF,ALLON,REFRESH,NOTHING /
    outputDisconnectAction=“NOTHING”, / SETUNDEF,NOTHING /
    outputReconnectAction=“NOTHING” \]  / REFRESH,NOTHING \*/
{
Channels:
    Type pigpio-digital-output : door-command \[ gpioId=2, invert=true, pullupdown=“UP” \]
}

default.rules

val ReentrantLock lockDoor = new ReentrantLock ()

rule “Door - Command”
when
    Item DoorSwitch received command ON
then
try {
    if (lockDoor.tryLock ()) {
        Thread::sleep (700)
        DoorSwitch.sendCommand (OFF)
        lockDoor.unlock ()
    } // if
} catch (Exception e) {
    logInfo(“Generic exception”)
} // try - catch
end

In a previous configuration of openHAB (without Docker), I’ve solved my problem putting a PIN initialization on system startup with:

sudo nano /etc/rc.local

and putting before the “exit 0” final command a line:

pigs w 13 1      #DoorSwitch command

Now that I’m running openHAB inside Docker, even if I set the rc.local this way, it doesn’t work with using all possible values of outputConnectAction :sweat_smile:

Do you have any advice? Thanks in advance :folded_hands:

2

Sometimes relays can be configured to swap the behavior so that they activate when there is voltage present isntead of when it’s not.

While OH is starting that basically means that OH is not connected to the pin and therefore it has no influence over the pin. So the binding would have to set the pin to on prior to disconnecting and hope that the pigpiod doesn’t turn the pin off, which is what I would expect the default behavior to be.

Thew short of it is I don’t think you can get get there from here using the GPIO binding.

There is no reason to use a ReentrandLock in rule in any version after 2.5. And in fact use of a ReentrantLock has always been dangerous because if an exception is thrown the lock may never become unlocked.

Note that a sleep can always be interrupted from outside the rule which results in an exception.

Unless you’ve installed it, I doubt pigs exists as a command inside the Docker container. But if it gets installed somehow by the binding, you can try adding that command to a script mounted to the container. That will get executed prior to openHAB staring up. See https://hub.docker.com/r/openhab/openhab/#executing-shell-scripts-before-openhab-is-started

But that’s likely going to be too late.