Skip to content

Commit 24036bf

Browse files
jasonrandrewsjasonrandrews
authored
Merge pull request #3268 from kavya-chennoju/device-connect-server-lp
Add device-connect-server learning path (draft)
2 parents 8ed25c9 + bca1abb commit 24036bf

4 files changed

Lines changed: 450 additions & 0 deletions

File tree

‎content/learning-paths/embedded-and-microcontrollers/device-connect-server/_index.md‎

Lines changed: 56 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,56 @@
1+
---
2+
title: Connect Devices and AI agents through Device Connect Server
3+
4+
draft: true
5+
cascade:
6+
draft: true
7+
8+
minutes_to_complete: 30
9+
10+
who_is_this_for: This is a follow-on topic for developers who have a working Device Connect mesh and want to add a server layer on top. The server gives you a persistent device registry, distributed state, and security primitives (commissioning, ACLs) so you can operate a multi-network fleet from one place.
11+
12+
learning_objectives:
13+
- Understand what the Device Connect server adds on top of the edge SDK and when you'd reach for it
14+
- Provision a hosted tenant on the Device Connect portal and download per-device NATS credentials
15+
- Commission two simulated devices against your tenant using the credentials the portal issues
16+
- Discover and invoke commissioned devices from a Python client using `device-connect-agent-tools`
17+
- Connect a Strands AI agent to the same tenant
18+
19+
prerequisites:
20+
- Familiarity with the Device Connect edge SDK (the [device-to-device Learning Path](/learning-paths/embedded-and-microcontrollers/device-connect-d2d/) is a good starting point)
21+
- An account on the [Device Connect portal](https://portal.deviceconnect.dev/)
22+
- Basic familiarity with Python and the command line
23+
24+
author:
25+
- Kavya Sri Chennoju
26+
- Annie Tallund
27+
28+
### Tags
29+
skilllevels: Introductory
30+
subjects: Libraries
31+
armips:
32+
- Cortex-A
33+
- Neoverse
34+
operatingsystems:
35+
- Linux
36+
- macOS
37+
tools_software_languages:
38+
- Python
39+
- Docker
40+
41+
further_reading:
42+
- resource:
43+
title: Device Connect
44+
link: https://deviceconnect.dev/
45+
type: website
46+
- resource:
47+
title: device-connect-server package
48+
link: https://github.com/arm/device-connect/tree/main/packages/device-connect-server
49+
type: documentation
50+
51+
### FIXED, DO NOT MODIFY
52+
# ================================================================================
53+
weight: 1
54+
layout: "learningpathall"
55+
learning_path_main_page: "yes"
56+
---

‎content/learning-paths/embedded-and-microcontrollers/device-connect-server/_next-steps.md‎

Lines changed: 17 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,17 @@
1+
---
2+
# ================================================================================
3+
# FIXED, DO NOT MODIFY THIS FILE
4+
# ================================================================================
5+
weight: 21
6+
title: "Next Steps"
7+
layout: "learningpathall"
8+
---
9+
10+
## Where to go next
11+
12+
From this baseline you can extend the deployment in a few directions:
13+
14+
- swap Zenoh dev mode for [Zenoh with TLS](https://github.com/arm/device-connect/tree/main/packages/device-connect-server#secure--zenoh-tls) using the `generate_tls_certs.sh` script in `security_infra/`
15+
- swap to a NATS backend with [JWT authentication](https://github.com/arm/device-connect/tree/main/packages/device-connect-server#authenticated--nats-jwt-auth) for per-device credentials
16+
- explore the [multi-tenant deployment](https://github.com/arm/device-connect/tree/main/packages/device-connect-server#multi-tenant-deployment) flow when several teams or workshops share the same infrastructure
17+
- replace the simulated number-generator with a real sensor or robot driver using the same `DeviceDriver` pattern from the edge SDK

‎content/learning-paths/embedded-and-microcontrollers/device-connect-server/background.md‎

Lines changed: 89 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,89 @@
1+
---
2+
title: Why add a Device Connect server
3+
weight: 2
4+
5+
# FIXED, DO NOT MODIFY
6+
layout: learningpathall
7+
---
8+
9+
## From device-to-device (D2D) to server
10+
11+
The [device-to-device Learning Path](/learning-paths/embedded-and-microcontrollers/device-connect-d2d/) showed Device Connect in its simplest shape. Each runtime is a peer on the same local network. Devices find each other automatically, exchange typed events, and call each other's remote procedure calls (RPCs) directly. There is no broker, registry, or cloud service to run.
12+
13+
That model is useful when everything is close together. It works well for prototypes, lab demos, and small fleets on one local area network (LAN). It is also a good fit when a cloud round-trip would add unnecessary delay.
14+
15+
As soon as the fleet grows, D2D mode starts to run out of road. You may need devices on different networks to talk to each other. You may need a registry that remembers devices after they disconnect. You may also need stronger identity, credential rotation, or audit logs.
16+
17+
Use a Device Connect server when you need:
18+
19+
- a **persistent registry** that survives device reboots and lets new clients list known devices
20+
- **distributed state** shared between devices and agents, with leases and watches
21+
- **multi-network reach** for devices and agents on different LANs, behind network address translation (NAT), or in the cloud
22+
- **fleet-wide operations** such as commissioning devices and rotating credentials
23+
- **stronger security controls** such as per-device identity, JSON Web Token (JWT) credentials, role-based access control lists (ACLs), and audit logs
24+
25+
The [`device-connect-server`](https://github.com/arm/device-connect/tree/main/packages/device-connect-server) package is the layer that adds those capabilities on top of the edge software development kit (SDK) you already know.
26+
27+
## What the server adds
28+
29+
The server does not change how you write device code. Devices still use `DeviceDriver`, `@rpc`, `@emit`, `@periodic`, and `@on`. Clients and artificial intelligence (AI) agents still use `discover_devices()` and `invoke_device()`.
30+
31+
The server changes how devices find and trust each other. In D2D mode, each runtime discovers nearby peers directly. With a server, every device and agent connects to a shared service.
32+
33+
That shared service gives you a few fleet-level building blocks:
34+
35+
- **routing** so devices on different networks can join the same mesh
36+
- **registry** so clients can see known devices, their capabilities, and their last-known status
37+
- **shared state** so devices and agents can coordinate through a common store
38+
- **commissioning** so each device gets its own trusted credential
39+
- **security controls** such as Transport Layer Security (TLS), mutual TLS (mTLS), JSON Web Token (JWT) authentication, role-based access control, and audit logging
40+
41+
Device Connect supports different messaging backends, including Zenoh, NATS, and Message Queuing Telemetry Transport (MQTT). In this Learning Path, you will use the hosted portal with NATS credentials. That lets you focus on the device and agent code instead of running the server yourself.
42+
43+
## A note on commissioning
44+
45+
Commissioning means giving a device or agent a trusted identity before it joins the mesh. Without commissioning, a process is just code trying to connect. With commissioning, the server can decide whether that process is allowed to publish, subscribe, register itself, or call an RPC.
46+
47+
The credential format depends on the messaging backend:
48+
49+
- with **Zenoh**, commissioning means issuing the device a client TLS certificate signed by a shared certificate authority (CA)
50+
- with **NATS**, commissioning means issuing the device a JWT credential bound to its tenant
51+
52+
In both cases, the credential answers the same question: is this identity allowed on this mesh?
53+
54+
In this Learning Path, you will use the [Device Connect portal](https://portal.deviceconnect.dev/) to download NATS credentials for three default identities on your tenant. Two identities will run simulated robot arms. The third identity will run the Python client or agent.
55+
56+
## Where this sits in the architecture
57+
58+
In the diagram, pub/sub means publish/subscribe, KV means key-value, LC means LangChain, and MCP means Model Context Protocol.
59+
60+
```
61+
┌──────────────────┐ ┌──────────────────────┐ ┌─────────────────────┐
62+
│ Devices │ │ Device Connect │ │ AI agents │
63+
│ (edge SDK) │ │ server │ │ (agent-tools) │
64+
│ DeviceDriver │◄───►│ Pub/sub · Registry│◄───►│ discover_devices() │
65+
│ @rpc @emit │ │ KV · Security│ │ invoke_device() │
66+
│ @periodic @on │ │ │ │ Strands / LC / MCP │
67+
└──────────────────┘ └──────────────────────┘ └─────────────────────┘
68+
```
69+
70+
Devices and agents still talk to each other through the same primitives (`@rpc`, `@emit`, `discover_devices`, `invoke_device`). The Device Connect server runs the pub/sub messaging, the persistent registry, the shared key-value store, and the security layer in one place.
71+
72+
The animation below shows the same idea end to end. A Device Connect server runs in Berlin. Robots in San Francisco and Tokyo install `device-connect-edge` and register with it. An AI agent in Bangalore installs `device-connect-agent-tools` and drives both robots through the server. Every `invoke_device` call and every event flows through the server.
73+
74+
<video width="100%" controls muted playsinline>
75+
<source src="https://raw.githubusercontent.com/kavya-chennoju/arm-learning-path-assets/main/videos/device-connect-server-overview.mp4" type="video/mp4">
76+
Your browser does not support the video tag.
77+
</video>
78+
79+
## What you'll do in this Learning Path
80+
81+
In the rest of this Learning Path you will:
82+
83+
- sign in to the Device Connect portal and identify your tenant slug
84+
- download credentials for the three default device identities
85+
- run two simulated robot arms with `device-connect-edge`
86+
- discover and invoke both devices from a Python client using `device-connect-agent-tools`
87+
- optionally attach a Strands AI agent to the same tenant
88+
89+
The next section walks through the setup.

0 commit comments

Comments
 (0)