GPIO and relays on startup

Hi all,
I am using RPI and have a relay board connected the GPIO on the header pins on the RPI. All this power by a pc power supply which is again connected to its own fuse. Whenever OH or the RPI crashes my girlfriend gets frustrated and she would like an easy way to restart the system to get the lights back on. So this means that she would disconnect the header pin cable, pull out the usb cable then wait a few seconds, then replug the usb, wait a second then replug the header pin.

If she does not unplug the header pin the power supply will turn itself on and off continously(or in most cases just off), i guess this is due to the state of the GPIO pins when the RPI is booted(note OH is not started at this point) and that the the relays has power to them.

So how can I ease this progress?

  1. Can I have one push button for reset and a diode on the ground(vcc as well?) wire going to the relay board?
  2. Or 2 switches where the first switch is for the power for RPI and the second to ground wire on the relay board?
  3. Or a 3 way switch somehow, where first stage is RPI power and second relay board, without cutting the power to RPI in the transition.
  4. The main problem is the OH crashing not RPI, so maybe a webpage where she can restart OH?
  5. Arduino with a switch that sends MQTT to restart OH

If the problem is OH and the machine is otherwise stable I would change your approach and move your OH to a separate machine and use Remote GPIO (enabled through raspi-config) or a script to control the GPIOs. That way the machine that interfaces with the relays does not need to be restarted nearly as frequently if at all, you might eliminate the weird GPIO startup behavior as I believe that is caused by the OH GPIO binding’s initialization (I at least don’t see that occur in my python script), and OH and the relay controller can be restarted independently.

If you are looking into all the extra work that 1, 2, 3, 4, or 5, you may as well consider this as a 6th option. And one that will likely be more reliable and less work in the long run than the other options.

Well every arduino, rpi etc can crash so moving the GPIO to a seperate hardware would reduce my problem to every two years instead of every two months, but I would still have the issue. So I need to solve it somehow, and its a mechanical problem not software related! The mechanical problem is that the relay are not optoisolated and if the relay has power and the rpi not on startup the current goes wrong way, then when rpi start up, in that instant ms the current goes through the GPIO pins and wrong way into power supply which then switches itself of instantly.

The relay and rpi are connected to the same powersupply, I assume this is the problem, because it works with a seperate powersupply for the RPI, however having a second powersupply takes more space, draws additional current. So if I could simply restart OH someway(software, that would reduce the need of shutting power off/on to every 2 years or so) or do it simpler with some diodes or a three way switch would be prefarable

You say that but I have seen this exact behavior before caused by the initialization of the software. The Pi comes up with the GPIO pins in a certain configuration, then the SW comes up and changes the PUD/PDN of the pins and stuff starts to trigger. The OH GPIO Binding is notorious for causing that problem.

If it truly is caused by the Pi, I think there is a way to force the Pi to come up with the Pins already in the right state by default. I never finished researching that because I discovered my problem was caused by the software.

I’m not saying that is what is happening in your case necessarily. Just showing that in my experience such problems CAN be caused by software.

OK, that would be option 4. Assuming that OH is truly crashing and is unresponsive, you will either need to set up some simple web interface like you described (if you already have an nginx or apache reverse proxy set up this would be trivial, if not it shouldn’t take too much to set something up in Node.js) or you can set up a systemd watchdog. You would need to configure OH to “ping” the watchdog device periodically and if OH stops doing that the watchdog will automatically restart the service.

I like your idea with watchdog, is that something that people have integrated to Oh with great success?

Don’t know. I only know that it exists. I’ve not used it myself yet.

The problems were NOT the relay board but a mic card connected to a GPIO pin. I need to investigate further to see what the actual problem is. For now I unplugged it to see if Openhab becomes more stable.