The Dashboard displays information from devices added to the Team. However, it does not necessarily include information about all devices, locations or groups. As explained below, the information to be displayed can be changed by editing the Dashboard.

In SensDesk, the Dashboard focuses on the sensor states, not the sensor values or the device status (that is only supplementary information). It consists of three parts. The first part gives a quick sensor state overview, grouped by sensor state and showing the number of sensors in that state. Each state has a specific color and icon; this scheme is applied throughout the SensDesk portal.

Status	Color	Sensor icon	Device icon
OK	Green
Alarm	Red
Unknown	Orange
Invalid	Orange
Disabled	Gray

The green color indicates sensors that are in the OK state, that is, they communicate normally and their value is within the allowed “safe range”. A device is OK as long as all of its sensors and detectors are OK. The Dashboard shows how many sensors are OK and on how many devices. The latter piece of information is particularly useful for devices that are turned off (Disabled) or malfunctioning (Invalid) as it allows to distinguish a problem with a sensor from a problem with an entire device.  Click the OK block to go to the list of sensors in that state.

Red means Alarm, i.e. the reading of a sensor or a detector is outside of the specified safe range. If a sensor or detector is in the Alarm state, the entire device is in the Alarm state, too. Sensors that do not communicate (are disconnected) are not listed in the Alarm section but rather in the Invalid section, even though alarm notifications are still sent for these sensors. This makes it easier to identify problems. The Dashboard also gives an overview of the number of alarms for the past 2 hours (bottom part of the page), so that there is a quick way to see the recent history of alarms, including those that only lasted a short time. This makes it easier to identify the problem if the user received a notification but the alarm ended before the user had a chance to look at it in SensDesk. Click the Alarm block to see a list of sensors in that state.

The orange color represents sensors in the Invalid state, i.e. sensors that either do not communicate at all (disconnected or destroyed), or are not sending valid data (faulty or damaged). Unlike the Alarm state, the Invalid state does not propagate to the device; a distinction is maintained between the Sensor invalid and the Device invalid states. In particular, Sensor invalid means one or more faulty sensors, while Device invalid means a faulty device. On the other hand, when a device is in the Device invalid state (e.g. due to loss of communication), all its sensors and detectors are also reported as Device invalid, so that it is possible to distinguish sensor faults from device faults. In the Dashboard, the Invalid section lists the number of sensors in the Invalid state, regardless of the cause. The number of devices with such sensors is also shown. Click the Invalid block to see a list of sensors in that state.

The grey section represents Disabled sensors. At the first glance, the number of sensors disabled by the user may not look like an interesting piece of information; however, it is very useful when diagnosing a problem. Sensors and detectors (digital inputs) can be disabled by the user at the Edit Sensor page of the respective sensor, digital input or output. Sensors may be disabled to make the SensDesk overview more concise or to avoid storing unnecessary data. It is also possible to disable (and remove from reports) unused digital inputs, outputs, or for instance counter values. The disabled items are then listed under Disabled so that they are easy to find if needed. In the Dashboard, the Disabled section shows the number of sensors as well as the number of devices with these sensors. Click the Disabled block to see a list of sensors in that state.

The sensor block only displays information about sensors and digital inputs of devices that the user has selected at the Edit Dashboard page.

The next important section is the list of Locations and Device groups. This section gives an overview of how many Locations and Device groups are in Alarm, that is, contain at least one sensor in Alarm, how many sensors are affected and how many sensors are Invalid or Disabled. It is a different presentation of the same information as above.

The Locations and Device groups block only displays information about sensors and digital inputs of devices that are assigned to Locations and Device groups selected by the user at the Edit Dashboard page.

The last part of the Dashboard is a list of last sensor state changes (that is, transitions from no alarm to alarm and vice versa, loss of communication, and so on). The table only lists the last state change for each sensor, and by default only in the last 2 hours.

The list always includes the date and time of the state change in UTC (universal time, without regard to the user’s time zone); the name and ID of the sensor, digital input or digital output in question; the Location and Sublocation assigned to the sensor; the current value and its unit of measurement; and the previous and current state. Clicking the sensor name or ID leads to more details about the sensor.

The Current state column displays the current sensor state, while the Last state column displays the previous state. In this way, it is easy to see e.g. that a sensor or a digital input has transitioned from the Alarm state to the OK state or vice versa. It is also possible that both columns show the Alarm state; this can happen, for example, when the sensor was in Alarm because its reading was below the Safe range, and then the reading jumped to a value above the Safe Range.

To display the last sensor state changes regardless of when they have happened, click the Show all sensors link.

There is one particularity with the list of sensor state changes. Since the table displays state changes, for new devices the state may not be shown or may show as Invalid because there is no record of a state change yet.

To edit the Dashboard, click the Edit tab under the Dashboard name. The process is the same as if creating a custom dashboard – see below.

What is My Dashboard

My Dashboard is the possibility to create additional dashboards with different contents. While the main Dashboard is the same for the entire Team, individual departments or users can define their own dashboards (i.e. devices to monitor) in order to simplify their view of the monitored environment.  This function is particularly useful in large installations where users can define separate views with devices that monitor different sets of equipment in order to see only sensors and devices that they are interested in.

Working with My Dashboard

Working with Dashboards in SensDesk is similar to working with Device groups, Locations or My Graph. To work with the Dashboards, use the Dashboards item in the menu. To create Dashboards and switch among them, use the Select My Dashboard drop-down menu in the top right-hand corner of the Dashboard.

To create a new dashboard, click +Add my Dashboard to open the new dashboard creation menu. Set a name for the new Dashboard and assign devices, locations and groups to it. To select devices, click their names. Selected devices are highlighted in blue and also shown in the pane at the right-hand side. In the same way, selected Locations and Device groups are highlighted.

The sensor block only displays information about sensors and digital inputs of devices that are listed among Assigned devices. Sensors, digital inputs and outputs of devices in the Assigned locations and Assigned device groups are not automatically included in the sensor block.

After saving, the Dashboard page is displayed and the data loaded. To switch among Dashboards, use the drop-down menu.

Users of the SensDesk Technology portal can create My Dashboard. If more are needed, users are advised to contact their distributor and agree on the conditions of using extended SensDesk functions, such as increased number of supported devices, extended the datalog length or increased number of custom dashboards or graphs.

When speaking of a Portal or a Cloud, most people think of a website with graphs or a remote repository that costs money. And it is often the case. However, SensDesk by HW group is not just a portal or a cloud; it is primarily a unified measuring and control center for HW group products. SensDesk gives a quick overview of sensor states, displays a history of measured values, and allows creating simple conditions to trigger alarm actions such as sending an e-mail or a text message or activating a remote output. Its main advantage is the unified presentation of information from many different sensors and detectors in a human-readable and a machine-readable form.

The SensDesk portal offers features for home users, small and medium-sized businesses (SMB), as well as large enterprises and corporations. For homes and small offices, it is often enough to monitor the current states of sensors and detectors, and to be able to download the past temperature or consumption values (or to receive an e-mail if a value is out of an allowed range). Larger clients put emphasis on the integration of independent monitoring with existing systems. This can be complex, and thus expensive, because different measuring devices provide data in different formats – either for legacy reasons, or due to the particularities of the measured quantities. In these cases, SensDesk provides the most value – it makes data from different sensors and devices available in a unified and serialized XML file format.  

Basic SensDesk features

• A simple and concise Dashboard provides an overview of only those sensors that are interesting for the user. Multiple custom Dashboards with different contents can be defined. For example, the IT department would only watch the data that is relevant for them, and so would the power engineers.
• Independent Safe Ranges can be set for each sensor for the purposes of e-mail alerts. Support for HWg-SMS-GW3 in order to send alerts via text messages (SMS).
• An overview of devices and sensors that can be sorted by the status (Normal, alarm, invalid) or by the unit of measurement.
• Devices and sensors can be grouped according to their physical (Locations) or logical (Groups) place.
• Graphs of measured values for individual values (sorted by the measured quantities) as well as for individual sensors; data can be exported to CSV, XML, PDF, SVG, PNG or JPG
• Custom graphs combining different quantities can be created to watch for interdependencies.
• Advanced user management with a simple administration can assign individual users only the permissions they need. Individual users are grouped under a Team.
• Permission groups to assign users the rights to individual devices. While the User management restricts what the user can do, the Permission group restricts the resources that the user works with.
• Export of current values to XML is available for all values belonging to a team as well as for individual dashboards and graphs, and provides for an easy integration with ERP systems.
• SensDesk Technology can be used as either free HWg-cloud.com or paid SensDesk.com platform operated by HW group, platform by another portal provider, or on the customer’s premises using a virtual server.

There is no need to list the common features of all portals, such as the ability to display the readings from individual sensors and detectors and plot their history in a graph.

SensDesk unifies measurement and control

SensDesk integrates the monitoring and control of all types of HWg devices, including the communication among them. All settings are done in the SensDesk portal.

In SMB and home applications, monitoring is easy to install given the small number of devices and locations and the simplicity of user permissions. However, infrastructure maintenance projects and large-scale deployments need to access the data in SensDesk through various extensions and third-party monitoring applications.

Advanced functions of the portal include the integration and mutual control among all types of HWg devices.

Monitoring center – Alarm messages and the control of other devices

The SensDesk portal can be used to quickly set up the communication among all types of HW group devices. It is the most effective way to establish feedback between HWg sensors and actuators.

As already mentioned, SensDesk allows to set a Safe Range for each sensor or detector and trigger an alarm action whenever this range is exceeded. The action can be the sending of an e-mail or a text message (HWg-SMS-GW3 required). Another possible action is the activation of an output at one of the monitored devices. For example, if there is a water leak from an air conditioning or heating system at your Prague site, another device in the monitoring center in London can close its contact to sound a warning horn. While the boxes themselves are capable of doing that, by using SensDesk as the monitoring and control center, equipment and installation costs can be significantly reduced. With SensDesk, HW group devices of different product lines can be integrated; for instance, a HWg-WLD water leak detector can control an output of a SD-2xOut device, without a Poseidon2 or Damocles2 unit that would be required for a direct connection. The purchase price of a SD-2xOUT device comes to about 30% of the cheapest Damocles2 product – the Damocles2 MINI.

Smart devices offer completely autonomous operation but their installation requires qualified, and thus expensive personnel.

Single-purpose devices can be pre-configured at the company headquarters and then sent to wherever they are needed. The administration takes place completely via the SensDesk portal.

The SensDesk portal also simplifies the installation. It enables bidirectional communication without the need to configure network equipment or to tunnel ports. In order to control a device from another one, if the devices are not connected directly to the Internet with public IP addresses, routers need to be specially configured. The SensDesk portal makes things simple - all devices communicate with SensDesk only, and the portal is in the public Internet.

In case of M2M communication, the communication port must always remain open on the target router / firewall, which requires the intervention of a network specialist.	Access to individual devices from the external network (Internet) is also uncomfortable with direct connections, as communication ports need to be open on the destination router / firewall (one port per device), which requires the intervention of a network specialist.
When SensDesk is used as an intermediary, there is a slight slowdown in communication, but there is no need to interfere with the network infrastructure, which increases the security of both the application and the rest of the network.	By using the portal solution for setting up the behavior, Saferange and other target application parameters, the security of not only the application but also of the rest of the network is again increased. This method is very user-friendly, and what is more important, it remains the same across different products.

Interoperability of HW group devices when using direct connections

Local Condition	Controlled	Poseidon2 3268	Poseidon2 4002	Poseidon2 3468	Damocles2 MINI	Damocles2 1208	Damocles2 2404	Ares12	SD-2xOUT	IP WatchDog2 Lite	IP WatchDog2 Industrial
Controlling
Poseidon2 3266
Poseidon2 3268
Poseidon2 4002
Poseidon2 3468
Damocles2 MINI
Damocles2 1208
Damocles2 2404
Ares12 (LTE)
HWg-PWRxx
SD-2x1Wire
SD-2xIn
SD-WLD
HWg-STE Plus
STE2
HWg-WLD
WLD2
IP WatchDog Lite
IP WatchDog Industrial

Using SensDesk as a communication center

Push protocol	Controlled	Poseidon2 3268	Poseidon2 4002	Poseidon2 3468	Damocles2 MINI	Damocles2 1208	Damocles2 2404	Ares12	SD-2xOUT	IP WatchDog2 Lite	IP WatchDog2 Industrial
Controlling
Poseidon2 3266
Poseidon2 3268
Poseidon2 4002
Poseidon2 3468
Damocles2 MINI
Damocles2 1208
Damocles2 2404
Ares12
SD-2x1Wire
HWg-PWRxx
SD-2xIn
SD-WLD
HWg-STE Plus
STE2
HWg-WLD
WLD2
IP WatchDog Lite
IP WatchDog Industrial

Values.xml – Export of measured values and connecting to third-party software

Different HW group devices may generate different XML data formats. When using SensDesk, the output XML for a master system looks like a single device with many sensors.

Many companies now use a monitoring or information system, such as Nagios or another NMS in the IT sector, or PRTG in facility management. Integration of new devices into existing systems is expensive, and system managers are often reluctant to implement more than one device or protocol. However, different devices cannot have the same communication protocol due to the different nature of the measured quantities, or simply due to technical evolution. SensDesk allows to integrate all HW group devices into a single system with a unified XML format; for a master system, Sensdesk behaves as a single device with many sensors. For the user, there are values.XML files available for the whole Team (containing the current readings from all sensors and detectors) as well as for individual dashboards. The XML files can be accessed with http username/password authentication or with a URL containing an authentication key. For more details about the XML format, see the protocol description.

Other interesting SensDesk features

Dashboard

The Dashboard is a signpost and control center. It allows to get quick overview about how many sensors are OK and how many are in alarm, not reporting or turned off.
A single click leads to the list of such sensors. A significant advantage is the ability to create custom Dashboards, for instance displaying only devices that relate to a particular process or technology area (e.g. only refrigerators, only freezers, or only electricity consumption). With a custom Dashboard, users do not have to waste time figuring out whether a sensor in alarm belongs to their area of responsibility, and instead concentrate on their work.

Groups and Locations

Groups and Locations can be used to logically structure the network according to users’ needs.

When a user has more than just a couple of devices in SensDesk, it is usually a good idea to group related devices together. For this purpose, SensDesk uses Groups and Locations. Both of these features allow to group related devices together; however, the usage is different. Locations relate to physical locations of devices (Prague, New York, 1st floor etc.), while Groups relate to logical groupings (servers, engineering, etc.). This is reflected in different behavior. Only an entire device can be assigned to a Group. At the same time, one device can belong to several Groups. On the other hand, one device can belong to only one Location. However, Locations can be broken down to Sublocations, where individual sensors can be assigned.

Graphs

SensDesk allows you to create graphs that combine sensors and measured values in order to display critical process values simultaneously.

Any portal solution includes graphing features. SensDesk can generate graphs for individual sensors or detectors as well as a quick device-level overview. There, the graphs are separated according to the unit of measurement so that the rendering of different quantities is not mixed up in a single graph. However, the added value of SensDesk is the ability to create graphs with multiple sensors regardless of the unit of measurement. This allows to easily visualize and monitor interdependencies of quantities and values. For example, it can be found out that a temperature drop in a room was caused by an open door or a rise in humidity. Rising costs of laundry drying may be caused by high external temperature. And so on. These and many other pieces of information can be very useful to save operational costs or as an early warning about possible malfunctions.

What is Teams and User Management

Devices and device groups can be displayed to selected users, and data tracking, control and device administration functions can be separated.

In order to efficiently and securely share data among several users, these users need to be grouped under a Team. Usually, a Team would be a company; it can also be an interest group or just a company department. A Team has an owner that can add users and set their roles. A Team is also subject to all limits and restrictions applied at the portal level. Push parameters, including PUSH login and PUSH password, also apply to a Team as a whole. Therefore, the devices do not belong to an individual user anymore; they belong to the Team. This greatly simplifies the situation when responsible people change in the company. A serialized output of all values in a XML file is also available for every Team.

Types of user roles

• UM: Team admin – Has all the privileges to work with the Team. The admin can add users, add devices, set alarms or add dashboards and graphs.
• UM: Device admin – May add and configure individual devices and sensors, and obviously view the measured values. In combination with the Permission groups function, these users may be restricted to working with selected devices only, in order to increase system security as well as simplify the work of individual users.
• UM: Report admin – Reserved for future use. The Report admin will be able to configure and edit reports, such as overviews of the measured values, displayed data and so on.
• UM: Visitor – Can only view data.

Plotting the values of one quantity in a simple graph is a standard feature of any monitoring software, including PDMS, Nagios, PRTG or SensDesk. It is even included in some devices, such as HWg-PWR (although it tends to be limited in such cases). Graphs provide a quick overview and analysis of the measured data. They make it easy to spot rising or falling trends or periodic events. Some software systems can plot the readings from several sensors in one graph, as long as the measured physical quantity is the same. However, few applications can plot different quantities with different scales in a single graph because such an ability is computationally and graphically demanding.

Typical applications of My Graph

The My Graph function is used to compare multiple measured values in order to spot any dependencies. This is useful for analyzing the causes of alarm situations as well as for optimizing the operation of equipment such as HVAC.

Checking the temperature in refrigerators, freezers and cooling boxes

It is important to monitor temperatures in refrigerated areas where doors are frequently open or closed. By looking at temperatures and other sensors in time, it is possible to detect faulty refrigeration equipment; for example, causes of rising temperature can be identified by correlating temperatures with door contacts. If the temperature only rises when someone enters the cooler, there is no reason for concern. The graphs can be also used to generate reports with temperature values plotted in time in order to demonstrate compliance with storage requirements, e.g. for food, pharmaceuticals or other critical substances. For monitoring temperature and humidity, devices such as STE2 or Poseidon2 3266 can be used.

With a HWg-PWR25 device, energy consumption metering can be added to the system. By comparing the temperature in the refrigerated area with the energy consumption, it is possible to detect frost buildup or coolant leaks (rising electricity consumption without a change in temperature is an indication of an imbalance in the system and rising costs).

Monitoring the environment and hot and cold aisles in server rooms

Environment monitoring frequently involves checking the temperature in racks or data centers. For administrators, this information is absolutely essential, even though they may hesitate to store this data in a third-party portal. This information allows to correlate temperatures in a rack with doors being opened and closed, or to compare temperature trends in a cold aisle in a data center with door contacts, air flow and humidity; this can help identify problems with air circulation, such as mechanical obstructions caused by users or A/C technical problems. As a result, it is possible to reduce datacenter operating costs and increase reliability for customers. In datacenters, frequently used devices include Poseidon2 4002 and Poseidon2 3268.

Energy consumption monitoring in office spaces

In office spaces, environment monitoring is usually a complete solution that, in addition to electricity consumption and temperature, also monitors parameters such as lighting intensity and air quality. Even though these parameters may fall into the Measurement & Control domain, independent monitoring has its place in energy management and in ensuring correct function in order to maintain productivity and efficiency. When blinds in a building are raised on a hot sunny day, A/C operation may become very expensive. Vice versa, when blinds are shut outside of the heat peaks, artificial lighting is used unnecessarily and, if coupled with lower air quality, reduces staff productivity. For these applications, Poseidon2 3468 and HWg-PWR12 are frequently used. These devices can be installed on DIN rails in electrical cabinets.

Temperature and humidity monitoring in greenhouses

When growing plants in closed greenhouses, air circulation needs to be ensured in order to maintain a homogeneous environment. By monitoring temperature and humidity at several places at the same time, crop yield and quality can be improved. Suitable devices include Poseidon2 4002 or Ares 12 that can, for instance, control multi-point air circulation together with automated watering.
 

Monitoring environment stability and producing heatmaps in warehouses

In many cases, it is necessary to monitor whether the environment in the given premises is stable, i.e. without significant fluctuations. This monitoring may be important to preserve the stored goods (food, flowers etc.), as well as for diagnostic purposes. Temperature or humidity sensors must be placed at the important locations, but also away from sources of false alarms, such as due to draught. With the My Graph function, it is easy to show the differences of the respective values and to list details.
 

For more information about the graph functions and their use, see a separate Application note or the video below.

The following table shows selected devices with outputs that can be used for manual or automated control of appliances and custom equipment:

* With the optional Relay Output 1W-UNI external module

Control methods

The outputs can be controlled either manually, or using a condition (local or remote). However, the choice between local or remote control must be made in advance. These two methods cannot be combined; such a combination could lead to issues, such as when the user would manually turn off a system activated with a local condition or vice versa. Reliable industrial devices must not be prone to such mishaps.

On/off actions are used to turn on back-up systems, to give a visual or acoustic warning signal or to activate other types of emergency systems such as additional cooling, a water pump, and so on.

Pulse output is typically used to reset communication equipment, restore the operation of a control unit, or to raise alarm.

Outputs can be controlled by simply switching the output on or off, as well as by creating a pulse of a defined duration. In all cases, the pulse output is activated by specifying the “Pulse Timer” parameter in the Outputs section of the given device.

Uses 

• Manual control over WWW (on/off or pulse)
• Manual control from the AresConf application (on/off or pulse)
• Manual control from the SensDesk portal (on/off)
• Activating an output using a local condition (on/off or pulse)
• Remote control using the WWW interface of another device (on/off or pulse)
• Activating an output using a condition from another device (on/off or pulse)
• Activating an output using a condition in the SensDesk portal (on/off)

Manual control over WWW 

Manual control is effected by pressing a button in the Outputs tab in the WWW interface of a Poseidon2 or a Damocles2 device. It is only possible if the output is in the Manual mode. If the output is in the LocalCondition mode, it cannot be controlled manually. The output is controlled by pressing the Change to On or Change to Off button respectively, depending on the current state of the output.

To be able to switch the output on/off for a short time only (power cycle), simply fill out the Pulse Timer parameter. When the Reset Toggle button is pressed, the output state is changed only for the defined time. Although it is possible to the Change to On and Reset Toggle buttons in combination, we strongly discourage it if you cannot directly observe the results. The reason is that the Change to On button inverts the function of the Reset Toggle button.

Manual control of outputs from the AresConf application

Hwg-Ares12, HWg-Ares14 and Ares12LTE units can be connected to an external Relay output 1W-UNI module using the 1-Wire bus. This allows extending the functionality of the Ares unit with remote relay control as well as local conditions. Manual control is effected by pressing the Set1 (close) or Set0 (open) button at the Outputs tab of the AresConf application. It is only possible if the output is in the Manual & Remote mode. If the output is in the LocalCondition mode, it cannot be controlled manually.

Activating an Ares output using a local condition (on/off)

The LocalCondition mode allows switching an output in reaction to a state or value change at a sensor or input connected to the device. This is sometimes called the “thermostat” function, referring to the typical application in heating control. In a similar way, water can be pumped into a tank if the level drops, or simply a warning light or a horn can be turned on.

The local condition mode is again set at the Output tab.

The following options are available:

• On if any alarm – the output is activated if at least one input or sensor is in alarm. The reaction of the output depends on the Alarm state (Hysteresis and Delay functions are taken into account).
• On if value equal to Trigger – the output is activated whenever the sensor value is equal to the “Trigger value” (Saferange, Hysteresis and Delay functions are disregarded – oscillations may appear if the value fluctuates around the “Trigger value”). 
• On if value higher than Trigger – the output is activated whenever the sensor value is higher than the “Trigger value” (Saferange, Hysteresis and Delay functions are disregarded – oscillations may appear if the value fluctuates around the “Trigger value”).
• On if value lower than Trigger – the output is activated whenever the sensor value is lower than the “Trigger value” (Saferange, Hysteresis and Delay functions are disregarded – oscillations may appear if the value fluctuates around the “Trigger value”).
• On if alarm on – the output is activated if the selected sensor or input is in the alarm state (Hysteresis and Delay functions are taken into account).

Manual control from the SensDesk portal (on/off)

Manual control of outputs from the SensDesk portal is detailed in the Application note - Controlling outputs from SensDesk, available at https://www.hw-group.com/support/controlling-outputs-from-sensdesk.

Again, only outputs in the Manual mode can be controlled. However, unlike the control via the WWW interface, SensDesk only provides “on/off” control, without the pulse output option.

An output can be controlled from the output overview page, the respective device page or the specific output page by clicking the corresponding gadget.  The default state is neutral:

If the switch is moved to one side or the other, SensDesk instructs the output to be set accordingly:

Depending on the device settings, this instruction is executed within the standard Push period (15 minutes) or in the shortened period (60 s). Before the instruction is executed, the output state can be changed again, or the change cancelled. The device page does not refresh automatically; it must be refreshed manually.

Activating an output using a local condition (on/off or pulse)

The LocalCondition mode allows switching an output in reaction to a state or value change at a sensor or input connected to the device. This is sometimes called the “thermostat” function, referring to the typical application in heating control. In a similar way, water can be pumped into a tank if the level drops, or simply a warning light or a horn can be turned on.

The local condition mode is again set at the Output tab.

The following options are available:

• On if any alarm – the output is activated if at least one input or sensor is in alarm. The reaction of the output depends on the Alarm state (Hysteresis and Delay functions are taken into account).
• On if value equal to Trigger – the output is activated whenever the sensor value is equal to the “Target value” (Saferange, Hysteresis and Delay functions are disregarded – oscillations may appear if the value fluctuates around the “Target value”). 
• On if value higher than Trigger – the output is activated whenever the sensor value is higher than the “Target value” (Saferange, Hysteresis and Delay functions are disregarded – oscillations may appear if the value fluctuates around the “Target value”).  
• On if value lower than Trigger – the output is activated whenever the sensor value is lower than the “Target value” (Saferange, Hysteresis and Delay functions are disregarded – oscillations may appear if the value fluctuates around the “Target value”).
• On if alarm on – the output is activated if the selected sensor or input is in the alarm state (Hysteresis and Delay functions are taken into account).

To be able to switch the output on/off for a short time only (power cycle), simply fill out the Pulse Timer parameter. Then, the output state is changed in response to the condition only for the defined time.

Local conditions can be used not only for local physical outputs but also for remote outputs. With Poseidon2 and Damocles2 devices, communication and cooperation among two or more such devices is possible (M2M mode). This is achieved with the Virtual outputs function – for details, see Activating an output using a condition on another device. This is useful, for example, when one device senses the level of a liquid in a tank and another device controls the corresponding pump, or when one device monitors the temperature and humidity in an environment and another device controls the air-conditioning unit.

Remote control using the WWW interface of another device (on/off or pulse)

Thanks to the Virtual Outputs function in Poseidon2 and Damocles2 units, it is possible to control outputs remotely from the WWW interface of another device. This function allows connecting remote outputs of Poseidon2 and Damocles2 units to the WWW interface of another unit. It is configured at the Virtual Outputs tab.

Support of Virtual outputs in HW group devices

Local Condition	Controlled	Poseidon2 3268	Poseidon2 4002	Poseidon2 3468	Damocles2 MINI	Damocles2 1208	Damocles2 2404	Ares12	SD-2xOUT	IP WatchDog2 Lite	IP WatchDog2 Industrial
Controlling
Poseidon2 3266
Poseidon2 3268
Poseidon2 4002
Poseidon2 3468
Damocles2 MINI
Damocles2 1208
Damocles2 2404
Ares12 (LTE)
HWg-PWRxx
SD-2x1Wire
SD-2xIn
SD-WLD
HWg-STE Plus
STE2
HWg-WLD
WLD2
IP WatchDog Lite
IP WatchDog Industrial

Up to 8 remote outputs can be connected to a Poseidon2 or a Damocles2 and then controlled just as if they were local outputs. Before using remote outputs, it is necessary to configure IP parameters; therefore, unconfigured outputs are Disabled by default. Virtual outputs cannot be connected to devices without local outputs.

After enabling, it is possible to configure the output name, IP address of the remote device, ID of the remote output (can be found at the Outputs tab), and also a username and a password if the remote device requires authentication (“Read only + Outputs” or “Read + Write” access level).

The virtual output then appears as another output at the Outputs tab, where it can be controlled just as if it was a local output. This makes it possible to control outputs at multiple devices through a single WWW interface and with a single authentication username and password.  

The main advantage is that the remote output is set to the proper state periodically; if there is a power outage at the remote device’s site, the output will be again set to the correct state when the power is restored.

To be able to switch the output on/off for a short time only (power cycle), simply fill out the Pulse Timer parameter. Then, the output state is changed in response to the condition only for the defined time.

For more information about the Virtual outputs function, see the Virtual outputs in Poseidon2/Damocles2 application note at: https://www.hw-group.com/support/virtual-outputs-in-poseidon2damocles2

Activating an output using a condition from another device (on/off or pulse)

The option to control outputs using conditions from another device extends the ways in which multiple Poseidon2 and Damocles2 units can communicate. It uses the Virtual Outputs function in Poseidon2 and Damocles2 units. This function allows connecting remote outputs of Poseidon2 and Damocles2 units to the WWW interface of another unit. It is configured at the Virtual Outputs tab.

Support of Virtual outputs in HW group devices

Local Condition	Controlled	Poseidon2 3268	Poseidon2 4002	Poseidon2 3468	Damocles2 MINI	Damocles2 1208	Damocles2 2404	Ares12	SD-2xOUT	IP WatchDog2 Lite	IP WatchDog2 Industrial
Controlling
Poseidon2 3266
Poseidon2 3268
Poseidon2 4002
Poseidon2 3468
Damocles2 MINI
Damocles2 1208
Damocles2 2404
Ares12 (LTE)
HWg-PWRxx
SD-2x1Wire
SD-2xIn
SD-WLD
HWg-STE Plus
STE2
HWg-WLD
WLD2
IP WatchDog Lite
IP WatchDog Industrial

Up to 8 remote outputs can be connected to a Poseidon2 or a Damocles2 and then controlled just as if they were local outputs. Before using remote outputs, it is necessary to configure IP parameters; therefore, unconfigured outputs are Disabled by default. Virtual outputs cannot be connected to devices without local outputs.

After enabling, it is possible to configure the output name, IP address of the remote device, ID of the remote output (can be found at the Outputs tab), and also a username and a password if the remote device requires authentication (“Read only + Outputs” or “Read + Write” access level). The virtual output then appears as another output at the Outputs tab, where it can be controlled just as if it was a local output.

The main advantage is that the remote output is set to the proper state periodically; if there is a power outage at the remote device’s site, the output will be again set to the correct state when the power is restored.

To be able to switch the output on/off for a short time only (power cycle), simply fill out the Pulse Timer parameter. Then, the output state is changed in response to the condition only for the defined time.

For more information about the Virtual outputs function, see the Virtual outputs in Poseidon2/Damocles2 application note at: https://www.hw-group.com/support/virtual-outputs-in-poseidon2damocles2

Activating an output using a condition in the SensDesk portal (on/off)

Activating an output of a remote unit using a SensDesk condition is one of the highest feats in terms of cooperation and communication among multiple devices (M2M mode). It requires cooperation not just among devices of the same family, but also among different devices that do not share a common communication protocol other than HWg-PUSH to communicate with the SensDesk portal.

Support for controlling outputs using SensDesk conditions

Push protocol	Controlled	Poseidon2 3268	Poseidon2 4002	Poseidon2 3468	Damocles2 MINI	Damocles2 1208	Damocles2 2404	Ares12	SD-2xOUT	IP WatchDog2 Lite	IP WatchDog2 Industrial
Controlling
Poseidon2 3266
Poseidon2 3268
Poseidon2 4002
Poseidon2 3468
Damocles2 MINI
Damocles2 1208
Damocles2 2404
Ares12
SD-2x1Wire
HWg-PWRxx
SD-2xIn
SD-WLD
HWg-STE Plus
STE2
HWg-WLD
WLD2
IP WatchDog Lite
IP WatchDog Industrial

At this time, the functionality for output control conditions in SensDesk is still being developed. For this reason, it is not very comfortable yet because the user needs to know the SensDesk ID of the controlled output. The easiest way to find it is to look at the URL of the output:

The condition is then created by editing the sensor on which the output should depend. First open the details of the sensor, switch to editing mode, and under Email & SMS alerts find the Simple set output alarm item. There, enter the ID of the output to control in the Recipient field.

The condition becomes active as soon as it is saved by clicking Save:

From this moment on, whenever the sensor goes into the Alarm state, the remote contact is closed. Likewise, when the sensor returns to the Normal state, the remote contact opens. Loss of communication with the sensor is treated as an Alarm and the remote output is closed.

To delete the condition, go again to the Edit Sensor page and check the Delete box next to the rule to delete. Confirm by clicking Save.

For more detail about the control using conditions, see the separate Activating a remote output using a SensDesk condition application note at: https://www.hw-group.com/support/activating-a-remote-output-using-a-sensdesk-condition

Support for controlling outputs using SensDesk conditions

Push protocol	Controled	Poseidon2 3268	Poseidon2 4002	Poseidon2 3468	Damocles2 MINI	Damocles2 1208	Damocles2 2404	Ares12	SD-2xOUT	IP WatchDog2 Lite	IP WatchDog2 Industrial
Controling
Poseidon2 3266
Poseidon2 3268
Poseidon2 4002
Poseidon2 3468
Damocles2 MINI
Damocles2 1208
Damocles2 2404
Ares12
SD-2x1Wire
HWg-PWRxx
SD-2xIn
SD-WLD
HWg-STE Plus
STE2
HWg-WLD
WLD2
IP WatchDog Lite
IP WatchDog Industrial

Relay output reaction time

All products connected to the SensDesk portal communicate at least once every 15 minutes. This saves network traffic (and money in case of GSM communication) but means that a relay output needs 0.1 to 15 minutes to react. That's far from convenient, and so we have introduced the CheckPeriod setting (CheckPush function) that can be activated from the SensDesk portal for any product with digital outputs.

The CheckPeriod function shortens the reaction time, in which the relay output at the remote device switches, to 0.1 to 60 seconds.

What outputs can be controlled

Digital outputs (DO) of Poseidon2, Damocles2 or other devices can be linked to a local condition. An output can be controlled by the “Thermostat” local function (e.g. to turn on a fan when the temperature exceeds 30°C). Such a DO cannot be controlled remotely (remains read-only).

Only outputs in the “Manual” mode (with no conditions or triggers) can be controlled from the SensDesk portal.

At this time, the functionality for output control conditions in SensDesk is still being developed. For this reason, it is not very comfortable yet because the user needs to know the SensDesk ID of the controlled output.  The easiest way to find it is to look at the URL of the output:

The condition is then created by editing the sensor on which the output should depend. First open the sensor, switch to editing mode, and under Email & SMS alerts find the Simple set output alarm item. There, enter the ID of the output to control in the Recipient field.

The condition becomes active as soon as it is saved by clicking Save:

From this moment on, whenever the sensor goes into the Alarm state, the remote contact is closed. Likewise, when the sensor returns to the Normal state, the remote contact opens. Loss of communication with the sensor is handled as an Alarm state and the remote output is closed.

To delete the condition, go to the Edit Sensor page and check the Delete box next to the rule to delete. Confirm by clicking Save.

Plans for future development include a JavaScript menu to avoid manual entering of the output ID, as well as repeated setting of the output state for as long as the condition is valid.

CheckPeriod: Shortened output reaction time

In order to shorten the time it takes for the outputs of a device to react to SensDesk requests, the CheckPush function was introduced. It is activated with the CheckPeriod option that is set to 60s. This faster communication mode is configured in SensDesk individually for each device. CheckPeriod only applies to outputs. It does not shorten the update period for sensor readings or input states.

In monitoring systems, measured data need to be shared in order to quickly react to changes. There are many monitoring units on the market that can measure any physical quantities. A universal protocol, such as MQTT, is needed when the measured values have to be shared with other devices or third-party systems. MQTT in particular is, thanks to its strengths, nowadays integrated by most producers of advanced IoT devices and applications. To demonstrate these advantage, let us take Poseidon2/Damocles2 devices and a Raspberry Pi as examples.

Poseidon2 family- in addition to measuring temperature, humidity or light intensity, these devices can also detect flood or absence of water, measure air flow, and more. They can send e-mail notifications and upload the measured values to a computer or to the dedicated SensDesk portal, where the data is displayed in easy-to-understand charts accessible from any computer, tablet or mobile phone over the Internet.

Damocles2 family devices provide lots of digital inputs for connecting dry contacts (e.g. 24 inputs in the 2404 model). All digital inputs feature S0 pulse counters with a memory to connect water, gas, electricity or other meters. Digital inputs can also monitor the opening/closing of doors or windows. For instance, a slightly open freezer door can cause lots of problems. When combined with a motion detector, the system can also alert to unwanted visitors. Built-in pulse counters help provide an overview of the total energy consumption at the monitored premises.

 

Both product families can share the measured values over MQTT. MQTT compatibility allows connecting to IoT Hub, MS Azure, AWS IoT, Bluemix Internet of Things and other cloud services and third-party systems.

MQTT: Basic idea

In IoT systems, the sensors should not decide what to do. Sensors should simply send the results of their work to a central location, and nothing more. Whoever needs these messages then subscribes to them, can process them and respond. For example, a second layer can be added where a relay reacts to switch on/switch off requests. A switch can notify that it has been switched, a temperature sensor can inform about the measured temperature, and the central location forwards all this information to the respective subscribers. This makes it easy to react to changing application requirements and to add functions, such as switching a relay with a delay or remapping physical devices to work in a more logical way.

 

History of MQTT

At the beginning, when thinking about a protocol to use for communication, HTTP was a unanimous choice. Everyone knows it and it is common world-wide. However, it became apparent that HTTP had many disadvantages for the Internet of Things. There is a lot of communication and the implementation is complicated. Moreover, the HTTP protocol is based on the “request-response” paradigm; so, various workarounds, such as long polling, heartbeat, HTTP/2, and so on, are needed for server-initiated communication. There are no QoS levels, and two HTTP devices always need a server application to enable mutual communication because a HTTP server alone cannot pass data between clients.  For these reasons, a binary version - CoAP - was developed to simplify implementations in MCUs. It reduced the data volume by replacing text headers with binary flags. However, with optional extensions, CoAP also become bloated, losing its main advantage.

For these reasons, the MQTT protocol (formerly: Message Queuing Telemetry Transport, now: MQ Telemetry Transport) was created. It is a simple and lightweight protocol for passing messages between clients through a central point – a broker. Thanks to these characteristics, it can be easily implemented even in devices with simple microcontrollers, and quickly became popular. It was designed by IBM and is currently maintained by the Eclipse foundation. Recently it has become an OASIS standard.

In principle, MQTT is based on the exchange of messages between clients through a central server – the MQTT broker. Messages are transferred over TCP using a Publisher – Subscribers structure. Messages are divided into “topics”; a device may either “publish” a given topic, i.e. send data to the MQTT broker, or “subscribe” to the topic to receive the data.

Theoretically, a client can be a publisher and a subscriber at the same time; however, these functions are usually separated. A publisher is usually a sensor or a measuring device that sends the measured values to the MQTT broker, while a subscriber is usually a control unit that receives (subscribes to) the values for further processing or visualization.

Message content

The message content is not defined in any way. It is simply any binary data that need to be passed on. The most common data formats include JSON (JavaScript Object Notation), BSON (Binary JSON) or plain text. Still, the format is not restricted in any way since MQTT does not process the data, only passes them on. It is solely up to the subscriber to “understand” the data. In the current protocol version, the message size is limited to a little less than 256 MB; however, because of the focus on “Internet of Things”, most messages are much shorter.  One of the aims of MQTT is to minimize the data volume. There is only a minimum of overhead.  MQTT is therefore suitable for occasional transfers of information and values, where transfer speed is not critical – ideal for IoT purposes.

Data transfer model

The MQTT protocol by itself only specifies the message structure but does not define the data transfer method. For this purpose, it uses the common TCP/IP protocol over a common Ethernet LAN or over the Internet. MQTT is at the application layer of the OSI model. Thanks to the simple structure and the use of the common Ethernet interface, MQTT can be easily implemented in devices with low-power, low-performance processors and is quickly becoming widespread. For the same reasons, it is quickly becoming popular in industry; MQTT can be relatively easily implemented into PLCs already equipped with a TCP/IP interface (Ethernet and RJ-45 jack) without any modification of the CPU unit hardware. 

For the message transfer, MQTT defines three QoS (Quality of Service) levels of message acknowledging:

• The lowest “QoS 0” level means that a message is sent without an acknowledgement and delivery is not guaranteed (at-most-once).
• The middle “QoS 1” level means that the message is delivered at least once.
• The highest “QoS 2” level means that every message is delivered exactly once.

However, a client need not support all three QoS levels; the MQTT protocol does not prescribe that. 

Security

The MQTT protocol by itself does not enforce or require any security. It is up to the client or device manager to decide whether or not to implement encryption. Therefore, it is advisable to be careful with public brokers and applications, especially from suspicious or unknown sources. When a public broker is used for the data, there is no effective control over other brokers that might, even temporarily, connect to it.

Security is generally ensured in closed networks or IT systems. To secure the transferred content, MQTT offers several options. Each communication between the client and the broker begins with the client logging in (“CONNECT” mode). In the login sequence, the client is identified with its “ClientID” and optionally with a “Username” and a “Password”. If the client capabilities allow, it is suitable to set the “ClientID” to a simple string that identifies the device well and helps keep an overview about the network.

Thanks to SSL/TLS support, MQTT supports logging in using a client SSL certificate. Supported protocols include TLS v1.2, v1.1 or v1.0 with x509 certificates. It is important to keep in mind that the MQTT protocol is purely text-based; without SSL/TLS, the communication is completely open (and the password is the primary concern).

Depending on the desired security level, the MQTT protocol prescribes the following TCP channels:

• 1883 = unencrypted MQTT - basic and most common MQTT communication channel; the communication is not encrypted in any way (including the password, which is sent in the open). This channel should not be used for any sensitive data.
• 8883 = encrypted MQTT - unlike the 1883 channel, data are encrypted using the SSL/TLS protocol, and client-side support is needed to establish the connection.
• 8884 = encrypted MQTT + client certificate - this is the highest level of security available for MQTT communication; in addition to the data being encrypted using the SSL/TLS protocol, the client must authenticate itself with a certificate issued by the broker. However, so far this channel is only supported by a handful of public brokers (e.g. Mosquitto - “test.mosquitto.org” server).

Simple MQTT setup

Poseidon2 and Damocles2 devices (external link) already have this protocol implemented and the setup requires no programming experience. Simply enable MQTT support in the device, set the MQTT broker’s IP address, username and password, and select the connected sensors to publish to the MQTT broker. The previous description makes it clear that a topic to publish (and to subscribe to at the other end) needs to be selected. A MQTT broker can be chosen from this list: https://github.com/mqtt/mqtt.github.io/wiki/public_brokers (external link). With a single click, the communication can be secured with SSL.

Sharing data with other devices and systems

MQTT can send data to IoT Hub, MS Azure, AWS IoT, Bluemix Internet of Things and other clouds. The setup is very simple, see this article for a description.

MQTT ensures interoperability of otherwise very different devices. Thanks to MQTT’s popularity, numerous libraries are available to facilitate the implementation in various processors. For example, Digikey offers instructions on how to implement MQTT in Raspberry PI 3 with ESP8266. The combination of HW Group products with Raspberry Pi is an effective system where Poseidon2 and Damocles2 take care of sending sensor data to the broker, and the Raspberry Pi reads, processes, and acts upon the values.  The result is a professional application at the measurement side, and the customer can focus on the application part.

There are two new options how to get the file values.xml

1. At http://sensdesk.com/sensdesk/team/TEAM_ID/values.xml after login with username and password
2. At http://sensdesk.com/sensdesk/values.xml?values_xml_key=YOUR_VALUE.XML_KEY

In both cases is for getting file values.xml an important page/sensdesk/team/ from the main menu using the Teams tab.

• You can find TEAM_ID in the address bar
• YOUR_VALUE.XML_KEY is listed on the values.xml key line

Change the XML format

In the <Agent> section, there is a new <Team> tag that identifies the Team to which Values.xml belongs.

A relay is generally characterized by its rated coil voltage for operating the contacts, and the maximum switching voltage and current that the contacts are designed for and guaranteed by the manufacturer (in terms of the minimum number of switching cycles).

If the relay is already built into a device, such as a programmable control unit, we are mainly interested in the maximum switching voltage and current of the outputs (contacts). However, there is usually a mention that these values are given for a resistive load. This is a well-intended warning from the manufacturer to prevent contact destruction.

Contact load

The effects occurring at a relay contact depend greatly on the size and type of the load, the current, the contact size and material, the operate time and the contact bounce. 
For DC loads, the maximum switching current is usually lower than for AC loads. While AC current periodically drops to zero, DC current does not; therefore, in the DC case, any electrical arc ignited when the contacts are pulled apart is very difficult to suppress. The arc discharge lasts longer in a DC circuit compared to an AC circuit. Hence it is important to distinguish in the datasheet between the maximum switching load specifications for DC loads and for AC loads.

In addition to the rated load voltage and current (i.e. steady-state values), the relay lifetime is also greatly influenced by the inrush current and switch-off spikes that occur when the load is connected/switched on or disconnected/switched off. For capacitive and inductive loads, these can be orders of magnitude higher than the rated values, and an undersized relay or a lack of the appropriate limiting circuitry can easily result in destroyed contacts.   

Switching a resistive load

When a purely resistive load is connected to the relay output, the entire allowed range of voltage and current can be used without any problems. A resistive load is defined as a device with its inrush and switch-off currents equal to the steady-state values. That is, a load whose electrical resistance is always the same and does not change in time; therefore, the current is also constant from the switch-on moment to the switch-off moment.

Usually, only resistors – purely resistive components designed for this particular purpose – exhibit this behavior. However, even devices that do not exhibit a constant resistance can be regarded as resistive loads, provided that their resistance only changes slowly with time.

Devices that mostly behave as resistive loads include:

• Incandescent bulbs
• Various LED lights
• Heating elements
• Voltage inputs of measuring instruments (multimeters, oscilloscopes, PLCs etc.)

The above examples of resistive loads do not necessarily exhibit a truly constant electrical resistance (it may change somewhat over time); however, if the relay contacts are appropriately oversized (approximately 2x to 4x), they do not usually cause any problems or contact damage.

Switching a capacitive load

 In contrast to a resistive load, the situation is entirely different with a capacitive load. When a capacitive load is connected to a power source, it starts to draw a very large current that quickly decreases. Therefore, when a capacitive load is switched on, there is a large inrush current that can significantly exceed the maximum allowed switching current of the relay contacts. When the capacity of the load is completely discharged, this inrush current is only limited by the parasitic resistance between the contact and the capacitive load. As the load charges, the current decreases.

For the relay, the switch-on moment is the biggest problem: the contacts carry the highest current and can be even welded together if this current exceeds the allowed maximum even for a short time. Remember that in a circuit with a capacitor, the inrush current can be 20x to 40x higher than the steady-state current.

The significance of inrush currents can be demonstrated by the “Inrush current” values in the technical specifications of switching power supplies or other appliances. Even with a small switching power supply or power converter (e.g. with an output power around 30W), the inrush current can reach tens of amps (32A is no exception). This kind of current can be drawn by a completely discharged (that is, disconnected for a long time) power supply for up to 100ms after being powered on. Since the current quickly drops to the rated value afterwards, the inrush current is not significant from the long-term perspective. However, its effect can be observed when a switching power supply (or a device containing one) is connected to an undersized circuit breaker: when the device is turned on, the circuit breaker may often trip. It is also common to observe the inrush current effects as sparks (sometimes quite prominent) when a switching power supply that has been disconnected for a long time is plugged in to an electrical outlet.

Ideally, the maximum switching current of the relay contacts (or any switches in general) should be close to the specified inrush current, or the inrush current should be limited.

Examples of devices that behave as a capacitive load:

• Switching power supplies – the higher the power output, the higher is usually the inrush current
• Long transmission lines or cables – due to the parasitic capacities between the wires in cables longer than about 10m
• Various voltage filters – e.g. loudspeaker crossovers
• The inrush current of capacitive loads can be reduced by connecting various elements in series with the load:

Connecting a resistor / NTC thermistor: the inrush current is reduced thanks to the voltage drop at this element (the voltage at the capacitive load increases gradually, not suddenly). However, there are additional losses in the steady state.
Connecting a choke (inductor): the inrush current is compensated (reduced) and, at the same time, there are no big steady-state losses (the choke exhibits only a small wire resistance).

Switching an inductive load

The biggest “enemy” of a common relay is an inductive load, such as a solenoid or an electromagnet. Its behavior is the most damaging, capable of completely destroying (welding or burning) the relay contacts. It behaves in the opposite way compared to a capacitive load. The switch-on effects are not a problem; the current increases gradually up to the rated current specified for the component (during this time, the inductive load behaves as a choke).

However, the problems come when the relay contacts open and the inductive load is disconnected. Due to the underlying physics principle, the inductive load tends to maintain the same current that was flowing through it before the disconnection. To this end, a voltage of the magnitude and polarity necessary to maintain this current is temporarily induced at the terminals of the inductive load.

Therefore, when an inductive load is switched off, there is a voltage spike that can damage the load itself (winding insulation) as well as the contacts of the disconnecting relay. The voltage spike is influenced by the inductance (the higher the inductance, the higher the voltage spike) as well as the switch-off time and method. The switch-off spike is the highest when a device is quickly electronically disconnected (snap-action) and there is no spike-limiting circuitry. The effect is especially adverse in case of high inductances, higher supply voltages and higher duty cycles (the ratio of electromagnet on-time to the cycle period). In practice, voltages of up to 30x the rated supply voltage (or switched voltage) are common.

When the inductive load is snap-action disconnected by opening relay contacts, the lack of limiting circuitry can lead to generated voltages of hundreds of volts, able to ignite an electric arc between the contacts. This is a “reliable” way to damage or even permanently destroy the contacts.

Examples of devices that behave as inductive loads:

• Solenoids / electromagnetic valves
• Electromagnets
• Electromotors
• Transformers
• Fans
• Relay coils

Surges can be limited by connecting various electrical components in parallel to the inductive load in order to shunt the switch-off spike voltage generated at the inductive load (coil) terminals:

• A diode and a resistor (for DC circuits) – the diode as well as the resistor need to be sized according to the switching frequency, spike voltage and the load input power. The diode breakdown voltage must be higher than the circuit supply voltage, and the maximum forward current must be higher than the current through the load (inductor) when switched on.
• A “spark quenching capacitor” (for AC circuits) – a RC circuit connected in parallel to the contact, where R = RL a C = L/RL2
• A circuit with two Zener diodes or a transil – the Zener diodes or the transil clamp the spike voltage to the specified threshold voltage. A disadvantage is that in case of overload, they fail and remain permanently open, shunting the load.
• A varistor circuit – a voltage-dependent resistor connected in parallel to the load and satisfying the condition 2 < Umax/Uj < 4 (where Umax is the varistor voltage, Uj is the supply voltage).

Various ways to protect relay contacts from the effects of switching an inductive load – from left to right: a diode, a spark quench capacitor, Zener diodes or a transil, a varistor.

Conclusion

The conclusion is that a switched load does not always follow the rated current and voltage specifications. These are only valid for resistive loads / appliances, which, in practice, are the exception rather than the norm. Therefore, the relay (or other) contacts should be always adequately oversized (with respect to the switched voltage and expected current), and the load should be equipped with additional circuitry depending on its behavior – that is, whether the load is generally capacitive (filters, switching power supplies) or inductive (solenoids and electromagnets). For some devices, the specifications indicate the maximum contact load as “Maximum switching current 16 (4) A, 250 V~”. In this case, 16A is valid for a resistive load, 4A for an inductive load.

If the capacitive or inductive load lacks the appropriate limiting circuitry, it can easily damage or destroy the relay as well as the control device where the relay is integrated – sensor, PLC, remotely controlled unit, etc.