The first implementation, in working order.

InfiIoT treats the connected asset as the stable object. Devices carry identity, variables describe measured or calculated values, and dashboards are views over that model. Events, reports and predictions use the same identities rather than creating separate copies of the data.

1. 01Create the organisation account and verify the work email address.
2. 02Name the people who administer users, device credentials and production access.
3. 03Open the authenticated portal and locate the assigned token or integration credential.
4. 04Store production credentials in a secret manager. Do not paste them into firmware repositories or support tickets.

A portal token can authorise device and API activity. Treat it like a production password and rotate it when ownership changes.

Start with the decision the dashboard should support. A useful first dashboard usually needs a small number of current values, a trend over the right operating interval and enough context to identify the asset and its state.

1. 01Choose the dashboard name and the operating audience.
2. 02Add the current value, trend or state widget that answers the first question.
3. 03Set the time interval and units before reviewing the visual shape.
4. 04Test the view with the service or operations person who will act on it.

A device represents the physical or logical asset sending data. Variables hold individual signals such as temperature, pressure, state, energy or location. Synthetic variables derive a new value from existing signals; geo variables attach location context.

1. 01Choose HTTP or MQTT based on the device and network constraints.
2. 02Send one known value with an explicit timestamp and unit.
3. 03Confirm the device identity, variable name and timestamp in the portal.
4. 04Only then increase the payload, sampling rate or fleet size.

An event evaluates a named condition against a variable. The action can notify a person, update another variable or call a webhook. Use persistence time or hysteresis when a noisy signal would otherwise create repeated alerts.

1. 01Choose the variable and the condition that matters operationally.
2. 02Set the threshold, persistence time and reset behaviour.
3. 03Choose who or what should receive the action.
4. 04Test the full route, including acknowledgement and recovery.

Reports work best when they have a named reader and review rhythm. Decide which measurements, exceptions and operating notes belong together, then schedule the output for that review cycle.

Prediction begins with a failure mode or maintenance decision, not a model. Confirm that the historical data includes the conditions and labels needed to evaluate the proposed outcome. Keep the first model advisory until false positives and missed events have been reviewed in the field.

• Use encrypted transport for device and API traffic.
• Issue the narrowest credential that the device or integration needs.
• Record who owns each credential and when it must be rotated.
• Separate test and production assets.
• Test loss of network, expired credentials and failed updates before rollout.
• Review event and access logs during pilot acceptance.