core
core copied to clipboard
Flume Integration High Flow Does Not Turn Off
The problem
When a high flow alert is triggered, the state does not auto turn off, nor is it possible to turn off or clear the state of the sensor in Home Assistant. The only way to get it to clear is to use the Flume app itself which defeats the purpose of using Home Assistant in the first place. This design also prevents keeping notification history in the Flume app as the notification has to be deleted.
Same issue occurs with the leak sensor. The Flume app shows the leak ended, Home Assistant does not. The only way to get it to update is to delete a notification in the Flume app itself which is illogical.
Use Case:
High Flow state is turned on and Home Assistant triggers notifications on the dashboard and via other automation. The state of the high flow sensor should turn off on it's own based on status from Flume, and not based on someone manually deleting a notification in flume app. By design, I want those notifications to remain for history purposes. There is no reason to keep the state of the sensor 'on' when the condition has cleared. Notifications have already gone out and people are aware at that point.
How should this work:
-
Preferred - Automatically turn off the high flow sensor when the condition has cleared based on a state from Flume -OR- based on flume real time water usage sensors showing no current flow.
-
If no other choice - Allow the high flow sensor to be turned off from within Home Assistant. This can be either someone clearing the condition on a dashboard, or from an automation that is using real time data from Flume (water usage) or other physical water leak sensors.
The API appears to have a way to mark the notification read. If there isn't a physical state for High Flow then perhaps an action in Home Assistant could be used to mark the notification read and set the state of the flow sensor to off.
What version of Home Assistant Core has the issue?
2024.5.2
What was the last working version of Home Assistant Core?
No response
What type of installation are you running?
Home Assistant OS
Integration causing the issue
Flume
Link to integration documentation on our website
https://www.home-assistant.io/integrations/flume
Diagnostics information
No response
Example YAML snippet
No response
Anything in the logs that might be useful for us?
No response
Additional information
No response
Hey there @chrismandich, @bdraco, @jeeftor, mind taking a look at this issue as it has been labeled with an integration (flume) you are listed as a code owner for? Thanks!
Code owner commands
Code owners of flume can trigger bot actions by commenting:
@home-assistant closeCloses the issue.@home-assistant rename Awesome new titleRenames the issue.@home-assistant reopenReopen the issue.@home-assistant unassign flumeRemoves the current integration label and assignees on the issue, add the integration domain after the command.@home-assistant add-label needs-more-informationAdd a label (needs-more-information, problem in dependency, problem in custom component) to the issue.@home-assistant remove-label needs-more-informationRemove a label (needs-more-information, problem in dependency, problem in custom component) on the issue.
(message by CodeOwnersMention)
flume documentation flume source (message by IssueLinks)
Pretty sure this is covered in docs. You have to manually use app to clear notifications - else they still show up. Same for leak.
Also it's the middle of the night so I could be wrong :)
This behavior is illogical and not consistent with other integrations. There is also no way to update, clear, or change the sensor state in Home Assistant. The Flume API discussion and app behavior points to more advanced ways to handle these states besides relying on a notification.
There was a discussion earlier about clearing it. I'm not sure what became of it.
I just got bit by this. It is one of those things that cause "spousal acceptance factor" to be decimated. Thankfully my spouse is more understanding, but not everyone is so lucky. Here's the use case:
- High flow detected, but it was a false alarm.
- Automation turns off house water at the main
- Spouse overrides the water valve, spouse is happy
- Something happens later in the day, a Home Assistant restart, internet connection lost (because this integration is internet polling), and the automation triggers again, as state changes from unknown to wet, or unknown to high flow. Changing the automation to only trigger from dry to wet, and low to high flow may help.
- Spouse says what?
Lost a lot of sleep over this issue as well. Last night a storm brought heavy rain and hail that temporarily disrupted the Flume WiFi signal. A few minutes later when connectivity restored, I got the water leak alarm in home assistant which simply triggers on the leak and/or high flow sensor going to the 'on' state.
Unbeknownst to me, the water leak sensor was still in the 'on' state from a leak that was detected a few weeks ago. I had no idea that old notification had to be manually deleted with the app or portal - of course I missed that tidbit in the doc.
So a WiFi reconnect will trigger the alarm on an existing leak on state, as will disabling/re-enabling the Flume integration. Oddly, an HA restart will not or else I would have seen this issue many restarts ago.
I'll have to consider another automation that triggers if the leak/flow sensor 'on' state has been ongoing for 24 hours to send a reminder alert to manually clear the damn stale notification.
"To clear the notifications, you will need to use your Flume app or go to: https://portal.flumewater.com/notifications and clear the notification in question."
Unfortunately this is a RTFM situation 😀
Some ideas have been floated around before
Well, instead of RTFM, I did RTFGH issues to find this as a known concern. Sure, I've since deleted the notification, but thought it worthwhile to bump the issue and to see what, if any, progress was being made. And as you said 4 months ago, there was some discussion about clearing it automatically, but was not aware what became of it.
RTFM??? Fine, but it's not logical and poor design. Plenty of folks here chiming in trying to explain this needs some attention to fix it. Thank you for what you do and providing the existing functionality, but there is absolutely room to improve this. Would be good for you to provide some sort of update on what has been done to look into other options.
There was at least 1 PR that was submitted a while back - but it got rejected and the person never moved it forward. I don't recall why. I'm not sure else how better to communicate the situation other than the docs. I don't have the bandwidth to write a patch - but am open to any other ideas you might have?