Hydrific Droplet

Yeah, I see it needs bluetooth. The VPN suggestion was wrong – it doesn’t seem like the app cares if it’s on the LAN or not.

It’s curious why it needs bluetooth once linked to the app. I can understand it needing bluetooth to initially connect to wifi, but I would have thought once the Droplet is connected to the Droplet cloud server it could have provided the pairing code remotely. But, maybe that’s all handled locally on the device. I suppose that’s good news.

Oddly, yesterday I was looking at my BLE proxies and just happen to notice the Droplet announcing itself (one of my few devices that provides a name) and it was on the BLE proxy that is the farthest from the Droplet, by quite some distance.

1 Like

I have added a Sena UD100 Bluetooth module to my HA server, but have not yet delved into much with it. I have noticed it picks up a LOT of BT devices, and this is while in a house without many neighbors. Hard to know what’s what given just hex addresses. But those are questions for another thread. I’ll look for the Droplet when I start using more Bluetooth, thanks for the info.

I suspect it’s a security thing. As in, you can’t pair it unless you have both the account and close proximity. Which seems reasonable.

I’ve not yet done much with MQTT on the HA server. Supposedly the Droplet can be integrated through either direct or through MQTT. I’ve not read anything that clarifies why I should choose one versus the other.

My main interest for having the Droplet integrated with HA is water damage prevention. As in, if leak sensors aren’t already warning of leaks, then it’d be nice to have some kind of ‘away mode’ automation set up using the Droplet to find out based on unexpected consumption while the place is unoccupied.

I either read or asked Droplet support but seems like using the native integration is the way to go.

I’ve had friends with massive damage from (small, like an ice maker) water leaks, so I’m probably biased away from the true risk. I’m tempted to just shut off the water when nobody is home, but would have to factor in things like the dishwasher or laundry running while also away. I tend to turn the water off when we know we will be away for a day.

What I do now is if nobody is home and there’s water flow and the dishwasher and washer are not drawing any power then send me an alert. It’s not very advanced. I just don’t want some AI turning my water off in the middle of a shower.

Next house I’m putting all the plumbing outside the exterior walls. :wink:

That and coin-operated faucets.

1 Like

Right, my main goal is keep detected leaks from making things worse.

Home/away for the vacation house can’t really turn off the water entirely due to the filtration system (high iron content) needing to purge periodically. Which I don’t really know enough about to make choices about automating it. I do plan on installing some power-monitoring switches to keep tabs on the system’s power use, as that might help get a better picture of water consumption ‘legitimacy’. That combined with Droplet usage.

I’m basically looking at having a higher level of vigilance during an ‘away mode’ situation.

Are there message threads here that get into more robust home/away mode scenarios? I don’t want to hijack this one.

Did you try with VPN?

I got one of these now and will connect it to HA. I am already using MQTT so I could connect droplet that way or I could use the integration. So looking for your experience.

Are the data sets / update rates the same for both MQTT and the integration?

Any other considerations?

1 Like

Were any of you who have the device able to do some testing of the consumption accuracy? @HAssister mentioned filling buckets at different flow rates. Did you get a chance to do that?

Another thing I’m curious about is whether it can detect slow leaks, like a dripping faucet.

I have not installed the unit yet, but still plan on doing the accuracy tests. I will post an update once ready.

I have to say I am a bit disappointed and would definitely not have gotten the droplet had I realized I would have to create an account AND put it on a WiFi network with internet access. I just put in a fake address. I then connected it to HomeAssistant and then went into Home Info > WiFi and switched it to my IoT network. It gave me an error, but I ignored it and it is properly reporting the data to HomeAssistant.

There is also another issue. They did not put in the proper resistor so that it will work with USB-C. It needs to indicate it expects power to be delivered to it, and that it is not sending power (USB-C supports bidirectional power flow). So you need to plug it in to a USB-A port despite the device having a USB-C port.

My experience is it does not.

I have mine plugged in to a UBS-C charger with a USB-C to USB-C cable and it works fine.

It didn’t work for me and I tried 3 different chargers. It wasn’t the cable because I’m using the same cable with an A to C adapter and now it works.

I’m glad it worked properly for you. I’m interested in hearing if anyone else has had the problem.

Some USB-C chargers will always have 5V on the USB-C port, but if they follow spec then there should not be no voltage on the port unless there is a certain amount of resistance between two pins.

Maybe your charger is not following the spec. Many don’t because a lot of devices won’t power up because the resistor is often omitted. This is really annoying and inconvenient. Many devices that ship with a USB-A to USB-C cable fall into this category.

I just tested again. I weighed out 1 gallon of water and marked it on a container. I have a pretty accurate scale that measures up to a 1kg, so repeated for about 3786g for a gallon.

I then filled 5 of them and Droplet was off by about a tenth of a gallon in five gallons. My house water meter was off by about two tenths. So, it seems accurate for 5 gallons. I’m starting to wonder more about the water company’s meter…

Of course, 5 gallons isn’t a month’s test, but we have outdoor hoses that are between the water meter and the Droplet.

No idea if the Droplet (cloud) AI would detect that. The app has notificed me of issues before.

It seem very sensitive to water flow. I frankly think you could record the reading when, say, the number of people home goes to zero and then, if it’s been a while, check again when people come back home and report if it seems different and then investigate.

We have a closed system (e.g. pressure regulator and back flow preventer) and have a hot water expansion tank. Just the movement of water from the hot water expanding during heating seems to result in some change. Might zero out, but for a faucet drip have to expect some false positives,

Just to test, I added a rule to my router to block Droplet from getting through the WAN. The App will note that Droplet is off line, but otherwise seems fine. But that was after installing it, of course.

1 Like

For the ones outside US that want to use Droplet, I’ll share my experience.

Got the Droplet 3 days ago, I’m in Italy. Shipping + customs duties + taxes brought the cost to $330. For that price Sonic by Watergate might be a better alternative if you also need a shutdown valve. I liked the fact that the Droplet doesn’t require touching the pipes and the fact I could remove it easily. My use case was primarly measurement, so I decided to get one.

Installed the apk on my mobile with VPN on, and registered with a US based address. Then paired the device and everything was fine. I think the VPN is not necessary, the trick is using a US address, but it doesn’t hurt turning VPN on while registering.

I had some trouble configuring the device, it wouldn’t detect the pipe initially. So I moved it to another section of the pipe and I also made sure no water was flowing at all. It finally detected the pipe and measures were finally flowing to HA. I think the issue was the fact that water was flowing during the detection process, I read in a troubleshooting article that no water has to flow during the initial setup.

I tested both the MQTT integration and HA integration. Using MQTT I noticed the sensors had defaulted to my local units (L and L/min) while using the HA integration, the flow sensor was in gal and gal/min. I opted for the HA integration and switched the units on the two sensors to L and L/min.

I’m now slowly tagging all my fixtures, etc. and it seems to be working very well.

I don’t really like the limited number of entities the official integration is providing, I expected at least a total water consumption cumulative sensor, but it seems the developer @sarahseidman had those initially but later removed them in the PR process of the integration.

I asked Sarah if she would be open to adding back the cumulative sensors, and in case the answer is negative, I’ll probably develop a custom integration.

Hope this helps people outside US that want to use Droplet. :slight_smile:

2 Likes

Not sure you need an integration. My Droplet was reporting very frequent small flows (both positive and negative) so I threw this together to sum and record less frequently.

recorder:
  exclude:
    entities:
      - sensor.droplet_total_excluded
      - sensor.droplet_e67c_water

template:

  # Keep a total of all the Droplet websocket updates, but exclude from recorder
  # And reset on an event
  - triggers:
      - trigger: state
        entity_id: sensor.droplet_e67c_water
        not_to:
            - unavailable
            - unknown
    actions:
      - variables:
          cur_sum: "{{ trigger.to_state.state|float(0) + states('sensor.droplet_total_excluded')|float(0) }}"
          new_value: "{{ 0.0 if cur_sum > 0.05 else cur_sum }}"

      - if:
          - condition: template
            value_template: "{{ new_value == 0.0 }}"
        then:
          - event: droplet_update_value
            event_data:
              sum: "{{ cur_sum }}"

    sensor:
      - name: Droplet Total Excluded
        unique_id: droplet_total_excluded
        unit_of_measurement: "gal"
        device_class: water
        state_class: total
        state: "{{ new_value }}"


  - triggers:
      - trigger: event
        event_type: droplet_update_value
    sensor:
      - name: Total House Gallons
        unique_id: droplet_total_house_gallons
        unit_of_measurement: "gal"
        device_class: water
        state_class: total
        state: "{{ (this.state|float(0) + trigger.event.data.sum|float(0))|round(3) }}"
1 Like

The Droplet device sends point-to-point delta values (volume since last push) that can also be negative. Here’s an official explanation from the vendor’s FAQ:

Q: Why does Droplet’s volume sensor sometimes show negative values?

A: The volume reported by Droplet over local API is point-to-point, meaning that each new value represents the difference in volume recorded since this data was last sent. Even when you’re not using appliances in your home, there can still be activity in your pipes. Droplet tries to be very accurate and is sensitive to small flows, which can include water sloshing back and forth, or slight movement as a result of pressure differences. Small negative values are to be expected, and are reported so that cumulative statistics reported in Home Assistant (or other consumers of the API) can be fully accurate.

Is there a specific reason why you created that vs using utility_meter? utility_meter works even if the source entity is excluded from recorder: it subscribes to state_changed on the event bus and calculates deltas on the fly. It doesn’t query recorder history. Statistics sensors instead won’t work if the source entity is excluded from recorder, they get historical data from recorder.

For my personal needs, I came up with a package, because I wanted more cumulative and statistics sensors. But I think I will create a custom integration that will provide all this to make it easier for the user, it will be configurable (units, tariff, etc.), it won’t require the creation of the point-to-point sensor nor manually creating other sensors/entities.

# Mains Water Meter Package
# Place in /config/packages/mains_water.yaml

input_number:
  mains_water_tariff:
    name: "Mains Water Tariff"
    icon: mdi:cash
    unit_of_measurement: "EUR/m³"  # ← Change to your currency/unit
    min: 0
    max: 100
    step: 0.01
    initial: 2.94

# =============================================================================
# UTILITY METERS
# Track consumption per calendar period (resets at hour/midnight/week/month/year)
# Change the source sensor on the first entry below (&water_source)
# All other entries will automatically use the same sensor (*water_source)
#
# Entity IDs will be: sensor.mains_water_hourly, sensor.mains_water_daily, etc.
# =============================================================================

utility_meter:
  mains_water_hourly:
    source: &water_source sensor.droplet_water  # ← CHANGE THIS TO YOUR WATER SENSOR
    name: "Mains Water Hourly"
    unique_id: mains_water_um_hourly
    cycle: hourly
    always_available: true

  mains_water_daily:
    source: *water_source
    name: "Mains Water Daily"
    unique_id: mains_water_um_daily
    cycle: daily
    always_available: true

  mains_water_weekly:
    source: *water_source
    name: "Mains Water Weekly"
    unique_id: mains_water_um_weekly
    cycle: weekly
    always_available: true

  mains_water_monthly:
    source: *water_source
    name: "Mains Water Monthly"
    unique_id: mains_water_um_monthly
    cycle: monthly
    always_available: true

  mains_water_yearly:
    source: *water_source
    name: "Mains Water Yearly"
    unique_id: mains_water_um_yearly
    cycle: yearly
    always_available: true

# =============================================================================
# STATISTICS SENSORS
# Rolling window analytics for trends, patterns, and anomaly detection
#
# Change the flow rate sensor on the first flow entry (&flow_source)
# Utility meter sources are fixed (they reference entities created above)
# =============================================================================

sensor:
  # ---------------------------------------------------------------------------
  # DAILY CONSUMPTION STATISTICS
  # Source: utility meter that resets at midnight
  # ---------------------------------------------------------------------------

  # Average daily consumption over the past week
  # Use: "What's my typical daily usage?" - baseline for comparison
  # Alert idea: notify if today's usage exceeds 150% of this value
  - platform: statistics
    name: "Mains Water Avg Daily (7d)"
    unique_id: mains_water_stats_avg_daily_7d
    entity_id: &daily_source sensor.mains_water_daily
    state_characteristic: mean
    max_age: &age_7d
      days: 7

  # Average daily consumption over the past month
  # Use: long-term baseline, seasonal comparison, billing estimate
  # More stable than 7d average, smooths out weekday/weekend differences
  - platform: statistics
    name: "Mains Water Avg Daily (30d)"
    unique_id: mains_water_stats_avg_daily_30d
    entity_id: *daily_source
    state_characteristic: mean
    max_age: &age_30d
      days: 30

  # Highest single-day consumption in the past month
  # Use: identify high-usage events (guests, garden watering, pool fill)
  # Helps set realistic alert thresholds
  - platform: statistics
    name: "Mains Water Peak Daily (30d)"
    unique_id: mains_water_stats_peak_daily_30d
    entity_id: *daily_source
    state_characteristic: value_max
    max_age: *age_30d

  # ---------------------------------------------------------------------------
  # HOURLY CONSUMPTION STATISTICS
  # Source: utility meter that resets every hour
  # ---------------------------------------------------------------------------

  # Average hourly consumption over the past 24 hours
  # Use: "How much am I using per hour on average?"
  # Useful for understanding daily patterns
  - platform: statistics
    name: "Mains Water Avg Hourly (24h)"
    unique_id: mains_water_stats_avg_hourly_24h
    entity_id: &hourly_source sensor.mains_water_hourly
    state_characteristic: mean
    max_age: &age_24h
      hours: 24

  # Highest single-hour consumption today
  # Use: identify peak usage hours (morning shower, dinner prep)
  # Helps understand when water demand is highest
  - platform: statistics
    name: "Mains Water Peak Hourly (24h)"
    unique_id: mains_water_stats_peak_hourly_24h
    entity_id: *hourly_source
    state_characteristic: value_max
    max_age: *age_24h

  # Highest single-hour consumption this week
  # Use: detect unusual high-consumption events
  # Alert idea: notify if current hour exceeds this by large margin
  - platform: statistics
    name: "Mains Water Peak Hourly (7d)"
    unique_id: mains_water_stats_peak_hourly_7d
    entity_id: *hourly_source
    state_characteristic: value_max
    max_age: *age_7d

  # ---------------------------------------------------------------------------
  # FLOW RATE STATISTICS
  # Source: instantaneous flow rate sensor (L/min)
  # Unlike consumption, this measures how fast water is flowing RIGHT NOW
  # ---------------------------------------------------------------------------

  # Highest flow rate observed in the past 24 hours
  # Use: identify max simultaneous demand (multiple fixtures at once)
  # Helps with pipe sizing and pressure considerations
  - platform: statistics
    name: "Mains Water Peak Flow (24h)"
    unique_id: mains_water_stats_peak_flow_24h
    entity_id: &flow_source sensor.droplet_flow_rate  # ← CHANGE THIS TO YOUR FLOW SENSOR
    state_characteristic: value_max
    max_age: *age_24h

  # Highest flow rate observed in the past week
  # Use: understand maximum demand patterns over longer period
  # Useful for plumbing capacity planning
  - platform: statistics
    name: "Mains Water Peak Flow (7d)"
    unique_id: mains_water_stats_peak_flow_7d
    entity_id: *flow_source
    state_characteristic: value_max
    max_age: *age_7d

  # Average flow rate over the past hour
  # Use: smoothed view of recent activity
  # High value = sustained water use; low = intermittent or no use
  - platform: statistics
    name: "Mains Water Avg Flow (1h)"
    unique_id: mains_water_stats_avg_flow_1h
    entity_id: *flow_source
    state_characteristic: mean
    max_age: &age_1h
      hours: 1

  # Minimum flow rate observed in the past 24 hours
  # Use: LEAK DETECTION - if minimum > 0, water is always flowing
  # Alert idea: if min_flow > 0 for extended period (especially at night),
  # there may be a leak (dripping tap, running toilet, pipe leak)
  - platform: statistics
    name: "Mains Water Min Flow (24h)"
    unique_id: mains_water_stats_min_flow_24h
    entity_id: *flow_source
    state_characteristic: value_min
    max_age: *age_24h

# =============================================================================
# COST SENSORS
# =============================================================================
# Cost calculation assumes:
#   - Source sensor reports in LITERS (L)
#   - Tariff is per CUBIC METER (m³)
#   - Divisor is 1000 (1 m³ = 1000 L)
#
# Adjust divisor for your local billing unit:
#   | Tariff Unit | Divisor |
#   |-------------|---------|
#   | /m³         | 1000    |
#   | /gal        | 3.78541 |
#   | /CCF        | 2831.68 |
#
# Currency is determined by Home Assistant system settings:
#   Settings → System → General → Currency
# =============================================================================

template:
  - sensor:
      # Today's water cost so far
      # Use: daily spending awareness, budget tracking
      # Resets at midnight with the daily utility meter
      - name: "Mains Water Daily Cost"
        unique_id: mains_water_cost_daily
        device_class: monetary
        state_class: total
        icon: mdi:cash
        state: "{{ ((states('sensor.mains_water_daily') | float(0)) / 1000 * (states('input_number.mains_water_tariff') | float(0))) | round(2) }}"
        availability: "{{ states('sensor.mains_water_daily') not in ['unknown', 'unavailable'] }}"

      # This week's water cost so far
      # Use: weekly budget tracking, week-over-week comparison
      # Resets on Monday at midnight
      - name: "Mains Water Weekly Cost"
        unique_id: mains_water_cost_weekly
        device_class: monetary
        state_class: total
        icon: mdi:cash
        state: "{{ ((states('sensor.mains_water_weekly') | float(0)) / 1000 * (states('input_number.mains_water_tariff') | float(0))) | round(2) }}"
        availability: "{{ states('sensor.mains_water_weekly') not in ['unknown', 'unavailable'] }}"

      # This month's water cost so far
      # Use: billing estimate, compare to utility bill, monthly budget
      # Resets on the 1st of each month at midnight
      - name: "Mains Water Monthly Cost"
        unique_id: mains_water_cost_monthly
        device_class: monetary
        state_class: total
        icon: mdi:cash
        state: "{{ ((states('sensor.mains_water_monthly') | float(0)) / 1000 * (states('input_number.mains_water_tariff') | float(0))) | round(2) }}"
        availability: "{{ states('sensor.mains_water_monthly') not in ['unknown', 'unavailable'] }}"

      # This year's water cost so far
      # Use: annual spending overview, year-over-year comparison
      # Resets on January 1st at midnight
      - name: "Mains Water Yearly Cost"
        unique_id: mains_water_cost_yearly
        device_class: monetary
        state_class: total
        icon: mdi:cash
        state: "{{ ((states('sensor.mains_water_yearly') | float(0)) / 1000 * (states('input_number.mains_water_tariff') | float(0))) | round(2) }}"
        availability: "{{ states('sensor.mains_water_yearly') not in ['unknown', 'unavailable'] }}"

Good question. I don’t quite remember now.

I have my original package file around and it includes both utility_meter and even a platform: integration that someone has suggested but (as Droplet support said) it was much more accurate to sum up the reported volumes.

I’m not home now where I can test, but is it that the utility_meter updates its state at the same frequency? My Droplet was updating every 20 to 30 seconds when idle and every 3 to 4 seconds when water was running. I don’t need to record that small of state changes.

I also decided I didn’t need daily and monthly totals – the daily/monthly “change” graphs are fine for my use.

➜  packages tail -26 droplet.yaml.save
#-------------- Droplet -------------------

utility_meter:
  house_water_usage_total:
    unique_id: house_water_usage_total
    source: sensor.droplet_e67c_water
    net_consumption: true
    delta_values: true 
    always_available: true

  house_water_usage_month:
    unique_id: house_water_usage_month
    source: sensor.droplet_e67c_water
    net_consumption: true
    delta_values: true 
    always_available: true
    cycle: monthly

  house_water_usage_daily:
    unique_id: house_water_usage_daily
    source: sensor.droplet_e67c_water
    net_consumption: true
    delta_values: true 
    always_available: true
    cycle: daily

By the way, I’m (also?) a big fan of using packages. I really like being able to group config for a specific feature (e.g. security, irrigation, hvac) together.

integration with the flow meter sensor didn’t seem like a precise measure because it has an irregular update frequency. much better cumulating deltas with utility meter.

but your code actually let me realize these two config options are fit for this specific case:

    net_consumption: true
    delta_values: true

the cumulation worked also without them because of last_reset changes, indicating it was an increment to add, but it’s better if I configure utility meter to appropriately “describe” the source sensor.

I’ll add them immediately to all utility meter sensors, and I’ll also add a lifetime cumulative sensor using a trigger sensor. Thanks for all the ideas, that’s why I love the HA community: quite a few clever people in here. :slight_smile:

From what I read, utility meter subscribes to every state change, so it updates as much as the source sensor does, but it makes sense in this case because the source sensor provides deltas that you need to track to accumulate. Frankly, for my setup (Proxmox on full SSD, HA Core in a LXC) I’m not concerned about those update rates. It could be a concern for people with RPi on SD cards though.

That’s one of my favourite HA features. You can cleanly organize things and I learned that only after a couple of years unfortunately. I hated those huge config files. :slight_smile:

Thanks for the exchange, it got me thinking, and I love it.

At the time I was on a Rpi 4 but with a SSD and my NFS backups were failing and I was wondering if the issue was related to the size of my backups. (I think it ended up being an mDNS issue.)

I’m on a VM with Proxmox now. No harm in keeping backups small, I guess. :wink:

It’s always (m)DNS. :nerd_face: