MediaWiki API result
This is the HTML representation of the JSON format. HTML is good for debugging, but is unsuitable for application use.
Specify the format parameter to change the output format. To see the non-HTML representation of the JSON format, set format=json.
See the complete documentation, or the API help for more information.
{
"batchcomplete": "",
"continue": {
"gapcontinue": "Rules_Examples",
"continue": "gapcontinue||"
},
"warnings": {
"main": {
"*": "Subscribe to the mediawiki-api-announce mailing list at <https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce> for notice of API deprecations and breaking changes."
},
"revisions": {
"*": "Because \"rvslots\" was not specified, a legacy format has been used for the output. This format is deprecated, and in the future the new format will always be used."
}
},
"query": {
"pages": {
"133": {
"pageid": 133,
"ns": 0,
"title": "Rules",
"revisions": [
{
"contentformat": "text/x-wiki",
"contentmodel": "wikitext",
"*": "Each Rule define the follow-up actions based on current DI / [https://wiki.netio-products.com/index.php?title=PAB '''PAB''']/ [https://wiki.netio-products.com/index.php?title=Watchdog '''WatchDog'''] function state. There can be several Rules executed based on one PAB function (switch output if Current > 1000 mA + Send Alert to NETIO Cloud IF Current > 500 mA). One Rule can be executed based on combination of several PAB / WatchDog states.\n\n'''Rules examples are available on page:''' https://wiki.netio-products.com/index.php?title=Rules_Complete_Examples\n\n== CONDITION ==\nRule conditions define when the action part of each Rule is executed. There can be multiple conditions for one Rule. \nIn order to execute the action, all conditions have to be valid (AND operator) / at least one of the conditions have to be valid (OR operator).\n<code>bootDelay</code> parameter <sup><code>FW 4.0.0+</code></sup> can be used to delay rule evaluation after power up (or internal periodic restart). This is useful for example for delay condition and alerts evaluation after PAB blocks are stabilized. (e.g. hysteresis or some delays). <code>bootDelay</code> parameter <sup><code>FW 4.0.0+</code></sup> is specified in seconds [s]\n\n<b>Example:</b>\n {\n \"conditions\": {\n \"bootDelay\": 20,\n \"operator\": \"OR\",\n \"WDT/test2/FAIL\": true,\n \"INPUTS/1/STATE\": \"off\"\n },\n \"actions\": {\n \"OUTPUTS/1/ACTION\": 4\n }\n }\n\n=== Available forms of conditions ===\n* <code>\"PAB/PAB1_1/IN\": true</code> = <code>PAB1_1</code> is in specified interval\n* <code>\"PAB/PAB_ZONE_1/ZONE\": 1</code> = <code>PAB_ZONE_1</code> is in zone 1\n* <code>\"PAB/CR13_PAB/DAY\": true</code> = daylight for current time on defined location (for use with DAYLIGHT-type PAB)\n* <code>\"WDT/WATCHDOG_1/FAIL\": true</code> = <code>WATCHDOG_1</code> is in ERROR state\n* <code>\"OUTPUTS/1/STATE\": \"on\"</code> = Output 1 is currently ON (1)\n* <code>\"INPUTS/1/STATE\": \"off\"</code> = DI1 is currently OFF (0)\n* <code>\"SYSTEM/DEVICE_POWER_UP\": true</code> = device boot after power-cut (external power outage, lower-level system (MCU) firmware update)<sup><code>FW 4.0.0+</code></sup>\n* <code>\"SYSTEM/DEVICE_BOOT\": true</code> = device boot after soft restart (internal watchdog or periodic restart) - no Power Outage, state of outputs not changed<sup><code>FW 4.0.0+</code></sup>\n* <code>\"NETWORK/STATE\": \"down\"</code> = indicates network connection status, states: \"up\" - device is connected, \"down\" - device is not connected<sup><code>FW 4.0.0+</code></sup>\n* <code>\"NETWORK/ETHERNET/STATE\": \"down\"</code> = indicates network connection status, states: \"up\" - device is connected, \"down\" - device is not connected<sup><code>FW 4.0.0+</code></sup>\n* <code>\"NETWORK/WIFI/STATE\": \"down\"</code> = indicates network connection status, states: \"up\" - device is connected, \"down\" - device is not connected<sup><code>FW 4.0.0+</code></sup>\n\n== FILTER (mask)== \nThe filter field specifies when the Rule is active. It acts as a mask If filter in certain time is not true, the action wont be executed even when conditions are fulfilled. Multiple filters can be set for one rule. For the rule to be active all filters must be true.\n\nAbove that the FILTER can be applied (scheduler, DI (Digital Input) or DO (Output) state). \n\n=== Available forms of filters ===\n* <code>\"SCHEDULE/TestSchedule/ACTIVE\": true</code> = <code>TestSchedule</code> is active\n* <code>\"OUTPUTS/1/STATE\":\"on\"</code> = Output 1 is ON\n\n\n== ACTION ==\nACTIONS part in the Rule contains list of several actions when condition(s) + filter(s) are valid. \n\nThe actions can change output states (turn OFF, turn ON, toggle, etc.) or trigger an Alarm state in NETIO Cloud. \nThere is one Alarm state reserved per each one output in the NETIO Cloud premium (only).\nYou can verify your configuration and check sending of the Output Alarm in the Device Log. \n\n=== Available forms of actions ===\n* <code>\"OUTPUTS/1/ACTION\": 0</code> = Turn OFF Output 1\n* <code>\"OUTPUTS/6/ACTION\": 2</code> = Short OFF Output 6\n* <code>\"CLOUD/OUTPUT/1/ALARM\": \"${COND_RESULT}\"</code> = Set condition output value to the alarm (Turns the alarm ON or OFF based on condition evaluation)\n\n''Note: The variable <code>${COND_RESULT}</code> contains output value of the given condition. It takes values 0 (condition not met) or 1 (condition met). It can be used for dynamic switching the alarm in Cloud ON/OFF depending on current state of the PAB.''\n\n\n=== Standard output actions per each output ===\n* 0 = TURN OFF\n* 1 = TURN ON\n* 2 = SHORT OFF\n* 3 = SHORT ON\n* 4 = TOGGLE - Changes the status from ON to OFF and vice versa\n* 5 = NOTHING (placeholder, DO NOT USE)\n\n== Structure ==\n\n{| class=\"wikitable\"\n|-\n! Variable\n! Value\n! Description \n|-\n| conditions\n| Eg: `\"PAB/PAB1_1/IN\": true`\n| Conditions definition. Relationship between conditions is defined by <code>operator</code> (AND/OR)\n|-\n| operator\n| AND/OR\n| Optional. Specifies relationship between conditions. <code>AND</code> = all conditions must apply at the same time. <code>OR</code> = at least one condition must apply. If missing, defaults to <code>OR</code>\n|-\n| filters\n| Eg: <code>\"SCHEDULE/MY_SCHEDULE/ACTIVE\": true<code/>\n| Filter definition. For multiple filter conditions, the relationship between them is always <code>AND</code>\n|-\n| actions\n| Eg: <code>\"CLOUD/OUTPUT/1/ALARM\": \"${COND_RESULT}\"</code>\n| Actions definition. All actions defined here will be triggered when conditions (and filters) are met\n|}\n\nCondition names are based on user-specified names and their types:\n* For PABs, the name has structure: <code>PAB/pab_name/pab_output_value</code> (TRUE/FALSE or int)\n* For WatchDogs, the name has structure: <code>WDT/watchdog_name/FAIL</code>\n\n== Sequence <sup><code>FW 4.0.0+</code></sup> ==\n\nSequences bring extended usability to ACTIONS. In addition to basic actions that are triggered right after certain condition (conditions) are met, sequence can be defined to enable repetitive actions.\n\n=== Configuration variables ===\n\n{| class=\"wikitable\"\n|-\n! Variable\n! Value\n! Description \n|-\n| repeat\n| int (0 to 1-MAX_INT) / true\n| How many times should the sequence repeat. Set <code>0</code> or <code>true</code> for indefinitely (can only be turned off by disabling the rule).\n|-\n| actions\n| \n| Standard actions as defined in section [[#ACTION| ACTION]]\n|-\n| delay\n| int [ms] in multiples of 100ms\n| '''May''' be set along with actions to be executed. Defines time the sequence waits '''after''' performing the action. The value is rounded up to hundreds of miliseconds (e.g. 85ms -> 100ms, 235ms -> 300ms).\n|}\n\n=== Example ===\nThis example triggers one-time action along with sequence of other actions and repeats 10-times after meeting certain condition.\n:'''Condition''': WatchDog '''CR01_WDT''' fails (receives timeout from defined address)\n:'''One-time action''': Restart output No. 2 (action 2 = short off/restart)\n:''' Sequence ''': Following steps repeat 10-times\n:# Turn output No. 1 ON \n:# Wait 10s \n:# Turn output No. 1 OFF\n:# Wait 2s\n:# Repeat\n\n <nowiki>\n{\n \"conditions\": {\n \"WDT/CR01_WDT/FAIL\": true\n },\n \"actions\": {\n \"OUTPUTS/1/ACTION\": 2,\n \"sequence\":{\n \"repeat\": 10,\n \"actions\":[\n {\"OUTPUTS/1/ACTION\": 1, \"delay\":10000},\n {\"OUTPUTS/1/ACTION\": 0, \"delay\":2000}\n ]\n }\n }\n}</nowiki>"
}
]
},
"138": {
"pageid": 138,
"ns": 0,
"title": "Rules Complete Examples",
"revisions": [
{
"contentformat": "text/x-wiki",
"contentmodel": "wikitext",
"*": "The concept of NETIO Conditions (PAB & WatchDog) & Rules is a set of prepared detections (Conditions) and Rules that act upon them. They are implemented directly in NETIO PDU devices. \n\n== CR01 - WatchDog (ping) to 1 IP address | default in FW 3.2.3 ==\nThe WatchDog functionality is used to monitor connectivity to specified IP address (or URL) by sending PING request to it.\n\nThe ping in this example is sent every 60s and waits 5s for the device to respond. If the ping fails, Watchdog returns <code>false</code> and restarts (ACTION: 2 = SHORT OFF) device connected to first output. After restart, it waits 120 seconds and starts monitoring again. If the device does not respond, WatchDog remains in ERROR state until next successful ping.\n\n===WatchDog definition===\n\nWatchDog name: '''CR01_WDT'''\n\n <nowiki>\n{\n \"target\": \"192.168.1.5\",\n \"pingInterval\": 60,\n \"timeout\": 5,\n \"maxTimeouts\": 0,\n \"timeToReboot\": 120,\n \"maxRestarts\": -1\n}</nowiki>\n\n===Rule definition===\n \nRule name: '''CR01_RULE'''\n\n <nowiki>\n{\n \"conditions\": {\n \"WDT/CR01_WDT/FAIL\": true\n },\n \"actions\": {\n \"OUTPUTS/1/ACTION\": 2\n }\n}</nowiki>\n\n== CR02 - Digital Inputs (Push button to Toggle Outputs 1 and 2) | default in FW 3.2.3 ==\n\nRule is used for managing outputs in response to change of Digital Inputs (DI) state. Rule monitors state of first DI. When DI switches from OFF (0) to ON (1), Rule switches (toggles) Outputs 1 & 2 to their opposite states (ACTION 4 = TOGGLE).\n\n===Rule definition===\n\nRule name: '''CR02_RULE'''\n\n <nowiki>\n{\n \"conditions\": {\n \"INPUTS/1/STATE\": \"on\"\n },\n \"actions\": {\n \"OUTPUTS/1/ACTION\": 4,\n \"OUTPUTS/2/ACTION\": 4\n }\n}</nowiki>\n\n== CR03 - Load Watchdog (Restart device if it's more than 2 minutes in IDLE mode) | default in FW 3.2.3 ==\nRule monitors load (Watts) on Output 1. If the load is between 1-20W for at least 2 minutes, it restarts (ACTION 2 = SHORT OFF) the output.\nExample uses PAB (Power Analysis Block) functionality to determine if measured value (load in our case) lies in given range for a period of time. When it does, defined Rule triggers device restart.\n\n===PAB definition===\n\nPAB name: '''CR03_PAB'''\n <nowiki>\n{\n \"type\": \"RANGE\",\n \"source\": \"OUTPUTS/1/LOAD\",\n \"lowerBound\": 1,\n \"upperBound\": 20,\n \"timeHysteresis\": 120\n}</nowiki>\n\n===Rule definition===\n\nRule name: '''CR03_RULE'''\n\n <nowiki>\n{\n \"conditions\": {\n \"PAB/CR03_PAB/IN\": true\n },\n \"actions\": {\n \"OUTPUTS/1/ACTION\": 2\n }\n}</nowiki>\n\n== CR04 - Load Watchdog with alarm to Cloud ==\nRule monitors load (Watts) on Output 1. If the load is between 1-20W for at least 30 minutes, it restarts (ACTION 2 = SHORT OFF) the output. In addition, it triggers an alarm in NETIO Cloud, which sends a notification to specified email address.\nThis example needs a NETIO Cloud account with Premium version active for first output. There also has to be email notification enabled for the output.\n\nExample uses PAB (Power Analysis Block) functionality to determine if measured value (load in our case) lies in given range for a period of time. When it does, defined Rule triggers device restart and sends alarm to Cloud.\n\n===PAB definition===\n\nPAB name: '''CR04_PAB'''\n \n <nowiki>\n{\n \"type\": \"RANGE\",\n \"source\": \"OUTPUTS/1/LOAD\",\n \"lowerBound\": 1,\n \"upperBound\": 20,\n \"timeHysteresis\": 1800\n}</nowiki>\n\n\n===Rule definition===\n\nRule name: '''CR04_RULE'''\n\n <nowiki>\n{\n \"conditions\": {\n \"PAB/CR04_PAB/IN\": true\n },\n \"actions\": {\n \"OUTPUTS/1/ACTION\": 2,\n \"CLOUD/OUTPUT/1/ALARM\": \"${COND_RESULT}\"\n }\n}</nowiki>\n\n== CR05 - Load Watchdog with zones (indicate OFF / IDLE / RUN mode by switched on output)==\nRule monitors load (Watts) on Output 1. Measured load is then classified to several zones defined with thresholds (limit values). Depending on the zone in which the measured load is currently located, different actions can be triggered. Load value has to be between defined threshold for at least 10seconds in order to be placed to respective zone.\nExample is composed of one PAB that classifies the zones and three Rules for 3 separate actions. Actions do the following:\n* Output 1 load lower than 1W: Output 2 = ON\n* Output 1 load between 1-20W: Output 3 = ON\n* Output 1 load between 20-200W: Output 4 = ON\n\n===PAB definition===\n\nPAB name: '''CR05_PAB'''\n\n <nowiki>\n{\n \"type\": \"ZONES\",\n \"source\": \"OUTPUTS/2/CURRENT\",\n \"thresholds\": [\n 1,\n 20,\n 200\n ],\n \"timeHysteresis\": 10\n}</nowiki>\n\n===Rules definitions===\n\nRule 1 name: '''CR05_RULE_1'''\n\n <nowiki>\n{\n \"conditions\": {\n \"PAB/NR05_PAB/ZONE\": 0\n },\n \"actions\": {\n \"OUTPUTS/2/ACTION\": 1,\n \"OUTPUTS/3/ACTION\": 0,\n \"OUTPUTS/4/ACTION\": 0\n }\n}</nowiki>\n\nRule 2 name: '''CR05_RULE_2'''\n\n <nowiki>\n{\n \"conditions\": {\n \"PAB/CR05_PAB/ZONE\": 1\n },\n \"actions\": {\n \"OUTPUTS/2/ACTION\": 0,\n \"OUTPUTS/3/ACTION\": 1,\n \"OUTPUTS/4/ACTION\": 0\n }\n}</nowiki>\n\nRule 3 name: '''CR05_RULE_3'''\n\n <nowiki>\n{\n \"conditions\": {\n \"PAB/CR05_PAB/ZONE\": 2\n },\n \"actions\": {\n \"OUTPUTS/2/ACTION\": 0,\n \"OUTPUTS/3/ACTION\": 0,\n \"OUTPUTS/4/ACTION\": 1\n }\n}</nowiki>\n\n== CR06 - WatchDog for 2 IPs (Verify IP connectivity outage with 2 IPs)==\nThe WatchDog functionality is used to monitor connectivity to specified IP address (or URL) by sending PING request to it.\n\nIn this example, we monitor two IPs and we want to restart device connected to Output 1 if none of the addresses reply.\nThe ping for both IPs is sent every 30s and waits 5s for device to respond. There are 5 consecutive timeouts tolerated before the ping is considered as failed. When the ping fails, Watchdog returns <code>false</code> and remains in ERROR state.\n\nIn case both of the defined WatchDogs are in ERROR state, the Rule is triggered which then restarts Output 1.\n\n===WatchDogs definition===\n\nWatchDog name: '''CR06_WDT_1'''\n\n <nowiki>\n{\n \"target\": \"192.168.1.51\",\n \"pingInterval\": 30,\n \"timeout\": 5,\n \"maxTimeouts\": 5,\n \"timeToReboot\": 120,\n \"maxRestarts\": -1\n}</nowiki>\n\nWatchDog name: '''CR06_WDT_2'''\n\n <nowiki>\n{\n \"target\": \"192.168.1.52\",\n \"pingInterval\": 60,\n \"timeout\": 5,\n \"maxTimeouts\": 5,\n \"timeToReboot\": 120,\n \"maxRestarts\": -1\n}</nowiki>\n\n===Rule definition===\n \nRule name: '''CR06_RULE'''\n\n <nowiki>\n{\n \"conditions\": {\n \"operator\": \"AND\",\n \"WDT/CR06_WDT_1/FAIL\": true,\n \"WDT/CR06_WDT_2/FAIL\": true\n },\n \"actions\": {\n \"OUTPUTS/1/ACTION\": 2\n }\n}</nowiki>\n\n== CR07 - Synchronized outputs states during working hours ==\nRule keeps track of first output state and when it changes, it switches output 2 to the same state. However, we want this synchronization only to work during working hours. We define the time with Schedule functionality and use it as a filter (mask) in Rules. Schedule can be defined manually or imported as a configuration file.\n\n===Schedule definition===\n\nSchedule name: '''CR07_SCHEDULE'''\n\n[[File:NR07_Schedule.png|NR070 Schedule]]\n\n===Rule definition===\n\nRule name: '''CR07_RULE'''\n\n <nowiki>\n{\n \"conditions\": {\n \"OUTPUTS/1/STATE\": \"on\"\n },\n \"filters\": {\n \"SCHEDULE/CR07_SCHEDULE/ACTIVE\": true\n },\n \"actions\": {\n \"OUTPUTS/2/ACTION\": \"${COND_RESULT}\"\n }\n}</nowiki>\n\n== CR08 - Load Watchdog -> Turn output ON after period of time ==\n\nIn this example we want to measure load on output 1 and indicate when the power is abnormally low for a period of time by switching device on Output 2 ON (could be control light, sound alarm etc.).\n\nIn PAB we define indication for low power usage (1-20W) that is measured for period of 30 minutes (1800 seconds).\nIn Rule we define switching Output 2 = ON (ACTION 1 = TURN ON) based on fulfilled PAB condition. This set up counts with human interaction after the Rule action gets processed. (e.g. restarting/replacing device on Output 1 and turning Output 2 OFF).\nIt is possible to alter this behavior in such a way that the control light (Output 2) turns automatically OFF when load on Output 1 returns to standard values, i.e. higher than 20W (device gets repaired/replaced) or drops to 0W (device was removed or Output 1 turned OFF). This setup is defined in Rule '''NR08_ALT'''\n\n===PAB definition===\n\nPAB name: '''CR08_PAB'''\n <nowiki>\n{\n \"type\": \"RANGE\",\n \"source\": \"OUTPUTS/1/LOAD\",\n \"lowerBound\": 1,\n \"upperBound\": 20,\n \"timeHysteresis\": 1800\n}</nowiki>\n\n===Rule definition===\n\nRule name: '''CR08_RULE'''\n\n <nowiki>\n{\n \"conditions\": {\n \"PAB/CR08_PAB/IN\": true\n },\n \"actions\": {\n \"OUTPUTS/2/ACTION\": 1\n }\n}</nowiki>\n\nRule name: '''CR08_RULE_ALT'''\n\n <nowiki>\n{\n \"conditions\": {\n \"PAB/CR08_PAB/IN\": true\n },\n \"actions\": {\n \"OUTPUTS/2/ACTION\": \"${COND_RESULT}\"\n }\n}</nowiki>\n\n== CR09 - Digital Inputs with Schedule ==\n\nExamples shows usage when we want to detect switching of Digital Input to ON state (1) but to (not) react only during specified hours (e.g. outside of working hours).\nReaction hours are defined with Schedule functionality. Schedule can be defined manually or imported as a configuration file.\n\n===Schedule definition===\n\nSchedule name: '''CR09_SCHEDULE'''\n\n===Rule definition===\n\nRule name: '''CR09_RULE'''\n\n <nowiki>\n{\n \"conditions\": {\n \"INPUTS/1/STATE\": \"on\"\n },\n \"filters\": {\n \"SCHEDULE/CR09_SCHEDULE/ACTIVE\": false\n },\n \"actions\": {\n \"OUTPUTS/1/ACTION\": 2\n }\n}</nowiki>\n\n== CR10 - TURN OFF Output 1 before midnight ==\nRule in a combination with Schedule can be used to ensure a specified output will be turned off at the end of the day (or any other time).\nSchedule in this application is '''NOT''' assigned to the output and acts only as a \"trigger\" for launching the Rule action.\n\n===Schedule definition===\n\nSchedule name: '''off_before_midnight'''\n\nSchedule configuration: Schedule is configured to have '''intervals every day from 23:59 to 24:00'''. In this configuration, the output turns of at 23:59.\n\n[[File:cr10_schedule.png|CR10 Schedule]]\n\n===Rule definition===\n\nRule name: '''CR10_RULE'''\n <nowiki>\n{\n \"conditions\": {\n \"SCHEDULE/off_before_midnight/ACTIVE\": true\n },\n \"filters\": {\n \"OUTPUTS/1/STATE\": \"on\"\n },\n \"actions\": {\n \"OUTPUTS/1/ACTION\": 0\n }\n}</nowiki>\n\n== CR11 - Total load (8QS)==\nCR11_PAB\n\n <nowiki>\n{\n \"type\": \"RANGE\",\n \"source\": \"OUTPUTS/TOTAL/LOAD\",\n \"lowerBound\": 30,\n \"upperBound\": 100,\n \"timeHysteresis\": 3\n}</nowiki>\n\n\n <nowiki>\n{\n \"conditions\": {\n \"operator\": \"OR\",\n \"PAB/total_outputs/IN\": true\n },\n \"actions\": {\n \"OUTPUTS/1/ACTION\": 4,\n \"CLOUD/OUTPUT/1/ALARM\": 1\n }\n}</nowiki>\n\n== CR12 - Negative load ==\nCR12_PAB\n\n <nowiki>\n{\n \"type\": \"RANGE\",\n \"source\": \"OUTPUTS/1/LOAD\",\n \"lowerBound\": -400,\n \"upperBound\": 0,\n \"timeHysteresis\": 2\n}</nowiki>\n\n\n <nowiki>\n{\n \"conditions\": {\n \"PAB/negative/IN\": true\n },\n \"actions\": {\n \"OUTPUTS/3/ACTION\": 4,\n \"OUTPUTS/4/ACTION\": 4\n }\n}</nowiki>\n\n\n== CR13 - Actions based on daylight <sup><code>FW 4.0.0+</code></sup>==\nTurns output ON/OFF based on sunrise/sunset times of set location.\nIn this example, output 1 gets turned on one hour before (-60 minutes) sunrise and turns off one hour (60 minutes) after sunset. Location is se for NETIO Products headquarters (U pily 103, Prague, CZ). Elevation is set as 247 meters, above sea level.\n\n=== PAB definition ===\nPAB name: '''CR13_PAB'''\n\n <nowiki>\n{\n \"type\": \"DAYLIGHT\",\n \"longitude\": \"14.4129433E\",\n \"latitude\": \"50.0058144N\",\n \"altitude\": 247,\n \"sunriseDelay\": -60,\n \"sunsetDelay\": 60\n}\n</nowiki>\n\n=== Rule definition ===\nRule name: '''CR13_RULE'''\n\n <nowiki>\n{\n \"conditions\": {\n \"PAB/CR13_PAB/DAY\": true\n },\n \"actions\": {\n \"OUTPUTS/1/ACTION\": \"${COND_RESULT}\"\n }\n}\n</nowiki>\n\n== CR14 - Actions based on Power-UP <sup><code>FW 4.0.0+</code></sup>== \n\nThis example describes rule that evaluates after device start-up. Generally, there are 2 options for setting up conditions: \n* SYSTEM/DEVICE_POWER_UP - device boot after power-cut\n\nCondition in rule description below reacts to device boot after power-cut. When device first starts after regaining power, it sends alarm to output 1 in NETIO Cloud service.\n\n=== Rule definition ===\nRule name: '''CR14_RULE'''\n\n <nowiki>\n{\n \"conditions\": {\n \"SYSTEM/DEVICE_POWER_UP\": true\n },\n \"actions\": {\n \"CLOUD/OUTPUT/1/ALARM\": \"${COND_RESULT}\"\n }\n}\n</nowiki>\n\n== CR15 - Sunrise/sunset addaptive schedule with deep night off <sup><code>FW 4.0.1+</code></sup>==\nControl output ON/OFF based on sunrise/sunset times of set location and combine it with standard schedule using rules.\n\nIn this example, output 1 gets turned on every day at 6:00 and switch off 30 minutes after sunrise and gets on again 30 minutes before sunset and turns off at midnight. This is an example of combination PAB output with standard schedule and mask the result of PAB with intervals defined in schedule.\n\nFollowing combination creates dynamic variable input with static scheduler overlay and the behaviour can be simply chosen by logical equations.\n\n=== 1. Configure schedule ===\nCreate a schedule with name \"christmas_off\" and create intervals 00:00 to 06:00 every day. No need to activate the scheduler for any output. Just define it.\n\n[[File:CR15 schedule christmas off.png]]\n\n=== 2. Create sunrise/sunset PAB ===\n\nFollowing PAB will have <code>true</code> result during the day between sunrise with 30 minutes delay and 30 minutes before sunset set for location of NETIO Products headquarters (U pily 103, Prague, CZ). Elevation is set as 247 meters, above sea level. This result will be used in condition in rules to detect sunrise and sunset.\n\nPAB name: '''daylight'''\n\n <nowiki>\n{\n \"type\": \"DAYLIGHT\",\n \"longitude\": \"14.4129433E\",\n \"latitude\": \"50.0058144N\",\n \"altitude\": 247,\n \"sunriseDelay\": 30,\n \"sunsetDelay\": -30\n}\n</nowiki>\n\n=== 3. Create RULE for output ON ===\n\nIn this rule is definition when the output 1 should be enabled (ON). It is combination of two conditions of PAB and scheduler.\n\n'''This code is saying:''' When is night ( day is false = <code>\"PAB/daylight/DAY\": false,</code>) and in paralel schedule is not active (set to be off = <code>\"SCHEDULE/christmas_off/ACTIVE\": false</code>) the result is <code>true</code> and following action (set output 1 to ON <code>\"OUTPUTS/1/ACTION\": 1</code>) is executed. \n\nRULE name: '''outON'''\n\n <nowiki>\n{\n \"conditions\": {\n \"operator\": \"AND\",\n \"PAB/daylight/DAY\": false,\n \"SCHEDULE/christmas_off/ACTIVE\": false\n },\n \"actions\": {\n \"OUTPUTS/1/ACTION\": 1\n }\n}\n</nowiki>\n\n=== 4. Create RULE for output OFF ===\n\nIn this rule is definition when the output 1 should be disabled (OFF). It is again combination of two conditions of PAB and scheduler.\n\n'''This code is saying:''' When it is day now ( day is true = <code>\"PAB/daylight/DAY\": true,</code>) or the schedule is active (set to be on = <code>\"SCHEDULE/christmas_off/ACTIVE\": true</code>) the result is <code>true</code> and following action (set output 1 to OFF <code>\"OUTPUTS/1/ACTION\": 0</code>) is executed. \n\nRULE name: '''outOFF'''\n\n <nowiki>\n{\n \"conditions\": {\n \"operator\": \"OR\",\n \"PAB/daylight/DAY\": true,\n \"SCHEDULE/christmas_off/ACTIVE\": true\n },\n \"actions\": {\n \"OUTPUTS/1/ACTION\": 0\n }\n}\n</nowiki>"
}
]
}
}
}
}