<scribe> scribenick: kaz
opening remark from Mr. Yoshiaki Ohsumi, the AC Rep. from Panasonic
kajimoto-san goes through his slides
kazuo: Hub-centric model is already
implemented
... another is Cloud-centric model
kawa: various products connected with
several existing protocols
... e.g., Echonent, ZigBee, dlna, allseen, knx, ...
... using multiple protocols cause higher costs
... safety, security and robustness
... risks of connected home include privacy leakage, hazardous
operations
... would enable emergency operation in case of disaster
... possible solutions
... 1. gateway model
... 2. Wot API mapping
... defining WoT API absorbing the device difference
... service examples
... immediate control any device from anywhere
... using various underlying protocols
... second example is reducing electric power consumption
... by demand response
... third example is automatic adjust
... choosing preferred options based on who is staying at
home
... Demonstration
... components of the demo
... - WoT client, WoT server in the cloud, home gateway, Things
(air conditioners)
... remote access using a smartphone app
... lights and air conditioners
... shows the actual interface data for the demo
... things description written by JSON-LD
... device can be controlled using this mechanism
... next demo is notification of energy consumption
... can turn on/off based on the notification
... next is personal adaption
... personal preference can be handled by this system
... we have some more scenarios
... please come to the demo booth at the entrance of the demo
hall
... and see our demos
... Conclusion
... let's work together!
claes: question
... configuration of the home gateway
(p10: 2-2. Solution 1: Gateway model)
claes: handling underlying
protocols
... how the server talks with the home gateway?
kawa: now using HTTP for the communication
claes: and the local server communication is also HTTP
kawa: yes
claes: what is done by the
gateway
... and what is done by the server?
kaji: thing description is described at the gateway
naka: used for various services
... object-orient model
... ECHONET is an international standard
... air conditioner has several capabilities
... those capabilities are modeled using the object model
... can be used for the WoT API
ishii: comments, questions?
dsr: structure of the mechanism?
kaji: suffered from various legacy
protocols
... WoT API could be a wrapping mechanism for the legacy
protocols
... WoT API is a very high-level abstract interface
joerg: you can break down into
different aspects
... different interaction models
... notion of what the semantics is like
... more tricky part
... manage using some kind of dictionary?
... we WoT IG is thinking of Thing Description
... and would split the issues
<dsr> Set of high level messages for the Web of Things abstraction layer, e.g. property update, event, action, response, register proxy for a thing, unregister proxy, and so forth.
kaji: there are many legacy
protocols
... the functionality depends on the air conditioners model
type
<dsr> ... some airconditioners only provide cooling not heating
kaji: common API can be defined regardless of the types
louay: regarding this picture
... (hub-centric vs cloud-centric)
... might want to think about sense vs service
... accessible services
kaji: current legacy protocols are
designed for each device
... user experience is very important as you mentioned
<dsr> … by its manufacturer
joerg: claes already touched
but
... even the first f2f had some discussion on the
architecture
... how to connect basic legacy devices
... the model using servient
... our issues are already captured by these models?
... or something missing?
kaji: a bit confusing
... implementations of current Panasonic products
... gateway provides the functionality of WoT servient
... we must provide cloude-based APIs
... a WoT servient is implemented withing the Hub (gateway)
joerg: virtual representations
... not up to the implementation decision?
kaji: regardless of the actual implementations
<dsr> Implementation decision as to whether things are placed in cloud, gateway or the home devices
nagano: what the TD would
return?
... what kind of TD?
<dsr> (does this depend on whether the thing is in the cloud, gateway or device?)
nagano: if the GW function handles
multiple devices
... what kind of TD will be sent as the response?
kaji: some specific session is
created for each communication
... between devices
<dsr> [Dave thinks the thing description can be the same, but the communications metadata may vary according to which server hosts the thing]
kaz: so the GW function handles multiple connections using some identification mechanism like IPv6
kaji: yes
<dsr> Note that a device inside a firewall can register a proxy in the cloud by which others can find and interact with that device.
[ adjourned ]