Ahh... nice solution. Perhaps I was simply thinking too complicated. Works fine.
There's however one thing that does not work with the accumulate for me. >>>> Number( intValue == 3 ) from accumulate( >>>> Event( $i : id, code == "ABCD") over window:time( 5m ), >>>> count( $i ) ) In all my other rules I retrieve the events that caused my rule to via via the kcontext.getMatch().getObjects(). In this case I just get a number object with value 3. Seems to be appropriate since I am matching against that number. But how can I get the ids of those three events that caused my rule to fire? Thanks, Ingo On 2013-12-05 09:40, Wolfgang Laun wrote: > What about > > rule cleanup > when > $d: Device( $id: id ) > not Event( id == $id ) > then > retract( $d ); > end > > -WL > > On 05/12/2013, IK81 <m...@kofler.me> wrote: >> The devices may come and go and there may be several hundreds of >> them. >> They are stored in a database. >> >> Currently, I feed the events into the knowledge session and trigger >> an >> EJB call (instead of the simple System.out.println I used in the >> example >> below) and pass the device id. The EJB does the rest and looks up >> the >> device and related information from the database. If the id is >> unknown, >> this call is just a NOOP. >> >> Currently the knowledge session and the database need no >> synchronization. I just wanted to avoid this in my design, but now >> it >> seems to be necessary just for this group-by issue. I can imagine >> that I >> can also insert the fact using a rule that matches if I get an event >> for >> a currently unknown device (i.e., having no fact for it in the >> session), >> but how to clean up the facts if a device disappears. This @expires >> annotation is only valid for events afaik. >> >> Are there really no alternatives for this group-by instead of having >> the fact? >> >> Ingo >> >> >> On 2013-12-05 06:52, Wolfgang Laun wrote: >>> Why is it "not practical" to add a fact for a device? You don't >>> have >>> to do this up front; they may come and go, dynamically. >>> >>> -W >>> >>> >>> On 05/12/2013, IK81 <m...@kofler.me> wrote: >>>> Hi, >>>> >>>> I am trying to figure out a rule for matching an incoming sequence >>>> of >>>> events, but so far I was not really successful. Basically, I want >>>> to >>>> process events from devices. Every event has a timestamp (long), >>>> an >>>> id >>>> (a UUID string), a deviceId and an error code (both are strings). >>>> >>>> What I want to have is a simple rule that fires, if a single >>>> device >>>> reports a certain error code (e.g. ABCD) 3 times within 5 minutes >>>> (i.e., >>>> getting 3 such events within 5 minutes). So far, I suceeded in >>>> counting >>>> the ABCD error codes in the time window as follows: >>>> >>>> >>>> rule "Detect 3 occurrences of code ABCD for a certain device" >>>> when >>>> Number( intValue == 3 ) from accumulate( >>>> Event( $i : id, code == "ABCD") over window:time( 5m ), >>>> count( $i ) ) >>>> then >>>> System.out.println("Raise alarm"); >>>> end >>>> >>>> This first attempt does not distinguish which device sent the >>>> error >>>> code. But how can I express to fire only if the events share the >>>> same >>>> deviceId? I found many solutions that use a fact (e.g., a device >>>> fact) >>>> to group by the device and do the accumulation. I successfully >>>> implemented the group-by using the following when-part of the >>>> rule. >>>> >>>> when >>>> Device($deviceId : id) >>>> Number( intValue == 2 ) from accumulate( >>>> Event( $i : id, deviceId == $deviceId, code == "ABCD") >>>> over >>>> window:time( 5m ), >>>> count( $i ) ) >>>> then >>>> >>>> Adding a device fact is however not practical in my case. Are >>>> there >>>> any >>>> alternatives for expressing this group-by? >>>> >>>> Thanks, >>>> Ingo >>>> _______________________________________________ >>>> rules-users mailing list >>>> rules-users@lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/rules-users >>>> >>> _______________________________________________ >>> rules-users mailing list >>> rules-users@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/rules-users >> >> _______________________________________________ >> rules-users mailing list >> rules-users@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-users >> > _______________________________________________ > rules-users mailing list > rules-users@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users _______________________________________________ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users