Category: Python

Posted on

Handling signal TERM in Python

I had an issue with the lights staying on after stopping the python script using start-stop-daemon, because I wasn’t handling the terminate signal that it passes to the script.

By default, when you call start-stop-daemon with –stop argument it sends a signal TERM (terminate). To handle this signal I created a class that registers a callback method for signal.SIGTERM. That method then sets a flag. So when start-stop-daemon is called with the –stop argument it will call the method and set the flag. In my main while loop I now check that flag and if it is set then I quit the code and clear the GPIO pins.

class CancellationToken:
    cancel_now = False
    def __init__(self):
        signal.signal(signal.SIGINT, self.exit_gracefully)
        signal.signal(signal.SIGTERM, self.exit_gracefully)

    def exit_gracefully(self,signum, frame):
        self.cancel_now = True
...



while not request.cancel_now:
    #do stuff here... and stop once the service receives
    # a TERM signal
Posted on

Build Lights

A few years back I created some build lights for our Continuous Integration (CI) server. You maybe asking “What are build lights?”. Well in a continuous integration server every time a developer checks in code to a source control repository it triggers an event on the CI server. The CI server will typically download the latest code from the repository build it and run all the unit tests. If all the test pass then it will typically copy the latest code to your development environment. If it fails people want to know ASAP, so they can fix whatever broke the build.

Build lights are the physical signal of whether or not all the unit tests have passed or they have failed.

When I built this project 3+ years ago I used a RPi to query our TeamCity CI Server using their XML REST based API. I wrote a script in python that polls the status every N seconds. If ANY of the unit tests fail a red LED would light up! This was the signal to the developers AND the project manager something was wrong. The best part was seeing how the other developers reacted. We had a number of unit tests that were failing for weeks and no one was fixing them, within 2 hours after I setup my RPi with the build lights the developers on the team had fixed ALL of unit tests that were having issues! 🙂

After that it was like a challenge to see who would fix the issue when the light would go red. In fact, the project manager would even jump in and ask why is the light red? It was amazing to see the effect it had on the team!

The reason I bring this up today and I’m blogging about it is… I’ve finally got around to hooking up the RPi to a stop signal that I bought on Amazon. To hook up a RPi to mains voltage I used a SainSmart 4-channel 5V relay.

Check out the video! 

Posted on

Updated: Motion Detection

Over 3 years ago I augmented my home security system with a Passive Infrared Motion (PIR) sensor and placed it at the front door. I quickly put together a Python script that runs on a Raspberry Pi (RPi) computer.  Basically it sends and email and triggers a IFTTT event whenever there is movement (detected by the RPi GPIO library) by the front door.

Side note: If you haven’t checked out IFTTT I highly recommend you check it out, there are a LOT of really cool things you can do with it.

There has been an issue with the sensor sending multiple text messages per “event”. This is due to how I wrote the code to handle the event detection with a callback. This would allow for multiple events / threads to be fired per movement in rapid succession. There are many ways I could handle this issue.

  • I could do some low level locks around the global variable
    • pro: control the date variable that’s being used by each thread
    • pro: very granular level of control
    • cons: more difficult to code
    • cons: more prone to errors
  • I could add all events into a global in-memory and loop on the main thread over the queue
    • assumption: there is a thread safe in-memory queuing library in Python
    • pro: easy to code
    • pro: could add extra functionality easy per event (e.g. logging messages)
    • con: need to find a thread safe queuing system
    • con: might be overkill
  • I could listen to different events that don’t run on a seperate threads
    • pro: after looking over the RPi GPIO (General Purpose Input Output) documentation again. It seems there are other events that might be more suited to the task.
    • cons: the events I’m looking out would likely miss the extra events that are triggered, but who cares! 🙂

I’m leaning towards the last option. I’ll start with that one tomorrow and see how it goes, and update the blog soon.

 

Update:

Okay, so updated the code. Haven’t checked it into GitHub yet and it is working well. I’m not getting the multiple notifications within the same second. However, I’m still get false positives on occasion. So since this is hardware, I thought maybe something is up with the voltage. Especially, since my RPi is about 40+ feet from the PIR sensor. I got the multimeter out and it was reading a constant 3.2V, so I think that’s fine. What I did notice was the connections were pretty loose, so I tightened those up a bit and we’ll have to wait and see if I still get those false positives.

https://photos.app.goo.gl/Kt5yd05WI6UQSVlE3