Shelly Flood sensor and Home Assistant

It's a hyper-expensive for what it is, small flood sensor device witch is actually:

• a binary sensor for floods, based on three separated conductive pin measuring the conductivity of the material the are in contact with, I guess, meaning you can't put the sensor on a conductive surface;
• a temperature sensor;
• a battery level sensor (lithium 3V battery type CR123A aka 17335).

All packaged in a wifi IoT platform featuring:

• a locally served WebUI;
• a CoIoT multicast/unicast service;
• an MQTT service;
• an optional cloud service from the vendor.

Basically you can use it all locally, inserting the battery¹ and connecting to the built-in AP broadcasting a shellyflood-xxxx wide open wifi, assigning IPs in the range 192.168.33.x where the built-in WebUI is served as http://192.168.33.1/ where you can configure a local WLAN to properly connect the device.

As a small advise: to consume less energy the device go in sleep mode in a very short timeframe, so all settings must be applied quickly or you need to wake up the device with a single quick push on the unique button aside the battery (long press do reset to factory defaults).

As usual regular fw updates are needed.

HA have a Shelly integration that support the Shelly Flood BUT not out-of-the box, you need to change in the Flood WebUI under

Internet & Security => ADVANCED - DEVELOPER SETTINGS

the CoIoT protocol setup from multicast to your HA IP:5683 (witch of course should be reachable by the Shelly, have the 5683 UDP open etc), save and reboot quickly. At that point HA will see not only the device in it's short "wake time" but also will keep getting "on alert" and spot upgrade from the otherwise silent/disconnected device. Temperature sensor tend to be updated on a certain temp threshold change (configurable in the device WebUI) or every some hours, battery sensors tend to transmit even rarely.

It's also possible to connect via MQTT with a personal broker (Mosquitto in my case, no special setup needed) that get updates from the Flood MQTT service (to be configured in the same page of CoIoT setup) and HA get from it with the MQTT manual integration, BUT for me this approach fails, HA do connect and works when the device is in the short "wake period" once configure/once you quickly press the button one time but do not get updates thereafter, even with broker persistence enabled… So for now I'm using the CoIoT/Shelly HA integration only.

Anyway, this suffice to get three entities, alert, temperature and battery level. Than it's time to configure HA to use the alert to do something, like close a motorised water valve automatically, pushing sound/other notifications to all humans and so on.

As usual with modern software and IoT simple things are complicated. First we need an "automation", an annoying wall of YAML, typically stored in ~/.homeassistant/automations.yaml witch is generally imported from ~/.homeassistant/configuration.yaml like automation: !include automations.yaml that trigger something, like a notification, when then flood sensor switch from dry to wet. Unfortunately there is no simple "notification" for such usage. Android have it's own kind of notifications, iOS it's own, HA WebUI it's own and so on. Any "device" (mobile apps and desktop WebUIs instances) need to be listed "individually"… Also to get notifications on mobile we need "persistent connection" active under the mobile app "Settings" view, under "Mobile App", under the "Servers" settings pane, and of course there is no damn search to quickly locate a specif parameter, no programmatically feasible way to set such options, no way to push certain settings to a set of mobile apps and so on. Just take a look at Notifications Basic docs to get an idea and the many posts in HA community "I can't get notifications"…

As a simple example for a single Android device, to get an unsatisfactory sound notification, that repeat a bit randomly in case of flood, once all in-app settings are correct:

- id: '...'
  alias: "A name for this automation, like 'Flood alert automation'"
  description: "something like the connected sensor location"
  trigger:
  - platform: state
    entity_id:
    - binary_sensor.shellyflood_..._flood
    from: 'off'
    to: 'on'
    for:
      hours: 0
      minutes: 0
      seconds: 1
  condition: []
  action:
  - service: notify.mobile_app_...
    data:
      title: "Water leak detected!"
      message: "From Shelly Flood in the basement"
      data:
        ttl: 0
        priority: high
  mode: single

While Shelly compared to many IoT devices is probably the most stable and friendly to their customers (not imposing anything cloud, not making local usages second class and so on) well… The sensor itself is damn expensive, for what it is, IMVHO a sound price should be not much more than 20€, and the HA setup as most HA setup is a pain. Oh, BTW HA itself is the less crappy IoT manager for homes and alike. Others are even worse…

Long story short IoT it's designed in modern time, so it sucks. But sometimes we do not have other sound option so there is not much we can do to get something done. Automatically crafting a simple passive device like a normally open switch that directly trigger a valve to close water intake might be far more reliable but for what we have in the market, demand no less work to be done correctly.

This article from The Verge well describe the past state of things compared to the actual one, a lesson that we should learn very well.