[TEST] Smart home: Leaving and Coming Home

[ashimura]

Submitter

Kazuyuki Ashimura for Tetsushi Matsuda, Keiichi Teramoto, Takashi Murakami, Morio Hirahara (ECHONET Consortium)

What to be done?

The purpose of this use case is to improve the usability of home appliances for device users by allowing device users to configure the operation modes of all devices at home without configuring those devices one by one when they leave and come home.

Why WoT? (Stakeholder's interest in using WoT)

WoT is necessary to achieve interoperability among devices from various vendors.

Description

• Configuration by a device user before starting to use a service
  • A device user logs in the server of a "home management service provider" with which the user has a contract.
  • The user specifies the operation modes of lighting, air conditioner and security sensor for the time when the user is out of home, the time when the user comes home and the time when the specified amount of time has passed after the user comes home.
• When the device user leaves home
  • The device user accesses the server of a "home management service provider" with a smartphone and notifies the server that the user is going to leave home.
  • The server updates the operation modes of lighting, air conditioner and security sensor according to the configuration specified by the user for the time when the user is out of home.
  • The server reads the operation modes of lighting, air conditioner and security sensor and informs the user's smartphone of those operation modes.
• When the device user comes home
  • The device user accesses the server of a "home management service provider" with a smartphone and notifies the server that the user will return home soon.
  • The server updates the operation modes of lighting, air conditioner and security sensor according to the configuration specified by the user for the time when the user comes home.
  • The server reads the operation modes of lighting, air conditioner and security sensor and informs the user's smartphone of those operation modes.
  • When the specified amount of time has passed after the user returns home, the server updates the operation modes of lighting, air conditioner and security sensor according to the configuration specified by the user for the time when the specified amount of time has passed after the user comes home.
  • The server reads the operation modes of lighting, air conditioner and security sensor and informs the user's smartphone of those operation modes.

Gaps between the user's need and what's possible today

The method for controlling multiple devices in an orchestrated manner is dependent on the implementation of a client application in the current WoT specification. That is a reasonable design choice. However, the orchestrated control of multiple devices needs to be implemented by each client application even if the same control is done by multiple client applications.

Target Users

• [ ] Device owners
• [X] Device user
• [ ] Cloud provider
• [X] Service provider
• [X] Device manufacturer
• [ ] Gateway manufacturer
• [ ] Network operator (potentially transparent for WoT use cases)
• [ ] Identity provider
• [ ] Directory service operator
• [ ] Other (please specify)

Other Target Users

No response

Expected Devices

• Lighting
• Air Conditioner
• Security Sensor
• Smartphone

Expected Data

The operation modes of lighting, air conditioner and security sensor. Reading and updating those operation modes on demand.

Potential Adopters

TBD

Potential Applications

TBD

Expected Protocol

TBD

Existing similar WoT use case already defined?

This is a trial use case description to see the feasibility of this new use case template based on the existing use case on "Leaving and Coming Home" from the WoT Use Cases and Requirements Note.

Dependencies on WoT - Affected WoT deliverables and/or work items

• WoT Thing Description
• WoT Binding Templates
• WoT Discovery

Other WG's standards, e.g., HTML/CSS, Device APIs, DID/Verifiable Credentials, JSON-LD and RDF

TBD

Expected relationship with Existing standards by other WGs within W3C

TBD

Existing standards outside W3C

• ECHONET Lite
• [ECHONET Lite Web API Guideline](https://echonet.jp/web_api/ in Japanese )

Expected relationship with existing standards outside W3C

TBD

Security Considerations

• It is necessary to prevent unauthorized users other than the device user from using the service provided by the home management service provider.
• It is necessary to disallow home management service providers other than the home management service providers permitted by the device user in advance to control devices at the device user's home.

Privacy Considerations

It is necessary to protect the information on what operations are done on the devices that are controlled or monitored at the device user's home. It is also necessary to protect the information obtained from the devices that are controlled or monitored at the device user's home.

Accessibility Considerations

User interface provided by a smartphone had better consider accessibility.

Internationalization (i18n) Considerations

User interface provided by a smartphone had better support internationalization.

[egekorkan]

As a feedback from a reviewer perspective where I want to understand gap:

• I think that the gap is there and is not specific to one use case. Thus, it is a good idea to invest time in a feature to address this use case. There have been similar discussions in the WoT CG.
• The gap is hidden behind too much information and the information above does not motivate the gap enough. From a specification editor point of view, I want to understand the gap as quickly and as precisely as possible.
• The real gap is controlling multiple devices at the same time. This means we need TDs (or something similar) that groups multiple Thing affordances. This can be currently done with having a "virtual" TD where there are multiple affordances of other Things and with a writeallproperties operation, this orchestration can be done. This is not a very good solution though.
• It is not clear how complex the orchestration is. The description contains configuration, time aspect, branching of logic and possibly more (loops maybe?). If there is complex application logic, I am not sure how we can solve this in the spec level other than creating a new domain-specific language. I have some experience in this direction that I can share. In any case, the Scripting API is also a relevant deliverable.
• Given there is mention of ECHONET and it is not clear how to use WoT with ECHONET, that is also a gap. Plugfest experience demonstrated some experience but our specs do not document this. We need either a binding, profile or guidelines on this in a WG document.

[ashimura]

Thanks for your comments, @egekorkan !

As mentioned within the "Existing similar WoT use case already defined?" section (and partly within the title having "[TEST]", this use case entry is copied from the existing use case from the UCR Note.

However, I think your points are very important for our discussion on the new Use Case Template itself (and how to put the information into it), and would suggest we continue the discussion by creating separate Issues for the Use Case Template :)

[chachamimm]

@egekorkan, your comments are important.

@ashimura, your comments are great. I agree.

@egekorkan, could you please create new issues for Use Case Template issues.

[egekorkan]

Thanks for the comments @ashimura and @chachamimm . I am aware that this is already submitted. What I wanted to do with my initial comment was to do a test run of how a review can happen.

I am not sure if there is a problem with the template or simply with the content provided but I would personally not approve this use case submission since I do not have enough information to proceed with standardisation activities. Maybe we need more subsections in the gap section? I will open an issue about that.