What to check before real devices go into service – transport security, credentials, limits, alarms, retention, roles, audit and API keys.
A test setup and a production setup differ in the details: a test device that still uses plain MQTT, an alarm nobody receives, an API key with every right. Go through this list before you put real devices into service, and again when you add a new kind of device. Each item links to the page that explains it.
Device connections
Check
Why
Read
Every profile keeps Plain MQTT on TLS only (port 8883), except a profile made for devices that cannot do TLS.
Credentials and data never cross the network in clear.
Provisioning keys you no longer need are revoked; the strategy of each profile is the one you mean. Only pre-provisioned devices is safer than Allow creating new devices for devices sold in volume.
The expected messages per month fit the plan. Telemetry and attribute messages count; commands, alarms and connection events do not. Warnings come at 80 % and 95 % by default, plus a notice when it is used up and when it is exceeded.
Each profile’s online rule fits its devices: Live connection for devices that hold MQTT, Recent message with a realistic Expected interval for devices that report and disconnect.
Every alarm rule that should wake someone has recipients (at most 20), a minimum severity and, if needed, a reminder. Rules without notify only record alarms.
The alarm settings fit your team: storm threshold, repeat window, Critical alarms ignore notification preferences, how long resolved alarms are kept (365 days by default).
You know your retention class. Raw readings are kept at most 90 days; hourly and daily aggregates for the whole class (up to 1,095 days). Export what you must keep longer.
We use necessary cookies to run the site. With your permission we also use analytics and marketing cookies. You can change your choice at any time. Cookie policy