---
title: "Shelly Flood"
description: "Shelly Flood water leak sensor in TapHome over MQTT: leak alarm, temperature and battery level. Up to 5 sensors per module, each by its MQTT Client ID."
url: "https://taphome.com/en/compatibility/shelly-flood-mqtt/"
language: en
lastmod: 2026-10-08
generator: hugo
ai:
  topics: ["mqtt","sensor","wifi","water-leak-detection","battery-powered"]
  questions: ["How to integrate Shelly Flood with TapHome via MQTT?","What does the Shelly Flood TapHome template detect?","How to configure multiple Shelly Flood sensors in one TapHome template?","Why is my Shelly Flood sensor not reporting data?","How to find the Shelly Flood MQTT Device ID?","Does Shelly Flood report battery level and temperature in TapHome?"]
---

# Shelly Flood

Communication: Packet Parser → MQTT

- [Shelly Flood Product Page](https://www.shelly.com/en/products/shop/shelly-flood)

The Shelly Flood is a battery-powered (CR123A) Wi-Fi water leak sensor. TapHome communicates with the device over MQTT — the recommended protocol for battery-operated Shelly devices, since the sensor sleeps most of the time and publishes data only on wake-up events.

The template supports up to 5 Shelly Flood sensors per module. Each sensor instance is distinguished by a `sensorN_topic` custom variable pointing to the device's MQTT Client ID.

## Configuration

### Device ID

Each Shelly Flood sensor has a unique MQTT Device ID in the format `shellyflood-<MAC6>`, where `<MAC6>` is the last 6 characters of the MAC address in lowercase hex (e.g., `shellyflood-112233`).

The Device ID can be found:

- On the device label (MAC address)
- In the Shelly web UI: **Settings** → **Device Info**
- Via API: `GET http://<device-ip>/settings` → `mqtt.id` field

> [!TIP]
> This device supports **mDNS discovery**. You can use the hostname `shellyflood-{MAC}.local` instead of an IP address when configuring TapHome. Replace `{MAC}` with the last 6 characters of the device's MAC address in lowercase hex (e.g., `shellyflood-112233.local`). Using a hostname prevents connectivity issues when the device's IP address changes.

### Template setup

After importing the template in TapHome:

1. Open the **Shelly Flood MQTT** module
2. Set the **MQTT Broker IP** and **Port** (default `1883`)
3. For each sensor instance, set the `sensorN_topic` custom variable to the Device ID of the corresponding Shelly Flood (e.g., `shellyflood-112233`)

The module subscribes to `shellies/#` and the listener scripts filter messages by the configured topic prefix.

> [!TIP]
> Only configure the sensor slots you actually use. Unconfigured slots (with the default `shellyflood-deviceid` value) will show an error message prompting you to set the correct topic.

## Device capabilities

### Water leak detection

Each sensor instance is mapped as a Reed Contact device in TapHome. The flood state is read from the `shellies/<id>/sensor/flood` topic:

- `true` → **Alarm** (water detected)
- `false` → **OK** (dry)

The sensor wakes up and publishes its state when water is detected or gone, and also during periodic reporting intervals.

### Battery and temperature monitoring

Each sensor instance exposes two service attributes:

- **Battery** — battery level percentage read from `shellies/<id>/sensor/battery`. A low battery warning is triggered when the level drops below 20%.
- **Temperature** — ambient temperature in °C read from `shellies/<id>/sensor/temperature`.

Both attributes are read-only and update whenever the sensor wakes up and publishes data.

### Additional capabilities

The Shelly Flood also publishes an online/offline status via the MQTT Last Will and Testament (LWT) topic, and a full JSON status message (firmware ≥1.8.0). A `rain_sensor` setting is available that inverts the flood detection logic for outdoor rain detection use. These capabilities can be added in a future template update.

## Troubleshooting

### Sensor not reporting data

1. Verify the Shelly Flood is connected to Wi-Fi and MQTT is enabled in the device settings
2. Check that the `sensorN_topic` custom variable matches the Device ID exactly (e.g., `shellyflood-112233`)
3. If the MQTT broker address changed, try using the mDNS hostname (`shellyflood-AABBCC.local`) to verify the sensor is reachable on the network
4. Use an MQTT client (e.g., MQTT Explorer) to subscribe to `shellies/#` and verify the sensor publishes messages on wake-up

### Flood alarm not triggering

1. Confirm the sensor contacts on the bottom of the device are clean and not obstructed
2. Test by placing the sensor on a wet surface — the device should publish `true` on the `/sensor/flood` topic within seconds
3. Check TapHome for the Reed Contact device state — 1 = alarm, 0 = OK

### Battery draining quickly

1. Shelly Flood is designed for long battery life (CR123A, typically 1–2 years depending on reporting frequency)
2. Frequent wake-ups (e.g., due to unstable Wi-Fi requiring repeated reconnection) can drain the battery faster
3. Ensure strong Wi-Fi signal at the sensor location

> [!WARNING]
> Gen1 Shelly devices do **not** support MQTT over TLS. Communication between the sensor and the MQTT broker is unencrypted (plain MQTT, port 1883). Ensure the MQTT broker is on a trusted local network.

## How to install in TapHome

### Prerequisites

- Shelly device connected to Wi-Fi (2.4 GHz), e.g. through the Shelly app or the device's own access point
- MQTT broker running on your local network (e.g., Mosquitto, Home Assistant, or TapHome built-in broker)
- TapHome CCU on the same network as the broker

> [!WARNING]
> On **Gen1** devices, enabling MQTT **disables Shelly Cloud**. Both cannot run simultaneously. On Gen2/Plus devices this limitation does not apply.

### Step 1 — Enable MQTT on the Shelly device

#### Gen1 devices (Shelly 1, 1PM, 2.5, EM, 3EM, Plug S, RGBW2, Dimmer, TRV…)

1. Open the Shelly web UI: `http://<device-ip>/`
2. Navigate to **Internet & Security** → **Advanced — MQTT**
3. Enable **MQTT**
4. Set **MQTT Server**: `<broker-ip>:<port>` (e.g., `192.168.1.10:1883`)
5. Optionally set **MQTT User** and **MQTT Password** if your broker requires authentication
6. Click **Save** — the device will reboot and connect to the broker

#### Gen2 / Plus devices (Shelly Plus 1, Plus 1PM, Plus 2PM, Plus Plug S, Plus H&T, Pro 3EM…)

1. Open the Shelly web UI: `http://<device-ip>/`
2. Navigate to **Settings** → **MQTT**
3. Enable **MQTT**
4. Set **Server**: `<broker-ip>:<port>` (e.g., `192.168.1.10:1883`)
5. The **Client ID** is pre-filled with the device ID (e.g., `shellyplus1pm-AABBCCDDEE`) — leave as-is unless you have a specific reason to change it
6. Click **Save** and reboot the device

> [!TIP]
> To verify MQTT is working, use an MQTT client (e.g., MQTT Explorer) and subscribe to `shellies/#` (Gen1) or `<device-id>/#` (Gen2). You should see status messages from the device.

### Step 2 — Find the Device ID / MQTT Client ID

Some templates require a **Device ID** or **MQTT Client ID** parameter. This is the unique identifier used in MQTT topics.

- **Gen1:** found on the label as MAC address (e.g., `AABBCCDDEE`). Device ID = `shelly<model>-<mac>`, e.g., `shelly1pm-AABBCCDDEE`
- **Gen2/Plus:** found in the Shelly web UI under **Settings** → **Device Info** → **Device ID**, or on the device label

### Step 3 — Configure in TapHome

1. In TapHome, add a new **Packet Parser (MQTT)** module
2. **IP Address:** enter the MQTT broker IP (e.g., `192.168.1.10`)
3. **Port:** `1883` (default; use `8883` for TLS)
4. **Device ID / MQTT Client ID:** enter the value from Step 2 (if required by the template)
5. Import the template — TapHome will subscribe to the device topics automatically

## Available devices

Shelly Flood MQTT Module

Custom Variables

|                                                 |                                                                                                                                 |
|-------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------|
| `sensor1_topic` (string) = shellyflood-deviceid | MQTT topic name of flood sensor 1 — format is 'shellyflood-DEVICEID' (find Device ID in Shelly web UI → Settings → Device Info) |
| `sensor2_topic` (string) = shellyflood-deviceid | MQTT topic name of flood sensor 2                                                                                               |
| `sensor3_topic` (string) = shellyflood-deviceid | MQTT topic name of flood sensor 3                                                                                               |
| `sensor4_topic` (string) = shellyflood-deviceid | MQTT topic name of flood sensor 4                                                                                               |
| `sensor5_topic` (string) = shellyflood-deviceid | MQTT topic name of flood sensor 5                                                                                               |

Flood Sensor 1 Reed Contact Read-only

Water leak detection — reports alarm on water presence, OK when dry

boolean

Service Attributes

|             |
|-------------|
| Battery     |
| Temperature |

Flood Sensor 2 Reed Contact Read-only

Water leak detection — reports alarm on water presence, OK when dry

boolean

Service Attributes

|             |
|-------------|
| Battery     |
| Temperature |

Flood Sensor 3 Reed Contact Read-only

Water leak detection — reports alarm on water presence, OK when dry

boolean

Service Attributes

|             |
|-------------|
| Battery     |
| Temperature |

Flood Sensor 4 Reed Contact Read-only

Water leak detection — reports alarm on water presence, OK when dry

boolean

Service Attributes

|             |
|-------------|
| Battery     |
| Temperature |

Flood Sensor 5 Reed Contact Read-only

Water leak detection — reports alarm on water presence, OK when dry

boolean

Service Attributes

|             |
|-------------|
| Battery     |
| Temperature |

**Connection:** Packet Parser → MQTT • Hostname: `shellyflood-{MAC}.local`

Possible improvements (2)

- Connection Status — LWT topic — true on connect, false on disconnect. Could detect offline sensors.
- Full Status JSON — Complete /status as JSON (fw ≥1.8.0). Could parse wifi\_sta.rssi, battery, act\_reasons.

## Sources

- Shelly Gen1 API Reference
  
  [shelly-api-docs.shelly.cloud](https://shelly-api-docs.shelly.cloud/gen1/) 2026-03-12
- Shelly Flood — Device-Specific API
  
  [shelly-api-docs.shelly.cloud](https://shelly-api-docs.shelly.cloud/gen1/#shelly-flood-mqtt) 2026-03-12

## Related Documentation

- [MQTT Integration](https://taphome.com/en/compatibility/mqtt-guide/)
- [Packet Parser (HTTP, TCP, UDP, FTP, MQTT)](https://taphome.com/en/docs/integration/packet-parser/)
- [Packet parser functions](https://taphome.com/en/docs/script/packet-parser/)
- [Parsing functions](https://taphome.com/en/docs/script/parsing-functions/)
- [MQTT Broker](https://taphome.com/en/docs/integration/packet-parser/mqtt-broker/)
- [Listener scripts](https://taphome.com/en/docs/script/listener-scripts/)

