Rule Examples/en: различия между версиями

In the example, the motion sensor is connected to the «dry contact» input, control type «switch». The siren is connected to the built-in Wiren Board relay, and the lamp is connected to the relay box via Modbus. When the «dry contact» input (motion sensor output) is closed, «1» is supplied to the lamp and the relay, and «0» when it is off.

The rule is triggered every time the control value «D1_IN» of the device «wb-gpio» is changed. The new value of this control is passed to the rule code as a variable newValue.

dev["wb-gpio/Relay_2"] = newValue;

dev["wb-mrm2_6/Relay 1"] = newValue;

dev["wb-gpio/Relay_2"] = newValue;

dev["wb-mrm2_6/Relay 1"] = newValue;

A motion detector with a «dry contact» output is connected to input D2. When motion is detected, it shorts D2 and GND and status «1» appears on the corresponding <code>wb-gpio/D2_IN</code> channel.

* when movement appears, the light turns on. If a thirty-second «off» timer was previously started, this timer is disabled;

* when motion is lost, a thirty second «off» timer is started. If he manages to reach the end, the light turns off.

             dev["wb-gpio/Relay_1"] = true;

                 dev["wb-gpio/Relay_1"] = false;

               dev["wb-gpio/relay_control"] = true;

                   dev["wb-gpio/relay_control"] = false;

           dev["wb-gpio/EXT1_R3A1"] = 1;

             dev["wb-gpio/EXT1_R3A1"] = 0;             

     return dev["relay_up_device/relay_up_control"];

         return dev["relay_up_device/relay_up_control"] = 0;

         dev["relay_down_device/relay_down_control"] = 0;

       return dev[relay_up_device][relay_up_control] && dev["relay_down_device/relay_down_control"];

       dev["relay_down_device/relay_down_control"] = 0;

       dev["water_meters/water_meter_1"] = ((parseInt(newValue) - counterCorrection) * inpulseValue) + meterCorrection; // We multiply the value of the counter by the number of liters / pulse and add the correction value.

Handling counters is conveniently done on [[wb-rules]], but you can use any automation tool like [[Node-RED]]. To speed up meter polling, configure [[RS-485:Configuration via Web Interface#poll-period |poll period]].

=== Examples ===

|text= Rule example

In the example, we are using the [[WB-MCM8 Modbus Count Inputs | WB-MCM8]] to control the first dimmer channel [[WB-MDM3 230V Modbus Dimmer | WB-MDM3]]:

# Short press turns on the channel.

# Double - turns off the channel.

# Long - increases brightness.

# Short, then long - reduces brightness.

Since changing the brightness requires a time-consuming action, we use a timer. We also control the state of the input with the button and stop the action when the button is released.

     if (i < 100 && dev["wb-mcm8_20/Input 1"]) {

     if (i > 0 && dev["wb-mcm8_20/Input 1"]) {

=== Generic module for wb-rules ===

We wrote a module for wb-rules [https://github.com/wirenboard/wb-community/tree/main/wb-press-actions wb-press-actions] that makes it easy to handle clicks in your scripts.

== Sensor MSW v.3 ==

When connecting the WB-MSW v.3 sensor to the Wiren Board controller, it is possible to create interesting scenarios using data from the sensor. For example, turn on the light when moving, signal with LEDs when the CO2 or VOC value is exceeded, turn on the air conditioner if it is hot or the air humidifier if the air is too dry. Rules are created individually for tasks. Here we will give some examples to understand the principle of working with the sensor. More examples of writing rules can be found in the '''[[Движок правил wb-rules | Rules engine wb-rules]]''' documentation.

When the CO2 concentration is less than 650, we flash green once every 10 seconds.

When the CO2 concentration is over 651, but less than 1000, we flash yellow once every 5 seconds.

When the CO2 concentration is over 1001, we flash red once a second.

         if (co2_good) {

             dev["devName/Green LED"] = true;

             dev["devName/Red LED"] = false;

             dev["devName/LED Period (s)"] = 10;

             dev["devName/Green LED"] = true;

             dev["devName/Red LED"] = true;

             dev["devName/LED Period (s)"] = 5;

             dev["devName/Green LED"] = false;

             dev["devName/Red LED"] = true;

             dev["devName/LED Period (s)"] = 1;

"Max Motion" - the maximum value of the motion sensor for N time. Time from 1 to 60 seconds can be set in register 282. The default is 10 seconds. When the Max Motion value reaches 50, we check whether the room is sufficiently lit, if not, turn on the light. As soon as the Max Motion value drops below 50, turn off the light.

             if (dev["wb-msw-v3_97/Illuminance"] < 50) {

                 dev["wb-mr3_11/K1"] = true;

             dev["wb-mr3_11/K1"] = false;

=== System rules ===

Many of the indications that are visible in the web interface of the controller out of the box are also created by rules on the wb-rules engine. Their code is here: [https://github.com/wirenboard/wb-rules-system https://github.com/wirenboard/wb-rules-system]. The system rules are collected in the <code>wb-rules-system</code> package, the script files on the controller are located in the <code>/usr/share/wb-rules-system/</code> folder.  

A few examples of system rules are below.

=== Rule for tweeters ===

[https://github.com/contactless/wb-rules-system/blob/master/rules/buzzer.js Rule] creates a virtual buzzer device with volume and frequency sliders and a mute button.

   cells: {

         runShellCommand("echo " + period + " > /sys/class/pwm/pwmchip0/pwm2/period");

   then: function (newValue, devName, cellName) {

=== Power status rule ===

[https://github.com/contactless/wb-rules-system/blob/master/rules/power_status.js Rule] creates a virtual device that reports the current power status. Two ADC channels are used as input data: battery voltage measurement and input voltage measurement.

The following logic is implemented:

1. If the input voltage is less than the battery voltage, then the board is powered by the battery. In this case, 0V is also displayed as the input voltage.

2. If the input voltage is greater than the battery voltage, then the board is powered by an external power source. The measurement from the Vin channel is displayed as the input voltage.

To illustrate, the rules use two different ways of triggering: by changing the value of the control (rule _system_track_vin) and by changing the value of the expression (the other two).

   cells: {

   }

         if (dev["wb-adc/Vin"] < dev["wb-adc/BAT"] ) {

             dev["power_status/Vin"] = 0;

             dev["power_status/Vin"] = dev["wb-adc/Vin"] ;

     return  dev["wb-adc/Vin"] > dev["wb-adc/BAT"];

     dev["power_status/working on battery"] = false;

     return  dev["wb-adc/Vin"] <= dev["wb-adc/BAT"];

     dev["power_status/working on battery"] = true;

== Thermostat ==

An example of a simple thermostat from the [https://support.wirenboard.com/t/novaya-versiya-dvizhka-pravil/4196/158 topic on the support portal].

       // =============== hallway underfloor heating

       "R01-TS16-1-mode": {//mode 0-manual 1-scheduled

       "R01-TS16-1-setpoint": {//setting

       "R01-TS16-1-lock": {//blockage in visualization 0-unlocked 1-blocked

defineRule(name, {

   whenChanged: temp, //when the sensor state changes

   then: function (newValue, devName, cellName) { // do the following

    if ( newValue < dev[setpoint] - hysteresis) { //if the sensor temperature is less than the setpoint - hysteresis

      dev[TS] = true;

    }

    if ( newValue > dev[setpoint] + hysteresis) { //if the sensor temperature is greater than the virtual setpoint + hysteresis

      dev[TS] = false;

    }

Termostat("R01-TS16-1", "A60-M1W3/External Sensor 1", "Termostat/R01-TS16-1-setpoint", "wb-gpio/EXT4_R3A1", "Termostat/R01-TS16-1-onoff"); //  

== Sending commands via RS-485 ==

For example, send a command to the device on the port /dev/ttys0 (corresponds to the hardware port RS-485-ISO on the [[Special:MyLanguage/Wiren Board 4|Wiren Board 4]]). To do this, we will use the rules engine and the ability to execute arbitrary shell commands. See [https://github.com/contactless/wb-rules#%D0%94%D1%80%D1%83%D0%B3%D0%B8%D0%B5-%D0%BF%D1%80%D0%B5%D0%B4%D0%BE%D0%BF%D1%80%D0%B5%D0%B4%D0%B5%D0%BB%D1%91%D0%BD%D0%BD%D1%8B%D0%B5-%D1%84%D1%83%D0%BD%D0%BA%D1%86%D0%B8%D0%B8-%D0%B8-%D0%BF%D0%B5%D1%80%D0%B5%D0%BC%D0%B5%D0%BD%D0%BD%D1%8B%D0%B5 documentation] for details.

Create a virtual device with switch type control via rules engine.  

When you turn on the switch a command will be sent: (Set Brightness ch. 00=0xff) for Uniel UCH-M141:

When you turn off the switch  a command will be sent: (set channel brightness 00=0x00) for Uniel UCH-M141:

1. Port setting

To configure the / dev/ttyNSC0 port to 9600 speed, run the following command

2. Sending a command

Sending data is done with the following shell command:

where "\xFF\xFF\x0A\x01\xD1\x06\x00\xE2" - is the entry of a "FF FF 0A 01 D1 06 00 E2" command.

3. Create the new rules file <code>/etc/wb-rules/rs485_cmd.js</code> in the rules engine

The file can be edited with vim, nano, or mcedit in an ssh session on the device, or it can be downloaded with SCP.

4. Describe the virtual device in the file

5. Restart wb-rules and check the operation

There should be no error messages in the log (exit via control-c)

A new device "Send custom command to RS-485 port" should appear in the Devices section of the web interface.

6. Add a function to configure the port.

7. Let's describe the rules for turning the switch on and off

Note the double shielding.

7. Putting it all together

The full contents of the file with the rules:

setTimeout(setup_port, 1000); // set setup_port() running 1 second after starting.

== Sending a message via Telegram bot ==

Messages are sent using [https://core.telegram.org/api#telegram-api Telegram API] via <code>curl</code>.

varmessage = "Text"; // write your message text

var token = "TOKEN"; // replace with bot token

var chat_id = CHATID; // replace with your chat_id

== Handling errors when working with serial devices ==

Implemented by subscribing to all '''meta/error''' topics.

== Custom fields in web interface ==

[[File:Sample-custom-config-1.png|300px|thumb|right|Example configuration]]

[[File:Sample-custom-config-2.png|300px|thumb|right|Example script]]

If you need to manually enter temperature and humidity settings in the interface of the Wiren Board controller.  

An easy way is to do in the defineVirtualDevice() field, make it readonly: false. And it will appear in the web interface in Devices as editable, and the value will be saved in the rules engine.

But a complex setup with menus and options cannot be done this way.

The correct but tricky way is to create a new tab in the Configs section with editable settings options fields.

Three files are required:

1. The output scheme of the html page in the Configs  

section: /usr/share/wb-mqtt-confed/schemas/test-config.schema.json

2. Description of the default configuration (when saving the form in the web interface, the values will be written to this file) : /etc/test-config.conf

3. Script that updates config  : /mnt/data/etc/wb-rules/test-config-script.js

The last file can also be edited from the web interface on the Scripts tab.

In the json file describes the schema of the output html page browser, according to generally accepted mapping standard. Description of keys here: json-schema.org ahhh!

After creating the files, you need to restart the services

When you click Save in the web interface, the wb-rules service will be restarted, and the values of the settings will be written to the rules.

== Complex rules with schedules ==

The object is a grocery store. Various store systems are controlled by feedback from temperature sensors and taking into account the store's work schedule.

Not cron-rules are used for schedules, but  the libschedule. The libschedule enables and disables rules, which, unlike cron rules, are executed continuously when enabled.

For example, we want the lighting to be on from 10 to 17h. The libschedule will follow the «turn on the lights» rule once a minute from 10 am to 17 PM.

This means that even if the controller is running intermittently and missed the transition time between schedules (10 am), the controller will still turn on the lights at the first opportunity.

(function(Schedules) { // closing

   function todayAt(now, hours, minutes) {

   function checkScheduleInterval(now, start_time, end_time) {

     if (end_date >= start_date) {

       // option 1: what if it's now the day of "end" date?

       // well, that seems not to be the case. ok,

       if (now >= start_date) {

   }

   function checkSchedule(schedule, now) {

     for (var i = 0; i < schedule.intervals.length; ++i) {

   function addScheduleDevCronTasks(schedule) {

   function addScheduleAutoUpdCronTask(schedule) {

   var _schedules = {};

   Schedules.registerSchedule = function(schedule) {

   Schedules.initSchedules = function() {

     for (var schedule_name in _schedules) {

     defineVirtualDevice("_schedules", params);

     for (var schedule_name in _schedules) {

         // setup cron tasks which updates the schedule dev status at schedule

         // if needed, setup periodic task to trigger rules which use this schedule

         // set schedule dev status as soon as possible at startup

       };

An example of a rule using Schedules:

(function() { // closing

   defineAlias("countersTemperature", "wb-msw2_30/Temperature");

   defineAlias("heater1EnableInverted", "wb-mrm2-old_70/Relay 1");

   Schedules.registerSchedule({

     "name" : "signboard", // signboard

       [ [12, 30], [20, 30] ],  // in UTC, 15:30 - 23:30 MSK

       [ [3, 30], [5, 20] ],  // in UTC, 6:30 - 8:20 MSK

       [ [4, 45], [20, 15] ],  // still UTC, 07:45 - 23:15 MSK

       [ [5, 0], [19, 0] ],  // still UTC, 8:00 - 22:00 MSK

       [ [4, 45], [19, 15] ],  // still UTC, 7:45 - 22:15 MSK

       [ [4, 20], [20, 45] ],  // still UTC, 7:20 -23:45 MSK

       [ [4, 0], [17, 0] ],  // still UTC, 07:00 - 20:00 MSK дневной режим