Monthly Archives: March 2016

Wifi-connect – quick wifi access point to tell a Raspberry Pi about a wifi network

This is all Andrew Nicolaou‘s work. I’m just making a note of it here so others can have a go.

An important part of Radiodan is the way it simplifies connecting a device to a wifi network. The pattern is more common now for screenless devices – Chromecast uses it and ESPs have code patterns for it.

The idea is that if it can’t find a known wifi network, the device creates its own access point, you connect to it on a different device such as a phone or laptop, it pops up a web page for you and you add in the wifi details of the network nearby that you want it to connect to.

Andrew, Dan Nuttall and Chris Lowis wrote the original code – which I wrote up here – and then recently Andrew investigated Resin’s approach, which seems to be more reliable. Resin uses their own platform and Docker images which we’re not using, so Andrew un-dockerised it, and has recently rolled it into the new iteration of Radiodan that we’re working on.

If you want to use it in your own project without Radiodan, here are some instructions. It uses a branch of the Radiodan provisioning code, but just installs the relevant pieces and doesn’t delete anything.

First make sure you have a wifi card with the right chipset – or a Pi3 (scroll down for special Pi3 instructions). Then:

Provision an SD card (this is on Mac OS X)

diskutil list
diskutil unmountDisk /dev/disk2
sudo dd bs=1m if=~/Downloads/2016-02-09-raspbian-jessie.img of=/dev/rdisk2

Put it in the Pi, login, expand the filesystem, reboot and login again.

Checkout the Radiodan code and provision the relevant parts.

sudo apt-get update -y && sudo apt-get upgrade -y
git clone https://github.com/radiodan/provision.git
cd provision
git fetch origin
git checkout -b minimal origin/minimal
sudo ./provision iptables node wifi-connect

reboot. Wait a minute or two and you’ll see a wifi access point called “radiodan-configuration”. Connect to it and a browser window will pop up. Select the wifi network you want to connect the Pi to, add the password and save. Connect back to the wifi network you selected for the Pi and you should be able to ssh to it at pi@raspberrypi.local

For a Raspberry Pi 3, you’ll need to tweak things in order to make it possible for the built in wifi:

sudo apt-get install raspi-config
sudo BRANCH=next rpi-update

IoT Semantic Interoperability IAB workshop summaries

Danbri drew my attention to this IoT Semantic Interoperability IAB workshop and I thought I’d spend a couple of hours skimming the papers to pick out themes as I’ve done before.

These are all my own opinions, reflecting my own interests; and the summaries of individual papers are very short.

Summary

As far as I can see, the issues are basically these:

  • Implicitly from these papers, consumers don’t want to buy into a particular ecosystem. So interop is necessary between devices (or is there another reason for interop?)
  • This raises a whole load of interoperability questions (interop at which level? protocol or data model? manufacturer implementation built-in interop or gateway model?)
  • Security becomes a huge problem with interop [draft-farrell-iotsi-00.txt, IoT-Security-SI.pdf]
  • Various established standards orgs want to be involved and contribute
  • A couple of older protocols with widely deployed standards and certification want to know how to adapt to an IP world

A few things I noticed:

Perhaps there are some learnings from previous IoT type implementations:

A few standards keep coming up, all being looked at in the IETF I think –

  • YANG modelling language – CORE WG in IETF
  • CoAP – REST for small devices – IETF again
  • HATEOAS – “Hypermedia as the Engine of Application State” – links for actions

and some concepts / technologies:

  • “method” “signal” “property”
  • Events, Actions, and Properties
  • streams of data
  • object-based modelling
  • XML
  • json / json-ld
  • RDF/OWL

What’s the business model here? Since standardisation and some level increases commodification, where does the money come from?

A few lines on each paper

I looked at the accepted papers in the zip file so there were a few missing from the complete list.

1. Gadgets and Protocols Come and Go, Data Is Forever

J. Arkko, Ericsson

A brief summary of current standards in various organisations and then a discussion of some of the architectural and security issues.

“Security models that enable users to secure their data in appropriate ways, while granting rights for specific parties to access parts of the data. Or for a specific duration.””Also, it would be useful to change the focus of standards efforts to look more at the data than transport, for instance in current IETF working groups.”

2. Noise in specifications hurts

C. Bormann, Universitaet Bremen TZI

An argument about using a particular format for the expression of http://cbor.io for human-readable schemas.

3. YANG as the Data Modelling Language in the IoT space

Benoit Claise, Cisco Systems

“I hope that the industry will standardize on a single data modeling language for a particular technology (like IoT), so that no mapping between data models would be required.”

“Summary: you should really use YANG as the data modeling language in the IoT space”

4. The ZigBee Cluster Library over IP

Robert Cragie

This is a manufacturer-orientated library for commands for specific types of radio-controlled devices and the commands relevant to them which can be profiled and added to or new commands.

“a ‘cluster’ is a group of functionally related attributes and commands”

“The ZigBee Alliance formed a working group with a working name of “ZCL-over-IP” to undertake the work of mapping the ZCL to an equivalent protocol, which can be used effectively with the IP suite.”

They considered UDP and REST but preferred option is “Use transaction and data representations typically in use in conjunction with IP and map the existing ZCL to these transactions and data representations”

As an example:

“ZigBee Smart Energy clusters were modeled in UML and then a completely new protocol based on HTTP and XML was produced”

5. Fairhair: interoperable IoT services for major Building Automation and Lighting Control ecosystems

Dee Denteneer, Michael Verschoor, Teresa Zotti. Philips Lighting.

“Building Automation and Lighting Control – goal is a standard – “Fairhair is built on the belief that the established BA&LC ecosystems have a major asset in their mature data model; an asset which can be largely maintained when these ecosystems transition to the IP and IoT domain while the opportunity for differentiation at the networking layer will gradually disappear.”

The Fairhair framework is expected to specify at least the following services and concepts:

  • a generic model description of a domain model in terms of web resources and a mapping of elements in this data model (e.g., objects) to URIs
  • mapping of the existing methods to interact with elements in the data model (e.g., to write a property value) to RESTful interaction methods as defined by CoAP.
  • “IoT friendly” data encoding formats, such as JSON or CBOR, instead of ecosystem specific encoding formats
  • a scalable mechanism for device and service discovery, independent on the ecosystem’s specific semantics
  • other orthogonal application services, related to the security model (e.g., supporting authorization, secure unicast and multicast communication) and network management.

6. Object Oriented Approach to IoT Interoperability

http://www.universal-devices.com

Device updates:

“When discussing runtime binding, the main question is: do devices really need to have á priori knowledge of the types/classes of other devices with which they attempt to interoperate with? Or does it suffice for a device only to discover a set of permissible actions and properties supported by the other device?”

High level, object-orientated approach:

“Objects: Objects/Subjects in a sentence or phrase and corresponding to nouns Properties: Nouns (they could be other objects) or adjectives Behaviors: Verbs; actions that an object can do or allows to be done to it. In Service Oriented Architecture, these are called Services Adverbs: Parameters for Behaviors”

An implementation: XML to define NMM

7. Interoperability and the OpenDOF Project

Bryant Eastham, President and Technical Committee Chair, OpenDOF Project 

“OpenDOF” – “The OpenDOF Project considers interoperability a core principle. It has had a huge impact on its design and implementation. We provide an open repository where semantic definitions of all kinds can be shared and provide the system for others to do the same, all to increase interoperability”

“The definition of interoperability that we presented in the Introduction referred to a common understanding of an action between a requestor and potential provider. In secure systems this common understanding must extend to the security configuration of the system(s) involved.”

8. It’s Often True: Security’s Ignored (IOTSI) – and Privacy too.

S. Farrell, Trinity College Dublin; A. Cooper Cisco

1. Don’t forget that the user owns the device and, arguably, the
data produced related to that device.

2. Don’t forget that the device needs to be updated and that the
vendor will end-of-life the device, but the above still needs to
be remembered.

3. Don’t forget that while we can secure information elements in
transit and in storage, that will always be imperfect and
information will leak out.

It is worth noting that the IOTSI call for submissions itself did
ignore all of these issues.”

[cheers]

9. Overview of IoT semantics landscape

Christian Groves (Christian.Groves@nteczone.com) Lui Yan (scarlett.liuyan@huawei.com) Yang Weiwei (tommy@huawei.com) Huawei Technologies

Survey of existing ontologies suitable for this purpose and some recommendations – that they be open, recommend which ones to use. Appendix is a list of ontologies that might be relevant.

10. Loci of Interoperability for the Internet of Things

Ted Hardie Google

“In the absence of a common systems engineering approach to specify where different types of rule are applied, nodes cannot know where the data they supply will be interpreted, or even that it will be interpreted only once. Contextualizing the data they send will increase the likelihood that it can be interpreted correctly. That contextualization should reference the most primitive possible schema or data model that results in a correct understanding, in order to increase further the chance of correct interpretation and to avoid leakage of unnecessary data about the system to observers.”

– interesting that it references the local and remote aspects. I’m not sure about the argument that it reduces the information leakage of node though.

11. IPSO Smart Objects

Jaime Jimenez, Michael Koster, Hannes Tschofenig, Ericsson

“The data model for IPSO Smart Objects consists of four parts: 1) Object Representation 2) Data Types 3) Operations 4) Content Formats”

“Objects and resources are implicitly mapped into the URI path hierarchy by following the OMA LWM2M object model, in which each URI path component sequentially represents the Object Type ID, the Object Instance ID and the Resource Type ID”

Contains an XML example that for me, brings back unpleasant memories of SOAP.

12. IOTDB ­ Interoperability through Semantic Metastandards

David Janes

A lot of assertions, not much argument (separating out into a semantic model and state, all json-ld and REST). Implementation and schemas.

15. SenML: simple building block for IoT semantic interoperability

Ari Keränen ari.keranen@ericsson.com Cullen Jennings fluffy@cisco.com

“SenML provides a simple model for retrieving data from sensors and controlling actuators. It provides minimal semantics for the data inline and allows for more metadata with in-line extensions and links.”

  • designed for low power, low capacity and processor devices
  • being standardised in IETF CORE

Example:

[{ "n": "urn:dev:ow:10e2073a01080063", "v":23.1, "u":"Cel" }]

17. SmartThings

M. Koster

“[W3C-WoT] model: a connected Thing is defined by and interacted with through its Events, Actions, and Properties.”

“Semantic interoperability may be achieved through common definitions
of cross domain meta models [e.g. schema.org instances] and domain specific models [i.e. vendor defined programming models], and shared
vocabulary to describe the events, actions, and properties of
connected things.”

18. Semantic Interoperability Requires Self­describing Interaction Models HATEOAS for the Internet of Things

Matthias Kovatsch Siemens AG / ETH Zurich; Yassin N. Hassan ETH Zurich; Klaus Hartke Universität Bremen TZI

Proposes semantic links and semantic forms so you get some of the nice characteristics of links (e.g. bookmarkablity). Focus is on developer as user.

19. A Pragmatic Approach to Interoperability in the Internet of Things

Kai Kreuzer, Deutsche Telekom AG Kai Kreuzer

  • open source, consideration of end-user usecases and so a functional perspective
  • semantics using tags based on ontologies

20. AllJoyn / AllSeen standards org

Marcello Lioy

Just consists of 3 links:
specs
scenarios
data model guidelines

XML based. Usecases are ifttt but mostly code generation for devs.
“method” “signal” “property” (with access parameters read / write)
Without looking too closely, it looks something like Java basics in XML

21. Modeling RESTful APIs with JSON Hyper-Schema

K. Lynn, L. Dornin, Verizon Labs

An actual usecase!

“The central problem in an IoT domain such as home control might be
characterized as “translating intention into configuration”. The
challenge is to translate a high level goal such as “turn off all the
lights on the first floor”, expressed in a natural language, into
action.”

The remainder of the document is some examples of json and json-ld defining REST interactions: “JSON Hyper-Schema”.

22. OGC SensorThings API: Communicating “Where” in the Web of Things

Open Geospatial Consortium

“a standardized open data model and application programming interface for accessing sensors in the WoT and IoT”

– an ontology for sensors.

Streams of data, sensors and their properties – datamodel is here.

23. IoT Information Model Interoperability An Open, Crowd-Sourced Approach in Three Parallel Parts

Jean Paoli, Taqi Jaffri, Microsoft

  • argues for separated protocols and schemas
  •  thinks crowd sourcing from schemas to devices would be a way to build bridges

24. OMA Lightweight M2M Resource Model

Author: Joaquin Prador – OMA Technical Director

“This paper gives an introduction to standard developed at the Open Mobile Alliance (OMA), Lightweight Machine to Machine (LWM2M). LWM2M provides several interfaces built on top of Constrained Application Protocol (CoAP) to perform management of a wide range of remote embedded devices and connected appliances in the emerging Internet of Things, to perform remote service enablement and remote application management.”

1) Bootstrap 2) Device Discovery and Registration 3) Device Management and Service Enablement 4) Information Reporting

Uses CoAP and DTLS (the latter for security)

Datamodel: id, name, operations [read / write / execute], instances, type, range or enumeration, units, description

26. Semantic Overlays Over Immutable Data to Facilitate Time and Context Specific Interoperability

Pete Rai – Principal Engineer – Cisco Stephen Tallamy – Engineering Architect – Cisco

Argues

“apply semantic interoperability layers over-the-top, as and when they are needed. This approach is specifically designed to leave the source data elements untouched and effectively immutable.”

27. Towards semantic interoperability in the IoT using the Smart Appliances REFerence ontology (SAREF) and its extensions

Jasper Roes & Laura Daniele

“SAREF is not about the actual communication with devices and has not been set up to replace existing communication protocols, but it lays the base for enabling the translation of information coming from existing (and future) protocols to and from all other protocols that are referenced to SAREF.”

Took a survey of existing models transformed them to rdf/owl and created a reference ontology.

The idea is to map existing data models and protocols together.

29. Implementation Experiences of Semantic Interoperability for RESTful Gateway Management

Bill Silverajan Tampere University of Technology; Mert Ocak, Ericsson; Jaime Jiménez, Ericsson

“a gateway needs to be introduced into the communication architecture that bridges between especially IP network with semantic data models and non­IP short range radio technologies with proprietary data models” [BLE, ZigBee]

“Integrating such proprietary data models to the network requires the gateway to translate between the data models. This translation is done using proprietary methods in most of the current gateway implementations and hence, creates silos between different gateway manufacturers.”

“Surprisingly, many of the organizations are creating similar application semantics than, in practice, only differ on the vocabulary used”

Uses “Hypermedia As The Engine of Application State (HATEOAS)”

30. Key Semantic Interoperability Gaps in the Internet-of-Things Meta-Models


Ned Smith Intel; Jeff Sedayao Intel; Claire Vishik Intel

“Semantic interoperability of IoT depends heavily on a flexible, simple yet effective meta-model. A tag- value model such as that proposed by Project-Haystack appears to satisfy these criteria, but not fully.”

“Security management interoperability appears to be the most significant set of functionality that should be common across all IoT networks”

suggests use of blockchain for authorities.

"<tag> <ontology> <authority> <blockchain>"

Can’t say I understood everything in this. Guess I’m missing a lot of context

31. Open Connectivity Foundation oneIoTa Tool

J. Clarke Stevens

Interesting collaborative tool for creating interop between IoT systems.

32. Derived Models for Interoperability Between IoT Ecosystems

J. Clarke Stevens, Piper Merriam

OCF – Derived Models for Interoperability Between IoT Ecosystems_v2-examples.pdf

“The Open Connectivity Foundation’s (OCF) oneIoTa tool is essentially a web-based, Integrated Development Environment (IDE) for crowd-sourcing data models for the Internet of Things”

some examples of simple and complex conversations using rules.

33. Semantic Interoperability in Open Connectivity Foundation (OCF)

Ravi Subramaniam, Open Connectivity Foundation (OCF)

“The OCF approach is Resource-oriented with a peer to peer RESTful architecture. The approach also follows a declarative paradigm which requires the explicit definition of information, data, semantics and objectives – these declarative statements are bound to imperative actions in a late-binding manner.”

– standards org with various working groups for interop, large companies.

34. IoT Security in the context of Semantic Interoperability

Darshak Thakore, CableLabs

“can the semantic information about a model also include its security characteristics as a first class member?”

35. IoT Bridge Taxonomy

Dave Thaler, Microsoft

Assuming heterogeneity in protocols and schemas how can we achieve interoperability? (protocol and schema bridges)

“In general, we believe that bridges should use specific schema bridges for known data models (which we call “static schema bridges”), and fall back to using a dynamic schema bridge when no specific schema bridge is found for a discovered resource.”

36. Summary of AllSeen Alliance Work Relevant to Semantic Interoperability

Summary written by Dave Thaler, Microsoft

An explanation of the alljoyn standards, some taken from the website.

37. Internet of things: Toward smart networked systems and societies The Ontology Summit 2015

Mark Underwood a, Michael Gruninger b, Leo Obrst c,∗, Ken Baclawski d, Mike Bennett e, Gary Berg-Cross f, Torsten Hahmann g and Ram Sriram h a Krypton Brothers, Port Washington, NY, USA b University of Toronto, Toronto, Canada c The MITRE Corporation, McLean, VA, USA d Northeastern University, Boston, MA, USA e Hypercube Ltd, London, UK f Knowledge Strategies, Washington, DC, USA g University of Maine, Orono, ME, USA h National Institute of Standards and Technology (NIST), Gaithersburg, MD, USA

“Communiqué of the Ontology Summit 2015” – what ontologies could do for IoT interop.

“A critical obstacle in the widespreadadoption /application of ontologies to earthscience and sensor systems is the lack of tools that address concrete use cases. Developers will need to focus on those tools and techniques that support the deployment of ontologies in IoT applications.”

38. YANG-Based Constrained Management Interface (CoMI)

Peter van der Stok, vanderstok.org; Andy Bierman yumaworks.com

Proposal for adapting the YANG data modelling language for low-power, low-connectivity connected devices. The model is shared by client and server before deployment. YANG is flexible enough to express the data models required. Being adapted by IETF CORE WG for use with CoAP.

?? Submission for IAB IoT Semantic Interoperability workshop 2016

Google

“Our goal is to work with IOT vendors and schema.org to create interoperable schemas that can be absorbed by a range of intelligent cloud services and local apps.”

Beacons, brillo, a hub / gateway and cloud platforms.

“We are still at an early stage of identifying commonalities (requirements) and thinking about interoperability between efforts by Google/Alphabet teams”

“how can we find a good balance between usability and flexibility (complexity) e.g. in terms of nesting common elements vs. precision and size of schema without nesting”