A full list of resource type specifications like the ones mentioned below can be found in the Nexus Channel Core Resource Type Registry.
Nexus Channel Core allows devices to share arbitrary data (read/write) with other devices by exposing that data as a set of 'resources'. For example, a Solar Home System (SHS) might host a battery 'resource' to expose information about its primary battery capacity and health. That same system might also host an energy generation 'resource', exposing how it is powered (solar, AC, etc), instantaneous power being generated, and cumulative energy generated by the source over time. Any devices that are able to communicate to the SHS (over any data communication link) have visibility into the current state of the SHS (as exposed via its hosted 'resources') as well as (optionally) update certain parameters of those resources (like low battery trigger level).
The above example relies on instances of well-defined "Resource Types" implemented on a device. These "Resource Types" are how devices implementing Nexus Channel Core are able to monitor and control each other without custom application logic for each new device. Independent of how a device developer implements the 'battery' resource, for instance, the same values are present (capacity, voltage, etc) and are accessed using the same property names and data types. In this way, devices only need to know what standard resource types other devices have implemented, then refer to the publicly available specifications for those resource types to determine how to read or modify the state of another device.
Nexus Channel Core operates at the application layer, and sends data payloads over existing communication channels between devices. This enables reuse of the same resource models and high-level application interfaces between devices, regardless of whether devices are connected using 2.4G links, LIN, 802.15.4, or a yet-to-be-developed networking standard.
Nexus Channel Core is a subset of the Open Connectivity Foundation (OCF) Specification, an industry and ISO/IEC standard (30118-1:2018). OCF specifies a way to define resource models in a non-proprietary, highly-interoperable format. It uses the following standards to model resource types:
-
OCF Resource Type Specification - Independent of any implementation details or code, every Nexus Channel Core resource type is fully defined by an OpenAPI spec file that is compliant with the OCF Resource Type specification. This ensures that every property exposed by the resource is specified with a sufficient level of detail (type, name, valid range, purpose) to enable developers to implement that resource type on a device, while also clarifying how to interact with other devices which implement the same resource.
-
RFC 7252 Constrained Application Protocol (CoAP) - The OCF Core specification explains how to transmit data between devices using CoAP protocol and simple verbs. Nexus Channel Core selects a subset of CoAP options and configurations which simplify use on resource-limited devices, and enable faster 'time to implementation' for device development teams.
-
RFC 7049 Concise Binary Object Representation (CBOR) - When interacting with a resource hosted on another device, the resource properties are represented using CBOR. When modelling a new resource type, the properties are annotated with their corresponding CBOR data types. Nexus Channel Core provides further restrictions beyond the OCF specification to simplify CBOR parsing and reduce data footprint for use on Class 0 embedded devices.
To see exactly what subset of CoAP, CBOR, and OCF that Nexus Channel Core supports, please see the following specifications:
To submit a new resource type for inclusion and receive a resource type registry value, please follow the instructions in the "Nexus Channel Core CBOR/Resource Type Creation Spec".
Autogeneration of sample source code (in C) from YAML resource type definitions
may be possible in the future, and the x-example fields included in resource
type YAML specifications are meant to support this future possibility.
An SHS might provide an energy consumption resource, exposing the total power draw of its loads, as well as how that power is split across different loads. If the SHS is able to log or report data, it might store this information in a sample log resource, allowing other application logic to make decisions based on stored load data.
Or, consider the case of a solar home system with expansion battery packs. Each of the battery packs might expose resources sharing its own battery state, while also allowing another 'authorized' device to modify parameters like minimum safe battery capacity in a standard way.
An appliance (like a freezer) might expose a demand response resource, enabling coordinated energy management with an 'energy management' device (like the SHS above) by enabling the concept of 'requested' and 'granted' power consumption amounts via resource properties. A freezer might lower its requested power at night (when the temperature is lower), allowing the system controller to 'free up' more energy for lighting or entertainment uses in the evening.
Perhaps one device in the same home has a rich UI (such as a TV), which the client wishes to use to control other devices in the household (change the brightness of their indoor lighting or change the temperature setpoint of their freezer, for instance). This can be accomplished by implementing a operating mode resource on each device to be controlled, enabling the user to modify each device's operating mode accordingly, and allowing manufacturers to specify custom operating modes based on their products specific needs.
The above examples barely scratch the surface of what is possible. Product designers can take advantage of new resource models as they are published, exposing capabilities historically limited to costly 'smart home' or industrially deployed devices. By enabling intelligent interoperability between devices at the application layer, Nexus Channel Core resource models allow developers to rapidly build reusable, advanced system designs that can be applied to multiple product lines and future revisions, completely independent of wiring or communication protocol changes over time.
If you're interested in submitting a new resource model (resource type), a good place to start
are issues tagged with resource model wanted
in the public nexus-channel-models Github repository.
A compliant reference implementation is available in the nexus-embedded
repository.