The Thread networking protocol is gaining traction as a backbone for smart home devices and wireless sensor networks. This project demonstrates how a variety of wireless MCUs from different vendors can be configured to communicate not only with each other, but with Home Assistant running on a host connected to an external network. Each vendor takes a slightly different approach to implementing the OpenThread protocol stack on their devices. Once set up, however, the devices are able to establish, join, and organize themselves into a functioning mesh network, hereafter referred to as the demo network.
Background
Before delving into the application-layer protocol chosen for this demo network and the devices chosen to implement it, this section provides a high-level overview of the relevant background concepts.
Thread is a mesh networking protocol in the same family as Zigbee, Z-Wave, and BLE Mesh, all of which boast several advantageous properties including security, scalability, and low-power consumption. However, Thread offers additional advantages through its native IP-based networking model and robust, self-healing mesh architecture with no single point of failure. Of course, these protocols all share certain disadvantages including limited range and lower data rates. Thread, in particular, is generally considered more difficult to implement on embedded hardware. Luckily, most developers use the OpenThread implementation of the Thread protocol, and ongoing open-source contributions continue to broaden platform support and make it easier to deploy.
A Thread network is composed of nodes which play one of two fundamental roles: Router or End Device. Routers form the basis of the mesh network by establishing multiple simultaneous connections to nearby devices and forwarding data packets toward their destination. End Devices, on the other hand, do not participate in packet routing and instead connect only to a single parent Router. Nodes can be further classified into one of two device types: Full Thread Devices or Minimal Thread Devices. In short, Full Thread Devices (FTDs) are those which maintain full network awareness and keep an up-to-date routing table, though they may act as either Routers or End Devices. Minimal Thread Devices (MTDs) do not maintain complete routing information and, thus, may only act as End Devices. More will be said about FTDs and MTDs in the coming sections.
Like most networks, Thread is modeled on the Internet Protocol suite and follows a layered architecture based on link, network, transport, and application layers. At the bottom of the stack is the link layer, for which Thread uses the IEEE 802.15.4 radio standard (the same as Zigbee) to operate in the license-free 2.4 GHz frequency band. Built on this is the network layer, where an IPv6-based mesh networking protocol is defined using 6LoWPAN as a bridge between this and the link layer. Next, at the transport layer, UDP messaging is used for mesh establishment and maintenance. The only layer not defined by the Thread specification is the application layer at the top of the stack. Here, developers must either create their own solution or select from one or more existing options like CoAP, MQTT-SN, Matter, etc.
The devices in our demo network employ CoAP (Constrained Application Protocol) at the application layer. CoAP is very similar to HTTP in that it is a RESTful web transfer protocol which identifies resources using URIs and operates in a client/server architecture. The client sends requests to the server using one of the GET, POST, PUT, or DELETE methods, and the server sends a response in return. Request messages themselves may be designated as either confirmable or non-confirmable to ensure reliable payload delivery for transactions that require it.
Many Thread devices on the market today, especially smart home devices, implement Matter at the application layer, often described as “Matter over Thread”. However, a considerable number of currently available wireless MCUs which support Thread do not support Matter. This is primarily attributable to Matter’s sizable memory footprint and implementation overhead, which can exceed the limits of most entry-level devices. By contrast, CoAP is supported by virtually all Thread-enabled hardware as it requires far less memory to implement and is even included with the OpenThread stack. Most MCU vendors (including those featured in our demo network) provide ready-to-use example projects utilizing CoAP at the application layer as well.
Because Thread is IPv6-based, Thread devices can communicate natively with any other IP-based device or service, including IoT platforms such as Home Assistant. Home Assistant is an open-source home automation platform which runs on local hardware and acts as a central hub for monitoring and/or controlling connected devices. While incredibly capable out-of-the-box, Home Assistant offers nearly endless potential for extension and customization. We take advantage of this flexibility to integrate support for the CoAP-based Thread devices which make up our demo network.
Application Overview
This demo showcases a simple Thread network composed of several wireless MCU development boards from various manufacturers. Aside from the target MCU, each of these boards is populated with at least one environmental sensor, an RGB LED, and expansion headers for adding more functionality. As mentioned in the previous section, each of these Thread devices employs CoAP at the application layer to communicate with an IoT backend running on a separate host system. In this case, said backend service is Home Assistant running on a Raspberry Pi. Users are able to not only visualize the aggregated sensor data on a Home Assistant dashboard, but also control the various output devices associated with each Thread node.
The behavior of each participant in the network is summarized below in Figure 1. Notice that each entity is capable of acting as either a CoAP client or a CoAP server depending on whether it is sending or receiving a request. To avoid over-complicating the example, only PUT requests are used to exchange information between endpoints.
Acting as CoAP clients, Thread devices send periodic PUT requests to the Home Assistant CoAP server to update the exposed /data resource with the latest sensor readings. Similarly, Home Assistant acts as a CoAP client by sending PUT requests to the appropriate Thread device’s CoAP server when a user interacts with the control interface. Different resources are exposed by the Thread devices depending on what features they support (e.g., /led, /fan, etc.).
The payloads of these CoAP requests adhere to different formats depending on which device and resource they are addressed to. In this application, all payloads arriving at Home Assistant’s /data resource must be formatted as JSON strings and include an id member which is unique to the originating device. Any additional members of the JSON structure are used to indicate which sensor values should be updated. An example payload from a Thread device to Home Assistant may look like {"id":"123a","t":"72.08","h":"48.33"}, where the t member denotes the temperature and h denotes the relative humidity. These additional parameters are optional and any that are not included in the payload will simply not be updated in Home Assistant’s database.
Each Thread device must be registered with Home Assistant ahead of time so its device ID can be recognized and other data members properly interpreted. Registering a device also involves specifying which CoAP resources are exposed by its CoAP server implementation and how any payload delivered to them is formatted. For instance, two devices may both make the /led resource available to control the state of their onboard LEDs, but one device may expect a simple payload for basic control (1 for “on” or 0 for “off”) while the other expects a more sophisticated payload to control multiple parameters (e.g., {"state":"on","brightness":25,"color":"FF2100"}).
Finally, notice that both non-confirmable (NON) and confirmable (CON) message types are used for sending PUT requests between nodes on the network. Thread devices sending telemetry to Home Assistant employ the non-confirmable type to operate more efficiently. That is, by not taking additional steps to verify the successful delivery of messages to the server, the devices require less memory to operate and can potentially spend more time in low-power mode. The impact on the system is minimal should the server miss an occasional packet of telemetry data.
On the other hand, Thread devices should acknowledge the receipt of any request from Home Assistant since they are triggered by intentional user actions. By sending confirmable messages, Home Assistant’s CoAP client waits for an acknowledgment from the receiving Thread device and repeatedly retransmits the request if none is received. Doing so helps the system recover from transient network errors while remaining responsive to the user.
Full Thread Devices
FTDs actively participate in the formation and management of the Thread mesh network by maintaining a full routing table, subscribing to the all-routers multicast address, and always having their radios enabled. Naturally, any system implementing this Thread device type must have sufficient resources (i.e., computational capability, memory availability, and a sustained source of power) to support these additional requirements. Typically, FTDs act as either Routers or Router Eligible End Devices (REEDs) depending on the needs of the network, though they may also be configured to act as Full End Devices (FEDs) for specific use cases.
All of the development boards functioning within this demo network operate as FTDs and, for the sake of simplicity, are pre-commissioned using hardcoded credentials. The firmware for each board was developed by adapting existing reference projects provided by their respective manufacturers. These projects all include a port of the OpenThread stack for the target platform and a CoAP-based application layer. The remainder of this section provides greater detail about the boards themselves, which components are used to provide telemetry to Home Assistant, and which output devices can be controlled by Home Assistant.
FRDM-RW612
Leading the discussion is the device which plays a crucial role in our demo network: that of a Border Router. Border Routers provide bidirectional IPv6 connectivity between nodes in a Thread network and hosts on external IP-based networks (typically Ethernet or Wi-Fi). They are not required for the formation of the Thread network itself, but at least one is needed if any Thread device must communicate with some non-Thread device. This is exactly the case with our demo Thread network in which devices communicate with Home Assistant hosted on a Raspberry Pi.
Any FTD implemented on suitable hardware can provide Border Router services to the Thread network. For this project, NXP’s FRDM-RW612 development board is employed for this purpose. It features the RW612 wireless MCU, which is lauded for its powerful computation capabilities, rich peripheral set, strong security compliance, and integrated tri-radio. It’s an excellent choice for single-chip Border Router solutions which, compared to more common (Linux + RCP)-based solutions, can reduce the cost, size, and power consumption of the final product.
Board Highlights
- Target MCU: the RW612
- A flashless MCU with a 260 MHz Arm Cortex-M33 core and 1.2 MB SRAM.
- Tri-radio subsystem: Wi-Fi 6 (2.4 GHz / 5 GHz) + Bluetooth LE + 802.15.4 (Thread / Zigbee)
- External QSPI memories: 512 Mbit flash and 64 Mbit SRAM
- Ethernet PHY and RJ45 connector
- NXP’s P3T1755 I3C/I2C temperature sensor
- An RGB LED
- Both Arduino and MikroE expansion headers
As part of a hands-on product training, NXP has provided an example implementation of a Thread Border Router using the FRDM-RW612 board. This teaching example enables Border Router services on the RW612 and exposes the OpenThread CLI as a means of configuring/managing the device. However, the application as provided requires that the CLI be used every time the board is reset to bring up the IPv6 interface, start the Thread service, start the CoAP server, and connect to a Wi-Fi network. While certainly useful for learning purposes, this is far removed from how deployed Thread devices are expected to operate.
To adapt NXP’s reference application to our more realistic network example, several changes were made to the source code and project configuration. At the outset, alternative build options were used to enable Ethernet as the external interface of the Border Router rather than Wi-Fi. Moreover, the OpenThread API was used to initialize the Thread device directly rather than rely on the CLI. This includes enabling the Thread and CoAP services in addition to establishing a Thread network connection based on hardcoded credentials. Now, without the need for manual configuration, connecting the FRDM-RW612 and Raspberry Pi to the same Ethernet network allows any device on the Thread network to send messages to Home Assistant (and vice versa).
Aside from providing Border Router services to the network, the FRDM-RW612 board otherwise behaves as a conventional FTD. The source code was further modified to periodically obtain samples from the onboard temperature sensor and send them to Home Assistant via a CoAP PUT request as described in the Application Overview section. The payload structure employed by the device when acting as a CoAP client is shown below in Listing 1.
Listing 1: The format of the payload sent by the FRDM-RW612 board to Home Assistant when acting as a CoAP client
{
"id": "281e", // required, unique device ID
"amb": { // optional, ambient sensor data object
"t": 21836 // optional, temperature data (mC)
}
}
The device’s CoAP server capabilities were expanded as well. To take greater advantage of the board’s RGB LED, the final code changes allow the exposed /led resource to interpret payloads containing a simple enumerated state/color code as defined by Table 1.
Table 1: The resources exposed by the FRDM-RW612 board’s CoAP server implementation and the payloads they accept
| Resource | Payload | State |
|---|---|---|
/led |
0 | LED Off |
| 1 | LED Red | |
| 2 | LED Yellow | |
| 3 | LED Green | |
| 4 | LED Cyan | |
| 5 | LED Blue | |
| 6 | LED Violet | |
| 7 | LED White |
FRDM-MCXW71
Another board from NXP, the FRDM-MCXW71 is a prototyping platform for the MCX W71 wireless MCU which supports Bluetooth Low Energy, Zigbee, and Thread. Whereas the FRDM-RW612 from the previous section is an excellent starting point for network bridging devices with higher resource requirements, the FRDM-MCXW71 is better suited for more constrained connected devices where security remains a priority. Examples of such devices may include sensor nodes, access control systems, metering devices, and power management solutions. The extended temperature range of the MCX W71 (-40 to 125 °C) along with its CAN FD interface make it a good fit for industrial applications as well.
Board Highlights
- The target MCU: the MCX W71
- Powered by an Arm Cortex-M33 with a max frequency of 96 MHz, 1 MB Flash, 128 KB SRAM
- An independent radio subsystem with dedicated core (CM3 @ 64 MHz) and memory (256 kB Flash and 88 KB SRAM)
- External 64 Mbit QSPI Flash
- A high-speed CAN transceiver accessible through a 2x2-pin header
- Two onboard sensors
- Accelerometer: ST’s FXLS8964AF 12-bit, 3-axis digital accelerometer
- Ambient light sensor: Everlight’s ALS-PT19-315C/L177/TR8 phototransistor which produces an output current proportional to light intensity
- An RGB LED
- Both Arduino and MikroE expansion headers
NXP’s previously mentioned hands-on product training also provides an FTD implementation for the FRDM-MCXW71 development board which requires manual configuration through the OpenThread CLI. Just like with the compatible reference application for the FRDM-RW612, the initialization procedure was modified to enable all necessary services and establish a connection to the Thread network using hardcoded credentials. A routine was also added to periodically acquire data from the selected sensors and report it to Home Assistant by issuing a CoAP PUT request.
In addition to the onboard ambient light sensor, measurements are also obtained from the HVAC Click board installed in the mikroBUS expansion socket. This particular Click board features the SCD41 CO2 sensor from Sensirion, allowing ambient CO2 concentration, temperature, and relative humidity to be obtained. Note that the onboard accelerometer sensor is not utilized in this project as the board is intended to remain stationary. The data that is collected is formatted into a JSON string following the template shown in Listing 2.
Listing 2: The format of the payload sent by the FRDM-MCXW71 board to Home Assistant when acting as a CoAP client
{
"id": "c261", // required, unique device ID
"amb": { // optional, ambient sensor data object
"i": 12, // optional, light level (arbitrary unit)
"co2": 812, // optional, CO2 concentration (ppm)
"t": 22059, // optional, temperature data (mC)
"h": 44530 // optional, relative humidity (m%RH)
}
}
Unfortunately, the RGB LED was placed between the mikroBUS headers on the FRDM-MCXW71 board, meaning any Click board inserted into the socket obstructs it from view. Therefore, NXP’s reference code pertaining to the CoAP server behavior was left unchanged. The exposed /led resource accepts either of the two payloads described in Table 2 to simply turn the LED on or off.
Table 2: The resources exposed by the FRDM-MCXW71 board’s CoAP server implementation and the payloads they accept
| Resource | Payload | State |
|---|---|---|
/led |
0 | LED Off |
| 1 | LED On |
STM32WB5MM-DK
STMicroelectronics has several offerings for developing IEEE 802.15.4-based solutions, and the STM32WB5MM-DK is one of them. It is a feature-packed board including an impressive array of sensors and output devices supporting a broad range of applications. The hero of the board is the unassuming STM32WB5MMG module, which integrates the STM32WB MCU, RF frontend, and antenna into a small 7.3 x 11 mm package.
Board Highlights
- The target MCU: the STM32WB5MMG module (based on STM32WB55VGY)
- Dual-core Arm Cortex-M4 (64 MHz) and Arm Cortex-M0+ (32 MHz, for radio/security tasks)
- 1 MB Flash, 256 KB SRAM
- External 128 Mbit QSPI Flash
- 0.96 inch 128x64 OLED display
- Four onboard sensors, all from ST
- Temperature sensor: STTS22H high-accuracy temperature sensor
- Accelerometer/gyroscope: The ISM330DHCX SIP features a 3-axis accelerometer, a 3-axis gyroscope, and a machine learning core
- Time-of-Flight distance sensor: The VL53L0X time-of-flight sensor uses the round-trip delay of 940 nm light to determine the range of objects up to 2 meters.
- Microphone: IMP34DT05TR digital PDM MEMS microphone
- An RGB LED
- An IR LED
- A capacitive touch button
- Arduino expansion headers
ST provides several reference applications for this MCU series as part of their STM32WBCube MCU Package, including an example demonstrating the exchange of both confirmable and non-confirmable CoAP messages between two STM32WB5MM-DK boards. Said application was straightforward to integrate into our demo network by modifying the hardcoded credentials to match those of the other devices. Building on this, the application was then extended to periodically poll the temperature sensor, time-of-flight sensor, and microphone, with the collected samples subsequently sent to Home Assistant via CoAP PUT requests. The payload structure for these requests follows that shown in Listing 3. Note that data is not acquired from the onboard accelerometer as it would not be particularly meaningful given the stationary board setup and low sampling rate.
Listing 3: The format of the payload sent by the STM32WB5MM-DK board to Home Assistant when acting as a CoAP client
{
"id": "bc58", // required, unique device ID
"amb": { // optional, ambient sensor data object
"t": 21.91, // optional, temperature (C)
"n": { // optional, noise level (arbitrary unit)
"min": 1107, // optional, minimum
"max": 3854, // optional, maximum
"avg": 2284 // optional, average
},
"d": 448 // optional, distance (mm)
}
}
Since the Thread networking protocol is not well suited to streaming audio data, a different approach is taken in reporting data from the onboard microphone. Namely, the samples from the microphone are processed to determine the ambient noise level based on the peak value of the audio waveform. This arbitrary noise level value can range from 0 (theoretical dead silence) to 32768 (the maximum magnitude representable by signed 16-bit data). To ensure short-lived audio events are captured, the microphone output is collected and processed at a higher frequency than that used for the other sensors. These higher-frequency samples are then used to compute running statistics (i.e., minimum, maximum, and average) between telemetry updates to Home Assistant. It’s these statistics which are then packaged into the CoAP request payload (Listing 3) rather than instantaneous noise level values.
Two CoAP resources are also exposed by the device as part of the CoAP server implementation, as outlined in Table 3. The /led resource accepts a JSON formatted payload which specifies whether the LED is on/off as well as its brightness and/or color. The /lcd resource accepts a payload of an ASCII string with no more than 17 characters. The received string is then displayed in the middle of the OLED display with a box drawn around the text.
Table 3: The resources exposed by the STM32WB5MM-DK board’s CoAP server implementation and the payloads they accept
| Resource | Payload | State |
|---|---|---|
/led |
{
"state": "ON",
"brightness": 55,
"color":{"r":255, "g":22, "b":196}
}
|
LED State: "ON" or "OFF" |
| LED Brightness: [0..255] | ||
| LED Color: RGB triplet in JSON notation | ||
/lcd |
"DigiKey!" | An ASCII string to be displayed on the OLED display (max 17 characters) |
WBZ451 Curiosity
The PIC32CX-BZ2 and WBZ451 Curiosity Development Board from Microchip features their WBZ451PE wireless module, which supports the Bluetooth Low Energy, Zigbee, and Thread protocols. With outline dimensions of only 77 x 30 mm, it’s the smallest board featured in this demo network. Its small size, onboard Li-Ion/LiPo battery support, and included mikroBUS Click header make it an ideal platform for prototyping IoT devices.
Board Highlights
- The target MCU: WBZ451PE RF module (based on PIC32CX-BZ2)
- Arm Cortex-M4 (64 MHz)
- 1 MB Flash, 128 KB SRAM
- External 64 Mbit QSPI Flash
- Battery header + Microchip’s MCP73871 Li-Ion/LiPo battery charger
- Microchip’s MCP9700A analog temperature sensor
- An RGB LED
- mikroBUS expansion header
Microchip offers several Thread-based examples in their wireless examples repository, including a set of CoAP applications which configure the board to act as either a CoAP client or a CoAP server. Because every node in our demo network assumes both of these roles (see the Application Overview section), a new application was created leveraging the code from both of Microchip’s example implementations. The resulting firmware establishes communication with other devices in the network using matching hardcoded credentials and periodically obtains data from the onboard temperature sensor. Acting as a CoAP client, the device sends a CoAP PUT request to Home Assistant’s /data resource adhering to the payload structure shown in Listing 4.
Listing 4: The format of the payload sent by the WBZ451 Curiosity board to Home Assistant when acting as a CoAP client
{
"id": "5f13", // required, unique device ID
"amb": { // optional, ambient sensor data object
"t": 76.09 // optional, temperature data (F)
}
}
The capabilities of Microchip’s reference CoAP server were also expanded to support control of both the onboard RGB LED and a small DC fan. As outlined in Table 4, the /led resource accepts a JSON payload to set the LED on/off status, brightness, and color. Similarly, the /fan resource expects a three-character string to control the on/off status and intensity of the DC fan (the UF3H3-700-TC from Sunon). Control of the fan is made simple courtesy of the DC Motor 25 Click add-on board based on the Allegro A3908 DC motor driver.
Table 4: The resources exposed by the WBZ451 Curiosity board’s CoAP server implementation and the payloads they accept
| Resource | Payload | State |
|---|---|---|
/led |
{
"state": "ON",
"brightness": 55,
"color":{"r":255, "g":22, "b":196}
}
|
LED State: "ON" or "OFF" |
| LED Brightness: [0..255] | ||
| LED Color: RGB triplet in JSON notation | ||
/fan |
"_ON" | Fan on |
| "OFF" | Fan off | |
| "076" | Fan power level [000..100] |
Minimal Thread Devices (Future Work)
As implied by their name, Minimal Thread Devices provide less functionality than Full Thread Devices. In particular, they do not maintain a routing table for the network and they do not subscribe to the all-routers multicast address. The only way they can participate in the network and communicate with other devices on the mesh is by taking on the End Device role and establishing a direct connection with a nearby Router.
MTDs requiring minimal latency should be configured as Minimal End Devices (MEDs) as their radios are constantly enabled and any messages sent to them will be received immediately. On the other hand, devices which can tolerate higher latency in exchange for lower energy consumption should be configured as Sleepy End Devices (SEDs). By disabling their radios when idle, SEDs can take full advantage of the low-power modes afforded by their hardware and maximize runtime when powered by a battery.
At the time of writing, our demo network does not yet include any MTDs. This is partly due to time constraints, but mainly because FTDs are both simpler to implement and are more interesting for demonstration purposes. Future work may include the addition of one or more MTDs to the network should it make sense for a particular board and/or module.
Home Assistant
One of the easiest ways to get started with Home Assistant is by installing Home Assistant OS on an SBC (e.g., a Raspberry Pi) or a virtual machine. Home Assistant OS makes it very easy to install updates and also supports apps. Because Home Assistant includes excellent support for MQTT but includes no native support for CoAP, a custom app which bridges CoAP and MQTT traffic is required to integrate Home Assistant with our demo network. Such an app is fairly simple to create by writing a basic Python script which does the following:
- Implements a CoAP server which exposes the
/dataresource. Payloads sent to this resource are forwarded to the MQTT publisher. - Implements a CoAP client which forwards MQTT data to the designated Thread device.
- Implements an MQTT subscriber which subscribes to the
ha/+/+/#topic filter. Any messages published to a topic matching this filter are forwarded to the CoAP client. - Implements an MQTT publisher which forwards CoAP data to the MQTT broker.
An example of the output logs for this app is shown below in Listing 5.
Listing 5: Example log output of the custom CoAP_MQTT_Bridge app
INFO:__main__:Received CoAP PUT request from [fdcd:4338:23b6:9c6e:5627:8dff:feda:e369] with payload b'{"id":"281e","amb":{"t":26812}}'
INFO:__main__:Sent MQTT message: ha/281e, {"amb": {"t": 26812}}
INFO:__main__:Received CoAP PUT request from [fd61:4477:10ef:1:f10a:3fe0:eda3:3405] with payload b'{"id":"bc58","amb":{"t":22.38,"n":{"min":1223,"max":3477,"avg":2180}},"d":471}'
INFO:__main__:Sent MQTT message: ha/bc58, {"amb": {"t": 22.56, "n": {"min": 1223, "max": 3477, "avg": 2180}}, "d": 424}
INFO:__main__:Received CoAP PUT request from [fd61:4477:10ef:1:766f:cd7d:9edf:3686] with payload b'{"id":"5f13","amb":{"t":81.09}}'
INFO:__main__:Sent MQTT message: ha/5f13, {"amb": {"t": 81.09}}
INFO:__main__:Received CoAP PUT request from [fd61:4477:10ef:1:cde8:1dbd:ba13:aba9] with payload b'{"id":"c261","amb":{"i":54,"co2":786,"t":22900,"h":30125}}'
INFO:__main__:Sent MQTT message: ha/c261, {"amb": {"i": 54, "co2": 786, "t": 22900, "h": 30125}}
INFO:__main__:Received MQTT message: ha/bc58/led, b'{"state":"ON","color":{"r":61,"g":43,"b":255}}'
INFO:__main__:Sent CoAP PUT request with payload b'{"state":"ON","color":{"r":61,"g":43,"b":255}}' to coap://[fd61:4477:10ef:1:f10a:3fe0:eda3:3405]/led. Response: 2.03 Valid b''
As a consequence of this CoAP-to-MQTT bridging approach, each device on the Thread network must be registered with Home Assistant as an MQTT device before it can be recognized. Given the small size of our network, the simplest means of accomplishing this is to directly edit Home Assistant’s configuration.yaml file. The details of how to do this are outside the scope of this article, but an example of adding support for the WBZ451 Curiosity board is provided in Listing 6 as a reference.
Listing 6: A snippet of the configuration.yaml file used to register the WBZ451 Curiosity board with Home Assistant
mqtt:
- sensor:
device:
identifiers:
- 5f13
name: "WBZ451 Curiosity"
manufacturer: "Microchip"
device_class: temperature
force_update: true
name: "Temperature"
qos: 0
state_class: measurement
state_topic: ha/5f13
suggested_display_precision: 1
unique_id: 5f13_amb_t
unit_of_measurement: "\xB0F"
value_template: "{{ value_json.amb.t | default('') }}"
- fan:
command_topic: ha/5f13/fan
percentage_command_topic: ha/5f13/fan
percentage_command_template: "{{ '%03d' | format(value) }}"
speed_range_min: 1
speed_range_max: 100
device:
identifiers:
- 5f13
name: "WBZ451 Curiosity"
manufacturer: "Microchip"
name: "Mighty Mini Fan"
optimistic: true
payload_off: "OFF"
payload_on: "_ON"
qos: 0
state_topic: ha/5f13
state_value_template: "{{ value_json.state.fan | default('') }}"
unique_id: 5f13_fan
- light:
device:
identifiers:
- 5f13
name: "WBZ451 Curiosity"
manufacturer: "Microchip"
brightness: true
command_topic: ha/5f13/led
name: "RGB LED"
optimistic: true
qos: 0
schema: json
supported_color_modes:
- rgb
unique_id: 5f13_led
Conclusion
Thread differentiates itself from similar mesh networking protocols by using IPv6 to enable interoperability with other IP networks while maintaining a robust, self-healing mesh with no single point of failure. Although Thread is often associated with the Matter smart home standard, the reality is that many Thread-capable wireless MCUs do not have the required memory capacity or adequate vendor support to effectively implement Matter at the application layer. Fortunately, there are several lighter-weight alternatives these devices may take advantage of, CoAP being the most popular and easiest to get started with. To demonstrate this, a simple CoAP-over-Thread network was established using a handful of development boards from several wireless MCU vendors. Each board includes a set of sensors and output devices that can be monitored and controlled through Home Assistant deployed on an adjacent network.