From 4232f3e5a769f91ec5e10ff88322b8f5e4c45591 Mon Sep 17 00:00:00 2001 From: Annie Tallund Date: Wed, 20 May 2026 13:05:00 -0700 Subject: [PATCH 1/2] Add RPi 5 to Device Connect LPs --- .../device-connect-d2d/_index.md | 8 +- .../device-connect-d2d/background.md | 4 +- .../device-connect-d2d/d2d-setup.md | 47 +++++----- .../device-connect-d2d/overview.md | 10 +-- .../device-connect-server/_index.md | 6 +- .../device-connect-server/background.md | 6 +- .../device-connect-server/server-setup.md | 85 +++++++++++-------- 7 files changed, 94 insertions(+), 72 deletions(-) diff --git a/content/learning-paths/embedded-and-microcontrollers/device-connect-d2d/_index.md b/content/learning-paths/embedded-and-microcontrollers/device-connect-d2d/_index.md index e4fd04b169..f07f30314e 100644 --- a/content/learning-paths/embedded-and-microcontrollers/device-connect-d2d/_index.md +++ b/content/learning-paths/embedded-and-microcontrollers/device-connect-d2d/_index.md @@ -4,16 +4,18 @@ title: Device-to-Device communication with Device Connect minutes_to_complete: 25 -who_is_this_for: This is an introductory topic for developers wiring up heterogeneous edge fleets, where devices need a shared way to find each other and a shared way to be controlled by agents. Device Connect provides this communication protocol between agents and devices, and standardizes how devices from different vendors advertise themselves and exchange structured messages, so both peer devices and AI agents can discover and invoke them through the same driver model. You'll use it to stand up peer-to-peer communication between two devices, with no broker or cloud service in between. +who_is_this_for: This is an introductory topic for developers wiring up heterogeneous edge fleets, where devices need a shared way to find each other and a shared way to be controlled by agents. Device Connect provides this communication protocol between agents and devices, and standardizes how devices from different vendors advertise themselves and exchange structured messages, so both peer devices and AI agents can discover and invoke them through the same driver model. You'll use a Raspberry Pi 5 as the primary edge device and stand up peer-to-peer communication with no broker or cloud service in between. learning_objectives: - Understand Device Connect Edge SDK primitives - - Set up a Python environment for Device Connect with no hardware required - - Build two simulated devices + - Set up a Python environment for Device Connect on a Raspberry Pi 5 and a development machine + - Build two device runtimes, with the primary sensor runtime running on the Raspberry Pi 5 - Use the Device Connect agent tools to discover both devices on the mesh and invoke their RPCs prerequisites: - Basic familiarity with Python and the command line + - A Raspberry Pi 5 running a 64-bit Linux distribution, such as Raspberry Pi OS + - A development machine on the same local network as the Raspberry Pi 5 author: - Kavya Sri Chennoju diff --git a/content/learning-paths/embedded-and-microcontrollers/device-connect-d2d/background.md b/content/learning-paths/embedded-and-microcontrollers/device-connect-d2d/background.md index a6b5a38893..9e26a94722 100644 --- a/content/learning-paths/embedded-and-microcontrollers/device-connect-d2d/background.md +++ b/content/learning-paths/embedded-and-microcontrollers/device-connect-d2d/background.md @@ -10,7 +10,7 @@ layout: learningpathall Arm processors sit at the heart of a remarkable range of systems, from Cortex-M microcontrollers in industrial sensors, to Cortex-A boards driving robots and appliances, to Neoverse servers in the cloud. Many edge applications need these devices to cooperate: a sensor publishes a reading, a supervisor reacts, a controller adjusts an actuator. The obvious way to wire that up is through a central broker or a cloud service, but both add latency, operational overhead, and a single point of failure you may not want in a lab, a vehicle, or a factory cell. -Direct device-to-device (D2D) communication sidesteps that. Devices on the same local network discover each other, exchange typed events, and call each other's functions directly, with no broker, no registry, and no cloud round-trip. It is a good fit for: +Direct device-to-device (D2D) communication sidesteps that. Devices on the same local network discover each other, exchange typed events, and call each other's functions directly, with no broker, no registry, and no cloud round-trip. A Raspberry Pi 5 is a good primary device for trying this pattern because it is an Arm-based Linux system that can run the same Python runtime and Device Connect SDK used by larger edge devices. D2D is a good fit for: - prototyping sensor networks and local automation flows - small fleets (roughly 50-100 devices) on a shared network @@ -33,7 +33,7 @@ In D2D mode, every participant is a peer. Each device runtime joins the same pub ``` ┌──────────────────────────────────────────────┐ -│ Sensor device │ +│ Raspberry Pi 5 sensor device │ │ - device_id: sensor-001 │ │ - @rpc get_reading │ │ - @emit reading_ready ─┐ │ diff --git a/content/learning-paths/embedded-and-microcontrollers/device-connect-d2d/d2d-setup.md b/content/learning-paths/embedded-and-microcontrollers/device-connect-d2d/d2d-setup.md index f4d65df37e..14b1af2866 100644 --- a/content/learning-paths/embedded-and-microcontrollers/device-connect-d2d/d2d-setup.md +++ b/content/learning-paths/embedded-and-microcontrollers/device-connect-d2d/d2d-setup.md @@ -6,16 +6,21 @@ weight: 4 layout: learningpathall --- -In this section you'll build two simulated devices on the same mesh: +In this section you'll build two device runtimes on the same mesh, with the Raspberry Pi 5 as the primary edge device: -- a **sensor** that publishes temperature and humidity readings on a schedule -- a **threshold monitor** that subscribes to those readings and raises an alert when the temperature crosses a configurable threshold +- a **sensor** that runs on the Raspberry Pi 5 and publishes temperature and humidity readings on a schedule +- a **threshold monitor** that runs on your development machine, subscribes to those readings, and raises an alert when the temperature crosses a configurable threshold This mirrors a real edge scenario, a room supervisor watching environmental sensors for out-of-bounds conditions, and exercises every Device Connect primitive across two cooperating devices. ## Install uv -This walkthrough uses [uv](https://docs.astral.sh/uv/) to manage the project and its Python dependencies. uv will resolve a compatible Python interpreter, create a virtual environment, and install packages for you, so no manual `venv` or `pip` steps are needed. +This walkthrough uses [uv](https://docs.astral.sh/uv/) to manage the project and its Python dependencies. Install uv on both machines: + +- the Raspberry Pi 5, which runs the sensor runtime +- your development machine, which runs the monitor and the agent-tools client + +uv will resolve a compatible Python interpreter, create a virtual environment, and install packages for you, so no manual `venv` or `pip` steps are needed. {{< tabpane code=true >}} {{< tab header="macOS or Linux" language="shell">}} @@ -34,7 +39,7 @@ uv --version ## Create the project -Create a new project and add the Device Connect packages: +Create the same project on both the Raspberry Pi 5 and your development machine, and add the Device Connect packages: ```bash mkdir ~/device-connect-d2d @@ -45,9 +50,11 @@ uv add device-connect-edge device-connect-agent-tools The [`device-connect-edge`](https://pypi.org/project/device-connect-edge/) package is the device runtime SDK. It is what turns a Python class into a live peer on the messaging mesh. The [`device-connect-agent-tools`](https://pypi.org/project/device-connect-agent-tools/) package is the client side: it lets an agent or script discover devices and invoke their RPCs. In production you might consume devices from a different client, but for this walkthrough it is the fastest way to confirm that discovery and RPC are working. -## Write a simulated sensor device +Keep both machines on the same local network. D2D discovery uses local network discovery, so VPNs, guest Wi-Fi isolation, or firewall rules that block local traffic can prevent the Raspberry Pi 5 and your development machine from seeing each other. + +## Write the Raspberry Pi 5 sensor device -Create a file called `sensor.py`: +On the Raspberry Pi 5, create a file called `sensor.py`: ```python import argparse @@ -72,12 +79,12 @@ class SimulatedSensor(DeviceDriver): device_type="simulated_sensor", manufacturer="Device Connect", model="SIM-TH-100", - description="Simulated temperature and humidity sensor", + description="Raspberry Pi 5 temperature and humidity sensor example", ) @property def status(self) -> DeviceStatus: - return DeviceStatus(availability="available", location="simulator") + return DeviceStatus(availability="available", location="raspberry-pi-5") @rpc() async def get_reading(self) -> dict: @@ -120,11 +127,11 @@ This driver uses three of the decorators introduced in the overview: - `@emit` declares `reading_ready` as an event the device publishes to the mesh - `@periodic` runs `publish_reading` every five seconds so the sensor produces fresh data on its own -The `identity` and `status` properties are what other peers see during discovery. They are how this device advertises itself as a `simulated_sensor` with a known manufacturer, model, and availability. +The `identity` and `status` properties are what other peers see during discovery. They are how the Raspberry Pi 5 advertises itself as a `simulated_sensor` with a known manufacturer, model, and availability. The readings are generated so you can focus on Device Connect behavior first; you can replace `publish_reading()` with a real sensor read later without changing the runtime structure. ## Write a threshold monitor device -Now create a second device that consumes the sensor's data. Create a file called `monitor.py`: +Now create a second device that consumes the Raspberry Pi 5 sensor's data. On your development machine, create a file called `monitor.py`: ```python import argparse @@ -155,7 +162,7 @@ class ThresholdMonitor(DeviceDriver): @property def status(self) -> DeviceStatus: - return DeviceStatus(availability="available", location="simulator") + return DeviceStatus(availability="available", location="development-machine") @on(event_name="reading_ready") async def on_reading(self, device_id: str, event_name: str, payload: dict): @@ -200,15 +207,15 @@ The monitor adds one primitive you haven't seen yet: - `@emit alert_raised` lets the monitor publish its own events when a threshold is crossed, so another peer or agent could subscribe to alerts in turn. - `@rpc get_recent_alerts` exposes the monitor's recent history so an external caller can query what it has seen. -## Run the sensor and the monitor +## Run the Raspberry Pi 5 sensor and the monitor -Open two terminals in the project directory (`~/device-connect-d2d`). In terminal 1, start the sensor: +Open a terminal on the Raspberry Pi 5 in the project directory (`~/device-connect-d2d`). Start the sensor: ```bash uv run python sensor.py --device-id sensor-001 ``` -In terminal 2, start the monitor with a threshold below the sensor's typical temperature range so you see alerts quickly: +On your development machine, open a terminal in the project directory (`~/device-connect-d2d`). Start the monitor with a threshold below the sensor's typical temperature range so you see alerts quickly: ```bash uv run python monitor.py --device-id monitor-001 --threshold 27.0 @@ -216,11 +223,11 @@ uv run python monitor.py --device-id monitor-001 --threshold 27.0 `uv run` executes the command inside the project's managed environment, so you do not need to activate a virtual environment manually. -Within a few seconds, the monitor terminal should start printing `received ... from sensor-001` lines, and an `ALERT:` line each time the simulated temperature rises above 27.0 °C. This is the sensor invoking the monitor across the mesh through its emitted event, and you did not configure any address or pairing between them. +Within a few seconds, the monitor terminal should start printing `received ... from sensor-001` lines, and an `ALERT:` line each time the temperature rises above 27.0 degrees C. This is the Raspberry Pi 5 sensor invoking the monitor across the mesh through its emitted event, and you did not configure any address or pairing between them. ## Query the monitor from agent tools -Open a third terminal in the project directory and run: +Open a second terminal on your development machine in the project directory and run: ```bash uv run python - <<'PY' @@ -241,7 +248,7 @@ print("recent alerts:", invoke_device(monitor_id, "get_recent_alerts")) PY ``` -The script discovers both devices, invokes `get_reading` on the sensor, and invokes `get_recent_alerts` on the monitor. The alert list should contain every breach the monitor has observed since it started: +The script discovers both devices, invokes `get_reading` on the Raspberry Pi 5 sensor, and invokes `get_recent_alerts` on the monitor. The alert list should contain every breach the monitor has observed since it started: ``` Found 2 device(s) @@ -260,8 +267,8 @@ You have exercised every Device Connect primitive across two cooperating devices - **Events**: the sensor emitted `reading_ready`; the monitor reacted through `@on` and emitted its own `alert_raised` - **Status**: both runtimes advertised themselves as `available` through the `status` property -The sensor and monitor did not know about each other before they started. They found each other on the local network and communicated purely through typed events and RPCs, with no broker, no registry, and no cloud service. +The Raspberry Pi 5 sensor and monitor did not know about each other before they started. They found each other on the local network and communicated purely through typed events and RPCs, with no broker, no registry, and no cloud service. ## Outcome -You now have a working D2D deployment where two simulated devices cooperate on the same mesh: a sensor that publishes data and a monitor that reacts to it and exposes its own state. This same driver pattern (a class, a handful of decorators, and a runtime) is how you would describe a real sensor, actuator, or monitor on the network. +You now have a working D2D deployment where a Raspberry Pi 5 primary device cooperates with a monitor on the same mesh: the Pi publishes data, and the monitor reacts to it and exposes its own state. This same driver pattern (a class, a handful of decorators, and a runtime) is how you would describe a real sensor, actuator, or monitor on the network. diff --git a/content/learning-paths/embedded-and-microcontrollers/device-connect-d2d/overview.md b/content/learning-paths/embedded-and-microcontrollers/device-connect-d2d/overview.md index f1d2d845db..3435936dc0 100644 --- a/content/learning-paths/embedded-and-microcontrollers/device-connect-d2d/overview.md +++ b/content/learning-paths/embedded-and-microcontrollers/device-connect-d2d/overview.md @@ -12,7 +12,7 @@ The [`device-connect-edge`](https://pypi.org/project/device-connect-edge/) packa You describe a device by subclassing `DeviceDriver` from `device_connect_edge.drivers`, then annotating methods and properties with primitives. The runtime wires them into discovery, pub/sub, and RPC for you. -In this Learning Path you'll use these primitives to write two cooperating drivers: a **sensor** runtime that publishes temperature and humidity readings on a schedule, and a **threshold monitor** runtime that reacts to those readings and raises alerts when a threshold is crossed. The subsections below walk through the identity, decorators, and runtime you'll use to build them, and the agent tools package you'll use to invoke them from a separate client. +In this Learning Path you'll use these primitives to write two cooperating drivers: a **sensor** runtime that publishes temperature and humidity readings from a Raspberry Pi 5 on a schedule, and a **threshold monitor** runtime that reacts to those readings and raises alerts when a threshold is crossed. The subsections below walk through the identity, decorators, and runtime you'll use to build them, and the agent tools package you'll use to invoke them from a separate client. ### Identity and status @@ -44,12 +44,12 @@ Any Python process that imports this package can find and drive devices without ## What you'll build -In the next section you will create two cooperating simulated devices on the same local network: +In the next section you will create two cooperating devices on the same local network: -- a **sensor** driver that publishes temperature and humidity readings on a schedule using `@rpc`, `@emit`, and `@periodic` -- a **threshold monitor** driver that uses `@on` to subscribe to the sensor's readings, emits its own `alert_raised` event when a reading crosses a threshold, and exposes the alert history through an `@rpc` method +- a **sensor** driver that runs on a Raspberry Pi 5 and publishes temperature and humidity readings on a schedule using `@rpc`, `@emit`, and `@periodic` +- a **threshold monitor** driver that runs on your development machine, uses `@on` to subscribe to the sensor's readings, emits its own `alert_raised` event when a reading crosses a threshold, and exposes the alert history through an `@rpc` method -You will run both devices as independent runtimes on one machine and watch the monitor react to the sensor in real time. Finally, you will use the agent tools package to discover both devices and query their RPCs from a separate terminal. +You will run both devices as independent runtimes on separate machines and watch the monitor react to the Raspberry Pi 5 sensor in real time. Finally, you will use the agent tools package to discover both devices and query their RPCs from a separate terminal. By the end, you will have a working D2D deployment where two devices find each other automatically and communicate through typed events and RPCs. This is the same pattern you would use to model a real sensor and a real supervisor on an edge network. diff --git a/content/learning-paths/embedded-and-microcontrollers/device-connect-server/_index.md b/content/learning-paths/embedded-and-microcontrollers/device-connect-server/_index.md index ce31a7de52..df2d794465 100644 --- a/content/learning-paths/embedded-and-microcontrollers/device-connect-server/_index.md +++ b/content/learning-paths/embedded-and-microcontrollers/device-connect-server/_index.md @@ -1,7 +1,7 @@ --- title: Deploy multi-network device meshes using Device Connect server and NATS -description: Connect devices and AI agents across networks using Device Connect server. Learn to provision NATS credentials, commission devices, manage persistent registry, and orchestrate multi-network IoT fleets with secure authentication. +description: Connect a Raspberry Pi 5, secondary devices, and AI agents across networks using Device Connect server. Learn to provision NATS credentials, commission devices, manage persistent registry, and orchestrate multi-network IoT fleets with secure authentication. minutes_to_complete: 30 who_is_this_for: This Learning Path is for developers who have completed the Device-to-device Learning Path and want to add a server layer to their Device Connect mesh. You'll learn to use persistent registry, distributed state, and security features (commissioning, ACLs) to operate a multi-network fleet. If you're new to Device Connect, start with the device-to-device Learning Path first. @@ -9,13 +9,15 @@ who_is_this_for: This Learning Path is for developers who have completed the Dev learning_objectives: - Understand what the Device Connect server adds on top of the edge SDK and when you'd reach for it - Provision a hosted tenant on the Device Connect portal and download per-device NATS credentials - - Commission two simulated devices against your tenant using the credentials the portal issues + - Commission a Raspberry Pi 5 primary device and a secondary device against your tenant using the credentials the portal issues - Discover and invoke commissioned devices from a Python client using `device-connect-agent-tools` - Connect a Strands AI agent to the same tenant prerequisites: - Complete the [Device-to-device Learning Path](/learning-paths/embedded-and-microcontrollers/device-connect-d2d/) to understand Device Connect edge SDK basics - An account on the [Device Connect portal](https://portal.deviceconnect.dev/) + - A Raspberry Pi 5 running a 64-bit Linux distribution, such as Raspberry Pi OS + - A development machine for the secondary device and Python client - Basic familiarity with Python and the command line author: diff --git a/content/learning-paths/embedded-and-microcontrollers/device-connect-server/background.md b/content/learning-paths/embedded-and-microcontrollers/device-connect-server/background.md index 14db041405..4abcd97bb0 100644 --- a/content/learning-paths/embedded-and-microcontrollers/device-connect-server/background.md +++ b/content/learning-paths/embedded-and-microcontrollers/device-connect-server/background.md @@ -70,7 +70,7 @@ Both answer the same question: is this identity allowed on this mesh? ### What you'll use in this Learning Path -In this Learning Path, you'll 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. +In this Learning Path, you'll use the [Device Connect portal](https://portal.deviceconnect.dev/) to download NATS credentials for three default identities on your tenant. The primary identity runs on a Raspberry Pi 5, the second identity runs on your development machine as another device, and the third identity runs the Python client or agent. ## Multi-network deployment architecture @@ -98,7 +98,7 @@ Devices and agents still talk to each other through the same primitives (`@rpc`, ### Real-world example: global device coordination -The animation demonstrates a complete multi-network workflow: a Device Connect server runs in Berlin, robot arms in San Francisco and Tokyo register with it using `device-connect-edge`, and an AI agent in Bangalore orchestrates both robots using `device-connect-agent-tools`. Every `invoke_device` call and event flows through the server, demonstrating how the server enables secure, multi-network device coordination. +The animation demonstrates a complete multi-network workflow: a Device Connect server runs in Berlin, devices in San Francisco and Tokyo register with it using `device-connect-edge`, and an AI agent in Bangalore orchestrates both devices using `device-connect-agent-tools`. Every `invoke_device` call and event flows through the server, demonstrating how the server enables secure, multi-network device coordination.