Github Documentation

• https://github.com/rdkcentral/BartonCore/tree/main/docs

What Barton offers

1. BartonCore produces a resource sensitive C/C++ based library that represents a local IoT device management and access service
2. A client of the library would typically expose the provided functionality to a local or cloud based service or user interface.
3. These clients interface with the supported devices through a resource model that abstracts the underlying protocols and transports

• Device control 
• Management with Formal API's
  • Standard IoT technology support
    • Zigbee
    • Matter
    • standard device interaction model for devices of the same class
    • device pairing and configuration
    • device communication health monitoring
    • OTA firmware upgrade management for devices

• The library provides device facilities for

  • discovery
  • pairing (including secure credentialling)
  • configuration
  • firmware management
  • control
  • eventing

• Included protocols and transports:

  • Matter
  • Zigbee
  • Thread

Block diagram

What is actually Barton Device service do

• Device Service is responsible for the management and interactions with all devices
• Devices can connect with various protocols and technologies including Zigbee, Matter, and OpenHome.
• Devices belong to a Device Class which defines the type of device. Some examples of Device Classes are Camera, Light, Door Lock, and Sensor (and many others).
• Each Device Class supports one or more endpoints
• Devices are exposed to clients as a set of resources that can be read, written
• Device Service can function without any hardware dependencies

What is not there in Barton

• Local automations
• Alarms
• Security
• Cloud connectivity
• Standard TR-181 Datamodels
• Standard HAL as per RDK-B specification

Supported OS runtime

• Linux

How does client interact

• Interaction to device service is through GObject API
• What do clients do
  • clients kicking off pairing/commissioning devices or interacting with already paired devices
  • These requests will usually percolate to technology-specific device drivers that may leverage subsystems for physical device interaction
  • In the case of Zigbee and Matter, these drivers may utilize standard cluster implementations
    • Zigbee core
    • Matter SDK
• Devices are stored in an internal device database
• Device Service device model is an attempt to standard device interaction for clients by abstracting out technology-specific concepts.
  • Endpoints -  Re-usable logical functionality. An example of this might be a light endpoint that could exists on a light bulb device, or a different IoT device that also has lights on it.
  • Resources - these are readable and/or writable attributes
  • Metadata - Basic device info (vendor, product, versions) / Detailed endpoint configuration with endpointId, deviceTypes, servers, clients, and parts 

• • • Sample device Model

      • deviceService> dump /2a63de336194874e deviceClass=light deviceClassVersion=3 managingDeviceDriver=matterLight resources: /2a63de336194874e/r/manufacturer value=TP-Link ownerId=2a63de336194874e type=com.icontrol.string mode=0x1 (r------) /2a63de336194874e/r/model value=Mini Smart Wi-Fi Plug ownerId=2a63de336194874e type=com.icontrol.string mode=0x21 (r---e--) /2a63de336194874e/r/hardwareVersion value=1 ownerId=2a63de336194874e type=com.icontrol.version mode=0x1 (r------) /2a63de336194874e/r/firmwareVersion value=0x00000001 ownerId=2a63de336194874e type=com.icontrol.version mode=0x39 (r--de--) /2a63de336194874e/r/firmwareUpdateStatus value=(null) ownerId=2a63de336194874e type=com.icontrol.firmwareVersionStatus mode=0x39 (r--de--) /2a63de336194874e/r/dateAdded value=1744644845171 ownerId=2a63de336194874e type=com.icontrol.dateTime mode=0x1 (r------) /2a63de336194874e/r/dateLastContacted value=1744664466026 ownerId=2a63de336194874e type=com.icontrol.dateTime mode=0x59 (r--d-l-) /2a63de336194874e/r/communicationFailure value=false ownerId=2a63de336194874e type=com.icontrol.trouble mode=0x39 (r--de--) /2a63de336194874e/r/resetToFactoryDefaults value=(null) ownerId=2a63de336194874e type=com.icontrol.resetToFactoryOperation mode=0x4 (--x----) /2a63de336194874e/r/serialNumber value=(null) ownerId=2a63de336194874e type=com.icontrol.serialNumber mode=0x1 (r------) /2a63de336194874e/r/firmwareVersionString value=1.0.0 Build 220930 Rel.143947 ownerId=2a63de336194874e type=com.icontrol.string mode=0x39 (r--de--) /2a63de336194874e/r/macAddress value=30de4bdb8034 ownerId=2a63de336194874e type=com.icontrol.macAddress mode=0x1 (r------) /2a63de336194874e/r/networkType value=wifi ownerId=2a63de336194874e type=com.icontrol.networkType mode=0x1 (r------) endpoints: /2a63de336194874e/ep/1 profile=light profileVersion=0 ownerId=2a63de336194874e resources: /2a63de336194874e/ep/1/r/label value=Matter Light ownerId=2a63de336194874e type=com.icontrol.label mode=0x3b (rw-de--) /2a63de336194874e/ep/1/r/isOn value=true ownerId=2a63de336194874e type=com.icontrol.boolean mode=0x7b (rw-del-) metadata: { "vendor": "TP-Link", "product": "Mini Smart Wi-Fi Plug", "hwVer": "1", "swVer": "0x00000001", "swStr": "1.0.0 Build 220930 Rel.143947", "serialNumber": null, "macAddress": "30de4bdb8034", "networkType": "wifi", "endpoints": [{ "endpointId": 0, "deviceTypes": [{ "type": 22 }], "servers": [29, 31, 40, 42, 48, 49, 51, 60, 62, 63], "clients": [41], "parts": [1] }, { "endpointId": 1, "deviceTypes": [{ "type": 266 }], "servers": [3, 4, 5, 6, 29], "clients": [], "parts": [] }] } /fdddc46b3881fe3c deviceClass=light deviceClassVersion=3 managingDeviceDriver=matterLight resources: /fdddc46b3881fe3c/r/manufacturer value=Onvis ownerId=fdddc46b3881fe3c type=com.icontrol.string mode=0x1 (r------) /fdddc46b3881fe3c/r/model value=S4 ownerId=fdddc46b3881fe3c type=com.icontrol.string mode=0x21 (r---e--) /fdddc46b3881fe3c/r/hardwareVersion value=1 ownerId=fdddc46b3881fe3c type=com.icontrol.version mode=0x1 (r------) /fdddc46b3881fe3c/r/firmwareVersion value=0x0098bd9b ownerId=fdddc46b3881fe3c type=com.icontrol.version mode=0x39 (r--de--) /fdddc46b3881fe3c/r/firmwareUpdateStatus value=failed ownerId=fdddc46b3881fe3c type=com.icontrol.firmwareVersionStatus mode=0x39 (r--de--) /fdddc46b3881fe3c/r/dateAdded value=1744663050010 ownerId=fdddc46b3881fe3c type=com.icontrol.dateTime mode=0x1 (r------) /fdddc46b3881fe3c/r/dateLastContacted value=1744664452372 ownerId=fdddc46b3881fe3c type=com.icontrol.dateTime mode=0x59 (r--d-l-) /fdddc46b3881fe3c/r/communicationFailure value=false ownerId=fdddc46b3881fe3c type=com.icontrol.trouble mode=0x39 (r--de--) /fdddc46b3881fe3c/r/resetToFactoryDefaults value=(null) ownerId=fdddc46b3881fe3c type=com.icontrol.resetToFactoryOperation mode=0x4 (--x----) /fdddc46b3881fe3c/r/serialNumber value=70016cdbb45b44b3839f9c06aaad5b65 ownerId=fdddc46b3881fe3c type=com.icontrol.serialNumber mode=0x1 (r------) /fdddc46b3881fe3c/r/firmwareVersionString value=1.1.11-c85ba1e-dirty ownerId=fdddc46b3881fe3c type=com.icontrol.string mode=0x39 (r--de--) /fdddc46b3881fe3c/r/macAddress value=000000000000 ownerId=fdddc46b3881fe3c type=com.icontrol.macAddress mode=0x1 (r------) /fdddc46b3881fe3c/r/networkType value=thread ownerId=fdddc46b3881fe3c type=com.icontrol.networkType mode=0x1 (r------) endpoints: /fdddc46b3881fe3c/ep/1 profile=light profileVersion=0 ownerId=fdddc46b3881fe3c resources: /fdddc46b3881fe3c/ep/1/r/label value=Matter Light ownerId=fdddc46b3881fe3c type=com.icontrol.label mode=0x3b (rw-de--) /fdddc46b3881fe3c/ep/1/r/isOn value=true ownerId=fdddc46b3881fe3c type=com.icontrol.boolean mode=0x7b (rw-del-) metadata: { "vendor": "Onvis", "product": "S4", "hwVer": "1", "swVer": "0x0098bd9b", "swStr": "1.1.11-c85ba1e-dirty", "serialNumber": "70016cdbb45b44b3839f9c06aaad5b65", "macAddress": "000000000000", "networkType": "thread", "endpoints": [{ "endpointId": 0, "deviceTypes": [{ "type": 22 }], "servers": [29, 31, 40, 48, 49, 51, 60, 62, 63, 53, 42], "clients": [41], "parts": [1] }, { "endpointId": 1, "deviceTypes": [{ "type": 266 }], "servers": [29, 3, 4, 5, 6], "clients": [], "parts": [] }] } deviceService>

Pairing & commissioning

• A client may tell Device Service to open for pairing Zigbee devices or to commission a Matter device
• It is redirected by the core of Device Service through a standard flow
• Initially, device service has subsystems locate the device and onboard it to its network
• From there, Device services passes responsibility to the correct device driver for the device, which will establish an initial device model for it
• Then, the driver is instructed to configure the device

Device drivers

• technology-specific plugins for operating with different device types
  • For example, Device Service comes with a Zigbee light device driver, as well as a Matter light device driver. Drivers are in charge of configuring and interacting with a known device
• Clients of Device Service may register their own device drivers
• Device Drivers are bits of code responsible for the mapping of resources to functionality on a device. The current set of drivers available in Barton are
  • MatterDoorLock
  • MatterLight
  • MatterWindowCovering
  • philipsHue
  • zigbeeDoorLock
  • zigbeeLight
  • zigbeeLightController
  • zigbeePresence
  • zigbeeSensor
  • zigbeeThermostat
  • zigbeeWindowCovering

subsystems

• Subsystems in Device Service provide safe/secure access to lower level parts of the stack to be used by device drivers. Currently Barton has a subsystem for Zigbee, Matter, and Thread

Matter

• Device Service currently requires clients to supply their own Matter SDK library implementation for Matter support
• Matter has no hardware requirements for basic functionality since it is an IPv6 based specification
• It can make use of BLE for commissioning of new devices

Thread

• If Thread support is enabled, Barton will attempt to communicate with the otbr-agent over dbus
  • D-Bus Communication
    • Barton connects to the otbr-agent service through D-Bus
    • D-Bus provides an interprocess communication mechanism that allows Barton to:
      • Query Border Router status
      • Retrieve Thread network credentials
      • Control Border Router operations
  • Thread Network Credentials
    • Barton retrieves Thread network credentials from the Border Router
    • These credentials are used when commissioning Matter over Thread devices
    • This is how devices like your Onvis S4 (shown in your file) can join the Thread network
  • Integration Requirements
    • For complete functionality, both Thread and Border Router support need to be enabled in the Matter SDK if Matter is also enabled
    • This ensures proper communication between all components in the ecosystem

BLE

• Device Service is built with BLE support, Matter devices may be commissioned directly by Device Service for Thread or Wi-Fi Operational Network access. Device Service, the Matter stack actually, expects a Bluez API over dbus

Zigbee(Roadmap)

• For Zigbee support, Device Service requires a separate runtime program that implements an abstraction library called zhal. Currently Barton provides a program called ZigbeeCore which implements zhal for Silicon Labs efr32 devices
• If Device Service is built with Zigbee support there should be an implementation of ZHAL, which is the Zigbee Hardware Abstraction Layer. The intent of ZHAL is to enable portability to different Zigbee stack and silicon vendors
  • Fimware Management
    • when a new firmware image is available for a device, the Device Descriptor List (aka whitelist/allowlist) is updated with the new firmware version number and filename
    • When this updated list is published and provided to Barton it is scanned for descriptors matching paired devices
    • If a paired device needs an upgrade its file is downloaded from the content server.

Device communication watchdog

• Device Service has a component that is responsible for detecting communication failure with the devices it manages
• Once the Device Communication Watchdog determines that a device is in communication failure, the device's communicationFailure resource (/000d6f000f486af8/r/communicationFailure from the example device earlier) is set to "true"
• This triggers a resource changed event

Database

• Device Service stores all of its configuration in individual files

Barton Reference App

• The Barton Reference App provides a CLI for interactively interfacing with Barton Device Service.

  • Interacting with Barton from your Code

    • Setup and Initialization

      • Include device-service-client.h
      • Create initialization parameters with b_device_service_initialize_params_container_new
      • Configure storage location with b_device_service_initialize_params_container_set_storage_dir
      • For Matter support, provide additional configuration:
        • b_device_service_initialize_params_container_set_matter_storage_dir
        • b_device_service_initialize_params_container_set_matter_attestation_trust_store_dir
        • b_device_service_initialize_params_container_set_network_credentials_provider

    • Client Creation and Startup

      • Create the client instance with b_device_service_client_new
      • Initialize the connection with b_device_service_client_start

    • Event Registration

      • Connect to system events using g_signal_connect
      • Common signals include:
        • Discovery events (DISCOVERY_STARTED, DISCOVERY_STOPPED)
        • Device lifecycle events (DEVICE_DISCOVERED, DEVICE_ADDED)
        • Endpoint events (ENDPOINT_ADDED)
        • Status events (DEVICE_DISCOVERY_COMPLETED, DEVICE_DISCOVERY_FAILED)

    • Device Interaction

      • Commission new devices with b_device_service_client_commission_device
      • Control devices by writing to resources with b_device_service_client_write_resource
      • Read device state with b_device_service_client_get_resource_by_uri
      • Execute device functions with b_device_service_client_execute_resource