First trigger of input GPIO not working after restart

[Olivierbkk]

Hi, I noticed that after restarting HB server or the Pi, the GPIO input need to be activated twice to work properly. After that they work fine.

For example if I restart, then open a window, the sensor still shows closed, then I close it and re open, only then it shows open.

The same applies for buttons and rockers.

[ebaauw]

I've never seen that. Did you check the Homebridge log, or did you only look at a HomeKit app? HomeKit might need some time to re-connect to an accessory (i.c. Homebridge) in case it became unavailable.

See the Wiki, in particular https://github.com/ebaauw/homebridge-rpi/wiki/Supported-Devices#device-state, to understand how Homebridge RPi interacts with the GPIO pins.
On Raspberry Pi reboot, the GPIO pins reset to factory defaults. To change these, see https://www.raspberrypi.com/documentation/computers/configuration.html#changing-the-default-pin-configuration. This is probably needed if you use reversed logic.
On startup, Homebridge RPi only configures the GPIO pins (for input/output, pull-up/pull-down resistors, etc), but doesn't change the state.

Make sure the input pins are wired and configured correctly: if you use an external resistor, make sure to specify "pull": "off". Preferably use pull-up resistors, so you don't need reversed.

If you think Homebridge RPi isn't working correctly, please run Homebridge in DEBUG mode, set Log Level to 3 and capture and attach the Homebridge log file. I would need to see e.g. a window open/close and button press, followed by restarting Homebridge, followed by two more window open/close and button presses. Note that the logging will be excessive with Log Level set to 3, please don't copy/paste log messages, but attach the file.

[JurgenLB]

I think I have the same issue; I have a number of contact sensors connected to a raspberry pi. { "device": "contact", "name": "Watermeter", "gpio": 17 }, { "device": "valve", "name": "Regenwaterklep", "gpio": 19 }, { "device": "contact", "name": "C.V. Groep 1 (Woning)", "gpio": 20 } if the contact sensor is active and you do a restart of homebridge. it chows that sensor as inactive. when the sensor switches state to inactive the next active is pick-up and the sensor is "live".

I have check this whit PiGPIO command line and this is because there is no change so pigpio doesn't send its state only at change the state is send.

Maybe we need to 'read' the contact on startup so that the state is "live"

[ebaauw]

Maybe we need to 'read' the contact on startup so that the state is "live"

Homebridge RPi does that. Set Log Level to 2 to see the interaction with pigpio.

[JurgenLB]

{ "name": "RPi", "hosts": [ { "host": "10.0.1.28", "name": "GPIO", "noPowerLed": true, "devices": [ { "device": "contact", "name": "Watermeter", "gpio": 17 }, { "device": "doorbell", "name": "Bel", "gpio": 24 }, { "device": "contact", "name": "Gasmeter", "gpio": 27 } ]

`:~ $ PIGPIO_ADDR=10.0.1.28 pigs r 27 1

:~ $ PIGPIO_ADDR=10.0.1.28 pigs r 24 0

:~ $ PIGPIO_ADDR=10.0.1.28 pigs r 17 1`

So this is strange then from the command line the 2 meters are 'active' but in RPI not. I will check the logs further

[JurgenLB]

I have put up a new homebridge for testing this is my log.

homebridge.log

I have started with input 6 to 3,3 v (High) then I have setup the RPI-plugin and restarted homebridge. the input chows 'not active' (dark) then I have put a few time the relays on and off. Then the status is "live" After a restart because of the cache function the status is still OK, only when the state changes when homebridge is not running and the cache function is "low", when the plugin comes online the status is not changing to "High" until new event.

I hope you can understand the situation.

[ebaauw]

[1/1/2023 10:20:46] [RPi] GPIO: listen map: [.... x..x .... ..x. .... .... .x.. ....]
[1/1/2023 10:20:46] [RPi] GPIO: command BR1 (10) 0 0 ""
[1/1/2023 10:20:46] [RPi] GPIO: command BR1 (10) => 402711007
[1/1/2023 10:20:46] [RPi] GPIO: command TICK (16) 0 0 ""
[1/1/2023 10:20:46] [RPi] GPIO: command TICK (16) => 2536020401
[1/1/2023 10:20:46] [RPi] GPIO: used gpios: ["6","17","24","27"]

During initialisation, Homebridge RPi determines what GPIOs to monitor. It sends a BR1 command to pigpio to read the states of the GPIO pins. This returns 402711007 or [0001 1000 0000 0000 1110 0001 1101 1111], or 6: high, 17: low, 24: low, 27: high.

[1/1/2023 10:23:20] [RPi] 24 V: gpio 6: low
[1/1/2023 10:23:20] [RPi] 24 V: set Contact Sensor State to 0
[1/1/2023 10:23:20] [RPi] 24 V: set Last Activation to 1006 seconds

Here you're setting GPIO 6 low, and the contact sensor state is updated to 0 (CONTACT_DETECTED). What's weird is that the state was null, as was Last Activation. Maybe because you used a new Homebridge installation, and didn't change the GPIO state before, while Homebridge was running? Still, Homebridge RPi should have initialised the state after the BR1.

I think I found the bug, introduced in https://github.com/ebaauw/homebridge-rpi/commit/91c2a66c394c44ac810c9b1211cd270883e64fa9. Also found another (potential) one: NodeJS seems to evaluate undefined & 0x01 as 0 instead of undefined, which might cause Homebridge RPi to think it already has set a value (low) for the GPIO on initialisation.

[JurgenLB]

I did these changes to my test system and now the state is "live" on startup Thank you for the fast reply Also thank you for explaining the code. I think we can close this

[Olivierbkk]

@JurgenLB May I know what changes you did? @ebaauw are you going to release a fix in an update?

[JurgenLB]

@Olivierbkk you can clone from github or make the changes manual on My Raspberry Pi running Homebridge; I have manual changed; /var/lib/homebridge/node_modules/homebridge-rpi/lib/PigpioClient.js and /var/lib/homebridge/node_modules/homebridge-rpi/lib/RpiService/GpioInput/index.js like ;

[Olivierbkk]

thanks for the explanations, I did the changes manually also

it seems to work fine with doors and windows sensors set as contact as well as push buttons

rockers still needs to be activated twice before they start to work normally - I totally can live with that...

the latency seems to be reduced also

[ebaauw]

rockers still needs to be activated twice before they start to work normally

Not in my testing. Note that if you flip the rocker while Homebridge is not running, that won't result in a button event. On startup, Homebridge RPi can see that the current state differs from the last state, but there's no way to determine when the rocker was flipped, or how many times. Similar to how button presses on a stateless switch aren't registered when Homebridge isn't running.

[Olivierbkk]

actually it does not happen always, and this morning I found the same with buttons so it could be from the home app or my Raspberry Pi specs are too low. I was trying to test that this morning by rebooting and trying all configurations for you but at the second reboot I lost all my RPi devices in Homekit so I spent the rest of the day putting them back and redoing the automations... beer time now cheers