For consideration - add a liquid flow rate capability. It could be useful in assorted applications like monitoring water flow in ponds, aquariums, homebrew systems, etc. Unless I am missing it I did not see a good capability to use for this data, though of course, powerMeter can be co-oped to support it.
Device Selector
capability.flowMeter
Driver Definition
capability "FlowMeter"
Attributes
flow - NUMBER
Commands
You can always just create a custom attribute for your device. Any reason that won’t work for your needs?
That approach will work just fine, it just does not work as well when integrating data with other systems etc. That is the path I have taken for now. Appreciate the feedback.
Just curious. What exactly can’t you do using this technique?
What devices report flow rate?
Please say more about this. What does having a capability do that you can't otherwise do?
Well I may be off base here...I can get what I need working with custom attributes. I think of capabilities as a way to define a standard schema for a set of device data, for use within Hubitat, by other devices, integrated systems, etc. You coudl get rid of all the capabilities and just use attributes, but then we woudl have all different definitions of the attributes that are common accross different devices. Of course, a standard schema is only needed in cases where there are sufficient users of a given type of data, in this case liquid flow rate. That may be a huge edge case that's only relevant to me. In terms of devices, I am using this in a custom sensor based off of the Adafruit Liquid Flow Meter
We generally add capabilities based on there being sufficient users of a given type of device, which in turn depends on there being available devices that present the capability. A custom sensor is a variation of the weakness you point out with respect to "different definitions".
I have been thinking of getting the Zwave FortrezZ Flow meter.
Might port this if I do.
This could be a good one for ST_Anything Hubduino. Although not sure how much effort it would take for @ogiewon to add in as it's way outside my skillset 
It actually wouldn't take very long at all, since it is already supported in HubDuino/ST_Anything! 
Take a look at my PS_PulseCounter device which sends a value to Hubitat based on the polling interval declared. In between the polling updates, the device counts pulses. When it is time to send the data, it converts the total count to engineering units and then sends the data using the "Power Meter" Capability. The local count is then reset and the process starts again. Since tracking electricity usage is very similar to tracking water usage, this seemed to make the most sense to me versus going down the custom attribute path.
Here is the documentation for the device. The source code is in my Github Repo.
//******************************************************************************************
// File: PS_PulseCounter.h
// Authors: Dan G Ogorchock & Daniel J Ogorchock (Father and Son)
//
// Summary: PS_PulseCounter is a class which implements the SmartThings "Power Meter"-style device capability.
// It inherits from the st::PollingSensor class. The current version uses a digital input to measure the
// the number of counts between polling intervals. At the polling interval, the pulse count is converted
// to engineering units via a linear conversion (engUnits = slope x counts + offset).
//
//
// Create an instance of this class in your sketch's global variable section
// For Example: st::PS_PulseCounter sensor3(F("power1"), 60, 5, PIN_PULSE, FALLING, INPUT_PULLUP, 1.0, 0);
//
// st::PS_PulseCounter() constructor requires the following arguments
// - String &name - REQUIRED - the name of the object - must be in form of "power1", "power2", etc...
// - int interval - REQUIRED - the polling interval in seconds
// - int offset - REQUIRED - the polling interval offset in seconds - used to prevent all polling sensors from executing at the same time
// - byte pin - REQUIRED - the GPIO Pin to be used as an digital input (Hardware Interrupt)
// - byte inttype - REQUIRED - which type of Arduino interrupt to trigger the ISR (RISING, FALLING, CHANGE)
// - byte inputmode - REQUIRED - Mode of the digital input Pin (INPUT, INPUT_PULLUP)
// - float cnvslope - REQUIRED - Conversion to Engineering Units Slope
// - float cnvoffset - REQUIRED - Conversion to Engineering Units Offset
//
// This class supports receiving configuration data from the SmartThings cloud via the ST App. A user preference
// can be configured in your phone's ST App, and then the "Configure" tile will send the data for all sensors to
// the ST Shield. For PollingSensors, this data is handled in the beSMart() function.
//
// TODO: Determine a method to persist the ST Cloud's Polling Interval data
//
// Change History:
//
// Date Who What
// ---- --- ----
// 2015-03-31 Dan Ogorchock Original Creation
// 2018-03-03 Dan Ogorchock Improved code to make generic for all boards, not just Arduino MEGA
//
//
//******************************************************************************************
I am using the PowerMeter capability in my little custom driver as well...thats what led to this post to begin with. I am using a separate driver as I have a device with a temp probe and the flow meter with a little bit of custom python code pushing the samples over to Hubitat (and to InfluxDB)
I looked at those but its a pretty expensive option for my use case. I am not inline with home / higher pressure plumbing lines, so I used a cheap Pi Zero and the Adafruit Liquid Flow Meter to get this going as a < $50 solution. With the bonus that I can add other sensors in such as a temperature sensor. the whole thing is for monitoring a custom pond heater I have.
This has me taking another look at HubDuino Dan, with which I have yet to get my feet wet. I would love a low cost option that could do something similar to FLO (now FLO by Moen), which is just too far outside of my budget.
I currently have the Fortrezz Flow Meter. The port from the OEM Smartthings DH was easy. However, it was limited. There's another DH out there that provides more capabilities, like increasing the frequency of updates.
I've been modifying the stock DH, and bringing in parts of the user DH. What I can do now is report on:
I didnt see the need for holding the thresholds on the DH; the RE will take care of that.
I still have some refining and code cleanup to do.
Flow meters are used in the aquarium industry to know when piping gets clogged, pumps stop functioning, or piping needs replaced due to narrowing of the lines due to various buildup within the piping. I can see a use for this and would welcome the feature.
I am attempting to use the PS_PulseCounter device with my water meter that outputs one pulse per gallon. Do you have any suggestions on how get my result in HE to show this count and not a conversion to power? Is this possible? Not really caring at the moment that it's labeled "power", just like to get the count correct. If I can get the number of gallons to show 1:1 instead of a conversion, I'll start getting my feet wet on writing an app for the rest of what I want. Thanks for any help or suggestions.
As long as you leave the last two parameters of the device constructor as 1 and 0, there will be no conversion. You’ll get the count of the pulse counter per polling interval.
That's what I was thinking but so far doesn't see to be working that way. Let me check back through and make sure I haven't messed up something. Thanks for the fast response!
The conversion to engineering units is a simple linear equation of y=Mx+b. What sensor are you using? Is it powered? Or just dry contacts? The interrupt based counter is very sensitive. Trying to manually touch the GPIO pin will typically result in numerous counts being registered. Depending on the frequency of pulses you’re trying to measure, you might be able to add a low-pass filter circuit to avoid extraneous counts.
That may be my issue as I was testing it by trying to touch the connections. The sensor on the water meter is a dry contact that closes for a short period every one gallon. It can sometimes remain closed depending on where it is in the cycle when water stops flowing. My water pipe is 3/4" so it should not be able to pulse more than about 23 times per minute at maximum flow.
Download the Hubitat app
