I propose to follow-up the "on-false" discussion from the help-forum
(http://sourceforge.net/forum/forum.php?thread_id=2110303&forum_id=743670)
under a more generic topic in the open discussion regarding the behavior of the rule engine.
The current implementation is: (as far as I'm aware of it - Jeff, please correct me if I'm wrong)
1) - received group messages on the bus are filtered (suppressed) if they contain the same value as the previous message
2) - if a rule is evaluated, and the overall result changes(!) to "true" (1), the actionlist is executed exactly once, until the overall rule-gets "false".
(in this case the on-false actionlist is executed exactly once...)
My change-requests are:
for 1) please pass the values independently on the previous values.
In my personal "EIB-world" I have 3 cases, when addresses are sent on my bus without a changed value:
a) for scenarios (to trigger a certain light-scene...)
b) for presets in blind-controls (EIS1:0 to trigger a preset and a :1 to trigger a different one...
c) for status logs / watchdog functions. (status log of a weather-station...), visualizations
I also need to get these consecutive "constant" values in a log. (std::cout...)
For me as a workaround I changed the SwitchingObject::doWrite (for the EIS1) and removed the check for (newValue != value_m). (made always true)
for 2): As a workaround for me I have changed the void Rule::evaluate() and removed the (curValue && !prevValue_m) check
I can imagine multiple more "elegant" options, how to fulfill ALL needs, I.e. your intention to filter (unwanted) repeating values and my (and ottorinos?) need to have
actionslists executed on condition change, but not with the entire rule-result changing.
Option A) evaluate a special flag for group-message. Similar to the "f" flag in a sending direction, if a "f" is set in the receiving direction, the value is always
processed and the rule (actionlist) is always executed.
Option B) define new type of rules... <rule id="Rule_name" type="repeating"> or <rule id="Rule_name" type="switching"> the rule is either behaving like as of today
("switching") or the actionlists are executed on every trigger of a condition --> "repeating".
Option C) define overall 4 types of actionlists instead of the current 2: <actionlist type="on-first-true">,<actionlist type="on-first-false">,<actionlist type="on-true-always">,<actionlist type="on-false-always">
i.e. the first 2 would behave as todays implementation, if the rule-result changes and gets true: "on-first-true" is executed, if it GETS false, "on-first-false" is
executed. The last two ones are always executed, if a rule is triggered by a condition and the result is true or false.
My favorite would be Option C. For me this seems to be the most logical implementation, easily to be analyzed ( Option A is more difficult to be analyzed later for problems), probably easier to be implemented and backward compatible.... (if type is omitted, then it is "on-first-true" and "on-false" is "on-first-false".
Just the new 2 types: "on-true-always" "on-false-always" have to be added.
I would implement this on my own, if my coding abilities and my xml- expertise would reach yours.... :-) So it's just a request and proposal to you...
Thanks again for you work!
best Regards, Jens
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Jean-François, (+ottorino)
I propose to follow-up the "on-false" discussion from the help-forum
(http://sourceforge.net/forum/forum.php?thread_id=2110303&forum_id=743670)
under a more generic topic in the open discussion regarding the behavior of the rule engine.
The current implementation is: (as far as I'm aware of it - Jeff, please correct me if I'm wrong)
1) - received group messages on the bus are filtered (suppressed) if they contain the same value as the previous message
2) - if a rule is evaluated, and the overall result changes(!) to "true" (1), the actionlist is executed exactly once, until the overall rule-gets "false".
(in this case the on-false actionlist is executed exactly once...)
My change-requests are:
for 1) please pass the values independently on the previous values.
In my personal "EIB-world" I have 3 cases, when addresses are sent on my bus without a changed value:
a) for scenarios (to trigger a certain light-scene...)
b) for presets in blind-controls (EIS1:0 to trigger a preset and a :1 to trigger a different one...
c) for status logs / watchdog functions. (status log of a weather-station...), visualizations
I also need to get these consecutive "constant" values in a log. (std::cout...)
For me as a workaround I changed the SwitchingObject::doWrite (for the EIS1) and removed the check for (newValue != value_m). (made always true)
for 2): As a workaround for me I have changed the void Rule::evaluate() and removed the (curValue && !prevValue_m) check
I can imagine multiple more "elegant" options, how to fulfill ALL needs, I.e. your intention to filter (unwanted) repeating values and my (and ottorinos?) need to have
actionslists executed on condition change, but not with the entire rule-result changing.
Option A) evaluate a special flag for group-message. Similar to the "f" flag in a sending direction, if a "f" is set in the receiving direction, the value is always
processed and the rule (actionlist) is always executed.
Option B) define new type of rules... <rule id="Rule_name" type="repeating"> or <rule id="Rule_name" type="switching"> the rule is either behaving like as of today
("switching") or the actionlists are executed on every trigger of a condition --> "repeating".
Option C) define overall 4 types of actionlists instead of the current 2: <actionlist type="on-first-true">,<actionlist type="on-first-false">,<actionlist type="on-true-always">,<actionlist type="on-false-always">
i.e. the first 2 would behave as todays implementation, if the rule-result changes and gets true: "on-first-true" is executed, if it GETS false, "on-first-false" is
executed. The last two ones are always executed, if a rule is triggered by a condition and the result is true or false.
My favorite would be Option C. For me this seems to be the most logical implementation, easily to be analyzed ( Option A is more difficult to be analyzed later for problems), probably easier to be implemented and backward compatible.... (if type is omitted, then it is "on-first-true" and "on-false" is "on-first-false".
Just the new 2 types: "on-true-always" "on-false-always" have to be added.
I would implement this on my own, if my coding abilities and my xml- expertise would reach yours.... :-) So it's just a request and proposal to you...
Thanks again for you work!
best Regards, Jens