Home > User Information
Device Configurations
Definition
A Device Configuration is a set of modules that contain instructions on how Messages from a Device are to be handled and stored in the Cloud. A Device Configuration is available for reuse in more than one Device Model.
Example
Plymouth Manufacturing wants to buy a new and more efficient IoT Conveyor Belt that has a different belt material. NuvIoT was able to use the same set of instructions, or device configuration, from the original Plymouth IoT Conveyor Belt without making changes to the system.
Overview
The Device Configuration provides instructions for how messages from a Device are handled and stored on the Cloud. It indicates how a device should work independent of a specific make and model so that it may be reused by different Device Models. The primary parts of a device configuration are Routes and Properties.
Parts of a Device Configuration
Label
By default, your Device will have generic label that will be used throughout your application. The device configuration will let you refer to the Device by another name within the Dashboard that is presented to the end user.
Routes
After the Cloud uses the Device ID to identify the Device that sent the Message, the Planner will obtain the Device Configuration. Based on the Message ID, it will attempt to lookup which Route should be used to process the Message.
The Route will consist of a set of Pipeline Modules which may include :
Sentinels - Checks the security of the message
Parsers - Extracts values from the message Payload
Sending any output messages to other systems or back to the device
Writing the values extracted from the message to a data stream.
Routes have a one-to-one mapping between a Message and a Device Configuration.
For more information on Routes, click here.
Data Stream Writers
Data Streams are used to capture and store data over time and can be created by creating Data Stream Writer objects. Where and How?
For more information on Data Streams, click here.
Transmitters
Transmitters are used to take Outgoing Messages and send them to a Device or user.
For more information on Transmitters, click here.
Custom Modules
Properties (Device Specific Settings)
The Routes associated with your IoT Device may contain workflows or business logic. In some cases, the rules associated with these modules may need to be configured for specific implementations. These properties can be added to the Device Configuration so that each installation can be different. Parameters can be used on the server within workflows or sent to the device so that values can be used within the firmware.
Your IoT device may have some work flows or business logic associated with them. In a number of cases, the rules associated with the work flows and business logic may have the need to be configured for specific implementations. For example, the Smart Litter Box may want to have a configurable parameter that will put a delay from the time the cat steps on the litter box until the upper unit rotates, this is done so that the cat won’t be scared of motion. For some cats it can be as quick as a few seconds, but for others they may prefer to be 60 seconds. This configuration parameter can be added to the Device Configuration so each installation can be different. Device Configuration parameters can be used on both the server within work flows or sent down to the device so those values can be used within firmware.
Error Codes
Common failures that occur are assigned an error code and can be identified at the Device Configuration level. These error codes can help diagnose and fix problems.
As anyone that does anything with technology knows, things don’t always go as planned with technology. Parts wear out or break, things happen that are unexpected or other failures occur. With this in mind the Smart Litter Box team wants to be proactive on handling these failures to ensure customer satisfaction. Common failures that occur are assigned an error code and can be identified at the Device Configuration level. These error codes can help diagnose and fix problems. Error codes can either be generated by the Device Configuration receiving specific messages or can be created by rules added to business logic. When an Error Code is created, it can send a notification to a distribution list, this can be sent as either an email or as an SMS text message. Optionally NuvIoT has a very basic Field Service implementation called Field Service Lite. Service Tickets can be generated when Error Codes are generated and managed by Field Service Lite.
Message Watch Dogs
A Watchdog is a piece of software that sends out a notification if it does not receive a message in a predefined period of time. It insures that the device has not lost a connection with the cloud.
In almost all cases you want to ensure that your device remains connected to your cloud application. If the device is not connected you will likely want to know so you can re-stablish the connection. After all, a connected IoT device that is not connecting doesn’t provide as much value as it could. A Watchdog is a piece of software that if not fed will send out notification that there is a problem. Another way of saying that is if the device doesn’t call in or send a message within a predefined amount of time, let’s say every 15 minutes, we can assume that the Watchdog isn’t getting fed and thus the Watchdog will timeout. When the watchdog times-out, it can be setup to send a notification to either a user or a distribution group.
Just as we have watch dogs that ensure that a device calls in and remains online, we also have watch dogs that can be used to look for messages arriving from the device. If a message does not get received from a device within a specified period of time and Error Code will be generated. An example of this for our Smart Litter Box is that we expect to have the cat use the litter box at least twice a day. That means that every 12 hours the cat should be using the litter box at least once. Since we know that each time the cat uses the litter box it will send an Enter message from the device to the server, we should receive that message at least once every twelve hours. If we don’t receive a message within that period, we can send out a notification to the cat’s owner that there may be an issue.