Likely you are attempting mixed type (number and string) in a column. See the InfluxDB-Logger support thread for discussion and information on how to identify.
2 Likes
thank you for the tip. it helped identify to failing attribute but i am not sure how to fixed it actually. I posted in the influxdb logger thread as well.
Failed record was: usageLastHour,deviceName=Flume_Water_Meter,deviceId=279,hubName=Home value=19.5 1690500420813000000
thank you!
I think i figured out the issue;
The Flume driver logs the events for "usageLastHour" is different way each time. Sometimes the value is numeric which is expected like "0.0" but sometimes it logs as "N/A" this causes issue with influxdb as the datatype changes from numeric value to string.
see sample:
| usageLastHour | 2.33 | DEVICE | Flume_Water_Meter | 2023-07-28 10:35:38.710 EDT | ||||
|---|---|---|---|---|---|---|---|---|
| usageLastHour | 0.0 | DEVICE | Flume_Water_Meter | 2023-07-28 10:05:31.567 EDT | ||||
| usageLastHour | n/a | DEVICE | Flume_Water_Meter | 2023-07-28 10:00:30.382 EDT | ||||
| usageLastHour | 0.0 | DEVICE | Flume_Water_Meter | 2023-07-28 09:05:16.449 EDT | ||||
| usageLastHour | n/a | DEVICE | Flume_Water_Meter | 2023-07-28 09:00:15.208 EDT |
is it possible to fix this in the driver?
Thank you!
Having an issue with this. I added a second Flume, parents house. I, of course, get the new device stats, not my home. Created a second account authorized for my home only. Change the username, password, secret, etc. Not working. Here's what's in the debug log, Looks like it's connecting fine, etc but then I get the error below. First 2 lines. Thoughts?
dev:1412023-08-08 09:54:05.098 PMerrorerror: status code: 400, reason phrase: Bad Request @ Line: 957
dev:1412023-08-08 09:54:05.093 PMdebughttpPostExec() failed: status code: 400, reason phrase: Bad Request
dev:1412023-08-08 09:54:04.859 PMdebughttpPostExec([uri:https://api.flumewater.com/users/104270/devices/null/query, headers:[Authorization:Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJIU...6ikStJKztY86XW7YBNY8], contentType:application/json, requestContentType:application/json, body:{"queries":[{"request_id":"lastMin","since_datetime":"2023-08-08 21:53:00","until_datetime":"2023-08-08 21:54:00","bucket":"MIN"},{"request_id":"lastHour","since_datetime":"2023-08-08 21:00:00","until_datetime":"2023-08-08 21:54:00","bucket":"HR"},{"request_id":"lastDay","since_datetime":"2023-08-08 00:00:00","until_datetime":"2023-08-08 21:54:00","bucket":"DAY"},{"request_id":"lastWeek","since_datetime":"2023-08-07 00:00:00","until_datetime":"2023-08-08 21:54:00","bucket":"DAY","group_multiplier":2},{"request_id":"lastMonth","since_datetime":"2023-08-01 00:00:00","until_datetime":"2023-08-08 21:54:00","bucket":"MON"},{"request_id":"flowLookback","since_datetime":"2023-08-08 21:51:00","until_datetime":"2023-08-08 21:54:00","bucket":"MIN","group_multiplier":3},{"request_id":"flowRefresh","since_datetime":"2023-08-08 21:51:00","until_datetime":"2023-08-08 21:54:00","bucket":"MIN","group_multiplier":3}]}])
dev:1412023-08-08 09:54:04.827 PMdebugfetchLocations resp = [success:true, code:602, message:Request OK, http_code:200, http_message:OK, detailed:null, data:[[id:139460, user_id:104270, name:Home, primary_location:true, address:123 Main St, address_2:null, city:Carlstadt, state:NJ, postal_code:07070, country:United States, tz:America/New_York, installation:HOME_ADDED, insurer_id:2, building_type:SINGLE_FAMILY_HOME, away_mode:false, usage_profile:[:]]], count:1, pagination:null]
dev:1412023-08-08 09:54:04.825 PMdebugX-RateLimit-Remaining is 117
dev:1412023-08-08 09:54:04.425 PMdebughttpGetExec([uri:https://api.flumewater.com/users/104270/locations/?limit=50&offset=0&sort_field=id&sort_direction=ASC&list_shared=false, headers:[Authorization:Bearer eyJ0eXAiOiJKV1QiLCJh...W7YBNY8], contentType:application/json, requestContentType:application/json])
dev:1412023-08-08 09:54:04.423 PMdebugfetchDevices resp = [success:true, code:602, message:Request OK, http_code:200, http_message:OK, detailed:null, data:[], count:0, pagination:null]
dev:1412023-08-08 09:54:04.421 PMdebugX-RateLimit-Remaining is 116
dev:1412023-08-08 09:54:04.251 PMdebughttpGetExec([uri:https://api.flumewater.com/users/104270/devices/?user=false&location=false, headers:[Authorization:Bearer eyJ0eXAiOiJKV1QiLCJhb...Y86XW7YBNY8], contentType:application/json, requestContentType:application/json])
dev:1412023-08-08 09:54:04.207 PMdebuggetTokens resp = [success:true, code:602, message:Request OK, http_code:200, http_message:OK, detailed:null, data:[[token_type:bearer, access_token:eyJ0eXAiOiJKV1QiLCJhbGciO...Dt36ikStJKztY86XW7YBNY8, expires_in:604800, refresh_token:4afbd9...293ea3b]], count:1, pagination:null]
dev:1412023-08-08 09:54:04.206 PMdebugX-RateLimit-Remaining is 119
It looks like the info that is expected by the virtual device is missing. Please enable debug logging and then try hitting configure on the parent device page. Then refresh the page and see what appears in the devices entries in State Variables on the virtual device page.
Hi,
with new account
devices : []
with original account
- devices : [{connected=true, product=flume1, last_seen=2023-08-09T03:19:26.000Z, battery_level=high, user_id=30931, bridge_id=6668xxx33658, id=6661xxxx9017, type=2, oriented=true, location_id=42004}, {connected=true, product=flume1, last_seen=2023-08-09T03:22:58.000Z, battery_level=high, user_id=30931, bridge_id=666xxxx904, id=66629xxxxxxx9201, type=2, oriented=true, location_id=36221}, {connected=true, product=flume1, last_seen=2023-08-09T03:16:21.000Z, user_id=30931, bridge_id=null, id=66683xxxx3658, type=1, location_id=42004}, {connected=true, product=flume1, last_seen=2023-08-09T03:23:00.000Z, user_id=30931, bridge_id=null, id=666xxxx904, type=1, location_id=36221}]
Please PM me the Logs output for the new account when you hit configure.
1 Like
Hey @tomw, can you provide any insight as to the meaning of “Monitoring” as a flowStatus value. I assumed—apparently wrongly—that this attribute was native to the API, so I asked the question of the Flume folks and they have no idea what I’m asking about, so now I’m guessing flowStatus is created by the driver.
The other values—Running and Stopped—seem self-explanatory. I don’t know what Monitoring means though and couldn’t find any references in this thread.
TIA.
@mluck flowStatus means if water is running and the driver is watching and tracking the flow and duration.
From there, the driver can then calculate how long the water has been running (by looking back in time -- hence monitoring). In hubitat, you can then set a threshold of when you want to be alerted based on how long the water has currently been running.
EDIT:
Another way to look at it is, if the water is off, the driver still monitors back in time. This allows a hubitat alert to untrigger (ie it was above a threshold, the water stopped -- but the threshold still exists for the next 2 min, and then stops)
2 Likes
Thanks for the response but I’m still not clear. I see three possible values for flowStatus: Running, Stopped, and Monitoring. I intuitively understand what Running and Stopped means. But it would seem the water main is ALWAYS either running or stopped. I would thing those two values would be collectively exhaustive.
In what situation would the Flume be Monitoring, but neither Running nor Stopped?
Monitoring = stopped water but still watching the look back -- and the duration is not set back to 0
If water starts, the time continues from where it was
Lookback = 5 min
Water starts, and runs for 1 min, and stops; Duration = 1 min
3 minutes later water starts and runs for 1 min; Duration = 4 min
The flumes sensitivity is great, but at low levels it isnt.
I had a slow leak; instead of the flume catching the slow 'drip' in real time, it would catch an accumulation of the amount over time that hit the sensors detection level. Flume itself did not catch the leak, so the lookback can monitor what is happening now and what happened in the past
Once the lookback water amount goes to 0, the status is set back to stopped, and the duration resets to 0 on the next water flow detection
If you set the lookback == refresh, it basically acts as you described without the lookback
2 Likes
Thank you much. Crystal clear!
@mluck awesome ... here is a working example for future travelers as well
refresh = 2min
lookback = 5min
There is a small leak, not enough to continually trigger the sensor, after a certain amount/time does.
This accumulation doesnt get detected based on the level/accumulation for 3 minutes. Flume will just see this as water start/stop/start/stop
With the lookback going back 5 minutes, each of those 3 minutes will continue to be aggregated as a total-run time
In hubitat, you can then set an alert/other to say 30 minutes ... You know (hopefully) nothing runs for that long and you can be alerted
2 Likes
Had an interesting thing happen recently. I noticed a while back that flume was registering almost zero water flow daily - like .1 or .3 gallons a day. obviously we are using more than that. I assumed the batteries were dead/dying, but when I checked the app it showed them at 100%. That really didn't make sense as I've had the sensor in place since Feb of '22, a few weeks past two years ago!
Yesterday I finally made time to look into it. Went out to the water meter out front and found (as sort of expected) a mess inside there. It's one of those underground w/a concrete lid over it. There were bugs, black widow spiders, dirt, dust and debris, likely due to significant storms we've had over the last few months. The Flume sensor was still in place w/its strap around the meter, but dirt and debris had worked it's way between the Flume sensor and the meter.
I cleaned things up a little w/out actually removing the sensor. (Admittedly a little freaked out by the black widows.) I moved the meter back and forth and disloged/removed as much as the dirt/debris between the sensor and the meter as I could. Ran some water and checked the app and water use was registering normally again, and appears to be working normally now.
One surpise is that the sensor is still reporting full battery to the Flume app, which it obviously can't be after two years. I'm thinking that it may update at some point, but it's been over 18 hours since I cleaned/adjusted the sensor and still showing 100%. Regardless of what it's reporting, I am mightily impressed that it still has enough juice to run at all after just over two years. IIRC I haver the black shrink-wrapped version of the battery pack.
I have a buried power line nearby, so at some point I'd like to follow through on plans to setup a wired power connection for the sensor, but there always seem to be too many honey-do's that I am told have a higher priority. 
This small adventure reminds me to thank you again, @tomw for the integration. 
6 Likes
Just ran across this Flume 2 battery pack hack, looks very interesting.
2 Likes
Batteries finally died, just over 2 years since install in 2022! Pretty impressive. I put in another set of Engergizer Lithiums and hope to get another two years.
Very glad that I have the original black battery pack rather than the grey. Super easy to remove the original batteries, replace them w/new, and slip the battery pack back in.
2 Likes
When I got my Flume, I think I got one of the last ones that shipped with that old/plain battery case, and thank goodness -- it made using a battery-conversion kit easy-peasy, and I haven't touched my Flume setup in years now... It's been chuggin' along with zero issues since install.
1 Like
Nice...no battery waste and no service gaps. That has been on my list, but my valve/sensor is out by the end of my driveway and I have to dig up the area to find the buried line that fed a light post that used to be there. Seems I have been a bit lazy, it's been two years!
1 Like
