Der neue Monatsrückblick für Mai und Juni 2026 ist online!

[Dieter_P]

Hallo zusammen,

ich habe mir einen Shelly Flood Gen4 zugelegt und betreibe ioBroker mit Shelly- und Zigbee-Adapter. Der Sensor soll sicherheitskritisch laufen (zuverlässige, zeitnahe Alarm-Zustellung) bei möglichst langer Batterielaufzeit.

Vorab, damit klar ist, was ich schon geprüft habe:

• Im Shelly-Adapter ist der Flood Gen4 als shellyfloodg4 gelistet (WLAN/MQTT, ab v10.3.0).
• Gen4-Zigbee-Berichte hier im Forum drehen sich bisher v.a. um Schaltaktoren (1PM); teils war die ZHC_latest-Version nötig, teils fehlten einzelne States.
• Im Zigbee-Modus nutzt der Gen4 kein paralleles WLAN (also keine Shelly-Cloud/Matter darüber).

Meine Fragen:

1. Shelly-Adapter (WLAN/MQTT): Betreibt jemand den Flood Gen4 produktiv darüber? Welche Datenpunkte kommen an (Flood/Dry-Wet, Batterie, ggf. Temperatur, Tamper)? Wird der Alarm trotz Deep-Sleep zuverlässig und zeitnah zugestellt?

2. Zigbee-Adapter: Läuft der Flood Gen4 speziell über Zigbee? Ist die Definition schon in der regulären Adapter-/ZHC-Version enthalten oder nur in ZHC_latest? Welcher State-Umfang (Dry/Wet, Battery, Tamper, Trouble)? Und stört das bekannte "unavailable" im Sleep die Alarm-Trigger in der Praxis?

3. Empfehlung: Für einen sicherheitskritischen Wassersensor – eher WLAN/MQTT über den Shelly-Adapter oder Zigbee? Gibt es belastbare Erfahrungswerte zur Batterielaufzeit im jeweiligen Modus?

Danke vorab für Einschätzungen und Praxisberichte!
Gruß

[Asgothian]

@Dieter_P sagte:

Hallo zusammen,

ich habe mir einen Shelly Flood Gen4 zugelegt und betreibe ioBroker mit Shelly- und Zigbee-Adapter. Der Sensor soll sicherheitskritisch laufen (zuverlässige, zeitnahe Alarm-Zustellung) bei möglichst langer Batterielaufzeit.

Vorab, damit klar ist, was ich schon geprüft habe:

• Im Shelly-Adapter ist der Flood Gen4 als shellyfloodg4 gelistet (WLAN/MQTT, ab v10.3.0).
• Gen4-Zigbee-Berichte hier im Forum drehen sich bisher v.a. um Schaltaktoren (1PM); teils war die ZHC_latest-Version nötig, teils fehlten einzelne States.
• Im Zigbee-Modus nutzt der Gen4 kein paralleles WLAN (also keine Shelly-Cloud/Matter darüber).

Meine Fragen:

1. Shelly-Adapter (WLAN/MQTT): Betreibt jemand den Flood Gen4 produktiv darüber? Welche Datenpunkte kommen an (Flood/Dry-Wet, Batterie, ggf. Temperatur, Tamper)? Wird der Alarm trotz Deep-Sleep zuverlässig und zeitnah zugestellt?

Dazu kann ich nichts sagen - ich hab das Gerät nicht.

2. Zigbee-Adapter: Läuft der Flood Gen4 speziell über Zigbee? Ist die Definition schon in der regulären Adapter-/ZHC-Version enthalten oder nur in ZHC_latest? Welcher State-Umfang (Dry/Wet, Battery, Tamper, Trouble)? Und stört das bekannte "unavailable" im Sleep die Alarm-Trigger in der Praxis?

Der Flood Gen4 läuft über Zigbee. Was mit ZHC oder ZHC-Latest gemeint ist weiss ich nicht, daher kann ich das nicht beantworten. Im ioBroker.Zigbee Adapter wird er wahrscheinlich nur in der latest version (3.5.4) unterstützt sein. Im Moment sieht es aber gut aus das diese bald ins Stable kommt.

Die vorhandenen States findest du hier: https://www.zigbee2mqtt.io/devices/S4SN-0071A.html

3. Empfehlung: Für einen sicherheitskritischen Wassersensor – eher WLAN/MQTT über den Shelly-Adapter oder Zigbee? Gibt es belastbare Erfahrungswerte zur Batterielaufzeit im jeweiligen Modus?

Nicht bei mir, ich hab den Sensor nicht. Ich gehe aber fest davon aus das die Batterielaufzeit im Zigbee Modus deutlich besser ist als im WLan Modus. Ich hab andere Sensoren im Einsatz bei denen die Batterieen seit 2 Jahren drin sind.

Danke vorab für Einschätzungen und Praxisberichte!
Gruß

[Dieter_P]

Danke

@Asgothian sagte:

Ich gehe aber fest davon aus das die Batterielaufzeit im Zigbee Modus deutlich besser ist als im WLan Modus. Ich hab andere Sensoren im Einsatz bei denen die Batterieen seit 2 Jahren drin sind.

So war auch meine Vermutung dass im Zigbeebetrieb ca zweistellige mA für wenige ms je Aufwachzyklus agieren, wohingegen Wlan auf 150-250mA für 1-2 Sekunden geschätzt wird. Ist halt ein Batteriebetriebenes Gerät und das ein guter Grund.

ABER wenn der ganze restliche Aufbau vielleicht noch so unsupported/wackelig ist, bringt mir das nicht viel darum frag ich.

Edit: Im aktuellen Zigbee stable Adapter v3.3.5 wird er schon mal erkannt: