Management
Device Snapshots
Iotellect server creates and keeps device snapshots, i.e. cached device metadata and most recent setting values. System operators only work with snapshots and rarely with devices directly. The platform, in its turn, synchronizes snapshots with devices.
Synchronization is made on a “best effort” basis, i.e. at the earliest opportunity when the device gets online and connects to the server. This is the way Iotellect solves the problem of remote configuration, control and monitoring of devices with unstable availability.
If a device is disconnected, Iotellect server queues setting changes and requested operations, while the device itself may buffer events and value updates. Both server-side and device-side updates will be synchronized once the connection is restored.
Mass Device Management
Regardless of device protocol, Iotellect always does its best to minimize the amount of manual work required for managing devices within your IoT app or solution.
Discovery and Provisioning
Iotellect tries to connect most devices in "plug-and-play" style via a number of varying methods:
- IP network scanning
- Broadcast-based network device discovery
- Automatic configuration of discovered devices for communicating with Iotellect
- Automatic creation of platform-side device accounts
- Scheduled auto-discovery and auto-connection
- Discovery of available device settings, operations and events
Groups
Groups are used to consolidate devices or system resources (such as event filters or alerts). They simplify management of large device/resource sets and make batch operations more convenient.
While it's possible to add members to any group using drag and drop, some groups may auto-populate their contents. Such a dynamic group checks resources with a user-defined criteria to figure out which ones are “valid” for this group. Those resources are automatically added to the group and auto-removed once they no longer match validity criteria. For example: dynamic groups in a fleet management product may automatically show vehicles with low fuel level, vehicles with active alerts, or even vehicles inside a geozone.
It's possible to put groups into other groups. Group nesting level is not limited. Nested groups are often used to reflect complex hierarchies of corporate assets divided by divisions/departments or geographically.
Groups may automatically analyze properties of their members and use flexible rules to evaluate aggregate groups status. For example, a group of devices may get red ("group members have problems") if at least one device in a group has synchronization errors.
Batch Operations
It is easy to execute an operation over a set of a group of devices, e.g. reboot ten devices at once. Groups also provide an easy way to apply similar settings to all members or automatically replicate configuration changes between them.
Since device snapshots are stored on the server, batch operations with a large number of devices are possible regardless of how many devices are currently connected to the server. Batch operations can be performed even on devices that are not fully identical, e.g. running different firmware versions and having differing setting formats. In each such case, the server will also perform the operation on a “best-effort” basis, i.e. try to match the settings of one device to the settings of another.
Direct Management
In most cases, operators of various Iotellect-based products are working with custom dashboards and user interfaces designed as a part of platform-based products.
However, system administrators and engineers may want to have immediate direct control over connected devices. In Iotellect, we call this direct device management.
It’s possible to configure, control and monitor any previously connected device regardless of its current connection status.
Administrators and engineers with necessary authorization level may view and change the values of device settings, execute operations and view their output, as well as monitor device events in real-time. Changes, operations and events will be queued if a device is currently offline.
Event Management
Iotellect events are a unified presentation of internal server activities, valuable operations of platform’s modules, asynchronous notifications received from devices, operator actions, and even configuration changes.
Event management is a set of features ordered for making sense of a large event set and pinpointing a few instances that are really important. Iotellect servers process billions of events received from diverse sources and generated within the system, but only a few of them are actually viewed and analyzed by system operators and administrators. Converting a million source events into a hundred manually assessed ones is performed via filtering, aggregation, masking, enrichment, correlation, and root cause analysis.
In Iotellect, there are transient and persistent events. Transient events can be only processed at the moment they are generated. Persistent events are stored in the server database, and therefore can be used for trend analysis, charting, report building, etc. All persistent events are automatically purged after a configurable expiration period.
Real-Time Monitoring and History Browsing
Monitoring valuable events in real-time is a typical activity of system operators in automation, physical security, fleet management, and many other IoT product types.
The essential UI tool for working with valuable events is Event Log. Pre-filtered events are subdivided into several severity levels and grouped into two areas: real-time events and event history. The log enables event sorting, filtering, removal, and acknowledgement processes within your IoT app.
Event Filtering
To mark out essential events from an incoming event stream, Iotellect users can create and manage event filters. A filter is owned by whoever created it but may be shared between users due to a flexible permission setup.
Events can be filtered and further highlighted by source, type, severity level, parameters of acknowledgment/enrichment, or any custom criteria defined by an expression.
Alerts and Notifications
Alerts notify system operators when certain important events occur or a valuable state is reached in any part of a distributed IoT solution. They make sure operators notice what they should notice without going around the system for periodic checking.
Triggers
Every alert has one or more triggers defining when to raise it. Each trigger may check one or more devices or resources, e.g. all devices in a group. Combined with the ability to set up multiple triggers per alert, this allows a very flexible setup.
An event trigger is raised when an event or a sequence of events conform to the trigger condition. This condition is flexibly configured by an expression, allowing complex checking. The trigger may be optionally active until deactivated by a correlated event or event sequence. A state trigger can either be raised in response to a certain state, or to any change in the state of whatever is monitored.
A state trigger periodically checks a specific value which is also pointed by a custom expression. State triggers have configurable hysteresis (deadband) time for activating the alert only if the condition lasts longer than the certain time period. Separate rearming hysteresis is also supported. Conditions of state triggers may be checked against dynamically adjusted baselines, such as monthly average or weekend maximum. Moreover, state triggers support value flapping (frequent change) detection that is reported as a separate alert type.
Notifications
Alert notifications inform operators about the alert conditions and provide related information. Notification types include pop-up messages to the operator, custom sounds, email/SMS/WhatsApp/Telegram notifications, and more.
Alerts may be acknowledged via your app’s UI or by replying to notification emails.
Active Alerts
Once raised, an alert may remain active while its causing condition is in force or until an event correlated to the activation event is received. The server keeps the global active alert list and tracks active instances associated with every resource and device. Active alerts with high priority are usually visualized on the system overview dashboards.
Pending Alerts and Alert Escalation
Some alerts require operator acknowledgements. Non-acknowledged alert instances are called pending alerts, and such alerts are highlighted to attract operator's attention.
Alert escalation usually indicates that the situation has become critical. Escalation rules can be bound to the number of active alerts and their lifetime.
Corrective Actions
When a certain error occurs, it often requires one specific remedy. Because of it being so predictable, it can be automated. Any system action or workflow may be automatically launched in response to an alert and interactively executed under operator’s supervision.
If no operators are on duty or your app functions in standalone mode, the corrective action is launched in non-interactive (a.k.a. "headless") mode. Such action relies on pre-defined parameters.
Job Scheduler
Iotellect's job scheduler lets you periodically execute any device management or system task, such as sending an attendance report by email or checking device status and running an external application in case of a problem.
There are two types of schedules. According to a simple schedule, an action is executed for a set number of times with a fixed interval. Advanced schedules allow complex execution patterns, like "execute every minute starting at 2:00 PM and ending at 2:59 PM, every day" or "execute at 10:15 AM on the last Friday of every month during 2023 and 2024".