Capability Request - Water Flow Rate

Would you be willing to share your DH? I would love to get my last device off of Smartthings and on to Hubitat. Thanks

1 Like

yeah let me clean up the code first. Just a note of caution on features - my DH does not log usage. You dont see any fancy graphs, etc. It's primarily used for point in time usage. I use it to measure high flow rates and long flow times.

1 Like

Sounds perfect for what I want, Thanks

try this: https://raw.githubusercontent.com/tman785/Fortrezz/master/devicetypes/jsconstantelos/my-fortrezz-flow-meter-interface.src/my-fortrezz-flow-meter-interface.groovy

I still need to work on it more, but for now, it does what it does. There is probably a race condition in there where you may get flow rates that are astronomical. They usually clear themselves out though.

I do have added in what I refer to as current flow. I keep track of the following values:

  • currentFlowAverage
  • currentFlowDuration
  • currentFlowHigh
  • currentFlowMeterStart
  • currentFlowRate
  • currentFlowStartTime

This allows me to easily use HE Rule Engine.

Let me know what you think.

Thanks, it seems to have even more attributes exposed than the original. You are right about the Rule Machine there is a lot that can be done. I will let you know if anything pops up. Does the DH report at a different rate when on battery as opposed to power? I ask because my power input is not working and I have to run on battery for now.
Thanks again great job!

+10 For this feature request.
I have also just integrated my water counter measurements (Global counter + Daily consumed Liters) into HE.
But I am also now stuck an non of the dashboards / selectors support this kind of devices. Using the EnergyMeter capability is a nice hack not very user friendly.

It would be great to have this supported OOTB.

1 Like

I havent tried moving my meter onto battery only, but you set the reporting interval in the DH. I go every 10 seconds, because, why not :slight_smile:

I am really surprised more folks aren't jumping on this kind of thing as a part of their overall system. To ignore water metering as a part of overall home/garden/small farm system management and control seems selling it short for both a) resource mgmt impact and b) catastrophe or leak mgmt.

Looking at "b" specifically it seem folks opt to ignore benefits of the meter indications and just opt for having water sensors deployed in critical locations. I get that, especially when installing a meter is prohibitive or daunting.

But the "not enough demand for the use case" catch phrase as applied to water metering stuff sells short the "if we had it people would employ it" potential.

There are a whole lot of folks on wells out there that have an awful lot of stuff they would automate if the perspective on these things went beyond the urban/suburban use case.

The industrial/agricultural/commercial solutions are there but they are a WHOLE lot more expensive than they need to be for the small scale user. This is where HE together with the up and coming affordably priced components could shine.

Case in point, you can get some great affordable pulse generating water meters now. I presume this is part of what is driving the original poster and others to start to want to put them into their overall topology.

I have a great deal of respect for the solutions folks like Profile - ogiewon - Hubitat have crafted to offer a generic address to the scope of pulse data applications. I'm just disappointed if it is the case that Hubitat folks don't see this as critical capability for integration. I guess I'm still in the group of new users that go, "Really?, there's 'no built-in' EASY BUTTON for that? So I gotta go roll up my hobbyist sleeves to make this work" .

With time, using the ancillary/community solutions might not bother me, but I guess I'm still old school.

3 Likes

This isn't the case. We do see the importance. There are a number of new capabilities we intend to add. We've been a tad busy with some other things, as you will see soon. This capability is on our list.

6 Likes

Yahooooo !

Thanks for the "just over the horizon" view B !

Should we start building the list of possible candidates?

Here's one that might be a willing partner for Hubitat given their similar size and desire to change the status quo. If they would only just offer more options in metal vs plastic,.

https://everydropmeters.com/

Looking at the website, I'm not seeing where these meters have any zigbee or z-wave options. They only have a 2 wire output on one model that outputs a frequency that would need to be translated by some other device. They are not Smart devices that could be connected to the hub without an intermediary device. That intermediary device is what would possibly make the compatibility list.

You rightly clarified the situation with Everydrop meters. They have been selling into irrigation controller integration channels.

I recently asked them about taking the next step and offering their own radio equipped counter. The answer I received suggested they saw the need for a remoted pulse counter (likely by wire). It might take a ZigBee competent partner to nudge them towards a solution ideal for HA systems like HE.

1 Like

If you have them contact me, I could put them in touch with an engineering firm that could do a customized Zigbee module for them, to make it work with Zigbee HA. Not for the faint of heart, they would have to really want to do this....

Thanks. They don't know me from Adam, but the lead for assistance was put in their court...we'll see if they contact you.

@bravenel
Any news an a new capability for pulse / rate counters?

I can tell you for sure that it won't be in the upcoming 2.2.4 release. We are planning capabilities additions for 2.2.5.

3 Likes

There are a few suggestions I'd like to submit concerning capabilities / attributes for control of Fans, Polling, Button events. Is there a preferred way for me to submit and explain the rationale / use case?

I just purchased several of the Fortrezz flow meters so looking forward to seeing this in 2.2.5.

Won't be in 2.2.5. Later.