TapHome

Shelly EM

Packet Parser → HTTP
Submitted by
Last updated: 03. 2026
Shelly EM

The Shelly EM is a single-phase energy meter with two independent metering channels and a 2A relay output for contactor control. Each channel connects to an external CT (current transformer) clamp — available in 50A and 120A variants — allowing non-invasive monitoring of two separate circuits simultaneously. TapHome integrates with the device locally over Wi-Fi using either the HTTP REST API or MQTT. No cloud connection is required.

Two TapHome templates are available: an HTTP template that polls the device’s REST endpoints, and an MQTT template that receives data via an MQTT broker. Both expose the same three devices — two energy meters (one per channel) and a contactor switch.

Configuration

HTTP template

The HTTP template requires only the device’s IP address (or mDNS hostname). TapHome polls three endpoints every 15 seconds:

  • /emeter/0/ — channel 1 energy data
  • /emeter/1/ — channel 2 energy data
  • settings/relay/0 — relay state and schedule check

The module-level read script caches each response into a custom variable (emeterZero, emeterOne, status) so that individual device scripts can parse the data without making redundant HTTP calls.

The template also checks the relay schedule status from settings/relay/0. If internal scheduling is enabled on the Shelly device, the template raises an error — disable scheduling in the Shelly web UI to avoid conflicts with TapHome automation.

MQTT template

The MQTT template requires the broker IP, port, and the Shelly Device ID (format: shellyem-XXXXXXXXXXXX, where X = MAC hex digits). The Device ID can be found in the Shelly web UI under Settings > Device Info.

After enabling MQTT on the Shelly EM (Internet & Security > Advanced — MQTT), TapHome subscribes to shellies/shellyem-{deviceID}/ topics and receives data via listener scripts.

On Gen1 Shelly devices, enabling MQTT disables Shelly Cloud. Both cannot run simultaneously.

Device capabilities

Energy metering (per channel)

Each channel is exposed as an independent Electric Meter device in TapHome, providing:

  • Instantaneous power — active power in kW (converted from W by dividing by 1000)
  • Cumulative energy — total consumed energy in kWh (HTTP: converted from Wh; MQTT: uses the persistent total topic in Wh)

The HTTP template reads power and total fields from the /emeter/{i}/ JSON response. The MQTT template listens to the emeter/{i}/energy topic (watt-minutes, divided by 60 000 for kWh) and the emeter/{i}/total topic (watt-hours, persistent across reboots).

The MQTT energy topic resets to zero on device reboot. For persistent energy tracking, the template also reads the total topic which survives reboots.

Each channel also exposes three service attributes:

AttributeUnitDescription
VoltageVRMS line voltage
Energy ReturnedWhTotal energy returned to grid — for solar/bidirectional metering
Reactive PowerVARInstantaneous reactive power

The MQTT template exposes only voltage as a service attribute per channel. Reactive power and energy returned are available only in the HTTP template.

Contactor switch

The relay output is exposed as a switch device in TapHome. The relay is rated 2A / 230 VAC — it is designed for contactor control only, not for direct load switching.

  • HTTP: reads ison from settings/relay/0 and controls via /relay/0?turn=on or /relay/0?turn=off
  • MQTT: reads from shellies/shellyem-{id}/relay/0 topic and publishes on/off to shellies/shellyem-{id}/relay/0/command

The relay is rated only 2A. Always use an external contactor for loads exceeding this rating. Direct connection of high-power loads will damage the relay.

Additional capabilities

The Shelly EM also exposes power factor (0.00-1.00) and a measurement validity flag per channel, per-channel configuration (CT ratio, max power limit), energy counter reset, auto-off timer on the relay, and WiFi signal strength. Via MQTT, additional topics for real-time power, reactive power, and energy returned per channel are also available. These capabilities can be added in a future template update.

Troubleshooting

Device not responding (HTTP)
  1. Verify the Shelly EM is connected to Wi-Fi and has a valid IP address
  2. Open http://{device-ip}/shelly in a browser — if it responds with a JSON containing "type":"SHEM", the device is reachable
  3. Check that TapHome CCU and Shelly EM are on the same network / VLAN
No data on one channel
  1. Verify the CT clamp is connected to the correct 3.5mm jack (channel 0 or channel 1)
  2. Check that current is flowing through the monitored conductor — the CT clamp must encircle a single conductor, not the entire cable
  3. Poll /emeter/0/ and /emeter/1/ manually to confirm non-zero power values
MQTT messages not arriving
  1. Verify MQTT is enabled in the Shelly web UI (Internet & Security > Advanced — MQTT)
  2. Confirm the broker address and port are correct in both the Shelly device and TapHome module settings
  3. Check that the deviceID custom variable matches the Shelly’s Device ID exactly (e.g., B929CC)
  4. Use an MQTT client (e.g., MQTT Explorer) to subscribe to shellies/# and verify the device publishes messages
Schedule conflict error

The HTTP template checks the schedule field in settings/relay/0. If the Shelly device has internal scheduling enabled, the template reports an error. Disable scheduling in the Shelly web UI (Settings > Relay > Schedule) — use TapHome automations instead.

Gen1 Shelly devices support only 2 concurrent HTTP connections. If TapHome and another system (e.g., Home Assistant) poll the same device simultaneously, communication may become unreliable. Consider switching to the MQTT template for multi-system environments.

How to install in TapHome

Prerequisites

  • Shelly device installed and powered on
  • Local Wi-Fi network (2.4 GHz)
  • TapHome CCU on the same network

Step 1 — Connect Shelly to Wi-Fi

Option A — Shelly app (recommended):

  1. Download the Shelly app (iOS / Android)
  2. Tap + → Add Device and follow the Bluetooth pairing wizard
  3. Enter your Wi-Fi credentials when prompted

Option B — AP mode (no app):

  1. On first power-up the device creates a hotspot: ShellyXXX-AABBCCDDEE
  2. Connect your phone/PC to that hotspot
  3. Open http://192.168.33.1 → Internet & Security → Wi-Fi Mode - Client
  4. Enter SSID and password → Save

Shelly only supports 2.4 GHz networks. 5 GHz networks will not appear in the scan.

Step 2 — Find the device address

Shelly Gen1 devices support mDNS (Zeroconf). You can reach the device using a hostname instead of an IP address:

1

shelly<model>-<MAC>.local

For example: shelly1pm-AABBCCDDEE.local (MAC address in uppercase hex, no colons).

Recommended: use the TapHome IP Scanner. Open the TapHome app and use the IP Scanner (Settings → Network → Scan). The scanner will discover devices on your network and show both the IP address and the mDNS hostname. Use the hostname instead of the IP address for a more reliable connection — it stays the same even if the device’s IP changes after a router reboot.

Alternative methods to find the IP address:

  • Shelly app: Device detail → Device info → IP address
  • Shelly web UI: Connect to the device AP before Wi-Fi setup — the IP is shown after saving
  • Router DHCP table: Look for a hostname like shelly1pm-AABBCCDDEE

Step 3 — Configure in TapHome

  1. In TapHome, add a new Packet Parser (HTTP) module
  2. Address: enter the mDNS hostname (e.g., shelly1pm-AABBCCDDEE.local) or IP address from Step 2
  3. Port: 80 (default, no change needed)
  4. Import the template — TapHome will poll /status to read device state

HTTP authentication is disabled by default on Shelly devices. If you have enabled login protection, TapHome does not support HTTP Basic Auth at this time — keep auth disabled for TapHome integration.

Available devices

Shelly EM Module
Custom Variables

Shelly EM

Read (module)
VAR response := SENDHTTPREQUEST("settings/relay/0");
IF response.IsSuccess
 status := response.Content;
 IF PARSEJSON(status, "schedule")
  ADDERROR("Internal scheduling on");
 END
ELSE
 ADDERROR(response.StatusCode + " (" + response.ReasonPhrase + ")");
 RETURN(NaN);
END
response := SENDHTTPREQUEST("/emeter/0/");
IF response.IsSuccess
 emeterZero := response.Content;
ELSE
 ADDERROR(response.StatusCode + " (" + response.ReasonPhrase + ")");
 RETURN(NaN);
END
response := SENDHTTPREQUEST("/emeter/1/");
IF response.IsSuccess
 emeterOne := response.Content;
ELSE
 ADDERROR(response.StatusCode + " (" + response.ReasonPhrase + ")");
 RETURN(NaN);
END
Electric Meter — Channel 1 Electricity Meter Read-only

Instantaneous power (kW) and cumulative energy (kWh) from CT clamp on channel 1

numeric Unit: kW / kWh json_path
Service Attributes
Voltage
Energy ReturnedTotal energy returned to grid on channel 1 — for solar and bidirectional metering setups
Reactive Power

Electric Meter — Channel 1

Read total consumption
RETURN(PARSEJSON(emeterZero, "total")/1000);
Read demand
RETURN(PARSEJSON(emeterZero, "power")/1000);
Service Attributes
Voltage [V]
RETURN(PARSEJSON(emeterZero, "voltage"));
backward [Wh]
RETURN(PARSEJSON(emeterZero, "total_returned"));
reactive [W]
RETURN(PARSEJSON(emeterZero, "reactive"));
Electric Meter — Channel 2 Electricity Meter Read-only

Instantaneous power (kW) and cumulative energy (kWh) from CT clamp on channel 2

numeric Unit: kW / kWh json_path
Service Attributes
Voltage
Energy ReturnedTotal energy returned to grid on channel 2 — for solar and bidirectional metering setups
Reactive Power

Electric Meter — Channel 2

Read total consumption
RETURN(PARSEJSON(emeterOne, "total")/1000);
Read demand
RETURN(PARSEJSON(emeterOne, "power")/1000);
Service Attributes
Voltage [V]
RETURN(PARSEJSON(emeterOne, "voltage"));
backward [Wh]
RETURN(PARSEJSON(emeterOne, "total_returned"));
reactive [W]
RETURN(PARSEJSON(emeterOne, "reactive"));
Contactor Switch Switch

2A relay output for contactor control — not rated for direct load switching

boolean
Values / States: ON · OFF

Contactor Switch

Read switch state
RETURN(PARSEJSON(status, "ison"));
Write switch state
# Simple HTTP Request:
# VAR response := SENDHTTPREQUEST("/example/set/value=" + St);
VAR response := SENDHTTPREQUEST("/relay/0?turn="+ if(St = 1, "on","off"));
IF response.IsSuccess = false
 ADDERROR(response.StatusCode);
END
# Set Http request method, body and headers
# VAR response := SENDHTTPREQUEST("/example/setValue", "GET", "value=" + St, "header1:value1", "header2:value2", ...);\r
# Or VAR request := HTTPREQUEST("/example/setValue");
# request.Method := "PUT";
# VAR response := SENDHTTPREQUEST(request);
#r
#
# Send TCP, UDP data:
# VAR data1 := "{\"name\":\"John\", \"age\":" + St + "}";
# SENDDATA(data1);
# VAR data2 := TOBYTES("{\"name\":\"John\", \"age\":" + St + "}", "iso-8859-1");
# SENDDATA(data2);
# You can process received TCP or UDP data in the Listener script
#
#
# Upload data to FTP:
# FTPUPLOAD("filePath", "somedata=" + St, "write"); # use "append" mode to append data to existing file
Connection: Packet Parser → HTTP
Possible improvements (9)
  • Power Factor — Power factor (0.00–1.00) per channel, available in /emeter/{i} and /status response. Not available via MQTT.
  • Measurement Validity — Boolean flag indicating if the measurement is valid. Available per channel in /emeter/{i}.
  • Per-Channel Configuration — CT ratio (ctrafos: 50/120), max_power limit, appliance_type. Could be exposed as service actions.
  • Reset Energy Counters — Resets accumulated energy data for both channels. Available via HTTP GET and MQTT command topic.
  • Auto-off Timer — Auto-off timer in seconds on relay endpoint. Could be added as service action parameter.
  • WiFi Signal Strength — WiFi RSSI in dBm, available in /status response
  • MQTT Real-time Power — Instantaneous power via MQTT (W). MQTT template uses energy+total topics instead.
  • MQTT Reactive Power — Reactive power via MQTT (VAR). HTTP template has it as service attribute, MQTT template does not.
  • MQTT Energy Returned — Energy returned to grid via MQTT (Wh). HTTP template has it as service attribute (backward), MQTT template does not.

Sources