ignored_states by items

[lcnittl]

As I understand, ignored_states and ignored_items work independently. Thus, if there is something in ignored_items -- let's say "button.*" for example, then all buttons are always ignored -- likewise, if there is something in ignored_states -- let's say "unknown", then all items with unknown state are always ignore.

Is there a way to use a combination of both? So for example, I only want to ignore button entities, whose state is unknown and not those whose state is e.g. missing. Is this currently possible, and if not, would you consider adding such functionality?

I could envision something like:

{"button.*": ["unknown"]}

In theory, this could substitute/combine both ignored_states and ignored_items, with

{"*": ["unknown"]}

being like ignored_states = "unknown", and

{"button.*": ["*"]}

(or "all", instead of "*" for states?) being like ignored_items = "button.*"

Thanks for your consideration! (and the nice tool :-) )

[dummylabs]

Hey @lcnittl, you're right, at the moment these settings work independently.

One of the project's goals is to keep it simple for end users while providing maximum flexibility. Thus all watchman settings were migrated to the UI in the past. Additional new format for ignored_items or ignored_states for the UI settings apparently makes it more confusing for the end user. Technically this can be achieved by creation of some extra yaml settings which are not visible in the UI and somehow take precedence over UI settings. But current integration architecture does not support such a split, all yaml settings are imported to the UI upon the first run and UI settings then become the only source of truth. This is a compromise which makes further development and testing much easier.

I believe the main case for most of the watchman users is a one-time big housework to detect and fix the bunch of the errors in their configuration files. Yes, they can then set up watchman to detect and report future errors automatically, but once most of the errors fixed, this automation should not require sophisticated filtering rules IMO.

What it your use case? Can it be solved if watchman will ever learn to generate reports in CSV format, which can be imported to the MS Excel or Google Sheets for further analysis and filtering? Or, may be, you can add specific button names in ignored_items list instead of wildcards?

[lcnittl]

Hi @dummylabs, thanks for your reply!

What it your use case?

I would say, this:

Yes, they can then set up watchman to detect and report future errors automatically, but once most of the errors fixed, this automation should not require sophisticated filtering rules IMO.

describes it quite nicely.

Why do I need more sofisticated rules after inital clean-up? I am experimenting quite a lot and have 4 different instances of home assistant running -- sometimes I copy paste junks of configuaration from onw instance to another -- in this case it is nice to have "direct" metrics in the WebGUI (via provided sensors and MarkDown panel). I fear that in this situation, exporting to cvs (or any other format) would not really solve the "problem" as it would add more steps get the insight.

Non-wildcarding entity_ids unfortunately fails for the same reason, being that there is plenty of changes (with unforseen entity_ids).

I see the point about making the configuration more complicated. Do you think that either of:

• have an additional field for this advanced configuration
• have an option (bool) to allow more advanced configuration (using the same fields)
• allow advanced configuration all the time using the current fields, with a logic that automatically determines what kind of config is used

would be feasible to consider?

[dummylabs]

I see your point now, thanks, will keep it in the backlog.

[dummylabs]

So far I don't see a way to map ignored_states to ignored_entities without overcomplicating the integration settings. Frankly, this would also confuse a significant part of the user base. There are plans to make Watchman settings alterable via a service (as a solution for #100), allowing users to change both ignored_items and ignored_states from an automation and run reports using these settings. These lists will remain independent, but will enable users to get different sets of rules for different reports without complicating the UI settings.

[lcnittl]

Thanks for your reply. no worries at all, it was just an idea, if it is not feasible and would make things to complicated, so be it. Still happily using Watchman