Their app does this. CoRE would have to be capable of doing what their app does, which would require some time developing that functionality I’d imagine. Smart Lighting and SHM custom rules aren’t helpful at all either, which is why FortrezZ probably put their app together in the first place.
Is it possible for this thing to be off a factor of 10? I’m using your DTH @johnconstantelo.
I tested by running the shower, and it shows a maximum of 0.2 gpm. Pretty sure the shower is restricted to 1.75 gpm, and I have good water pressure. Also there is no way that little water is coming out.
Thank you for your tips on the SmartApp.
Hmmm, interesting. I just tried something, and I think you’re on to something.
Did you change the reporting threshold to 10 seconds from the default 60 seconds?
I did, and while the total gallons used calculations are right (last used, and highest usage), the flow rate is off!
To test, I filled a sink with 3 gallons and timed it; which took roughly around 109 seconds. I should have seen roughly a flow of 1.6gpm. When the DH was set to 10 seconds, I was only seeing 0.3gpm, but when going back to 60 seconds (the default), I got 1.6gpm.
Thanks for bringing this to my attention! I’ve been so busy bringing a 2 year project to implementation for work that the last few weeks have been “heck”, and haven’t paid much attention to flow accuracy.
I can get to solving this problem in just a few days, so give me just a bit of time and I’ll post back when I’ve updated the code.
Thanks again.
I did. You got it. Thanks!
I’m sorry about that bug. I wasn’t going to get any sleep thinking about the fact that I had a bug in my code, so I just updated my DH with the fix. Would you mind updating too?
The issue was that FortrezZ’s code assumed people wouldn’t change the reporting threshold, so their basic calculation of just subtracting the current value with the previous value gave an accurate flow rate cause 60 seconds was the default.
Since people like me and you just can’t stop tweaking our devices and always change the defaults ;-), the formula needed changed to take into consideration those changes (line 273 specifically). Here’s the github link again:
Hey @dantheman2865, FYI.
EDIT. High Flow alarm works now too, but only the first time. I need to spend some time figuring out how to reset alarmstate. Stay tuned.
1 Like
Will do tomorrow. Thanks!
First test, note second below: Appears it’s off in the other direction now. Did a fill test. Filling at about 1.25 gpm, and showing 7.2. Weird though it bounces around 1.8 toward the front and back side of the fill, but could be coincidence.
I’ll have a look at the code too.
Second test: Showed a really accurate 1.2 on second test after I hit configuration button. But ONLY showed the events/flow every 60 seconds, even though it’s configured to every 10 seconds. Weird.
Time to look at some logging for me. 
What I’ve found so far:
- Appears that it doesn’t report every 10 seconds until flow is on. This is very smart, I like it.
- I should have known that the app interface would report at intervals it wants. That was confusing me.
- GPM appears to have step increments of 0.6 GPM. This could be a DTH issue, or the fact that it’s a large flow meter and the resolution simply isn’t good enough to catch less. I’d still be happy, but will look into the device more.
BTW, this device is also capable of notifying on power loss. I think Fortrezz should consider selling the FMI on it’s own, or a variant just for that purpose. People are looking for devices like this!
PS: An error trapped:
8:37:41 AM: debug zwave parsed to [['name':'waterState', 'value':'none', 'isStateChange':true, 'displayed':true, 'linkText':'Water Meter', 'descriptionText':Water Meter water state is none]]
8:37:41 AM: error groovy.lang.GroovyRuntimeException: Ambiguous method overloading for method java.math.BigDecimal#minus.
Cannot resolve which method to invoke for [null] due to overlapping prototypes between:
[class java.lang.Character]
[class java.lang.Number]
8:37:41 AM: debug 0.0
8:37:31 AM: debug zwave parsed to [['name':'gpm', 'value':'Flow detected\n0.60 gpm\nat 08-08-2016 8:37 AM', 'isStateChange':true, 'displayed':true, 'linkText':'Water Meter', 'descriptionText':Water Meter gpm is Flow detected
0.60 gpm
at 08-08-2016 8:37 AM]]Correct, and sorry for the delayed reply. It’s just fat dumb and happy doing nothing when there’s no flow.
I’m not sure about that cause during my testing last night I would see it start at 0.1, then 0.2, and all ranges in between up to 1.6gpm for one of my sinks, and then bounce between 1.5 and 1.6. My reporting interval is set to 1 though. FWIW, when I set the threshold to 6 I also saw the flow rate bounce between 1.6 and 1.6, but waiting a minute for me is too long in my opinion.
Yep, and that feature works well. Their MimoLite does the same thing (except no battery backup), and I use a couple of them around the house for garage door control and my motorized water valve.
Interesting. I was live logging last night and didn’t catch this error. I’ll have to check when I get home from work.
The high flow alarm is my next thing to tackle. It’s set on the FMI, and managed in the DH by looking for alarm states, but once it trips, it doesn’t reset for the next high flow alert. I think because of the flexibility of SmartThings and how DH’s can be written, I may just handle high flow alerts separately via code than relying on the device to send an alert.
Hopefully I’ll have some time tonight to work on this. stay tuned.
1 Like
Ok, well I was able to repeat that too. Frustrating… You’d think the math part wouldn’t bee difficult. I’ve got a few evening meetings, so I’ll multitask and continue to work on the DH.
I appreciate the second set of eyes on this @bridaus. Thanks for helping me work the kinks out.
EDIT Log:
- Moved where “waterState” gets defined/send (none, flow, highflow) - from AlarmReport to MeterReport sections. On to figuring out the flow rate calculation goofyness…
Let me know how I can help, testing revisions and such. I don’t always have time, but when I do I’m happy to load it and test.
Thanks!
Here’s something interesting. I believe we’ve reached tweaking limits in terms of the lowest reporting and flow rates possible on this meter, assuming someone uses only 10 seconds, and since the meter only reports in tenths of gallons.
Here’s some raw data I collected with my sink flowing as slow as I could possibly get (and I mean slow). The DH would not report anything lower than 0.6, and I can assure you I was much less than that.
MeterReport(deltaTime: 10, meterType: 3, meterValue: [0, 0, 121, 208], precision: 1, previousMeterValue: [0, 0, 121, 207], rateType: 1, scale: 2, scale2: false, scaledMeterValue: 3118.4, scaledPreviousMeterValue: 3118.3, size: 4)
MeterReport(deltaTime: 10, meterType: 3, meterValue: [0, 0, 121, 207], precision: 1, previousMeterValue: [0, 0, 121, 206], rateType: 1, scale: 2, scale2: false, scaledMeterValue: 3118.3, scaledPreviousMeterValue: 3118.2, size: 4)
The difference between “scaledMeterValue” and “scaledPreviousMeterValue” is what is used to calculate GPM based on volume used, and when the time is set to 10 seconds, here’s what you get: (via FLOW CALCULATOR)
I still have some code clean up to do, so once I finish I’ll let you know.
Also, even though I was running the sink as a very low flow rate, the meter eventually updated the phone app to let me know there was flow. That’s good to know otherwise the continuous flow monitor (FortrezZ’s app) wouldn’t do it’s job.
Yeah, the maths say if you are measuring in tenths of a gallon, every ten seconds, you can only get 0.6 resolution on your GPM single reading by single reading.
0.1 gal per 10 sec = 0.6 gal per 60 seconds.
A better way to do this would be on a moving average, of a certain amount of readings. As readings poured in over time, the accuracy of the flow would improve. Could start after two readings (at 10 seconds), or a set amount of time based on resolution.
If it’s not something you want to do, I can pull request it, because I’m really interested in a filter change predictor when my flow gets too low. 
Oh now that’s an interesting use case predicting filter changes, I like it. Feel free to pull the code as I could use help with that kind of change at the moment. I just updated my github repo with my latest version.
Also, I did not catch that error you had in the post above today.
I’m slow because I have to steal time, but I’ll do this, thanks so much for your work on this, the device is awesome.
Yeah, same here. I should be paying attention in a meeting, but this is way more interesting right now… No rush on my end.
I started some work tonight, I have a good idea of how to do this.
Question: Do we think people will really want the 60 second gpm? When set to 10 sec the device only reports every ten seconds when there is flow, and not other times. I don’t think that’s a problem unless people run their water all day long, or this is in an industrial setting. This is not a chatty device/web device, I question whether the setting is useful. On the fence, thoughts?
I do like the quicker reporting primarily to catch and track short use intervals. Personally I’d like to see data in real(er) time, so the smaller the interval the better for me. I wish the reporting parameters were like Aeon’s HEM, but I can work with the flexibility the flow meter provides today.
Like you said, this is not a chatty device and it only sends data when there’s flow. I think 10 seconds should be the default, not 60. Heck, my several Iris and Aeon Smart Plugs are a 100 times more chatty, and they’re not causing my mesh any problems.
Finally got some time to work on this. Another thought provoking question:
Do you think:
- The meter reports the first tenth gallon immediately when it happens, OR
- The meter reports the first tenth gallon after it happens to sample the measurements once every reporting interval?
The difference is in case 1, the flow could actually be anything from 0.1 to infinity, and in the second case it could be a minimum of 0.6 to infinity.
I know I am overthinking this, but getting a bit more precision out of this using software is something I’m very interested in. Really love this device.
PS: I’m leaving the reporting threshold in, and simply making the device go into High Accuracy mode when the reporting is set to ten seconds. It’s the most flexible that way.
Working beta/prototype here: https://raw.githubusercontent.com/bridaus/jcdevhandlers/master/devicetypes/jscgs350/fortrezz-flow-meter-interface.src/fortrezz-flow-meter-interface.groovy
I probably didn’t break anything, works for me.
Issue pull request too if you like it.
Note: You have to be using High Accuracy Reporting (reportThreshhold = 1) in order for this to work. All other settings default to normal.
Hi @bridaus, I think it reports after the first 10th happens. I just turned on my sink with just a drizzle of water coming out, and it took several seconds before flow was reported to ST. I thought I remembered reading somewhere that it reported immediately when flow was detected, but that could also mean after a 10th gal had registered.
I’ll give your DH a try tonight. We just returned from a short vacation, so I’m playing catch up on a few things. The good news is that ST worked flawlessly for 5 days - Routines, SHM, Smart Lighting, you name it… My event logs were super clean, and I had zero device issues the whole time we were gone!
1 Like