XML Interfaces to the Internet of Things

Happy Birthday Moore's Law!

Moore's Law is 50 years old.

Or less prosaically: Moore's Law is 33⅓ iterations of itself old.

Moore's Law is dead, or at least nearly, or at least, so they keep telling me

The first time I head that Moore's Law was nearly at an end was in 1977. From no less than Grace Hopper, at Manchester University.
Since then I have heard many times that it was close to its end, or even has already ended. There was a burst of such claims this year, which caused a wag to tweet

"The number of predictions that Moore's Law is about to end doubles each eighteen months."

(I'm not sure whether I have heard more often that Moore's Law is coming to an end, or that Voyager I has left the solar system.)

A data point: The Raspberry Pi

As an excellent example, in February this year, almost exactly three years after the announcement of the first version, version 2 of the Raspberry Pi computer was announced.

Raspberry Pi

Since three years is exactly two cycles of Moore's Law, does the new Raspberry Pi deliver a four-fold improvement?

• Six times faster
• Four times as many cores
• Four times as much memory
• Twice as many USB ports
• Same size
• Same price

Moore's Law has three dimensions

Moore's Law says nothing about speed of computers. It says:

The number of components on an area of integrated circuit doubles per eighteen months, at constant price.

(Interesting factoid: a doubling per 18 months is almost exactly an increase of 100 every ten years).

So apart from time, there are three dimensions: price, size, and number of components. This means you have choices:

• get twice as much
• get something smaller
• pay less for the same.

Choices

In general we have been optimising this choice: computers have been getting smaller, cheaper and more powerful all at the same time: when you buy a new computer, it is typically a little smaller, a little better, and a little cheaper than the last one you had.

Apparently the price of new home computers peaked in 1990 at $4500. We now pay typically around one tenth of that, for a much more powerful computer.

This doesn't mean we don't get a doubling; only that the doubling happens over a longer period than 18 months.

Generations of ten

This reduction of price/increase in power has been observable since the introduction of the first commercial computers in the 50's.

(Since we're talking orders of magnitude, it doesn't matter if we're talking dollars, pounds, or euros, since they are all roughly of the same value).

50's: Mainframes, order of millions

60s/70s: Minicomputers order 100,000

70s/80s: Workstation 10,000

80s/90s: PC order 1000

90's/00s: Netbooks/Tablets Order 100

00s/10's: Pi/Arduino Order 10

Now: The ¤1 Computer

Recently the first computers of the order of one unit of currency have been appearing, such as the Arduino mini.

The Internet of Things

It is on these super-cheap devices that the internet of things is predicated.

At $1, manufacturers can add them to anything.

But Why?

If the data is there, people will use it

UK Grid

Obvious Example: Connected Alarm Clock

Wake me at 6 so I can go for a run. But not if it is raining.

Wake me in time to meet the flight. Earlier if the flight is early; later if it's delayed; earlier if there's bad traffic.

(Some of this is already happening)

Controlling remote devices

A surprising unexpected success of HTML was in controlling devices, such as home routers

Problem

The problem with this approach is that it requires not only a server on the device, but also a processor for the returned values that can check them, and generate new pages for error handling etc.

But this requires not only large amounts of memory, but also significant processing power - more than you can get from a ¤1 computer

The Solution

Let the device deliver its data as XML instances, and accept control values as XML instances.

Distribute the interface over the network.

Not new, just cheaper

Example: petrol stations in USA

Cash tills, petrol pumps, petrol tanks, and so on.

All produce, and accept, XML instances to deliver and control.

XForms are used to read off data and configure the devices.

"The future is already here — it's just not very evenly distributed." William Gibson

XForms

History: V1.0 an XML markup originally designed for Forms on the Web

V1.1: Generalised - now applications as well as forms

In preparation: V2.0 - even more generalised

XForms - The Basics

Declarative

Separation of Data, Controls and Styling

Data over the network or local

Device independent controls

Diverse implementation strategies possible

Model

Data+Constraints:

• Datatypes
• Relationships
• Read-only+conditions
• Relevance+conditions
• Required+conditions
• Value constraints

Plus where to get the data, and where to send it.

An Example

Nest thermostat

<model>
   <instance id="thermostat" 
       resource=”http://thermostat.local/data”/>
   <bind ref="ambient_temperature_c" type="decimal"
         readonly="true()"/>
   <bind ref="target_temperature_c" type="decimal"/>
   <bind ref="target_temperature_f" type="decimal" 
         calculate="../target_temperature_c*9 div 5+32"/>
   <submission resource="http://thermostat.local/data" 
               method="put" replace="instance"/>
</model> 

Display Values

<instance id="display">
   <data xmlns="">
      <temperature/>
      <target>20</target>
      <scale>C</scale>
   </data>
</instance>
<bind ref="instance('display')/temperature" type="decimal"
      calculate="if(../scale='C',
           instance('thermostat')/ambient_temperature_c,
           instance('thermostat')/ambient_temperature_c * 
                9 div 5 + 32"/>
<bind ref="instance('display')/target" type="decimal"/>

Convert back

<bind ref="instance('thermostat')/target_temperature_c"
      calculate="if(instance('display')/scale='C',
            instance('display')/target,
           (instance('display')/target - 32)* 5 div 9")/>

User Interface

The controls in XForms specify what they do, not how they look

<select1 ref="instance('display')/scale" label="Scale">
    <item label="°C" value="C"/>
    <item label="°F" value="F"/> 
</select1>

Controls

Controls

Although you could just input the target temperature:

<input ref="instance('display')/target" label="Target"/>

It is better to use the control for ranges, which allows a display of a rotary control for instance:

<range ref="instance('display')/target" label="Target" 
       step="0.5"/>

and include limits:

<range ref="instance('display')/target" label="Target" 
       step="0.5" start="0" end="30"/>

Dynamic limits

Of course, these limits depend on which scale is being used. Better still is put the limits in the instance, and link them to the scale used:

<instance id="display">
   <data xmlns="">
      <temperature/>
      <target>20</target>
      <scale>C</scale>
      <start/>
      <end/>
   </data>
</instance>
<bind ref="instance('display')/start" 
      calculate="if(../scale='C', 0, 32)"/>
<bind ref="instance('display')/end" 
      calculate="if(../scale='C', 30, 85)"/>

Dynamic limits

and then on the control:

<range ref="instance('display')/target" label="Target"
       step="0.5" start="{../start}" end="{../end}"/>

Submitting

In the model you specify where to send the data, and what to do with the returned result:

<submission resource="http://thermostat.local/data"
            method="put" replace="instance"/>

Normally you activate this with a button in the user interface:

<submit label="Submit"/>

Auto submitting

However, in a direct-manipulation interface like a thermostat, you want the new values to be submitted without further user intervention.

For that, there is an XForms action that causes the data to be submitted:

<send/>

We just need to state under what circumstances it is to be activated.

Auto submitting

In XForms, just as in HTML, you can listen for events, and then respond to them. In this case, we want to react to changes in the control:

<range ref="instance('display')/target" step="0.5" ...>
    <action ev:event="xforms-value-changed">
       <send/>
    </action>
</range>

This says: when the xforms-value-changed event happens on the range control, submit the data.

Polling

With an interface to something that is continually updating, you need to poll it regularly for updates.

<model id="model">
   ...
   <dispatch ev:event="xforms-ready"
         name="my-timer" delay="20000" targetid="model"/>
   <action ev:event="my-timer">
      <send/>
      <dispatch name="my-timer" delay="20000"
          targetid="model"/>
   </action>   
</model>

Repetition

<repeat ref="firewall/rules" label="Exceptions">
   <output ref="./port" label="Port"/>
   <output ref="./url" label="URL" />
</repeat>

Multilingual

<instance id="label"
     resource="http://example.com/labels-en.xml" />

Which looks like

<labels lang="en">
   <submit>Submit</submit>
   <help>Help</help>
   <scale>Scale</scale>
   ...
</labels>

Example

Then

<select1 ref="instance('display')/scale"
      label="{instance('label')/scale}"> ...

Not Only XML

In fact the Nest produces its data as JSON. But we don't care!

There is no essential difference between:

{"temperature": {"scale": "C"; "value": 21}}

and

<temperature>
   <scale>C</scale>
   <value>21</value>
</temperature>

XForms 2.0 accepts JSON and treats it as XML.

It is also possible to deal with text returned from a device.

Experience

Experience has shown that XForms reduces the time needed to produce an application by an order of magnitude.

For instance, one big example reduced the time from 5 years with 30 people to 1 year with 10 people: from 150 person-years to 10 person-years!

Implementations

There are a number of implementations available, including client-side and server-side implementations.

XForms is part of Open Office/Libre Office

Conclusion