MeshDash Docs
R2.0
/
Home Frontend Guide Automation Views

Automation Views

Frontend Guide tasks autoreply auto reply monitor iot web telemetry automation cron schedule rules directives
Tasks, Auto-Reply, Monitor, and Web Telemetry — how to use the automation tools in the dashboard.

Automated Tasks

The Tasks view (Tasks API ↗) lets you schedule messages or web data ingress to be sent to any node on a cron schedule.

Layout

Two columns: the left panel shows deployed tasks (from /api/tasks/), the right shows a node grid to select a target. Click any node card (including the cyan BROADCAST card) to open the task creation modal for that node.

Task Modal — Task Type

Standard Message
Type a text message in the payload box. It will be sent as a Meshtastic text message to the selected node on the schedule.
Web Sensor Ingress
Provide a JSON config for the web scraper. The server fetches the URL, extracts the block, prepends your prefix, and broadcasts it. See the Web Telemetry view for a guided wizard to build this config.

Cron Schedule Builder

The schedule dropdown converts a human-readable option into a cron expression:

Run Once
Pick a specific date and time. Converts to M H D month *.
Daily
Pick a time (HH:MM). Converts to M H * * *.
Every Hour
Always 0 * * * *. No time picker shown.
Custom Crontab
Type a raw cron expression. The preview updates live. Example: */15 * * * * = every 15 minutes.

The CRONTAB PREVIEW box always shows the exact expression that will be stored in the database. Confirm it looks correct before saving.

Click DEPLOY TASK to save (POST /api/tasks/). The left panel refreshes automatically.


Auto Reply

The Auto-Reply view (Auto-Reply API ↗) manages rules that automatically respond to incoming mesh messages.

Creating a Rule

Fill in the form and click ADD RULE:

  • Trigger phrase — the text to match
  • Match typecontains, exact, or regex
  • Response — the reply text. Supports placeholders like {short_name}, {battery_level}
  • Cooldown — seconds before the same sender can trigger it again
  • Enabled toggle

Bulk Enable/Disable

Buttons at the top of the rules table enable or disable all rules at once. Useful for maintenance windows when you want to temporarily suppress all automated responses.

Rule Matching Logic

Rules are evaluated in the background packet processing worker (not in the browser). Every incoming text message is checked against all enabled rules. Multiple rules can fire for a single message. The cooldown is per-rule, per-sender node.


Monitor (Telemetry Alerts)

The Monitor view (Telemetry Monitor API ↗) deploys rules that watch node metrics and fire mesh alerts when thresholds are crossed.

Creating a Directive

  1. Select a target node from the left sidebar
  2. Fill the form: metric, condition (< below or > above), threshold value
  3. Set the alert destination (node ID or ^all) and channel
  4. Set the check frequency in minutes
  5. Click DEPLOY TASK

Active Directives Table

The bottom panel shows all active rules. Each row has:

  • Test button (flask icon) — sends a test alert immediately, bypassing threshold and cooldown checks
  • Delete button (trash icon) — permanently removes the rule after confirmation

The monitor worker runs server-side every 60 seconds. It only evaluates rules when the radio is connected.


Web Telemetry / IoT Ingress

The Web Telemetry view is a 3-phase guided wizard for extracting data from public websites and broadcasting it over the mesh. It is a frontend companion to the /extract and /api/monitor endpoints.

Phase 1: Target Acquisition

Select a destination node from the left sidebar, then enter a public URL and click PARSE DOM. The frontend calls POST /extract with the URL and receives a list of up to 50 text blocks extracted from the page's HTML.

Phase 2: Payload Extraction

The blocks are displayed as selectable cards. Filter by text using the search box. Click the block you want to use as the data payload. Pagination allows browsing all 50 blocks (10 per page).

Phase 3: RF Transmission & Automation

With a block selected:

  • Enter a sensor label (prefix) — prepended to the message, e.g. Tank Level:
  • Select a mesh channel (0–7)
  • Click TRANSMIT NOW to fire a one-time transmission immediately via POST /api/monitor
  • Or set a schedule (Once / Daily / Hourly) and click DEPLOY TASK to create a recurring automated task via POST /api/tasks/

The task stores a JSON payload config {"url":"...","block_id":N,"prefix":"Label","channel":0} as the task's actionPayload. The task scheduler (task_scheduler.py) fetches and re-scrapes the URL on each scheduled run.

How Tasks Execute (Backend Flow)

When a task's cron expression fires, task_scheduler.py calls the local MeshDash API to execute it:

  • Standard Message: POST /api/messages — sends a text message to the specified node/channel. Retried up to 3 times on failure.
  • Web Sensor: POST /api/monitor — fetches the URL, extracts the block, prepends the prefix, sends as a message. The URL is SSRF-validated server-side.

The task scheduler runs within the main MeshDash process. It only executes tasks when the radio connection is active (is_ready is set). Tasks that fire while the radio is disconnected are skipped for that cycle.

Auto-Reply — How Rules Are Evaluated

Rule evaluation happens in the packet processing worker — every incoming TEXT_MESSAGE_APP packet is checked against all enabled rules immediately as it is processed. This means:

  • Auto-replies are sent within milliseconds of the incoming message being received
  • Cooldowns are per-rule per-sender — rule 1 and rule 2 each have independent cooldowns for each node
  • The cooldown tracker resets on service restart (it is in-memory)
  • Multiple rules can match the same message — all matching rules fire (subject to their individual cooldowns)
  • Replies are sent back to the sender's node ID on the same channel the original message arrived on

Monitor Directives — Execution Timing

The telemetry monitor worker evaluates rules every 60 seconds. It only evaluates rules when the radio is connected. For each rule:

  • It checks now - last_checked >= check_interval_minutes × 60 before evaluating
  • The same interval serves as the alert cooldown — a rule cannot fire again until check_interval_minutes has elapsed since the last alert, preventing alert spam
  • The last_checked timestamp is always updated, even when the threshold is not crossed
  • The last_alerted timestamp is only updated when an alert is actually sent