blog_data/data/blog/posts/2022-06-02_2016-monitoring-a-co2-tank-in-a-lab-with-a-raspberry-pi.rst

2016 Monitoring a CO2 tank in a Lab with a raspberry pi
#######################################################
:date: 2022-06-02 16:54
:author: tyrel
:category: Tech
:tags: Linux, raspberrypi
:slug: monitoring-a-co2-tank-in-a-lab-with-a-raspberry-pi
:status: published

This was written in 2017, but I found a copy again, I wanted to post it again.

The Story
---------

For a few months last year, I lived around the block from work. I would sometimes stop in on the weekends and pick up stuff I forgot at my desk. One day the power went out at my apartment and I figure I would check in at work and see if there were any problems. I messaged our Lab Safety Manager on slack to say "hey the power went out, and I am at the office. Is there anything you'd like me to check?". He said he hadn't even gotten the alarm email/pages yet, so if I would check out in the lab and send him a picture of the CO2 tanks to make sure that nothing with the power outage compromised those. Once I had procured access to the BL2 lab on my building badge, I made my way out back and took a lovely picture of the tanks, everything was fine.

The following week, in my one on one meeting with my manager, I mentioned what happened and she and I discussed the event. It clearly isn't sustainable sending someone in any time there was a power outage if we didn't need to, but the lab equipment doesn't have any monitoring ports.

Operation Lab Cam was born. I decided to put together a prototype of a Raspberry Pi 3 with a camera module and play around with getting a way to monitor the display on the tanks. After a few months of not touching the project, I dug into it in a downtime day again. The result is now we have an automated camera box that will take a picture once a minute and display it on an auto refreshing web page. There are many professional products out there that do exactly this, but I wanted something that has the ability to be upgraded in the future.

Summary of the Technical Details
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Currently the entire process is managed by one bash script, which is a little clunky, but it's livable. The implementation of the script goes a little like:

#. Take a picture to a temporary location.
#. Add a graphical time stamp.
#. Copy that image to both the currently served image, and a timestamped filename backup.

The web page that serves the image is just a simple web page that shows the image, and refreshes once every thirty seconds.

The Gritty Technical Details
~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The program I'm using to take pictures is the **raspistill** program. If I had written my script to just call **raspistill** every time I wanted a picture taken, it would have potentially taken a lot longer to save the images. This happens because it needs to meter the image every time, which adds up. The solution is Signal mode and turning raspistill into a daemon. If you enable signal mode, any time you send a SIGUSR1 to the process, the backgrounded process will then take the image.

Instead if setting up a service with *systemd*, I have a small bash script. At the beginning, I run a **ps aux** and check if raspistill is running, if it's not, I start up a new instance of raspistill with the appropriate options and background it. The next time this script runs, it will detect that raspistill is running and be almost a no-op.

After this, I send a SIGUSR1 (kill -10) to take the picture which is then saved, un-timestamped. Next up I call imagemagick's convert on this image, I crop out the center (so I couldn't use **raspistill's** "-a 12" option) because all I care about is a 500x700 pixel region.

This is then copied to the image that is served by the web page, and also backed up in a directory that nginx will listen to.

.. figure:: {static}/images/2022/06/bl2cam-leds.jpg
   :alt: Leds on a CO2 tank