W3C home > Mailing lists > Public > public-wot-wg@w3.org > September 2018

[online-plugfest] minutes - 28 September 2018 - slot B

From: Kazuyuki Ashimura <ashimura@w3.org>
Date: Fri, 28 Sep 2018 16:50:04 +0900
Message-ID: <CAJ8iq9VfTjOiuGqzPp275Bxu2tSAtWj=_MDG81pNeR4-eX9r6A@mail.gmail.com>
To: Public Web of Things IG <public-wot-ig@w3.org>, public-wot-wg@w3.org
available at:

also as text below.





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

                               - DRAFT -

                            Online PlugFest

28 Sep 2018 - slot B


          Kaz_Ashimura, Michael_Lagally, Itaru_Nakagawa,
          Kunihiko_Toumura, Michael_McCool, Toru_Kawaguchi,
          Takeshi_Sano, Takeshi_Yamada, Sebastian_Kaebisch,





     * [2]Topics
         1. [3]PRs
         2. [4]Siemens
         3. [5]Oracle
         4. [6]Fujitsu
         5. [7]Panasonic
         6. [8]Hitachi
         7. [9]AOB
     * [10]Summary of Action Items
     * [11]Summary of Resolutions


   McCool: new one from Benjamin

   <inserted> [12]https://github.com/w3c/wot/pull/556

     [12] https://github.com/w3c/wot/pull/556

   McCool: (checks Intel proxy setting)


   Sebastian: some of the TDs are ready and put on the GH
   ... but made some error within the TDs
   ... for the namespace

   McCool: we have to include some additional namespaces for
   schema as well

   <McCool__> everyone should use this context snippet:
   "@context": "[13]http://www.w3.org/ns/td",

     [13] http://www.w3.org/ns/td

   McCool: any update on the bug with the Directory?


     [14] http://plugfest.thingweb.io:8081/

   Sebastian: not sure about that


     [15] https://github.com/thingweb/thingweb-directory

   Sebastian: would add MQTT binding for node-wot
   ... also some request from Panasonic

   McCool: I'm not running MQTT things personally
   ... so Koster and Panasonic?

   Sebastian: yeah, would like to test those end points
   ... have to ask Panasonic
   ... planning to use the same one of parking service which I
   used in Bundang
   ... possible collaboration with Panasonic's smart home scinario


   Lagally: worked on integration scenario
   ... environment sensors from KETI
   ... if the room is empty
   ... organic components in the air
   ... turn the light if any problems
   ... starting with simulations
   ... please send me a quick know about your integration scenario
   ... maybe only one due to time restriction
   ... if you have something available on the Internet, please let
   me know

   McCool: my devices are now exposed
   ... different kinds of authentication
   ... TD available here


     [16] https://github.com/w3c/wot/blob/master/plugfest/2018-sept-online/TDs/Intel/OCF-TDs.json

   Kaz: ah, so this TD includes more than one device

   McCool: yes, 21 devices
   ... physically available on one same frame

   Kaz: interesting
   ... would be interesting how to bundle multiple TDs
   ... and how to split them

   McCool: any other questions?
   ... could create an array of hyperlinks
   ... have not yet done, though


   Sano: so far Fujitsu proxy could connect with Siemens event
   source by CoAP
   ... also Panasonic using HTTPS

   Itaru: used curl
   ... ignored certification check
   ... almost same logic with the gateway

   Kaz: connected with which?

   Itaru: festlive from Siemens

   Sebastian: Matthias is not available today
   ... HTTP sounds like cloud connectivity

   Lagally: there is some interface for fest-plant
   ... exposed by node-wot
   ... depends on which TD is used
   ... currently we don't see the picture
   ... anything to improve?

   Sebastian: check with Victor
   ... will send a message

   Lagally: tx

   Sano: would mention our plan
   ... connection check between proxy and Siemens gateway
   ... set up locally
   ... connectivity for Matthias

   Kaz: plan by slot C today?

   Sano: yes

   McCool: any additional network access you need?

   Itaru: want to test client-side
   ... mainly European and American ones
   ... until slot C (10pm JST)
   ... and JP ones another day
   ... meaning sometime next week

   Kaz: ok


   Toru: tried 3 things
   ... (share his screen)
   ... tried to access Fujitsu's remote proxy
   ... found some devices tehre
   ... also accessed our own hue light via Fujitsu proxy
   ... but there was no cause header, so didn't work
   ... we support bearer token
   ... related to our own server, so worked well
   ... on the other hand, got empty responses from blue pump
   ... response was success but payload was empty
   ... another one
   ... Eurecom server
   ... successfully connected
   ... however, didn't support cause header
   ... also Eurecom has self-signed certification for bearer token
   ... from browser there is no way to set credentials

   McCool: they could regenerate credentials and provide them?

   Toru: would be helpful
   ... another issue, portal looked like not working for Intel

   McCool: OCF gateway crashing
   ... all up again now
   ... will fix all the context files
   ... in the middle of configuration for hardware
   ... all straighten out now

   Kaz: so Panasonic should tray again?

   McCool: yes
   ... data payload was empty due to discovery failure
   ... fixed context for you
   ... should work now
   ... make sure the data is valid

   Toru: would you share the screen?

   McCool: (shares his screen)
   ... using playground to validate the data
   ... will fix the data
   ... I'm using iotschema.org
   ... any more additional schemas?

   Lagally: seems there is some error with the URL

   McCool: (add parenthesis to make the TD valid)
   ... shows the TD spec draft


     [17] https://w3c.github.io/wot-thing-description/

   Sebastian: your TD looks ok
   ... maybe some issue with GH
   ... can you remove the line of "iotschema.org"?

   McCool: (still gets an error)

   Sebastian: strange

   Lagally: 2 comments
   ... using a TD with array of context
   ... maybe you can click "paste this schema"

   McCool: (go through the TD)
   ... seems to be reasonable
   ... will make an issue and bring it to Ege

   Itaru: one topic to discuss
   ... have an issue with protocol binding mismatch
   ... HTTP server POST method with some value
   ... we use PUT method to update property
   ... there 2 cases
   ... 1. Intel's OCF server uses POST
   ... 2. Eurecom also uses POST
   ... 3. need to specify which method to use
   ... otherwise we would have problem with binding

   McCool: OCF devices require to use POST
   ... will fix that for OCF devices
   ... in general we need to clarify what method to be used
   ... anything else?


   Toumura: this afternoon, tried to connect with Intel
   ... created something like illumination sensor
   ... if the illumination value is lower than some specific value
   the LED lamp would be turned off

   McCool: turned off and on

   Toumura: using POST method
   ... so I changed my code to match it
   ... would try Eurecom

   McCool: would it help to add method name?

   Toumura: if you specify that using the "form" field, that would
   be helpful

   McCool: can do that
   ... let's adjourn the call but I can stay here
   ... will work on the bridge

   <itaru> EureCom don't use POST, but also not PUT, don't know
   which method they use...


   Kaz: if you have any specific plan for collaboration already,
   please put that idea on the spreadsheet
   ... if not, you can continue collaboration on this IRC
   ... Google hangout or WebEx

   McCool: will stay here on webex

   [slot B adjourned but McCool can stay on the call]

Summary of Action Items

Summary of Resolutions

   [End of minutes]

    Minutes manually created (not a transcript), formatted by
    David Booth's [18]scribe.perl version 1.154 ([19]CVS log)
    $Date: 2018/09/28 07:48:08 $

     [18] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [19] http://dev.w3.org/cvsweb/2002/scribe/
Received on Friday, 28 September 2018 07:51:08 UTC

This archive was generated by hypermail 2.3.1 : Friday, 28 September 2018 07:51:08 UTC