There's not really a way to optimize it further without losing info from attributes supported by the integration.
The best I could see was maybe to remove 1 API access (out of 4) from each refresh, which would require removing the home/away status info. Some people might use this for automation or even presence indication, though, so I'm reluctant to do that.
What are you trying to do that requires further optimization? Keep in mind that the Flume sensor data itself isn't particularly responsive even though it is very accurate once updated, so spinning on Refresh at a high rate doesn't really give any more responsive data.
I was thinking that each poll to the API gives a number, and the quicker I can poll that number the more accuracy I'll gain in my hubitat logging over time. But if the resolution is only so-much as provided by the flume API, maybe it doesn't matter then?
The measurement is very accurate, but it doesn't update very often no matter how fast you poll using the API. So, I don't personally see much benefit from refreshing more than a few times per minute.
Another question on tiles. I used attribute tiles to show me the last min, hour, and day of water usage. However, it's a bit of a waste of space honestly. On the Neurio driver they were able to use an "html" attribute to let us make a custom tile (although I haven't figured it out yet, but others have). Is there something like that possible in a future update of this?
I would recommend looking at one of my other drivers like the children from the Unifi Network or Blink (I think) to copy over the Tile Template method. It is a replacement/update I made to the original mircolino method (who is not on Hubitat anymore).
@tomw and I seem to have way too many cross over points.
@tomw
Hey Tom.....noticed the last couple days your awesome flume driver is generated some errors in the log. I'm not noticing any particular problems manifesting, but maybe I'm just not noticing yet.
error: status code: 429 reason phrase: too many requests @ line: 950 (and also @ line: 133)
That's the rate limiting error from Flume's cloud. They limit the number of requests per hour to 120, and each refresh from my driver executes 4 requests. What do you have as your scheduled refresh rate? Do those errors go away after an hour (and then possibly return later in the 'next' hour)?
The flume mobile app just notified me it’s time to replace the battery pack in my Flume 2. That means mine lasted about nine months, and now I get to pay them for the privilege of using another one of their proprietary packs.
What have others’ experiences been like with the Flume 2 battery?
If you have the shrink-wrap version and a outlet close enough, a mains-powered battery conversion kit works really well -- mine's still going since original install over a year ago.
I gotta think there's a version of that shrink-wrap model's basic 4-battery "cage" on AliExpress or something like that -- it just seems to be a super vanilla / standard looking battery component thingamajig.
Yep, I'd bet you will run into that issue about halfway through each hour. Is that what you're seeing?
Try pinging Flume support to see if they would increase your limit given your use case (and that you're a repeat customer of theirs). Maybe they will throw you a bone.
For anyone curious, these are the 4 requests and their purposes in each refresh by my integration:
/devices/{id}/query - for usage data (minute, hour, day, week, month)
/users/{userid}/usage-alerts - for usage alerts, primarily smart leak
/users/{userid}/notifications - for notifications, like high flow, long duration
/users/{userid}/locations - for location information, primarily home/away status.
The last one is the one I alluded to earlier in this thread as one I could potentially remove, but ultimately the rate limit is so low that it isn't a silver bullet for anyone that is polling faster than every other minute or for multi-device use-case like @mluck
Interesting and disappointing interaction with Flume today. They basically said the their API volume limit is set per-customer. As a result, if I purchase two or three Flumes, I only get a half or a third of the API value. Which doesn't seem to make good business sense as it disproportionately punishes repeat customers.
I spoke to a support manager this afternoon and asked them to reconsider. They said they'd get back to me. Fingers crossed.
Their limit is really low. It's barely usable as it is.
If their cost structure is based on keeping that limit so low I could understand it on a per-unit basis. But per-customer is punitive like you said for anyone that wants to use it with multiple purchases.
Well, the saga continues. Here's the response from Flume's engineering lead. It's a workaround that should be fine for now, but a bit silly for a startup that is still supposed to be in an agile stage of growth. Oh well.
@tomw, I don't see any reason that your Hubitat integration would be rendered unusable by this workaround, do you?
Yes, currently if you set up an additional device with a different account you will have a separate API allocation. You could even set up an account using something like mluck+1@alum.mit.edu and the emails will still go to mluck@alum.mit.edu - but this of course would make a 3rd party integration like Hubitat potentially unusable.
Unfortunately, the system we use isn't designed to make account level exceptions for the API limits, but I understand your point and have recorded this as a feature request!
At some level, every software person is just hacking away at things I guess.
I think it would work, as long as the account email and client ID/secret from Flume and the login details you use for my integration are a match, regardless of where the emails ultimately end up.
