Our plants need watering, part I

Here at Isotoma Towers we’ve recently started filling our otherwise spartan office with plants. Plants are lovely but they do require maintenance, and in particular they need timely watering.

Since we’re all about automation here, we decided to use this as a test case for building some Internet of Things (IoT) devices.  One of my colleagues pointed out this great moisture sensor from Catnip (right).

This forms the basis of our design.

There are lots and lots of choices for how to build something like this, and this blog post is going to talk about design decisions.  See below the fold for more.

 

As a systems architect I wanted to explore real-world concerns with deploying IoT units in the field, rather than just play.  Microcontrollers have very small amounts of RAM and are comparatively slow so they need to be programmed at a low level, either in assembler or C.

I used to write assembler for the venerable Acorn ARM 2 based machines (many many many years ago) and I was once a full-time C programmer, so I kind of know what I need to do.  I am woefully out of date though, so a lot of this stuff is very new to me.  It seemed to me that my experiences here might be useful to others, since I am going from very low levels of knowledge.

Since I want to investigate real-world concerns that means that I think the following things are important:

1. Cost of deployment
2. Ease of deployment
3. Batteries – how many, what sort and how frequently do they need to be changed
4. Packaging
5. In field upgrades and reconfiguration
6. Robustness
7. Security

I’m going to aim for monitoring around a dozen plants, and we’ll assume there will be a nice web/mobile interface with automated alerting – that bit I already know how to do.  If we can get our device status into the cloud the rest is easy.

This blog post will discuss the overall design of the units.  In the next post I will talk about software issues and tooling, and in the final blog post I’ll talk about the results and real-world challenges and hopefully show some progress.

We’re AWS Partners (plug), and I decided to use the Amazon Web Services Internet of Things services as the basis for the design.  This gives us a bunch of relatively simple services out of the box which assist with IoT deployments.

Design iteration 1

The Catnip moisture sensor talks I²C (I-squared C), a neat serial protocol for devices to talk to each other on a single PCB (printed circuit board).  Assuming your components have a shared power (Vcc) and earth (GND) then it needs only two lines – a clock and a data line.

We’re going to need a microcontroller unit (MCU) of some sort to talk to the moisture sensor.  An MCU is like an entire computer in a single tiny package, with just enough capability to do what you need. There are many many options for this, and I’ll talk about them a bit later.  Getting this right is one of the more interesting and challenging choices.

I got out my big old box of electronics and pulled out some components that might be useful.  Since we want ease of deployment we’re going to want to go wireless – nobody wants lots of cables trailing around.  I have some experience with these XBee ZigBee Radio modules (right) –  they are low power and relatively low cost at around £15, so they seemed a decent option.

We can’t talk directly to AWS over the ZigBee radios, so we’re going to need a base station plugged into a computer of some sort (maybe a Raspberry Pi) – and that means a lot of the heavy lifting can be done on the real computer in Python (a much easier language to use than C).

The XBee devices also need only 2 serial lines, so we need an MCU with (so far) 4 IO pins.  It’s pretty hard to find an MCU with less than 4 lines.

The ZigBee API mode will require a decent amount of RAM to process, so we need an MCU with a little bit of power in it.  After some experimentation I got this basically working with a Teensy 3.2 development board. These are really excellent Arduino-compatible boards that use the ATMEGA32U4 CPU with 32K of Flash, 1K of EEPROM and just over 2K of RAM.  They cost about £15 for the board.  If we were building this in bulk we’d get the MCUs alone for about £5.

We’re only going to need to read the soil moisture once an hour or something, and it is a princely two bytes long, so data rates are really not a problem.  We can clock this thing low.

So the first design looks something like this:

Here’s an image of the teensy and the xbee together, with an Arduino Due as an I2C device for test purposes:

So how do we score on our objectives with this design?

Cost of deployment	Moisture sensor £10, ZigBee £15, MCU £5.  With packaging etc. we can get this in at around the £40 mark per plant.  But then you need a PC with another ZigBee unit, so that’s perhaps another £50.  If we have 12 plants that’s a total of perhaps £500.	PRICY
Ease of deployment	The ZigBee units are amazingly easy to deploy.  They automatically form a network, so that is straightforward.  However setting up a raspi, installing the software and connecting it to the internet is kind of annoying.  Also we need to map each device to some sort of plant metadata in the back-end.  This is all OK for a hobbyist, but no good for consumers.	DIFFICULT
Batteries	Minimising power for this sort of device is really about managing sleep modes.  We need to power the whole thing down as much as possible while we’re not doing any actual sensing.  The ZigBee is very good for this.  The ATtiny85 draws very little as well.  I think we can run this from 2 watch batteries and get many many months out of them.  The raspberry pi needs plugging in, but lets ignore that for now.	EXCELLENT
Packaging	again apart from the server component, this can be easily packaged into something robust and attractive.	EXCELLENT
In field upgrades	This is more difficult.  The device would need to be plugged directly into a PC and new firmware blown onto it.  Again ok for hobbyists but annoying (and difficult) for the consumer.	POOR
Robustness	The ATtiny85 and the XBee are rated for industrial temperature ranges.  The XBees are great at reconnecting and the radio mesh protocol is very good.  It is quite sensitive to environment though, and the range is variable – perhaps as low as 8m in the wrong conditions.  This could get annoying.	MODERATE
Security	You might not think this is important, but it really is.  IoT devices are a great way into a network for an intruder because of their poor level of maintenance.  We can run the XBee units in a secure mode with AES encryption between points, and optionally we can deploy our own keys (although it makes deployment more difficult).  All communication with AWS is from a linux machine that we can take some appropriate steps to secure.	GOOD

Not a bad result, but it is definitely worth considering some alternatives.  In particular the price and ease of deployment are problems.

Design iteration 2

We have to have one Catnip sensor per plant so we can’t do much about that from a cost perspective.  However, plants are often co-located so perhaps we can connect multiple sensors to a single transceiver.

To reduce the cost we can perhaps have multiple plants connected to one ZigBee and ATMEGA unit – since that’s the expensive part.

We can’t run I2C reliably over those sorts of distances.  We need some way to get serial data over longish distances, ideally with very cheap cable.  Enter the MAX485 (right).

This is a very cheap (30p) unit to implement RS485 a long-distance serial protocol that supports daisy-chaining.  The MAX485 has normal TTL logic on the outputs, so we can connect this straight to something on our sensor board.

We’re going to need yet another MCU on each plant, which will sample the I2C readings and then send them to the MAX485.  The Microcontroller doesn’t need much oomph – it needs to be able to read and write I2C, read and write a serial protocol and have 4 pins.

Atmel do a great line of “tinyAVR MCUs” called ATtiny.  These are low-power and super cheap. The ATtiny85 is a pretty good fit for our requirements.  They cost around 65p each in bulk, and have 8 pins in a nice convenient inline package, which you can see to the left.

These have 5 spare pins (after Vcc, GND and Reset), and we only need 4 so we even have a whole spare pin!

The reason the ’85 is so cheap of course is it is… limited.  As with many of these low-end MCUs the clock speed depends on the supply voltage, and you can ramp up or down the voltage.  We’re going to want to run this from batteries, so 3V is a convenient voltage.  That means we get 20MHz.  It has a whole 8K of flash, 512 bytes of EEPROM and 512 bytes of SRAM.

20MHz would be ample… but the tiny line doesn’t have a USART unit, which provides serial support.  That means we’d need to do all our serial processing on the CPU itself – a technique called ‘bit-banging‘.  This is ok at low data rates, and we don’t need a very high rate for this application.

Here is the moisture sensor and a USB/TTL interface connected to a tiny85 dev board for testing:

So here’s design number 2:

So many parts!

This primarily reduces cost.  Now each plant needs only £1 worth of electronics, if it is near another plant.  Lets assume our plants are in 4 groups of 3.  Then we’d need 4 transmitters (£25 ea.), and 12 sensors (£15 ea). Then we need the £50 base station.  All in this is £330.  However we now have a bunch of trailing wires, which is going to make this harder to deploy and less robust.

Still not a great solution.

Design Iteration 3

While I love the XBee units, they are a significant part of the cost.  I therefore investigated some other options. If we’re in a domestic environment then there’s a good chance there is already WiFi present – perhaps we can use WiFi?

I had assumed WiFi would be expensive, but remarkably it isn’t.

The unit to the right is the ESP8266 wifi serial transceiver.  This has its own processor on board  and it implements its own TCP/IP stack.

Amazingly these cost only £6, which means it is significantly cheaper than the XBee.

Finally if we have WiFi support then we don’t need our base station.  This hugely improves ease of deployment – potentially this could be a consumer device.

Here’s what it looks like:

That’s an awful lot simpler isn’t it!

We’re going to need a more powerful microcontroller though.  To implement the AWS IoT protocols we’re going to need to support TLS cryptography and we’re going to handle X.509 certificates.  I’ve done some sums and I think we’re going to need 20K of RAM minimum.  We’re also going to need an SSL stack (WolfSSL is the one I’ve been experimenting with) and, probably, a decent onboard embedded OS (such as FreeRTOS).  This is going to need 30 or 40K of Flash, minimum.

Something like Atmel’s ATSAM4LC2 (right) would fit the bill from the looks of it, with good low power performance 128KB of Flash and 48MHz, which should be ample.  These cost, remarkably, under £3.

The Arduino Due has a similar MCU at its core, the snappily named ATSAM3X8E, and this is what I have been experimenting with.

Lets see how this scores:

Price	So now we’ve got a unit that costs £10 for the sensor, £3 for the MPU, £6 for the wifi. With packaging, batteries etc. we’re looking at perhaps £25 per unit, with a total price for 12 plants of £300.  If we combine the secondary “headless” RS485 concept from Design 2 we can squeeze it even lower.  the headless units cost £15 and our “headed” unit would be £25, with an inbuilt sensor. we need one head and 2 headless per 3 plant cluster, which is £55 per cluster or £220 in total.	BETTER
Ease of deployment	After turning the units on the consumer will need to go through a wifi config handshake (connect to the unit as an AP, tell it the wifi network and password, reconnect, give the unit a cert).  With some server-side support this is going to be a pretty pleasant operation.	GOOD
Batteries	Sleep mode for the MPU is good.  We can turn off the wifi module entirely when we don’t need it. Although it draws a lot more power when operating, we can minimise this.	GOOD
Packaging	Still good – none of the components are huge.  We’ll need to see how well the antenna fares though.	GOOD
In field upgrades	We’ll still need to plug the devices into a computer for upgrades unfortunately, but the units can manage themselves a lot more effectively with the more powerful MPU.  It is conceivable that, for another £5 per unit or so, we could make them reprogram themselves over the air (an ATtiny85 and some flash memory could work as a reprogrammer on board).	EXCELLENT (if we can get a separate reprogrammer working)
Robustness	With less components it becomes more robust.  WiFi can be flaky though.  We’ll have to see how this works in practice.	GOOD
Security	Less components means less things to secure – but we’re now implementing some pretty challenging security protocols directly in C on an embedded microcontroller.  This is going to be worse, there’s no two ways about it.  We need the in field auto upgrade feature to really be sure we can manage security.	QUESTIONABLE

 

Conclusion

So we’ve gone from over £500 to perhaps £200 for a “normal” deployment, and we’ve got something that looks like it might work. However, there is an awful lot left to do, including the non-trivial matter of getting our embedded device to talk to AWS!

The next post will talk about how I’ve been experimenting with doing this.