Rules - Revision history

Tbezstarosta: /* A representative deployment: */

2026-08-11T07:37:44Z

‎A representative deployment:

Tbezstarosta: /* A representative deployment: */

2026-08-11T07:37:09Z

‎A representative deployment:

Tbezstarosta: /* A representative deployment: */

2026-08-11T07:36:33Z

‎A representative deployment:

Tbezstarosta: /* A representative deployment: */

2026-08-11T07:34:20Z

‎A representative deployment:

Tbezstarosta: /* A representative deployment: */

2026-08-11T07:33:34Z

‎A representative deployment:

Tbezstarosta: /* A representative deployment: */

2026-08-11T07:33:16Z

‎A representative deployment:

Tbezstarosta: /* COOLDOWN functionality */

2026-08-11T07:29:03Z

‎COOLDOWN functionality

Tbezstarosta: /* A representative deployment: */

2026-08-11T07:02:21Z

‎A representative deployment:

Tbezstarosta: /* COOLDOWN functionality */

2026-08-11T07:01:10Z

‎COOLDOWN functionality

Tbezstarosta: /* COOLDOWN functionality */

2026-08-11T07:00:21Z

‎COOLDOWN functionality

@@ Line 49: / Line 49: @@
 === A representative deployment: ===
 Controlled device (e.g. an AV matrix switcher) drives a GPIO output that is wired through a relay into a NETIO PDU digital input (DI). Immediately after the device reboots, the GPIO can briefly assert a spurious/undefined signal before settling — this transient is picked up by the relay and closes the contact on the NETIO DI, satisfying the Rule condition.
 [[File:NETIO Cooldown Diagram 50pct.png |NETIO Cooldown Diagram ]]
-NETIO Cooldown Diagram 50pct.png
 Without a cooldown condition, the Rule fires on every such transition:

@@ Line 50: / Line 50: @@
 Controlled device (e.g. an AV matrix switcher) drives a GPIO output that is wired through a relay into a NETIO PDU digital input (DI). Immediately after the device reboots, the GPIO can briefly assert a spurious/undefined signal before settling — this transient is picked up by the relay and closes the contact on the NETIO DI, satisfying the Rule condition.
-Schedule name: '''CR07_SCHEDULE'''
+[[File:NETIO Cooldown Diagram 50pct.png |NETIO Cooldown Diagram ]]
 NETIO Cooldown Diagram 50pct.png

@@ Line 52: / Line 52: @@
 Schedule name: '''CR07_SCHEDULE'''
+NETIO Cooldown Diagram 50pct.png
 Without a cooldown condition, the Rule fires on every such transition:

← Older revision		Revision as of 07:34, 11 August 2026
Line 52:		Line 52:
	Schedule name: '''CR07_SCHEDULE'''		Schedule name: '''CR07_SCHEDULE'''

−	~~[[File:NETIO Cooldown Diagram.png\|NR070 Schedule]]~~

← Older revision		Revision as of 07:33, 11 August 2026
Line 52:		Line 52:
	Schedule name: '''CR07_SCHEDULE'''		Schedule name: '''CR07_SCHEDULE'''

−	~~<img src="~~[[File:NETIO Cooldown Diagram.png\|NR070 Schedule]]~~" style="width: 50%; height: auto;">~~	+	[[File:NETIO Cooldown Diagram.png\|NR070 Schedule]]

← Older revision		Revision as of 07:02, 11 August 2026
Line 58:		Line 58:

	Adding a cooldown condition (e.g. 90 s) to the Rule blocks re-evaluation for the specified window immediately after the Rule fires. Since 90 s exceeds the device's full reboot + stabilization time, the boot-time GPIO transient occurring after the forced power cut falls inside the cooldown window and is ignored. The device is therefore allowed to complete a full, uninterrupted boot cycle before the Rule can trigger again		Adding a cooldown condition (e.g. 90 s) to the Rule blocks re-evaluation for the specified window immediately after the Rule fires. Since 90 s exceeds the device's full reboot + stabilization time, the boot-time GPIO transient occurring after the forced power cut falls inside the cooldown window and is ignored. The device is therefore allowed to complete a full, uninterrupted boot cycle before the Rule can trigger again
		+
		+	=== CoolDown family ===

	*<code>"cooldown"</code> This is the basic cooldown condition which comes into effect whenever the rule activates (the conditions turn from `false` to `true`) and the actions block gets evaluated. This then pauses the evaluation of the rule for the specified time.		*<code>"cooldown"</code> This is the basic cooldown condition which comes into effect whenever the rule activates (the conditions turn from `false` to `true`) and the actions block gets evaluated. This then pauses the evaluation of the rule for the specified time.

@@ Line 47: / Line 47: @@
 The "cooldown" family of conditions serve as a way to prevent unwanted repeat triggering of rules which have their conditions met and often changing. This is achieved by pausing rule execution for a specified time after the condition state changes based on the specific cooldown condition used. Only one cooldown condition can be present in a `conditions` block at any time. The cooldown period doesn't activate while the rule is already in a cooldown period, there needs to be a new cooldown triggering event happening after the cooldown period is over.
-=== A representative deployment: === a controlled device (e.g. an AV matrix switcher) drives a GPIO output that is wired through a relay into a NETIO PDU digital input (DI). Immediately after the device reboots, the GPIO can briefly assert a spurious/undefined signal before settling — this transient is picked up by the relay and closes the contact on the NETIO DI, satisfying the Rule condition.
+=== A representative deployment: ===
 Without a cooldown condition, the Rule fires on every such transition:
 * <code> Device reboots → GPIO glitch → relay closes → DI triggers the Rule.</code>
-* <code>Rule action cuts power to the device for a fixed interval (e.g. 30 s) to force a clean restart.</code>
+* <code> Rule action cuts power to the device for a fixed interval (e.g. 30 s) to force a clean restart.</code>
-* The power cut itself causes the device to reboot, which reproduces the GPIO glitch on the next boot.
+* <code> The power cut itself causes the device to reboot, which reproduces the GPIO glitch on the next boot.</code>
-* Steps 1–3 repeat indefinitely (observed cycle period ≈ 60–61 s), and the device never completes an uninterrupted boot sequence.
+* <code> Steps 1–3 repeat indefinitely (observed cycle period ≈ 60–61 s), and the device never completes an uninterrupted boot sequence.</code>
 Adding a cooldown condition (e.g. 90 s) to the Rule blocks re-evaluation for the specified window immediately after the Rule fires. Since 90 s exceeds the device's full reboot + stabilization time, the boot-time GPIO transient occurring after the forced power cut falls inside the cooldown window and is ignored. The device is therefore allowed to complete a full, uninterrupted boot cycle before the Rule can trigger again