dummylabs
Implement dynamic ignore_items + service calls
This adds an additional ignore_items list that is dynamically populated by calling newly added services watchman.add_ignored_items and watchman.remove_ignored_items. This would enable users to build automations that change what entities should be ignored depending on various external conditions.
Potentially a solution for #100.
Not sure if this is the best approach to get dynamic filtering support implemented though, so feel free to brainstorm / suggest improvements!
Potential improvements:
- Somehow represent the active
ignore_itemslist so this info can be taken into account when populating the dynamic list. - Should the config be parsed again explicitly after these services are called?
- Or provide as a service field for user to choose?
I'm not sure if this is something that should be part of Watchman. I've this situation with my RV which occasionally obviously is away from home, and thus from HomeAssistant. For my entities that are in the RV, I use "python_script.set_state" to set their state as "away" when the RV is not at home. That excludes them from watchman reports when their unavailability is obvious. It also shows their state in dashboards clearly as something that is anticipated under such conditions.
For my entities that are in the RV, I use "python_script.set_state" to set their state as "away" when the RV is not at home
Externally changing an entities state could have nasty side effects that should ideally be avoided, and would require a user to alter the state for each of these entities. Looking at my setup there could be hundreds of entities offline at any given time which would make altering all those states unfeasible.
On the other hand, a single call to watchman.add_ignored_items using a list of wildcard patterns to match the required entities would do the trick.
On the other hand, a single call to
watchman.add_ignored_itemsusing a list of wildcard patterns to match the required entities would do the trick.
Do you have a suggested solution to show their states on dashboards as something that is expected, under those condititions ?
Hi @RoboMagus, thanks for the PR. I believe this task can be simplified with a service that just overwrites the content of the ignored_items list in the Watchman config entry. That way, you don't need to manage a separate list, and the user has one source of truth. And it seems to be more straightforward from the user's perspective. If someone decides to manage it through automation, they won't need a separate configuration option, and vice versa.
Please note that the format of ConfigEntry data has changed in version 0.6.4 to make the config_flow code easier to read and understand. In version 0.6.3, all comma-separated lists (e.g., included_folders, ignored_items, ignored_files, etc.) were stored as lists. Now, they are plain strings with comma-separated names, and all back-and-forth transformations for OptionsFlow code have been removed. Integration settings are now fetched directly from the ConfigEntry object all over the code without an intermediate dictionary in hass.data[DOMAIN_DATA].
I haven't merged these changes into the main branch yet, doing so will definitely cause conflicts with your PRs. I apologize for the inconvenience.
The 0.6.4 is tested and ready to publish, but I'm struggling with hassfest validation flow bug ~~which blocks this version from being published to HACS~~.
Upd: apparently, failed hassfest validation does not prevent release to publish to HACS, 0.4.6-beta.0 is out! :tada: