|
| 1 | +--- |
| 2 | +description: Present a Tasmota ESP32 device as a Shelly Gen2 Pro 2PM |
| 3 | +--- |
| 4 | + |
| 5 | +# Shelly Gen2 Emulation |
| 6 | + |
| 7 | +Shelly emulation presents a Tasmota device as a generation 2 **Shelly Pro 2PM** (`SPSW-202PE16EU`). It is intended for local controllers that discover and communicate with Shelly devices using mDNS and the [Shelly Gen2 RPC protocol](https://shelly-api-docs.shelly.cloud/gen2/General/RPCProtocol/), including the Sigenergy stack and its mySigen app. |
| 8 | + |
| 9 | +??? tip "This feature is included in standard `tasmota32` binaries" |
| 10 | + |
| 11 | + Shelly emulation is disabled at runtime by default. Standard `tasmota32` builds include the web server and mDNS discovery, so they advertise `_shelly._tcp` without requiring a custom build. |
| 12 | + |
| 13 | + Some specialized ESP32 variants can include Shelly emulation without mDNS discovery. In those builds, `/shelly` and `/rpc` remain available, but controllers cannot discover the device automatically. |
| 14 | + |
| 15 | + When [compiling your build](Compile-your-build), add the following to `user_config_override.h`: |
| 16 | + |
| 17 | + ```c++ |
| 18 | + #define USE_WEBSERVER |
| 19 | + #define USE_EMULATION_SHELLY |
| 20 | + #define USE_DISCOVERY |
| 21 | + ``` |
| 22 | + |
| 23 | + `USE_EMULATION` is enabled automatically when `USE_EMULATION_SHELLY` is defined. |
| 24 | + |
| 25 | +## Enable Shelly emulation |
| 26 | + |
| 27 | +Select **Configuration > Configure Other > Emulation > Shelly single device**, or run: |
| 28 | + |
| 29 | +```text |
| 30 | +Emulation 3 |
| 31 | +``` |
| 32 | + |
| 33 | +The device restarts after the emulation setting changes. Only one Tasmota emulation can be active at a time, so selecting Shelly emulation disables Belkin WeMo or Hue Bridge emulation. |
| 34 | + |
| 35 | +## Discovery and identity |
| 36 | + |
| 37 | +When Shelly emulation is selected, Tasmota advertises `_shelly._tcp` and `_http._tcp` on port 80 using mDNS. Discovery includes the active IPv4 and IPv6 addresses on Wi-Fi and Ethernet. |
| 38 | + |
| 39 | +The emulated identity is derived from the ESP32 Wi-Fi station MAC address: |
| 40 | + |
| 41 | +| Field | Value | |
| 42 | +|:---|:---| |
| 43 | +| Device type | Shelly Pro 2PM, generation 2 | |
| 44 | +| Model | `SPSW-202PE16EU` | |
| 45 | +| Device ID | `shellypro2pm-<lowercase-mac>` | |
| 46 | +| mDNS hostname | `ShellyPro2PM-<uppercase-mac>.local` | |
| 47 | +| Device name | Tasmota `DeviceName` | |
| 48 | + |
| 49 | +The controller and Tasmota device must be able to exchange multicast DNS traffic on UDP port 5353 and reach HTTP port 80. Networks that isolate wireless clients, filter multicast, or separate the controller and device across VLANs may require additional mDNS forwarding and firewall configuration. |
| 50 | + |
| 51 | +## Tasmota channel mapping |
| 52 | + |
| 53 | +The emulated device always exposes two switch, two input, and two metering channels: |
| 54 | + |
| 55 | +| Shelly component | Tasmota source | |
| 56 | +|:---|:---| |
| 57 | +| `switch:0` | `Power1` / `Relay1` | |
| 58 | +| `switch:1` | `Power2` / `Relay2` | |
| 59 | +| `input:0` | `Switch1` | |
| 60 | +| `input:1` | `Switch2` | |
| 61 | +| Metering for `switch:0` | Energy phase/channel 1 | |
| 62 | +| Metering for `switch:1` | Energy phase/channel 2 | |
| 63 | + |
| 64 | +If a relay is not configured, that Shelly output uses a persistent virtual state so controllers still see a working two-output Pro 2PM. An unconfigured input reports `false`. Metering fields report zero when no corresponding Tasmota energy channel is available. |
| 65 | + |
| 66 | +The emulation reports active power, voltage, frequency, current, power factor, imported active energy, and returned active energy when those values are supplied by the configured Tasmota energy driver. |
| 67 | + |
| 68 | +## HTTP and RPC interface |
| 69 | + |
| 70 | +The emulation implements the Shelly Gen2 device-information endpoint and the HTTP forms of RPC calls: |
| 71 | + |
| 72 | +```bash |
| 73 | +# Identify the emulated device |
| 74 | +curl http://<tasmota-ip>/shelly |
| 75 | + |
| 76 | +# Read all component status |
| 77 | +curl http://<tasmota-ip>/rpc/Shelly.GetStatus |
| 78 | + |
| 79 | +# Turn the first output on |
| 80 | +curl "http://<tasmota-ip>/rpc/Switch.Set?id=0&on=true" |
| 81 | + |
| 82 | +# Send a framed RPC request |
| 83 | +curl -X POST \ |
| 84 | + -H 'Content-Type: application/json' \ |
| 85 | + -d '{"id":1,"src":"user_1","method":"Switch.Toggle","params":{"id":1}}' \ |
| 86 | + http://<tasmota-ip>/rpc |
| 87 | +``` |
| 88 | + |
| 89 | +The supported RPC methods are: |
| 90 | + |
| 91 | +| Namespace | Methods | |
| 92 | +|:---|:---| |
| 93 | +| `Shelly` | `GetDeviceInfo`, `GetStatus`, `GetConfig`, `GetComponents`, `ListMethods`, `ListProfiles` | |
| 94 | +| `Switch` | `GetStatus`, `GetConfig`, `Set`, `Toggle` | |
| 95 | +| `Input` | `GetStatus`, `GetConfig` | |
| 96 | +| `Wifi` | `GetStatus`, `GetConfig` | |
| 97 | +| `BLE` | `GetStatus`, `GetConfig` | |
| 98 | +| `Sys` | `GetStatus`, `GetConfig` | |
| 99 | +| `RPC` | `Ping` | |
| 100 | + |
| 101 | +RPC component IDs are zero-based and limited to `0` and `1`. |
| 102 | + |
| 103 | +!!! warning "Local network control is unauthenticated" |
| 104 | + The emulation identifies itself with `auth_en: false`. Its `/shelly` and `/rpc` endpoints do not use Shelly digest authentication or Tasmota `WebPassword`, because local Shelly controllers must be able to discover and poll them. Enable this feature only on a trusted network. |
| 105 | + |
| 106 | +## Scope and limitations |
| 107 | + |
| 108 | +This is a compatibility layer for local Shelly discovery, polling, metering, and two-output control. It is not Shelly firmware and does not implement the complete Shelly ecosystem. |
| 109 | + |
| 110 | +- The emulated model and switch profile are fixed to a two-channel Shelly Pro 2PM. |
| 111 | +- Shelly Cloud, Shelly MQTT, WebSocket RPC, BLE transport, scripts, webhooks, schedules, firmware update, and Shelly configuration writes are not implemented. |
| 112 | +- Status is intended for polling. The emulation does not send Shelly RPC event notifications. |
| 113 | +- `GetConfig` methods report compatibility values; configuration must still be changed with Tasmota commands or the Tasmota web UI. |
| 114 | +- Only the methods listed above are supported. Other Shelly RPC calls return `Method not found`. |
| 115 | + |
| 116 | +## Troubleshooting |
| 117 | + |
| 118 | +1. Run `Emulation` and confirm it returns `3`. |
| 119 | +2. Open `http://<tasmota-ip>/shelly`. If this fails, confirm the firmware contains `USE_EMULATION_SHELLY` and `USE_WEBSERVER`. |
| 120 | +3. Browse for `_shelly._tcp` with `dns-sd -B _shelly._tcp` (macOS) or `avahi-browse -rt _shelly._tcp` (Linux). If the HTTP endpoint works but discovery does not, confirm the build contains `USE_DISCOVERY` and that multicast is not filtered. |
| 121 | +4. Confirm the controller and Tasmota device are on the same reachable network. For mySigen, the Shelly-compatible device and SigenStor must be connected to the same WLAN. |
| 122 | +5. If outputs or readings do not match, check the Tasmota template, relay count, switch assignments, and energy-driver channel order. |
| 123 | + |
| 124 | +See the official Shelly documentation for the [`/shelly` endpoint](https://shelly-api-docs.shelly.cloud/gen2/ComponentsAndServices/Shelly/) and [RPC over HTTP](https://shelly-api-docs.shelly.cloud/gen2/General/RPCChannels/). |
0 commit comments