tutorial

Monitoring OpenEMS with Vigilmon

OpenEMS powers smart grids, solar inverters, battery storage, and EV charging — but a silent component failure can mean lost solar yield or an undetected battery fault. Here's how to monitor every critical service with Vigilmon.

OpenEMS (Open Energy Management System) is an open-source platform for managing distributed energy resources — solar inverters, battery storage systems, EV chargers, grid meters, and everything in between. It runs as a Java/OSGi bundle on embedded controllers and on server hardware, exposing a web UI on port 8080 and a REST/JSON API on port 8085. When OpenEMS goes silent, you may lose solar surplus routing, miss a battery fault, or leave EV chargers uncoordinated. Vigilmon keeps eyes on every layer so you know the moment something breaks.

What You'll Set Up

  • Web UI availability monitor (port 8080)
  • REST/JSON API health check (port 8085)
  • OSGi component bundle health via API probe
  • Energy device controller connectivity (battery, solar inverter, EV charger, grid meter)
  • Modbus device communication health
  • Time-series historian database connectivity
  • Scheduler and optimizer service health
  • WebSocket live data stream heartbeat
  • BMS (Battery Management System) data integrity check
  • Cron heartbeat for the OpenEMS process itself

Prerequisites

  • OpenEMS installed and running (single-node or distributed)
  • OpenEMS REST/JSON API enabled on port 8085
  • A free Vigilmon account

Step 1: Monitor the OpenEMS Web UI

The OpenEMS web interface runs on port 8080 and is the first thing operators check. Add an HTTP monitor for it:

  1. Log in to vigilmon.online and click Add Monitor.
  2. Set Type to HTTP / HTTPS.
  3. Enter http://your-openems-host:8080.
  4. Set Check interval to 1 minute.
  5. Set Expected HTTP status to 200.
  6. Click Save.

If you reverse-proxy the web UI through nginx or Caddy with TLS, monitor the HTTPS URL instead.

Step 2: Monitor the REST/JSON API

The REST/JSON API (port 8085) is what SCADA systems, dashboards, and automation scripts talk to. A separate monitor ensures the API layer is alive even when the web UI is up:

  1. Add a new monitor — Type: HTTP / HTTPS.
  2. URL: http://your-openems-host:8085/rest/channel/.
  3. Expected HTTP status: 200 or 401 (unauthenticated probes return 401 — still proves the API is responding).
  4. Check interval: 1 minute.
  5. Save.

For authenticated installations, create a read-only API user and use the authenticated endpoint:

http://your-openems-host:8085/rest/channel/_sum/State

The _sum/State channel returns the global system state and is a reliable liveness signal.

Step 3: Probe OSGi Bundle Health

OpenEMS runs as OSGi bundles. A bundle that fails to activate leaves a device controller silently offline. Query the REST API for active component list:

  1. Add a monitor — Type: HTTP / HTTPS.
  2. URL: http://your-openems-host:8085/rest/component/get/.
  3. Expected HTTP status: 200.
  4. Under Keyword / Body contains, enter "isEnabled":true to assert at least one active component.
  5. Check interval: 2 minutes.
  6. Save.

This verifies that the OSGi framework is running and components are activating normally.

Step 4: Monitor Energy Device Controllers

Each energy device (battery, solar inverter, EV charger, grid meter) registers as a component with a channel reflecting its connection state. Poll the relevant channels:

Battery Controller

  1. Add monitor — Type: HTTP / HTTPS.
  2. URL: http://your-openems-host:8085/rest/channel/ess0/State.
  3. Expected status: 200.
  4. Body contains: "value":0 (0 = OK in OpenEMS fault bitmask).
  5. Check interval: 1 minute.

Solar Inverter

  1. URL: http://your-openems-host:8085/rest/channel/pvInverter0/State.
  2. Same status/body assertions as above.

EV Charger (EVCS)

  1. URL: http://your-openems-host:8085/rest/channel/evcs0/State.
  2. Body contains: "value":0.

Grid Meter

  1. URL: http://your-openems-host:8085/rest/channel/meter0/State.
  2. Body contains: "value":0.

Replace ess0, pvInverter0, evcs0, meter0 with the component IDs from your OpenEMS configuration (config.json or the UI's Components tab).

Step 5: Monitor Modbus Device Communication

OpenEMS communicates with inverters and meters over Modbus TCP. The Modbus bridge component exposes a State channel that reflects communication errors:

  1. Add monitor — Type: HTTP / HTTPS.
  2. URL: http://your-openems-host:8085/rest/channel/modbus0/State.
  3. Body contains: "value":0.
  4. Check interval: 1 minute.

If you have multiple Modbus bridges (modbus0, modbus1, …), create one monitor per bridge. A non-zero state value means the bridge is retrying or has lost contact with a physical device.

Step 6: Monitor Time-Series Historian Connectivity

OpenEMS logs channel data to InfluxDB or a local TimescaleDB/SQLite store. Check the historian component:

  1. Add monitor — Type: HTTP / HTTPS.
  2. URL: http://your-openems-host:8085/rest/channel/influxdb0/State (or your historian component ID).
  3. Body contains: "value":0.
  4. Check interval: 2 minutes.

Alternatively, add a TCP port monitor to verify the InfluxDB port is reachable:

  1. Add monitor — Type: TCP Port.
  2. Host: your-influxdb-host, Port: 8086.
  3. Check interval: 2 minutes.

Step 7: Monitor Scheduler and Optimizer Services

The OpenEMS Scheduler sequences controller execution each cycle. Monitor it via the Scheduler component channel:

  1. Add monitor — Type: HTTP / HTTPS.
  2. URL: http://your-openems-host:8085/rest/channel/scheduler0/State.
  3. Body contains: "value":0.
  4. Check interval: 2 minutes.

If you run the Grid-Optimized Charging optimizer, add:

  1. URL: http://your-openems-host:8085/rest/channel/gridOptimizedCharge0/State.
  2. Same assertions.

Step 8: Heartbeat for the WebSocket Live Data Stream

OpenEMS pushes live channel data to dashboards over WebSocket. While Vigilmon doesn't speak WebSocket natively, you can verify the WebSocket upgrade endpoint responds:

Create a small probe script that connects, receives one message, then exits 0. Run it via a cron job and push a heartbeat ping to Vigilmon on success:

#!/bin/bash
# probe-openems-ws.sh
python3 -c "
import websocket, sys
ws = websocket.create_connection('ws://your-openems-host:8085/websocket', timeout=10)
msg = ws.recv()
ws.close()
sys.exit(0 if msg else 1)
" && curl -fsS "https://vigilmon.online/api/push/YOUR_HEARTBEAT_KEY" > /dev/null

Add to cron:

* * * * * /usr/local/bin/probe-openems-ws.sh

In Vigilmon:

  1. Add monitor — Type: Heartbeat.
  2. Set Expected interval to 2 minutes (grace for cron jitter).
  3. Copy the heartbeat URL into the script above.

Step 9: Monitor BMS Data Integrity

Battery Management System data should update continuously. A stale _sum/EssSoc channel indicates the BMS has stopped reporting:

  1. Add monitor — Type: HTTP / HTTPS.
  2. URL: http://your-openems-host:8085/rest/channel/_sum/EssSoc.
  3. Expected status: 200.
  4. Body contains: "type":"INTEGER" (confirms the channel returned typed data, not an error payload).
  5. Check interval: 1 minute.

For a tighter check, pair this with a Vigilmon keyword assertion that rejects "value":null — a null SOC means the BMS is offline.

Step 10: Cron Heartbeat for the OpenEMS Process

Add a systemd-triggered heartbeat so Vigilmon knows the OpenEMS JVM is alive:

# /etc/systemd/system/openems-heartbeat.service
[Unit]
Description=OpenEMS Vigilmon heartbeat
After=openems.service

[Service]
Type=oneshot
ExecStart=/usr/bin/curl -fsS "https://vigilmon.online/api/push/YOUR_HEARTBEAT_KEY"

# /etc/systemd/system/openems-heartbeat.timer
[Unit]
Description=Run OpenEMS heartbeat every minute

[Timer]
OnBootSec=60
OnUnitActiveSec=60
After=openems.service

[Install]
WantedBy=timers.target

Enable with:

systemctl daemon-reload
systemctl enable --now openems-heartbeat.timer

In Vigilmon, create a Heartbeat monitor with a 2-minute expected interval to absorb timer jitter.

Alerting Configuration

  1. In Vigilmon, go to Alert Channels and add your preferred destination (email, Slack, PagerDuty, webhook).
  2. Set Alert after: 2 consecutive failures for API/device monitors to avoid false alarms from transient Modbus retries.
  3. Set Alert after: 1 failure for the BMS data integrity monitor — a silent BMS is always urgent.
  4. Enable Recovery alerts so you know when a device controller comes back online after a fault.

Summary

| Monitor | Type | Interval | |---|---|---| | Web UI (port 8080) | HTTP | 1 min | | REST/JSON API (port 8085) | HTTP | 1 min | | OSGi component bundles | HTTP + keyword | 2 min | | Battery controller state | HTTP + keyword | 1 min | | Solar inverter state | HTTP + keyword | 1 min | | EV charger state | HTTP + keyword | 1 min | | Grid meter state | HTTP + keyword | 1 min | | Modbus bridge(s) | HTTP + keyword | 1 min | | Historian (InfluxDB TCP) | TCP Port | 2 min | | Scheduler/Optimizer | HTTP + keyword | 2 min | | WebSocket stream | Heartbeat | 2 min | | BMS data integrity | HTTP + keyword | 1 min | | OpenEMS JVM process | Heartbeat | 2 min |

OpenEMS coordinates real hardware — a missed fault can mean wasted solar yield, a discharged battery, or an EV left uncharged overnight. These thirteen monitors give you full-stack visibility from the JVM process down to individual device state channels, so you catch failures before they cascade.

Sign up for a free Vigilmon account to get started.

Monitor your app with Vigilmon

Free plan — 5 monitors, no credit card required. Up and running in 60 seconds.

Start free →
← Back to all articles