Wialon IPS
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.
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.
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.
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.