Sometime in the not too distant future, I need to bring in a plumber to do some work replacing the shutoff valves on either side of my water meter (the handles have corroded off ). Since getting usage data out of the utility water meter (I’ve googled the model a bit and it seems it uses a proprietary protocol that hasn’t been fully reverse engineered) isn’t an option I was wondering if anyone knew of an additional meter that I could have the plumber add to the line so that I could track my own water usage. I don’t use a lot of water so this is mostly for curiosity’s sake.
I’m curious too. Water is my most expensive bill (stupid desert) so my interest is more than curiosity.
I bought a 1" meter on eBay that pulses once for every gallon and connected that to a esp8266.
I have a water meter which does not have any kind of pulse/communication output, but I have been successfully using cheap D-Link network camera (~40e) and dialEye (http://olammi.iki.fi/sw/dialEye/) to get water meter consumption value. I fetch consumption value every 30s via exec binding and use openHAB rules to calculate instantaneous and daily consumption values.
I’ve read about that solution before… would appreciate some more info since I really wanna implement this to my solution also… but I’m to n00b to see how I get the data from the app and into OH - maybe some MQTT?
Yep, I use MQTT and ESP Easy on a esp8266.
I’ve been using a few of the compact ones with pulse output for years and they work great!
I would prefer to use the already installed from the water supplier - then do some readings with either dialEye or OpenCV to read the actual status…
Trying to see if it’s possible with OpenCV here:
I’m not familiar with OpenCV, but at least dialEye was pretty easy to configure. Just follow howto guide. dialEye zip also contains sample water meter image and configuration which can be used to test dialEye functionality.
Okay… Also how to get the data over to a MQTT broker?
Do you know if DialEye also can read digits - instead of the rotating wheel?
Is there specific reason why you want to use MQTT? As I said, I have been using exec binding to fetch water meter value directly to openHAB item. On my setup, exec binding runs every 30 sec.
No, dialEye support only rotating dials. I have a simple rule on openHAB which increases full cubic meters every time when current value is smaller than previous value (simplified). I also have another simple rule which can be used to initialise initial water meter value on openHAB (full cubic meters).
Perhaps his OH server isn’t in his utility room where the meter is located. In some places such meters are even located outside or buried in a hole in the alley. There are lots of reasons why one might want to run dialEye on a different machine from their OH server.
You could use OpenCV for that perhaps.
Maybe I need to run the dial eye on another instance, since my water meter is in the ground out near the main road…
My water meter only have one rotating disc, then I’m a bit worried for the accuracy…
Yes exactly - it should be pretty easy to do some OCR with that solution… just need the interface between OH… but as you said it might be done in python, same language as OpenCV…
I don’t have OH and meter in the same room either. Network camera is just placed top of water meter. I have D-Link WLAN camera. DialEye just need image file or url where to fetch image.
Depends accuracy of the rotating disc. Is it decilitres, litres, or hundred litres (or some other non metric units)? If it’s decilitres or even litres, then accuracy most probably is not enough as you should read state very fast, other wise you will miss easily some consumption.
If you are able get OpenCV work via python, I’m definitely interest in as well. Then I could mix OpenCV and dialEye together and get exact values without any OH rules.
Mine rotation disc is 1 liter Per revolution, that’s why afraid of the accuracy- then I’ll try and do some more about the OpenCV integration
This reply may be better suited as its own post, but I’ll leave that to a moderator…
I have recently been diving head-first into openHAB, and trying to collect data from as many sources as possible in my house. I would really like to get info from my water supply and implement controls/automation, so I began building a device for this.
I also run a hackerspace, so myself and my compatriots have taken to the task of trying to get water supply data into openHAB and implementing control (i.e. leak detection shut off), rules, automation, etc.
Water flow rate
Flow analysis (usage data, learning patterns, identifying leak events)
Shut-off solenoid valve
Plug-and-Play communication with openHAB
We found there are no off-the-shelf devices that provide everything we are looking for. There are a few similar devices on the market, but they are mostly designed for industrial applications or very specific tasks.
We are building this device with openHAB in mind. It is still in development, and we are working out several important design features, including the communication type.
Here are a couple photos of our 1st prototype device:
So far we have a flow meter with temperature sensor, solenoid to shut off flow. On either end is a “shark-bite” style fitting to help with installation and removal. A manual shut-off valve should be installed immediately upstream of this device.
Some issues we are still working out:
Connection/Communication hardware (I am a fan of hard-wiring everything, but I understand this isn’t practical for everyone)
Whether to use ‘Normally Open’ vs. ‘Normally Closed’ solenoid (power usage, power failure, etc.)
How device affects flow & pressure (downstream of device), and minimizing this.
We have also decided to add another component to the water line in order to power our device:
Using this micro hydroelectric generator, a battery, and a charging circuit, we believe we can make this whole device a self-contained unit.
Also, if we can get a working device and enough interest, we hope to order components in bulk and offer kits to others at a price that is less than what they could build individually. We plan to do this with many other custom “openHAB ready” hardware as well.
Any input, thoughts, criticisms are welcome!
Wow dijit, that’s impressive! I like it a lot. My only thoughts are the following:
I would certainly make the turbine (or “micro hydroelectric generator”) an option, particularly if it is the only plastic part in the mix.
Also … I don’t think a 'normally ’ is required, in fact, I would even discourage it. In other words … in the event of a complete power loss … just leave the valve as it is. That should be SO infrequent as to be a non issue … and if anyone DOES need even more reserve power than what a small led acid battery would provide … you can always buy a deep cycle marine battery that would run the thing for a month.
I encourage you to continue … this looks like an awesome project and will easily provide functionality similar to this floLogic solution and yet provide more data to the user & probably at a greatly reduced cost. I look forward to reading about your progress!
Thanks for the feedback @Ctrl-G
I agree, and we are still trying to find a brass version of the turbine/generator (though it may likely have plastic internals).
So, here is the debate within our group:
We have a solenoid that is open when not powered (“fail-open”), and closes when triggered, i.e. when voltage is applied.During normal operation I think this makes the most sense for most applications.
However, in the event of a leak (that we want to stop with this device), it would be possible for the leak to cause a power loss (circuit breakers trip, wiring is shorted, etc.). If the device were to lose power during this critical event, it would “fail-open”.
So here is the worst case scenario:
There is a leak.
OpenHAB rules trigger the valve to be closed to stop the leak, and also notify us of the leak.
Unfortunately, the leak was already enough to cause a breaker to then trip, circuit to short and fail, etc.
Our water device loses power (either because it was powered directly or the battery is exhausted)
When the water device loses power, it opens the valve (fail-open)
The leak continues, gets way worse, and a very angry person is cursing this device, and us
For my house, I am not on municipal water. If I lose mains power to the whole house, I won’t have any water to worry about because the water pump will stop. So for me, a fail open is fine.
On the flip side of this debate: we have a “fail-closed” solenoid which would stop water flow if power is lost to the device. This does not make sense, because for normal operation we would have to supply constant voltage for the valve to be open and water to flow. Any interruption in power to the device would cut the house water supply, which would get very annoying very quickly.
Hopefully our device and system will work fast and reliably enough to prevent any of this “what if” scenario, but it is something to consider. Also, the turbine/generator obviously only works when the water is flowing, so we need to test this setup quite a bit to make sure this is sufficient to keep a battery charged (assuming we make the device self-contained).
Lots to think about and test.
One more thing (sorry, my posts are always too long and full of parentheses). I had not yet come across the “floLogic” system in my research. I about fell out of my chair when I saw the purchase price! $1600?!
This is one of the many reasons I began getting into open source hardware and software, but I’ll stop my rant on markup prices and corporate profits right there.
Thanks again for the feedback, keep it coming! Its good to have outside opinions and thought processes. I will post updates in a separate post.
I have been following this topic with interest. Maybe a bistable solenoid might be interesting to use for this application. It only requires some energy to open it or to close it, and will remain in position afterwards.
In the event of a power loss you would only need a small amount of energy to close the valve.
I have used these valves long ago to create urinal control systems, operating on a single 9V cell.
Just my 2 cents