¶ Project Task
¶ Description
Program scans the BLE broadcast and controls only the appearance of any devices (tags). If there are several tags, then the program searches for a tag with a stronger RSSI signal level.
¶ Program Example
The current release of the Complex Events editor does not support working with the program. Request a test build from Technical Support Team .
¶ Project Implementation
In the device configuration, on the Bluetooth tab, it is needed to enable Bluetooth operation.
The program has two main variables for tag control: id and fixed_id.
id - the current nearest tag (value can change quickly depending on data in the BLE broadcasting)
fixed_id - the current fixed tag (tag that the device accepts as the main one, saves it and sends it to the server)
There is also a global fix status. The status is set to true if fixed_id is set to (tag found) and set to false if the tag in fixed_id is not the strongest or has been out of the broadcast for longer than the time specified by the LOSS_T variable.
Below there are the main conditions used to determine if a tag was missed, found or changed.
_first_fix- condition is met if(fixed_id == 0) && (id != 0).
This is a situation when the device has not yet detected the tags,0is sent to the server and then the first tag appears.
If the condition is met, then:fixis set to true;idis writtent tofixed_id;idis written to User parameter CE No. 1;rssiis written to User parameter CE No. 2;41046event is generated.
_loss_id- condition is met if(fixed_id != 0) && (id != fixed_id).
This is a situation when the device has already fixed a tag, but it is no longer the current closest one or it is already the missed one.
If the condition is met, then:fixis set to false;fixed_iddoes not change;0is written to User parameter CE No. 1;-128is written to User parameter CE No. 2;41047event is generated.
_second_fix- condition is met if(fixed_id != 0) && (id != 0) && (fix == false).
This is a situation when a fixed tag is overwritten with another tag with a stronger signal.
Если сработало условие, то:fixis set to true;idis writtent tofixed_id;idis written to User parameter CE No. 1;rssiis written to User parameter CE No. 2;41046event is generated.
¶ Flowchart
 |
| Flowchart. Part 1 |
At the very beginning of the program, in the "+" branch of the on_start condition, one-time recalculation of one of the system variables is performed. This block could contain all one-time calculations or actions that need to be performed only after the start of the program.
Next, in the scan ble block, real-time data about the tags is obtained. At this stage, the program receives information that new data has arrived for processing.
Block of functions highlighted with OPTIONAL frame:
The easiest identification option is by MAC address. This does not require additional calculations. The MAC address is already known in the scan ble block.
But if it is needed to get an ID from the data transmitted by sensor, then it should be added such a construct.
Check condition checks and gets the required ID. If the ID is received, then it is updated in the update id block. If the ID was not received, then in the unset new_data block, the flag for receiving new data, which was received earlier in the scan ble block, is reset.
This approach is convenient for working with iBeacon.
 |
| Flowchart. Part 2 |
The new_data condition allows connecting a block of functions to process new information from the tag.
The task of this block of functions is to select the tag with the strongest signal level.
In the compare id block, check is made to obtain information from the current strongest tag. If the new data is from the current tag with the strongest signal, then the _update_rssi flag is set.
The need init condition checks for the first pass through these functions after enabling. If the program entered this block for the first time after enabling, then without further analysis, transition to saving the current ID and signal level is made.
The update rssi condition checks the state of the _update_rssi flag. If it is active, then without further analysis, transition to saving the current ID and signal level is made.
In the (rssi_tmp > rssi) condition, the signal strength of the new tag and the current tag with the strongest signal are checked. If the new one has stronger signal, then the tag with the strongest signal is overwritten. Otherwise, data analysis is terminated.
The set id action updates the tag's id, capacity, and activity state.
The active state should be noted - each time the data from the tag is updated, the _id_inactive flag is reset.
 |
| Flowchart. Part 3 |
The update activity timer condition periodically runs the tag activity check procedure.
The clean inactive id action performs:
- reset current strongest tag if
_id_inactiveis True - sets the
_id_inactiveflag
The fix conditions block controls the _first_fix, _loss_id and _second_fix conditions. They were previously described in the guide.
The fix timers block controls delays for triggering the _first_fix, _loss_id and _second_fix conditions. Variables for setting delays are described later in the guide, in the Advanced section.
The on fix condition performs the following:
(all variables were previously described in the guide earlier)
fixis set to true;idis writtent tofixed_id;idis written to User parameter CE No. 1;rssiis written to User parameter CE No. 2;41046event is generated.
The on loss condition performs the following:
(all variables were previously described in the guide earlier)
fixis set to false;fixed_iddoes not change;0is written to User parameter CE No. 1;-128is written to User parameter CE No. 2;41047event is generated.
 |
| Flowchart. Part 4 |
The update rssi condition checks the state of the _update_rssi flag. If it is active, then the current tag signal is updated.
The set rssi param action updates the current signal power in the CE User Parameter No. 2.
¶ Advanced
¶ Settings
Variables used for set up:
FIRST_FIX_T- timeout for fixing the_first_fixcondition (first capture after enabling).
Default is 30 000 ms
It is not recommended to set values less than the default, because it increases the probability of fixing not the closest tag.
SECOND_FIX_T- timeout for_second_fixcondition (identifier change).
Default is 2 000 ms
It is not recommended to set values less than the default, because this is necessary for correct handling of ID change events on the server. The device must sequentially send 0, and then a new identifier, so that the server fixes the change.
LOSS_T- timeout for_loss_idcondition (identifier reset).
Delays before resetting the fixed identifier are used to cut off unnecessary changes of identifiers. Relevant for the case when several identifiers are approximately at the same distance from the device.
Default is 60 000 ms
It is not recommended to set a value less than 30000 ms.
¶ User Parameters
User parameter CE No. 1 - the last 4 bytes of the MAC address of the fixed tag (or other contents of the fixed_id variable).
- Parameter type: Unsigned integer.
-
- Recommended to be transfered as 4 byte parameter
User parameter CE No. 2 - RSSI signal level from the tag in dBm.
Always a negative value. The larger the value, the stronger the signal.
- Parameter type: Signed integer.
-
- Recommended to be transfered as 1 byte parameter
¶ Events
| Code | Description |
|---|---|
41046 |
New tag capture event |
41047 |
Tag lost event |