Similar to capability.energyMeter, but for fluid volume rather than electricity. Attribute changed from energy to volume. I’ve made a smart device to monitor my residential water meter, and currently it hijacks powerMeter and energyMeter for reporting. Would be nice to have a true volume meter capability.
Naming this one is a challenge because folks tend to think of Volume as a synonym for Sound Pressure Level. Your name is accurate, but it’s nice to pick a name that avoids second guessing.
Perhaps… Capacity Meter?
Dang… I don’t think there’s a better name, really.
Great initiative!
I’d be interested in understading what you did to monitor the water usage! I’ve been thinking about implementing something but wasn’t quite sure where to start on this one. In particular, I want to monitor my sprinkler system usage since sometimes we get broken sprinkler heads which turns into a very expensive problem.
1 Like
Excellent point about the rather nasty name collision… Maybe go long: capability.fluidVolumeMeter with attribute:fluidVolume?
A possibility is to go generic with capability.quantityMeter and attribute:quantity, but I’m concerned with the generality/specificity trade off for capabilities. If you go too general (think about a hypothetical capability.measurement) then you lose much of the strength of the capability abstraction.
I think I prefer fluidVolumeMeter.
1 Like
Sorry just chime in, I’m not a coder but surely “Flow Meter” might be good?
1 Like
The meter in my house (and I think most houses) uses a magnetic coupling between the wet portion of the meter (impeller or something) and the dry portion (counter and AMR hardware). My gizmo is built around a digital compass module strapped to the side of the meter which can sense the magnet spinning inside. From there, it was just a matter of connecting it to a microcontroller/xbee radio combo and doing some counting/timing of the changing readings.
I think both are necessary for two different purposes. Flow meter would be for something like “Gallons per minute” but this capability is more about “total gallons”. In my application I want both.
1 Like
Hmmm, my meter isn’t inside my house. It is in a hole in my front yard basically. It had a mechanical counter on it previously, but they recently added a remote smart meter reader to it. I probably should go grab the model info on that and see what I can work out.
Was hoping you had solved the whole exposed/outdoor issue.
1 Like
Hopefully this will be implemented one day. It does seem that SmartThings have a lot of catching up to do with regards to defining capabilities! 
I’m currently writing generic handlers for zwave multisensor and meter reports, for use across all my device handlers. I’ve decided to map sensor/meter Types to attributes as follows:
physicalgraph.zwave.commands.sensormultilevelv4.SensorMultilevelReport:
- sensorType: 0x12 (Air Flow) => attribute: fluidFlow (units can be “m^3/h”, “cfm”)
- sensorType: 0x13 (Tank Capacity) => attribute: fluidVolume (units can be “m^3” or “gal”)
physicalgraph.zwave.commands.meterv3.MeterReport:
- meterType: 0x2 (Gas Meter) => attribute: fluidVolume (units can be “m^3”, “ft^3”, or “gal”)
- meterType: 0x3 (Water Meter) => attribute: fluidVolume (units can be “m^3”, “ft^3”)
Therefore, I’d cast my vote for generic capabilities of fluidVolumeMeter and fluidFlowMeter