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 <ml(a)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 <ml(a)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(a)lists.jboss.org
>>>>
https://lists.jboss.org/mailman/listinfo/rules-users
>>>>
>>> _______________________________________________
>>> rules-users mailing list
>>> rules-users(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/rules-users
>>
>> _______________________________________________
>> rules-users mailing list
>> rules-users(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/rules-users
>>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/rules-users