Wialon IPS
Example on GitHub (opens in a new tab)
Model
Problem: Suppose you have a monitoring unit connected to a car and working via Wialon IPS protocol. It is known that in addition to the basic values defined in the protocol, it transmits the following additional parameters.
| Parameter | Name in packet |
|---|---|
| CAN speed | can_speed |
| Mileage | can_odo_km |
| battery voltage | acc_voltage |
| ext_voltage | ext_voltage |
| Fuel in percent | fuel_lev_p |
| ignition | ign |
| engine_is_on | engine_is_on |
| driver_door | driver_door |
| Passenger door | pass_door |
| left rear | l_rear_door |
| Right rear | r_rear_door |
| Trunk open | trunk |
| parking | parking |
| marker lights | marker_lights |
| dipped headlights | dipped_beam |
| Hand brake | hand_break |
| foot brake | pedal_break |
Also, the block description says that it provides a response to the following commands.
| Action | Command |
|---|---|
| Close all doors | #can_closealldoor#\r\n |
| Open all doors | #can_openalldoor#\r\n |
| Blinking lights | #can_blinkerflasing#\r\n |
| Horn | #can_horn#\r\n |
| Horn and blink | #can_hornblinker#\r\n |
| Stop the engine | #can_stopengine#\r\n |
| Start the engine | #can_startengine#\r\n |
To connect the vehicle unit to the platform, create a Wialon model for it. IPS.
There are many parameters in the template model. By searching through the model, you can understand which parameters are already present, and which ones you need to add yourself.
| Parameter | Name in packet |
|---|---|
| CAN speed | can_speed |
| Mileage | can_odo_km |
| battery voltage | acc_voltage |
| ext_voltage | ext_voltage |
| Fuel in percent | fuel_lev_p |
| ignition | ign |
| engine_is_on | engine_is_on |
| driver_door | driver_door |
| Passenger door | pass_door |
| left rear | l_rear_door |
| Right rear | r_rear_door |
| Trunk open | trunk |
| parking | parking |
| marker lights | marker_lights |
| dipped headlights | dipped_beam |
| Hand brake | hand_break |
| foot brake | pedal_break |
Remove or hide unnecessary parameters from the display and leave only the necessary ones.
Add the two missing parameters.
For more information on Wialon IPS argument formation
Also in the template model there are examples of several commands, form on the basis of them the commands of your block. commands for your block.
Important: According to the protocol, the text of each command must end with a \r\n package endpoint
(#can_closealldoor#\r\n), which means carriage return and line break. However, since these are control characters rather than printable ones, they are not displayed in the platform interface in the command input field. Although you can see them if you go to the HEX tab.
To avoid errors when forming your commands, for Wialon IPS model there is a possibility to not add \r\n (0D0A) in the command text input field. You need only specify only the command text itself from grid (#) to grid (e.g., #can_openalldoor#). The platform will substitute control characters \r\n at the stage of sending the command by itself.
For more information on Wialon IPS actions formation
View a preview of the object with the model you have created by clicking Show preview. preview**.
If you wish, select an icon to display the object on the map, or upload your own image.
Model to import (opens in a new tab)
Object
Create an object for your vehicle. Select the model you just created. Then enter the identifier corresponding to the IMEI of the monitoring unit, with prefix wialon:. Specify the name of the object.
After saving, the instructions for configuring the device to the platform will open.
Connection
To connect the vehicle to the platform in the configurator settings of the monitoring unit monitor unit configurator settings, specify
- host dev.rightech.io
- port 20332
Make sure that after saving the settings, the 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.
Logic
As an example of interaction of several devices in one automaton let's consider the following problem.
Problem: Suppose that the kettle from the MQTT example needs to be turned on and off automatically when you come and go from home. So, you need to implement in the automaton the control of entry/exit from some geo-zone defined by the area around the house. Then, as soon as the car enters this geofence, the kettle will turn on, and hot tea will be waiting for you at home. And if you drive away, the kettle will turn off if it is suddenly left on.
The automaton will contain two states: at home and away from home. Transitions between these states will occur when receiving events of entering and leaving the geofence.
Create a new automaton. Choose two models: a kettle and a car, as the automaton will organize interaction between two objects with these objects. automaton will organize interaction between two objects with these models. models. Events will come from the car, and commands will be sent to the kettle.
Since the logic of the automation script calls for cyclic control over being in the geofence, the automaton will be infinite, final state can be moved out of view and not used. Create two states of the automaton.
Transitions between states will occur when events are received about entering or exit from the geofence. Checking for additional conditions is not required in this case. Please note that the car model must be active when selecting events, because as the events received from it will be used to trigger the transition.
Now add commands that will be executed in the states: turning the kettle on and turning the kettle off. Note that when selecting actions, the kettle model must be active. model of the kettle, since the commands will be sent to it.
The automaton is ready. Select the objects and run it.
You can run this same automaton for other objects - for example, to have your neighbor's kettle turn on and off when he comes and goes respectively.
The automaton is running, but to transition between states, events must be received about entering and leaving the controlled geo-zone.
Geofences
Create a geofence that defines the area around your home. You can choose You can choose from polygon, rectangle, or circle geofences.
Add a geofence to the vehicle object. After receiving the actual coordinates you will see the status of being in the In/Out geofence. Here you can also see the events that are generated on entry and exit. These are the ones that were used in the the automaton.
Now there is a transition between states when entering and leaving a geofence.
Commands are sent to the kettle.
