AP breakouts Montreal F2F 2016

Topics

Resource Patterns:

• Property
  • e.g. Measured Temperature, Color state
  • - suggestion: GET / PUT a resource
• Collection
  • e.g. a group of properties, config values, GPIO pins, etc.
  • - suggestion: resource pattern like e.g. core interfaces collections
• Action
  • e.g. dimming of a light, brewing coffee, runing a dishwasher program
  • POST to an action resource
  • - suggestion: for long running actions: sub-resource for execution tracking (GET/PUT/DELETE)
• Event
  • e.g. doorbell, current power cosumption, it starts to rain
  • - suggestion: resource that updates the state and keeps at least the last knwon state
• Subscription
  • e.g. subscribe to an event, the update of a value or the execution of an action
  • - suggestion: resources to manage subscriptions, e.g. like [RestHooks](http://resthooks.org/docs/)
• Binding
  • e.g. on/off property of lightswitch and lightbulb, temperature of sensor and input of HVAC
  • - suggestion: "bind" or "connect" to interactions together on the thing level, protocol binding specifies how to synchronize the state

Abstract Messages / Schema of the thing-models:

• Actions: calling, state
• Lifetime: registering
• Event Notifications
• Subscribing
• Binding a resource to another resource
• Metadata as opposed to payload data model

Scripting APIs:

• Consuming Things
  • Factories:
    • Discovery
    • Thing description
    • Proxying another thing
    • Local
  • Interaction
    • subscribing
    • calling actions
    • read/write properties

• Exposing things
  • Factories:
    • Thing description
    • Programmatically creating a thing
    • Proxying another thing
  • Interaction
    • event handling
    • spontaneous

Error conditions:

• abstract list of error conditions
  • can be mapped to protocols
  • can be used by APIs
• integrity constraints
  • what expectations can we put on the interactions/messages

Architecture Model:

• Dataflow of Plugfest demos as a base for the required messages (e.g. event description level)
• Deployment views

Minutes

AP & DI:

Deployment scenarios:

• A) Single-Thing WoT Server on device directly controlled by WoT client in local network
• B) in addition to (A), also discovery and control from remote (through internet)
• C) Home hub is a servient that is a local proxy of electronic devices, and is accessed like A/B. Discovery between hub and devices is local.
• D1) Shadow is a servient acting as a remote proxy (e.g. on the cloud), discovery of shadow is remote
• D2) Both shadow and hub to enable local discovery for the hub and remote access and discovery via the shadow
• D3) industry case: local servients abstract industrial protocols, accessed or proxied by local clients.
• D4) Car gateway providing WoT server inteface to car-specific interfaces, accessed remotely
• E) Servient-to-Servient interaction, client/server roles for interaction determined by appliation. Variation of scenarios A-D.

Findings/Questions:

• need a building block: how to create and sync virtual instances / shadows of a thing?
• need to investigate how these servients find each other

Interactions for discovery:

• local
  • be discoverable
  • discover
• remote
  • be discoverable
  • discover

API primitives:

discovering is covered by current practises Registering/Advertising need to be specified

Factory functions for thing object:

AIs

• Structure for scenarios out of the Contributions of Fujitsu and DI
• API primitives for the "Registering/Advertising" part of the discovery
• Define Lifecycle for Proxies / virtual shadows
• Possible Plugfest proposal: have an example script using client/physical API, check interoperability