Hey guys,
So i want to control some Solid State Relays via the GPIO pins with qlc as controller.
Everything works except that when qlc boots up it turns all Outputs to High until i enable an all active scene and then disable it again. Ive tried to write an script inside qlc and set it als startup event but it seems to not execute on its own. When i manually run the script it works as intended.
This project is for an install where amateurs will control the system, so having it automatically handle that would be awesome.
Thanks in advance!
GPIO Output high on startup
-
- Posts: 3
- Joined: Fri Oct 18, 2019 4:49 pm
- Real Name:
I found a solution with the autostart of the script.
It seems like the autostart scene/script gets executed before the GPIO initialized. Ive added an 1 second wait command at the start of the script and it now turns off all outputs as it should.
However it will still activate all outputs when the GPIO module initializes so you still get around 1-2 seconds with all outputs enabled.
It seems like the autostart scene/script gets executed before the GPIO initialized. Ive added an 1 second wait command at the start of the script and it now turns off all outputs as it should.
However it will still activate all outputs when the GPIO module initializes so you still get around 1-2 seconds with all outputs enabled.
-
- Posts: 4
- Joined: Fri Feb 14, 2020 7:37 pm
- Real Name: Aaron Duerksen
Another solution might be to use inverted logic to drive the relays.
Instead of "high=on" and common=0V, you could have "low=on" and common=3.3V. If all the GPIO's are either input or high by default, then they'll never be on until you explicitly tell them so, but you'll need to invert your commands.
I'm an embedded software engineer. We do this all the time in that world. The hardware is usually designed to behave itself with no software at all, and then the software is written to control *that*, however it needs to do it.
Instead of "high=on" and common=0V, you could have "low=on" and common=3.3V. If all the GPIO's are either input or high by default, then they'll never be on until you explicitly tell them so, but you'll need to invert your commands.
I'm an embedded software engineer. We do this all the time in that world. The hardware is usually designed to behave itself with no software at all, and then the software is written to control *that*, however it needs to do it.