IoT Monitoring Project Checklist: Devices, Data and Alerts

Devices and protocols: know what is being connected

Record manufacturer, model, hardware and firmware version, fleet count, unique identifier and owner. Provide protocol notes and an authorized anonymized sample. Identify serial, Modbus, MQTT, HTTP or proprietary interfaces, and flag documentation or access still to be obtained.

MQTT QoS describes message delivery. It does not by itself establish application deduplication, command execution or recovery of every offline reading. Define message identifiers, idempotent processing and execution acknowledgment for the application.

Pair protocol notes with a raw message and its expected interpretation. For a cumulative runtime field, record the unit, overflow behavior and what happens after a restart. A screenshot showing a normal value will not tell a developer whether a reset to zero is expected, a device fault or a decoding error.

Measurements: preserve meaning and time

Swipe horizontally to see the full table.

Network and recovery: define outage behavior

Describe connectivity, coverage, power, outbound restrictions, gateway resources and who can arrange access. Agree offline buffering, capacity eviction, reconnect throttling, deduplication and late-data handling. If maximum outage duration is unknown, record it as a condition to investigate.

Estimate raw buffering from message rate × bytes per message × outage duration, then allow for encoding, indexing and operating headroom. Confirm capacity by measurement. Raw vibration waveforms cannot be sized like occasional status readings.

Alerts and ownership: who acts, and how?

Record threshold basis, duration, recovery criteria, maintenance suppression, grouping, escalation and recipients. Separate device outages from abnormal values. Keep acknowledgment and handling records. Without field evidence, a threshold is a configuration to validate, not an established diagnosis.

Assess monitoring and remote control separately. Starting equipment or changing parameters requires decisions on authorization, command expiry, device acknowledgment, human confirmation and necessary local interlocks.

Identify someone who can answer questions about alerts. An equipment engineer knows which operating conditions need inspection; duty staff know what happens when notifications become too frequent; a manager may need a daily summary. They need different views and timing. Sending every alert to one group does not complete the response process.

Write acceptance scenarios using failure replay

• Use one device type and dataset to verify identity, units, timestamps and trends.
• Simulate outages, duplicates, ordering and clock offset; check indicators and recovery.
• Trigger, acknowledge and resolve an alert; inspect ownership and records.
• Run under the agreed load and inspect missing data, latency and queries.
• Retain sample data, configuration version, expected results and failure notes.

This checklist supports project preparation; it does not replace site safety assessment, sensor selection or equipment certification. List missing information and agree how it will be investigated.

For handover, ask someone who did not build the system to investigate a failure using only the interface and documentation. Can they distinguish a device, gateway or platform problem, locate the logs and identify whom to contact? This reveals gaps a feature demo may miss: logs without device IDs, alerts without source values or instructions kept only on a developer’s computer.