Monitoring

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.

If you can connect to a device via the Web interface, you will find the Default tab on the System tab or Reset to Default, Load default, etc.

Using HWg Config (HWg-SMS-GW3, HWg-SH4, HWg-STE, HWg-STE PoE, HWg-STE Push, HWg-STE Push PoE, HWg-STE Plus, HWg-STE Plus PoE, STE2, IP Watchdog2 Lite, IP Watchdog2 Industrial)

• With HWg-Config, you can reset the device only 60 seconds after switching it on / restarting. Out of this time, the reset option is inactive. Disconnect the power-reset device and reconnect it.
• Open HWg Config and search for the device (the flag that the device can be reset is retrieved only when accessed, so if you search for a device before restarting, the option remains inactive)
• Click on the device and open the details in the setting. Press the Load to Default button

Or

• Select the device you want to reset and right-click to open the context menu. Select Load to Default

Using the DIP switch (Poseidon, Poseidon2 and Damocles2)

• Disconnect the power-reset device and reconnect it.
•  Within the 30s after reconnecting, change the DIP 1 - Setup status to 6 times (3 times by turning it on and off).

Using the DIP switch (IP WatchDog Lite, IP WatchDog HWg-WR02a)

• Disconnect the power-reset device and reconnect it.
•  Within the 30s after reconnecting, change the DIP 1 - Setup status to 6 times (3 times by turning it on and off).

Using the reset button (STE2 Units)

• Disconnect the device to be reset, from the power supply
• Press the Reset button and reconnect the power. Hold the button for another 3 seconds.

Using the reset button (HWg-PWRx Units)

• Press the Reset button (the cover sheet will need to be pierced) and Hold the button for 10 seconds..

Using  Short-circuit jumpers (Units HWg-STE, HWg-STE PoE, HWg-STE Push, HWg-STE Push PoE, HWg-STE Plus, HWg-STE Plus Poe)

• Disconnect the device to be reset, from the power supply
• Open the box and short-circuit SET ( place the jumper on both pins)
• Connect power and wait about 15 seconds. Now remove the jumper.
• Disconnect the device from the power and reconnect it.