Temperature is an attribute of your Boiler. If you exhibit this attribute
in some pattern with a constraint, you are explixitly saying that all
Boilers meeting this constraint becom eligible for matches.
If your application requires to do something whenever the
temperature exerts a certain behaviour ("passes the threshold"),
you'll have to model this explicitly, which isn't too difficult.
A simple implementation might use a separate Temperature class
with fields
int previous;
int current;
Boiler boiler;
where the termperature for some boiler is registered. Whenever
this has previous <= 240 and current >240, update boiler,
setting alert to true. This fires some rule that's needed to handle
the alarm, and this should turn off the alarm.
-W
-----Ursprüngliche Nachricht-----
Von: [email protected] [mailto:[email protected]]im
Auftrag von Allan Terry
Gesendet: Donnerstag, 16. April 2009 23:13
An: [email protected]; [email protected]
Betreff: JESS: When becomes true semantics
I am looking for the following semantics:
Lets say I have a Boiler class with location, temperature, and pressure
fields.
I write a rule like When Boiler.temperature > 240 then ....
I want the rule to trigger when its condition becomes true, not when it
is true in all cases. I don't want it to trigger again if the facts
change but the condition is still true. Example:
Event with temperature set to 250. Rule should fire
Another event for the same boiler with temperature = 270. Rule is still
true, should not fire
Now set its temperature to 100. Rule does not fire
Set temperature to 260. It has become true again and should fire.
Multiple clauses should not change things. When the entire condition
becomes true, the action is activated. The facts tested in the various
clauses will vary with time, but as long as the condition remains true,
the action should not be triggered with each change.
I tried this with another RETE-based rules engine which shall remain
nameless. It fires when a new event satisfies the condition, whether or
not it was true before.
Interestingly, this worked for classes with a single field, but as soon
as I added multiple fields I started getting the "is true" semantics.
Does Jess offer this "becomes true" semantics? Maybe there is a better
term for it. If not, is there a reasonable approach I could take to
layer it on?
thanks, Allan
--------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users [email protected]'
in the BODY of a message to [email protected], NOT to the list
(use your own address!) List problems? Notify [email protected].
--------------------------------------------------------------------
--------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users [email protected]'
in the BODY of a message to [email protected], NOT to the list
(use your own address!) List problems? Notify [email protected].
--------------------------------------------------------------------
