[SOLVED] Conflicting Set Reaction Groups Appear to Fire Simultaneously in Single Rule Evaluation

[tunnus]

I really like these new widgets in MSR status page! Still, at least for the history-widgets, a filtering capability would be helpful. I have quite a many rules running with short intervals and they are clogging these lists making it harder to see "more interesting" ones...

Can file a request in Mantis, if there's wider support for the idea?

[toggledbits]

@tunnus I'd encourage some discussion here before opening a PR. The more specific you can be in defining the problem and, ideally, what you think the solution should look like, the more likely it will be to bubble up on the wish list.

[tunnus]

@toggledbits so e.g. in Reaction History widget I have a lot of repeating rules firing (by design):

These just make it harder to spot & follow more "rare" rules/events. Filtering would help, if you could specify strings that are filtered out. E.g. "SiteSensor" or "uplink" in my case.

[Alan_F]

I can think of several kinds of filtering that could be useful here:

Show only matching rules: So I can see the history of when a certain rule ran

Filter out matching rules: As requested above, to remove rules with 'site sensor' or in my case 'poll' from the list

Filter out rules by their characteristics: For example, do not show any rules that run based on time events. This would let me see only things that had 'happened'. I have a rule acting as a SiteSensor that runs every 60 seconds, but I really don't need to see that on the list.

I think ideally the filtering would be done right in the widget, and not in the config file, but it's probably easier to do more complicated filtering in the config file.

[tunnus]

@alan_f in my opinion filtering in the widget itself would be better than in a separate config. Would be faster/easier to change, configs need MSR restarts. Also, not a fan of yaml files...

[Alan_F]

@tunnus I agree in general, but if you wanted really granular filtering like a specific list of rules that should be filtered out, rather than just keywords, it would make sense to put those in a config file. Also if you always wanted them filtered out the config would make more sense. If you wanted to change filters based on whatever you wanted to see right now, then a config file and Reactor restart would be a pain.

Just thinking through the user interface... what if there were a drop-down box at the top of the widget. When the box opens up it would have all the rules listed, each with a check box next to it that would allow the user to select/unselect it?

That might get ugly on a system with hundreds of rules, so in a perfect world there would then be a text filter within the drop-down box. Click the drop-down to show all rules, then type "sitesensor" to show only the Sitesensor rules in the drop-down. Then the user could check/uncheck various Sitesensor rules. The user could then type "HVAC" to see only the HVAC rules and then check/uncheck various HVAC rules.

[toggledbits]

One of the many irons I have in the fire on this project is an editor for settings in the GUI/Tools page. Challenging, tons of fun, but a lot of work and miles to go before I sleep.

[wmarcolin]

Hi @toggledbits
Is the wish list still open? Is this information that appears in widgets stored in some attribute/element that we can access to use in rules? Or even demonstrate for example in a dashboard in Hubitat?
Thanks!

[toggledbits]

Everything that is shown in widgets are attributes of entities. All attributes of entities are accessible in rules. Does that answer the question?

The wish list is always open.

[wmarcolin]

@toggledbits I was thinking of the list of running tasks as "Set Rules", a simple way of having this query.