Home Alone Elderly Monitoring System now has its own Blog

Starting today, I'm posting all of my notes on my Elderly Monitoring system here: http://eldermonitor.blogspot.com/

All of the old home automation  material will remain here, but look for new stuff on the new blog.

A Pattern Language for Haskell System Programming?

Continuing on my previous blog entry (Haskell for the Working Programmer), it occurs to me that there needs to be a set of idioms to define a Haskell for System Programming.  Or, perhaps more strongly: There needs to be a Pattern Language for developing System Programs using Haskell.

When I say System Programs, I am stretching the term a bit to mean an application that touches the real world a lot. That is, it isn't so much focused on doing a ton of data manipulation or business logic, but spends most of its time interacting with the system (hardware, OS, or network) at hand.  This is the land of embedded development, network tools and server management.  Haskell can play here, but I don't see a lot of literature about how to do this.

Haskell is a rich ecosystem for implementing cutting edge ideas. This is its academic heritage and it keeps the language healthy and forward looking. But for us working programmers, we can't always be interrupted from our tasks to explore new mind blowing techniques (e.g. "Okay, I grok Monads, so let's get some work done... whoa, wait... Arrows? I need to start using Arrows?").

So, you want to build Home Monitoring base station (something to collect sensor data, analyze it and perform some action or notification via the Internet).  Oh, and it needs a built in web server for configuration.

How do you do this using Haskell?

That isn't quite a fair question. A Haskell newbie would not be advised to adopt such a big project until they've mastered the language a bit. So, let's ask again, but a little more focused:

I'm an Erlang/Clojure/ML/Scheme programmer (so I understand FP); I've played around with Haskell and now I want to implement my Home Monitoring base system. Where do I start?

That's better.

So, what is needed here is way to guide a developer towards their goal with just a subset of Haskell. (I've recently written over  3000 lines of Haskell for a commercial system. It doesn't sound like a lot, but since it was mostly system programming stuff, I leveraged lots of Hackage libraries and FFIs.  In retrospect, I would say that I used a fairly small  subset of advanced Haskell features to get the job done.)

An aside:  I mentioned  the phrase Pattern Language as opposed to Design Patterns.  I don't want to bring up an old war in the Pattern Community (is there an active Pattern Community these days?), but I am talking about a group of related Patterns (or Idioms) that you can select to help you build a specific thing. Patterns in a Pattern Language are not adhoc. Each Pattern leads to one or more Patterns you may choose to help you build the thing. Check out the original source for further understanding and information. (I'm too lazy to find a great example of a software Pattern Language for system programming, but you can look at my own 1997 contribution to the community: A Pattern language for User Interface Design for the general idea of what I am talking about.)

Now, where were we? Subset of Haskell...

This subset of Haskell wouldn't be restrictive. By all means, if an advanced Haskell technique helps get the job done or makes the program more manageable, then use it.  But Haskell has an ocean of ideas and new users are apt to drown in lieu of getting their project completed.

You don't need to master all of Haskell, just master what you need.  Just by using Haskell (in particular the type system), you are already on your way to constructing correct system programs.  (But, please remember to handle exceptions -- the monadic wrapped real world is full of unexpected behavior).

So, what next?  I don't know. I am wondering if something like The School of Haskell would be a good place to start building such a pattern language (where examples could be not only listed but tried out).

Haskell for the Working Programmer

There is a need for a book.  I would call it "Haskell for the Working Programmer".
The audience would be, you guessed it, working programmers.  Maybe even for working functional programmers.   I already grok functional programming. I have been doing it for over a decade now. It is Haskell I'm trying to grok.

Sure, there is Real World Haskell, and it is great. But, it is also getting dated and perhaps the pacing is a bit too iterative for my tastes. That is, they start off with sub-optimal (naive) solutions to problems and then (in later chapters) proceed to make them better and better.  Too much reading!

As a working programmer, I tend to learn better by studying and stealing exemplars. 

Maybe I want a cookbook.  Or, perhaps, what I am really looking for is a book that recognizes that my first goal is to compose a working program.  Of course, I want to understand why something works, but maybe, just maybe, I want to see something (anything) work first!

Should I feel ashamed that I still haven't mastered Monads?  (Sure, I've used them, debug them and have even constructed a few, but I can't say yet that I have mastered them -- at least not the theory). Can I call myself a Haskell programmer?

Read this: http://www.free-variable.org/2012/08/i-remember-the-time-before-monads/  by Paul Callaghan (you can skip down to the Monads section).  It rings true.

In this way, I feel that Haskell is a bit like Perl.  You can write lots of good, usable Perl without diving into the deep dark arts of Perl objects (bless them).  And, you don't have to write a CPAN module to be a productive Perl programmer. The Perl community has accepted this (or at least seemed to).  Do a google for Haskell and you'll find lots of  computer science-y (aka research) blogs and perhaps a dozen or so explanations on why Monads are easy, how everyone uses them and then you feel dumb when you can't figure them out.

Haskell needs more Working Programmers. Erlang seems to have snagged them all and it was the Monad that scared them away.

P.S.
If you live in the DC area and want to meet with (at least one) Working Programmer, consider joining the DC Area Haskell Users Group and help make it a reality.

Intel Atom (Haskell) vs ARM (Lua) for Home Monitoring Station

ARMs are cheap and plentiful, but computationally limited.  I'm looking to do some image processing (motion detection is done by cheap webcams rather than PIR sensors) using OpenCV. This should work on an ARM, but how slow will it go?

Haskell doesn't have much of an ARM presence and I can't rely on bindings to port well.  If I use Haskell (and I have already prototyped some motion detection using Haskell and OpenCV), then I'll need a beefy server. Why?  Imagine 5 or 6 motion detectors working in parallel to form a comprehensive picture of movement in a household.  Plus, some of the visual detection is fairly fine grain (detecting steam, smoke and burner flame from a stove -- more on that later!).

I feel like I am selling my ideas short by going with ARM (at this point). I'd toss the Haskell code and use Lua (upon which I've also done some OpenCV prototyping).

What is the state of small (set-top) Atom PCs?
Well, this one: http://www.newegg.com/Product/Product.aspx?Item=N82E16883220294  looks promising ($244). The price is a bit high (compared to Android/ARM stuff out there), but it can be a good system to target.

/todd

Home Monitoring / Elderly Care project reboot

This blog has been an  on-and-off  forum for my Home Monitoring project for Elderly people. (A non-intrusive, internet aware means of keeping track of Grandma/Grandpa).

For the past year I've been exploring different technologies, from X10 to Z-Wave to Cameras to homebrew sensors.

Within just a year, prices have dropped dramatically on embedded (ARM) computers, Android tablets, and USB/Wi-Fi cameras.  I'm not so much dedicated to cheap hardware, but I am open to any options given the steep prices for Z-Wave and other proprietary tech.

More info to come.  This is going to be interesting and... different.

For background, check out:

http://toddbot.blogspot.com/2012/08/webcam-based-motion-detection-unix-style.html
http://toddbot.blogspot.com/2012/06/my-home-monitoring-project-goals.html


Stay tuned.
/todd

Thinking Big and Home Monitoring?

Sometimes I think too small.  I come up with a small idea and pour a lot of time into it,  cutting and polishing diamond from stone.  That is fine. That is where I spend a lot of time. But that is not me.

I like Big, bold ideas.

Now is a good time to be looking for Big Ideas.  The internet is huge.  It is the largest thing that humankind has devised. But it is not a single thing. It is not a networked collection of servers and clients. It is the essence of virtual. We run our ideas in virtual machines.  We use virtual memory.  In our distributed, concurrent web of things we don't ask how big, but how many?

What if my home monitoring project isn't really about a bunch of internet enabled sensors. What if the sensors are just players in a virtual network that represent home.  How do I make sense of all of the collected data?  How do I maintain privacy?  How do I make of all of this ubiquitous?

The Nest smart thermostat is a diamond.  It has one task and it does it (apparently) beautifully.
But I am interested in the bigger picture.  I'm interested in a more radical idea:

What if  you could monitor your home by modelling your home (sensors)  as intelligent agents in the cloud?  What if this model ran on a virtual network dedicated exclusively to you?  What if you virtual network of sensors could tell a story (a story about the well being of your home)?

What I don't want:  An alarm sent to my phone notifying me that Grandma's stove has been left on for over an hour without any sort of movement in the kitchen.

What I do want: An alarm sent to my phone because it is 11pm, the stove is on, no one has moved around in the kitchen for 20 minutes,  the TV is on in the bedroom and Grandma has never used the stove that late (her profile has shown that she has never used the stove after 9pm).

I dunno. There is a realistic, big idea somewhere in there. I just need to tease it out.

Next week I am heading off to the San Francisco Erlang 2013 conference.   Hopefully it will remind me that I am not a diamond cutter.

Another Weekend hack: BSON in Lua

I don't use MongoDB, but I'm doing some BSON (instead of JSON), so I whipped up a BSON implementation in pure Lua (because no one else has seemed to have done this).

The files are here: https://github.com/tcoram/bson-lua

/todd

My Weekend Lua Hack: A LuaJIT/RabbitMQ binding

I spent Saturday afternoon getting the LuaJIT ffi to work with RabbitMQ. It was surprisingly easy to a simple publish/consume script up and running.

The files are here: https://github.com/tcoram/rabbitmq-lua

Lua, LuaJIT and interesting things

It's been (at least) 6 years since I've last written any Lua code.
I bumped into this:  https://github.com/SnabbCo/snabbswitch/wiki which looked really interesting.

Can Lua do this?
What is Lua up to?

Well there is LuaJIT and it is (apparently) very fast:
http://luajit.org/performance_x86.html

Hmm.. Where else can I find Lua?
In Erlang? https://github.com/rvirding/luerl

Okay. Time to get the new Lua book and get myself back up to speed.

Experimental Erlang mumble server

I've been avoiding github for a long time now. I've got a bunch of hacks I've accumulated over the years and now figure that github is as good a place as any to put them.

So, my first push is an experimental Mumble (voip) server I wrote a while back in Erlang. It compiles and runs a basic voip chat server but is probably not up to date with the Mumble spec.  Plus there are some half-baked voice mail stuff included that doesn't work yet.  It's called Maunder.

I don't expect anyone to fork it (or contribute), but it is better for it to live there than to exist solely on my harddrive.


You'll need a mumble client to talk to it.
/todd

Haskell vs Erlang

I've been doing copious amount of Haskell and Erlang at work for the past few months. I can't say that I'm an expert at either (in particular, Haskell continues to fascinate and frustrate me), but I have solid software that is about ready. (Laptop monitoring software that must work silently and safely 24x7.)

Most of my prototype was done in Haskell and I rewrote some of the software in Erlang.  There were pluses and minuses for both languages.

Take, for example, some applications I had to write to interface with D-Bus (pretty much the standard for Linux process to process communication these days).  I couldn't find a D-Bus interface in Erlang, but the Haskell one was pretty comprehensive.  It was a bit of a struggle, but the payoff was that when I  finally got the code to compile, it pretty much ran flawlessly. Haskell is pretty strict about data types and D-Bus is all about moving data structures around. There was no "ball of mud' structure could trip me up later, I had to explicitly describe the data structures in completion.  Once the D-Bus code compiled, it worked.

Three months later and that Haskell D-Bus code just purrs along.

But, then there was BSON.  I had to produce and consume some structured binary data. I considered using Google's Protocol Buffers, but that was too rigid. I was still working out fields that would comprise the data and didn't want remote stuff to just stop working because I tacked on an extra field.

Here, Haskell was a struggle. You just don't toss around arbitrary data. I was getting runtime failures whenever an errant structure element appeared. Yes, I know, I should be handling the exceptions, but this was proof of principle code and I had yet to harden it. Bad me.

Erlang, meanwhile, shined where it usually does: When I wanted a failure recovery strategies and tons of crash diagnostics, it produced them.  Plus, Erlang OTP is a lot like Unix: It is a complete runtime environment (log rolling, process management, etc).

Both languages were a pleasure to use. Haskell was a pleasure to compose apps with and Erlang was a pleasure to orchestrate a system of communicating processes.  They both have their places.  I can't see replacing any of the D-Bus interfacing apps (currently in Haskell) with Erlang, yet Erlang  OTP certainly rocks with its ability to stay up and running.

Kitchen monitoring with a Robot?

In my Kitchen monitor adventures (a long going project to keep watch on an elderly person's stove activities), I keep running into privacy issues.

If you remember, my project has evolved to using a wireless camera (and image recognition) to keep an eye on kitchen occupancy and stove usage.  The idea is to notify someone if the stove has been left unattended (no one in the kitchen) for some critical amount of time.  I need a combination of temperature and motion sensing.  The camera would keep track of motion (a little more sophisticated than a simple yes/no motion detector) and a temperature probe would keep track of stove usage.

On privacy concern is actually security:  The system would be comprised of wireless nodes communicating to a base station. There are many ways to jam signals (both on purpose and as happenstance) and if I don't authenticate the data it could be spoofed (pranksters).

The other privacy concern is more personal. I installed a wireless camera in my kitchen and it started to creep people out. Is that thing on?  Are you taking my picture?  Is video being beamed over the internet?

There is indeed something creepy about being monitored by a camera.  Even if I offered promises that the images were "just" for computer analysis and a human doesn't see them (..starting to sound like TSA here...), family members weren't convinced.  Mount the camera on a rotating turret and suddenly it becomes downright ominous.

So, I started to think more about personal privacy.  I had no intent of sending "snapshots" to anyone. The camera was just to be used as a more sophisticated sensor.  What if I mounted those sensors in a robot?  That is, what if the housing was more robot-like than camera like?

This isn't about hiding the camera. There is something subtly more comforting to being watched by a self contained "thing" (be it a cat, dog or maybe even -- robot).

This wouldn't be a mobile robot.  Why does every robot have to move around?  What if this one was the size of a toaster, could be placed on the table or maybe a counter top with a view of most of the kitchen?  Yes, it would have to rotate it's "head" to see everything (versus a camera mounted in a corner near the ceiling).  What if I put the whole computer into the robot and so it becomes completely self contained. No radio between it and the sensors. Maybe wi-fi "just" for communicating serious events (e.g. the kitchen is on fire).

Are we ready for kitchen robots?

Oh, and I am starting to play with a MLX90614  Infra-red thermometer to see if I can do the stove monitoring from a distance (the robot itself).

Stay tuned.

AFT to EPUB or MOBI?

Every year or so I brush off my dusty Perl interpreter and mess a bit with AFT. I am not sure how relevant the system is these days. I still use it once in a while (I still resist using word processors).

I've been thinking about writing an AFT config/rule file to generate EPUB or MOBI formats for e-readers.  I don't have a tablet or e-reader myself (yet -- ever?), but this looks like a useful exercise.  I've also been thinking about standing up an online version of AFT where you can submit your files (or type them in) and generate HTML, PDF or EPUB/MOBI.

So much copious free time...yeah, right.

/todd

Robots are Future Proof, All other computer based technologies are not

Here is the thing about building a robot (from scratch). Your robot is unique. It is a physical entity that is distinct and different from everything else. Even without the uniqueness (maybe you can make clones), it is still a "thing".   If it performs slowly or has defects, that makes it somewhat quaint.

I'm sitting here looking at my son's old Robosapien is from 2004. That is ancient technology.  But, if you put in some batteries and power it up it still turns heads and generates smiles.  This is not nostalgia at work. When we get flawlessly articulated robots existing pervasively in homes, it will be nostalgic.  Right now, however, it is still a minor marvel.

Internet/PC/Tablet/Phone software is notoriously non-future proof. This is why writing software is mostly an endeavor  that you must enjoy in the "here and now".  Once you are done, it is already on its way to obsolescence.

Embedded software is not as bad,  if your device is not cutting edge (e.g. Smartphones peripherals are short lived; Smoke alarms, washer/dryers, heart monitors are long lived).

I suspect that it is the physical nature of the robot that makes it future proof.  This may be why Biomorphic robots are more interesting to me than the ones with big brains.

There is also the appealing (to me) image of the lone hacker working in a dark, shadowy workshop focusing on getting the actuators to turn... just right...

Lagging on Posts

Not much copious free time these days.  A lot of my electronic / mcu work has been shelved (temporarily) and I am doing more PC oriented things at work that take up much of my time.

I am hoping to (re)start blogging and there will be future posts regarding

1. A class on "hacking" (in the old school sense) I am teaching to homeschooled kids starting in January
2. My adventures using Haskell and OpenCV as a means to take a much higher level approach to the home monitoring stuff I've been blogging about here

more to come..

/todd

Cheap little linux things

Forget the Raspberry Pi.  This is currently the cheapest "complete" linux-able appliance I've seen so far: http://www.amazon.com/MK802-Android-Google-Player-Allwinner/dp/B008F5NSLU/ref=wl_it_dp_o_pdT1_S_nC?ie=UTF8&colid=1JI25VHV3LM3P&coliid=I22TB06XNRJJBC

(The Pi doesn't come with Wi-fi, is less powerful and is somewhat larger.  The Pi is more hackable, but if you are looking for more of a turn-key system, these Android based gadgets look interesting.)

Webcam based Motion Detection: Unix Style!

I've been playing around with the idea of using cheap USB webcams as motion sensors.  My PIR solution would detune in the presence of heat (a kitchen stove!).

I picked up a cheap Logitech webcam (C200 for $15 at Micro Center) and started writing some C code... but hey, wait -- that isn't the Unix way.

I downloaded a camera streamer (fswebcam) and graphicsmagic (a cleaner ImageMagick) and threw together this little script:


#!/bin/sh
THRESH=10 # Motion Threshold
SCALE=64x48
sudo umount /tmp/rd 2>/dev/null
sudo mkdir /tmp/rd 2>/dev/null && sudo chmod 777 /tmp/rd && \
sudo mount -t tmpfs -o size=100K tmpfs /tmp/rd/
trap "sudo umount /tmp/rd" EXIT 
fswebcam -q --greyscale --no-banner --scale $SCALE - >/tmp/rd/before.dat
while true; do
    sleep 0.5
    fswebcam -q --greyscale --no-banner --scale $SCALE - >/tmp/rd/after.dat 
    gm compare -metric RMSE /tmp/rd/before.dat /tmp/rd/after.dat null: \
|awk -v TH=$THRESH '/Total/{ if($3 > TH) printf("Motion!(%f)\n",$3)}'
    mv /tmp/rd/after.dat /tmp/rd/before.dat
done

Note: I am using a ramdisk to keep it fast (and embedded friendly).  The scale of the image is reduced to keep comparisons cheap and fast.

I now need to see if I can port this to my Beaglebone!

Strategies for Erlang/OTP on a small embedded (turnkey) platform (i.e. Beaglebone)

As I have mentioned before, I am pretty much using Erlang on the Beaglebone as if it was running on a small (very constrained) server. I'm not using it for bit banging or peripheral interfacing.  I've got very low power (and handy) 8-bit micros to deal with that.  Any peripheral I connect to the Beaglebone will be bridged through a UART.

Where Erlang/OTP will work for me on the Beaglebone is to effectively do what it would on a large server:  I want the Beaglebone to be the brains behind my home sensor network.

Why not just use a PC?  Well, this is effectively (once configured) a turnkey system.  Turn it on, stick it onto your network (or if no 24/7 internet connection, connect it to a cellular modem) and it does it's job.  It does it's job with very little power consumption, a small footprint and minimal "boot" time.  It is just another appliance.  (Note: I am doing development and testing on a PC, only every once and a while making sure that the code runs okay on the Beaglebone. But the final target is a Beaglebone.)

However, with this smallness comes some constraints.  The first  is the most glaring one: there is no harddisk. The Beaglebone has a microSD, but that is the boot medium. On a failsafe system we do not boot from the same place as we actively write data.  So, I am going to have to make sure that Erlang logs nothing to the microSD.  (Yes, I know that the microSD is partitioned, but it *is* just one medium. It is one point of failure and I fear the mysterious vendor-dependent machinations of wear leveling).

What? No logs?  Well, think about it.  Who is going to see those logs?  Well, you could upload them to a server on the internet as part of a bug report, right? Really? What use will a bug report be when Grandma's basement is flooding and the monitoring system isn't doing its job?

Okay, this thing is going to have to be reliable. Think "automobile sensor system" reliable.  Think about what happens when your automobile's sensor system fails: This is a very big deal.  Home monitoring doesn't sound as important as your automobile's sensor system, but when it fails the results can lead to similar problems. This is one of the reasons I chose Erlang/OTP.  I want some support (and some nudging) in creating a very reliable home monitoring system.

But, I digress. What are these strategies I must consider when doing Erlang/OTP on such a small platform?

1. No logging to disk. Nope, the microSD is just for booting and maintaining a list of registered sensor nodes with encryption key, signature and assignments.  At some point I am considering adding additional flash storage (NAND serial flash memory?) just for this registration. The microSD needs to be kept clean as possible -- hey I need to check to see what Linux is touching there too (see next item).  In general: Assume you will run 24/7 without total system failures and keep everything in RAM (Erlang ets?). If there is a major glitch requiring a reboot, do it fast and start fresh.
2. Trim Linux.  Honestly, it is pretty cool to be able to ssh into my router or set-top-box.  But, the final version of this home sensor base station should not need a bunch of Linux services running. Trimming services should even improve boot time. I don't want anything running that isn't under *my* control. I'm a bit of a control freak.  Heh, Erlang (beam) could even be process pid 1, as far as I am concerned ;-) Well, I may still want to keep an ssh daemon running to debug it... but it won't be of much use when the box sits at Grandma's house.
3. You don't have a ton of RAM. Run light.  If you are an internet connected device (and my home monitor certainly is), then get the information off of the device (and into the cloud) as soon as possible.
4. One home monitor base station = One single point of failure. Consider a couple of stations (2 Beagle bones?) working together: Redundancy.When both are alive, they agree on which gets to handle "control" (i.e. sending the data to a cloud server, turn on/off lights, etc). They both receive, track and analyze all sensor broadcasts, but only one does anything with that data.  The two servers can be joined by co-heartbeats.  Maybe one has a cellular modem in case the Internet connection goes bye-bye.  This may sound like overkill, but it dramatically increases the reliability of the system.  How to effectively manage this (particularly after a "failover") is tricky. Assuming that the failed server recovers (reboots or is "plugged back into the outlet"), the two need to be brought back into sync (somewhat).

#3 is the most interesting problem right now.  I am hoping that OTP will help me build the solution. I don't need to completely solve it right now, but it should be considered when building my "first, one and only" home monitor base station.  A cluster of Beaglebones anyone?

My Home Monitoring Project: Goals, where/why Forth and Erlang?

A few people have asked, so here is the quick lowdown:

I am building a home sensor network for my house as well as a target group of "independent elderly"  who have grown kids that want to keep track of them (did you leave the stove on after going to bed? etc).  

I would like the system to support lots of distributed sensors, so they need to be inexpensive ($20 target BOM).  Right now, your home sensor choices are X10, Z-Wave, etc.  They are either too power dependent, too limited or too expensive.  You should be able to put a sensor in every room of your house (and maybe some in your garden, garage or yard).

The sensors should be very, very low power and ideally run off of CR2032 batteries or 2 AAAs.  My sensor MCU is a Silabs C8051F912 (8K Flash; 768 bytes of RAM and insanely low power). I am programming it with Charley Shattuck's MyForth (sort of a macro-assembler that feels like Forth). I  am using an RF12B 433Mhz transceiver using my own protocol (soon to be published). The protocol is encrypted using RC4 (with a 3 byte counter -- 16 million unique key sequences before rolling over is secure enough given a 1 sensor message per minute rate; I am mainly using it for authentication to prevent spoofing -- the data itself isn't that "secret").

  I am not that interested in home "control" yet (turning on lights, etc -- anything that involves AC power), but the types of things I want to sense are:

1. Basement flooding (Water activated Switch).
2. Motion (entry/exit of house and rooms).
3. Temperature (each room and outdoors).
4. Stove (Motion + temperature + time-of-day): Is the stove on for for a long time? Is anyone in the kitchen? Is it an odd time for the stove to be on?
5. Soil moisture (garden).
6. Doorbell (button press to ring + log it -- was someone at the door earlier today?)
7. Vibration/Motion (Was someone on the back deck?)
8. Tap detect (did someone knock on the front door)?
9. Open Window/Door

It would be nice to combine as many sensor capability into one device (perhaps vibration, motion, temperature & switch) and then you analyze the data based on what the device is supposed to monitor.

Some of my current sensors elements include:

1. Piezo vibration sensors
2. Passive IR sensors
3. MEMs accelerometers (for knocks, etc)
4. Magenetic reed switches (for detecting open windows and doors)

The base station is currently utilizing a Beaglebone running Erlang (in truth I am doing development on a laptop running Erlang, but my test target is the Beaglebone).  I am also looking at using RabbitMQ for reliable delivery to the "Cloud" (for further processing/notification). A RabbitMQ queue will run on the Beaglebone so if an Internet connection is not available sensor data is locally queued. A local server (also on the Beaglebone) will feed off of the queues to do things like control lights, bells, pumps, etc.  There will be a shovel between the local RabbitMQ and the Cloud based RabbitMQ.

I chose Erlang because it has a nice message protocol parsing capability and OTP is focused on 24/7 availability. I have been familiar with Erlang for over 10 years, but this is the first year I've actually had an opportunity to dive in deeply.  Plus I am doing some Erlang at work so there is some mental synergy.

I chose MyForth because it is nice and forces me to really think about small system development. 

I chose the Silabs 8051 because it is a very, very nice 8-bit family with a ton of peripheral support -- it is also cheap, ubiquitous and low power .  I've used it (and MyForth) on a couple of job related tasks and am very happy with the match.

Where am I right now?

1. One prototype PIR + temperature sensor is complete
2. One base station radio transceiver -> USB/UART prototype completed.
3. Almost done with Erlang base station message processing module (decryption tonight!)

I have a long road ahead, but I am enjoying tackling things at a lower level (I just finished implementing RC4 in MyForth!).

Erlang on Beaglebone: Don't sweat the small stuff

My interests regarding Erlang on the Beaglebone (or any other small low power ARM system) is less about the peripheral device capability and more about running "big system" stuff on small platforms.

I've thought about hooking SPI (or I2C) peripherals to the Beaglebone, but it just seems too complicated to be worth the effort.  Apparently, I will need to patch the Linux kernel and then convince Erlang to play with it by writing a Port driver.   It's really at the Linux level where things start to get complex:

Every peripheral uses SPI in its own manner.  Being synchronous, you just can't ask a SPI device to "get 1024 bytes" and just consume data.  As a master, you need to send a byte for every byte you want to receive (and understand that for 4-wire SPI you will receive a byte simultaneously during the sending of a byte).

You can implement a peripheral's SPI protocol in kernel or user space under Linux.
However, the notion of I/O buffering and time sliced multitasking is somewhat counter to what SPI is about. (Of course you can do SPI in a multitasking environment, but unlike asynchronous UART buffering, if you write a user space SPI driver, you can't expect the kernel to do more than 1 byte worth of  SPI  work for while you wait for your next slice.)

A kernel based SPI protocol is more efficient, but it means that you are mucking about with kernel development for *every* peripheral you want to support.  I don't want to write kernel drivers for every SPI device.

Alas, handling all of this is trivial with a simple microcontroller.

I believe that dealing with low level synchronous protocols is not a good fit for Erlang. I prefer to have Erlang modelling my application domain than worry about bit banging.

My current choice for a home sensor transceiver is a RFM12B. It talks SPI.  It has a 2 byte nternal buffer for bytes it receives over-the-air.  You need a very responsive SPI driver or you will lose data.

I will use a $3 microcontroller as a bridge between the RFM12B and the Beaglebone UART.  The microcontroller will handle the SPI and stream it to a simple asynchronous serial protocol for Linux to receive and buffer.

The Erlang on the Beaglebone will handle the sensor protocol parsing via a standard Linux UART (/dev/XXX).  Because Erlang is adept at parsing binary, I'll keep the UART protocol binary.

I won't use Linux/Erlang to sweat the small stuff -- microcontrollers make excellent bridges!