About this article

• Audience: Integrators attaching M8 accessories to Ghost Protocol Shadow cameras
• Goal: Understand the sidecar plugin model and MQTT contracts for relay I/O, WLAN, and CANbus
• Type: Concept

Summary

M8 accessories extend a Shadow without touching the main vision pipeline. Three Ghost Protocol plugins cover the common kit:

Accessory	Plugin	Outcome
I/O relay controller	m8_controller	Relays, GPIO, door events, status LEDs
Wi‑Fi adapter	m8_wifi	WLAN stats + failover signaling
CAN adapter	m8_can_bus	SocketCAN / J1939-class vehicle telemetry

Uplink doctrine: prefer LAN PoE+; use M8 Wi‑Fi as secondary. Full product page: Shadow connectivity & M8 accessories.

Prerequisites

• Shadow with M8 accessory port
• Plugin system available on the device
• Adequate PoE+ (or approved local power) — accessories do not replace power delivery

Decoupled service model

The Edge AI / RF-DETR pipeline owns the camera:

1. Main daemon — Sole persistent claim on encode + RF-DETR.
2. Plugin sidecar — Independent process; must not open the camera device graph.
3. Data path — MQTT command ingress and telemetry/events egress.

Plugins never compete with the primary H.265 / detection stack for ISP ownership.

I/O relay controller (m8_controller)

Resource	Typical use
Power relays	Door locks, strobes, contact closures
GPIO (3.3 V)	Door sensors, triggers, dry contacts
Status LEDs	Local health / mode

MQTT (live plugin contract)

Topic	Direction	Purpose
casper/{id}/cmd/relay	Host → Edge	Relay pulse / latch commands
devices/{id}/events	Edge → Host	Door and automation events
devices/{id}/responses	Edge → Host	Command acknowledgements / errors

Example relay command:

{
  "relay": 1,
  "duration_ms": 1000
}

duration_ms of zero toggles latch; positive values pulse then release. Always stop() cleanly so relays reset to a safe state.

Older docs mentioned devices/{id}/cmd/m8. Prefer the live casper/{id}/cmd/relay subscription used by plugins/m8_controller.

Wi‑Fi adapter (m8_wifi)

Item	Detail
Role	Monitor WLAN RSSI/SSID; signal failover when Ethernet is down
Telemetry	{casper|devices}/{id}/telemetry/wifi
Doctrine	Secondary to PoE+ LAN — see connectivity

Lab “WLAN-only broker” setups (host MQTT on Wi‑Fi for desk testing) are not the same as M8 dual-uplink production failover.

CANbus adapter (m8_can_bus)

Item	Detail
Host interface	Linux SocketCAN (can0)
Telemetry	{casper|devices}/{id}/telemetry/can
Use	J1939-class heavy-vehicle frames correlated with vision events

Bring-up bitrate and PGN maps for a given fleet stay in operator handoff.

Plugin packaging

Each plugin follows the standard package contract:

• start(mqtt_client) — start monitors / subscriptions
• stop() — clean shutdown (relays safe, threads joined)

Packages load from plugins/m8_controller/, plugins/m8_wifi/, plugins/m8_can_bus/ without rebuilding the core edge image. Deploy via the plugin system.

Lab test rig (relay — optional)

• Host GPIO → M8 GPIO input for trigger simulation
• M8 relay COM/NO → host input for closed-loop confirmation
• Shared ground; keep GPIO current within limits

Production docs use role labels (site-role-a) rather than physical door names.

Security and safety

• Relays can switch high loads — isolate lab loops from production circuits.
• Validate command sources through fleet MQTT ACL and Phantom Vision proxy ingress.
• Monitor sidecar CPU/USB health; IRQ and CAN listeners run in dedicated threads.

Next steps

• Shadow connectivity & M8 accessories — doctrine and ports
• Plugin system — deploy / remove
• MQTT architecture — namespace map
• Plugin authoring — packaging patterns

Operator depth

Wiring photos, SSIDs, and fleet CAN maps live in private operator handoff (not published).