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.