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.

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.

             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;

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

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

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

         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;

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 дневной режим

   // signboard and facade illumination

   // sales area illumination

       dev["wb-gpio/EXT1_R3A1"] = ! dev._schedules.frontshop_lighting; //inverted contactor

   // backstoreroom ventilation

       dev["wb-mr6c_81/K1"] = ! on; //inverted contactor

       dev["wb-mr6c_81/K5"] = ! on; //inverted contactor

   // Freezer showcase illumination

       //  

the lighting in the freezer showcases via the normally-closed relays (inverted)

   //Display fridges

       dev["wb-gpio/EXT1_R3A5"] = !on; // inverted

   // ========= Boilers and supply ventilation ТЗ ===========

   // feedback on the temperature of the vegetable zone

   // position controller works daily

       heater1EnableInverted = !false; // inverted

   defineRule("heatersDayOn", {

       heater1EnableInverted = !true; // inverted

   // position controller works at night

       heater1EnableInverted = !false; // inverted

   defineRule("heatersNightOn", {

       heater1EnableInverted = !true; // inverted

   // supply and exhaust ventilation are forcibly switched off

   // ==================  The cash register area =================

   // in the checkout area during working hours, the temperature is maintained by air conditioners (position controller)

   defineRule("countersACOn", {

       dev["wb-mir_75/Play from ROM7"] = true; // air conditioning cash area for heating

   // after working hours, the air conditioning is off

       dev["wb-mir_75/Play from ROM2"] = true; // shut down air conditioning cash area

   // =============== Vegetable Zone ==============

   // Refrigeration of vegetables with air conditioning only when the air temperature is above 18.5C   

   defineRule("acVegOn", {

       dev["wb-mir_76/Play from ROM3"] = true; // Cooling +18

   defineRule("acVegOff", {

       dev["wb-mir_76/Play from ROM2"] = true; // turn off

* [[Wb-rules | Brief description of wb-rules on wiki]]

* [https://github.com/wirenboard/wb-rules Full description of wb-rules on Github]