<namespace>/...: This is usually referred to as the prefix or the base URI. Drivers will be written to publish/consume data on URIs that are relative to the prefix, which simplifies deployment.
<service name>: By convention, these start with
s.venstarfor the Venstar-brand thermostat). A service is a name for a particular grouping of interfaces (see below), and typically represents an instance of a driver. A driver may expose more than one service, and a service may be composed of multiple drivers (rare).
<instance name>: A driver or service may expose several instances of an interface. In the case where there is only one instance of an interface for a service, the instance is conventionally denoted as the underscore character (
_). Otherwise, the instances are conventionally given some human-readable name that helps differentiate them. For example, a thermostat service that exposes multiple thermostats might name instances by which room the thermostats are in (note: this kind of naming should not be considered in place of proper metadata)
<interface name>: By convention, these start with
i.xbos.thermostatfor the standard XBOS thermostat interface). Interfaces encapsulate a set of signals and slots (see below). Interfaces are well-defined, and a standard set of XBOS interfaces exist here.
signal: is a keyword in the URI that indicates that the name specified afterwards is an output of the driver
slot: is a keyword in the URI that indicates that the name specified afterwards is an input to the driver
<signal, slot name>: this is the name of the signal or slot. These are defined by the corresponding interface.
C*in the context of BOSSWAVE permissions.
<namespace>/.../<service name>/<instance name>/*:
<namespace>/.../<service name>/<instance name>/<interface name>/*:
<namespace>/.../<service name>/<instance name>/<interface name>/signal/<signal name>:
<namespace>/.../<service name>/<instance name>/<interface name>/slot/<slot name>:
<namespace>/.../<service name>/+/<interface name>/signal/+:
info) that publishes all state for an instance of the device. We do not divide this data up in any way because thermostat data generally requires the context of the whole device's state to make sense of the data.
setpoints, which only grants control over the thermostat's heating and cooling setpoints, and
state, which grants control for all available device state. This division exists because being able to change the thermostat's heating/cooling/off mode and override and fan states constitute a much larger degree of control than changing the setpoint parameters to the control loop. We could imagine granting access to the setpoints to more people, and leave access to the full device state for building administrators.