Request a temperature resource across a constrained mesh

Steps

Screens captured against Contiki-NG Cooja Contiki-NG release/v4.9 c20b12cd, Cooja 4.8 (2022071901), Temurin 17.0.20.1, image sha256:b14d5afb0a2a852d9e72bbed607ead03f6ccc5f4b609 on 2026-10-08; the tool may have moved on — the text steps are the contract.

1. 1 Step 1

   Do

   Open the CSC in Cooja. In the Network panel, identify server 1, relay 2, and client 3. In the Mote output panel, filter CLIENT|SERVER|RELAY and wait for the client route.

   You will see

   Server 1 starts /temperature at 21.5; relay 2 reports reachable=1 at 20.765 s. Client 3 reports root reachable via relay at 35.642 s. The motes sit at x=0,25,50 m with a 40 m radio range.

   Why it matters

   The client is 50 m from the server, so the relay is required for this path. These are positions and protocol output from a simulated radio run.

2. 2 Step 2

   Do

   In the Mote output panel, find CLIENT CON GET and the next SERVER GET and CLIENT response rows. Read the URI-Path and the response value.

   You will see

   35.642 s: CON GET serialized_len=16, hex=40010000bb74656d7065726174757265. 35.717 s: SERVER GET /temperature -> 2.05 Content 21.5. 35.758 s: CLIENT response phase=1 type=2 code=69 payload=21.5.

   Why it matters

   The Contiki-NG serializer produced these CoAP bytes before the send API set the final Message ID. Response code 69 is 2.05 Content; type 2 is ACK.

3. 3 Step 3

   Do

   In the Mote output panel, read the CON PUT bytes, server change, and client response. Compare the new value with the first GET.

   You will see

   35.758 s: CON PUT serialized_len=21, hex=40030000bb74656d7065726174757265ff32322e30. 35.808 s: SERVER PUT /temperature -> 2.04 Changed 22.0. 35.881 s: CLIENT response phase=2 type=2 code=68.

   Why it matters

   The ff payload marker precedes ASCII 22.0 in Contiki-NG serialization. Code 68 means 2.04 Changed, proving the server accepted the write.

4. 4 Step 4

   Do

   In the Mote output panel, find the baseline NON GET and the following server receipt. Compare its first byte and token with the CON GET.

   You will see

   35.881 s: NON GET serialized_len=18, hex=520100004333bb74656d7065726174757265. 35.900 s: SERVER GET /temperature -> 2.05 Content 22.0. No client callback row followed this baseline NON request in this run.

   Why it matters

   The 52 header identifies a NON request with a 2-byte token; the server did receive it. Server receipt and client callback are distinct observations.

5. 5 Step 5

   Do

   Read the ScriptRunner fault line and Network panel after relay 2 moves away. Find the client CON GET sent during the outage.

   You will see

   43.549 s: FAULT relay 2 moved to (300,300). 45.882 s: CLIENT LOSS CON GET /temperature serialized_len=16. The captured Network pane shows only server 1 and client 3 within view.

   Why it matters

   The client has no direct 40 m link to the server while the relay is away. A request log alone does not prove delivery or a response.

6. 6 Step 6

   Do

   Let the CSC finish and in the Mote output panel inspect the restored CON exchange and final NON attempt. Check ScriptRunner panel for TEST OK and compare server receipts after each request.

   You will see

   48.549 s: relay 2 restored to (25,0). 50.380 s: SERVER GET /temperature -> 2.05 Content 22.0. 50.399 s: CLIENT response phase=4 type=2 code=69 payload=22.0. 50.399 s: relay moved away before final NON GET; no later SERVER GET by 60.400 s.

   Why it matters

   The CON request at 45.882 s received a reply 4.517 s later, after the outage. The final NON has no server receipt in this bounded run; this is a measured outcome, not a universal guarantee.