A Val Town project for automating myenergi Zappi and Eddi devices using the raw myenergi API. It includes secure API endpoints, scheduled cron jobs, and examples for turning Zappi charging on or off, changing charge modes, reading Eddi temperature, triggering Eddi boosts, and building custom myenergi automation workflows.

You will need the following environment variables:

MYENERGI_HUB_SERIAL=
MYENERGI_API_KEY=
MYENERGI_API_TOKEN=
ZAPPI_SERIAL=
ZAPPI_CRON_ON_MODE=eco_plus
ZAPPI_DEFAULT_ON_MODE=eco_plus
EDDI_SERIAL=
EDDI_DEFAULT_TARGET=1

Set the cron/default mode to your preferred setting. EDDI_DEFAULT_TARGET controls which heater/relay output is used when a boost call doesn't specify one (1 = Heater 1, 2 = Heater 2, 11 = Relay 1, 12 = Relay 2).

ZAPPI_SERIAL and EDDI_SERIAL are each optional — set whichever devices you actually have. Calls to an endpoint for a device you haven't configured will return an error.

lib/myenergi.ts = reusable myenergi client and auth logic. zappiApi.ts and eddiApi.ts = the HTTP API layers. You can call these from workflows, telegram bots etc, or use the existing cron files to run on a schedule. There is two cron files for Zappi. You can reference these for Eddi if needed.

This project integrates with the myenergi API to automate Zappi chargers and Eddi hot water diverters.

At the time of writing, myenergi says the API exists but is not officially supported and was originally developed for internal use. Their help centre directs developers to the community forum for help and examples.

This README focuses on the parts needed for simple Zappi and Eddi automation:

• where to get the API key
• which serial numbers you need
• how authentication works
• the main status and control endpoints
• the caveats to be aware of

---

For the raw API flow used in this project, you need:

• your gateway / hub serial number
• an API key
• your Zappi serial number (if using a Zappi)
• your Eddi serial number (if using an Eddi)

In this project, those are typically stored as:

• MYENERGI_HUB_SERIAL
• MYENERGI_API_KEY
• ZAPPI_SERIAL
• EDDI_SERIAL

---

To generate an API key:

1. Log in to myaccount.myenergi.com with the same account that originally registered the devices
2. Go to Products
3. At the top of the device list, open the Gateway Device
4. Click Advanced (small key icon)
5. Click Generate new API key

Important notes:

• The API key is only available in the account that originally registered the devices. If you do not see the Advanced option, myenergi says you are probably logged into a shared or different account.
• Generating a new API key invalidates the old one immediately.
• The new key is shown once only, so copy it straight away.

---

myenergi's official guidance says API access requires the hub serial number plus the API key. The "Gateway Device" may be:

• a physical myenergi hub
• or another myenergi device acting as the gateway if it has built-in internet connectivity

For a standard Zappi, the serial number can be found:

• on the label on the left side of the unit
• on the device under Menu → Information
• in the app under Menu → Settings → Device Settings

For a standard Eddi, the serial number can be found:

• on the label on the side of the unit
• on the device under Menu → Information
• in the app under Menu → Settings → Device Settings

If you are using vHub, it can appear in the device list with the same serial number as the device acting as vHub, which can make the hub/device distinction a bit confusing.

---

The raw API flow commonly used by community integrations uses HTTP Digest Authentication with:

• realm "MyEnergi Telemetry"
• qop="auth"
• algorithm="MD5"

For current usage, the typical credentials are:

• username = hub / gateway serial number
• password = API key

---

Community integrations generally resolve the backend in one of two ways:

Use the last digit of the hub serial:

https://s<lastDigit>.myenergi.net/

Call https://director.myenergi.net/ first and read the x_myenergi-asn response header to determine the correct backend host. This is commonly used because myenergi has moved users onto newer hosts such as s18.myenergi.net.

In practice, newer integrations usually prefer the director lookup approach.

---

The API surface is broader than what is listed here, but these are the main parts relevant to Zappi and Eddi automation.

/cgi-jstatus-*

Returns current status for the myenergi ecosystem and can include arrays for devices such as zappi, eddi, and others.

/cgi-jstatus-Z

Useful when you only care about Zappi data.

/cgi-jstatus-Z<ZAPPI_SERIAL>

Example:

/cgi-jstatus-Z10077777

This is the most useful status endpoint for a single-Zappi automation flow.

/cgi-jstatus-E<EDDI_SERIAL>

Example:

/cgi-jstatus-E20088888

This is the most useful status endpoint for a single-Eddi automation flow.

From the documented community response structure, common fields include:

• sno = serial number
• sta = status
• zmo = Zappi mode
• grd = grid power
• vol = supply voltage
• che = charging / delivered energy related value
• mgl = minimum green level

The documented zmo mode mapping is:

• 1 = Fast
• 2 = Eco
• 3 = Eco+
• 4 = Stopped

From the documented community response structure, common fields include:

• sno = serial number
• bsm = boost state (1 = boosting)
• tp1 = temperature probe 1 (°C, 127 means "not connected")
• tp2 = temperature probe 2 (°C, 127 means "not connected")
• rbc = relay board connected
• r1a / r2a = relay 1 / relay 2 active
• r1b / r2b = relay 1 / relay 2 boost type
• dat / tim = device date and time

---

These are the key endpoints for simple mode switching.

/cgi-zappi-mode-Z<ZAPPI_SERIAL>-1-0-0-0000

/cgi-zappi-mode-Z<ZAPPI_SERIAL>-2-0-0-0000

/cgi-zappi-mode-Z<ZAPPI_SERIAL>-3-0-0-0000

/cgi-zappi-mode-Z<ZAPPI_SERIAL>-4-0-0-0000

These mappings are widely documented in the reverse-engineered app API reference.

For most automations:

• On = fast, eco, or eco_plus
• Off = stop

---

/cgi-zappi-mode-Z<ZAPPI_SERIAL>-0-10-5-0000

The documented example corresponds to a 5 kWh manual boost.

/cgi-zappi-mode-Z<ZAPPI_SERIAL>-0-11-5-1400

The documented example corresponds to 5 kWh, completed by 14:00.

/cgi-zappi-mode-Z<ZAPPI_SERIAL>-0-2-0-0000

Successful control calls are commonly documented as returning:

{
  "status": 0,
  "statustext": ""
}

---

Eddi boosts use a separate endpoint shape that takes a target output and a duration in minutes.

/cgi-eddi-boost-E<EDDI_SERIAL>-10-<TARGET>-<MINUTES>

Example — boost Heater 1 for 60 minutes:

/cgi-eddi-boost-E20088888-10-1-60

/cgi-eddi-boost-E<EDDI_SERIAL>-1-<TARGET>-0

Community documentation maps the target parameter to:

• 1 = Heater 1
• 2 = Heater 2
• 11 = Relay 1
• 12 = Relay 2

Successful boost calls return the same { "status": 0, "statustext": "" } shape as Zappi control calls.

---

/cgi-jlock-<ZAPPI_SERIAL>-01000000

Examples:

• /cgi-set-min-green-Z<ZAPPI_SERIAL>-60
• /cgi-set-min-green-Z<ZAPPI_SERIAL>-100

Examples:

• /cgi-zappi-phase-setting-Z<ZAPPI_SERIAL>-0
• /cgi-zappi-phase-setting-Z<ZAPPI_SERIAL>-1
• /cgi-zappi-phase-setting-Z<ZAPPI_SERIAL>-2

Community documentation maps these to:

• 0 = single phase
• 1 = three phase
• 2 = auto

Examples:

• /cgi-jdayhour-Z<ZAPPI_SERIAL>-YYYY-M-D
• /cgi-jdayhour-E<EDDI_SERIAL>-YYYY-M-D

These are more useful for reporting and analysis than for simple device control.

---

A typical request flow is:

1. Resolve the correct backend host
2. Authenticate using Digest auth
3. Call a status or control endpoint

Example shape:

curl --digest -u HUB_SERIAL:API_KEY \
  -H 'accept: application/json' \
  'https://HOST/cgi-jstatus-ZZAPPI_SERIAL'

curl --digest -u HUB_SERIAL:API_KEY \
  -H 'accept: application/json' \
  'https://HOST/cgi-jstatus-EEDDI_SERIAL'

This matches myenergi's official guidance that access uses the hub serial and API key, plus the community-documented Digest auth flow.

---

For a small automation service, these are the key values:

MYENERGI_HUB_SERIAL=<gateway_or_hub_serial>
MYENERGI_API_KEY=<generated_api_key>
ZAPPI_SERIAL=<zappi_serial>
EDDI_SERIAL=<eddi_serial>

These values come from the official myenergi account/device flow described above. Set only the device serials you actually have.

If your service exposes its own HTTP endpoint, you will usually also add your own app-level secret, for example:

MYENERGI_API_TOKEN=<your_own_secret>

That token is your own application secret, not a myenergi value.

---

• myenergi says the API is not officially supported today.
• The key-generation flow is official, but many of the concrete endpoints above come from community reverse-engineering rather than a polished supported developer portal.
• Regenerating the API key immediately invalidates the old one.
• If vHub is involved, serial numbers can be slightly confusing because the gateway/device relationship may not be obvious.
• Eddi temperature probes report 127 when no probe is connected — treat that as "unavailable" rather than a real reading.
• Because the API is unsupported, it is safest to treat undocumented behaviour as subject to change. That last point is an inference from myenergi's support position.

---

For simple Zappi and Eddi automation, the minimum useful setup is:

• hub / gateway serial
• API key
• Zappi and/or Eddi serial
• Digest auth
• cgi-jstatus-Z<serial> / cgi-jstatus-E<serial> for reads
• cgi-zappi-mode-Z<serial>-... for Zappi mode changes
• cgi-eddi-boost-E<serial>-... for Eddi boosts