EventAction Plugin ¶

Scope in RT 2026.2.1 ¶

This page documents the EventAction implementation and interface present in CVEDIA-RT 2026.2.1. It is deliberately limited to behavior supported by the source implementation.

EventAction can parse action entries, retain them, and accept events into its queue. In this revision it is not an end-to-end action-delivery interface:

process() returns success without processing the supplied event.
addEventToQueue() appends an event to the internal queue.
The queue-draining and action-dispatch implementation is commented out.
Event-action handler registrations in the inspected REST, MQTT, and WriteData plugins are also commented out.

Consequently, this guide does not promise REST calls, file writes, retries, batching, queue statistics, webhooks, or external notifications. Verify the runtime implementation for a later release before depending on EventAction to deliver an external side effect.

Configuration data accepted by `loadConfig`¶

EventActionManaged::loadConfig() receives an array directly. It does not read an eventaction object or an actions wrapper. Each array item is parsed as one EventActionImpl.

[
  {
    "action_type": "log",
    "event_filter": "",
    "config": {},
    "enabled": false
  }
]

This JSON is the value passed to loadConfig; it is not, by itself, a complete RT configuration file or a proof that an action will be dispatched.

Field	Type	Default / parsing behavior
Array item	object	One action entry. The top-level value is iterated directly.
`action_type`	string	`""`. Maps the values listed below to an `EventActionTypeEnum`; an unrecognised value remains `EventActionType_None`.
`event_filter`	string	`""`. Stored as the entry's `EventFilter`.
`config`	object	Created if absent and stored as the entry's `ActionConfig`. The EventAction implementation does not define or validate an action-specific schema.
`enabled`	boolean	`false`. Stored on the entry; it does not enable a dispatch loop in this revision.

The source maps these action_type strings:

Value	Enum
`disk`	`EventActionType_Disk`
`mqtt`	`EventActionType_MQTT`
`rest`	`EventActionType_REST`
`screen_message`	`EventActionType_ScreenMessagePopup`
`screen_notif`	`EventActionType_ScreenNotification`
`sound`	`EventActionType_Sound`
`log`	`EventActionType_Log`
`gpio`	`EventActionType_GPIO`
`shm`	`EventActionType_SharedMemory`

Recognising one of these strings only establishes how the entry is represented in EventActionImpl; it does not establish that a handler is registered or that it will run.

C++ interface ¶

The installed SDK declares the public iface::EventAction interface with the following methods. The source-only concrete EventActionManaged implementation overrides them with the same signatures:

expected<bool> loadConfig(pCValue eventActionsConfigObj);
pCValue processScript(pCValue config, pCValue data);
void addEventToQueue(std::string id, pCValue const ev);
std::vector<EventActionImpl> getEventActions();
expected<bool> process(pCValue eventObj);

EventActionManaged also provides:

static std::unique_ptr<iface::EventAction> create(
    std::string const& moduleName);

There is no getConfigDescriptors(), getQueueSize(), clearQueue(), or getQueueStats() method in this implementation. addEventToQueue() returns void, and getEventActions() returns std::vector<EventActionImpl> rather than an expected value.

Source-backed configuration and queue example ¶

The following source-backed illustration constructs the exact array shape consumed by loadConfig(). It requires the internal EventAction plugin build and headers: eventactionmanaged.h is not an installed SDK interface, and its sol/forward.hpp dependency is unavailable from the installed SDK. It is not a standalone compilation example. It demonstrates source-level configuration parsing and enqueueing only, not an externally delivered action.

#include "api/convert.h"
#include "cvalue.h"
#include "eventactionmanaged.h"

using namespace cvedia::rt;

void configureEventAction()
{
auto eventAction = EventActionManaged::create("documentation-example");
auto entries = api::convert::cvalueFromJsonString(R"json(
[
  {
    "action_type": "log",
    "event_filter": "",
    "config": {},
    "enabled": false
  }
]
)json");

if (!entries) {
    // Handle JSON conversion failure.
    return;
}

auto configured = eventAction->loadConfig(entries.value());
if (!configured || !configured.value()) {
    // Handle configuration-load failure.
    return;
}

eventAction->addEventToQueue("documentation-event", VAL(CValueType::MAP));
}

getEventActions() can be used to inspect the parsed entries. Do not infer queue length, retry state, handler state, or an action outcome from this API.

Lua and action delivery ¶

processScript() remains an internal direct C++ path distinct from the commented-out queue-dispatch path. When RT is built with BUILD_LUA_LIB and the provided config has a script value, it loads and caches that script's eventHandlerProcess function, invokes it with the supplied data, and replaces data.data when the function returns exactly one value. It otherwise returns the supplied data. This source behavior does not make it an EventAction Lua binding or show that queued actions invoke it.

No EventAction-specific Lua binding was found in the inspected 2026.2.1 source. This guide therefore does not provide configure, loadConfig, queue, REST, webhook, or custom-script Lua calls for EventAction.

Likewise, no automatic action-delivery example is presented here. The source has a commented-out queue-dispatch path, so an example claiming that enqueued events write to disk, send HTTP/MQTT traffic, invoke a webhook, or automatically reach a custom handler would not be a verified representation of this release.

Troubleshooting ¶

Observation	Source-backed interpretation
Omitting `enabled`	The parsed entry defaults to `false`.
Supplying an `actions` wrapper	`loadConfig()` expects the array itself, not a wrapper object.
Supplying an unknown `action_type`	The entry is left with `EventActionType_None`; this parser does not report an unknown-type error.
An enqueued event does not trigger an external action	Expected from the inspected implementation: enqueueing does not drain the queue, and dispatch is commented out.