State change at start up

[sweetapollo]

Hello. I have a project that I have completed with your accessory plugin, but there is a problem with my solution which is after boot, homebridge starts and during the “Exporting and configuring GPIO” and “Exporting GPIO pins from config file” section of the homebridge boot, it activates the pins.

I have the pins crossing a switch so they take the action of a button press on a remote fob. So I have three pins and a ground. I place the pins in mode “out” and pull “down” with the action inverted for a set duration.

Once the homebridge has booted, all is fine, and homebridge can be closed and restarted without causing an issue. All switches work through HomeKit as they should, but my problem is that if the pi reboots due to power failure or scheduled reboot, it will activate the pins on startup again.

At first I added GPIO commands before the homebridge opens so that I can set the pin state for pins 23-25 (13, 19, 26 WiringPi) to OUT and to have a state of 1. I can check this manually and this should set them to the correct format required to be in an “off” state.

This hasn’t made any difference and again when homebridge starts for true first time, the pins are activated before going back to the pin state above and working normally.

I’m not sure what I am missing, but it just means I cannot guarantee that this is in a fail safe state for use.

My code looks like this in the homebridge config:
{
"platform" : "WiringPiPlatform",
"name" : "Pi GPIO (WiringPi)",
"overrideCache" : "true",
"autoExport" : "true",
"gpiopins" : [{
"name" : "GPIO2",
"pin" : 13,
"enabled" : "true",
"mode" : "out",
"pull" : "down",
"inverted" : "true",
"duration" : 2000
},{
"name" : "GPIO3",
"pin" : 19,
"enabled" : "true",
"mode" : "out",
"pull" : "down",
"inverted" : "true",
"duration" : 2000
},{
"name" : "GPIO4",
"pin" : 26,
"enabled" : "true",
"mode" : "out",
"pull" : "down",
"inverted" : "true",
"duration" : 2000
}]
}

This is the GPIO mode and state change before homebridge starts:

/usr/bin/gpio mode 23 out
/usr/bin/gpio mode 24 out
/usr/bin/gpio mode 25 out
/usr/bin/gpio write 25 1
/usr/bin/gpio write 24 1
/usr/bin/gpio write 23 1

sleep 5

/usr/bin/homebridge &

[rsg98]

Does it behave properly if you set overrideCache to false in your config?

[mpavlis76]

sweetapollo> Did you find finally any solution? I have exactly same problem and still don’t know how to deal with it :(.

[sweetapollo]

Override cache seemed to make no difference. I will spend more time with it this week, but my temporary fix was to remove my scheduled reboot and set the first pin that activates to a safe pin, this way if the device reboots at least the fob is activating a safe mode. Not a fix but means I can still use HomeKit while I figure it out without removing code

[sweetapollo]

So override cache makes no difference. Also tried removing the cachedAccessories file to see if that made a difference, but it doesn’t seem to.

[matthewsaj]

Had the same issue, for me I wanted the pins high, they were pulled low when set to output and then back to high during the startup process.

Worked around if by disabling auto export and using an export script, setting "$GPIO export high" this sets output and high at the same time and avoids the state change.

[viictor924]

@matthewsaj I've been trying to solve this same issue and your comment is the closest thing I have found to a solution. Was wondering if I could get your input.

This is my set-gpio.sh file (I've set $GPIO export low)

Note: I set mine to "low" because the "high" signal turns on my relay.

Then I did this
chmod +x set-gpio.sh
sudo ./set-gpio.sh

And got these errors.

So I did an "ls" inside /usr/local/bin and "gpio" is not on there.

That being said, I can find "gpio" inside /usr/bin so I changed the filepath on ./set-gpio.sh from "GPIO=/usr/local/bin/gpio" to "GPIO=/usr/bin/gpio"and

After running ./set-gpio.sh again I still got the following errors which I fixed by removing -g from export

After removing that -g the ./set-gpio.sh script seems to work (no errors but also doesn't return any messages).

At this point, restarting the homebridge service does not trigger the relay turning on. But, if I unplug/plug in the Pi then the relay will be triggered. I think I could solve this by having the ./set-gpio.sh script run automatically upon reboot. Currently, I have my pi restart homebridge on reboot by using an init.d file (not systemmd).

These are the steps I followed to set up homebridge with init.d
https://github.com/nfarina/homebridge/wiki/Homebridge-autostart-at-boot-(init.d)-on-Ubuntu-(linux)

I'm wondering if there's a way to modify the init.d file so that it runs both the ./set-gpio.sh script and the homebridge script at the same time. Something like using the && operator to run the ./set-gpio.sh script FIRST and then run the homebridge script only if the set-gpio script was successful.

This doesn't work though. I get an error:
sudo: cd: command not found

Do you have any suggestions?
Thanks

P.S. This relay will trigger a fob that opens my garage so that's why this is critical for me

[johnw78]

Whilst this is a really old thread, I stumbled across it while I was having the same issue. Some of the above responses pointed me towards a workaround that solved the issue for me, so in the hopes that it may help anyone else who stumbles across this thread, here's what I did to resolve the issue.

MY ISSUE:
I am using a 4 relay module to control a set of sprinkler valves. These valves need to be connected to the Normally Open connection on the relays so that the sprinklers are off if the raspberry pi shuts off due to power outage or error. Essentially the fail safe state needs to be that the valves / relays are off.
I found that when my PI started up, home bridge would startup and then all the relay's would turn on. Based on some of the comments above, this may or may not have been Homebridge that is triggering the relays on, but either way, I didn't want them to come on, because all the sprinklers would come on every time the Pi reset. The HomeKit default time I have setup meant they would go off after 5 minutes, but even so, not ideal.

MY SOLUTION:
I created a bash script called relays_off.sh which simply ran

#!/bin/bash
pigs write 17 1
pigs write 22 1
pigs write 27 1
pigs write 23 1

This set the sate of all the relevant GPIO pins I cared about. I then ran this on reboot by adding it to the PI's crontab.
sudo crontab -e

the crontab just contained the following
@reboot sudo bash /<path_where_i_had_saved_the_script_file>/relays_off.sh