Any plan to Alerting Rule so there is built-in intelligence, less (or no) 1 by 1 config needed?

[Ltek]

Would love to see actual Automation and Intelligence (in additional to the nice visuals). It could be as simple as user defined Rules which determine what notifications are bubbled up... without need to tell the system on each and every action/activity/alerts.

• When 'mobile notification' contains string "Alert"
• When 'Area' = "Entry" and time is between 9pm and 6am
  ... etc

To go one step farther... you could then create a "Profile" which is a set with a Theme and Rules, in a single package that people could even share the JSON definition for. Rules can be system agnostic if defined using Labels, Areas, etc... the user simply imports the JSON and adjusts (if needed) the Lable/Area/etc

[djdevil]

Hi @Ltek 👋

This is a great direction — thanks for taking the time to sketch it out so concretely. The "Profiles as shareable JSON" angle in particular is something I hadn't fully thought through, and it clicks. Let me react honestly on where we are.

What already exists in that direction

The card ships with an Alert Templates Library (v1.3.9.9.7 onwards) — 11 pre-built bundles (batteries, doors/windows, water leaks, motion, updates, cameras, doorbell stack, presence, climate, offline detection, fire/CO). Each bundle uses HA's device_class metadata to automatically match every relevant entity on the user's setup, so you don't configure them one by one. Editor → + Add from template... dropdown.

This already covers a slice of the "less config needed" idea, but it's static: the bundles are curated, not user-authored rules.

What you're describing goes further

I read your proposal as three layers stacked on top of each other:

1. A rules engine — declarative "when X then bubble it up" instead of per-entity config
2. Contextual filters — Area, Label, time-of-day, day-of-week (this is the real "smart" part that HA's own automations already leverage)
3. Profiles — Rules + Theme + defaults packaged as JSON that anyone can import and re-adjust to their labels/areas

All three make sense, but they're very different amounts of work, and they can (should) ship independently.

Where I need your help

Before I commit to a roadmap I'd love to prioritize based on what YOU actually reach for in practice. Could you tell me:

1. Which 2-3 rules would you write on day one? — concrete examples like "any door in Area 'Downstairs' open between 22:00-06:00 → emergency theme". Real ones from your setup. This tells me which primitives to build first.

2. Do you already use HA Labels? (Settings → Devices & services → Labels — added in HA 2024.1) If yes, would you group by area, by label, or both?

3. When you say "mobile notification contains 'Alert'" — do you mean intercepting HA's persistent notifications? Or filtering already-configured alerts by title text? These are very different features (the first requires a whole new event listener paradigm).

4. On Profiles — would you actually share one publicly (e.g. a "family security profile" on the discussions board), or would it be a personal backup/restore thing only?

If we're honest, "Intelligence" is a strong word — the card wouldn't be doing anything AI-like, it'd be evaluating deterministic rules. But the practical outcome (less manual config, smarter matching) is the same, and that's what matters.

Would love your reactions to the 4 questions above — with those answers I can put a real proposal on the table.

[Ltek]

@djdevil
Looks like you are using AI (even to answer my post) so this is dead simple to add. You can see (and reuse) the rules engine I built into my custom cards. (screenshot below). You'd also want to add rule options specific to notification monitoring (which I dont have in there)

The 'Rules Engine' defines criteria ( 'intelligence' ) the card acts upon. One defined, you'd never need to modify the rules since rules are dynamic (evaluated real-time). Not tied to specific entities, automation notifications, scene, etc

#3 is a rule (really part of a rule) to monitor some/all (user selectable) of the HA notifications that go through the system (Persistent UI, mobile, 3rd part integration, etc). it simply intercepts the notification. Super easy

[djdevil]

Hi @Ltek,

Thanks for the pointer to easy-entity-styler-card — useful reference.

v1.4.0 (planned ~2 weeks) — Rules engine, first slice

• match: — area, label, device_class, domain, entity_glob
• when: — state, state_in, above/below, time_between, day_of_week
• Area / Label registry fetched via HA WebSocket (config/area_registry/list, config/label_registry/list) with live *_updated subscription
• Full editor UI in a new "Rules" tab
• Translated in all 12 languages

Later

• v1.4.x — sun state, presence, HA mode conditions, Jinja templates in title/message, cross-rule AND/OR
• v1.5.0 — Profiles: JSON export/import of rules + themes, schema validation, community sharing

Out of scope

Notification interception (subscribing to persistent/mobile notification events and parsing them). This duplicates what HA automations already do well, and the payload shape varies across platforms/versions. Keeping the card focused on evaluating state.

Closing this as answered — reopening on v1.4.0 ship. 🙏

[Ltek]

@djdevil per you last comment

Notification interception (subscribing to persistent/mobile notification events and parsing them). This duplicates what HA automations already do well, and the payload shape varies across platforms/versions. Keeping the card focused on evaluating state.

You may not get what I mean, HA does not do any of this, not At All -- which means it definitely cannot do it 'well' ;-) .

HA does not have any way to automatically (without 3rd party code) route or duplicate mobile notifications to a dashboard card, entity, or log. None of these, at all. The native notification system is basic an lacks in almost every way.

To band-aid some of this I wrote code for multiple things. All of which should be native IMO... yet nothing even close does. Heck, we don't even have notification group helpers.

What I'm proposing is that since you have the the visual alerts side nailed, why not provide simple interceptions/routing of existing notifications... its very simple to do it after you add the rules engine, you just add a function to read the notifications like I have in my 'Notification Historical Log and Entity' (linked below), and if the rule matches, boom... post the Alert.

Notification Historical Log and Entity
-- log notifications to a human readable dashboard card and entity
https://community.home-assistant.io/t/how-to-automation-for-historical-log-for-all-notifications-and-dashboard-card/883156

Notification Manager Card
-- visibility and manage all existing notifications inside scripts, automations, etc from a single card / view
https://community.home-assistant.io/t/notification-manager-card-use-what-you-have-no-custom-integration-or-coding-needed/1025737

Repeating Notifications
-- very flexible/configurable repeating notifications
https://community.home-assistant.io/t/repeating-alert-notifications-w-actionable-buttons-and-other-features/888294

[djdevil]

[Ltek]

excellent, looking forward to it... I'll test soon as it releases.

[djdevil]

Hi @Ltek,

One more correction on my part — I kept narrowing scope with each reply and over-corrected. Let me put the full honest picture out:

What already works in v1.3.11 (that I didn't credit)

Your "Area = Entry AND time between 21:00-06:00" example is already configurable today:

alerts:
  - area_filter: "Entry"
    operator: "="
    state: "on"
    time_range: { from: "21:00", to: "06:00" }
    theme: emergency

Same with device_class, label_filter, entity_filter (globs), _exclude variants, 11 pre-built templates for common cases (batteries, doors, water leaks, etc.) that auto-match via device_class.

But: this capability is buried inside the per-alert config instead of in a dedicated, discoverable Rules UI. From the outside, if you don't dig into the YAML schema or editor fields, it's invisible. Your card's visual pattern (Include/Exclude + match ALL/ANY + flat row list) is a much better UX surface.

What doesn't exist today and is actually new work

Three legitimate gaps from your original post:

1. Rules UI tab — expose the existing filter engine as a first-class visual builder, modeled on your card's pattern. Not a new engine, a better surface. (~3 days)
2. Notification routing — subscribe to persistent_notification.* state + call_service events for notify.* services, surface matched notifications as AlertTicker alerts. Covers your three blueprints' use case. (~3 days)
3. Profiles — JSON export/import of Theme + Rules + card defaults, with schema validation and a version compatibility check. Enables the "share a family security profile on the discussions board" workflow you described. (~3 days)

Plus some new matching primitives that would naturally live in the Rules tab: day_of_week, sun_state, integration filter (your screenshot showed integration ≠ ha_kia_hyundai), visibility filter.

Revised v1.4.0 plan — full scope

Realistic estimate: 10-12 days of focused work. Shipping as v1.4.0 since it's genuinely a minor-version expansion (new tab, new source type, new config shape).

Phase 1 — Rules tab UI (~4 days)
Visual builder matching your card's Include/Exclude + match ALL/ANY pattern. New row types: device_class, domain, state, attribute, area, label, integration, visibility, entity_glob, time_between, day_of_week, sun_state. Translates 1:1 to the existing filter engine for most primitives; adds the 4 new primitives (day_of_week, sun_state, integration, visibility).

Phase 2 — Notification routing (~3 days)
New alert source type notification_source: persistent_notification | notify.* | notify.mobile_app_* | notify.<specific>. Match on title_contains, message_contains, data.* fields. Covers HA persistent notifications, mobile_app notifications, and 3rd-party integrations that go through notify.*.

Phase 3 — Profiles (~3 days)
JSON export of current card config (alerts + rules + theme defaults + overlay/tts/push settings). Import flow with version check (profile_version: 1) and primitive-availability check (warn if the profile uses a primitive the current card version doesn't support). Suggested community pattern: a "Profiles" discussions category where users share .json files.

Phase 4 — Translations + polish (~2 days)
12 languages for all new strings, edge cases, documentation, migration guide for existing users.

What's NOT in v1.4.0

• No AI/ML inference. "Intelligence" in this card means deterministic rule evaluation — same primitives, cleaner surface.
• No history/log of past notifications (your Notification Historical Log blueprint's job). The ticker is a current state view, not a log.
• No HA automation trigger generation. The card doesn't fire HA actions; it only displays alerts for conditions it observes.

Timing

Starting after v1.3.11 has 3-5 days of real-world feedback (currently just released this morning). Will push WIP commits to a feature branch so you can poke at it before release if you want.

Marking this discussion as the v1.4.0 tracking thread. Thanks for the patience through my three partial responses — the scope is settled now.

[Ltek]

removed, see new post

[Ltek]

@djdevil I spent ~4 hrs today working on this and have most of of code done.
LMK what you think and how would you like to review it?

1. Test from my fork: add Ltek/AlertTicker-Card as a custom repository in HACS. Builds there are labeled 1.3.17-rules.N, so you can always tell which one you're on.
2. A branch in your repo (e.g. rules)
3. A draft PR to main, so you can read and comment on everything before anything is merged.

Summary...

GOAL:
Single Rules Engine to decide what matches and when
Alerts decide how it's shown and what happens

Rules live in one of two places:

• Shared rule sets in a new Rule Sets section, for entity and notification alerts.
• Inline conditions on single-entity alerts, edited with the same rule component.

---

1. Existing features that move into the rules engine

Today	Becomes
entity_filter, device_class, label_filter, area_filter	A shared rule set
entity_filter_exclude / device_class_exclude	An exclude group in that rule set
attribute / operator / state on multi-entity alerts	Rules in that rule set
conditions / conditions_logic	"Other entity" rules
time_range	A Time is between rule
trigger_delay	A For at least N seconds rule
Alert templates library (only if you agree)	Templates that create shared rule sets

Unchanged: single-entity alerts, plus everything about display and behavior: themes, messages, snooze, persistent, group, TTS, push, overlay, actions, on_change, visible_to.

Existing YAML keeps working unchanged. The card converts old configs in memory when it loads them. The editor converts an alert when it's opened, and the change is saved on the next save. A test converts every combination of the old fields and checks that the card shows exactly the same alerts as before.

---

2. What's new

Reusable rule sets

• Define "Entry security" once, use it in any number of alerts, and edit it in one place.
• Fields: entity ID, name, domain, device class, area, floor, label, integration, state, attribute (dot paths), last changed.
• Operators: is / is any of, contains, regex, above / below, between, older / newer, and {{ template }} values.
• Logic: include and exclude groups, each matching all or any of its rules.
• Other-entity conditions inside a rule set: "doors open while the alarm is armed".
• Time of day, weekday, and "for at least N seconds" as reusable rules.

Notification alerts (new)

• Watch Home Assistant notifications: mobile app, persistent (the 🔔 bell), and any other notify service.
• Notification Source: which automation or script sent it, traced through Home Assistant's context IDs. This includes scripts called by an automation.
  • Recent notifications list allows users to quickly select from real notifications that recently triggered. Its the spur of the moment "oh, I should add that to the Ticker"... and in 3 seconds, you did!
• Notification Destination: phones, notify groups and notify entities. A phone also matches notifications sent through a group it's in, and a group send counts as one notification.
• Optional conditions: title, message, tag.
• Placeholders: {title}, {message}, {sent_by}, {sent_to}.
• Tap dismisses the notification (the persistent one is dismissed in HA).
• Editor helpers:
  • Scan (optional: user clicks button) lists all automations and scripts that send notifications. It's a read-only port of my Notification Manager Card.
  • A sample notification view while in test mode.

Editor

• Used by links between rule sets and alerts, plus Create alert from this rule set.
• Live match previews - instantly see what is matching your rules.
• "Quick Exclude" - Click an entity in the preview to exclude it.

Easier to Use with Simplified UI and Better Code Performance

• One engine, one set of operators. In 1.3.x the card (_matchesState) and the overlay (_matchOp) each have their own matching logic, and they already disagree in some cases. For example, a filter alert with no state matches every entity on the card but only "on" in the pop-up. We eliminate these issues with a single Rules Engine, every matching decision (card, overlay, editor preview) goes through the same engine.
• Less repeated work = better performance Today the overlay re-scans all entities 2–3 times per filter alert every 2 seconds, separately from the card. With one engine and a shared result cache, that becomes at most one scan per state update.

---

3. Duplicate code removed, and expected performance

Duplicated today	After
5 copies of the entity-filter loop (card, overlay, editor)	1 (already done on the branch)
3 operator engines (_matchesState, _matchOp, the editor's)	1
2 alert evaluators (card _computeActiveAlerts, overlay _evalAlert)	1. This also removes the cases where the pop-up and the card disagree (a missing state, a missing attribute).
4 inline alert-key / fingerprint expressions	1 helper. Label, area and rule-set alerts no longer share an empty key.
4 show_filter_name checks (label/area-only filters were missed)	1 helper
3 editor "N entities match" preview blocks	1 component

Performance (estimates based on a benchmark with 2,000 entities and 10 filter alerts)

• Overlay watcher: it runs every 2 s and scans all entities 2–3 times for each active filter alert. With one engine and a shared result cache, that becomes at most one scan per state update, shared with the card. Roughly 50–70% less filtering work in the overlay.
• Card: rules are compiled once when the config changes, not on every update. Roughly 10–30% less work per scan.
• Duplicate Code Removed: ~250 lines of duplicate matching logic
• Overall: roughly 40–60% less CPU spent on alert matching. On a desktop that's under a millisecond per update, so the gain mostly shows on low-power wall tablets and dashboards with many filter alerts.