How do we do this?
Once your Enless wireless sensors are communicating correctly, either with a local receiver or through a network provider, the next three questions are usually:
-
How do I know when the batteries need replacing?
-
How do I know if a sensor has stopped transmitting,
-
How do I know if the wireless link has been interrupted?
This article explains the main ways to monitor battery status and sensor activity across the different Enless wireless technologies.
Battery Monitoring
Battery information is available on Enless sensors, but the way it which it is presented depends on the wireless technology being used.
Wireless M-Bus
With Wireless M-Bus, battery status is available as a Modbus point.
You can view it in either of these places:
-
Field Installation software under Modbus Map
-
A CSV export from the same software
In the Modbus map, the battery value is typically shown as:
-
1 = Battery OK
-
0 = Battery LOW
A LOW Battery Status generally indicates the battery voltage has dropped below 3 V.
For example, in the Modbus export, the battery status may appear as a dedicated register such as:
-
Data Battery = OK when value = 1
If the battery becomes fully depleted and the sensor stops communicating, the battery point alone may no longer update. In that case, the best way to detect the issue is to monitor the sensor transmission timer, covered later in this article.
LoRa Private Mode with Enless Receiver
With LoRa sensors in private mode using an Enless receiver, battery information is available from the receiver as either:
-
a Modbus point, or
-
a BACnet point
This depends on the receiver model and integration method.
Modbus
On the receiver web interface, the battery information is included in a point called Status.
This is a 16-bit status word, and the battery level is encoded in bits 2 and 3. These two bits indicate one of four battery levels:
|
Bit value |
Battery level |
|---|---|
|
0 |
100% |
|
1 |
75% |
|
2 |
50% |
|
3 |
25% |
In practice, the status word must be decoded to determine the battery level.
BACnet
With BACnet, there is usually a dedicated point called Battery Level rather than a full status word.
The meaning is the same, but in this case the battery value is provided more directly. The battery level is represented using:
|
Value |
Battery level |
|---|---|
|
0 |
100% |
|
1 |
75% |
|
2 |
50% |
|
3 |
25% |
This makes BACnet integration simpler when you want to trend battery condition or trigger alarms.
LoRaWAN
With LoRaWAN sensors using a third-party gateway or a network operator, battery status is obtained by decoding the uplink payload.
A decoding guide is typically provided for each Enless sensor model. Once the frame is decoded, the battery information can be extracted from the relevant byte or bits in the payload.
The exact battery location and format depend on the transmitter model, so you should refer to the corresponding decoder document for that device.
For some models, the payload gives a direct battery state; for others, a specific nibble or bit field must be interpreted.
Sigfox
With Sigfox sensors, battery status is also available by decoding the data frame.
Depending on the product, the battery indication is commonly represented as:
-
1 = Battery OK
-
0 = Battery LOW
As with Wireless M-Bus, a LOW battery indication generally corresponds to a battery voltage below 3 V.
The exact position of the battery flag depends on the sensor type, so the correct payload decoding document should always be used for the specific model.
Detecting When a Sensor Stops Transmitting
Monitoring battery level is useful, but it does not always tell the full story. A sensor may stop reporting because of:
-
a flat battery,
-
radio communication issues,
-
interference,
-
receiver or network problems,
-
or the sensor being powered down or damaged.
The best way to detect this depends on the wireless architecture.
Sigfox and LoRaWAN via Operator
With Sigfox and LoRaWAN through a network operator, detecting missing transmissions is typically handled in the backend or cloud platform.
A common method is to create a rule that checks whether new data has been received within an expected time window. If no new message arrives after that period, the sensor can be flagged as offline.
This logic is usually implemented on the application server, dashboard, or cloud platform receiving the uplinks.
Wireless M-Bus
With Wireless M-Bus, each sensor provides a timer point that shows how long it has been since the last transmission was received.
You can find this point in:
-
Field Installation software under Modbus Map
-
or in a CSV export
Important detail:
-
the timer increases by 1 unit every 5 minutes
So the conversion is:
-
1 = 5 minutes since last transmission
-
12 = 60 minutes since last transmission
-
24 = 120 minutes since last transmission
This makes it straightforward to create an alarm in the BMS or PLC.
For example, if a sensor is expected to report regularly and the timer reaches:
-
12, you may treat the sensor as offline for 1 hour
-
24, you may treat it as offline for 2 hours
The threshold should be chosen according to the configured transmission interval of the sensor.
LoRa Private Mode with Enless Receiver
With LoRa private mode and an Enless receiver, the receiver provides a counter showing the time since last reading.
This can be viewed in the receiver web interface and exposed to the BMS through the available protocol points.
Important detail:
-
the counter increases in minutes
-
there is no scaling factor
So:
-
1 = 1 minute since last reading
-
60 = 60 minutes since last reading
This is easier to use than the Wireless M-Bus timer because the value is already expressed directly in minutes.
A typical alarm strategy would be:
-
define the expected transmission period,
-
allow a grace period,
-
trigger an alarm if the timer exceeds that threshold.
For example, if the sensor normally transmits every 10 minutes, you might alarm if no update is received after 30 or 60 minutes.
Recommended Monitoring Strategy
For the most reliable supervision, monitor both:
1. Battery status
Use the battery point or decoded payload to identify when the battery is approaching replacement.
2. Time since last transmission
Use the timer or last-seen counter to detect:
-
dead batteries,
-
lost communication,
-
receiver issues,
-
or devices that have gone offline for any reason
Using both checks together gives much better visibility than battery monitoring alone.
Practical Examples
Example 1: Wireless M-Bus
A sensor has:
-
Battery = 1
-
Timer = 3
This means:
-
battery is OK
-
last message was received 15 minutes ago
If the timer rises to 12, then no transmission has been received for 1 hour.
Example 2: LoRa Private Mode
A sensor shows:
-
Status = battery level 75%
-
Time since last reading = 1
This means:
-
battery is still healthy
-
the latest message was received 1 minute ago
If the counter rises to 90, the device has not been heard from for 90 minutes.
Example 3: Sigfox or LoRaWAN
The payload decoder shows:
-
Battery = 0
This means:
-
battery is low
If messages then stop arriving completely, the backend should raise a communication timeout alarm based on missing uplinks.
Key Points to Remember
-
Wireless M-Bus battery status is generally shown as 1 = OK and 0 = LOW
-
LoRa private mode battery level is available via Modbus status bits or a BACnet battery point
-
LoRaWAN and Sigfox battery monitoring require payload decoding
-
To detect a failed or silent sensor, monitor the time since last transmission
-
On Wireless M-Bus, the timer scale is 1 unit = 5 minutes
-
On LoRa private mode, the timer scale is 1 unit = 1 minute
Conclusion
Monitoring Enless wireless sensors effectively comes down to two simple checks:
-
battery condition
-
last transmission time
Battery status helps you plan maintenance before a device fails, while the transmission timer helps you identify sensors that have stopped communicating for any reason.
In most installations, setting alarms on both values in the BMS, PLC, or cloud platform is the most effective approach.
Other Resources & Customer Survey:
💬 Don't miss out! Follow the Forest Rock News channel on WhatsApp Click Here!
💬 We’d also love your feedback! Please take a moment to complete our quick Customer Survey
It only takes a minute and helps us serve you better!
IoT Devices for BMS, Automation & Smart Connectivity | Forest Rock