W3C home > Mailing lists > Public > public-wot-ig@w3.org > June 2016

Re: [FYI] WWDC 2016 Apple Homekit

From: Francois Daoust <fd@w3.org>
Date: Mon, 27 Jun 2016 12:42:22 +0200
To: Scott Jenson <scottj@google.com>, Dave Raggett <dsr@w3.org>
Cc: 전종홍 <hollobit@etri.re.kr>, "public-wot-ig@w3.org" <public-wot-ig@w3.org>
Message-ID: <5771030E.60007@w3.org>
Hi Scott, all,

Le 22/06/2016 16:21, Scott Jenson a écrit :
> On Mon, Jun 20, 2016 at 12:04 PM, Dave Raggett <dsr@w3.org
> <mailto:dsr@w3.org>> wrote:
>
>     I very much agree with what you say. Is this something that you can
>     help to realize? It would be great to have Google involved. Do you
>     have any comments on the new Web of Things Interest Group Charter
>     [1] currently undergoing W3C AC Review, and the early draft charter
>     for a Web of Things Working Group [2]?  The Interest Group could
>     study ways to support versioning, and if there is sufficient
>     consensus, this could be standardized in the Working Group. What
>     suggestions do you have in respect to standardizing the
>     device/service models for specific domains such as smart homes?
>
>
> I'm happy to help as I can, but as there are multiple teams at Google
> working on various IoT projects and I can't speak for them. I will
> suggest, however, that one of the key groups contact you. Is someone
> from Apple already on this list and participating?
>
> As to standardizing on the device/service model, it usually helps to do
> a quick survey of what existing models are already out there. In
> addition to HomeKit, can anyone else suggest any other projects? It
> seems reasonable to start with these existing models, find a resonable
> subset for "Version 1" and then allow the differences to be expressed
> using the 'optional' mechanism. Subsequent standards work would then try
> to move the optional pieces into the required.

Most Home Automation Systems provide a similar Home-like user interface 
that lets the user discover and interact with nearby devices/services. I 
had a quick look at the following projects to see which device 
categories or service characteristics they support:

- Amazon Alexa: 
https://www.amazon.com/smarthome-home-automation/b?ie=UTF8&node=6563140011
- Apple HomeKit: https://developer.apple.com/homekit/
- Crestron: http://www.crestron.com
- Google Nest: https://nest.com
- HomeSeer: http://homeseer.com
- Insteon: http://www.insteon.com
- LG HomeChat: http://www.lghomechat.com
- Samsung SmartThings: https://www.smartthings.com
- Wink: http://www.wink.com

Some of them, such as Apple HomeKit, LG HomeChat or Google Nest seem to 
restrict support to a few device categories. Targeted categories are not 
the same in each case. For instance, LG HomeChat focuses on large home 
appliances, while others focus on smaller appliances. However, it may be 
possible to view a large appliance as a group of more atomic devices 
(e.g. a refrigerator might be viewed as a light, thermostat, door, and fan).

Other systems, such as Crestron, HomeSeer or Insteon, tend to be generic 
all-purpose home automation systems and by definition try to support a 
large number of device categories. That said, their Web sites usually 
feature similar restricted sets of device categories.

Roughly speaking, trying to take a stab at a possible subset, the 
following device categories are prominently highlighted in most systems:

- Lighting
- Thermostats / Weather systems
- Outlets
- Doors (door status, door locks, garage doors)
- Shades
- Cameras (security cameras, front-door camera)

Looking at it more in terms of exposed characteristics than in terms of 
device categories:

- Brightness
- Door state
- Temperature
- Pressure
- Lock state
- Power state

Also, all of these systems incorporate some sort of grouping mechanism 
(zones, rooms, scenes, etc.).

There are of course many more projects that may be worth looking at. 
This is by no means meant to be exhaustive... and may not even be 
correct, so feel free to chime in! This is also obviously restricted to 
the home scenario, where e.g. geolocation does not really play a role. 
Perhaps not surprisingly, these categories and characteristics seem to 
match the examples that I often see mentioned in this WoT IG.


Taking this back to a discussion on standardization, I note that the 
current proposed draft charter [1] for a possible Working Group focuses 
on creating a Web-based abstraction layer but leaves concrete 
instantiations of that layer out of scope. The abstraction layer is a 
means to an end. I wonder if leaving the end out of scope is a good idea.

Other device-focused working groups at W3C are typically chartered to 
work on exposing a particular set of functionalities:

- The Device and Sensors WG develops 6 concrete APIs (e.g. Battery 
Status, Wake Lock, Proximity, Ambient Light):
  http://www.w3.org/2016/03/device-sensors-wg-charter.html
- The Second Screen WG only deals with second screens:
  http://www.w3.org/2014/secondscreen/charter.html
- The TV Control WG only deals with tuners:
  http://www.w3.org/2016/03/tvcontrol.html
- The Automotive WG is more generic in scope, but builds upon a 
previously agreed set of Vehicle Data interfaces:
  https://w3c.github.io/automotive/vehicle_data/data_spec.html

These WG sometimes develop a generic "platform" or "framework" to ease 
their work:
- The Generic Sensor API:
  https://w3c.github.io/sensors/
- The Vehicle Information Access API:
  https://w3c.github.io/automotive/vehicle_data/data_spec.html

... but they also specify the "end", meaning the concrete specifications 
that make use of that platform.

I believe that it would be useful to scope a possible Working Group to 
an initial set of concrete device categories as well. Could the above 
list provide a useful starting point?

Thanks,
Francois.

[1] https://w3c.github.io/wot/charters/wot-wg-2016.html
Received on Monday, 27 June 2016 10:42:57 UTC

This archive was generated by hypermail 2.3.1 : Monday, 27 June 2016 10:42:58 UTC