Problem: Suppose you have a transportation monitoring tracker connected to a scooter and running Navtelecom protocol. It is known to transmit the following parameters.
ParameterParameter number in the protocolFLEX
Event code21.0
Event Time31.0
Status of function modules 151.0
Status of Functional Modules 261.0
GSM Level71.0
Number of satellites81.0
Navigation receiver enabled81.0
Valid navigation81.0
Course14 1.01.0
Battery voltage201.0
Scooter unlocked31, 1st output1.0
Status of virtual accelerometer sensors1393.0
Tilt angle relative to local vertical1403.0
Pitch angle1413.0
Roll angle1413.0
Also, the description of the tracker says that it provides a response to the following commands.
Request device model and versionSystem command
Request firmware informationSystem command
UnlockEnable output 1
LockDisable output 1
Turn on headlightEnable output 2
Turn off headlightDisable output 2
Restart the deviceSystem command
To connect the scooter tracker to the platform, create a model for it. Navtelecom.
The template model has all the parameters from the FLEX 1.0, 2.0 protocol sections and some parameters from the FLEX 3.0 section. By searching the template model you can to see which parameters are already present and which ones you need to add yourself.
In this case, all the necessary parameters are already present in the model. It remains only to remove or hide unnecessary parameters from display, and the necessary parameters group them.
Also, all possible commands that can be sent are predefined in the template model. The commands to turn output line 1 on and off are in this case responsible for locking the scooter, and output line 2 is responsible for the headlight. Rename these commands. Other necessary commands can be left unchanged, and any unnecessary actions can be can be removed or hidden from the display.
View a preview of the object with the model you created by clicking the Show preview button. preview**.
If you wish, select an icon to display the object on the map, or upload your own image.


Create an object for your scooter. Select the model you just created. Then enter the ID that corresponds to the IMEI of the monitoring unit, ** prefixed with ntcb:**. Specify a name for the object.
Once saved, the instructions for configuring the device to the platform will open.


To connect the scooter to the platform in the configurator settings of the block monitor unit configurator settings
  • host dev.rightech.io
  • port 21400
Make sure that after saving the settings, data from the device is sent and are displayed in the interface. After receiving the coordinate packet, the object should be displayed on the map.
Send commands and check that the connected device responds to them.


As an example on complex geo-fence control, consider the following task.
Task: Suppose we need to send different notifications to the platform if a scooter has left a valid geo-zone for riding and if the scooter has entered a geo-zone that is strictly forbidden for riding. It turns out that in this example there are two geofences over which the scooter movement control is different.
The automaton will contain three states:
  • pending event triggering on geo-fence crossing;
  • outside the authorized geofence;
  • in a forbidden geofence.
Transitions between these states will occur when we receive the events of entry and exit events from the corresponding geozones. However, if in one of the past examples default events Entry/exit geofence were used, in this case you need to add your own events to the model. In this case you need to add your own events to the model, which will then be used to make transitions in the automaton. transitions in the automaton. If you don't do this and use the default events default events, then, for example, the Geozone Exit event will be triggered when you exit from an authorized geofence. exit from both allowed and forbidden geofences, and you will not be able to distinguish between them in the automaton. to distinguish between the two in the automaton.
Go to the model and create additional events. You need to create at least at least two events: leaving the allowed geofence and entering the forbidden geofence. However, it is better to create a complete set of events for both types of geo-fences, i.e. four events.
Create a new automaton.
Since the logic of the automation script calls for cyclic control of entering and leaving geofences, the automaton will be infinite, the final state
can be moved out of sight and not use. Create three states of the automaton.
Transitions between states will occur when events are received about entering or exit from the geofence. No additional conditions need to be checked in this case. Note that you should select the events you created, not the events for geofences present in the geofence. not the default geofence events.
Now add commands to send notifications.
The automaton is ready. Select the scooter object and run it.
The automaton is running, but events must be received to transition between states of entering and exiting controlled geo-zones.


Create geofences that define the allowed and forbidden area for the scooter use.
Add geofences to the scooter object. After receiving the actual coordinates the status of being in the In/Out geofences will appear.
Add the appropriate events for these geofences that you created earlier. Then they will be generated when you enter and exit the geofence. These are the ones used in the automaton.
Now when entering and exiting geofences there is a transition between states and the notifications are sent.