Smart home and smartfactory intelligent systems


Published on

MVP Summit 2013 Exhibit Session

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Smart home and smartfactory intelligent systems

  1. 1. SmartHome and SmartFactory Intelligent Systems With .NET Micro Framework, Azure and MQTT Lorenzo Maiorfi Mirco Vanini
  2. 2.  Cloud Hosting Environment (Azure VMs)  MQTT Network  MQTT Broker by HiveMQ (  .NET MF embedded devices running as MQTT Network “nodes” Our Reference Application Modules  sensors/actuators working as publishers/subscribers of data/commands  MQTT-2-Z-Wave embedded bridge  MQTT-2-ZigBee embedded bridge  MQTT-2-ISM (2.4GHz Radio) embedded bridge  MQTT industrial controller (ABB PLC)  Node-red “engine”, acting as  designer and runtime host for “flows”  interface/protocol/API adapter among service endpoints  simple business-logic modules hosting platform
  3. 3.  Application protocol over TCP layer  Based on pub/sub messaging model MQTT is the de-facto standard for M2M / IoT Applications  Messages are made of two simple parts:  Topic, a string typically expressed in hierarchical form “/part1/part2/part3/…”  Payload, an arbitrary content expressed as a byte-array  3 QoS levels for message publishing  QoS Zero (best effort)  QoS One (broker confirms to publisher that message has been delivered, but cannot confirm that same message wasn’t delivered more than once)  QoS Two (broker confirms to publisher that message has been delivered, and just once)  MQTT provides for both “retained” and “last will” messages
  4. 4.  Blazingly Fast  Enterprise-grade security HiveMQ Broker by DC2  Clustering  Portability  Support  100% MQTT compliant  Websockets  Scalability  Modular  Administration made easy
  5. 5.  Despite its powerful network model, real world scenarios often require to extend such network to other communication systems  A common requirement is radio coverage: MQTT Bridging  ZigBee mesh networks for industrial environments  Z-Wave mesh networks for smart home systems  ISM (2.4 GHz) technology for cheap and fast data exchange  Bridging MQTT with these technologies allows for:  building hybrid networks whose nodes share same messaging model  joining different MQTT networks with radio links  greater overall reliability (by redundancy)
  6. 6.  “Mesh” networking model means that any node can extend overall coverage to adjacent nodes, acting as a router  Digi XBee modules are by far the most common chips used worldwide ZigBee Networks  Coverage is about 50-100m (1mW) for standard modules and up to 1.6km (50mW) for “Pro” modules  They’re great to implement remote IO management (digital inputs/outputs and analog inputs)…  …but together with a host microcontroller board they’re great to implement arbitrary message exchange too  They can be configured and updated remotely  Serial API exposed to host applications is simple but powerful  We have extended XBee API client libraries originally coded by Micheal Schwartz ( in order to get greater reliability and performance
  7. 7.  Licensed by Sigma Designs (formerly ZenSys), Z-Wave is becoming the “de facto” standard for Smart Home systems  Z-Wave is based on mesh network model (like ZigBee), but radio modules typically require much less power to work than XBee (a battery operated device can work for years) Z-Wave Networks  There are plenty of Z-Wave enabled devices (power outlets, power meters, sensors, thermostats, blinds motors drivers, switches, etc)  We developed a managed Z-Wave Serial API Controller stack targeted to .NET Micro Framework devices  Our client lib provides support for most commons profiles (basic, meter, multilevelsensor, multilevelswitch, wakeup, etc)  Client API is async-only  Works with any Z-Wave Serial API Controller device, connected through a UART port to host application microcontroller
  8. 8.  Despite its great flexibility, a network infrastructure itself cannot address real-world scenarios  We need a way to design and run business logic flows orchestrating message exchange among network nodes Business Logic Flows  Node-red is an open project whose main purpose is that to act as an engine that runs/hosts “flows” designed by mean of node-red itself  Despite being general, it fits in a natural way with MQTT  Node components can be written in JavaScript  It uses a visual design language using a SPA web IDE (hosted by node-red itself)  Many node components are built-in  Despite it can also implement business logic of medium complexity, node-red killer-application is no doubt “interface/API” adaptation among “actors” in heterogeneous systems (in our reference application we provide an example of both cases)
  9. 9.  Windows 8 Store App  consumes a custom tcp socket “tunneling” in order to get and publish MQTT messages even with no MQTT client lib support Sample Client Apps  Windows Embedded Compact 2013 App  uses µM2MQTT Library by Paolo Patierno in order to directly interact with MQTT broker  Windows Phone 8, iPhone Apps  use a plain HTTP REST/JSON API  kind of “longpolling” technique implemented by a node-red flow changes messaging model from pub/sub to request/reply
  10. 10.  Mirco Vanini: Windows Store App  Paolo Patierno: uM2MQTT Library & WEC 2013 Demo App  Fabrizio Bernabei, Tiziano Cacioppolini: WP8 Demo App Credits  Daniele Galiotto: iPhone App  Lorenzo Maiorfi: firmware, web broker spa web app, node-red flows