So, I'm working on an art project. My idea is to use PIR sensors to turn on lights in a dark room, which is pretty simple, but I need some help with the logic in the code. I'm able to write a sketch that takes either the high or low input from the PIR and tells an LED (actually, lamps through a seeed relay shield) to turn on or off, but I want each light (four total) to be on one at a time, and to turn on in sequence of brightness. So, each of the 4 lights is a bit brighter, and as you walk around, you trigger one at a time. I can't quite figure out how to write code that turns on one light at a time, even if multiple sensors are detecting. Here's a rough sketch of what I'm trying to do
if (PIR1 is HIGH), turn on Light1,
Else (do nothing) //meaning, if another sensor detects, don't turn on its corresponding light
then,
when PIR2 detects, turn on light2, but if any of the other sensors detect, don't turn on their corresponding lights.
I think my problems are, ordering the way the lights turn on, and making code that specifies that the other lights shouldn't turn on if its not their turn. Sorry if this is confusing, and I appreciate it!
As a very basic solution, you could have two arrays with 4 elements each: one with the list of pins to "listen" to, one with the pins that trigger the lights. Then, you'd have a single index variable that applies to both arrays. It begins at 0, so it listens to the first PIR; when that goes off, it activates the first light, then the index increases by 1 and starts listening to the second PIR.
Of course, you'll also need a mechanism for resetting the index (perhaps after a certain length of time)
I have thought of using an array, but each sensor needs to correspond to one light. You have to trigger the sensors in the correct sequence to turn the lights on, if that makes sense. So, if you're at sensor1, the next closest sensor is sensor3, and as you walk by it, it needs to stay off, and sensor1/light1 needs to be on exactly until you trigger sensor2.
As long as a sensor gets power, it will operate - but as KenF said, you can simply ignore this input if you wish to. Just map the allowed sequences of sensing, in an array or otherwise, and build your code to follow that (as always, it may help to imagine you're instructing a human to operate this system manually; what does he need to know? what rules should he follow?)
The thing is, there are limitations to what can be done within an ISR. You can't, for example, use Serial.print or delay as those functions themselves rely on interrupts (which are disabled during the service of YOUR interrupt).
There's also the possibility, that your interrupt will interfere with the normal execution of your code at some critical point, making your main code less ... predictable.
A common approach is to have the interrupt routine simply update a variable upon it's execution and then have the main code check this variable and undertake the appropriate action. Instead of looking at this intermediate variable, however, you might just as well make a check of whatever should cause the interrupt.
Unless it's some fleeting event, that you're likely to miss if you don't action it IMMEDIATELY, it's more sensible to avoid the interrupt method altogether.