[wot-f2f] minutes - Plugfest preparation - 25 January 2016

available at:
  https://www.w3.org/2016/01/25-wot-minutes.html

also as text below.

Kazuyuki

---
   [1]W3C

      [1] http://www.w3.org/

                               - DRAFT -

            WoT IG f2f in Sophia - Plugfest Preparation Day

25 Jan 2016

   See also: [2]IRC log

      [2] http://www.w3.org/2016/01/25-wot-irc

Attendees

   Present
          Soumya_Kanti_Datta(Institute_Telecom),
          Kaz_Ashimura(W3C), Kazuaki_Nimura(Fujitsu),
          Takuki_Kamiya(Fujitsu), Daniel_Peintner(Siemens),
          Oliver_Pfaff(Siemens), Ari_Keranen(Ericsson),
          Matthias_Kobatsch(Siemens), Victor_Charpenay(Siemens),
          Arne_Broering(Siemens), Johannes_Hund(Siemens),
          Katsuyosi_Naka(Panasonic), Yoshiaki_Ohsumi(Panasonic),
          Sebastian_Kaebisch(Siemens), Darko_Anicic(Siemens),
          Carsten_Bormann(TZI/IRTF),
          Rui_Pedro_Fereira_da_Costa(Institut_Telecom),
          Louay_Bassbouss(Fraunhofer_FOKUS),
          Toru_Kawaguchi(Panasonic), Michael_Koster(remote),
          Christian_Glauss(Siemens), Dave_Raggett(W3C)

   Regrets
   Chair
          Johannes

   Scribe
          kaz

Contents

     * [3]Topics
         1. [4]Logistics
         2. [5]Plugfest planning
         3. [6]Initial plugfest
     * [7]Summary of Action Items
     __________________________________________________________

Logistics

   <inserted> (everybody working on their plugfest demo)

   johannes: (talk about the logistics plan)
   ... in the afternoon all the plugfest participants are
   encouraged to present one-page presentation on their plugfest
   demo

   soumya: open day room will be #151 tomorrow

   sebastian: TD repository
   ... [8]http://vs0.info.ethz.ch:8080
   ... coap://vs0.inf.ethz.ch:5687

      [8] http://vs0.info.ethz.ch:8080/

   soumya: lunch place is #250 Salsa on level -2

   <michael> OK, I found the IRC

   <mkovatsc> For now, we have a Hangout running at
   [9]https://hangouts.google.com/hangouts/_/xcqkbhnlc4dzgdrw3jdtj
   fdtu4a

      [9] https://hangouts.google.com/hangouts/_/xcqkbhnlc4dzgdrw3jdtjfdtu4a

   <mkovatsc> There might be a proper Webex later

   <michael> OK, I could switch to "original version" of hangouts
   and the chat works

   [lunch]

Plugfest planning

   johannes: any volunteer to start?

   sebastian: still have problems but can start

   <mkovatsc> any remote participants in here?

   <mkovatsc> we want to have quick pitches about what everyone
   brought to the Plugfest at 2pm

   sebastian: (Auto TD Registration & T2T Setup)
   ... have two things
   ... heater and temp sensor
   ... first scenrio is register each TD from the heater and the
   sensor to the TD repository
   ... also provide the source for task description

   <michael> Michael here

   sebastian: temp sensor should send the task for the heater to
   turn on/off
   ... temp sensor sends a message to the heater
   ... to turn it off
   ... HTTP connection
   ... all I need is thing description on data types, etc.
   ... simple interaction using that

   kaz: do you have two different implementation models?

   sebastian: no
   ... for the initial stage, devices send their Thing Description
   to the central TD repository
   ... there are various possible implementation models
   ... note that the GUI on the PC to configure the sensor is
   optional and just used to handle the sensor easily

   <mkovatsc>
   [10]https://hangouts.google.com/hangouts/_/xcqkbhnlc4dzgdrw3jdt
   jfdtu4a

     [10] https://hangouts.google.com/hangouts/_/xcqkbhnlc4dzgdrw3jdtjfdtu4a

   <inserted> matthias: we are

   <mkovatsc> we are adding the presentation computer to the
   hangout to share slides

   (the iPad has been connected with Michael finally)

   toru: next Panasonic
   ... (Nice plugfest overview and findings)
   ... (Background and objectives)
   ... in Sapporo, had discussion on server/client model
   ... would verify interoperability this time
   ... (System configuration)
   ... implemented security features
   ... collaborative work with Siemens
   ... access to the Wot Servient on the cloud
   ... devices in Osaka
   ... (Servient Specificaiton)
   ... Protocol, Method, Things and properties, Security,
   Discovery, Implementation
   ... lights and air conditioner
   ... using MS Asure for the cloud side
   ... (Findings from the plugfest)
   ... convention of naming properties, property value range,
   feedback of operation
   ... should ignore the out-of-range value? or substitute with
   the Max/Min values?

   johannes: one question
   ... asynchronous feedback?

   toru: showing the progress to the users, etc.

   david: (shows homestar.io page)
   ... (homestar.io:20000/api/things)
   ... shows description
   ... @id, @context, istate, ostate, model, meta
   ... also JSON-LD description

   <dpjanes>
   [11]http://homestar.io:20000/api/things/urn:iotdb:thing:REST:6a
   cd18449fe571d3a1d12ef66aa443dd:rest-dimmer-light/model

     [11]
http://homestar.io:20000/api/things/urn:iotdb:thing:REST:6acd18449fe571d3a1d12ef66aa443dd:rest-dimmer-light/model

   <dpjanes>
   [12]https://github.com/dpjanes/homestar-rest/blob/master/models
   /RestDimmerLight.iotql

     [12]
https://github.com/dpjanes/homestar-rest/blob/master/models/RestDimmerLight.iotql

   david: istate is the actual state
   ... ostate is what is requested
   ... let's look at the actual data
   ... (data)
   ... change Web API
   ... and see the resulted date is changed
   ... this is the model here
   ... might have temperature sensor with some specific
   temperature range
   ... switching over to my terminal
   ... (select id, meta:schema:name)
   ... (select id, istate:temperature)
   ... kelvin or celsius for temperature

   <dpjanes> set istate:on = true;

   david: two different devices use the same semantics
   ... but what's the best way?

   carsten: would be good to have presentation tomorrow but pretty
   interesting demo

   johannes: a bit hard to follow
   ... the concept of actions
   ... you model state transition using istate/ostate

   david: how do we know?
   ... two ways
   ... we can detect the state transition by checking the actual
   change of states

   carsten: we do have interface and find out the change
   ... the action interface is useful for cooking dinner

   johannes: we can discuss the detail during one of the TF-AP
   calls
   ... is that OK?

   david: ok

   (next Nimura-san from Fujitsu)

   <dpjanes> Docs here for how to play with the API

   <dpjanes>
   [13]https://github.com/dpjanes/homestar-coap/tree/master/docs/p
   lugfest

     [13] https://github.com/dpjanes/homestar-coap/tree/master/docs/plugfest

   @@@nimura

   (next Darko)

   darko: IFTTT Rule Engine
   ... IFTTT statements:
   ... if this = if a certain event occurs
   ... (IFTTT Rule Engine Embedded in a THing)
   ... Client API, Server API, Physical API, TD + IFTTT Rule
   Engine
   ... (Event)
   ... Event Rule -> NodeMCU - Brightness sensor
   ... (Action)
   ... Action Script -> NodeMCU - Brightness sensor
   ... (T2T Interaction)
   ... Event Rule & Action Script -> NodeMCU-Brightness Sensor ->
   NodeMCU-LED

   kaz: from software viewpoint, those NodeMCUs are WoT servients?

   darko: yes

   nimura: using COAP?
   ... we Fujitsu use HTTP

   darko: the rule engine automatically uses the client/server
   mechanism
   ... and the users don't see the event handling

   takuki: how does this mechanism work with the TD repository?

   darko: there is thing description on the NodeMCUs

   ari: @@@

   darko: you can make pattern on sensor's reading
   ... this is just an operation using thing description
   ... common set of operations can be handled by the rule engine

   kaz: so making a sequence of events/actions a meta command?

   darko: yes

   johannes: anybody else?

   (next Christian(?))

   chris: from Siemens
   ... (Plugfest@Nixe F2F)
   ... (Security Showcase w/ NodeMCU)
   ... assume that servient don't have own Internet connection
   ... get client_id and client_secret
   ... client registers servient and get rs_id and rs_secret
   ... more detail tomorrow

   (next Louay)

   louay: (Thing API Demo)
   ... two demos
   ... one about THing API
   ... HomeKit accessories

   <michael> slides aren't updating

   louay: weather sensor (temp, humidity)
   ... dor
   ... and outlet
   ... see:
   [14]https://github.com/w3c/wot/blob/master/TF-AP/thing-api/thin
   g-api-webidl.md
   ... inline with WebIDL description
   ... (demo window)
   ... Browse All Things
   ... request weather using sensors
   ... temperature and humidity
   ... same with the door
   ... open or closed
   ... client Web app accesses things
   ... (Thing Description Demo)
   ... another is demo on Thing Description
   ... using the same system
   ... WoT server using Node.js
   ... support HTTP

     [14]
https://github.com/w3c/wot/blob/master/TF-AP/thing-api/thing-api-webidl.md

   johannes: Node.js server?

   louay: own implementation

   johannes: @@@

   louay: there are some open questions
   ... discovery for connected things
   ... here using BLE
   ... imagine you're not at home
   ... all the things are connected with the Internet
   ... if we use iCloud, etc., we could assume same connection as
   the one at home, though
   ... the most important here is discussion on Thing API
   ... what kind of abstraction should be used is the point

   (next Tibor)

   tibor: WoT is a W3C open project
   ... shows Node.js source

   (making the fonts bigger)

   tibor: ... properties like battery_value, is_camera_on
   ... power_consumption
   ... interesting element is modular architecture
   ... HTTP, MQTT, WebRTC, etc. can be used
   ... would show HTTP demo
   ... shows terminal
   ... start HTTP REST server
   ... and shows the Web page at localhost:8888
   ... can see properties on the page
   ... also can lock/unlock devices
   ... can see the actual transferred data on the terminal
   ... web of things security at:
   [15]https://github.com/w3c/web-of-things-framework/blob/master/
   security.md
   ... not done P2P connection
   ... UML diagram available on the above page
   ... shows Node.jp source again
   ... jwt (JSON Web Token)
   ... JSON with encryption

     [15]
https://github.com/w3c/web-of-things-framework/blob/master/security.md

   johannes: implementation based on what?

   tibor: protocol and security?

   kaz: relationship between wot repository and
   web-of-things-framework repository?

   johannes: wot for the IG and framework for the CG?

   kaz: will ask Dave as well

   tibor: happy to present tomorrow

   johannes: will talk with Soumya about the schedule
   ... maybe complicated to participate remotely
   ... would involve you in the IG discussion closely

   tibor: tx

   (next Johannes)

   johannes: one brief slide
   ... (servient-side scripting API)
   ... Java-based implementation
   ... thing description parser by Victor
   ... API by Louay
   ... can show the sample script tomorrow
   ... one servient represents a device
   ... a thing can interact with each other
   ... two ways to expose functionality
   ... implemented the proposal by Oliver on security
   ... TD as some kind of manifest
   ... what should happen on the servient
   ... and what the servient should do
   ... thing to thing interaction
   ... handle overall behavior
   ... continuous scripting
   ... sample script on Github
   ... MIT licensed
   ... interact with Daniel's UI
   ... questions on this concept?

   (no questions)

   johannes: would suggest we go into actual plugfest and testing
   from now
   ... would see pair building
   ... who has implementations?
   ... two people implemented clients
   ... five people implemented servers

Initial plugfest

   daniel: which network are you using?

   sebastian: t2t

   daniel: Thing Description Repository
   ... TemperatureThingy
   ... send commands
   ... and request temperature
   ... Try AlarmThingy

   (test several interactions)

   darko: what about the brightness sensor?

   daniel: try Brightness sensor
   ... and led
   ... and MyLEDF for Nimura-san

   darko: would change the brightness now
   ... also ledOnOff

   daniel: next try MyLEDF

   johannes: should we try Panasonic?

   toru: just registered
   ... MyAirconditioner_P1

   kaz: we need to check the air conditioner in Osaka
   ... within the video, the white box at the top is LEDs
   ... the middle one is Toshiba's air conditioner
   ... and the third one is Panasonic's air conditioner
   ... we can tell whether the air conditioner is heating or
   cooling base on the direction of the fins

   toru: also shows Panasonic's client GUI
   ... turning on the security feature
   ... need to get token before sending data
   ... try LED and air conditioner

   kaz: who generates and manages the security token?

   oliver: minimal token is installed on the cloud server and the
   client

   kaz: wondering if we might want to have a standard way to
   manage/install security tokens...

   daniel_johannes: try Siemens GUI with Siemens LED
   ... and servient

   sebastian: would try Siemens GUI with Panasonic air conditioner
   ... get temperature from Siemens sensor
   ... and send the temperature data to Panasonic air conditioner
   ... this temp sensor works with the air conditioner in Osaka :)

   [ Plugfest Preparation Day adjoruned ]

Summary of Action Items

   [End of minutes]
     __________________________________________________________


    Minutes formatted by David Booth's [16]scribe.perl version
    1.128 ([17]CVS log)
    $Date: 2016/01/26 04:33:48 $

     [16] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [17] http://dev.w3.org/cvsweb/2002/scribe/