The Internet of Things at Scale with F# and Actors

It’s Christmas time which means only one thing – It’s socially acceptable to have enough lights flashing at all hours of the day to make the runway staff at Heathrow jealous. But how do I go about managing potentially thousands of chains of fairy lights all attached to my house?

First I’m going to start with a warning. If you plan to do this yourself, be very careful 230V AC is enough to cause permanent long lasting damage to you or your surroundings.

This sounds like an Internet of Things project to me but what is the Internet of Things? Well, answers to this question in the past have included such responses as “A security nightmare”, “Pointless” and “Does this mean my toaster can like my Facebook status?”. It’s essentially the interconnectedness of as much as possible to create a smarter living environment. But where’s the fun in that? I want to control my Christmas tree from my phone.

So, how are we going to manage to write something like this with the intention of running it at massive scale? Thankfully some really smart people solved that problem in the 1970s with the introduction of the actor model, which basically says that we can treat each of our entities in the world as a completely independent item. If we want to change it’s state, then we send it a message telling it to change it’s state. Actors can do a couple of other things as well, things like spawning new actors and sending messages to other actors.

So in our case how can we think about our Christmas lights using the actor model? Well we’ve got 2 options depending on our usage. We could have multiple strings of lights all on a single parent like a Christmas tree. We could also choose to treat each of our Arduinos as an independent actor with a single string of lights attached. We’ll be choosing the second because I’ll be looking to control lights which aren’t necessarily on a tree and it’s also easy.

I’ve always found it easier to understand a full system when I see a crudely drawn diagram on the back of a napkin and so to address this, here’s a full diagram. The rest of this post just focuses on the actors part.

To control Christmas lights, we only need a single direction of data, from server to client. Let’s use websockets to do the job through the help of Pusher. Pusher basically gives us a really simple API on top of a raw websocket. It’s also really cheap (free for 100,000 messages per day). They also provide a web hook API for some useful bits and pieces, most notably channels having users in or users leaving a channel. As we get unlimited channels, we’ll represent each of our Christmas lights as a channel with the same name as the actor instance.

I think that’s enough of the cruft surrounding the application, let’s get into the real meat of the application, most importantly our actors. Our actors will only exist in memory when the lights are known to be online and available to the internet, otherwise they’ll be unloaded. We’ll be storing our state in Azure table storage, because it’s A) Highly scalable and B) REALLY cheap (you might be spotting a pattern in my purchasing for hobby projects).

I usually find it easiest to model the messages that I’ll be sending first so let’s do that now, we’ll use a discriminated union to represent our message types.

Let’s now create our actor which maintains our state and handles our messages but wrap it in a reusable function capable of spawning new ones with new names. Our actors will be created using the great Cricket library.

Now we’ll need a way of interfacing with our actor system, to do this I’ll create a couple of simple Web API endpoints to toggle our lights and flash pattern on or off by simply sending our message types to our actors.

For the level of application which I’ve shown here, the actor model is probably verging on overkill but in cases where we’ve been using remote nodes with attached sensors where nodes and sensors have loads of associated state, the actor model has let us build applications quicker and easier.