Here’s what I’ve built, or what I’m currently working on.


We have an electronic Z-Wave lock on our back door.   This lock works great with our Domoticz home automation system over the Z-Wave interface.  The lock allows users to each have their own  code, but an epic fail is that you have to take the lock apart to create/change/delete codes.  I hate the way codes are managed on this lock and the task is quite onerous.  There HAS to be a better way!  My needs require:

  • to be able to have family members be able to have ability to unlock the door
  • to be able to allow access for hired house help (babysitters,contractors)
  • to easily create and distribute some kind of physical token (other than a key) that can be easily revoked/changed if lost
  • solution has to operate reliably with our existing home automation infrastructure

Of course ESP8266  and MFRC522 to the rescue!


First, the shopping list (bring your own 5 volt power source):

You can build just about ANYTHING with the ESP8266 so long as you have a problem to solve, and couple imagination to the problem – you can do magic!  That’s just what I did here.  I had an RFID chip reader antenna module (MFRC522) and proceeded to see how others have implemented an RFID badge reader.   I found one project that implemented a basic reader with a relay switch to activate a solenoid.  Since I don’t have a solenoid on my lock, I had to make modifications to the code from Luis’ project:

  • use MQTT to signal to Domoticz to unlock the door over my own MQTT broker like the rest of my sensors
  • log when invalid tags are scanned
  • enter a unique client and topic name to uniquely identify the reader on the system

Here’s my fork of Luis’ code which adds improvements that include server-side MQTT support and an example for Domoticz home automation.  To connect the reader to the door lock, I had to get the Domoticz IDX address of the lock and build a statement into the code that would be sent when the database returned a match.  The statement looks like this where XXX is the IDX of the locking device:

echo shell_exec(`mosquitto_pub -h $pubHost -u $pubUser -P $pubPass -t $topic -m “{\”command\”:\”switchlight\”,\”idx\”:123,\”switchcmd\”:\”Off\”}”`);

The project workflow is as follows:

  • User scans their tag
  • 8266 calls out over WiFi to a local server to check a database of RFID tags using an HTTP POST
  • fobcheck.php script receives the POST value containing the tag ID and checks the database
  • If the database returns a match, fobcheck.php runs a shell command to the server-side MQTT client to instruct the door to unlock

The completed reader is simply powered from a 5V power source outside and placed in a convenient location near the door.   Here’s what I used to build the reader in a weatherproof case: (click for larger image)

The fobs can be attached to any keychain for easy use and are relatively cheap so if they are lost or stolen, can be easily deactivated.

To manage users, I use a database back end where each tag has a record which contains the assigned user, tag ID, and enablement value (1 for active, 0 for inactive):

To allow the ESP8266 to read the database, I wrote a PHP connector script.  It connects to the database when the ESP8266 sends an http POST request:


Click for larger image:


So you may recall my tank notification project whereby I create alerts to our mobile phone to notify us to empty the tank for the dehumidifier in the basement.  That project was cool, but it didn’t really come full circle.   I got tired of emptying that beast daily!  After all, who needs home automation if you can’t get your house to actually do all the work for you?  The point of automation is to transform a process workflow into a repeatable sequence of steps and turn those steps into actionable smarts, output, or work requiring little to no human intervention.  Sure, there are self-emptying dehumidifiers out on the market but I decided to build my own automated tank for the following reasons:

  • Because I can!
  • Commercially available self-emptying dehumidifiers often fail – their pumps wear out often
  • As a learning exercise – to learn the needed bit of knowledge and transform that knowledge into a process plan
  • Because, why the fuck do I want to empty a 5 gallon container of water every day during the humid seasons???


As the humidifier runs, the tank fills – this is basic physics at work.  During filling, the level rises.   Tank level is something we can measure and turn into system input.  To solve this problem, I need to know the following things:

  1. When the level reaches maximum – How do we measure that?
  2. How to communicate our input to the central computer so we get notified and so we can send instruction to the pump to turn on
  3. We know we need to turn the pump on at maximum level to prevent overflow (and a mess, and unhappy wife)
  4. How do we know when to turn the pump off?  We don’t want to run a dry pump – that is bad!
  5. Communicate tank status during draining
  6. Send signal to turn the pump off – what logic is used to define an empty tank and only run the pump when there is water present

NOTE: It is desireable to keep pump cycles to a minimum so we preserve the life of the pump.  This is why a 10 gallon container is used to collect condensate.  I use a 1/3 horsepower submersible pump to drain the container.  Drain time is about a minute.


We can register maximum level using a float sensor.  In this design, I use two.  One at maximum level and one at minimum level.  This allows me 3 possible states to power the logic needed to drive the decision to turn the pump on and off as needed but not let the pump run dry. (VERY important!)  The float sensor I used was sourced from Amazon and looks as pictured here.  


This sensor was not ready to be used just yet.   I had to make a mount for it out of PVC, so that I could set the correct height.  I didn’t want the maximum tank level to be too close to the tank lid, that would just be too risky.  One of these is also set much deeper into the tank to register the minimum reading.






Once we have the sensors mounted to the lid, and proper depth set, we can now read these using (you guessed it) an ESP8266 wireless MCU running my favorite flavor of open source firmware, Tasmota.  I have found so many versatile uses for this firmware which runs reliably on ubiquitous $6 modules.  Just two pin inputs and a ground connection are all that are required to read the sensors.  To hook them up, I used 4 conductor solid telephone wire from the terminals to the sensor wires.  

The ESP8266 was connected to both sensors and shared a common ground.  When the status is read (either ON or OFF) we use a rule to format an MQTT message to a computer running Domoticz (this should also work with other HA software apps as well).  On the Domoticz HA computer, we declare two integer values (1 or 0) and set them (click for larger image): 

Once those are in place, we can then setup a logic structure to power the decisions on when and when not to apply power to the pump.  In Domoticz, it’s super easy to create a logic scenario.  If you can click and drool with a mouse, you can implement a LUA script or a block type logic like this (click for larger image):

Every time the sensor state changes, the variables we set get updated by a rule placed into the Tasmota firmware console:

rule1 on POWER1#state=1 do publish domoticz/in {“command”:”setuservariable”,”idx”:5,”value”:”1″} endon on POWER1#state=0 do publish domoticz/in {“command”:”setuservariable”,”idx”:5,”value”:”0″} endon

rule2 on POWER2#state=1 do publish domoticz/in {“command”:”setuservariable”,”idx”:6,”value”:”1″} endon on POWER2#state=0 do publish domoticz/in {“command”:”setuservariable”,”idx”:6,”value”:”0″} endon

These two rules allow us to create the MQTT message when the event is triggered by a sensor action when the water rises or falls.  This message then updates the variables on the Domoticz computer and the logic re-evaluates the situation.   This process occurs constantly and allows us to run the pump only when needed and when it is wet.  We also get notified on our mobile device when the pump turns on and when it turns off so we are aware.


What pump did I use anyway you ask?  I found this gem on Amazon (Amazon ASIN B000X07GQS) and boy is it FAST!:

In order to turn this on and off by command, I used one of the famous KMC70011 WiFi outlets which I re-flashed with Tasmota (I don’t like Chinese servers having control of my shit)  These are very reasonable on Amazon, and when you liberate them from their Chinese overlords, they are AWESOME!  Reflashing with Tasmota is fairly easy and these are easy to open and make the right connections.  They are also ETL certified for safety.





My dehumidifier uses an external tank (5 gallons) so that we can keep it running as needed to keep the basement humidity within the range of 30-50%.  In this configuration, there is no “auto off” and the tank will overflow if not emptied.  The goal is to keep the humidifier running steady so no humidity builds up and this greatly mitigates mold risk and keep the basement (and our stored belongings) from smelling musty.   Also, I just hate having to check the tank daily or worse, forgetting and finding a puddle on the floor.  Here’s a look at how well controlled the humidity is: (click for larger view)


Using the ESP8266, and Tasmota firmware, I created a custom water sensor that would talk to my automation hub for just a few dollars:

Once wired up, I flashed the ESP8266 module with Tasmota and setup the module to read the voltage returned by the sensor on the Analog pin (A0).  This is not enabled by default and requires you to enable it at compile time before you flash the ESP8266.  Once done, a rule was added to tell the firmware to send the raw value (between 0 and 1024) of pin A0:

on tele-analog#a0 do publish domoticz/in {“idx”:421,”nvalue”:0,”svalue”:”%value%”} endon

Analog pin A0 is not selectable as a data acquisition source within the GUI framework of Tasmota (at the time of this writing), but the Tasmota project has added some incredible rules functionality to the firmware which lets you configure all sorts of things and really extend the capability of Tasmota. You can see the main page of the Tasmota firmware here:

Here is the Tasmota Console, where you can see the data being reported over my MQTT broker which transports the data to my automation computer:


That being said, the “idx” value in the rule is the Domoticz object address on the dashboard which will receive the data I want.  When data arrives on the console, it looks something like this:

Any value over 200 will trigger a notification on my mobile.  I could also setup a pump that would drain the tank for me (maybe that’ll be a part 2 to this project) so I don’t have to manually empty it.   Oh well, I’m halfway there, at least I don’t have to check the tank every day anymore.  With this solution, I will get plenty of advance warning to empty the tank and avoid overflow and a wet mess on the basement floor.  Here is the final setup:


Now when the tank fills, a notification is sent to my mobile:



At some point in our lives, we will have loved ones who live alone, but that doesn’t mean they have to be alone when help is urgently needed.  Phones are great for reaching out – IF you can get to them and if you have time to dial, wait for the call to connect, and hopefully a live person picks up at the time of the call.   Of course, one should always call 911 in any emergency, but there are sometimes even 911 may not be possible.  Such as in the case of a home invasion or burglary, phone lines often get cut and smart intruders are getting savvy and jamming cellphones since many people no longer maintain land lines anymore.   Often though, the internet service goes untouched.  

I designed a panic button that exploits the internet and uses the popular IFTTT service to create and send notifications when the button is activated.  The button is a very simple implementation and will work within 150 feet of the wireless router.  When activated, by pressing and holding the button down for a few seconds, the ESP8266 chip connects to the preprogrammed WiFi network and calls a webhook on the IFTTT service (which is free).  IFTTT then generates the alert which can arrive by SMS and/or email.  You can aim the email destination to a single email or an email group so that multiple people can receive the alert when the button is activated.  In an emergency, you may only have seconds to let people know you’re in trouble.  Hitting a panic button and then calling 911 is a good combination in any emergency.  In the case of your phone not working, someone else can then call 911 on your behalf if you can’t be reached, or they can check in on you if you are close by.


I wrote the source code for the button in C++ and it is available as an open source (anyone can freely use it) on Github.  The code is compiled and burned onto an ESP01 (an ESP8266 variant) chip, which is powered by a 3 volt lithium cell (CR123) which is rated for a 10 year shelf life.  This ensures that the button will always be available when you need it – and hopefully you won’t.  I built the button inside an ABS plastic case which is very sturdy and allows the WiFi signal to emanate freely.  The actual button also has a pink glow ring that doubles as an indicator that lets the user know the message was successfully sent, which can help put someone in distress at ease knowing that help has been summoned.  This ring does not light if the button is out of range or if the button is unable to contact the IFTTT service, so you know when it is lit, that the message got out.  All it takes to activate the alert is holding down the button until a steady glow is seen in the ring, which takes only a few seconds.  This design helps to reduce or eliminate false positives if the button is ever bumped or knocked accidentally.   More pictures of the button:

There are many WiFi controlled outlets, switches, and other gadgets out there on the market these days.  These are great tools for smart home automation and are available for a reasonable price.  These devices add smart convenience to our homes and the ability to do voice control of lights and other appliances just by asking Alexa or Google if you have a smart speaker.  These devices are super easy to setup in just minutes, but with such simplicity comes the cost of privacy and more importantly, cyber security.  After all, simplicity is nice…

Almost all of these WiFi smart devices get their smarts from a cloud server that is operated by the manufacturer.  In most cases, the manufacturer is a Chinese company who produced your device and is powering the smarts for the appliance in your home.   Some people might be ok with this, but I prefer that the Chinese do not have direct access to the control point for appliances in my home.  Most people are unaware of the fact that the manufacturer has direct access and control of appliances in their home because they often lack the understanding of how these wireless switches operate – if they only knew.   When you give a command to operate a WiFi switch or control, your command is received by the app made for the device, which communicates with the cloud server, and this server then sends a command to your wireless device which is always in contact with it.  This method of control works great and is reliable, but because it is carried by a 3rd party channel, it is open for privacy invasion and potential misuse by the manufacturer or their employees.  Even if not for nefarious reasons, what happens to the cloud server providing the control if the manufacturer goes out of business?  Chances are, your smart switch would cease to be smart.

Typical foreign cloud based control methodology

Fortunately, most (if not all) of these devices use the ubiquitous ESP8266 wireless chip and there are open source firmwares available for the taking, so that you can re-flash your wifi switch and link it directly to your automation hub, foregoing the foreign cloud, and the risks.  Tasmota, which is available on github is one of the most popular aftermarket firmwares that you can download and compile with the free Arduino IDE software, then flash the compiled firmware into the ESP8266 chip on your device using an FTDI 3.3v USB to Serial converter.  There are 4 connections to the chip that must be made; VCC (3.3 volts), TX, RX, and Ground.  Once these connections are made, there is nothing stopping you from flashing your own firmware and liberating your WiFi switch from the clutches of the foreign server.  

One such device of many I have reflashed is a 3 outlet outdoor WiFi switch where each outlet is individually controllable.  Taking the unit apart involves removing 4 phillips screws and locating the ESP8266 and the 4 required connection points.   In this article, I’ll document it.  In this picture below, you can see these connections marked:

NOTE: NEVER apply AC power when programming or disassembling these switches!

Once flashed and reassembled, you must then plug it in, and use a browser to browse to the IP address of the device on your network (consult your router’s tools for this).  Once on the device’s tasmota page, you can then click CONFIGURATION, then CONFIGURE MODULE:

Then on the CONFIGURE MODULE page, set the following settings:

NOTE: your device may have the relays configured differently, so you’ll have to experiment.

At this point, you could control the device directly using the web page on the switch itself.   This isn’t very practical, so in my case, I use Domoticz as a home automation hub – it’s also open source and VERY flexible and powerful.   To do that, we’ll need to create 3 dummy switches in Domoticz, and find out the IDX (the device ID) in the domoticz console, and then provide this IDX number to the Tasmota firmware now running on the switch.  This will let Domoticz directly control the device.

Finally, we need to setup a messaging transport (I use MQTT, it’s easy to setup and it’s reliable and flexible and works with Domoticz:

At this point, you should now be able to control each outlet via the switches on your local Domoticz hub:


There are a number of products out there which use different methods for filtering content.  Because my home network is very customized, many of the consumer products out there don’t offer the flexibility I need as a parent without “dumbifying” my network.  I have invested a great deal of time and some money on setting up and using second hand enterprise network gear from Cisco and Ubiquiti and I did not want to sacrifice all that.  My requirements for a solution were:

  • had to be impossible to circumvent
  • had to be effective at blocking undesireable traffic, yet be flexible enough for “adult” needs
  • had to fit my network topology and environment
  • had to be secure
  • had to be easy to manage


Because my network is built using mostly Cisco enterprise gear (router and switches), I had a lot of flexibility.  I created something I like to call “Jailed DNS”.  Jailed DNS is where you prevent local network devices from using another DNS resolver outside the network.  For those who don’t know what DNS is, I will refer you to this resource which gives a basic understanding of what DNS is, and how it is used as part of the fundamental internet machinery.  In my implementation here, the intent was to provide a local DNS server on my network that would be responsible for all internet lookups.  Here is a basic diagram of my home network (click for larger view).  You will see that the network is broken up into several zones (known as vlans).   These vlans operate as discreet internal networks that have their own subnets and host groupings.   There are many advantages to partitioning a network in this way:

  • Limit broadcast traffic within a physical switch
  • Apply different network policies to different groups of devices
  • Isolate sensitive devices from the rest of the network (control & automation)


In this example, you can see restricted and unrestricted areas of the network.  When devices on the unrestricted network talk to the local DNS server (DNS Jail), their query is forwarded to a public DNS server like  This DNS server does not discriminate any queries sent to it and will refer devices to the requested resources.  Devices on the other restricted areas of the network, will query the local DNS Jail, and the DNS Jail will know to forward lookup requests to OpenDNS.  OpenDNS is configured to block a few things:

  • Undesired content categories (ie. porn, BitTorrent, etc)
  • Security scam related sites (phishing, scam, hacking, etc)
  • Blacklisted domains (ie. YouTube, Roblox, etc)
  • Anything else I would rather my kids or guests not visit

In order for a DNS Jail to work effectively, you have to have the ability to prevent local devices from using external DNS servers, or it won’t work.   I achieved this in my Cisco Router’s IOS settings by creating the following in my internet ACL (Access Control List): 

This setting does two things:  1) it prevents DNS requests from leaving the network and going out on to the internet   and 2) it allows ONLY the DNS Jail server ( in this case, to be the ONLY host allowed to send queries outside the network (DNS Recursion and Forwarding).   This is one of the most important steps.   Many routers have settings to do this – consult your router’s docs.

Once this was completed, I had to create two “views” on the DNS Jail server.  The views define how the server responds based on the source network subnet of the requesting device.   This is how the DNS Jail is able to decide to forward requests to  or to OpenDNS for content restriction.   Here, you can see how I configured my DNS Jail, which is a copy of BIND9 (DNS Server) running on my network (click for a larger view).  You can see all the subnets of the “Area51” view that are for unrestricted devices, and the “Majic12” view that contain the restricted subnets.   Oh!  and look at that magic statement in there: forwarders {} where I declare the IP addresses of the OpenDNS servers which will receive forwarded requests and do the content filtering magic.


Once this is all done, I startup BIND on my network and it starts processing DNS requests for my networks immediately.  If we try to go to a “bad” destination from a restricted endpoint, we will see the page denying the request!  If we are on the unrestricted part of the network, we are allowed through!  YAY!  Of course no filtering solution is perfect, but if there is a false positive, then the denial page gives the user the opportunity to have the page unblocked with the network owner’s approval.

If we head on over to OpenDNS, you’ll see a nice dashboard which also lets you setup many content filtering categories & websites.   The dashboard will also have tools for you to review settings and most visited and blocked traffic.   It’s FREE and it’s pure magic!   This parental control solution is quite effective and can be setup with a small investment of time.  Over the long run of usage, it will pay you back by making it easy to manage internet content for your family or small business.











Sonoff: A Versatile WiFi Switch

I have been playing a lot with home automation technologies and the ESP82XX/arduino platform as hardware interfaces to my ever expanding control system. Most of the stuff I’m implemented has been Z-Wave, but though Z-Wave is an excellent technology, it is rather pricey to acquire. Since the ESP8266 & ESP8285 chips have started showing up in some finished electronics, it is now possible, now more than ever, to reprogram these devices with your own custom firmware!

One such device is made by iTead Studio and is called Sonoff. Sonoff allows you to switch an AC load using your mobile device or PC from anywhere via their own cloud. In my home automation implementation, I want as little cloud involvement as possible – to minimize attack risk, and to keep other firms from data mining my habits at home. The only way to do that is to use technologies that allow local control and without cloud reliance. Unmodified, the Sonoff is an excellent device and generally available for $7 per unit. If you don’t mind sharing your usage data with iTead Studio or relying on their cloud infrastructure to operate your device, then there’s no need to modify it – just use it as prescribed.

For those who want total control and privacy, you can easily use 3rd party firmware or write your own! In my case, I wrote my own firmware which enables a simple HTTP interface which can be called by my Domoticz controller or manually. Since I have a VPN connection to my home on a DDNS hostname, I can easily and securely operate any devices from anywhere in the world with no need for an outside 3rd party, right from my mobile. To flash a custom firmware, you will need a few things:

  • Sparkfun FTDI Basic 3.3v USB to Serial interface
  • 5 pin header (to solder into the Sonoff unit)
  • Arduino IDE software – to program the ESP8285 chip in the Sonoff
  • Screwdriver
  • Soldering Iron
  • Custom Firmware of your choosing or your own
  • Male to Female Dupont wires to wire the FTDI breakout to the header you’ll install (see diagrams)


This project/information deals with MAINS CONNECTED equipment!  You should NOT attempt to undertake anything described herein unless you are familiar with and confident with working with electricity and electrical safety!  Risk of DEATH, FIRE, ELECTRIC SHOCK, and PROPERTY DAMAGE can result if you are attempt anything described here without being familiar with the concepts and safety herein.   I will not be liable for your use of any of this information should you or someone else be killed or injured.  I implore you to seek qualified and experienced help if you are unfamiliar with or unsure of anything described here.  PLEASE BE SAFE!

Let’s Get Started!

First, you will CAREFULLY disassemble your Sonoff unit and remove the curcuit board inside.  You will notice an unpopulated header where you will solder your 5 pin header to.  This is the programming interface.  (click for larger view)

Once you have soldered on the 5 pin header, you will now connect your FTDI serial breakout to your Sonoff:  (Click for larger view)

Once connected, now you will load your firmware into the IDE and choose the “Generic ESP8285” board and 1M size flash as shown: (click for larger view)

To flash: (NOTE: there is NO WAY to go back to stock firmware!  this is a final operation!!!)

  1. Remove 3.3v lead
  2. Hold down button & reconnect 3.3v lead (at the same time)
  3. Release the button
  4. Flash your firmware

That’s it!  Reassemble your Sonoff switch and your Sonoff should be ready to use!

Here’s my firmware.  You are free to use/modify it.   In my application I wanted the IP hardcoded, but you can easily change this to be DHCP.  I’m currently (at the time of this writing) trying to figure out how to serve the HTTP interface from SPIFFS but not quite there yet so for now, it is hardcoded and functional.

Here’s how mine looks:

Very simple!  You’ll notice that in my code, the switch responds to the URLs of /on and /off which makes it stupid simple to integrate with controllers like Domoticz, Wink, Smartthings, etc:  (click for larger view)

Once you configure this in your controller, you can then operate it as any other part of your system, and even with Amazon Echo (Alexa)!

First Project with the ESP8266 WiFi/MCU Module

The ESP8266 is an inexpensive WiFi-Serial MCU module that allows you to create sensors, switches, or just about any WiFi enabled connectivity for projects.  In my project, I decided to embark on a learning exercise by creating a real time energy threshold monitor to monitor my electricity usage and know when we were experiencing a time of high utilization.  The hope is that by doing so, we become more conscious about how much energy we use and that this can hopefully lead to better habits that reduce our energy costs.

We have a Z-Wave home automation system based on a Raspberry Pi, USB Z-wave stick, and Linux running Domoticz – an open source home automation suite.  Domoticz is a very capable system that lets you tie in a wide variety of control endpoints, data sources, and load switching.  To add the ESP8266 to Domoticz, I had to write some code (firmware) for it using the Arduino IDE (1.8.x) and install the community ESP8266 libraries.  I needed two channels (LEDs) to represent two states; low and high usage.  I used 2 GPIO ports on the module to light an LED (red or green) depending on what Domoticz detected for energy usage.  The interfacing is done as a simple HTTP request to the LED (see code).  In order to do this I had to also create a dummy switch in Domoticz under Hardware and create two separate instances; one for each LED.  

Once I had both virtual devices created, I was then able to see them in the devices list: 

It is a good idea to create a static IP reservation in the DHCP settings of your network, this way, the ESP8266 always comes up with the same IP address on your network: 

Now that we know what the IP address of the module will be, it was easy to assign each virtual switch in Domoticz to each LED (click for larger view):

You can see here how I created the linkage to each LED.  Domoticz makes it easy!  They now show up on the Control Board in the Domoticz web UI:

I still had to have logic in Domoticz to decide when to switch back and forth between red and green LEDs.  Fortunately, it’s easy to do and set that in the Events utility which allows you to build blocky style logic code that makes Domoticz pure magic:  

Here is a LINK TO THE SOURCECODE for the ESP8266 module for this project.  It should help you setup something similar.  These ESP8266 modules are the perfect thing for creating great automation solutions, only limited by your imagination!  Let me know how you use them in your project!  I plan to transfer my module into a decorative frosted glass globe that will glow and change color when the energy demand changes.  Meanwhile, here’s a video demonstration of the module in action:


I recently setup a wireless front door security camera to watch and notify of any visitors to our front porch.  During the holidays, there’s a lot of package stealing being reported in the news.  I am prepared!  My home made system does the following:

  • uses passive infrared (PIR) to detect motion within 30 feet
  • sends a push notification of the detection to my smartphone via pushover
  • records 2 minutes of 1080p video & converts it on the fly from H264 to .mp4
  • uploads the .mp4 file over wifi to my NAS for safe keeping and later viewing
  • sends another push notification when the .mp4 file is uploaded
  • continues to watch for the next motion event to record

The camera and PIR sensor are mounted in a weatherproof enclosure and can be powered from any DC source from 7-35v.  Here are some close up pictures.  Click for larger image:

file_000 file_001 file_002 file_003














The logic:

  • PIR motion event causes the sensor to send a 3v signal to GPIO pin 26 on the raspberry pi computer.
  • When pin 26 goes high, it is read by the “detect” function and stored in a variable.
  • The IF logic uses the variable for detection to either process video recording or return to the continuous loop.
  • The continuous loop runs every second

How to setup:

  • grab the latest copy of raspbian-jessie-lite image (no gui)
  • burn jessie lite image to MicroSD card
  • run raspi-config to set options (internationalisation, and turn the camera socket on if using a camera module – recommended)
  • log in using raspbian default pi user and install necessary packages, update, & reboot the pi:
    • sudo apt-get update
    • sudo apt-get dist-upgrade
    • sudo reboot
    • sudo apt-get install rsync wiringpi gpac htop exfat-fuse exfat-utils
  • insert a large capacity USB stick to cache video recording to & format it with exfat file system and mount to /video
    • fdisk /dev/sda (change partition to type exfat)
    • mkfs.exfat -n video /dev/sda1
    • create /video directory
    • edit /etc/fstab and set mount point for USB exfat key to /video (this ensures the USB is mounted on each boot) Your video files will process on the USB key before being uploaded by rsync (you need a NAS or server that can receive the incoming rsync stream).
  • setup wifi (/etc/wpa_supplicant/wpa_supplicant.conf)



The loop is a simple bash loop called by /etc/rc.local and runs whenever the unit is turned on:



The file containing the functions does all the heavy lifting:



DIY Holiday Flickering Lights

Happy Holidays to all!  In case you are in the spirit to DIY your own window candles or make a flickering lantern/fixture, here’s a Arduino sketch I wrote that has lifelike flickering of up to 3 channels (candles).  If you only want one channel per light, just comment out the 2nd and 3rd LED lines in the LOOP code.  Here is the sketch, happy holidays!:


Freedom to distribute is granted.