Which Enless wireless sensor should I get?

We summarize here some aspects about the main options available to get sensor data over wireless using the Enless range

At Innon we partnered with Enless Wireless in France to provide you with the best wireless solutions.

We tried many different wireless products and came to the conclusion that wireless shouldn't be an alternative option to hard wiring devices, it should be instead a "unique" option, designed for situations where wires are not going to cut it.

Wireless sensors make the most sense when you have no wire at all (power is provided using a battery) and the network wouldn't be achievable with wires, either because of the costs or because it is not manageable all together. This leads to many design considerations where the reading speed is not a main priority anymore, but the priority shifts into having a long lasting battery and a low data/low power protocol.

This is where IoT (Internet of Things) shines. Interconnecting devices with little human intervention over wireless is one of the key goal in this market.

And if in the domestic world short range devices implementing zWave and Zigbee play a significant role, in a more robust and professional network such devices present huge limitations such as short battery life, communication reliability, lack of standard integrations etc. In most cases this makes the use of wired devices much more appropriate.

But IoT includes also technologies that are really interesting and can open the door to solutions that would be otherwise not achievable using a typical BMS application. Within the long range wireless solutions, IoT includes things like Sigfox, LoRa WAN, LoRa and wireless MBus.

In this article we will help you understanding the differences, why we believe these options became really interesting to us and what could be the best suited solution for your system.

General considerations

The wireless solutions we are going to explore in this article have a few things in common which is worth mentioning.

1) they are designed to have long lasting batteries. Even in the worst case scenario, these are sensors where the batteries will last from a minimum of 2 years up to over a decade, depending on the protocol and transmission frequency. The idea is that despite the battery, you can count on a reliable solution that will require low maintenance

2) they are long range wireless devices. We will see how this applies to the different technologies, but these sensors do not lose signal just across the room. These networks take advantage of low bandwidth/low frequency to push data much further than the usual wireless solution, with extreme cases of miles of open air installation coverage

3) they usually work only in one direction (read only) where the sensors "transmit" data to a receiver. Also, data is usually transmitted at relatively long intervals, normally configured between 5 to 30 minutes between transmissions, with the sensors more power hungry electronics going into a sort of "sleep" state in between, guaranteeing the best battery longevity

4) no matter the technology you might choose, you will find the same sensor types and almost identical look for each option. The technology decision is driven primarily by the type of install solution you are planning for the sensors, that being integrating with a BMS or directly to cloud, for example

 

Typical look of an indoor sensor

Typical look of outdoor/harsh environment sensors

 

Typical look of energy metering devices

 

Typical look of gateways and repeaters for local solutions

A summary of the solutions available

We are going to provide more details on each option later in this article, but to summarize:

 

Let's have a deeper look into each option

Note: find all the downloadable material on our wireless sensors on our SUPPORT WEBSITE.

Wireless MBus

Summary

Designed for local installation and to interface with a BMS system over Modbus RTU through a dedicated gateway, it is the best performer indoor.

The low frequency used by this protocol (169MHz) allows the best walls penetration between them all. This means that few access points are required to cover a building. Real world tests in our office space at Innon and my block of flats have shown communication working between a sensor and a receiver across around 4 floors without an access point. This obviously doesn't account for hard environments with a lot of noise (inverters, data centers, etc). Tests should be carried out in the specific environment where the solution is going to be installed.

The sensors transmit all to a receiver (gateway), which then relays the information over Modbus slave RS485 or RS232. 

The configuration of the network is all done on the gateway over USB, using a dedicated software called FCT. The software is usable by a "high skills" electrician or easily by a BMS engineer, it does require some minimum amount of learning.

Repeaters do not require any configuration and have got no limits in the amount of transmitters they can repeat.

Only the receiver (gateway), the repeaters and the specific Modbus to MBus transmitter require DC power, all the other transmitters are battery powered.

The best use case and main strength of this solution is probably the installation within the same building and it makes it a good option for large buildings, but transmission across separate buildings can also be achieved using access points.

Battery life is quite long with sensors averaging a 5 years battery life with transmission every 5 minutes (transmission frequency configurable for even longer lasting battery life).

The gateway and entire network is designed to work only with Enless Wireless MBus sensors, no third party sensors are supported.

Network topology

Large building, few repeaters needed.

Blue background: receiver (gateway) and access points

Green background: meter sensors

Yellow background: temperature, humidity, CO2 sensors

 

LoRa

Summary

It is also called LoRa "private mode". It uses the LoRa sensors range configured in "private mode" and works in a very similar way to Wireless MBus: it requires a gateway (receiver) that translates all the transmitters (sensors) data into Modbus RTU or BACnet IP (future dedicated receiver).

Though it performs well indoor, it doesn't penetrate walls in the same way the MBus range does, due to the higher frequency used (868MHz in Europe, 915MHz Australia and North America, 865Mhz to 867MHz India, 923MHz Asia). In real tests made in our Innon office space, we were able to achieve about 60% wall penetration compared to Wireless MBus, so about 2 to 3 floors (which is still really good).

It is a viable solution indoor and compared to Wireless MBus it might just need a few more repeaters.

It does cover extremely long distances outdoor, and that allows to easily create a network between buildings.

It doesn't require a software to be configured, it is configured using a web browser connecting directly with an ethernet cable to the receiver. This makes it configurable by "less skilled" engineers compared to Wireless MBus.

Repeaters do not require any configuration and have got no limits in the amount of transmitters they can repeat.

Sensors can be configured to use this mode or the LoRa WAN (see the next section on this article) using a physical jumper inside the sensor.

Only the receiver (gateway) and the repeaters require DC power, the transmitters are battery powered.

Battery life is quite long with sensors averaging a 5 years battery life with transmission every 5 minutes (transmission frequency configurable for even longer lasting battery life). It does exceed slightly the battery life of the Wireless MBus range though, with some sensors ranging higher.

The gateway and repeaters are designed to work only in LoRa "private mode". Also, you can only use Enless LoRa sensors, no third party LoRa sensors are supported in "private mode".

Network topology

Average buildings, perfect for networking between buildings.

Blue background: receiver (gateway) and access points

Green background: meter sensors

Yellow background: temperature, humidity, CO2 sensors

 

LoRa WAN

Summary

LoRa WAN uses the same sensors used for the "private mode" LoRa. Swap the setting of a jumper within the sensor and this mode will be activated.

LoRa WAN is a wireless network that does not integrate (at least locally) with a BMS: it relies on network operators to create a network of LoRa receivers that will take care of receiving the data of the sensors within range and transfer it using an internet connection (wired or mobile) to a cloud based system.

Websites like LoRa Alliance give some broad information on the network operators that can offer the connectivity. APIs to the cloud service will allow cloud-cloud data transfer, the development of dashboards, data analytics etc. Third party services are also available to be purchased for the scope (look up for "LoRaWAN dashboard" or "LoRaWAN IoT Platform" on Google and you will get a long list of links with instructions to create basic dashboards and links to third party companies).

You can also get in touch with us to discuss about the cloud solution and portal: we work with our clients and partners to make sure you get a solid and easy to use full packaged solution.

LoRa WAN is made for scale and to be easy to install. The expectation is to get the minimal amount of work to perform on site, and transfer the setup of the system to a remote server, which is done usually by IT and software engineers. This makes the system more suitable for large scale projects of small sites monitoring.

The Enless receiver and repeaters will not work in this mode. If the sensors (transmitters) are not able to reach the network operator receiver (gateway), the network operator will most likely be able to recommend a standard LoRa WAN repeater or will be probably able to install a specific local receiver.

From our tests indoor, the wall penetration is quite good due to the frequency used (868MHz in Europe, 915MHz Australia and North America, 865Mhz to 867MHz India, 923MHz Asia). Signal quality though will primarily depend on the position of the network operator receiver.

Battery life is quite long with sensors averaging a 5 years battery life with transmission every 5 minutes (transmission frequency configurable for even longer lasting battery life), with some sensors ranging higher.

The activation and configuration of the sensors (like the time between transmissions) is made remotely using downlink commands, no action is required on site (except from plugging in the internal battery to get the configuration and power the sensor).

Network topology

Smaller buildings, ideal for districts and scale installations.

Blue background: receiver from LoRa network operator

Green background: meter sensors

Yellow background: temperature, humidity, CO2 sensors

 

Sigfox

Summary

Sigfox (https://www.sigfox.com/en) is a wireless network that does not integrate (at least locally) with a BMS: it relies on selected regional network operators to create a network of Sigfox receivers that will take care of receiving the data of the sensors within range and transfer it using an internet connection (wired or mobile) to the Sigfox cloud based backend (https://backend.sigfox.com/).

The network operator (WND Group in UK, for example) will provide network coverage. Accessing the Sigfox backend, a detailed Service Map is available to verify accurately the network coverage in specific areas.

The network operator can install additional receivers (gateways) in the area if not covered and they usually pay a small periodic fee to the building owner for giving access to such service. Local access gateways are also available to cover indoor installation with no required setup (it requires internet access to push data to the cloud).

APIs to the Sigfox backend service will allow cloud-cloud data transfer, the development of dashboards, data analytics etc. Third party services are also available to be purchased for the scope (look up for "Sigfox dashboard" on Google and you will get a long list of links with instructions to create basic dashboards and links to third party companies). Full documentation on the Sigfox API can be found HERE. 

You can also get in touch with us to discuss about the cloud solution and portal: we work with our clients and partners to make sure you get a solid and easy to use full packaged solution.

Sigfox is made for scale and to be easy to install. The expectation is to get the minimal amount of work to perform on site, and transfer the setup of the system to a remote server, which is done usually by IT and software engineers. This makes the system more suitable for large scale projects of small sites monitoring.

From our tests indoor, the wall penetration is quite good due to the frequency used (868MHz). Signal quality though will primarily depend on the position of the network operator receiver.

Battery life is shorter than the LoRa alternative averaging 5 years battery life with transmission every 60 minutes for the ambient sensors and 5 years battery life with transmission every 20 minutes for the outdoor/harsh environment sensors (transmission frequency configurable for even longer lasting battery life).

The activation and configuration of the sensors (like the time between transmissions) is made remotely when adding the sensor on the Sigfox backend, no action is required on site (except from plugging in the internal battery to get the configuration and power the sensor).

Network topology

Smaller buildings, ideal for districts and scale installations.

Blue background: receiver from Sigfox network operator

Green background: meter sensors

Yellow background: temperature, humidity, CO2 sensors