Step 5: Firing Instant A-events

This step corresponds to test_agg_lib_5 .

Instant A-events are sent to the AggreGate server "on the spot". They are "lightweight" — there is no dealing with storing them on the flash disk, etc. They are fast(er) — just send! They are more reliable — no flash disk complexity involved. They are also easier to be lost. Should your device lose power at a wrong moment, the instant A-event will be forgotten. Another limitation: instant A-events can only be fired successfully when there is an active connection to the AggreGate server. Bottom line: use instant A-events for events that are not-so-important and/or numerous.

In this step we add an instant A-event for reporting the booting (powering up) of the device.

The steps

Notice that...

  1. Aggregate.xtxt now contains the DB instant A-event . This event has only one field — the date/time of the event. It is possible to have additional fields, of course.

  2. There is a new generate_boot_event() sub is in device.tbs . It calls agg_fire_instant_event() to send the instant A-event to the AggreGate server. We call generate_boot_event() from callback_agg_synchronized() , not on_sys_init() . As was explained above, you need to have an established connection to the AggreGate server in order to be able to fire instant A-events, and the connection is ready when callback_agg_synchronized() is called.

  3. Notice how this procedure uses agg_record_encode() .

  4. Notice also the use of the TIME library [not yet documented] for producing the date/time field of correct format.

Notice how the add_fire_instant_event() call has the event_level argument. The level defined by this argument will override the default level set in the configurator , unless you set the event_level = EN_AGG_EVENT_LEVEL_USE_DEFAULT, in which case the default event level will be used.

The result

To be able to see instances of your new event, right-click on the device in the tree and choose Monitor Related Events .

test_agg_lib_5