Meter Command Flow

From a button click in the app, down to the physical smart meter and back — gatekeeper checks, protocol adapters, push vs pull responses, and follow-on side-effects.

100%
DEVICE MESSAGING HARDWARE OUTGOING INCOMING Request blocked DEFERRED · SUSPENDED · ABORTED 1 2 3 4 5 6 7 8 9 10 11 12 13 14 App User Clicks 'Send Command' REST API Receives the request Create record Interaction saved to database Gatekeeper Can this be sent right now? Queue message Stored in Redis Encode & dispatch LoRaWAN · Calin API v1 · v2 Network server ChirpStack or Calin API Smart electricity meter Physical hardware on the pole Network server Receives meter response Push or pull Webhook · polling every 5s Decode response Via protocol adapter / codec Process & correlate Match response to sent request Update record Write result to database After-effects Orders · commissioning · more App User Sees real-time update

Key Concepts

Gatekeeper (step 4)

Before queueing a command, the system checks whether the meter and grid are in a state that allows the command to go through.

  • QUEUED — all clear, command is dispatched to the device
  • DEFERRED — meter is mid-commissioning; command waits and resumes automatically
  • SUSPENDED — grid or gateway temporarily offline; retries when restored
  • ABORTED — meter unreachable for too long; command is permanently cancelled
Adapters & Codecs (steps 6 & 10)

Meters use different physical and API protocols. An adapter layer handles encoding outgoing commands and decoding incoming responses for each.

  • LoRaWAN (CALIN) — low-power radio via ChirpStack network server; binary encoded payloads
  • Calin API v1 — HTTP API through a gateway device (DCU); task-based
  • Calin API v2 — updated HTTP API with a richer response structure
Push vs Pull (step 9)

Responses come back from meters in two different ways, depending on which communication protocol the meter uses.

  • Push (LoRaWAN) — ChirpStack posts a webhook when the meter replies; near-instant
  • Pull (Calin API) — a background job polls the API every 5 seconds to check if the task completed
After-Effects (step 13)

When a command completes (or fails definitively), a chain of follow-on actions runs automatically.

  • Update the meter's last-known state (credit, power limit, RSSI, etc.)
  • Advance or fail an active commissioning flow
  • Notify linked orders or batch commands of their progress
  • Trigger follow-up reads (e.g. read credit balance after a top-up)
  • Push a real-time update to the user's dashboard via WebSocket