I'm currently using NodeRED to interact with the GPIO pins of my RPI4 board. All works pretty well, but when I'm rebooting my RPI I have a very short signal pulse to the relays that are connected to the GPIO output pins. Which means that strange things happen in my home automation (curtains closing, sunscreens closing, etc). The reason is that this part of my domotica is connected with a classic PLC which I control with relays from the GIPIO pins. A very short signal is already sufficient for the PLC to act.
I've experimented with the different settings for the output nodes (initialise pin state, not initialise pin state, set high, set low): but all act the same.
When electronics startup or shut down as the voltages drop or fluctuate it's not unusual to get strange signals on boards. Expensive boards have parts to take care of this where it may cause problems. The Pi being "inexpensive" lacks these safeguards. If you are having issues you will need to do this yourself. Putting clamps, filters, or other circuits to hold the pin down or up until the device is fully operational can be as simple as an electrolytic capacitor but probably will be more involved. On my pi a simple rc filter did the trick. The problem is finding a solution that fixes the pin bounce but allows proper operation of the pin, or at least acceptable operation.
Before Node-RED starts the OS is in charge of the pins and some initialise high and some low. I’m not sure if there a table somewhere which describes which do what but if you can accept/follow those then you may not see the toggling you currently see. Obviously if you need (say) a low level and the OS initialises it high, and then Node-RED sets it low then you will see the spike.
I don't believe it's a software issue. I think it's a hardware design compromise. It's been a while but I had a device that responded to very fast signals and thus I did the rc filter. A quick goggle still reveals power on pin issues. But, I could be wrong.
From the description it appears not to be a power up issue, it is described as happening when pigpiod is started with node-red already running, which suggests that it is an interaction between node red and pigpiod.
@rik1984, if you have not already done so, add a debug node showing what is going into the gpio pin, then stop and restart pigpiod and see what node-red sends to the pin.
@Colin not sure if i understand it correctly. Pull up resistors are relevant to ensure the right signal at an input pin, right? Not for the GPIO output? I have a direct connection to a relay board VCC - In1
@Colin#2 for the debug node holds the same. There is no Nodered output connector at gpio in node. I like your idea: how can I debug?
Is there another way to debug this? GPIOD logging?
Alternatively indeed adding a vc filter is a good idea!
That makes sense. I'll first try to add the resistor as you suggested.
I've debugged what goes into the gpio out node indeed. There are no messages at all
I think the explanation of @dceejay makes sense. That it happens at the handover of the gpio from the os to nodered. Im thinking whether i can prevent the os from having access.
. All works pretty well, but when I'm rebooting my RPI I have a very short signal pulse to the relays that are connected to the GPIO output pins.
He states on power up @Colin
[Edit] I doubt resistors alone will fix this. RC filter of some type, T filter, Pi filter, something a little more sophisticated but not exotic.
Yes sorry for the confusion about when it occurs. I have just retested all scenarios. And as you can see it only appears once after restart and the first startup of NodeRED
I just tested all scenarios:
When I reboot NodeRED while the Gpiod connection is running nothing happens, the same when I stop nodered, wait a while and start it again
When I stop pigpiod (killall) NodeRED keeps showing the active connections. When I restart NodeRED it shows Connection Refused. When I start Pigpiod NodeRED directly picks-up the connections but WITHOUT the spike signal
When I stop pigpiod (killall) and start it again. NodeRED is still showing the connections, but the pins are not working anymore. Till I restart NodeRED it is working again WITHOUT spike signal. I was wrong in my first post (I was really under the impression that that happened).
So the strange thing is: it only happens after a fresh boot of the RPI. In the following scenario's:
Gpiod auto starts at startup, NodeRED starts (after): spike!
Gpiod auto start disabled, NodeRED starts, Gpiod started (nothing happens, but NodeRED is not identifying the gpiod connection status), restart NodeRED: spike!
Gpiod auto start disabled, NodeRED not started at startup, starting up Gpiod manually, after starting up NodeRED manually: spike!
Gpiod auto start disabled, NodeRED not started at startup, starting up NodeRED manually, after starting up Gpiod: spike!
@Colin about the PLC: unfortunately I have an old Siemens logo installed in my house, without network connection. Maybe I should consider upgrading to one with a LAN / Modbus interface
Before we go much further can you give a little more detail on your hookups? How is the gpio hooked up to the device? Wire? What kind of wire? How long is the wire?
[Edit]
Unless you are sending Mhz signals down the wire I don't think you need a high pass filter. It sounds like you are sending a high or low relatively slowly. It would be helpful if you described what the gpio outputs to the device as well. Is it a command string? My first thought is a simple debounce type of circuit is all you need, maybe a couple of 10uF tantalums would work too. That fixed one of my problems similar to yours.
@Colin, yes i've put a 4k7 resistor between the gpio out and the in on the relays board. This didn't effect
@gerry I appreciate your thinking along. I will make a detailed picture of the gpio setup, relays and nodered flow. This will take some time, i will post it in the beginning of next week
