Help setting GPIO initial state on Raspberry Pi

[Jim Schmidt]

Hi,

I'm having trouble with system startup and my GPIO settings on a raspberry pi.

I have a momentary switch application that should take a GPIO pin LOW pause 2 seconds and then take the pin back to High. (Application is garage door opener)

I have the switches and rules set up so that everything works except that I cannot find any way to maintain the pin in the LOW state when the r-pi is booting. 

I have a Rule as follows:

rule first_run

when 

System started

then

var Timer pause

logInfo("Startup","Initializing GPIO signals")

sendCommand(b1_dd_switch, OFF)

sendCommand(b1_sd_switch, OFF)

sendCommand(b1_door_light, OFF)

sendCommand(b1_flood_light, OFF)

sendCommand(b1_carriage_lights, OFF)

sendCommand(b1_pump, OFF)

sendCommand(b1_drain_valve, OFF)

sendCommand(B1_Water_Status, OFF)

logInfo("Startup","System Initialized")

end

I added the logInfo lines because I was seeing something strange at startup as I watched the LEDs on the relay and the openhab.log for correlation.

The system loads the rules file, logs both messages then I get the following messages:

NTP Refresh Service has been started
Exec Refresh Service has been started
HTTP Refresh Service has been started

The LEDs on the relay board all come on when the Exec Refresh messages hits the log.

I did have rrd4j persistence with restoreOnStartup enabled, but eliminated that strategy for all items to see it it might be causing the issue.

Thanks

[Jim Schmidt]

I was unable to find an elegant solution to this issue, so I resorted to Brute Strength and used command line GPIO calls to manage "executeCommandLine(...)" to manage this functionality. I'm not excited about this approach, but but it's better than having the Garage door open when I have a power glitch.

[Michael Traut]

I recently browsed for the topic of GPIO initial state and here are some interesting links:

1) There's much dicussion on this (e.g. http://www.raspberrypi.org/forums/viewtopic.php?t=7443&p=93865), just google on "raspberry gpio initial state". Interestingly there seems to be no common sense on this (?? this is should be deterministic, anyway ??). Some claim that PI (more concrete PI software developers) do know nothing of embedded devices and should be better of playing around elsewhere :-)

2) The initial states for the PINs differ, some of them are on high-impedance. You should find this in one of the articles above. This ones you could use without disturbance.

3) The new images provide some way to define the bootstate of the PIN http://www.raspberrypi.org/documentation/configuration/pin-configuration.md. Maybe this could solve your problem completely.

All in all it seems that your external circuit should always be prepared to find the PIN in some state that might kill the GPIO, (so e.g. always use external resistor for input).