Lesson 2.8 - Standard Flows: Timers and Geofences

General timers are used to delay alarms. Like, if a door or window opens and isn’t closed again within a certain time, the alarm goes off. Same thing if the temperature passes a limit and doesn’t drop back down soon enough.

In this lesson, we’ll explore the standard flows. Since the Flow is not supported on the generic HTTP and MQTT integration it must be tried out with real device using a new connector such as LoraWAN. This put some constraints on especially the Geo Query flows since requires movement of the IoT nodes. There are some translators available that can be used to simulate movement of devices in and out of geofences but it is beyond the scope of this training.

Timers

To start using General Timers two items are required:

1. The General Timer Flow: This is a special Flow that after translator service has executed checks if a timer should be started or not. If the timer expires the IoT node will get an update.
2. The General Timer Translator or a customized variant of it: This is very similar to a normal Alarm Translator with built in alarm thresholds and hysteresis but instead of setting an alarm it controls the timer functionlality.

Common Use Cases

• Garage doors that don’t close automatically like they’re supposed to.
• People forgetting to shut doors or windows behind them
• Levels that are allowed to temporaryily passed a threshold but needs to go back within a certain time.
• Assets that are allowed to be inside or outside a geofence a certain time.
• Check if assets are in use or not by starting a timer when no movement detected.

Setting one up is pretty easy:

1. Change the Device Flow
   Set the flow of the device to general-timer., see flow for details.

2. Add a general-timer translator
   Add it via the Translator menu in the device settings, or apply it to multiple devices using Select Many.

3. Open Contextual Parameters
   Access contextual parameters either:

   • From the device menu, or
   • With Select Many → Edit

4. Configure the General Timer Parameters
   Below is a breakdown of the available parameters:

Parameter	Description
timerTriggerField	Field to monitor as a trigger (e.g., door, motion, temperature)
timerDelay	How long (in milliseconds) the trigger must remain active before the timer expires
timerBooleanTriggerValue	For boolean fields—set this to true or false depending on your logic
timerHighTriggerLevel	For numeric fields—this is the upper threshold
timerLowTriggerLevel	For numeric fields—this is the lower threshold
timerTriggerHysteresis	Adds hysteresis to avoid rapid toggling around the threshold

For instructions on how to create an Alarm Monitoring View, refer to the linked guide. Use the following fields:

• timerStart – Indicates whether the timer has been started.
• timerStartAt – The timestamp when the timer started. If no timer is running, this will be an empty string.
• timerExpired – Indicates whether the timer has expired. This is the primary "alarm" field used to trigger alerts.

Use a suitable sensor, such as a Sensative Strip with a magnetic contact, to test the timer functionality.

1. Set the trigger field to door and the timerBooleanTriggerValue to false.
2. Configure the timerDelay to 30,000 ms (30 seconds), then open and close the door to observe how the timer behaves. The timer should reset if the door is closed before the delay period expires.

Geofences

To start using Geofences two items are minimum required:

1. The General GeoQuery Flow: This is a special Flow that after translator service has executed checks if an IoT node is inside or outside geofences and if yes sends them an update event.
2. Geofences with reference IoT nodes with either the General Geofence Translator or a customized variant of it: This is very similar to a normal Alarm Translator with built in alarm thresholds and hysteresis but instead of setting an alarm it controls the timer functionlality.

Geofences are difficult to test in a short training session because they require physically moving assets. Use the following as a setup guide for a proof of concept (PoC) or full commercial installation instead of expecting to fully experiment during the lesson.

The General Geo Query Flow

The General Geo Query Flow works together with the Location Service—using GPS, Wi-Fi, or BLE data—to determine whether an IoT node is inside or outside a geofence.
This query executes every time an IoT node (typically a tracker) reports a new location event.

Geofences can be both outdoor and indoor.
Indoor geofences include a property called floorIndex, which maps to a specific floor level to help localize the tracker accurately.

Enabling Geofence Capabilities

1. Use General Geo Query Flows
   Assign the General Geo Query Flow to the IoT nodes that should participate in geofencing logic.

2. Create Geofence Generic Nodes
   These nodes serve as reference points for geofences and help visualize how many trackers are within each one.
   Add the translator general-geofence to the geofence IoT nodes.

   

3. Create Geofences
   Define geofences directly on the map or through map widgets in dashboards that use geomapped floor plans.
   Use the _id of the generic geofence node as the reference node in each geofence.

4. Enable Indoor Localization (Optional)
   For indoor localization, Combain is the recommended provider.
   To improve accuracy and distinguish between floors, a Combain AI Indoor Survey must be performed.
   This survey maps Wi-Fi routers and BLE beacons’ RSSI levels for triangulation using the Combain mobile app.

   

   Steps for a Combain trial:

   • Request a Combain account from your technical support contact.
   • Log in to the Combain Indoor Portal.
   • Create a new Place and choose it to be of the type Building in the portal and ensure Combain correctly recognizes the layout. If not, redo the process until it does.
   • Upload and align floor plans for each level of the building.
   • Perform a detailed survey using the Combain Android AI Indoor Survey App.
   • The more detailed your survey, the higher the localization accuracy.

   For exact details of the complete Combain process and tools see Combain Indoor Positioning Guide

5. Create Map Views and Dashboards
   Visualize the locations of your geofences, geofence IoT nodes, and trackers within dashboards or map views.

Improve Geofencing with Wi-Fi RSSI Level Capability

When it’s important to count the number of trackers within a specific area—for example, to provide a KPI to stakeholders—it is recommended to complement the geofencing capability with Wi-Fi Router RSSI level checks.

The idea is to use Wi-Fi RSSI thresholds to cover the main area where assets should be counted, while the geofence serves as a backup to capture devices located just outside the beacon’s range.
Together, these two methods provide a more accurate and reliable result.

Enabling Wi-Fi RSSI Level Detection

To enable Wi-Fi RSSI-based detection, a customized translator is used.
This translator monitors the signal strength (RSSI) of known Wi-Fi beacons and decides whether a tracker should be considered inside a geofence area.

This approach is commonly used in large-scale infrastructure projects, like Airports, where asset tracking within storage zones or restricted areas is critical.

Recommended Configuration for Optimal Performance

To improve the likelihood of accurate detection, apply the following settings:

1. Increase Wi-Fi beacon broadcast frequency
   Change the beacon interval from the standard 100 ms to 40 ms for faster updates.

2. Use Wi-Fi channel 0 for all beacons
   Trackers typically start scanning from channel 0 and stop once their buffer is full.
   Using channel 0 ensures the highest chance of detection, especially in busy Wi-Fi environments.

3. Reduce Wi-Fi router transmit power
   Limit the transmission power to around 4–10 dB (instead of the maximum 26 dB).
   This helps avoid interference with other Wi-Fi infrastructure and isolates the beacon coverage to the desired area.

4. Use lowest bit rate
   Because trackers scan for Wi-Fi and BLE only briefly to conserve energy, it’s best to keep the bit rate at the standard 1 Mbit/s.
   With the transmission power set low, this minimizes interference with the building’s existing Wi-Fi infrastructure while maintaining reliable detection.

By combining Wi-Fi RSSI thresholds with geofencing, the platform can achieve more precise indoor localization and reliable occupancy tracking across complex environments.

Hardware requirements for localisation services

Your tracker must support scanning the available IT infrastructure in the area. Currently, three tracker types are supported:

1. GPS or other positioning satellites only

   • Requires a clear sky to see GPS satellites.
   • Example: Digital Matter Oyster.

2. GPS + Wi-Fi 2.4 GHz only

   • Requires a 2.4 GHz Wi-Fi infrastructure (5 GHz scanning is not supported as of 2025).
   • Example: Sensative Square Tracker (supports scanning of up to 16 Wi-Fi beacons for maximum accuracy).

3. GPS + BLE + Wi-Fi 2.4 GHz

   • Examples: Digital Matter and Abeeway trackers.

Localization Service Integrations

To perform localization, a third-party service is required.
The platform currently integrates with:

• Traxmate
• Combain

Other providers such as Amazon Web Services and Google also offer location services, but these are not yet integrated.
If you require integration with another provider, contact your technical support representative.

Commercial Use

When moving to commercial deployment, request a quote from your support representative.
All localization services include costs based on the expected number of monthly localization pings.

Q&A: Why Timers Matter in an IoT Platform

Question

Why use timers in alarm logic?

Answer

Timers allow for time-based conditions to be evaluated before triggering an alarm. This is crucial when you don’t want an alarm to fire immediately upon a threshold being crossed, but only if that condition persists for a certain amount of time.

Question

Can’t I just trigger an alarm the moment a value exceeds a threshold?

Answer

You could—but in many cases, that leads to false positives. For example, a temperature sensor might briefly spike above a limit due to a short anomaly or noise. A timer ensures that only sustained conditions (e.g., over 10 minutes) result in an alarm, improving accuracy.

Question

What’s a real-world example of using a timer?

Answer

Let’s say you want to detect overheating in a server room. If the temperature rises above 30°C for more than 15 minutes, that’s a serious issue. A timer can track how long the threshold is exceeded before firing an alarm.

Question

Can timers help detect when a condition returns to normal?

Answer

Yes. By resetting the timer when the condition clears, you can create logic through a customized translator that also tracks recovery time, or use that state to trigger a "cleared" notification. Recovery time can also be visualized in Charts by checking how long time timerExpired were true.

Question

How does the platform implement timers?

Answer

Timers are exposed via the fields:

• timerStart – Whether a timer has been triggered
• timerStartAt – When it started
• timerExpired – Whether the timer has expired (this is often the alarm trigger)

These fields can be used in visualizations, rule logic, or reporting.

Question

Are timers only useful for alarms?

Answer

No. Timers are also useful for things like:

• Tracking equipment runtime duration
• Measuring time since last motion detected
• Detecting downtime or inactivity
• Enabling delayed actions in automation flows If the general-timer translator does not fulfill your needs, you can easily create other logic to start and stop timers through a custom timer translator.

Question

Do I need to write code to use timers?

Answer

Not for any standard use case, timers are managed via the platform’s flows, translator logic or rule engine, and can be visualized directly in reports or dashboards using standard fields. The only time you need to write code is if the standard general-timer translator does not fulfill your timer start logic needs.