Hinweis für die Textformat-Version; um diese Version im PDF Format zu lesen, laden Sie bitte https://www.dk1ri.de/myc/Rules.pdf

MYC Rules

Author: DK1RI
Version V02.00.02 20250311
This project can be found in https://github.com/dk1ri  also.

Introduction

The program [17] will be integrated into the commandrouter. Corrections and enhancements will be found there [7]
Because some condition could not be described with rules defined in this document in version earlier than V02.00.01, the syntax was modified and may be not compatible with the earlier version. The LD with version V02.00.01 and later will support the new syntax. The rules of existing FUs (by DK1RI) will be changed if necessary.
 
This paper describes the syntax of rules of the MYC system.
For more details of the MYC system please check the reference.

Definitions and formats

see https://dk1ri.de/myc/Definitions.txt or https://dk1ri.de/myc/Definitions.pdf

Some explanation /General Rules behavior

Rules announcements start with “R” or “S” or “Q”
“R” rules are valid always, “S” rules are used during configuration only and are not forwarded by the CR. “Q” rules are used for login. The LD uses “R” and “S” rules and do not distinguish between “R” and “S” rules.
Rules are defined by FU and RU.

“R” , “S” rules

A “R” / “S” rule may have one or more of these functions:
        ? Rules will block commands but do not modify them.
        ? All commands can be blocked
        ? If a command has more than one parameter, and not all combinations are allowed, this will be defined by a rule. This cannot be defined by the command announcement.
        ? By default all commands are working always. A rule will show, when a command is blocked under a specific status or condition. 
        ? Usually commands are not executed by change of a status of another FU. A rule can initiate this: eg the device can be switched off under special conditions.
        ? The LD can once send a fixed command if a special status is set, but cannot vary the command depending on the status.
        ? A rule cannot use descriptions. It uses transmitted valued only (may be changed later)
        ? Rules are not checked completely for errors or inconsistencies! Wrong rules may crash the program!
        ? A rule can restrict a range of numeric parameters used by commands.
	
Each rule is one announcement line (for FU) or an (MYC string) answer or info of an  “an” command (for RU).
All “R” rules are always handled by the LD in the sequence it get the rules, starting with rules of FU.
By default all commands are working. If a command should be blocked, there must be a rule. 
These rules are used by the LD, which have the status for switch, range and array memory commands of the system at any time and know all “R” and “S” rules and block / initiate commands accordingly. The LD has no knowledge of the content the memories of the devices ( of “om”, “am”, “of, “af” commands); so rules cannot have the content of these memories as a condition for blocking any command, This may be changed later.
If a command should be generated by the LD under some conditions, use R;<c> … Example is a reset under some conditions. The command will be executed on time only.
The LD can send a command after another command. Example is a webserver, where a loading command is necessary to read a page. This “AFTER” rule should follow directly the originating rule. The condition of the originating command must be true for the “AFTER” rule to be active. If the “AFTER” has no condition, the command is sent with no further restrictions.
The “oo” and “ou” command has a temporary effect on a device only, So the status cannot be stored for these commands. There may be a rule with a condition of this command (without parameter) to initiate another fixed command.
If different commands work for the same function of a device (one “op” command changing the location and another changing the speed) the actual status of the LD may be wrong after the command. In these cases a rule, that create a read command, may help or the device send infos after the command.
Neither the LD nor the SK do this automatically.
“oa” and “aa” commands have a limited number of memory and the status can be used as condition. 
“ob” and “ab” in rules are not supported now (may be later).
For answer commands with corresponding operating commands the token of the answer command or the operate command can be used for conditions. The LD should have the same status.
The SK may observe rules or not. The CR ignore rules but ignores commands with wrong number of parameters or wrong format. The LD requires commands with correct format.
Some limitation for the SK within a command should be described within the announcement of that command by <des>. The LD (and the CR) do not use <des>, it uses transmitted values only.

A FU will have rule announcements to inform about dependencies, which exist between the commands and status within the FU.
If there are dependencies between different devices,  a special rules-device RU will provide these rules.

The syntax of the rules should be very simple. Lines are readable, because they must be easily programmed as a part of the announcements of FUs.

"Q"-rules
“Q” rules are produced by the RU only and sent to the CR only and are not forwarded. They are used by the CR only, because the CR knows the interface of the user. They are used for user management.
As default the command-router allow all commands on all interfaces. The CR can block or allow commands or a complete device, if necessary, for a specific user using “Q” rules.

Format:
Q;<username>;<c>[TO<c>] [<c>]….	allow command (used together with Q;* !*)
Q;<username>;[!]<c>[TO<c>] [!<c>]….	allow command (used together with Q;* *)
A basic command-token of a device only means all token of the device.
One Q rule per user.

special rules, as first “Q” rule:
Q;* !*				login required for all. All command forbidden by default
Q;* *				login required for all. All command allowed by default
These two rules missing:	 (default) All commands, which are not mentioned in “Q” rules, are 
				allowed for all users without account (default). For users with account
				Q;* !* is valid (ie commands have to be allowed)

Rules syntax for R” and “S” rules

<left side> IF|UNLESS|AFTER|IN <right side>

left side:
!$<c>[ !$<c>]...			<c> is blocked
!!$<c>					used together with “AFTER” only, <c> is not blocked
<valid command_string>		One command will be sent to FU

IF|UNLESS|AFTER			separate left side and right side
					A “AFTER” rule should follow a rule for initiating.  Left side of 
					an “AFTER” is a direct command always. Multiple “AFTER” 						rules are possible. Remember, that the decision for blocking is 
					made after checking all rules for that command. So, if here is a 
					rule blocking after these “AFTER” rule, this is blocked as well.

right side:
<condition>[<logical operator>[<logical operator>]..<condition>][….]
Execution is from left to right. Multiple operators are stacked: the last one is executed to the next condition first.

<condition> :
$<commandtoken><|>|=n|s|<calculated value>		for commands with one parameter only
$<commandtoken>&<data>&<data>[&<data>]…		for others
Each <data> describe the condition for matching of the parameter at this position, starting with 0.
Last <data> is the condition for the data of this command. In case of “xo” commands with more than one data parameter the last &<=n>&<data> describe the relative position of this data parameter and the data itself
Wrong number of <data> will not work correctly. 

<data>:					<|>|=<value>
<value>:					n|s|<calculated value>
<calculated_value>				will be defined later
	
				
<logical operator>:
!|OR|AND|(|) 

More than one of these operators can exist in sequence, but few combinations are allowed only and combination of these combinations (as “AND ! ( !“ ):
! (
AND !
AND (
OR !
OR (
( !
((
) OR
) AND
) )

Reserved characters / words

R;|S;|Q;		start of rule line
space			separator

left side:
$				command following
!				block
!!				execute (valid only together with “AFTER” rules)
!$~				block all commands, allowed only one time for a device, skip following 
				rules
!!$~				if !$~ is used by a device, !!$~ must follow (at the end of the rules at least 
				without condition) to avoid blocking for the next device. Has no function 					if it is the last rule. Following rules are used again.
<valid_command>		direct command in hex notation

IF|UNLESS|AFTER		separate left side and right side

right side:
between conditions,  must have separator “ “:
AND				logic operator (OR is implicite)
!				negation
( )				bracketing
within conditions, no space:
$				commandtoken following
&				separator of parameters
<  > =	TO			compare operator, TO can be used for a numeric range only
~				any value
+ - * /				arithmetic operator
( )				bracketing	
n				numeric value
s				string must not contain spaces (this is the separator)

Some hints for conditions

Usually all commands are valid always and can be blocked by rules. A rule describes, if a command will not be executed under some conditions. There is no way to execute blocked commands and direct commands initiated by the RU but blocked by a rule of a device.
A device usually has no rule with direct commands. It may use direct commands for initiating answer commands eg; but can send infos instead. So this should be avoided.
Rules with a direct command are executed once always if conditions are “TRUE”; any command will initiate this. The condition must change to “FALSE” and then to “TRUE” again to execute the command again.
Rules with the same commandtoken on the left side are “Ored” and cannot be “ANDed”. “AND” can be on the right side of a rule only. It is recommended to define all conditions for a commandtoken within a device in one rule only. 
Within a command some parameter define “locations” of a function (the stack for xs and xr commands eg) one defines data. In these cases for the right side  $<commandtoken>$<data>$<data>[$<data>].. must be used always for a condition. For location parameters only those values are used, which are defined by the condition. These <data> deliver “True” always and are “ANDed” with the <data> of the (last) data parameter. If all data of a location should match use ~. ~ with a location will match if data match in any location. 
A restriction of the values of a command can be done with a condition with the commandtoken of the left side. 
The “!~” rule block all commands if the condition is “True”. So rules following are ignored until a 
“!!~” rule is found.
Float values for condition of “xa” commands must be entered in the coded hex format. This may be changed later.

Examples

R;!$2 IF $5=0				means: Command 2 will not work if status of command 5 is 0

R;!$2 IF $6&=0&=1	
					means: Command 2 will not work if status of the location 0 of						command 6 is 0 and data is 1 (example for an “xr” command)

R;!$4 UNLESS $7&0&3500000TO3799999 OR $7$0&7000000TO7199999
					means: Command 4 will work only unless state 7 is in the range 						of .............
R;0102	 AFTER			The command 0102 is sent, if the condition of the previous 						command is true
R;0102	 AFTER !$1=0		The command 0102 is sent, if the condition of the previous 						command is true and the status of command 1 is not 0.
R;0102	 IF ( $1=0 $2=1 ) AND $4=0 command is sent, if $4=0 and $1=0 or $2=1

Q;!* 1 30TO50			commands 1 and 30 to 50 forbidden for all
Q;* 0TO100 !500TO550		0 to 100 allowed, 500 to 550 forbidden for all

Copyright

Dieses Dokument darf unverändert kopiert werden.
Die Ideen in diesem Dokument unterliegen der GPL (Gnu Public Licence,V2) soweit keine früheren, anderen Rechte betroffen sind.
Die Verwendung der Unterlagen erfolgt auf eigene Gefahr; es wird keinerlei Garantie übernommen.
This document can be copied without changes.
The ideas of this document can be used under GPL (Gnu Public License, V2) as long as no earlier other rights are affected.
The usage of this document is on own risk, there is no warranty.

Reference

[1]	https://dk1ri.de/myc/MYC.pdf  (german)
[2]	https://dk1ri.de/myc/MYC.en.pdf
[3]	https://dk1ri.de/myc/Description.txt or https://dk1ri.de/myc/Description.pdf
[4]	https://dk1ri.de/myc/commands.txt or https://dk1ri.de/myc/commands.pdf
[5]	https://dk1ri.de/myc/Reserved_tokens.txt or https://dk1ri.de/myc/Reserved_tokens.pdf
[6]	https://dk1ri.de/myc/Rules.txt or https://dk1ri.de/myc/Rules.pdf
[7]	https://dk1ri.de/myc/commandrouter.txt or https://dk1ri.de/myc/commandrouter.pdf
[8]	https://dk1ri.de/myc/Rules_device.txt or https://dk1ri.de/myc/Rules_device.pdf
[9]	https://dk1ri.de/myc/skin.txt or https://dk1ri.de/myc/skin.pdf
[10]	https://dk1ri.de/myc/logicdevice.txt or https://dk1ri.de/myc/logicdevice.pdf
[11]	https://dk1ri.de/myc/Definitions.txt or https://dk1ri.de/myc/Definitions.pdf
[12]	https://dk1ri.de/myc/spec_version.txt or https://dk1ri.de/myc/spec_version.pdf
[13]	https://dk1ri.de/myc/webserver.txt or https://dk1ri.de/myc/webserver.pdf
[14]	https://dk1ri.de/myc/ki.txt or https://dk1ri.de/myc/ki.pdf
[15]	https://dk1ri.de/myc/communication.txt or https://dk1ri.de/myc/communication.pdf
[16]	https://dk1ri.de/myc/Security.txt or https://dk1ri.de/myc/Security.pdf
[17]	https://dk1ri.de/myc/logicdevice.zip