MNEM IoT Presentation for Export

Size: px

Start display at page:

Download "MNEM IoT Presentation for Export"

Tabitha Norton
5 years ago
Views:

1 MNEM IoT Presentation for Export Scott Colestock MN Enterprise Mobile User Group - August 2016 scott@colestock.net

2 Let's talk IoT - why such a big deal now? A lot of companies that have been in the sensor business or "machine-to-machine" (M2M) business are actually sort of mystified that IoT entered a new "hype cycle" in 2015 As cost of data plans and the cost of hardware for connectivity drops, many more interesting opportunities are revealed The efficiencies of more visibility - whether into a supply chain, or a manufacturing floor, or a vehicle - are being appreciated in more and more sectors of the economy. As that delivers value, creates pressures for others to follow

IoT: Quick Level Set IoT/M2M defined as exchange of data between devices (across a network) for monitoring & control Ingredients: Sensors to capture asset status & event data Device(s) that aggregate

Device Management: enable customers to remotely configure & adjust embedded device settings, monitor device status, troubleshoot, provision, etc.

3 IoT: Quick Level Set IoT/M2M defined as exchange of data between devices (across a network) for monitoring & control Ingredients: Sensors to capture asset status & event data Device(s) that aggregate & transmit captured data (& receive/enact remote instructions) A communications network Backend software systems for translating, analyzing & acting on data IoT: Quick Level Set - Platform Segments: Device Management: enable customers to remotely configure & adjust embedded device settings, monitor device status, troubleshoot, provision, etc. Network Management: enable customers to provision data services & activate/deactivate wireless plans for devices, monitor performance & usage metrics, exception reporting, spend optimization, etc. Also: providing the networking environment (private IPs, static IPs, VPN, etc.)

4 Integrated with wireless carriers (or provided by wireless carriers.) Often the "visible part" of a MVNO IoT: Quick Level Set - Platform Segments (2): Application Enablement: Why isn't this just classic web services? Because you would like: An MQTT broker to support publish/subscribe - lighter than HTTP (less time & power per server interaction) MQTT not used exclusively - HTTP, websockets, SMS, all possible too... Support "publish my current state" as a primary use case Ad-hoc exploration & visualization of data (especially time-series) When you know you're doing mostly telemetry (publication of semi-uniform data sets), a variety of declarative techniques become interesting "INSERT INTO dynamodb.ranger-high-temps (timestamp, payload) SELECT * FROM '$aws/things/+/shadow/update/accepted' WHERE state.reported.oil_temp_farenheit > 200" Complexity across Device Management, Network Management, and "Application Enablement" has created a market demand to get them from a single vendor... "One throat to choke" Lots of M&A activity over the last several years to create "triumvirates" Top tier carriers (AT&T / Verizon) making that attempt - but many others too Let's Talk MQTT MQTT is a binary client-server publish/subscribe messaging transport protocol, standardized by OASIS MQTT utilizes many characteristics of the TCP transport, so the minimum requirement for using MQTT is a working TCP stack Port 1883 or 8883 with SSL/TLS Used in telemetry, automotive, smart home, energy monitoring, etc. Implements the brokered publish / subscribe pattern Can save power/time/data over straight HTTP MQTT Control Packets Fixed header references MQTT message types (below) & associated flags Variable header references topic name, message ID

5 Payload (often json, but could be binary/text/xml/etc.) MESSAGE TYPE DESCRIPTION CONNECT Client request to connect to Server (includes keepalive value used by heartbeat) CONNACK Connection Acknowledgement PUBLISH A message which represents a new/separate publish PUBACK QoS 1 Response to a PUBLISH message SUBSCRIBE A message used by clients to subscribe to specific topics SUBACK Acknowledgement of a SUBSCRIBE message UNSUBSCRIBE A message used by clients to unsubscribe from specific topics UNSUBACK Acknowledgement of an UNSUBSCRIBE message PINGREQ Heartbeat message PINGRESP Heartbeat message acknowledgement

6 DISCONNECT Graceful disconnect message sent by clients before disconnecting. MQTT Publish / Subscribe Publish and subscriber don't need to know about each other - publish to a "topic" that interested parties can subscribe to Topic definitions use a path-like structure ("topic levels") Topics created dynamically (on the fly) Single (+) & multi-level (#) wildcards possible when subscribing some/test/topic some/+/topic top-level/# top-level/+/+ +/# # Just as with the web (or even within REST conventions) there are differences of opinion about how to organize URI/path space, so also with MQTT - and with various IoT backends you might encounter. (MQTT hindered in having standard interface ala REST since single "Publish" verb.) MQTT QoS Levels 0: At most once delivery: The sender tries with best effort to send the message and relies on the reliability of TCP. No retransmission takes place. 1: At least once delivery: The receiver will get the message at least once. If the receiver does not acknowledge the message or the acknowledge gets lost on the way, it will be resent until the sender gets an acknowledgement. Duplicate messages can occur - so your application must be prepared to be OK with that. Messages queued for offline clients (as with 2) 2: Exactly once delivery: The protocol makes sure that the message will arrive exactly once at the receiver. This increases communication overhead but is the best option when neither loss nor duplication of messages are acceptable. (Often not implemented) Note: Publishers send with a given QoS...but subscribers subscribe with a given QoS. From a given publisher to a given subscriber, the "net" QoS is the lower of the two. MQTT Demo: Phone to MQTT.fx to command-line (m2m.eclipse.org)

7 MQTT Other Topics Last Will & Testament Messages (LWT): A message specified at connection time that will be delivered to broker IF client does NOT disconnect gracefully Retained Messages: Last known good value and persists at the MQTT broker for the specified topic - every time a new client subscribes, they will receive Clean vs. Persistent Sessions: Persistent = keep my past subscriptions, deliver my missed QoS 1/2 messages Not everyone a fan of MQTT: Just google "clemens vasters mqtt" Poor extensibility (no ability to extend metadata or "verbs") Strange decisions about headers versus payload (e.g. client ID in payload) Strange decisions to save bits/bytes when IP and TCP headers and TLS framing will negate savings Strange/wasteful method of communicating version info Nothing said about payload encoding in spec - no content negotiation Poor error handling - no way to distinguish bad network conditions versus server issues (which will cause undesirable retry behavior) Messages delivered immediately once you're subscribed - no ability to throttle or accept-as-able. If you want to deal with "important messages first", you're required to pull down all messages and store until you can process Many features - like persistent sessions and QoS2 - turn out to be impractical And more...but protocols with weaknesses often thrive... IoT Backends (Application Enablement) Revisited Ingest data at large scale, using a variety of connection protocols (often MQTT/TLS with json payloads) Provide ability to interact with the ingested data & the "connected things" Provide ability to respond to data under various conditions - including pushing state/actions back out! Let's contrast two players... The "Things" in IoT Different IoT backends bring different levels of formality to "thing definition" - the model for a connected device Amazon IoT limits thing definition to three key-value pairs (for querying) and then a json body (key/values and arrays)

8 (Amazon Demo) Amazon Shadow Service ("desired" vs "reported") AWS IoT doesn't really care about your 'thing definition' - but SQL rules engine lets you query on it Telit Things Background: Telit does Device Management, Network Management, Application Enablement - plus cellular/gps modules Thing Definitions: Analogous to "classes" Attributes: strings (with history) Alarms: collection of related states (low/high or on/off or freezing/coolish/warmish/burning) Properties: int or float plus units (full time series preserved) Methods: functionality exposed with input/output parameters Notion of "autodef" attributes & properties Things: Analogous to objects - they are instances of thing definitions IoT Topics & Payloads Amazon ("Shadow Service") To report its state over MQTT, the thing publishes json on topic $aws/things/thingname/shadow/update. (state:reported) To request changes to state over MQTT, an app publishes json on topic $aws/things/thingname/shadow/update. (state:desired) To receive updates from the shadow, subscribe to topic $aws/things/thingname/shadow/update/accepted. To receive deltas between last reported state and new requested state, subscribe to topic $aws/things/mylightbulb/shadow/update/delta This json will only reflect properties that are different. Telit / TR-50 TR-50: Telit IoT relies on an MQTT topic called "api" where commands formatted using "TR-50" are sent - with replies on a "reply" topic (HTTP works just as well) TR-50 is essentially a json format for enumerating and invoking "methods" - some methods might be as simple as "property.publish"

9 In addition, you can subscribe to thing/thingname/property/, alarm, location, etc. Let's talk about a simple IoT device Raspberry Pi 3 With a Grove Pi sensor kit (we're using a temp/humidity sensor, two LEDs, a buzzer, and an LCD) Using simple python app to measure temp and squawk if it goes above threshold Let's go from simple device...to cloud-connected device...to mobile companion app for device

MQTT MQ TELEMETRY TRANSPORT. AN INTRODUCTION TO MQTT, A PROTOCOL FOR M2M AND IoT APPLICATIONS. Peter R. Egli INDIGOO.COM. indigoo.com. 1/33 Rev. 1.

MQTT MQ TELEMETRY TRANSPORT. AN INTRODUCTION TO MQTT, A PROTOCOL FOR M2M AND IoT APPLICATIONS. Peter R. Egli INDIGOO.COM. indigoo.com. 1/33 Rev. 1. MQTT MQ Telemetry MQTT Transport MQ TELEMETRY TRANSPORT AN INTRODUCTION TO MQTT, A PROTOCOL FOR M2M AND IoT APPLICATIONS Peter R. Egli INDIGOO.COM 1/33 Contents 1. What is MQTT? 2. MQTT characteristics