Re: [WotT IG] Architecture draft

Hello WoT-ers,

Just an offer up for review is the APIs that was done for Intel(r) Edison. Here is the API spec:

http://iotkit-comm-js.s3-website-us-west-2.amazonaws.com/api/index.html

Wiki: https://github.com/intel-iot-devkit/iotkit-comm-js/wiki/Iotkit-comm

Code is on github here: https://github.com/intel-iot-devkit/iotkit-comm-js

Thanks
Dzung Tran

From: "dsr@w3.org<mailto:dsr@w3.org>" <dsr@w3.org<mailto:dsr@w3.org>>
Date: Monday, April 27, 2015 at 2:53 AM
To: "Kerry.Taylor@csiro.au<mailto:Kerry.Taylor@csiro.au>" <Kerry.Taylor@csiro.au<mailto:Kerry.Taylor@csiro.au>>
Cc: "public-wot-ig@w3.org<mailto:public-wot-ig@w3.org>" <public-wot-ig@w3.org<mailto:public-wot-ig@w3.org>>
Subject: Re: [WotT IG] Architecture draft
Resent-From: <public-wot-ig@w3.org<mailto:public-wot-ig@w3.org>>
Resent-Date: Monday, April 27, 2015 at 2:53 AM


On 27 Apr 2015, at 04:07, <Kerry.Taylor@csiro.au<mailto:Kerry.Taylor@csiro.au>> <Kerry.Taylor@csiro.au<mailto:Kerry.Taylor@csiro.au>> wrote:

Dear WoT-ers

http://hollobit.github.io/swot-model/

I have just had a look at this architecture.

I think there should be a much clearer differentiation between “WoT devices” and “WoT Servers” .
Obviously we would want to enable that a  Thing that is a “WoT device” could  also  host a “WoT server” but the two  should be firmly distinguished (with, possibly, some attention to a special  low-cost internal interface between a co-hosted server and device that does not assume an Ethernet or wireless connection. But as this capability would be internal to  an implementation it does not really need to be standardised).

The concept of a “WoT Device” (that necessarily includes a “Wot Server”) plus “other WoT Devices” is inelegant and confusing.  Surely those “other WoT Devices” would also have “Sensors”  and should conform to the WOT-3 interface if possible, or otherwise make their internal sensors visible through WoT-4 without having to also offer WOT-1 and Wot-2?

With hindsight, I should have left the introduction of web of things devices until later, as the idea of embedding a server with a device that also includes sensors and/or actuators is really quite simple. It assumes that the web of things semantics for metadata, events, properties and actions can be overlayed on the protocol used to connect to this server. Where this isn’t practical, you then need a gateway of some kind that implements the device abstraction layer mapping from the internal IoT protocols to the external web of things model.

CoAP seems like a natural fit, but I am less clear about Bluetooth Smart devices, and am taking a closer look, particularly for healthcare related devices.  There is no fundamental requirement for the devices to be always on and permanently connected via IP.  For battery operated devices, or especially devices that scavenge ambient power, the devices will be asleep/off most of the time, and only wake up when needed to communicate with other devices. This fits fine into the web of things model if you assume that the server hosting the proxy for the device knows when to expect to communicate with the device. For instance, the device could switch on its “radio” at regular time slots. The server hosting the proxy could also listen for irregular communication, e.g. when the device wants to transmit an event or property update prior to the next scheduled time slot.

Also, note the  widely used Semantic Sensor Network vocabulary  (on track for  Recommendation in the Spatial Data on the Web Working Group)  models “Sensing Devices” as both “sensors” and “devices” (allowing inheritance of characteristics from both ) -- it would make sense to me for this WoTgroup to aim  fill in more about the device capabilities that is needed for this WoT role.

Quite so, and I am hoping that we can build upon the work you have already done. Some devices may transmit individual data points, whilst others buffer them up and transfer a block of data.  We need a way to express the metadata that describes how a particular device operates. This is where a survey of particular devices and IoT communications technologies would be very helpful.  To make this quite concrete, I am developing some experimental open source software, that to start with is based around JavaScript and node.js.  There are lots of modules available for node.js which makes it really attractive for rapid prototyping.  This includes support for a range of IoT protocols, including CoAP, MQTT, Bluetooth Smart and ZigBee. For browser to server, and server to server communication I am starting with HTTP and Web Sockets.

What would help for demo purposes would be recommendations on low cost devices to experiment with, and also for existing IoT platforms with deployed sensors and actuators for building experimental bridges to. Any suggestions?

—
   Dave Raggett <dsr@w3.org<mailto:dsr@w3.org>>

Received on Monday, 27 April 2015 17:08:14 UTC