Docs
Widgets / directory

Eventor

EVENTOR

Automation rules widget for conditions, actions, mail and notification flows.

At a glance

Default8 x 3
Minimum4 x 2
Resizeboth
Pinoptional
Interactiveno

Behavior

  • Acts like a visual rules engine inside the dashboard ecosystem.
  • Supports human-readable trigger and action previews.
  • The app models rules as trigger pin or timer plus condition plus a list of actions such as SETPIN, INCREMENT, MULTIPLY, NOTIFY or MAIL.

Firmware contract

Rules live mostly in the dashboard/server layer; firmware receives the resulting writes.

On the app side this widget snaps to the 8-column square grid and uses both resizing. Its raw type is EVENTOR and the matching icon token in the app is bolt.badge.automatic.

Pin support: The widget itself does not require one pin; rules inside it can watch or write many pins and channels.

Transmission: Rules resolve into actions like SETPIN, INCREMENT, MULTIPLY, NOTIFY or MAIL.

Canvas preview

docs.widget.preview
Eventor
0/0
no rules
Eventor

Widget contract

PropertyValue
Raw typeEVENTOR
Default size8 x 3
Minimum size4 x 2
Resize modeboth
Pin requirementoptional / infrastructure
Pin supportThe widget itself does not require one pin; rules inside it can watch or write many pins and channels.
Interactiveread-only / service
TransmissionRules resolve into actions like SETPIN, INCREMENT, MULTIPLY, NOTIFY or MAIL.

Allowed pin families

The widget itself does not require one pin; rules inside it can watch or write many pins and channels.

Transport path

Rules resolve into actions like SETPIN, INCREMENT, MULTIPLY, NOTIFY or MAIL.

Operational limits

Rule validation is mandatory because broken automations are worse than missing ones

Service authority boundary

Eventor is a rule editor over server authority. The real source of truth is the rule graph stored server-side, not the tile on the canvas.

Who validates it: backend / project policy / dashboard grants.

What the board sees: the resulting write, notification or text payload, not the visual tile itself.

Configuration surface

  • condition type can be GT, GTE, LT, LTE, EQ, NEQ, BETWEEN, NOT_BETWEEN or CHANGED
  • actions can target pins, notifications or mail
  • rule order matters because the app allows drag reordering
  • best combined with clear natural-language previews
  • advanced editors need explicit typing for thresholds, BETWEEN ranges and CHANGED semantics before save

Limits and caveats

  • Rule validation is mandatory because broken automations are worse than missing ones
  • Complex projects need backend inspection and audit trails
  • This widget is mostly an editor over backend authority, not a self-sufficient client-side automation engine
  • Ambiguous action ordering or loosely typed thresholds eventually create non-reproducible automation bugs

Protocol and implementation notes

  • Rules resolve into SETPIN, NOTIFY or MAIL actions, which means validation and audit trails matter more than canvas chrome.
  • This widget is mostly a frontend for server logic, so project sharing and future marketplace rights should constrain who can edit rules.
  • Advanced editors need explicit typing for thresholds, BETWEEN pairs, CHANGED semantics and action order before a rule is safe to persist.

Layout notes

Canvas footprint

8 x 3

Default footprint in the Plynx canvas before user resizing.

Resize floor

4 x 2

The minimum size accepted by the app during drag-resize.

Interaction model

Display

Whether the user edits state directly or only reads it.

Related widgets

SuperChart

Historical and live chart surface with multiple streams, periods and annotations.

Terminal

Bidirectional terminal for commands, logs and line-oriented interaction.

Map

Live position widget with device points, tracks and board-originated GPS updates.

Table

Dynamic multi-row table fed by firmware commands and row updates.