The program loads onto the ESP32 without any problems or error messages. If a simple test of activating the pir is carried out then all works as expected and the LED stays on for 11 seconds.
If the test is complicated by activating the pir whilst the LED is on the I don’t see the expected increase of the time that the LED is on which should have occurred as the interrupt handler should have updated the variable last_motion_time.
I put a simple message in the first line of the handler_interrupt routine to show when it is being called, and discovered that handler_interrupt routine is not being called whilst the LED is on! As soon as the LED goes off then the handler_interrupt routine is called when the pir is activated.
Is there a command in Python to relinquish control that we could put at the end of the while True loop that might give the IRQ handler a chance to do its bit?
I’ve tested the example again, and you are right. It doesn’t trigger the handler_interrupt() function while the LED is on. But I think it is related with the behavior of the PIR motion sensor itself and not with the code.
I’ve tested this same code, but instead of a PIR, I used a pushbutton. The handler_interrupt() function is triggered every time I press the pushbutton. That’s why I say it must be the behavior or the PIR motion sensor, or the interrupts we’re doing here are not prepared to deal with PIR interrupts? Do you have any idea why this happens?
You are correct the problem is caused by the PIR sensor. I had established, by trial and error, that if there was an eight second or more delay between the interrupts from the PIR sensor, but less than the delay_interval then the LED stayed on. I Tested this by setting the delay interval to 15: putting a print(‘ISR running ‘) statement into the handler_interrupt routine: putting Print statements to print out the last_motion_time variable for when motion was detected or stopped and also the current time when motion was stopped. After waving at the PIR to put the LED on, providing that I counted more than eight seconds but less than fifteen seconds I could see the ISR running message and the last_motion_time printed out.
But why? Being a male, it was only as a last resort that I looked at the product documentation, and there I could easily see why, the PIR is a HC-SR505 and as a feature has a Delay Time: The default 8S + -30% . Problem solved and thank you for your help.
I wasn’t aware of that. But now, everything makes sense.
I’ll need to check the datasheet carefully next time.
Thank you so much for doing that experiments and letting us know the reason why it was not working. This is very useful information not just for us, but for all our readers. I think this is something worth point out in the course (I’ll add that information in the next eBook update).