Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to mbed Connect Asia 2016 Overview of mbed Device Connector
Similar to mbed Connect Asia 2016 Overview of mbed Device Connector (20)
Recently uploaded
Recently uploaded (20)
mbed Connect Asia 2016 Overview of mbed Device Connector
- 1. Overview of mbed Device Connector Jan Jongboom Haoli Qu ARM mbed Connect / Shenzhen, China December 5, 2016
- 2. © ARM 20162 Your hosts Haoli Qu Software Engineer Jan Jongboom Developer Evangelist
- 3. © ARM 20163 Who is making decisions when it comes to IoT?
- 4. NO
- 6. © ARM 20166
- 7. © ARM 20167
- 8. © ARM 2016 Less people neededAutomatic planning 8 Real life example - Telenor Big telecom company Owns 4,000 buildings in Norway Toilet cleaning schedule made by 'hand' Realtime insight
- 9. © ARM 2016 Less people neededAutomatic planning 9 Real life example - Telenor Big telecom company Owns 4,000 buildings in Norway Toilet cleaning schedule made by 'hand' Realtime insight
- 10. © ARM 201610 Internet of Things is sensors + data intelligence
- 11. © ARM 201611 Plenty of services doing data intelligence Generic cloud Application specific
- 12. © ARM 201612 Many connectivity methods
- 13. © ARM 201613 Many boring parts... Devices disappearing Sleep schedules Ultra-constrained devices IP vs. non-IP mbed Cloud Connect
- 14. © ARM 201614 Handling connectivity mbed Cloud Connect mbed Cloud Client Proprietary protocol
- 15. © ARM 201615 Single way of talking to devices Regardless of connectivity method - IP or non-IP LWM2M abstraction for objects and resources
- 16. © ARM 201616 Communicating with a device mbed Cloud Connect Application Device running mbed Client 1 - Application makes HTTPS REST call - GET /light/intensity 2 - mbed Cloud sends CoAP request to device 3 - Asynchronously device sends state over CoAP 4 - Response is delivered to application (asynchronously)
- 17. © ARM 201617 Communicating with a device mbed Cloud Connect Application Ultra-constrained device with BLE HTTPCoAPBLE
- 18. © ARM 201618 Characteristics Calls to mbed Cloud Connect always yield a call to the device Unless... All APIs are asynchronous - devices can be asleep Secured from cloud to edge-node: To the device with mbed Client Gateway responsible for last mile Not a data store!
- 19. © ARM 201619 From Cloud Connect to application Rely on notifications - minimize traffic to device Notifications can be delivered to any URL Simple use case: Forward data straight into application cloud Advanced use case: Device management APIs Manage devices straight from application cloud
- 20. © ARM 201620 Managing devices through Watson IoT
- 21. © ARM 201621 Managing devices through Watson IoT
- 22. Bridges
- 23. © ARM 201623 Bridges Open source bindings to application clouds running in Docker Best practices: Watchdog, isolation, logging For Azure, IBM, AWS, generic MQTT Two-way communication E.g. node-red on IBM Watson https://github.com/armmbed/?utf8=✓&query=bridge
- 24. © ARM 201624 Don't need the full bridge? Quick bindings using Python, node.js APIs Use own datastore, or external cloud Binding to Telit Cloud written in 1.5hr
- 25. © ARM 201625 Quickly build web applications? Konekuta Highly-opiniated node.js framework Internally developed for demo's and workshops Combining best practices: State and UI syncing, caching device data, error handling... https://github.com/ARMmbed/konekuta
- 26. Demo time
Editor's Notes
- From Cambridge we have Haoli Qu, from Amsterdam Jan Jongboom.
- * Who is making decisions when it comes to IoT? You might think... well dev conference, probably..
- Developers? (This is actually how developers look like according to a stock website)
- * Business is driving IoT IoT is means to reduce cost - make business run more effectively So: we need to forget about the things we think about the funny consumer pictures, and start thinking about business needs...
- Stop thinking about smart toasters
- Or the smart diaper, as it's easier to check Twitter than to check your kid's diaper...
- * Example, used to work in Telenor, big telco. Got 4000 buildings in all of Norway. * 4000 buildings == a lot of toilets * Cleaning schedule is currently made by hand (clean every toilet every X time) * Real(ish) time insight == automatic planning == less people needed * $!
- OK, really this is the last stock photo I have ;-)
- * The automatic planning is the real IoT part. Simple sensors feeding data into a spreadsheet where a manager actually decides is not really IoT. * Devices feed data into facility management system, FMS makes the decision on where to send people. * IoT = sensors + data intelligence.
- IBM has Watson, Microsoft has various BI platforms, Google hsa DeepMind, Amazon has QuickSight. Many more. On Application level you have app specific vendors. We see facility management, energy management, waste management vendors on the right. Depending on your data it might actually end up in many different clouds...
- * Devices connect over many different connectivity methods... * Cellular, WiFi, Low powered mesh, LoRa, BLE, Zigbee, proprietary * Connectivity is boring. Bytes should go from A -> B. * You can either add value on device side or intelligence side. Not in between.
- Lot of edge cases: devices disappearing, sleep schedules on low powered devices, devices have different capabilities. Some have IP, some do not. Some are ultra-constrained devices with 16K mem, some are full computers. * mbed Device Connector handles the boring part!
- * Connectivity either directly via mbed Client on the device (on devices that are fast enough, have IP). * Portable. Now on mbed OS 5, will come to other RTOS's soon... Can we name FreeRTOS? * Or via gateways. mbed Client on a Linux box, then over non-IP to the device. * Reference designs available for Bluetooth Low Energy (on Raspberry Pi) and LoRaWAN (in the cloud). * Gateway code is small. Our BLE gateway is ~400 lines of code in node.js (+UI it comes to 1,500 LoC) - the mbed Client logic is in a C++ binary which is same for all gateways.
- * Offers access to devices in exactly the same way regardless of connectivity method. * LWM2M, device has objects and resources. * Device A has an LED, LED has state ON/OFF.
- * Through mbed Device Connector you can query the state, or write a new state. * mDC will connect to device, request value, report back. * Or on constrained-devices that sleep, will ask the gateway. * Does not do caching, it's a proxy to talk to the device! Database not included!
- * Through mbed Device Connector you can query the state, or write a new state. * mDC will connect to device, request value, report back. * Or on constrained-devices that sleep, will ask the gateway. * Does not do caching, it's a proxy to talk to the device! Database not included!
- * End-to-end encrypted, to device when connected directly, gateway's responsibility to handle non-IP part... @todo, don't call it end-to-end
- * Getting the data out of it * Can deliver notifications over a web hook to any URL. * Minimize traffic from your app -> device, bad for battery. * Simplest use case: forwarding your data into application cloud of your choice. * More advanced use cases can take advantage of device management APIs. * F.e. In Watson IoT you can manage your devices even though they're connected through mDC.
- Here we have IBM Watson IoT platform, which is a new mbed partner, in which you can activate Watson<>Connector bindings from their UI.
- After that the device management APIs are used to show Connector managed devices alongside other devices in Watson. Perfect integration.
- For all bindings to other clouds we developed 'Bridges'.
- * Sending data over in a reliable manner requires things like watchdog process, isolation, logging, etc. * Connector bridges are plug-n-play, Docker containers that connect Connector <-> App cloud, which handle all that for you. * Currently available for Azure, IBM, AWS and generic MQTT bridge.
- * Don't need the full suite of bridges? Simple one-offs or during development? * Writing against the Python or node.js API and dump data that way. * Jan wrote a script that forwarded data to Telit Cloud for an event in an hour and a half... Without knowing anything about Telit.
- Later today we'll have the 'Building an internet connected lighting system' workshop, in which we'll be using Konekuta to build the user-facing part of the system.
- We'll be showing two demo's. One is how to take a device running mbed OS 5 + WiFi, and show how easy it is to connect a new sensor to it, thanks to mbed ecosystem. Second is how we can manage two devices straight from IBMs cloud using their workflow programming language with node-red.