Close

Does this project spark your interest?

Become a member to follow this project and don't miss any updates

The Moteino Framework

Automation framework based on wireless Moteino nodes.

7.4k 16 156 161

This project was created on 07/30/2014 and last updated a month ago.

Description
The Moteino automation system is a decoupled framework of internet connected things designed to add convenience, monitoring, security and safety to a residence, living space and beyond. It is powered by a range of devices that are based on the Moteino wireless Arduino compatible development board. The small size and versatility enable you to build low power nodes that gather environmental data, or devices that control things in your home.
Details

Overview video

Demo video

Introduction and mission statement

I have long wanted to build my own automation framework for my residence. All existing solutions were either expensive, poorly designed, underperformant, bulky or not versatile enough for what I needed. So I created the Moteino, a low power wireless Arduino compatible based on the popular Atmega328p chip, that accepts RFM69W/HW/CW or RFM12B transceivers on reverse, is of SD card size, is wirelessly programmable and can fit in very small enclosures.

Among other things, I wanted this system to be:

  • Open source
  • Easy to build/replicate by those with some Arduino experience
  • Easily extensible and customizable
  • Inexpensive compared to other systems like Z-wave and Zigbee
  • Use common parts/sensors that are easy to source
  • Main components should have a very simple design, no exotic or complex frameworks/compilers
  • Easy to scale and hardware build with manufacturability in mind

Sample integrated devices

Once I tested a few revisions of the Moteino and I had a robust revision, I started conceptualizing several devices that would make it easy to monitor or control certain things like:

  • Mailbox via MailboxNotifier (aka MailboxAlert or MailMote). This little sensor box can run for many months on a small LiPoly battery and reports back motion detected at the mailbox, battery level, and the last time the mailbox was opened. It became one of the most loved Moteino based devices at our house, and very popular blog project. The love for this device grows more with every Michigan winter storm. Thank you MailboxAlert!
  • Garage door via GarageMote. This device can detect the garage doors position (open, closed, unknown), and trigger an open/close action. Very useful on those stressful days when you wonder if you closed the garage.
  • The sump pump mote via an ultrasonic sensor. Going on vacation? If your sump pump fails you could come home to a few feet of water, so better safe than sorry.
  • Motion via the MotionMote. Care to know when there's motion in your house when there shouldn't be any? Me too!
  • Lights via SwitchMote. Swap your current mechanical light switches with SwitchMotes and control your lights wirelessly in addition to the new push button. They work at 120-250V but are designed to fit US electrical boxes.
  • Water meter via a photo reflective sensor. Useful to monitor water usage for potential pipe breaks or water leakage.

System design

Artistic diagram

Self imposed requirements

To make it truly useful, flexible and secure, I imposed several critical requirements for my Moteino automation framework:

  • Remote SSL secured control. The RaspberryPi gateway computer can relay a SSL secured web interface to the internet allowing the owner to check status and take actions from anywhere on the internet.
  • Real time updates. Secure sockets allow the remote interface to receive real time updates from the Pi gateway. No more boring browser refreshes.
  • Wireless over-the-air programming of critical devices or those enclosed in difficult locations (especially the SwitchMote which is wired to mains and attached in electric boxes behind covers).
  • Use the RFM69's hardware AES128bit encryption for secure wireless communication
  • Allow Email/SMS/Pushover notifications
  • The central Moteino+RaspberryPi gateway computer has to survive a power outage and continue to receive critical messages from battery operated nodes such as MotionMote.
  • Components have to be easy to source, manufacture and system easy to scale. The network can be extended with new Moteino based devices at any time without changing the topology or disturbing existing devices.

RFM69 library

I've spent several weeks developing the RFM69 library which I made free and open source, is now widely used in RFM69 based projects, and now also used in several other THP entries. I'm very happy others found my work useful and I applaud project such as the Reactron Overdrive and PlantFriends  which used Moteinos (or clones) and RFM69 library and took...

Read more »

Components
  • 2 × Moteino The heart of the "Moteino Framework". A little SD-card sized breadboard friendly, wireless equipped, atmega328p based development board. Would need at least 2 to make a framework of things. Also a USB version is available and the new MoteinoMEGA for larger more memory intense projects. https://lowpowerlab.com/Moteino
  • 1 × RaspberryPi This is my choice for this framework and was used to develop the central gateway that communicates with the rest of the Moteino Framework and also delivers secure websockets and live updates to internet clients. http://www.adafruit.com/product/998
  • 1 × MotionMote and MailboxNotifier Itself a kit of several components, makes up a truly wireless low power motion sensor. https://lowpowerlab.com/motion
  • 1 × SwitchMote Kit Use a few of these to replace your traditional light switches and sync your lights or control them from the internet. https://lowpowerlab.com/SwitchMote
  • 1 × GarageMote Kit Install one on your garage door, add a Moteino and your garage is on the internet! https://lowpowerlab.com/GarageMote
  • 1 × PowerShield and HC-SR04 ultrasonic sensor The HC-SR04 needs 5V so I used a PowerShield to provide that from a LiPo battery. This is for the sump pump sensor and a parking assist project that I may also add details later. https://lowpowerlab.com/shop/powershield and https://lowpowerlab.com/shop/HC-SR04
  • 1 × EE-SY310 photoreflective sensor This is for reading the water meter, might also work for analog electric meters. https://lowpowerlab.com/shop/EE-SY310_breakout

Project logs
  • Final Motion-OLED Prototype

    a month ago • 0 comments

    I've enhanced my Motion-OLED Moteino project and added a few more features to the already existing ones:

    • a general purpose button which is wired to interrupt 1 (pin D3) of the Moteino. This is useful to wake it up from sleep and respond to whatever command you have it do. For instance, I've programmed it to browse through past received messages from the wireless network, or it can be used to access a user menu where you can choose different modes of operation.
    • The OLED can display anything you want. I like to keep the OLED mote in the kitchen area where it provides a hands-free alternative method to check the "snail mail". The periodic messages received from across the street (thanks to the powerful and very small RFM69 transceiver) are displayed on the OLED with the last time the mailbox was opened, very convenient.
    • The ON-OFF slide switch can cut power from the LiPo battery, which in my case is a 1300mAh which lasts about 3 days with the OLED kept ON and the transceiver in RX mode all the time to listen for messages.
    • The USB port allows easy programming from the Arduino IDE and also charges the battery in about 2.5 hours when fully discharged.
    • A buzzer allows you to hear when a messages is received, or to alert you when mail is delivered, a garage door opens, a light turns on, etc.
    • And of course, the same PCB/kit can be used as a low power motion detector by inserting a PIR sensor instead of the OLED display, quite versatile.
    • I've discovered thinner acrylic makes for very nice cases that are easier to assemble and I might switch from thicker 3mm acrylic for such enclosures. Acrylic is found in many colors and shades which means these enclosures can be of many colors. Just look at a variety here.
    • this kit will replace the current MotionMote kit and will also be usable as a mailbox notifier and standalone receiver for those who just need a motion or mailbox sensor and are not interested in the whole automation framework.

    As of today I am still waiting for production PCBs to be delivered and tested, and once everything is confirmed ready to go I will post the details and sample source code for the OLED display shield. For now here's a sneak peek of what's coming:

  • Closing the Security Gap

    a month ago • 0 comments

    HTTP(S) and Websockets Security

    There are a lot of open source home automation attempts out there. Many are missing some essential security that leaves them vulnerable. Those that actually allow the user to control physical things in their home are especially vulnerable. An attacker could gain control and cause an appliance to turn on-off repeatedly causing a hazard, could gain access to the home by opening a garage or door, or could just watch for human activity for other evil purposes.

     I knew that getting ahead of the crowd meant imposing some strict requirements including physical and virtual security to restrict access only to those authorized and minimize the chance of an attack.

    Sure, anyone can add some authentication, not a big deal. And it's not too hard to add SSL. I had thrown web sockets in the mix for real time updates (cf polling as a method of "updating" on end clients). So web sockets had to be secured as well. Since the node.js websocket server runs on a different port than the webserver, rather than securing two channels of communication (webserver and websockets) I implemented what I believe is the first OSHW home automation interface with real realtime two-way communication between the webserver and the clients, by marshalling the websockets through the webserver itself, and thus obfuscating the internal websocket port. Hence both the webserver and websockets traffic run on the same SSL port 433. The websocket server is obscured and any non localhost requests to it are blocked. The details of this implementation are extensively documented in this article on my blog. HTTP-Auth authentication blocks any intruders from accessing the web interface. Below is a diagram of this whole scheme.

    Wireless Security

    Another important aspect of security is obfuscating the wireless requests and making it harder or impossible to decode. This is achieved with hardware AES128 encryption on the wireless transceivers such that any wireless packets to and from the end nodes cannot be decrypted by an attacker.

    A more sophisticated attacker armed with a  $20 RTL-SDR dongle and laptop could listen for more extended periods of time and record messages and then replay them in hope to cause a door to open for instance. Such a simple portable SDR solution (cf. portableSDR project) is elegantly explained by w2aew in this video:

    Hence the remaining gap to fill is implementing an algorithm to thwart any replay attacks for those critical commands that control physical things like appliances, lights, garage, doors, etc. This is essentially a way to salt each wireless packet with a sliding window type signature such that if it's replayed it would be obsolete. Until this is implemented, one can tune their end node transceivers output power to only be powerful enough to reach the home gateway, which would be recommended anyway to avoid polluting the RF traffic in your neighborhood. So unless you have a curious close-by neighbor with radio knowledge who might eaves drop on your RF traffic, it would make it harder for an external intruder to get physically close to your home/location to record your traffic and try to mess with it via replay attacks.

    Rolling code vulnerabilities

    It seems a lot of key fob entry systems like auto locks and garage openers are using rolling code to secure their wireless communication. The transmitter increments a number in the packet with each subsequent transmission. The receiver remembers the last received token and knows what token or series of tokens are expected next. This attack involves blocking/jamming legitimate signal, then replaying the intercepted legitimate signal. Because of the jam, the receiver never receives the legitimate signal with the expected new token and thus the replayed message will appear legitimate.

    I found ...

    Read more »

  • Architecture decisions

    a month ago • 0 comments

    My vision for Moteino Framework was to create an affordable/open/ideal/easy hardware platform that would fuel a new generation of wireless internet-of-things, and I think it came out pretty decent. My Hackaday Prize entry even made it in the top 50 semifinalists (out of 800+). More devices are being added to the Moteino Framework and existing ones are being improved to make it fun for those makers who like to DIY and solder their internet-of-things from easy to assemble kits. The end users have maximum freedom as far as using/building stuff with Moteino. They can build absoltely everything from scratch, as some have done, but some prefer to just save time and buy building blocks. Hence I funded my way through this adventure by selling ready made Moteinos and kits in my online webshop.

    People have asked many times why the Moteino was designed the way it was, and why not use this and that and the other type of MCU, transceiver type, radio band, or wireless technology. The number one reason why Moteinos are what they are today is because in the end they need to be designed to manufacture, work well, be reliable, license free, easy and fun to use in a friendly board format, cheap to buy or make, achieve long open air range or excellent indoor obstacle penetration when used with transceivers, etc. Here is my reasoning behind all these decisions and the answers to some frequently asked questions.

    MCU choice – Why not ATTiny/ARM chips? They are cheaper!

    Because it makes little sense, economically and practically, for what I had in mind. ATtinys are very memory challenged (typically FLASH not more than 8KB and SRAM not more than 512b), are somewhat supported in the Arduino IDE with some tweaks, don’t generally have real dedicated SPI/i2c/serial hardware support (some have SPI or serial). The bootloaders typically take a big chunk of the already limited FLASH. They cost  less than an ATMega328 but the savings would never justify the features tradeoff unless for projects where all you need is a few I/O and you program it once and never have to touch it again. In fact some of the “larger” ATTinys are getting close in price to the popular ATMega328. ARM is a steep learning curve, the chains are not very easy to get going and the large fine pitch SMD chips are harder to get started with unless you get ready made development boards. Tools are also costly and the general public has an easier time with Arduino/AVR.

    Could be much smaller with ATTiny or with other board layouts/set of hardware
    Really? I could shrink the Moteino to the size of a fingernail (I actually did a project where the diameter of the circular board was 10mm with a QFN-28 ATMega328 on it, no kidding, the ICSP was on a header that would snap off after programming, leaving the circular 10mm finished board). You can do almost anything you can put your mind to. The big question is are they designed for manufacturability? Are they easy to use to the average electronic hobbyist as well as for the experienced maker? Are they a building block for greater things or are they a stumbling block? I am personally willing to invest a few bucks more to get the luxury of a tool that is not a pain to get started with and just works.

    Why not CC1101 / NRF24L01 / other cheap ebay transmitters?

    NRF2

    I really wanted to like these and I’ve done my own open air range testing with these NRF radios before I moved on to settling on RFM69. They are simply hopeless in terms of range. They have higher power versions (the PA+LNA) but those are hopeless in terms of size and power consumption and cost several times more than a RFM69. Most versions I’ve seen have a 2×4 header that was a challenge to fit flat/tight anywhere.

    Why not use “inexpensive off the shelf” transmitter and receiver pairs? After all, they are just $1 on ebay!

    transmitter

    Wow, I’m not impressed. They are inexpensive and you get what you pay for, a leg or an arm. I want a full set. You...

    Read more »

View all 8 project logs

Build instructions
  • 1

    The Moteino Framework is made up of many different devices that have their own build instructions. Each device has been linked in the description and in the logs to their own page on my blog where you will find instructions, sources, guides. Most build instructions for the various projects can be found at http://www.lowpowerlab.com/ and cab generally be accessed through the main menu.

    The Github repositories containing source code, eagle files, and any CAD/visual data are found here.

See all instructions

Discussions

anthony.webb wrote a month ago null point

One of the real critical components to a project like this is the packet/msg design and how to identify devices and their properties on the network. This may be beyond the scope of the this HaD project, but have you given any thought on on the packet/msg protocol that the devices would use to share state, etc? I presume you have something you are using in your own project, is it something you would be willing to share?

Are you sure? [yes] / [no]

Felix Rusu wrote a month ago null point

That would be more of a transport/app layer, you can certainly do that. What I mainly provided was a network layer. You can implement a struct kept in EEPROM that describes the physical properties and description of a node that can then self publish. I did something like that for SwitchMote - see the SwitchMote config sketch: https://github.com/LowPowerLab/SwitchMote

Are you sure? [yes] / [no]

rileyporter wrote a month ago null point

The amount of work and expert documentation is amazing. I am using your boards + library for my home automation projects. I hope you and your family the best and please continue to do amazing things. For the judges or others, I have to say that as a security engineer by trade the required encryption in your code is a breath of fresh air!

Also kudos for your project being used in other HaD projects! Good luck!

Are you sure? [yes] / [no]

Felix Rusu wrote a month ago null point

Thank you sir, I appreciate your comments :)
My best wishes to you as well!

Are you sure? [yes] / [no]

David Cook wrote a month ago null point

Hey Felix,

Thanks for including LoFi in your architecture log posting (I see its distinctive yellow pigtail poking into one of your pictures). I appreciate all of the hard work you’ve put into Moteino over the years, including the many revisions, and extensive support. I hope it is selling well for you.

Even though we are competitors in this event, we obviously share the same passion. If you are ever in Chicago, drop me a line so we can meet up.

Best of luck,

David

Are you sure? [yes] / [no]

Felix Rusu wrote a month ago null point

Hey David, thanks for your thoughts. You're actually far ahead in the competition (vote wise), and you've put a fair amount of work, congrats. It's about less than 1.5 years since I started making the first Moteinos so not very long. I love Chicago but we end up driving there only when we have friends over who've never been and they want to go with us. Thanks for the invitation :)

Are you sure? [yes] / [no]

Richard Johnson wrote 2 months ago null point

Nice project.
How open is the network of the devices?
Is it possible to be hacked? I don't like RF control systems for this reason.

Are you sure? [yes] / [no]

Felix Rusu wrote 2 months ago null point

You have a choice of AES128bit hardware encryption on the wireless transmissions. Then you can implement your own algorithms to avoid any potential replay attacks (which BTW would require a fairly high tech attacker).

Are you sure? [yes] / [no]

Eric Tsai wrote 2 months ago null point

Hi Felix. I'm a fan of your RFM69 library, and use it in my own Hackaday project. Glad to see you on here! I've been using your RFM library to integrate wireless sensors into another home automation platform called OpenHAB, and it's been really great.

Are you sure? [yes] / [no]

Kenji Larsen wrote 2 months ago null point

Congratulations, Felix, on being a THP semifinalist - you certainly deserve it!

Are you sure? [yes] / [no]

hneiraf wrote 2 months ago null point

Moteino is definitively the best RF integrated Arduino clone.
I've tried others, but moteino is far the best option.

Are you sure? [yes] / [no]

Fernando Faria wrote 2 months ago null point

Really nice project.

Are you sure? [yes] / [no]

Don Oldridge wrote 3 months ago null point

Great project, it looks like it will address a number of problems, and make it easy to add new types of sensors and automation. Kudos on a well-documented project that looks great.

Are you sure? [yes] / [no]

Jasurbek wrote 3 months ago null point

Very nice, can you measure the time of flight between two sensors ?

Are you sure? [yes] / [no]

Saxx wrote 3 months ago null point

I have bought about 8 Moteinos and now use them as temperature and mumidity sensors around the house. I have connected one as a gateway to my server that logs temperature, humidity, uptime (Moteino battery life), RSSI and battery voltage. The data is uploaded to a MySQL database using my own API.

You can read about my projects on my http://www.borngeek.net/ (Not updated in a while tho...)

Now I'm making v3 of the logging system with display and barometric pressure in addition to the above mentioned.

Thanks for the Moteino and expect more orders from me :-)

Are you sure? [yes] / [no]

dickson wrote 3 months ago null point

Rock star.

Are you sure? [yes] / [no]

Similar projects