Multi-Pi Mesh Networking

A mesh lets you treat two or more Raspberry Pi devices as a single, coordinated system. Instead of managing each Pi in isolation, you name the group, decide which Pi leads it, and tell LoopString which rooms belong to which device. The platform then keeps every Pi in the group aware of its peers so Node-RED flows can coordinate across physical locations without any custom networking code on your part.

This is different from the fleet overview in Multi-Device Setups, which is about monitoring many independent devices side by side. A mesh is about devices that need to work together — sharing a common control boundary, exchanging status, or reacting to conditions happening on another node.

When to use a mesh

A mesh is the right choice when two or more Pis need to coordinate in real time — for example, when a sensor reading on one Pi should influence an actuator on another, or when you want a single view that spans physical zones. If your devices operate independently and you simply want to see them together in a dashboard, you do not need a mesh.

A mesh requires a minimum of two devices and supports up to ten.

How to set up a mesh

Mesh management lives in Settings under Device Meshes. You will need a Pro or higher subscription to create a mesh.

1. Open the dashboard and navigate to Settings.
2. Select Device Meshes from the sidebar.
3. Click Add Mesh.
4. Give the mesh a name that describes the physical installation — for example, "Greenhouse Cluster" or "Building A Network".
5. Check the box next to each Pi you want to include. You must select at least two.
6. For each selected Pi, type in the room names that device is responsible for, separated by commas.
7. Choose one Pi as the primary device by selecting the star radio button next to it.
8. Click Create Mesh.

The platform saves the configuration and immediately syncs it to every Pi in the group via Firebase Realtime Database. No redeployment of Node-RED flows is required — the peer discovery data is pushed automatically.

To edit a mesh later, click the pencil icon on any mesh card. To remove a mesh, click the trash icon. Removing a mesh stops the RTDB sync; each Pi will continue running its own flows independently.

Primary and secondary roles

Every mesh has exactly one primary device. The primary is the reference point for the mesh — its device ID is what other Pis use to locate the group's control context in the RTDB tree.

Secondary devices are all other members of the mesh. They are peers, not subordinates — they can read and write to shared RTDB paths just like the primary. The distinction matters mostly for disambiguation: when a Node-RED flow on any Pi needs to know which device is the authoritative source for a particular signal, it checks the primaryDeviceId field in the mesh config.

You can reassign the primary at any time by editing the mesh and selecting a different device.

How RTDB sync works

When you save a mesh in Settings, Firestore stores the configuration under your user account. A Firebase Cloud Function called onMeshWritten fires automatically on every create, update, or delete of that document.

On create or update, the function writes the mesh configuration to the Realtime Database at the path /meshes/{meshId}. This path is globally readable by any authenticated Pi agent running your Node-RED flows. Each Pi in the mesh can subscribe to this path using a standard Node-RED RTDB in-node and will receive the full peer list — device IDs, labels, roles, and room assignments — within seconds of a change.

On delete, the function removes the RTDB node entirely. Pis that were subscribed to that path will receive a null value and can handle the disconnection gracefully.

Timestamps are stored as milliseconds since epoch so they are compatible with the RTDB format that Node-RED reads natively.

Use Cases

Multi-zone greenhouse

A commercial greenhouse might use three Pis: one in the propagation area, one in the main growing bay, and one in the shipping and post-harvest zone. Each Pi manages its own sensors and actuators — temperature, humidity, CO2, irrigation — for its local rooms.

With a mesh, the growing bay Pi can read the propagation Pi's temperature output from RTDB and pre-condition its heaters before a batch of seedlings is transferred. The dashboard shows all three zones under a single device group with a unified alert view. If a CO2 alarm fires in any zone, staff can see which Pi reported it without switching between devices.

Setup: create a mesh with three members, assign the growing bay Pi as primary (it has the most sensors and is the reference point for the facility's baseline readings), and scope the rooms for each Pi to match their physical zones.

Distributed manufacturing line

A factory line might run four Pis positioned at sequential stages: raw material intake, processing, quality inspection, and packaging. Each stage has its own process controls and must stay within defined parameters, but they also need to pace each other — if the processing stage falls behind, the intake should slow down.

With a mesh, an RTDB path on the processing Pi can publish its throughput rate. The intake Pi's Node-RED flow subscribes to that path and uses the value as a throttle input. The quality inspection Pi can write a reject flag that the packaging Pi reads before accepting the next unit.

Setup: create a mesh with all four Pis, assign the processing Pi as primary since it is the constraint in the system, and name the rooms after each production stage for clear identification in the dashboard.

Troubleshooting

Pis are not seeing each other's data in Node-RED

Verify that your Node-RED RTDB input node is subscribed to /meshes/{meshId} using the correct mesh ID. The mesh ID is visible in the Firestore document path — you can retrieve it programmatically via the LoopString API or by noting it in the Settings page URL when you edit the mesh. Check that the Pi's Firebase credentials have read access to the top-level meshes collection; this is granted by the default security rules when you use the official Pi provisioning setup.

Mesh shows the wrong number of devices after adding one

The maximum is ten devices per mesh. If you attempt to add an eleventh, the platform will reject the request with an error. If you are below the limit and still see stale data, try refreshing the Settings page — the React Query cache has a five-minute stale window for mesh data, so a recent change might not appear immediately in the UI without a manual refresh.

A deleted mesh is still visible in RTDB on the Pi

Deletion triggers the onMeshWritten Cloud Function, which removes the RTDB node. If the Pi still sees data at /meshes/{meshId}, the most likely cause is that the Cloud Function failed silently. Check the Firebase console under Functions for any errors logged by onMeshWritten. Re-saving and then re-deleting the mesh will retrigger the function. As a manual fallback, you can remove the RTDB path directly from the Firebase console.

Primary device reassignment is not reflected on secondary Pis

Primary reassignment is a mesh update and goes through the same onMeshWritten Cloud Function as any other change. The updated primaryDeviceId should appear in RTDB within a few seconds. If a secondary Pi's Node-RED flow cached the old primary ID in a flow variable, restart that flow or trigger a re-read from RTDB to pick up the change.

The Add Mesh button is greyed out or shows a tier gate

Multi-Pi Mesh is a Pro plan feature. If you are on Hobby or Starter, the Device Meshes panel will show a plan upgrade prompt. Upgrade your subscription from the Billing section of Settings.

Known Limitations

A single mesh supports between two and ten devices. If you need to coordinate more than ten Pis, consider splitting your installation into multiple meshes and using a shared RTDB path as a rendezvous point between them.

Room names are entered as a free-text comma-separated list when configuring the mesh. They are not validated against the rooms defined in your Configurator draft. If a room name in the mesh does not exactly match the room key in your deployed flow, the Pi will not be able to correlate mesh membership with local sensor paths. Use the exact room keys from your Configurator — these are the lowercase hyphenated identifiers shown in the room header, not the display labels.

Mesh sync is one-directional: Firestore is the source of truth and RTDB is the read replica. Do not write to /meshes/{meshId} in RTDB directly; any manual change will be overwritten the next time a mesh document is updated in Firestore.