sk: would like to ask you all about your devices

da: LED board, MCU and proximity sensor

(Sebastian take notes on the flipchart)

da: and brightness sensor

sk: what kind of scenario?

da: the proximity sensor reads the proximity
... the sensor can detect the LED's brightness too
... there is a script to control how to change the color
... need scripts for the LED and the sensor
... and a micro event processor on another board
... changing RGB values

sk: what kind of building blocks inside?

da: using TD
... also use scripting

sk: available online?

da: not yet
... also might work with other devices

sk: can work with Johannes's device?

jh: 2 devices: (1) basic LED board regularly changes the brightness

(Johannes connects his PC to the projector)

sk: do you have brightness sensor?

jh: shows the UI of the client "basicLed"
... another UI for "fancyLed"
... and "servient" and "counter"
... basicLed works on a raspberry pi and siemens light board
... "voter" UI to let people vote "tooCold" or "tooHot"
... servers upload TD to the repository
... shows concrete scripts for "voter"
... dynamically upload the script to the server
... collaboration for producing
... but experiencing some issue

sk: people can download the script and run that locally?

jh: yes

sk: would be great if Darko's device can work with Johannes's

mk: connects the projector to his pc
... brought this "BACnet Thing"
... BACnet controller - KNX Room Unit and Lighting Controller/Blinds Controller
... Simulated I/Os at the top
... lighting controller and blinds controller actuate devices
... overview and summary
... features and challenges
... error handling, interaction not fit property/action/event
... property-specific encoding, property-specific bindings
... sub-resource interaction, singleton event modelling
... can provide this device for others' scenarios
... would try, e.g., Johannes's servient and Panasonic's device in Japan using Echonet
... including TD, protocol binding

sk: Nimura-san, short introduction for your device?

nk: shows his slides on the projector
... one page
... Scripting API Implementation
... would connect with Simens's script

sk: what kind of communication between LED and WoT servient smartphone?

nk: legacy BLE interface
... App Script access the ExposedThing via the ConsumedThing

rm: shows his slide
... Overview of our system
... smart home in Kanazawa, Japan
... server in Nagoya
... and the client here in Beijing
... Functional structure
... WoT I/F is supported on the server
... others are Fujitu's original I/F
... HTTP + XML/SOAP
... compatible to ITU-T standard
... shows live-stream video from Kanazawa, Japan

sk: can we control this smart house from here?

rm: yes
... but there is some network problem now
... will check with my colleagues tomorrow
... Nimura-san (and his client software) knows the IP address

sk: shows his device
... Scenario Setup
... ESP8266 (NodeMCU), Temperature sensor, ...
... if it's too hot, the temp sensor detect that
... the sensor sends "search for action @type="tooHot" to the TD repository
... and the TD repository sends TD back to the sensor
... explains the sequence

ka: the temp sensor is installed/attached to each person to detect who feels how?

sk: yes

(some more discussion)

ka: inspired by Sebastian's demo scenario
... and think there is a possibility we need some smart decision maker module who makes decision on who to send which TD to whom based on the situation
... e.g., if the temperature is hotter than 100 degree centigrade, maybe the TD should be sent to the fire extinguisher/evacuation systems instead of the air conditioner

Demo scenario on the flipchart (Click to enlarge)

Demo scenario copied on the wiki

[ Prep day adjourned ]