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
... http://vs0.info.ethz.ch:8080
... coap://vs0.inf.ethz.ch:5687

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

<michael> OK, I found the IRC

<mkovatsc> For now, we have a Hangout running at 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> 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> http://homestar.io:20000/api/things/urn:iotdb:thing:REST:6acd18449fe571d3a1d12ef66aa443dd:rest-dimmer-light/model

<dpjanes> 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> 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: https://github.com/w3c/wot/blob/master/TF-AP/thing-api/thing-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

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: 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

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 ]