1. nd
IOTLondon 22 May '12
Quest for a
low-power home hub
@paul_tanner

2. Scenario
● Many devices
● Many services
● Many protocols
● Standards? DHYB
● Crazy mess of
visualisations
● Exploding routers!
● It can only get worse

3. Hub
cloud services
● Handle diverse
sensors/ actuators
● Interact with various
cloud services
HUB
● Single connection to
home router
● Modularity/ Openness
sensors/ actuators
devices

4. Requirements
● Modular protocols
● Downloadable config.
● Buffer storage
● Rule support
● Open source
● Durably packaged
● Affordable
● Low power

5. Local Devices
● 433 Mhz (prop)
● 868 Mhz (prop)
● Zigbee (profiles)
● One-wire
● 6LowPAN
● RS232 Serial
● UDP on LAN

6. Cloud Services
● Cosm/ pachube
● Incl. SSL
● Thingiverse
● Nimbits
● AMEE
● Wunderground
● Proprietary APIs
● AlertMe
● etc ...

7. Available Tech
● Nanode (Atmel)
● OpenKontrol
● SK Pang (MBED)
● BeagleBone (ARM)
● Raspberry Pi
● FriendlyARM
c
● Digi ConnectPort
● NSLU2 (Slug)
● Hacked routers etc.

8. SWOT – SKP Gateway
● MBED
● Performance
● Memory
● Libraries
●
Slot for 2nd RFM12
● Robust packaging
● Only one slot for
Xbee/ XRF

9. SWOT - OpenKontrol
● Two radio slots in
addition to RFM12
● Lower cost processor
● Restricted memory
● Daughterboard
(Ethernet port)
● Promise of lower
power
● Indicators

10. Others
● Nanode
● used by OEM
● BeagleBone (ARM)
✔ linux stack + node.js
✔ “capes”
● FriendlyARM
● Pi (unobtainable any
time soon)
✔ linux stack
✗ hardware ecosystem

11. Example App
● Monitors emit UDP
multicast
● Temperature from XRF-
based sensors
● Additional data from
AMEE and wundergr.
● Energy and temperature
to pachube
● Feedback in graphs,
twitter alerts etc.

12. Tests So Far
● Building kits with minimal
doc?
● Some things feasible
with each platform
● e.g. TCP sockets
● Current library issues
● No UDP multicast for
Arduino
● linux with node.js
www.nodejs.org
version discrepancies

13. Issues
● Concurrency
● O/S or not?
● Support in libraries
● e.g. multicast
● Memory requirements
● Packaging
● IDE, languages
● nodejs/ python vs. c++ www.asmithillustration.com

14. Conclusions
● Today: jury is still out
● Initially O/S and
libraries will decide
● Packaging is soluble
● Memory could
therefore be a killer
● Finally, power use

15. Questions?
www.slideshare.net/paul_tanner
@paul_tanner
www.e-ssociation.com/blog

16. Comparative Factors
Platform O/S On (W) S/Save Sleep multicast enclosure
(W)
OK * 0.7 Y
Gateway
MBED * 1.7 Y
Beaglebone linux 2.5 Y
NSLU2 linux
iMac OS/X 75 50 2 Y
PC Win7 100 52 1 Y
* could use qp, FreeRTOS, Contiki etc.