Webhooks, Notifications, and Integrations
Updated: January 2026
Once your Mesh-Plug installation is ingesting Meshtastic data and rendering it inside WordPress, you’ve done more than build a dashboard. You’ve established a server-side data pipeline capable of automation, alerting, and system-to-system integration.
Mesh-Plug is designed to act as a control and distribution layer between off-grid mesh networks and on-grid services. This guide walks through how to extend that pipeline using server-side automations, outbound webhooks, and native WordPress hooks; all without exposing MQTT credentials or relying on browser-side logic.
Architecture Overview: How Automation Works in Mesh-Plug
Mesh-Plug processes incoming Meshtastic data after ingestion, not in the browser.
Depending on your deployment, data may arrive via:
- Direct MQTT ingestion (live mode; admin / operator use)
- Server-side collectors and snapshots (observer mode; public / shareable dashboards)
- Future webhook or batch ingestion paths
Once normalized, each packet is passed through Mesh-Plug’s internal event pipeline, where it can trigger actions such as:
- Writing to NodeDB or historical archives
- Evaluating conditions and thresholds
- Sending outbound webhooks
- Triggering email or internal alerts
- Firing native WordPress actions for custom code
All automation logic runs server-side, inside WordPress. No browser JavaScript, no long-running daemons, and no dependency on Node-RED or external workflow engines.
Automation Rules (Current State)
Mesh-Plug automations are intentionally conservative and deterministic. Rather than an overly abstract “visual flow builder,” rules are designed to be:
- Auditable
- Predictable
- Safe for shared hosting and VPS deployments
- Compatible with observer-mode dashboards
Automations are configured under:
Mesh-Plug → Automations
Each rule consists of:
- Trigger – When the rule evaluates
- Conditions – Optional filters on message fields
- Actions – One or more responses, executed in order
Example: Battery Voltage Alert
Goal: Send an email when any node reports low battery voltage.
Rule Configuration
- Trigger: Message Ingested
- Scope: Telemetry packets
- Condition:
- Field:
battery - Operator:
< - Value:
3.5
- Field:
- Action: Send Email
Email Template
- Subject: Low Battery Detected on {{node_name}}
- Body:
Node {{node_id}} reported low battery ({{battery}} V) at {{timestamp}}.
Once enabled, Mesh-Plug evaluates every incoming telemetry packet. When the condition matches, the action fires immediately; no polling, no cron delay.
Webhooks: Forwarding Data to External Systems
Webhooks are the primary integration mechanism in Mesh-Plug. They allow you to forward normalized mesh data to any external system capable of receiving HTTP requests.
Common use cases include:
- Laravel or Rails backends
- Node-RED flows
- Custom logging APIs
- Automation platforms
- Long-term analytics pipelines
Example: Forward Telemetry to a Custom API
- Trigger: Message Ingested
- Packet Type: Telemetry
- Action: Webhook (POST)
Endpoint
https://yourserver.com/api/meshtastic
Payload
{
"node_id": "{{node_id}}",
"node_name": "{{node_name}}",
"battery": "{{battery}}",
"rssi": "{{rssi}}",
"snr": "{{snr}}",
"timestamp": "{{timestamp}}"
}
Mesh-Plug sends a signed, server-side request each time new data arrives. The receiving system can store, visualize, or act on the data instantly.
Time-Series and Analytics Pipelines
Mesh-Plug does not attempt to replace dedicated analytics platforms. Instead, it acts as a clean data forwarder.
InfluxDB / Grafana Example
- Action: Webhook
- Method: POST
- Endpoint:
http://localhost:8086/write?db=meshtastic
Body (Line Protocol)
telemetry,node={{node_id}} battery={{battery}},rssi={{rssi}} {{timestamp}}
Once enabled, all matching telemetry flows directly into InfluxDB and becomes available for Grafana dashboards, alerts, and historical analysis.
Native WordPress Hooks for Advanced Customization
For sites that need tighter CMS integration, Mesh-Plug exposes internal hooks you can bind to in custom plugins or themes.
Example: Update a Device Post Meta Field
add_action('mesh_plug_message_ingested', function ($msg) {
if (!empty($msg['node_id']) && isset($msg['battery'])) {
$post = get_page_by_title($msg['node_id'], OBJECT, 'devices');
if ($post) {
update_post_meta($post->ID, 'last_battery', $msg['battery']);
}
}
});
This allows you to:
- Keep public device pages updated
- Drive custom dashboards
- Sync mesh data with other WordPress plugins
- Maintain a fully CMS-native data model
Chained Actions and Conditional Responses
A single rule may execute multiple actions in sequence.
Example: High Temperature Response
- Condition: Temperature > 30 °C
- Action 1: Webhook → Cooling Control API
- Action 2: Email → Administrator
- Action 3: Log → Internal Alerts Table
This layered approach lets you respond automatically while still maintaining human visibility and audit trails.
Scheduling and Snapshot-Based Automations
Mesh-Plug includes a lightweight scheduler that integrates with WordPress cron.
Use scheduled automations for:
- Daily or hourly summaries
- Health checks
- Snapshot validation
- Offline detection
Example: Daily Status Report
- Trigger: Scheduled (Daily)
- Action: Email
Body
Node A battery: {{latest('node_a','battery')}} V
Node B battery: {{latest('node_b','battery')}} V
The latest() helper resolves values from the most recent server-side snapshot; no live MQTT connection required.
Integrating with Cloud Automation Platforms
Mesh-Plug webhooks are compatible with nearly all third-party automation tools:
| Platform | Use Case |
|---|---|
| IFTTT | Trigger smart-home or notification events |
| Zapier | Forward data to Slack, Sheets, email, or CRMs |
| Home Assistant | Update entity states from mesh telemetry |
| AWS Lambda / Cloud Functions | Run custom scripts or analytics |
Because Mesh-Plug runs server-side, credentials and secrets are never exposed to the browser.
Logging, Auditing, and Troubleshooting
Every automation execution is logged under:
Mesh-Plug → Logs → Automations
Logs include:
- Timestamp
- Rule name
- Node ID
- Condition result
- Action success or failure
If an action fails:
- Verify the webhook endpoint returns HTTP 200
- Check WordPress and PHP error logs
- Confirm outbound requests are allowed by hosting or firewall rules
Logs can be exported for audits or diagnostics.
Security and Deployment Considerations
| Concern | Recommendation |
|---|---|
| Credential exposure | Never embed secrets in JavaScript |
| Public dashboards | Use observer mode with server snapshots |
| Rate limits | Apply limits at the broker or collector layer |
| Field deployments | Disable outbound webhooks if isolation is required |
| Backups | Automations are stored in WordPress options; include them in backups |
Mesh-Plug is designed to degrade safely; if automations are disabled, dashboards continue to function.
Practical Automation Scenarios
- Off-grid weather stations publishing public status pages
- Community mesh dashboards with alerting but no live MQTT
- Fleet or asset tracking with WordPress-based reporting
- Environmental monitoring with escalation workflows
- Forwarding mesh data into Laravel or other SaaS platforms
Final Notes
Automation is what turns Mesh-Plug from a viewer into a system.
By combining server-side ingestion, controlled automation, outbound webhooks, and native WordPress hooks, Mesh-Plug allows you to connect off-grid radios, on-grid services, and human-readable dashboards without compromising security or reliability.
Whether you’re running a private mesh, a public observer dashboard, or a hybrid deployment, Mesh-Plug provides a stable foundation for event-driven, mesh-aware applications; entirely within WordPress.
Leave a Reply