I made more changes from the code you originally pulled from. For some reason, high flow alarm would trigger just once, and never again. I couldn’t understand why (still learning DH coding and such), so I changed the code to do that within the DH instead of relying on an alarm condition to be sent from the physical device. I figured the flexibility with ST allowed for that. I just used sendEvent for “water” and “waterState” and it works as expected.
I’m going to incorporate your changes so I don’t have to try and merge a lot of changes. I like what you did and look forward to testing.
EDIT. Thanks for your work on this. I’ve wanted to learn more about lists, and this is very helpful.
No worries at all. I tested quite a bit last night, and your stuff works perfectly. I made several other changes as well to clean things up:
Merged your changes, but I commented out your logging debug/trace statements so as to keep Live Log as clean as I could when not making code changes and debugging.
Changed how parameters are handled via the new Updated section now (no need to tap on the config tile) and removed unneeded code due to that change, specifically the area where you asked why setThreshhold was being called in the parse section (part of FortrezZ’s original code).
Cleaned up code for how high flow is detected compared to FortrezZ’s original design, and made sure it didn’t cause problems with their SmartApp (if you’re using it).
My next change will be to work on the section where you can reset the meter back to zero, not just the high values for GPM and gallons used.
Here’s the latest for your review. I learned a lot from spending time understanding what you did, which gave me many ideas for a few other DH’s I’m tinkering with. Thank you for spending time on helping make this a better DH, I really appreciate it!
Scratch the “Updated section” part. For some reason ST runs each section twice and the parameters don’t take, but if you tap on the Config tile after changing parameters everything works. I have no idea why.
Actually I almost prefer not to have it automatically run because what if you made a mistake with your choice and wanted to back it out? I think I’ll remove the Updated section and just require the user to tap Config afterwards.
Yes, and I’ve been working with FortrezZ support the last few hours. There’s a error in their tech spec document that they found, as well as a separate command class to call. I’ve tried both of their suggestions, but it still didn’t work, so I’m just waiting for another suggestion from their engineer. Stay tuned.
Tested briefly. Looks great. Like the style changes. Some things to check into (either of us)…
After a reset, the cumulative is set to the actual to-date (I think). So the highest usage shows that first very high value until the next reset.
I think this is in my code, I got a super high gpm at some point, and it stayed highest. I’ll have to think through the logic to see if there is any divide by low numbers maths issues.
Sometimes in Android, staying in the app makes an extra linefeed happen in the tiles. Doubt we can do anything about this, probably an app issue.
My battery meter has always shown zero. To be fair, I’ve never tried diagnosing it except I did swap the cables once as mentioned somewhere, but that’s all I did.
Yeah…the reset isn’t working yet. FortrezZ said it works on their end, so the only recommendation I was given is to physically reset the meter and try again. I’ll do that next week before the end of the month, so for now all it does is reset the values until the meter can get reset. What I find very interesting is that you too are experiencing the same thing. I wonder if FortrezZ is testing with newer firmware than what we have.
I did mean to tell you that last week. It started after I used your changes. Just tap on the tile to reset just the high gpm value. I may just revert back to my original code for that part. I’m ok with how it was calculated before given how the meter works. For my use case I’ll be good.
I’m sure you’re right cause I see that happening on a few other DH’s I have on Android (all my phones and tablets). Unfortunately (or fortunately) I don’t any iOS device to test with.
Battery reporting is funky. I ran my FMI on batteries for 2 days and never saw a level change. The first time I did that is when I got a battery report, but after that I never bothered to do any more testing like you.
I went ahead and did a factory reset on my FMI and reincluded it to ST. The factory reset worked, but doing a meter reset with ST (both methods they told me to try) did not work. I’ve emailed FortrezZ support again. Stay tuned.
I think maybe it’s the software that should reset this value, yes? It’s ok if the meter keeps it forever, you just have to calculate that in your rest. The energy meters are the same.
Yes, that’s what the DH is suppose to do. meterReset() is suppose to do that based on the command classes the FMI supports, as well as parameter 3 configurations, but neither of those to methods work.
Support got back to me this afternoon, and it’s fixed. Totally my error in the code. I’m embarrassed… I forgot to include “return” before cmds.
I’m cleaning up a few things, and want to add some type of timestamp in the DH to let the user know when the meter was last reset. Stay tuned, and I’ll post an screenshot and link soon.
Hey @bridaus, @dantheman2865. I updated my DH, and I decided to see how well “carouselTile” would work as the top tile. It does!
Every time you cycle through the different charts or refresh a chart, it adds that to the carousel so you can swipe to the left to see past charts. Is it useful? Probably not, but it was a fun and an easy tweak to the DH.
I discovered a problem with the data that is sent to the cloud to build the charts when report threshold is changed.
sendDataToCloud is called when there’s flow, and the data being sent is a calculated flow rate but the charts are displaying gallons. I believe that changing the reporting threshold to anything other than 60 seconds causes wrong gallon data on the charts.
I started wondering how in the world I was using so much water, and discovered that the call to the cloud was sending my gpm’s every 10 seconds (I want it that fast). So that meant I was sending 1.2, 1.8, 1.2, etc etc which would add up on the charts to 4.2 gallons using that sample data, when in actuality I used more like 1 gallon. I tested using my sink and a known water level representing 3 gallons. With a 60 second reporting threshold I used 3 gallons, but with 10 seconds I used 18 gallons based on what the charts say!
To resolve this, I moved where data is sent to the cloud, as well as what variable should be used. I moved sendDataToCloud to within the IF statement that checks for delta == 0. This also reduces the need to constantly send data to the cloud. Technically we should only send data once flow stops. Here’s the updated code:
I also added a few new attributes (ending in LastReset) to capture high values prior to being reset in case the user needs to know or forgot to save.
EDIT:
Also added another user preference for a custom device ID (used only for charting) that causes a new set of charts to be created. There’s no easy way of resetting charts if you want to start over after resetting the meter, unless a user waits it out for the data to cycle all the way through 4 weeks of data collection, or the user does a factory reset causing the device ID to change.
If you’re interested, I created a little SmartApp that will reset the meter on a monthly basis at a time you specify. This is handy if you only care about seeing current month data in the phone app, especially if you do any external logging for long term analysis.
