Connectivity profiles

Every Solution (FuelFleet, ClimateFleet, …) shares the same dashboard spine. Connectivity profiles describe how field data reaches Autoconnecto. Mix WiFi, 4G, and Ethernet on the edge; the platform boundary is always normalized telemetry keys on a device (or gateway child).

Engineer transport details: backend/docs/MODBUS_TUNNEL.md in the repo and Device connectivity (developer).

---

Profile summary

ID	Name	Edge role	Typical link	Autoconnecto path
P1	Cloud Modbus + serial tunnel	Serial bridge (DTU)	4G, sometimes WiFi	Gateway MQTT_SERIAL — cloud is Modbus master, child + register map
P2	Edge Modbus master	ESP32, industrial GW, SBC	WiFi, Ethernet, 4G on edge	Edge polls RS485, publishes JSON via device or gateway + childDeviceId
P3	Transparent / TCP tunnel	Serial server, some DTUs	Ethernet, 4G	Gateway DIRECT or LAN bridge — Modbus master in cloud or on LAN
P4	Native smart device	Integrated sensor/controller	WiFi, LTE, Ethernet	Device token — MQTT / HTTP / WebSocket
P5	Hub gateway relay	Multi-drop hub	Mixed	Gateway token + per-sensor childDeviceId
P6	Integration	LoRaWAN, vendor cloud	RF → HTTP	ChirpStack / TTN / generic webhook + mapping

Validation tiers (see Validation status for the live table):

• Bench tested — Run on Autoconnecto with real hardware (today: EnergyFleet / ClimateFleet P1 only).
• Pending bench test — Documented from datasheets; safe to follow for install planning; sign-off when lab/field allows.
• BYO — Any hardware that publishes the Solution telemetry keys.

---

P1 — Cloud Modbus + serial tunnel (4G DTU)

Autoconnecto publishes Modbus RTU frames on MQTT; the DTU forwards them to RS485.

flowchart LR
  AC[Autoconnecto cloud]
  DTU[Cellular DTU e.g. USR-DR154]
  BUS[RS485 bus]
  SL[Modbus slave sensor or meter]
  AC -->|MQTT modbus/tx rx| DTU
  DTU --> BUS
  BUS --> SL

Piece	Role
Gateway device	MQTT_SERIAL, owns broker topics
Child device	Slave ID + register map + auto poll
DTU	MQTT ↔ RS485 only (not Modbus master)

Example guide: USR-DR154 Modbus MQTT (XY-MD02 climate sensor).

When to use: Remote sites without local WiFi; one or few Modbus slaves on one bus.

---

P2 — Edge Modbus master (ESP32 / edge gateway)

The edge device is Modbus master; Autoconnecto receives telemetry JSON.

flowchart LR
  AC[Autoconnecto]
  EDGE[ESP32 or edge GW]
  BUS[RS485]
  SL[Modbus slaves]
  AC <-->|MQTT or HTTP| EDGE
  EDGE --> BUS
  BUS --> SL

Example guide: ESP32 Modbus edge (WiFi MQTT).

When to use: Lab and plant WiFi; multiple local polls; offline buffering; custom scaling before cloud.

---

P3 — Transparent / TCP Modbus

Modbus RTU or TCP crosses a tunnel; framing depends on gateway connection_mode (DIRECT, outbound tunnel). Prefer P1 for cellular unless you run a LAN bridge (modbus-tunnel-bridge in repo).

When to use: Fixed Ethernet at panel; existing serial servers; short LAN hops.

---

P4 — Native MQTT / HTTP / WebSocket

Sensor or controller speaks Autoconnecto protocols directly (device token). No cloud Modbus.

When to use: Smart meters with LTE, WiFi IAQ boxes, SDK-based firmware.

---

P5 — Gateway relay

One gateway connection; payloads include childDeviceId for each logical sensor.

See Device connectivity → Gateway tab.

---

P6 — Integrations

LoRaWAN and vendor webhooks. Map DevEUI / external IDs to devices; normalize keys in Integrations.

---

Choosing a profile

Constraint	Often fits
No WiFi at site	P1 (4G DTU) or P4 (LTE device)
Indoor / office WiFi	P2 (ESP32) or P4
Plant Ethernet panel	P3 or P2 with Ethernet
Genset controller with Modbus	P2 or P3 at panel; map controller registers
LoRa sensors	P6

Each Solution reference stack lists which profiles apply and the recommended wiring for that domain.