I had a recent occurrence at work that caused me to look around for a tool to monitor a directory for any changes made. Since there didn’t seem to be anything out there, I created a check called dirchanged. It looks at all the files in a directory and creates an sha256 has of the names and contents of the files. That hash is compared to a known value to determine if there have been any changes made.
There are a couple of issues with this check specifically that it doesn’t look into subdirectories and that the hash for comparison is passed on the command line from within the Nagios configuration files. I think the first issue will be fixed soon enough w/ a flag to indicate if the directory tree is to be traversed. The second issue is more cumbersome in that the hash value has to be stored somewhere. I’m not yet certain that putting it in the Nagios configuration files is better than putting it somewhere on the target file system. From the security standpoint, having the check not stored on the target file system is better, much less chance of it being changed by bad guys.
I’ll let it run for a while and see how it behaves and if changes are warranted.
I was reminded recently that when writing code in C, you have to take care to understand how variable are going to be used when declaring them. I was had just finished working on the code used to control the fire effects at The Crucible‘s Maker Faire 2013 booth when the system just seemed to come to a halt. That’s not quite what it was supposed to do.
The system was designed to have 3 24′ towers as the central part of the booth. On top of the towers would be accumulator based fire effects – a 24″ round sphere w/ a 2″ exhaust port, a 9″ x 24″ oblong tank w/ a massive 3″ pneumatic solenoid / exhaust and three smaller accumulators based on old fire extinguishers. The solenoids on the fire effects would all be controlled with an Arduino. The idea was that there would be no direct user interaction this year but the system would run automatically. Plug in the Arduino and away we go.
The code would run one of a number of possible sequences, pause between 30 and 90 seconds, randomly run the next sequence, pause . . . And it did that, most of the time. A couple of times after starting up the Arduino, several sequences would run and then nothing else would happen. Made me wonder if I had crashed the Arduino.
I added some Serial.print statements to the code to dump out details on what was happening internally and ran the code again. This time it ran without issue for almost 2 hours before coming to a halt. Looking at the output on the serial console showed that that pause value was -31438. Of course everything came to a halt, the system was attempting to pause negative 31,438 milliseconds! This didn’t make much sense until I reread the Arduino docs and saw that ints are 16 bit values. Of course it rolled over into a negative number.
Digging into the code I realized that I had used int’s in several places where an unsigned long was needed. Once fixed, all was right with the world and the system went on to work just fine for both days of the Maker Faire.
Perhaps I need to start writing these systems on a Raspberry Pi where I can use Python
I gave a talk at PyCon 2012 on using Python to control external devices through an Arduino.
Seems I was just a wee bit nervous giving the talk. Perhaps some more practice next time…
It’s been a while since I worked with Twisted in Python and I forgot how easy and fun it is to create a robust network server with it.
I’m working on a prototype rfid card reader for use at work. We need to track various types of people who come into the facility – volunteers, faculty, youth, Create members, etc and giving them an id card that they can just swipe when they walk in the building would be a boon to help know who’s here and if they should be doing whatever it is that they’re doing.
The folks over at SparkFun have a simple USB based rfid reader that looks like it’ll do just what’s needed. Plug it in to a USB port and the card looks like an old fashion serial port. On my Mac, it comes up as /dev/tty.usbserial-A900UCVB.
The code does two things. First it reads the rfid, verifies that it’s a valid number and then drops it into a holding tank. Second is that it serves up the rfid from the holding tank (along with some supporting data) as json data through an HTTP server. And because its Twisted asynchronous network code, it can basically do both at the same time.
The next step will be to munge this into the existing timecard system and then we can start beta testing it. That’s going to be a bit more challenging. For now, the prototype code is available at https://github.com/pkropf/rfidcard. Have a look and let me know what you think.
One of the additions that I want to make to Exuro is the ability to accept money and then interact in different ways with the person who shelled out some of their hard earned dollars. In order to do that, I first need to figure out how to accept a money and process the amount given via an Arduino.
I’m working with a Pyramid Technologies Apex 5000 bill acceptor and an Arduino Uno. The folks at Pyramid Technologies seem to be completely open to helping people work with their products. I purchased a used Apex 5000 on ebay and their support folks were quite willing to answer configuration questions and help me with the project. That’s pretty cool.
It turns out that the Apex 5000 is pretty simple to interface with an Arduino. There’s a configuration setup whereby the bill acceptor will send N 50 milli-second pulses per $1 value of the bill that was read. The configuration that I’m currently working with sends 1 pulse per dollar. So a $1 will send 1 pulse, a $5 will send 5 pulses and so on.
The output line on the Apex 5000 is an open collector which makes things pretty simple. The output line of the bill acceptor is connected to a pin on the Arduino that’s used to count pulses. On the Arduino Uno, I’m using pin 2 since that is one of the two that can support interrupts. There’s a 2K resistor that connects the bill reader output / Arduino pin 2 connection to the +5 V pin on the Arduino. And the ground for the bill collector and the Arduino are also connected.
With this hardware configuration, I’m able to read the pulses from the bill collector. My first attempt actually had the configuration so that there were 10 pulses per $1. But this resulted in completely bogus readings because the whole sequence of pulses could take up to 20,000 milli-seconds for a $20 bill. To start, that’s way too long to wait before making the determination as to the bill domination. And the code was slipping sideways when trying to count the pulses. So I reset the configuration to 1 pulse per dollar which results in a maximum of 2,000 milli-seconds for the largest bill allowed.
Right now, the code is still a little wonky. There’s still a problem with determining the actual dollar value. I suspect that it has to do with the relationship between the interrupt and the simplistic logic in the loop to determine the value. Some more debugging is needed.
There’s a code repository to share whatever way I manage to make this work. Feel free to poke at it with a sharp stick.