Docs
Widgets / directory

Email

EMAIL

Service widget for sending mail notifications and alert summaries.

At a glance

Default2 x 2
Minimum2 x 2
Resizenone
Pinoptional
Interactiveno

Behavior

  • Mostly configured from the dashboard side.
  • Pairs naturally with Eventor condition/action graphs.
  • Connector-side actions expect destination, subject and body style fields rather than a scalar pin payload.

Firmware contract

Use sparingly for alarms, reports and non-realtime notifications.

On the app side this widget snaps to the 8-column square grid and uses none resizing. Its raw type is EMAIL and the matching icon token in the app is envelope.fill.

Pin support: No direct pin interaction from the UI widget itself.

Transmission: Server-side email action using to/subject/body style payload fields or Eventor mail actions.

Canvas preview

docs.widget.preview
email
Email

Widget contract

PropertyValue
Raw typeEMAIL
Default size2 x 2
Minimum size2 x 2
Resize modenone
Pin requirementoptional / infrastructure
Pin supportNo direct pin interaction from the UI widget itself.
Interactiveread-only / service
TransmissionServer-side email action using to/subject/body style payload fields or Eventor mail actions.

Allowed pin families

No direct pin interaction from the UI widget itself.

Transport path

Server-side email action using to/subject/body style payload fields or Eventor mail actions.

Operational limits

Server rejects empty or malformed to/subj payloads

Service authority boundary

Email is backend-mediated. The widget is only the authoring/trigger surface for a message action that should be logged and permission-checked.

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

  • dashboard must include a valid email widget
  • HTTP and connector flows expect destination and subject fields
  • best used for reports, summaries and escalation alerts

Limits and caveats

  • Server rejects empty or malformed to/subj payloads
  • Delivery depends on configured mail provider and quota
  • This is an alerting surface, not a general-purpose user mailbox

Protocol and implementation notes

  • Email flows map to dedicated connector actions with destination, subject and body fields.
  • Malformed or empty email payloads are rejected server-side, so treat this widget as an alerting surface rather than an arbitrary mail client.
  • Mail widget payloads are constrained by the protocol body and should stay concise; long reports belong in docs, logs or linked artifacts.
  • Treat email as a server-mediated alert channel, not a general-purpose messaging bus.

Layout notes

Canvas footprint

2 x 2

Default footprint in the Plynx canvas before user resizing.

Resize floor

2 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

Notification

Service widget that emits push notifications rather than rendering UI on the canvas.

RTC

Background time-sync widget that exposes server time to firmware logic.

Bridge

Background bridge for writing pins on another device or token context.

Webhook

Non-visual automation widget for relaying events to external HTTP endpoints.