Uptime monitoring for openHAB smart home automation platform

openHAB is the backbone of many production smart home deployments — it controls lights, thermostats, door locks, security systems, and hundreds of other devices. When openHAB goes down, automation rules stop firing, devices become uncontrollable, and occupants lose visibility into their home. Unlike a web application outage, a dead home automation hub can mean unlocked doors, unmonitored HVAC, or failed security alerts.

This tutorial covers production-grade uptime monitoring for openHAB using Vigilmon. We will walk through:

• Monitoring the openHAB REST API health endpoint
• Monitoring the openHAB dashboard and Main UI
• SSL certificate monitoring for remote access
• Webhook alerts for DOWN/UP events
• Monitoring openHAB on Docker and Linux

Prerequisites

• openHAB 3.x or 4.x running on Linux, Raspberry Pi, or Docker
• A free account at vigilmon.online

Part 1: Identify the openHAB health endpoint

openHAB exposes a REST API that Vigilmon can poll to verify the platform is alive and responding. The /rest/ endpoint returns a JSON summary of the openHAB API and is safe to hit externally without authentication.

Default ports

| Access type | URL | |-------------|-----| | HTTP (local) | http://openhab-host:8080/rest/ | | HTTPS (with reverse proxy) | https://openhab.example.com/rest/ | | Main UI | http://openhab-host:8080/ |

Verify the REST API is responding

curl -s http://localhost:8080/rest/ | head -5

Expected output includes the openHAB version and available links:

{
  "version": "4.2.0",
  "locale": "en-US",
  "measurementSystem": "SI",
  "links": [...]
}

If the REST API returns 200 with JSON, openHAB is running and accepting requests. If it times out or returns 503, openHAB or its underlying Java runtime is not healthy.

Dedicated alive endpoint

openHAB 4.x includes a dedicated alive check at /rest/alive:

curl -s http://localhost:8080/rest/alive

This returns HTTP 200 with no body when the server is up, making it an ideal lightweight monitor target that does not require parsing JSON.

Part 2: Expose openHAB for external monitoring

If Vigilmon needs to reach openHAB from outside your local network, you have two options.

Option A — reverse proxy with nginx

# /etc/nginx/sites-available/openhab
server {
    listen 443 ssl;
    server_name openhab.example.com;

    ssl_certificate /etc/letsencrypt/live/openhab.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/openhab.example.com/privkey.pem;

    # Allow monitoring endpoint without auth
    location /rest/alive {
        proxy_pass http://localhost:8080/rest/alive;
        proxy_set_header Host $host;
    }

    # Require auth for everything else
    location / {
        auth_basic "openHAB";
        auth_basic_user_file /etc/nginx/.htpasswd;
        proxy_pass http://localhost:8080/;
        proxy_set_header Host $host;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

This exposes /rest/alive without credentials while protecting the Main UI and full REST API behind basic auth.

Option B — openHAB Cloud Connector

If you use myopenhab.org (the official openHAB cloud), your instance is reachable via https://home.myopenhab.org. You can monitor this URL directly, though it adds a dependency on the cloud relay that local monitoring does not have.

Part 3: Set up HTTP monitoring in Vigilmon

Monitor the openHAB REST API

1. Log in to vigilmon.online and click Add Monitor.
2. Choose HTTP(S) monitor.
3. Enter: https://openhab.example.com/rest/alive
4. Set interval to 1 minute.
5. Set expected HTTP status to 200.
6. Add your alert channel.
7. Click Save.

Monitor the Main UI

Add a second monitor for the web dashboard to catch frontend failures independently:

1. Click Add Monitor → HTTP(S) monitor.
2. Enter: https://openhab.example.com/
3. Set interval to 2 minutes.
4. Add a keyword check: must contain openHAB (present in the page title).
5. Click Save.

| Monitor | URL | Check | |---------|-----|-------| | openHAB API | https://openhab.example.com/rest/alive | HTTP 200 | | openHAB UI | https://openhab.example.com/ | keyword: openHAB |

Part 4: SSL certificate monitoring

openHAB is often exposed via Let's Encrypt certificates managed by nginx or Caddy. Certificate renewal failures are silent until the cert expires, at which point remote access to your home automation stops working.

1. In Vigilmon, click Add Monitor.
2. Choose SSL monitor.
3. Enter your openHAB domain: openhab.example.com
4. Set alert threshold to 14 days before expiry.
5. Add your alert channel.

If you also expose openHAB via myopenhab.org, add an SSL monitor for home.myopenhab.org to catch issues with the cloud relay certificate.

Part 5: Webhook alerts

Add a webhook receiver to your infrastructure to receive DOWN/UP events from Vigilmon. This can live on any server in your network, or on a serverless function:

// webhook-receiver.ts (Node.js / Express)
import express from 'express';

const app = express();
app.use(express.json());

app.post('/webhook/vigilmon', (req, res) => {
  const { monitor_name, status, url, response_code, checked_at } = req.body;

  if (status === 'down') {
    console.error('[VIGILMON] openHAB DOWN', {
      monitor: monitor_name,
      url,
      code: response_code,
      at: checked_at,
    });

    // Trigger fallback lighting rules, send push notification,
    // wake on-call engineer, etc.
    sendPushAlert(`openHAB is DOWN as of ${checked_at}`);
  } else if (status === 'up') {
    console.info('[VIGILMON] openHAB recovered', { monitor: monitor_name });
  }

  res.sendStatus(204);
});

app.listen(3000);

Vigilmon sends this payload on DOWN and UP transitions:

{
  "monitor_id": "mon_abc123",
  "monitor_name": "openHAB API",
  "status": "down",
  "url": "https://openhab.example.com/rest/alive",
  "checked_at": "2026-06-30T08:01:00Z",
  "response_code": 503,
  "response_time_ms": 8412
}

Part 6: Docker deployments

If you run openHAB in Docker, add a health check to detect JVM hangs or startup failures that leave the container running but unresponsive:

# docker-compose.yml
version: "3.8"

services:
  openhab:
    image: openhab/openhab:4.2.0
    restart: unless-stopped
    ports:
      - "8080:8080"
      - "8443:8443"
    volumes:
      - ./openhab_addons:/openhab/addons
      - ./openhab_conf:/openhab/conf
      - ./openhab_userdata:/openhab/userdata
    environment:
      - CRYPTO_POLICY=unlimited
      - EXTRA_JAVA_OPTS=-Xms256m -Xmx512m
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8080/rest/alive"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 90s

The start_period: 90s accounts for openHAB's slow JVM startup. Once past the grace period, Vigilmon's external polling and Docker's internal health check provide two independent layers of detection.

Check the container health status:

docker inspect openhab --format='{{.State.Health.Status}}'

Part 7: Monitoring openHAB add-ons and bindings

Individual openHAB bindings can fail while the core platform stays up. You can expose binding status via the REST API and monitor it with Vigilmon:

# Check a specific thing's status
curl -s http://localhost:8080/rest/things | \
  jq '.[] | select(.label == "My Z-Wave Controller") | .statusInfo'

For critical infrastructure bindings (Z-Wave controller, MQTT broker connection, database persistence), consider writing a small health-check script that polls the REST API and exposes a /health endpoint:

#!/bin/bash
# /usr/local/bin/openhab-binding-health
# Returns 0 if all critical things are ONLINE, 1 otherwise

THINGS=$(curl -sf http://localhost:8080/rest/things)
OFFLINE=$(echo "$THINGS" | jq '[.[] | select(.statusInfo.status != "ONLINE")] | length')

if [ "$OFFLINE" -gt "0" ]; then
  echo "DEGRADED: $OFFLINE things offline"
  exit 1
fi

echo "OK"
exit 0

Run this script as a local HTTP endpoint (via a small shell server or systemd socket) and add it as a Vigilmon HTTP monitor with keyword check OK.

Summary

Your openHAB deployment now has four layers of monitoring:

1. REST API monitor — confirms openHAB's Java runtime and REST layer are responding, polled every 60 seconds by Vigilmon.
2. Main UI monitor — confirms the web interface is accessible for remote management.
3. SSL monitor — alerts you 14 days before your certificate expires, before remote access fails.
4. Webhook/Slack alerts — DOWN and UP events are delivered to your team or personal notification channel within one check interval.

Vigilmon handles check scheduling, multi-region polling, alert routing, and uptime history. You get notified within 60 seconds of any openHAB failure, whether it's a JVM crash, a failed binding, or an expired certificate.

Monitor your openHAB installation free at vigilmon.online

#openhab #smarthome #iot #homeautomation #monitoring