DEV Community: antigones

Matter protocol on a budget

antigones — Sat, 11 Jan 2025 14:17:54 +0000

A Thread border router is not mandatory to interact with Matter devices

Matter is a “super-standard” for IoT device interoperability: it promotes cooperation between smart things manufacturers and allows to control objects from the local network. It is relatively new, as its first specification version just came out in 2022.
Even if the ability to get devices into market requires an attestation from Matter consortium, it is possible to study how Matter works at a relatively cheap cost.

Matter works over IP-based technologies like Wi-Fi (“Matter-over-WiFi”) and Thread (“Matter-over-Thread”). While the first is generally used for the communication with devices transferring large amount of data (e.g. cameras), the latter is suitable for low-power devices requiring to transfer small amount of data (e.g. sensors or lights).
Matter-over-Thread guarantees communications among a variety of devices and networks and to do so it requires two special “components”: a Thread border Router and a Radio Controller. The Thread Border Router handles communications among different kind of networks (eg. Wi-Fi, Ethernet and Thread) while the Radio Controller handles communication among devices.

How does Matter work

Adding a device to a network with Matter is super-easy: just scan its QR code and that’s it, the device is ready and configured. But what’s in that QR code?
The QR code contains a lot of informations used to integrate the device into the domestic network such as the version of Matter standard, PIN and passkey to authenticate the device in the configuration phase, informations about the device and its vendor - namely the Vendor ID (VID) and Product ID (PID) – and security certifications of conformity to the CSA standard.
In order to produce Matter devices, manufacturers must register to the Connectivity Standard Alliance (CSA), which manages the Matter protocol. It’s CSA to assign the VID to uniquely identify each manufacturer and then each manufacturer uniquely assign PID to its own devices (and so, the union of VID and PID uniquely identify the device). This ensures interoperability and guarantees that a device is coming from a verified manufacturer and that it respects the Matter standard.
When the user scans the QR code (e.g. in the Google Home application on the phone), a pairing is initiated using PIN and informations stored in the QR code itself and the authentication certifies that the device is legitimate. The app also connects the device to the Wi-Fi network or the Thread network and when the pairing is completed, the device is part of the network, being accessible from all the other compatible devices and controllers.
CSA also gives a generic VID for test and development purposes only so that developers can test Matter devices without a formal certification at no cost (and of course, that generic VID cannot be used for commercial products!)

Adding a device to the network: the commissioning

The process of registering and adding a Matter device to a network is called commissioning.
When the user wants to add a new device to network, the Google Home app (or another app capable to add Matter compatible devices) will act as commissioner. It will ask the user to scan the QR code (or to enter a PIN) printed on the device: at this point, the device is temporarily connected to the commissioner, cryptographic keys are exchanged to secure operational connection, informations to join the network are received and and the device is officially part of the network.

Removing a device from the network: the decommissioning

Conversely, the process of removing a Matter device from the network is called decommissioning: it can be requested with an app (e.g. Google Home App) or from the device itself (e.g. pressing a button).
When the device is decommissioned, cryptographic keys are invalidated and the device is reset. At this point the device cannot communicate anymore with the other devices in the network.

A low cost “hands-on” experiment with ESP32

One way to play with Matter on a board without having to buy or configure a Thread border router is using an ESP32: Arduino core for ESP32 in fact gives us the capability to use Arduino IDE and the Arduino framework to deploy a Matter-enabled board.

After installing ESP32 support in ArduinoIDE, just compile and upload the following example to the board (it has been readapted from example script in Arduino-esp32 repository from Espressif):

In the snippet of code, the class of the device configures all the callable methods for the object and callbacks it responds to. In this case, since the board acts as a switch light:

MatterOnOffLight OnOffLight;
…
OnOffLight.toggle();
OnOffLight.onChange(setLightOnOff);

Also note:

OnOffLight.updateAccessory();

This directive ensures that the current state of the light (e.g., whether it is ON or OFF) is correctly reflected on the device and on the controller. This could be useful if, for example, the user presses a button to toggle the light state: updateAccessory() would reflect that change in the Google Home App. Conversely, if the user toggle the light from the application, updateAccessory() would update device state accordingly.

If you want to upload the snippet to ESP32, make sure to set the partition scheme to “Minimal SPIFFS”, to gain some space for the code.

Now it's time to add the device to the local network by choosing to add a "Matter enabled device":

and to enter the pin to begin the commissioning process (the pin is written in the serial output by the sketch, you can also scan the QR code at given the url):

Once the process ends (you should receive a message about the board not being certified but in this case is related to the fact that is just a development device) the board joined network!

In the following video you can see the results of the experiment: the board is controlled from the Google Home mobile application. On the converse, a button on the board also acts as a "switch" lighting or shutting off the led and the status on the mobile app gets updated using Matter protocol.

Pumpkins in the Cloud: control your Jack-o-Lantern with Azure IoTHub!

antigones — Mon, 30 Dec 2024 17:15:06 +0000

With Halloween approaching, I had some fun 3D-printing my own pumpkin to put on display at night (see cover image!).

The pumpkin itself was very nice, so I bought some IR remote controlled led tealights to give it the glow for some additional spooky amusement.

The original idea was to just use a tealight led to light up without messing around with circuitry but I ended up putting it in the Cloud using Azure IoTHub.

Tools

IR remote controlled tea light led
IR receiver
IR emitter (AZDelivery KY-005)
Esp8266
Jumper cables

Understanding how to control the candle with IR

In order to control the tealight led, we have to know the command to send and we have to know, in fact, which commands the remote is sending to light and shut off the candle.

For this step an Esp8266 would do the trick: it ensures compatibility with Arduino-IRRemote, a library to interact with IR emitter and receivers.

The following circuit connects an IR receiver to the board and allows to read IR data from pin D5:

The following snippet of code decodes IR commands and prints them on the serial monitor:

When pressing “on” and “off” buttons on the remote control, the library prints all the data received, along with the code to use to send the same command from an IR emitter:

21:32:55.011 -> received
21:32:55.011 -> FE01FF00
21:32:55.011 -> Protocol=NEC Address=0x0 Command=0x1 Raw-Data=0xFE01FF00 32 bits LSB first
21:32:55.142 -> Send with: IrSender.sendNEC(0x0, 0x1, <numberOfRepeats>);
21:32:55.174 -> received
21:32:55.208 -> 0
21:32:55.208 -> Protocol=NEC Address=0x0 Command=0x1 Repeat gap=39700us
21:32:55.274 -> received
21:32:55.274 -> 0
21:32:55.274 -> Protocol=NEC Address=0x0 Command=0x1 Repeat gap=96600us
21:33:01.148 -> received
21:33:01.148 -> FF00FF00
21:33:01.148 -> Protocol=NEC Address=0x0 Command=0x0 Raw-Data=0xFF00FF00 32 bits LSB first
21:33:01.246 -> Send with: IrSender.sendNEC(0x0, 0x0, <numberOfRepeats>);
21:33:01.609 -> received
21:33:01.609 -> 0
21:33:01.609 -> Protocol=UNKNOWN Hash=0x0 1 bits (incl. gap and start) received

In this case, we have to use the statement:

IrSender.sendNEC(0x0, 0x1, <numberOfRepeats>);

to light the candle and the statement:

IrSender.sendNEC(0x0, 0x0, <numberOfRepeats>);

to turn it off.

This part of the circuit can be unwired now (since it’s not going to be useful anymore) and we will integrate those commands in a script to control it through the microcontroller first and the from Cloud.

Controlling the candle, programmatically

It’s now time to setup the circuit to emit an IR signal: as per the following schema, the data will be sent controlling D6 pin.

To test the circuit, we can use serial communication to control the led emitter with a simple command interpreter:

Putting the pumpkin in the Cloud

To put the pumpkin in the Cloud we can use Azure IoTHub.

Azure IoT Hub is a managed cloud service allowing bidirectional communication: cloud to device and device to cloud.

Just to play, we can add a free-tier level service IoTHub service and then add a device:

Here I added a device called “esp8266” and so I obtained a key to establish a bidirectional cloud-device communication.

After configuring our IoTHub resources, we must take note of the following parameters (e.g. from Azure Portal):

Wi-Fi connection parameters are also required.

To send message to the Cloud we can adapt the following example sketch: https://github.com/Azure/azure-sdk-for-c-arduino/blob/main/examples/Azure_IoT_Hub_ESP8266/Azure_IoT_Hub_ESP8266.ino

We can prepare a command interpreter:

Then we can adapt the callback for received messages:

At this point we can use Azure Portal IoTHub interface to communicate with the device:

Going quantum: using Grover’s algorithm to generate worlds

antigones — Sat, 06 Apr 2024 09:53:00 +0000

Image credits

Formalizing the algorithm to generate worlds from a set of rules as a SAT problem opens the solution to a “quantum twist”

As seen in the previous article, it is possible to express the problem of generating worlds from a set of rules as a boolean SAT problem.

Grover’s algorithm can be used to solve such problems in the quantum computing domain (https://qiskit-community.github.io/qiskit-algorithms/tutorials/06_grover.html). Starting from a set of equiprobable states (Hadamard), Grover’s algorithm is a process capable of “making good states emerge” among all the others.

Let’s try to generate a 1x2 map starting from the following constraints, expressed as propositional formulae:

{
  C_00: S_10 & ~C_10 & ~L_10, # C00 iif S_10 and not C_10 and not L_10
  C_10: L_00 & ~C_00 & ~S_00,
  L_00: ~S_10 & (C_10 | L_10),
  L_10: L_00 & ~C_00 & ~S_00,
  S_00: S_10 & ~C_10 & ~L_10,
  S_10: ~L_00 & (C_00 | S_00)
  (C_00 | L_00 | S_00), # you have to choose at least a value
  (C_10 | L_10 | S_10)
}

We first need to express those constraints in Conjunctive Normal Form (CNF) and we can use sympy to obtain it:

from sympy.logic.boolalg import to_cnf
   c = to_cnf(model_ruleset)
   print(c)

The formula expressed as CNF is the following:

(L_00 | ~C_10) & (L_00 | ~L_10) & (S_10 | ~C_00) & (S_10 | ~S_00) & 
(C_00 | L_00 | S_00) & (C_10 | L_10 | S_10) & (~C_00 | ~C_10) & 
(~C_00 | ~L_10) & (~C_10 | ~S_00) & (~L_00 | ~S_10) & (~L_10 | ~S_00) & 
(C_00 | S_00 | ~S_10) & (C_10 | L_10 | ~L_00) & 
(L_00 | S_10 | ~C_00) & (L_00 | S_10 | ~C_10) & 
(L_00 | S_10 | ~L_10) & (L_00 | S_10 | ~S_00) & 
(C_00 | C_10 | L_10 | ~S_10) & (C_00 | C_10 | S_00 | ~L_00) & 
(C_00 | L_10 | S_00 | ~L_00) & (C_10 | L_10 | S_00 | ~S_10)

Let’s also remap variables with the following equivalence in order to use them with Qiskit:

a = L_00
b = L_10
c = C_00
d = C_10
e = S_00
f = S_10

Now it’s time to use Grover:

from qiskit import MissingOptionalLibraryError
from qiskit.tools.visualization import plot_histogram
from qiskit.primitives import Sampler
from qiskit.algorithms import Grover
from qiskit.circuit.library import PhaseOracle
from qiskit.algorithms import AmplificationProblem

expression = '(a | ~d) & (a | ~b) & (f | ~c) & (f | ~e) & (c | a | e) & (d | b | f) & (~c | ~d) & (~c | ~b) & (~d | ~e) & (~a | ~f) & (~b | ~e) & (c | e | ~f) & (d | b | ~a) & (a | f | ~c) & (a | f | ~d) & (a | f | ~b) & (a | f | ~e) & (c | d | b | ~f) & (c | d | e | ~a) & (c | b | e | ~a) & (d | b | e | ~f)'
try:
    oracle = PhaseOracle(expression)
    problem = AmplificationProblem(oracle, is_good_state=oracle.evaluate_bitstring)
    grover = Grover(sampler=Sampler())
    result = grover.amplify(problem)
    print(result)
    display(plot_histogram(result.circuit_results[0]))
except MissingOptionalLibraryError as ex:
    print(ex)

In this script, PhaseOracle constructs a quantum circuit which is equivalent to the logical expression in input.

AmplificationProblem builds a problem which is suitable to be elaborated by Grover’s algorithm and specifies a function to evaluate if a state is good.

The script plots the following histogram:

The states seem to be mapped in the order they are encountered in the CNF:

adbfce
000111
111000

Even if the histogram isn’t so much clear, printing the quasi-probabilities as a dictionary shows that the two states with maximum quasi-probability are:

S_10, C_00, S_00 (000111)
L_00, C_10, L_10 (111000)

Which are equivalent to the following rows in the truth table we previously found for this little 1x2 world:

C_00,L_00,S_00,C_10,L_10,S_10
[False, True, False, True, True, False]
[True, False, True, False, False, True]

Trying to bridge the gap between WFC “Even Simpler Tiled Model” and Constraint Satisfaction Problem (CSP) propositional rules

antigones — Fri, 15 Sep 2023 23:15:59 +0000

(Photo by Ross Sneddon on Unsplash)

Recently I tried to implement my own version of "Even Simpler Tiled Model" - a simplified version of Wave Function Collapse algorithm (source: https://github.com/antigones/py-wfc-estm) as explained in this page.

"Even Simpler Tiled Model", just like Wave Function Collapse, can be for example used to generate maps out of a set of rules. The idea is that it is possible to formalize those rules from a sample map and then use them to generate a new one, "propagating" reasoning about admissible/unadmissible values from tile to tile.

Playing with my own implementation, a question arose: what defines a rule making a map difficult to collapse, when applying the Wave Function Collapse algorithm in its “Even Simpler Tiled Model” (ESTM) simplified form?
Trying to answer this question, I ended up fallbacking the model to a propositional logic rules-related question and trying to formalize "Even Simpler Tiled Model" as a set of propositional logic rules.
I took a sample map, defined as follows:

img = [
          'LLLLLLLLLL',
          'LLLLLLLLLL',
          'LLLLLLLLLL',
          'LLLLLLLLLL',
          'LLLLLCLLCC',
          'LLLLCSCCSS',
          'LLLCSSSSSS',
          'LLCSSSSSSS',
          'LCSSSSSSSS',
          'CSSSSSSSSS'
      ]

Analyzing the sample map, the following rules came out:

{
    'L': {
        (1, 0): {'L', 'C'}, 
        (0, 1): {'L', 'C'}, 
        (0, -1): {'L', 'C'}, 
        (-1, 0): {'L'}
    }, 

    'C': {
        (-1, 0): {'L'}, 
        (0, -1): {'S', 'L', 'C'}, 
        (1, 0): {'S'}, 
        (0, 1): {'S', 'L', 'C'}
    }, 

    'S': {
         (-1, 0): {'S', 'C'}, 
         (0, -1): {'S', 'C'}, 
         (1, 0): {'S'}, 
         (0, 1): {'S', 'C'}}
     }
}

The rules informally state the following (see map at the beginning of this post):

a Land can have a Land at North, East, South, West; Coast in the East, West, South
Sea can have Coast or Sea in the North, Sea in the South, Coast or Sea at East and West
Coast must have Land in the North; can have Land or Coast and East and West; must have Sea at south

Let’s rewrite this set of rules as a set of logic propositions.
To accomplish this task and to be sure not to forget a rule, I wrote my own model checker using SymPy.

An 1x2 sized world

Since we have to rewrite the rules for each and every cell in the map, we first consider a 1x2 sized world.
In this world, we define:

L_00, “there is a land in (0,0)”
C_00, “there is a coast in (0,0)”
S_00, “there is sea in (0,0)”

L_10, “there is a land in (1,0)”
C_10, “there is a coast in (1,0)”
S_10, “there is a sea in (1,0)”

And the rules as:

{
    C_00: S_10 & ~C_10 & ~L_10, 
    C_10: L_00 & ~C_00 & ~S_00, 

    L_00: ~S_10 & (C_10 | L_10), # a Land in (0,0) only admit a C or a L in (1,0), does not admit Sea
    L_10: L_00 & ~C_00 & ~S_00, 

    S_00: S_10 & ~C_10 & ~L_10, 
    S_10: ~L_00 & (C_00 | S_00)

    (C_00 | L_00 | S_00), # you have to choose at least a value
    (C_10 | L_10 | S_10)
}

(where ":" stands for "if and only if")

To have a “valid” world map (i.e. a map respecting all the defined rules) we can only choose a set of truth values assignment satisfying all the rules (a model).
The model checker prints all the assignments satisfying all the rules.

For this small world, we have the two following models:

Reading the first row in the truth table, we can see that choosing Land in (0,0) pushes a Coast or a Land in (1,0). This gives us two perfectly valid maps in just one row:

L
C

L
L

Reading the second row in the truth table, we can see that choosing a Sea or a Coast in (0,0) only pushes a Sea in (1,0):

CS
S

leading to the two (both valid) maps:

C
S

and

S
S

A 2x2 map

We can extend reasoning for maps of size beyond 1x2. Let’s consider a 2x2 world map.
We can again write the propositional ruleset:

{
    C_00: S_10 & ~C_10 & ~L_10 & (C_01 | L_01 | S_01), 
    C_01: S_11 & ~C_11 & ~L_11 & (C_00 | L_00 | S_00), 
    C_10: L_00 & ~C_00 & ~S_00 & (C_11 | L_11 | S_11), 
    C_11: L_01 & ~C_01 & ~S_01 & (C_10 | L_10 | S_10), 

    L_00: ~S_01 & ~S_10 & (C_01 | L_01) & (C_10 | L_10), 
    L_01: ~S_00 & ~S_11 & (C_00 | L_00) & (C_11 | L_11), 
    L_10: L_00 & ~C_00 & ~S_00 & ~S_11 & (C_11 | L_11), 
    L_11: L_01 & ~C_01 & ~S_01 & ~S_10 & (C_10 | L_10), 

    S_00: S_10 & ~C_10 & ~L_01 & ~L_10 & (C_01 | S_01), 
    S_01: S_11 & ~C_11 & ~L_00 & ~L_11 & (C_00 | S_00), 
    S_10: ~L_00 & ~L_11 & (C_00 | S_00) & (C_11 | S_11), 
    S_11: ~L_01 & ~L_10 & (C_01 | S_01) & (C_10 | S_10),

    (C_00 | L_00 | S_00),
    (C_01 | L_01 | S_01),
    (C_10 | L_10 | S_10),
    (C_11 | L_11 | S_11)
}

and use the model-checker to determine models:

We have four models here.
Let's choose S in (1,1) - filtering all the models having S_11 to True:

The truth table suggests the following situation:

Let's choose L in (0,0):

The truth table evolves the map to the following one:

which is valid.

If we take a step back and choose S in (0,0) then we have:

which leads to the following (equivalent) set of maps:

which can be "unraveled" as the following four maps:

Going up, 3x3 maps

Using the model checker to generate/check rules for a 3x3 map, we obtain the following models:

Let's choose L for (2,2), to observe propagation as rule inference:

Leading to the map:

which shows propagation of Land values across the tiles!

Let's choose L in (2,0) - and note that it is interchangeable with a Coast:

This gives two valid maps, where there is no difference in putting a Land or a Coast in (2,1):

A “very difficult” map

Let’s stress things and consider the following sample map:

img_hard = [
               'KB',
               'SB',
           ]

and again, let’s write out the rules as logic proposition:

{
    B_00: B_10 & ~B_01 & ~K_01 & ~K_10 & ~S_01 & ~S_10, 
    B_01: B_11 & ~B_00 & ~K_11 & ~S_11 & (K_00 | S_00), 
    B_10: B_00 & ~B_11 & ~K_00 & ~K_11 & ~S_00 & ~S_11, 
    B_11: B_01 & ~B_10 & ~K_01 & ~S_01 & (K_10 | S_10), 

    K_00: B_01 & S_10 & ~B_10 & ~K_01 & ~K_10 & ~S_01, 
    K_01: S_11 & ~B_00 & ~B_11 & ~K_00 & ~K_11 & ~S_00, 
    K_10: B_11 & ~B_00 & ~K_00 & ~K_11 & ~S_00 & ~S_11, 
    K_11: ~B_01 & ~B_10 & ~K_01 & ~K_10 & ~S_01 & ~S_10, 

    S_00: B_01 & ~B_10 & ~K_01 & ~K_10 & ~S_01 & ~S_10, 
    S_01: ~B_00 & ~B_11 & ~K_00 & ~K_11 & ~S_00 & ~S_11, 
    S_10: B_11 & K_00 & ~B_00 & ~K_11 & ~S_00 & ~S_11, 
    S_11: K_01 & ~B_01 & ~B_10 & ~K_10 & ~S_01 & ~S_10,

    (B_00 | K_00 | S_00),
    (B_01 | K_01 | S_01),
    (B_10 | K_10 | S_10),
    (B_11 | K_11 | S_11)    
}

The model checker only returns 1 model:

the only admissible solution.

For a 3x3 map with the "hard" rules, we obtain UNSAT and the map cannot collapse.