Close
0%
0%

Iota: Internet of things for all

A low cost Internet of things platform to build your own smart house

Similar projects worth following
Iota is designed to bring The Internet of Things to hobbyists in an affordable and easy to use system.

By making the nodes simple and cheap, Iota allows you to put them everywhere in your house and by providing a common interface, allows you to monitor, control and automate your own smart house.

http://youtu.be/2OtIs6aiwQg

Iota combines cheap AVR dev boards and cheap nRF24L01+ radio modules to create a home network of sensors, and "actuators" which can switch things on and off through your house.

Over time you can build up a custom smart home, all wirelessly and designed to be light on power to allow long run times from 2xAA batteries.

System Design

One of the primary goals of Iota is to make it simple to build a network of sensor and actuator nodes.

It is easy enough to combine a micro controller and radio to send simple messages, but you have to write special code for each case, each new message you want to send.

So as you add more nodes, more combinations, the code becomes harder to write, harder to combine.

Iota solves this by providing a higher level abstraction using the MQTT-SN protocol allowing different messages to be sent without needing special code for each case.

Another thing Iota provides is security.

By default, the radios used in Iota send messages in plaintext, which means anyone can listen in or even inject their own messages.

You might not care if your neighbour knows the temperature of your room, but you sure don't want them switching your lights on and off in the middle of the night!

To protect your network of things, Iota encrypts messages between the nodes and the hub using the AES encryption standard.

  • 2 × nRF24L01+ Radio module Cheap radio module capable of up to 2Mb (mega-bits) per second
  • 2 × AVR ATMega328 16MHz dev board. Compatible with Arduino Pro Mini
  • 2 × CP2102 Serial Converter USB 2.0 To TTL UART Similar to an FTDI chip, but much cheaper

  • Use cases

    nathan.andrew.williams08/19/2014 at 09:40 0 comments

    So what can you do with Iota?

    Iota is a simple framework that is flexible enough to cover many different uses.

    Home automation

    Perhaps the most obvious use case is to automate your home.

    Create rules based on the time, the light levels, temperature, humidity or anything else you can sense to activate lights, open blinds or even send emails.

    • Put a sensor on your cat door and tweet your cat’s movements.
    • Put a light sensor in the window and open the blinds when the sun is shining, close it when it gets dark
    • Use temperature sensors in each room, and find which room is the coldest, use the information to improve that room’s insulation or heating

    Air quality measurement

    Using a CO2 sensor and particulate sensor, work out the air quality both in and outside of your home.

    Plant management

    Track the water level for your plants, turn a pump on to water them when they are dry and you have an automated garden.

    Smart toys

    If you have young children, you probably have many toys that sing and flash, even when you trip over them in the middle of the night.

    Add an Iota node to them and make a rule to turn them off after a certain time automatically, or even control them from your phone when play time is over!

    Smart remote control

    An Iota node with an IR LED can become a remote control for your TV, DVD player etc.

    A few rules later and you can have sequences that turn your TV and DVD player on, wait a few seconds, switch to the DVD input and then hit play.

    Now you can control it all from your phone, instead of juggling remote controls.

    Iota isn’t limited to a set task, its simple design allows your creativity to be the decider in what it becomes.

  • MQTT-SN

    nathan.andrew.williams08/19/2014 at 09:35 0 comments

    The difficulty with writing software to communicate between different systems is that each system needs to be able to understand the other.

    If you send specific messages, the code on both sides needs to know how to understand those messages.

    This causes a problem when you want to start sending new messages that you didn’t plan for before.

    You would have to go and update the code everywhere before you can send it.

    MQTT-SN

    The solution is to provide a common messaging format, and Iota uses MQTT-SN.

    MQTT-SN is a version of MQTT designed for sensor networks where nodes have limited processing and memory.

    MQTT provides a “publish & subscribe” model and allows new message types to be created on the fly without needing special code ahead of time.

    Publish & Subscribe

    The Publish & Subscribe model is a flexible messaging design which allows nodes to publish (send) any message they like, and to subscribe to messages they are interested in.

    MQTT uses a “topic id” for this which might look like:

    /bedroom/master/temperature

    With the above topic id, a temperature sensor in the master bedroom would publish the current temperature, maybe every few minutes.

    The sensor doesn’t know or care if anyone wants to know, it just keeps publishing.

    These messages go to a “message broker” who handles receiving and sending of messages.

    Other nodes might subscribe to the above topic id, and will get a copy of the message whenever it is published.

  • Security

    nathan.andrew.williams08/19/2014 at 02:45 0 comments

    Security is a big part of Iota, something I consider a critical component.

    Iota is about more than sensors spread throughout your house, it can also control things and the last thing you want is for your neighbour to ‘accidentally’ control the lights in your home at 3am in the morning!

    Iota also allows complex rules to be established, such as “if the room temperature drops below X after 8pm, turn my electric blanket on”.

    With complex rules possible, all parts of the system need to be secured, otherwise an attacker could control things by sending fake temperature readings.

    Security - Hard to get right

    One of the strong motivators for including security measures into Iota, is that security is a hard thing to get right.

    An attacker only needs to find one hole in the system, while the person writing the code has to try and fix all holes in the security.

    By including security in Iota from the beginning, everyone benefits from the shared code and fixes made against it.

    We won’t get everything right from the start, but as it is improved and strengthened, everyone benefits.

    Security components

    There are three main parts of Iota’s security design:

    1. Encryption
    2. Message IDs
    3. Key exchange

    Encryption

    As Iota sends messages over a radio link, anyone with compatible radio modules, or even a Software Defined Radio can listen in to the messages sent, resend them, or modify and resend them.

    Encryption hides the contents of the message using a mathematical algorithm and a secret key that should only be known by the communicating nodes.

    This prevents attackers from reading and modifying the messages sent and received.

    Iota uses the AES encryption standard, which is quite strong whilst still being simple enough that it can be done on an 8-bit micro controller.

    Message IDs

    Encryption alone is not enough though.

    If you send the same message repeatedly, it will look the same each time.

    The attacker might not be able to read the contents, but they could copy and replay the message, and still influence your system.

    This is known as a replay attack.

    By simply adding an increasing number (the message id) to each message the encrypted message changes significantly each time, even if the rest of it is unchanged.

    The receiving node knows what message ids it has already seen, and rejects repeated message ids, preventing a replay attack.

    Key exchange

    The last challenge is how to ensure the communicating nodes have the same key without an attacker getting a copy.

    If you send the key over the radio link, it will have to be unencrypted, and during that time an attacker might be listening.

    A better option is to send the key “out of band”, which means through a different mechanism.

    Iota does this through a physical connection (such as wires).

    When you want to add a new node to your Iota system, you connect it to the hub node.

    The hub generates a new random key and sends it over the wired connection to the node and keeps a copy.

    This prevents an attacker from listening in to the key, keeping it safe.

  • Curse of perfectionism

    nathan.andrew.williams08/17/2014 at 23:20 0 comments

    I haven't updated this project for a while, but it doesn't mean I haven't been working on it.

    I confess, I have a problem. I am a perfectionist, and that is not a good thing.

    I like the idea of explaining the design, and then quickly showing a completed prototype. I prefer to deliver than promise too much up front.

    This has backfired on me though as I have been busy at work and let the project languish.

    So it is time for an update about Iota, even without a completed system to demonstrate.

    Goal of Iota

    It isn't too hard to get two wireless nodes talking to each other, but once you go past a single node, with a single job, it becomes much harder.

    The different nodes need to know how to understand each other, adding a new node means changing the code on all nodes that interact with it.

    Iota is an abstraction that lets nodes talk a shared protocol that is flexible enough to add new nodes without rewriting the code on the other nodes.

    Iota also brings security to your network of nodes, no one wants a script kiddie neighbour turning your lights on and off in the middle of the night!

    This is a real problem, there is even another entry that does exactly this:

    http://hackaday.com/2014/08/14/thp-entry-a-433mhz-packet-cloner/

    Security is hard to get right, there are many ways to make mistakes that make it easy for someone to break.

    By doing it once, as open source, only one set of security code needs to be checked and any improvements made get shared by all.

    Long term vision

    Ultimately I hope to get to a point where others are creating Iota hardware. I would love nothing more than to be able to buy nodes that I couldn't have come up with myself.

    I want to see other people be creative with this so I can put sensors and actuators all over my home, automating everything, all without having to tell Google when I turn the heat up or down!

  • Designing the API

    nathan.andrew.williams07/06/2014 at 05:02 0 comments

    Early on in this project I was set on delivering a lot consistently, but I just couldn't keep the pace up.

    Somewhere in those early days I started hacking some "test code" together and it was a mess.

    So ignore the code currently in GitHub, it is all being rewritten, but first I need to design upfront.


    Iota API design

    So this project log is about the design of the Iota API.

    This is what I have so far:

    Setup

    Iota.begin(trigger_pin)

    Publishing

    topic_id = Iota.register_topic(TOPIC_NAME) 

    Iota.send(topic_id, data, len)

    Receiving

    topic_id = Iota.register_callback(TOPIC_NAME, my_func) 

    void my_func(uint8_t topic_id, uint8_t *data, uint8_t length) {} 


    The way you would use this is to call setup on the Iota module, and give it a trigger pin (more on that later, ignore for now).

    Sensors

    Now, if you are building a pure sensor, you would only need the publishing methods.

    The first publishing method registers an MQTT topic name with the system, which gives you a numerical id for that topic.

    From here you can have your code sit in a loop taking samples, sending them through Iota and maybe sleep a little while to save power.

    Actuators

    If your node is out to perform some action, such as turning something on, you would pay more attention to the receiving methods.

    The first receiving method registers an MQTT topic name and a callback.

    When the node is sent a message, Iota will decode the message and activate the callback function for that topic name.

    The basic code structure here would be to register events you are interested in and provide a function to act on that event, and then sleep until Iota wakes you, saving battery power.

    Mixed Nodes

    Of course a node doesn't have to be just one or the other.

    In some cases you might want to sensor something and react.

    For a node like this you might set a timer to wake the node up, take a measurement, send the reading and go back to sleep. At the same time, you have callbacks registered which will also wake the node when an incoming message is received so you can act on it, and once again go back to sleep.


    Now this is an early document and the design might change as it is being developed and tested.

    I am open to suggestions if you see an area I am missing, or a better way to do something.

    Or if you are wondering how you would do something, ask and we can check that it can be done with the above API.

  • Prototypes

    nathan.andrew.williams06/18/2014 at 21:40 0 comments

    I am back at work on Iota, working in the evenings after my little girl is asleep and during my lunch breaks at work.

    It has been slow going, and I am not where I wanted to be at this point, but I have something to show at least.

    I am now liberated from the breadboards!

    At the top right is a node without any sensors at the moment, and to the left of it a USB to serial adaptor to program it.

    At the bottom is the bridge between the EeePC hub and the radio network.

    The controller board in both cases is an Arduino Pro Mini clone based on the AVR ATMega328 chip.

    It is running at 16MHz, and at that speed should be run from 5v, but as the radios need 3.3v, I am technically over clocking the AVR for the voltage, but so far it seems stable.

    In hindsight I should have gotten the 3.3v version which has a slower crystal on board, but if the speed proves problematic, I can divide the clock through software, so it shouldn't be an issue.

    Next steps

    From here I need to get the EeePC updated and communicating with the other node over the radio.

    From there I want to add sensors and LEDs to the node and continue developing the MQTT-SN software layer for communicating between the hub and nodes.

  • The Pi didn't make it

    nathan.andrew.williams06/17/2014 at 11:33 0 comments

    Sorry to say, the SD card slot transplant for the Pi failed, and the poor thing never woke up from surgery.

    (I should stick to through hole!).

    So in its place, I am digging out this old little system to stand in for the hub for now:

    It wasn't what I had in mind, but until I can replace the Pi, it should do the job well enough for now (and it has a built in "UPS"!).

  • Distractions, Setbacks and a little progress

    nathan.andrew.williams06/17/2014 at 10:23 0 comments

    So I have been quiet of late, and I thought it was about time I explain myself.

    Distractions

    To start with, I have this little cheeky girl growing her first few teeth:

    Which has been a bit more stressful than normal, with less sleep and less time to work on things.

    Setbacks

    Along the way I also had my soldering iron break on me, which took a while to fix, and when I finally got it working again, I broke the SD card slot on my Raspberry Pi!

    Not once, but twice!

    First the side highlighted at the bottom, this wasn't too bad, it kept working if held at the right angle, but once the second part at the top went I could only boot the Pi by holding the card in place.

    I have spent a lot of time trying to glue the microSD card adaptor down, and other quick hacks that just didn't do the job.

    So I am going to tear apart an old SD card reader and see if I can do a transplant...

    Progress

    However it isn't all bad news, before breaking things I made some headway on some prototype boards, finally getting away from the breadboards:

    At the top is a bit of a Pi plate for the Raspberry Pi (aka The Hub), bottom left is a CP2102 USB to serial adaptor with an FTDI socket layout and bottom right is the start of a node.

    No sensors yet as I broke the Pi not long after completing the Pi plate, I was actually removing said plate and unknowingly using the SD card for leverage...

  • Tech Blog: MQTT-SN

    nathan.andrew.williams05/27/2014 at 21:22 0 comments

    Iota makes use of a number of different technologies, and I wanted to explain some of them along the way.

    This week will be about MQTT-SN, what it is, how it works and why it was chosen for Iota.

    MQTT-SN & MQTT

    To start with, MQTT-SN is simply a version of MQTT with additional considerations for sensor networks.

    It aims to reduce the amount of data transferred and introduces the ability for nodes to sleep without being disconnected, an important feature for battery powered nodes.

    MQTT was also designed to work over a TCP/IP connection, while MQTT-SN is targeted at wireless radio links.

    A gateway allows nodes using the different protocols to communicate, acting as a bridge between the TCP/IP network and the radio links.

    Apart from these differences, the protocols are largely the same, so the rest of this post will focus on MQTT.

    Read more »

  • Prototyping

    nathan.andrew.williams05/24/2014 at 02:20 0 comments

    Iota is based around cheap nRF24L01+ radios and the MQTT-SN protocol for communications.

    I have been busy doing a mix of hardware and software prototyping this week, with the first steps confirming that the radios work and that I can get them communicating with raw packets.

    Code: https://github.com/NathanWilliams/iota/tree/master/prototyping

    That was easy enough, my next goal has been to build a base set of libraries to communicate using MQTT-SN over these radios.

    The problem is that the libraries I have been using so far (RF24MQTT-SN Arduino) are designed for the Arduino platform. 

    Not that there is anything wrong with that, but my goals are to make as much of the code as platform independent as possible.

    My goal was to reveal that work today, but things haven't gone completely to plan.

    The problem is, I have a 6 month old daughter!

    Having said that, I have made considerable progress, I just haven't gotten it working on hardware yet.

    But in the interests of open development, I am putting the code up as is today anyway, just don't expect it to work yet!

    Code: https://github.com/NathanWilliams/iota/tree/master/mqtt_rf24

View all 11 project logs

Enjoy this project?

Share

Discussions

Daniel Dunn wrote 07/18/2020 at 20:36 point

Some of the work I've been doing for a similar project, but for atmega328 and RFM69 (Although I've been meaning to try porting to NRF) may be useful here.

I have power save beacon mode,over the air pairing like Bluetooth, 64 bit timestamps for the message ID that give you time sync to within millisecond as part of the replay protection, ultra low power beacon frames(I'm aiming for under 10uA, with the ability to wake a device up within a minute), a gateway (Currently requires a Raspberry Pi or other computer, and is integrated with my Kaithem framework,but I'll probably make a standalone version eventually).

My overhead is fairly high, but not too horrible, 12 bytes for the less-secure RT frames, 25 bytes for the full packets with 8 byte MACs, and 9 bytes for a beacon frame, in addition to the low level preamble and sync word(6 bytes for RT, 8 bytes for everything else).

Packet size also doubles if the signal gets too weak, because there's a header bit that will turn on a Golay code to correct errors and give you about 30% more range, it can correct 3 out of 24 bits.

In practice I don't think that's as much of an issue because of the automatic TX power control algorithms to keep from crowding the airwaves.

I also have mesh network support planned for one or two hops, I'm hoping I can just use a heuristic and repeat anything weaker than -55db, unless we see a very strong copy of it while waiting a random time to send it.   I think that should be fairly efficient with bandwidth.

What I don't have is an application layer, just a pipe to send raw messages.  I'd really like to define a standard way to read, write, or request registers so things could be truly plug and play though.

https//github.com/EternityForest/SG1

  Are you sure? yes | no

seilerjacinda925 wrote 11/19/2019 at 15:44 point

Hi

Nice to meet you after viewing your profile i am Jacinda, from (jakarta) indonesia,

i have a project discussion with you please email me on: (jacinda.seiler@yahoo.com)

  Are you sure? yes | no

Neil Cherry wrote 05/15/2015 at 13:40 point

Nathan, very cool! I'm building something similar. I'm currently using a Chipkit UNO32 or Fubarino Mini (PIC32 as opposed to an AVR, but I have Arduinos also), a W550io board and sensors (usual assortment). I'm working with MQTT but will check out MQTT-SN also. I have it talking to Misterhouse and Node-Red. I hope to get Homeseer 3 talking to MQTT so it can join in. :-)

I'm going to take a look at the AES library and work it into my existing code. Thanks for the ideas.

  Are you sure? yes | no

plinio wrote 12/07/2014 at 10:02 point
Get AES on Atmega328 looks quite hard, have you get it working in software? The best is using a radio transceiver with AES in hardware.

Dario.

  Are you sure? yes | no

nathan.andrew.williams wrote 12/12/2014 at 09:37 point
Actually the hard work has already been done:
https://github.com/DavyLandman/AESLib

Using a radio that already has it would make it more expensive.
Doing it in software would allow me to make a node that uses a $1 radio and $2 AVR.
If you know of a radio that provides AES encryption cheaper than that, I would love to know!

  Are you sure? yes | no

Daniel Dunn wrote 07/18/2020 at 20:46 point

I don't know of radios that do, but  ChaChaPoly is a little lighter I think, and it's a stream cipher, so you don't have to pad messages to 16 bytes to use the authenticated modes.

RFM69s have AES, but I don't use it because it seems to be a near useless unauthenticated ECB mode.

  Are you sure? yes | no

Jimmy wrote 10/25/2014 at 13:32 point
Great project! This IoT technology is going to be the future of mass device automation and spark new generation collaborative community, really exciting stuff.
However, I would like to know what separates your project from an existing one called "The Thing System" as seen here http://thethingsystem.com/. It appears to me that both are attempting to accomplish the same but with slightly different communication and management methods.

  Are you sure? yes | no

Eric Tsai wrote 07/04/2014 at 21:05 point
Hi Nathan, your project is very similar to mine. I totally understand about "distractions". Mine little girl is turning 6 months :)

  Are you sure? yes | no

nathan.andrew.williams wrote 07/05/2014 at 06:11 point
Wow, I love your project!
Thanks for introducing me to OpenHAB, I hadn't heard of it before and you have just opened my options up.

I hope you will find something useful to take from my project in return!

Good Luck!

  Are you sure? yes | no

Adam Fabio wrote 06/14/2014 at 06:37 point
Nice idea Nathan - thanks for submitting the Iota to The Hackaday Prize! I love those nRF24 Radios - and having a simple way to get nodes online through your hub will be great! Looks like you've got the "connected" side of things well covered - but keep those photos coming in once you've got your prototypes underway.

  Are you sure? yes | no

nathan.andrew.williams wrote 06/14/2014 at 09:37 point
Thanks for the support!
I have had a couple of set backs lately, along with a 6 month old getting her first few teeth.

I hope to get some new updates out soon.

  Are you sure? yes | no

Samuel Wittman wrote 05/27/2014 at 22:40 point
Yeah, I dunno much about hardware, either, just that switch boxes are expensive, especially as the numbers get higher. If you can get away with it in software, like a giant computer with capture cards and outputs, that would be ideal, and would make playing around with audio much easier. This is definitely an expensive option, but I believe less expensive and more featured than manual switches.

As for consoles, the power point doesn't work, especially on modern and future consoles. All require some sort of physical button push to go from off to on, and the repeated blackouts would eventually be damaging.

  Are you sure? yes | no

Samuel Wittman wrote 05/27/2014 at 17:22 point
Hm. One cool thing that might not be easy is turning gaming systems on and off. Since controllers are bluetooth now, it should be possible to connect to each console with bluetooth and send whatever "start console from controller" command and then temporarily shut off so that this frankenstein device doesn't eat up a controller slot. This would probably require canibalizing a controller for each system, which may be a bit expensive unless you use cheap chinese alternatives, which isn't a bad option.

As far as real AV stuff, in an ideal world, I'd like some magic box that offers n*k switching over ALL types of inputs, giving the ability to put any video input (games, computers, vcrs) on any video output (monitor, tv, projector), including the same stream on multiple sources, and different streams on different sources simultaneously. I'd like to do the same thing for individual audio channels, independently of which video source it belongs to, so I can hotswap which speaker is playing which channel, as well as control relative volumes.

Light control, including rgb, is a must. Also some ability to specify complex behaviors. I'm imagining a system where, when I put a video on my projector, my lights turn off and my blinds close. If someone rings my doorbell, my lights come on.

Two features I'd love to see, but probably aren't easy, are voice control and in-home person tracking. Say I'm watching tv or netflix as I do housework. As I walk from room to room, my video follows me to whichever set of AV equipment is in that room. Another, easier example would be lights. My roommate likes to have the lights on everywhere, but she tends to leave them on. If lights could come up in the rooms she's in and turn off behind her, I'm sure I'd save a ton on the electric bill.

  Are you sure? yes | no

nathan.andrew.williams wrote 05/27/2014 at 21:40 point
For the consoles, would it be enough to switch the power point?
That would probably be easy for turning it on, but I guess regular black outs to the console might not be best for its health... (It used to be simpler before they had hard drives!)


As for the AV switching, I can imagine modifying a HDMI switcher box easily enough, but the analogue channels would be harder (VGA, composite, audio etc).
I'm just a software guy with a hardware hobby, so I don't know enough about if you could switch them through solid state relays or if there is a simpler option.

Voice control might not be as hard as it seems, there are voice recognition modules like this one: http://www.robotshop.com/ca/en/easyvr-speech-voice-recognition-module.html

Or you could get some voice recognition software on a Raspberry Pi possibly.
I can imagine pairing that with a bluetooth dongle and headset to let you roam the house while turning things on and off!

As for person tracking, you could get away with something simple like IR motion detectors, but trying to tell who is who would need something like a Kinect and clever software (most likely beyond my skill set).


As for the doorbell and movie example, I can completely imagine it.
When you hit play on the remote, the system detects it and triggers the blinds.

When the doorbell is pressed, the system could play back the IR remote signal to pause the movie and then simply turn on some side lamps via a relay, or if you are feeling adventurous it could be wired in to the room's light switch!

  Are you sure? yes | no

Daniel Dunn wrote 07/18/2020 at 20:41 point

I have working offline voice recognition in Gstreamer with pocketsphynx, haven't tried it on the pi but I hear it works.  It works great on regular Linux, I can just go to the web interface for the virtual mixing board, create a mixer channel that has the recognizer as an output, and connect the input to a microphone.

The key to using pocketsphynx is to only use keyword and keyphrase spotting more, accuracy is pretty much trash as far as I can tell in full transcribing mode.

There is also Mozilla's deepspeech which runs on the pi 4 and apparently has seriously awesome accuracy, but I don't have a Pi 4.

  Are you sure? yes | no

Samuel Wittman wrote 05/22/2014 at 16:59 point
This looks frickin sweet. I've been contemplating something similar, but in a wired format for the purpose of some interesting AV controls.

  Are you sure? yes | no

nathan.andrew.williams wrote 05/24/2014 at 02:36 point
Thanks!

I have so many great ideas to build on top of this, I just have to get the foundation done first.

What kind of AV controls do you have in mind?
I'm looking for more example "use cases" to help explain what I am trying to achieve.

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates