A prototype application that demonstrates dynamic endpoint with device commissioning and cluster control. It adds the non-chip device as endpoints on a bridge(Matter device). In this example four light devices supporting on-off cluster and temperature sensor have been added as endpoints
The Bridge Example makes use of Dynamic Endpoints. Current SDK support is limited for dynamic endpoints, since endpoints are typically defined (along with the clusters and attributes they contain) in a .zap file which then generates code and static structures to define the endpoints.
To support endpoints that are not statically defined, the ZCL attribute storage mechanisms will hold additional endpoint information for NUM_DYNAMIC_ENDPOINTS
additional endpoints. These additional endpoint structures must be defined by the application and can change at runtime.
To facilitate the creation of these endpoint structures, several macros are defined:
DECLARE_DYNAMIC_ATTRIBUTE_LIST_BEGIN(attrListName)
DECLARE_DYNAMIC_ATTRIBUTE(attId, attType, attSizeBytes, attrMask)
DECLARE_DYNAMIC_ATTRIBUTE_LIST_END(clusterRevision)
These three macros are used to declare a list of attributes for use within a cluster. The declaration must begin with the DECLARE_DYNAMIC_ATTRIBUTE_LIST_BEGIN
macro which will define the name of the allocated attribute structure. Each attribute is then added by the DECLARE_DYNAMIC_ATTRIBUTE
macro. Finally, DECLARE_DYNAMIC_ATTRIBUTE_LIST_END
macro should be used to close the definition.
All attributes defined with these macros will be configured as ATTRIBUTE_MASK_EXTERNAL_STORAGE
in the ZCL database and therefore will rely on the application to maintain storage for the attribute. Consequently, reads or writes to these attributes must be handled within the application by the emberAfExternalAttributeWriteCallback
and emberAfExternalAttributeReadCallback
functions. See the bridge application's main.cpp
for an example of this implementation.
DECLARE_DYNAMIC_CLUSTER_LIST_BEGIN(clusterListName)
DECLARE_DYNAMIC_CLUSTER(clusterId, clusterAttrs, incomingCommands, outgoingCommands)
DECLARE_DYNAMIC_CLUSTER_LIST_END
DECLARE_DYNAMIC_CLUSTER_LIST_BEGIN
macro which will define the name of the allocated cluster structure. Each cluster is then added by the DECLARE_DYNAMIC_CLUSTER
macro referencing attribute list previously defined by the DECLARE_DYNAMIC_ATTRIBUTE...
macros and the lists of incoming/outgoing commands terminated by kInvalidCommandId (or nullptr if there aren't any commands in the list). Finally, DECLARE_DYNAMIC_CLUSTER_LIST_END
macro should be used to close the definition.DECLARE_DYNAMIC_ENDPOINT(endpointName, clusterList)
DECLARE_DYNAMIC_CLUSTER...
macros.Run the Docker container:
$ docker run -it --rm -v $PWD:/host -w /host ghcr.io/project-chip/chip-build-telink:$(wget -q -O - https://raw.githubusercontent.com/project-chip/connectedhomeip/master/.github/workflows/examples-telink.yaml 2> /dev/null | grep chip-build-telink | awk -F: '{print $NF}')
Compatible docker image version can be found in next file:
$ .github/workflows/examples-telink.yaml
Activate the build environment:
$ source ./scripts/activate.sh
In the example dir run (replace <build_target> with your board name, for example, tlsr9518adk80d
or tlsr9528a
):
$ west build -b <build_target>
Flash binary:
$ west flash --erase
To get output from device, connect UART to following pins:
Name | Pin |
---|---|
RX | PB3 (pin 17 of J34 connector) |
TX | PB2 (pin 16 of J34 connector) |
GND | GND |
The following buttons are available on tlsr9518adk80d board:
Name | Function | Description |
---|---|---|
Button 1 | Factory reset | Perform factory reset to forget currently commissioned Thread network and back to uncommissioned state |
Button 2 | Lighting control | Manually triggers the lighting state |
Button 3 | Thread start | Commission thread with static credentials and enables the Thread on device |
Button 4 | Open commission window | The button is opening commissioning window to perform commissioning over BLE |
Red LED indicates current state of Thread network. It is able to be in following states:
State | Description |
---|---|
Blinks with short pulses | Device is not commissioned to Thread, Thread is disabled |
Blinks with frequent pulses | Device is commissioned, Thread enabled. Device trying to JOIN thread network |
Blinks with wide pulses | Device commissioned and joined to thread network as CHILD |
Green LED used to identify the device. The LED starts blinking when the Identify command of the Identify cluster is received. The command's argument can be used to specify the the effect. It is able to be in following effects:
Effect | Description |
---|---|
Blinks (200 ms on/200 ms off) | Blink (Clusters::Identify::EffectIdentifierEnum::kBlink ) |
Breathe (during 1000 ms) | Breathe (Clusters::Identify::EffectIdentifierEnum::kBreathe ) |
Blinks (50 ms on/950 ms off) | Okay (Clusters::Identify::EffectIdentifierEnum::kOkay ) |
Blinks (1000 ms on/1000 ms off) | Channel Change ( Clusters::Identify::EffectIdentifierEnum::kChannelChange ) |
Blinks (950 ms on/50 ms off) | Finish ( Clusters::Identify::EffectIdentifierEnum::kFinishEffect ) |
LED off | Stop (Clusters::Identify::EffectIdentifierEnum::kStopEffect ) |
Build chip-tool cli
Pair with device
${CHIP_TOOL_DIR}/chip-tool pairing ble-thread ${NODE_ID} hex:${DATASET} ${PIN_CODE} ${DISCRIMINATOR}
Example:
./chip-tool pairing ble-thread 1234 hex:0e080000000000010000000300000f35060004001fffe0020811111111222222220708fd61f77bd3df233e051000112233445566778899aabbccddeeff030e4f70656e54687265616444656d6f010212340410445f2b5ca6f2a93a55ce570a70efeecb0c0402a0fff8 20202021 3840
Switch on the light:
${CHIP_TOOL_DIR}/chip-tool onoff on 1 2
here:
Switch off the light:
${CHIP_TOOL_DIR}/chip-tool onoff off 1 2
here:
Read the light state:
${CHIP_TOOL_DIR}/chip-tool onoff read on-off 1 2
here:
Change brightness of light:
${CHIP_TOOL_DIR}/chip-tool levelcontrol move-to-level 32 0 0 0 1 2
here:
Read brightness level:
./chip-tool levelcontrol read current-level 1 2
here:
OTA feature enabled by default only for ota-requestor-app example. To enable OTA feature for another Telink example:
After build application with enabled OTA feature, use next binary files:
All binaries has the same SW version. To test OTA “zephyr-ota.bin” should have higher SW version than base SW. Set CONFIG_CHIP_DEVICE_SOFTWARE_VERSION=2 in corresponding “prj.conf” configuration file.
Usage of OTA:
Build the Linux OTA Provider
./scripts/examples/gn_build_example.sh examples/ota-provider-app/linux out/ota-provider-app chip_config_network_layer_ble=false
Run the Linux OTA Provider with OTA image.
./chip-ota-provider-app -f zephyr-ota.bin
Provision the Linux OTA Provider using chip-tool
./chip-tool pairing onnetwork ${OTA_PROVIDER_NODE_ID} 20202021
here:
Configure the ACL of the ota-provider-app to allow access
./chip-tool accesscontrol write acl '[{"fabricIndex": 1, "privilege": 5, "authMode": 2, "subjects": [112233], "targets": null}, {"fabricIndex": 1, "privilege": 3, "authMode": 2, "subjects": null, "targets": null}]' ${OTA_PROVIDER_NODE_ID} 0
here:
Use the chip-tool to announce the ota-provider-app to start the OTA process
./chip-tool otasoftwareupdaterequestor announce-otaprovider ${OTA_PROVIDER_NODE_ID} 0 0 0 ${DEVICE_NODE_ID} 0
here:
Once the transfer is complete, OTA requestor sends ApplyUpdateRequest command to OTA provider for applying the image. Device will restart on successful application of OTA image.