What works without a connection
What each client can still do when the network drops, and what happens when it comes back.
Every client holds an open connection to the IoTFlows cloud and redraws as readings arrive. What survives losing that connection differs by client, and on mobile it differs by platform.
Sections about the phone assume the app is installed. See Install the mobile app and sign in.
Offline behavior by surface
| Surface | Client | Readable offline | Writable offline | On reconnect |
|---|---|---|---|---|
| Messaging | Android | Yes, chats and history from the on-device database | Yes, queued in the outbox | Outbox flushes, oldest first |
| Messaging | iOS | No, messages are held in memory only | No, a failed send turns red | Tap the red bubble to resend |
| Chat attachments | Android, iOS | Files opened recently, from the media cache | No | Download resumes |
| Maintain | Android | No | No | List refetched |
| Maintain | iOS | Yes, the last list fetched for that view | No | Cached list refreshed in place |
| Inventory | Android, iOS | Yes, the last parts list fetched | No, adjustments fail | Cached list replaced wholesale |
| Everything | Web | No | No | Live updates resume, figures do not refresh |
On mobile
What each client does as the connection degrades: live, degraded, offline, reconnecting.A state machine of four boxes in a row, joined left to right by arrows. Live: updates arrive as they happen. Degraded: the last-loaded data stays on screen and stops updating. Offline: reads come from cache, and writes either queue or fail. Reconnecting: the client retries from about one second apart, backing off to about sixty. A return arrow runs from Reconnecting back to Live, labeled: subscriptions are restored and the mobile outbox flushes, oldest message first.Check which phone your operators carry before you rely on any of this.
Android keeps chats, messages, and members in a database on the device, so a thread opens and scrolls with no connection. Its messaging writes go to an outbox, a queue holding the actions you took while disconnected: sending, editing, deleting, pinning, reacting, and saving a draft. They publish in the order you made them.
iOS has neither. Messages are held in memory for as long as the screen is open, and a send that does not reach the server turns red for you to tap. Nothing queues and nothing retries on its own, so leaving the chat loses the message.
Attachments are cached on both. A file you opened recently plays from the device instead of the network, and anything older waits.
Maintain and Inventory hold less. Inventory paints the last parts list it fetched on both platforms, but a stock count is a shared number other people are changing, so an adjustment made offline fails rather than queuing. Maintain caches its list on iOS only, per view; on Android the tab stays empty until a request succeeds.
On the web
The dashboard caches nothing. There is no offline mode and no stored copy, so a tab opened without a connection shows nothing.
A tab already open keeps whatever it last loaded and stops updating. The numbers on screen are the numbers from the moment the link dropped, not the current ones.
Two toasts report the same condition in different words: Waiting for Network and Trying to connect. Both mean an action needed the live connection, it was not there, and the change was not sent. Repeat the action once the connection is back.
Do not site an operator station on Wi-Fi that drops out, expecting the web dashboard to ride it out. It does not cache, so every dropout blanks the screen. Put the operator on the mobile app instead, or fix the coverage first.
When the sensor loses connection
A sensor that cannot reach the cloud publishes nothing, so the cloud has nothing to record. The machine reads as stopped for the whole gap, whether or not it was running.
That is the most common cause of a downtime entry nobody on the floor recognizes. Check the device before you classify the reason. See Get a device back online.
On reconnect
The web dashboard reconnects on its own, and keeps trying indefinitely. It retries about a second after the drop, then doubles the wait each time up to a minute. It also reconnects at once when your operating system reports the network back, or when you return to the tab. A Reconnecting toast stays up while it works.
Live updates resume as soon as it succeeds. Figures loaded when you opened the page are not fetched again, so reload if you need a number to be current.
Android works through its backlog in a fixed order: the outbox first, then the chat list, then the thread you have open. iOS has no backlog to work through, so a message that failed while you were offline is still sitting there unsent.
See also
A four-phase plan for putting a plant on IoTFlows: pilot one line for two weeks, win operator adoption and turn on alerts, cut the downtime category list down to reasons you can act on, and only then add scheduling and maintenance. Each phase carries a gate that has to close before the next one starts.
Answers to the questions asked before buying IoTFlows and during the first week after: whether the sensors touch the PLC, what machines they fit, how long an install takes, whether one sensor can cover two machines, what network access the devices need, how an organization gets created, whether a machine's history survives a sensor swap, and where invoices live.