Tenant Operations on Deevnet IoTaaS

Walkthrough: Device to Backend

Mon, 01 Jan 0001 00:00:00 +0000

Walkthrough: a Pico W or ESP32 Talking to a Backend #

The whole path, end to end: a microcontroller on your bench publishes readings over MQTT, a backend on a workload receives them and can send commands back, and the device’s own log lines land in your log store.

 Pico W / ESP32 ──Wi-Fi (your key)──▶ IoT network ──TLS 8883──▶ MQTT broker ◀──TLS 8883── backend workload
 │ │ (your tenant network)
 └── publishes bench1/log/<device> ───────────────────────────▶ log bridge ──▶ your log partition (index, 2)

The tenant in this walkthrough is called bench1. Use your own name everywhere you see it.

Pi Lab

Mon, 01 Jan 0001 00:00:00 +0000

Pi Lab #

The Raspberry Pi bank is a shared workbench for projects that need a Pi rather than a VM: edge compute, SDR, sensors, GPIO, clustering experiments. The hardware and why it was chosen are under Raspberry Pi in Implementation & Tooling; this page is how to use it.

The idea is the SD card is the product. You develop on a bank Pi; when the project works, the card moves to dedicated hardware and the bank Pi returns to the pool.

Connect Device to Wi-Fi

Mon, 01 Jan 0001 00:00:00 +0000

Connect Device to Wi-Fi #

Any Wi-Fi board you flash, such as a Pico W or an ESP32, joins the site’s IoT SSID with your tenant’s Wi-Fi key. It makes no difference whether the device is your own or a pre-wired kit borrowed at a meetup (CARPE keeps those on its Example Project Kits page): once your key is on it, it is one of your devices.

This page covers only getting the device onto the network. Talking to the broker comes after, in Devices & MQTT, and the walkthrough does both end to end.

Convert a Tenant to a Pi Image

Mon, 01 Jan 0001 00:00:00 +0000

Convert a Tenant to a Raspberry Pi Image #

This page converts a tenant into a standalone Raspberry Pi image: your app and your devices keep working, with no Deevnet behind them. The Pi is flashed from the image factory’s pi-backend image and runs your tenant’s back-end services itself, so it can go anywhere: home, a classroom, a project that outlives the site.

 on Deevnet on your Pi
 ────────── ──────────
 devices ──TLS 8883──▶ mqtt.mobile.deevnet.net devices ──TLS 8883──▶ your Pi (Mosquitto)
 app ──TLS 8427──▶ Deevnet log store app ──TLS 8427──▶ your Pi (VictoriaLogs)
 you ──TLS 3000──▶ Deevnet Grafana you ──TLS 3000──▶ your Pi (Grafana)
 <tenant>/… <tenant>/log/<device> <tenant>/… <tenant>/log/<device> ← unchanged

The Pi keeps the app contract: the same ports, the same topic prefix, the same reserved log level, the same ingest and read tokens with the same partition header, and a Grafana organization with the same three data source UIDs. What changes is the host name, the CA and the secrets. Nothing on the Pi belongs to Deevnet. It has no Deevnet account, key or route, and its CA and tokens are generated on the card the first time it boots.

Troubleshooting

Mon, 01 Jan 0001 00:00:00 +0000

Troubleshooting #

Is it the network? #

If Terraform or an MQTT client times out, check the network before anything else. From your laptop on DVNTM-TD:

curl -fsSLO https://raw.githubusercontent.com/deevnet/ansible-collection-deevnet.net/main/scripts/segment-check.sh
bash segment-check.sh DVNTM-TD

It checks your address and DNS, the provisioning API, the state store and the broker (each over the site CA), the internet, and that the rest of the site is correctly out of reach. Turn off any VPN or iCloud Private Relay first. All passing means the network is fine and the problem is on the Terraform or client side (below). Anything failing: send the whole output to the operator; the fix is on the substrate, not in your repo.