Smart home and smartfactory intelligent systems

  • 601 views
Uploaded on

MVP Summit 2013 Exhibit Session

MVP Summit 2013 Exhibit Session

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
601
On Slideshare
0
From Embeds
0
Number of Embeds
2

Actions

Shares
Downloads
17
Comments
0
Likes
2

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. SmartHome and SmartFactory Intelligent Systems With .NET Micro Framework, Azure and MQTT Lorenzo Maiorfi Mirco Vanini
  • 2.  Cloud Hosting Environment (Azure VMs)  MQTT Network  MQTT Broker by HiveMQ (www.hivemq.com)  .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.  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.  Blazingly Fast  Enterprise-grade security HiveMQ Broker by DC2  Clustering  Portability  Support  100% MQTT compliant  Websockets  Scalability  Modular  Administration made easy
  • 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.  “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 (mfsmarttoolkit.codeplex.com) in order to get greater reliability and performance
  • 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.  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.  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.  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