Meeting minutes
ECHONET review/updates/translations
Matsuda: a use case consists of ECHONET devices
McCool: for people at home and outside home?
Matsuda: yes, people going out of the home
McCool: fyi, OGC is working on Geofencing to identify the location
Matsuda: ok
… but please note this use case itself doesn't use Geofencing
McCool: ok
… the smartphone is the UI
… going to talk with the cloud service
… so not directly talk with the devices
Matsuda: right
McCool: would assume the connections is HTTP-based
Matsuda: yes, that's my assumption
McCool: ECHONET consolidated Things and other parties' devices included here
… what is a bit confusing is
… having two hubs
… 1. ECHONET Lite Controller at the home
… and 2. Device manufacturer's server on the cloud
Matsuda: some devices can be directly connected to the device manufacturer's server
… but wanted to avoid confusion
McCool: it's common to have multiple paths to the cloud, e.g., SmartThings in addition to ECHONET
Matsuda: ECHONET itself doesn't specify the protocol between the ECHONET controller and the device manufacturer's server
McCool: ok
… btw, the latest template has an additional section of "Variants"
… to describe possible variants of the proposed use case
… if applicable
Matsuda: need to check with the ECHONET HQ if need to add it
McCool: that's not mandate
… our main target is the Web interface
… i.e., Smartphone-Service provider's serer A-Device manufacturer's server
Kaz: so the Service provider's server A and B would handle the possible binding between the ECHONET Lite Web API and the WoT
Matsuda: yes
McCool: possibly a 1:1 mapping
Matsuda: it depends on the level of coverage of the ECHONET Lit Web API capability by WoT
Kaz: maybe we might want to have an ECHONET Profile for WoT at some point to clarify the coverage
McCool: the smartphone might talk with all the devices one by one
… or the Service provider's server A may provide a virtual device including those devices
Kaz: yeah
… as Matsuda-san described in March, ECHONET Lite Web API has device grouping capability
… but probably for this use case and the upcoming Plugfest, they would like to start with one-by-one connection
McCool: ok
… I got the use case itself
… and would like to think about some more possible settings as useful subsets (if possible)
… (goes through the ECHONET Lite Web API Dev Specs v.1.3.0)
ECHONET Lite Web API Dev Specs v.1.3.0
(Their "Device Description" is described P32 and the following pages.)
McCool: the next step is whether we merge this proposed use cases into the main Use Cases document or not
… would have a prototype implementation as well
Kaz: yes, that's why I'm asking them to join the Plugfest during TPAC
McCool: would see which device can be mapped to TD how
… I think this interface, e.g., for battery, is quite similar to TD
Kaz: can we ask Matsuda-san to start generating the HTML?
McCool: would see Geofencing mentioned as a possible variant
… but if Matsuda-san can wait, would be better to talk with Lagally next Tuesday
… and then make decision
Matsuda: the next official meeting on the ECHONET side will be held Wednesday next week
… so can't guarantee we can add additional variants
Kaz: I think Geofencing itself is rather a horizontal feature which could be applied various vertical use cases
… so don't have to describe it within this use case description
… we can think about combination of Geofencing and other vertical use cases later
McCool: that's true
[adjourned]