energy-device-gateway

Tool v0.1.0 TypeScript MIT

Self-hosted energy gateway with live browser dashboard, secure login, normalized meter payloads, and IAMMETER-compatible forwarding for selected LAN devices.

View on GitHub Docs →
energy-device-gateway

Project overview

energy-device-gateway is the self-hosted control-plane option in this project family. Instead of running the bridge logic on a tiny embedded device, you run it on normal hardware such as a NAS, mini PC, home server, or Docker host and get a fuller browser console in return.

The gateway is built for people who want local control first:

  • read supported meters and inverters on the LAN
  • normalize the data into one shared payload model
  • inspect the runtime state in a browser
  • protect the setup with login
  • optionally forward the same data to IAMMETER-compatible services

That makes it useful as both a day-to-day monitoring layer and a practical staging point before data is sent elsewhere.

Why choose the gateway version

Compared with the embedded edge firmware, the gateway gives you more room to operate:

  • normal filesystem storage for configuration and runtime state
  • easier backups and host-level monitoring
  • a richer live view for troubleshooting
  • a more familiar deployment path for Docker and server users
  • browser-based password management and service controls

It is the better choice when you already have always-on hardware and want the monitoring bridge to feel more like a dependable service than a small appliance.

Real console screenshots

energy-device-gateway live dashboard

The live view is designed for operational checking rather than marketing screenshots: source health, latest upload result, trend, phase detail, and recent events are all visible without leaving the page.

energy-device-gateway settings view

The settings area keeps source selection, host details, upload target, and access-control tasks together so the gateway can be maintained as a long-running local service.

Supported device families

The current scope is intentionally selective and focused on source devices that are useful in real monitoring setups:

  • IAMMETER WEM3080T
  • Fronius SunSpec inverters
  • Shelly Pro 3EM

The gateway converts them into one normalized runtime model, which means the browser console and uploader do not need a separate workflow for each device family.

Best-fit scenarios

energy-device-gateway fits especially well when you want:

  • a self-hosted local monitoring layer on hardware you already own
  • one browser console for runtime checks, settings, and upload validation
  • a cleaner path for backups, logs, and later expansion
  • a service that can stay online quietly in the background instead of a laptop-only dev tool

Host choices

The gateway does not require special hardware. Common hosts include:

  • a NAS that can run containers
  • a mini PC used for home automation or network services
  • a small Linux server
  • a Docker-capable workstation for testing

Basic startup path

For many users, a Docker-style run is the quickest path to a first evaluation:

docker build -t energy-device-gateway .
docker run --rm -p 8080:8080 energy-device-gateway

You can also run it directly with Node.js during development:

npm install
npm run typecheck
npm test
npm run dev

First access

After the service starts, open the browser console at the configured host and port. On the first run, the project can bootstrap the administrator password from the UI when no password has been preconfigured.

That first-login flow is important because it means the gateway can be deployed cleanly in both casual lab setups and more deliberate long-running installs.

A stable first deployment usually looks like this:

  1. Start the gateway on the host that will stay online.
  2. Set the administrator password.
  3. Configure one supported source device.
  4. Check the live dashboard locally.
  5. Enable forwarding only after the local readings and payload look correct.

Ongoing maintenance

Because the gateway runs like a normal service, routine care is straightforward:

  • keep the host online
  • back up the config if the install matters
  • revisit settings only when the source device, upload target, or password changes
  • use the live dashboard as the first stop when you want to verify source health

This is a network integration project

energy-device-gateway does not wire directly into mains measurement points. It reads data from already-networked devices and should be treated as the software layer that sits between those devices and your browser or upload destination.

A healthy deployment usually looks like this:

  1. The physical meter or inverter is installed and publishing local data.
  2. The gateway host sits on the same LAN or a routed local network.
  3. The gateway polls the source device over the relevant local protocol.
  4. Operators check the browser console first.
  5. Optional forwarding sends the normalized payload to the chosen destination.

Host placement advice

For the smoothest experience, place the gateway on hardware that:

  • stays powered on continuously
  • has stable LAN access to the source device
  • is easy to back up or redeploy
  • can be reached easily in a browser from the rest of your local network

Validation checklist after setup

  • the source device reads correctly in the live dashboard
  • the expected phases and counters look plausible
  • recent events do not show repeated communication failures
  • login works reliably after the initial bootstrap
  • upload remains off until the normalized local data has been checked

Main configuration areas

The gateway console is intentionally split into the tasks people actually perform:

  • source setup
  • upload target setup
  • authentication and password rotation
  • runtime inspection
  • restart and service-level controls

Source configuration

For a typical install, the source setup includes:

  • device family
  • device host or IP
  • source port
  • local identity details used by the runtime model

Because the project supports only a short list of source families, the configuration stays readable and easier to validate.

Upload targets

The gateway can be used as a local-only browser console, but it can also forward normalized payloads to:

  • IAMMETER Cloud
  • a compatible local endpoint
  • another destination that accepts the expected upload path and payload shape

That flexibility makes the gateway useful as a standalone operator console and as an intermediary layer in a broader monitoring stack.

Authentication model

The browser console is protected by login. Passwords are stored as one-way hashes unless an environment-managed password is supplied by the host. This is a practical difference from lighter embedded tools: the gateway is designed to live on normal infrastructure and behave like a real service.

Runtime views that matter

The Live screen is where most validation happens:

  • current power and energy state
  • phase-by-phase readings
  • recent history or trend context
  • recent runtime events
  • the upload status and payload path

That combination makes it easier to decide whether a problem is coming from the source device, the LAN, or the upload target.

← Back to our projects