Monitoring

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.

The HW group solutions has a number of common features:

• Immediate availability of measured data in applications
• Warning and alarm functions
• Deployment of devices in IT infrastructure and industry
• High level of data security
• Support for a wide range of software applications and platforms
• Remote control and management of devices
• These features require a reliable, stable connection with a high level of security of transport and communications services, which today provide especially standards derived from Ethernet.

What can Ethernet, WiFi and others do?

Ethernet

Ethernet is known mainly as a standard computer network. For IoT is overlooked, because for many people, IoT is a matter of wireless. But a wireless solution brings issues of signal strength, interference, noise, radio standard compatibility and security. Ethernet, however, does not have any limits on speed, encryption, the volume of data transferred, and is therefore the first choice for Industrial IoT (IIoT) applications. Ethernet, in addition to data transfer, also provides power to the device feature (PoE - Power over Ethernet), which can facilitate power in a number of applications.

It should be added that conventional Ethernet by wire also has a number of wireless alternatives because other Networks use the same transport and communication protocols to fully replace Ethernet.

WiFi

WiFi or wireless Ethernet in most todays corporate buildings and public spaces represents standard. It allows high bandwidth and encryption security. For stationary applications where high power consumption is not essential, a reliable alternative to wired Ethernet. The default setting is more complex, but it can be solved in a number of ways.

GPRS / LTE

GSM, resp. GPRS is bit neglected interface in the world of IoT. IoT is considered to be a modern and progressive technology, while GSM for history, for those who want to use GPRS data on 3G or 4G Networks. But GPRS is a reliable interface, and if you do not require the transmission of dozens of MB data, it is completely satisfactory. Coverage is perfect in most countries, and although a number of operators have already been notified of this network being shut down and replaced by LTE Networks, GSM will still be there for some time. Under low costs can often have data in the order of dozens of MB per month for free. You can take advantage of the classic Ethernet, IP communication, such as http (s), so you do not have to open any special communication ports, SSL security, and so on. GSM represents a classic client / server communication, and if you use TCP / IP communication, it's also confirmed and you're sure the data arrived at the destination.

LTE is more interesting from IoT layman's point of view, but it is important to note variation among LTE standards, in combination with the IoT term abbreviation. At this point, when we write about LTE, we mean the TDD and FDD standards, which are referred to 4G Networks. That's the classic mobile phone network. It has the same benefits as GPRS, plus high bandwidth. These networks probably swap the classic GSM / GPRS in future.

Both GSM and LTE Networks are ideal for mobile applications because they are able to automatically re-register themselves to the strongest point without loss of connection automatically when in motion. This is a big advantage against Lora, Sigfox or LTE cat M1 / ​​NB-IoT. In addition, they allow you to send data to any IP address, that is, anywhere, and you are not bound to the cloud and therefore the operator's application.

While GSM / GPRS Networks are unified across the globe (or there are 4 standards that can be met by one device), the situation in LTE Networks is more complex, and it is often necessary to use different devices with regional bandwidth and protocol variation.

LTE cat M1/NB-IoT

NB-IoT (Narrowband) is a subset of LTE cat M1. Both networks benefit from IP protocol, making it easier to use than Lora or SigFox.

While NB-IoT is designed exclusively for IoT devices and has a very limited bit rate (<250 kbps for download and <20 kbps for upload), as well as the volume of data being transferred. The bandwidth is 200 kHz. There is also limited switching between the connection points, because as long as NB-IoT has at least some connection, the data message is sent. But as the communication is mostly conducted after a UDP / IP unverified protocol, data is lost easily in mobile network. Therefore, NB-IoT is primarily suitable for stationary applications with extremely high energy efficiency requirements.

LTE cat M1, as opposed to NB-IoT, supports voice Voice Over LTE (VoLTE) and has a transfer rate of up to 1MB /s. In addition, Cat M1 allows you to switch from one wireless cell to other, so it's suitable for mobile and mobile applications such as telematics and fleet management. Here, however, the data volume must be kept within the bandwidth and VoLTE is used more for voice messages than for calls.

If we considered LTE standard worldwide different, the NB-IOT, and LTE cat. M1 are more complex. There are a few more standards. Fortunately, this is only a matter of physical layer editing, so the production of different models means just fitting other component and does not affect the application.

HW Group prepares IoT products based on NB-IoT, respectively. LTE cat.M1 for 2019, their application deployment is assumed in the industry. The big advantage of this technology is both a connection to the standard mobile network, where can be expected stable operation, as well as duplex communication without need of cloud storage provider. Customer can choose cloud application or storage to use. Their earlier deployment is hindered, in particular, by small network expansion and opaque pricing policy for operators.

What are the other technologies and their limitations?

LoRa / SigFox

These are two communication interfaces developed for simple IoT applications.

SigFox operates in the 868 MHz non-licensed ISM band (906MHz in the US), which covers unlicensed short-range technology, such as part of home weather stations, garage door control, but also wMbus, wireless sensor technology. This is related to the need to minimize costs. SigFox was designed intentionally as a lightweight protocol for small message transfer. Fewer data means less power consumption and therefore longer battery life. The baud rate is 100 or 600 bits / sec. 12 bytes of useful data (plus some overhead) are transmitted over 2 seconds.

LoRa is a reliable wireless technology that also uses the 868 MHz bandwidth, but the data rate is in the range of 0.25kbps - 50Kbps. The basic element of this technology is spread spectrum modulation, which makes LoRa resistant to interference. Other advantage of this technology is the two-way communication and the ability to switch between connecting points. A great disadvantage is the complexity of the setting parameters.

In both cases, data transmission is secure. Coding is performed on the application layer using AES128 and multi-bit authentication. Also, in both cases, transmission time is limited (ie 1% transmission time per hour - only 36s!) not only with low consumption but also with limited bandwidth. In both cases, one message may contain only a few tens of bits (not bytes!). It allows to send very short message types (light, off, fault, temperature transmission, but ne more complex reports or datalogs).

At the same time, for both types of networks, the criteria for transmission reliability are set to a different level than for standard Ethernet. While Ethernet is now operating with 99.9999 percent reliability criteria, LoRa and Sigfox have a default error rate around 5 percent. This is due to the limitation of broadcasting times and the possibility that the cell can be overwhelmed at the moment. The transmission error is not solved by the device, the data are broadcast at the next time slot. For applications for which both networks are designated, this level of reliability is sufficient.

These IoT Networks (along with NB-IoT or LTE cat M1) are also called Low Power WAN (Low Power WAN) LPWAN to emphasize low power consumption and therefore the ability to power from batteries and accumulators. The device achieves long-term battery life (5-10 years) based on the limitation of data transmission (eg. once per day).

In addition, thin communication protocol of LPWAN networks does not allow remote management diagnostics and setting of devices or sensors. Each sensor must be managed on site, almost battery powered low-cost sensors have not any space to modify operating parameters. These features move classic Ethernet based networks up not only for industrial and IT segments but also for all remote control applications.