@mill7 , by the way, generators can take dictionaries, in which case the keys become variables available in templates. So you could implement your alert with the list of thresholds inlined as follows (once I release template support for delay_on_secs):
I asked chatagpt about this, but he couldn’t give me the correct code without errors.
I think for dumb people like me to improve documentation it should be optimized for neural networks, so that when they make a request, chatagpt give the code without errors.
There’s a slight inaccuracy in this line, the quotation marks are needed
Hi All,
I just released v1.11.4 of Alert2 and Alert2 UI.
Changes
Add done_notifier config option to specify notifier to use to notify that a condition alert stopped firing.
Make delay_on_secs take a template when used with generators
Update tests and docs
@mill7, I also added an example of using variable dictionaries in a generator. No idea if LLMs will pick it up or not. And thanks for the typo correction.
I was waiting for a forum post about support for null values in delay_on_secs: but the update to HA came faster
thanks a lot it’s the best way to do things ))
I understand that if there is more than 1 alarm message in 1 minute, the messages stop being sent, but when the alarm goes away, the message is only about Throttling ending.
But I have all alarms through rest_command: sent to my site in my database and I can not get a message that the alarm is finished if there was Throttling, it turns out I need to either not use Throttling or in my database will forever hang not closed alarms.
If I understand this correctly, it would be great to just send a separate message that the alarm is closed and a separate message that there was Throttling.
@mill7 : Throttling disables notifications, so by it’s nature you will miss events when the alarm starts or stops firing. Are you saying you want an extra notification when the throttling ends that reports whether the alarm is still firing or not?
A better mechanism to programatically track alarm state is to trigger an automation based on alert2 events (eg alert2_alert_on and alert2_alert_off) on the events bus, and have that automation update your database. Would that work for you?
Just chiming in with a massive thanks to the developer of this alerting integration. Echoing what other people have said in this thread, I’ve also managed to cut a lot of configuration code, hundreds and hundreds of lines in favor of using this, and also simplified enormously the process of new alerts getting added to my system. Because it’s no longer a huge chore to add new alerts and the configuration can reload without restarting all of Home Assistant, now I feel no fear of adding new alerts.
I would also like to extend an enormous thanks to the developer of the notiscript integration. This has been instrumental in helping me glue together the alerts created by Alert2 with a script that I already had, which I was already mostly using before. Being able to pipe all alerts through that script allows me to log the alerts at the time that they happen and also have a consistent behavior across alerts. It’s wonderful to get alerted on the phone, yet also hear the alert spoken at specific times of day through the voice assistants around my home. Without NotiScript, this would not be possible.
Once again, an immense amount of thanks to everyone who has made this wonderful experience possible.
I thought about it and it doesn’t fit because the purpose of Throttling is to reduce the number of notifications, if I catch alert2_alert_on and alert2_alert_off events it would be the same as if Throttling didn’t exist at all.
So the ideal logic of Throttling would be that when alert2 is on and the number of messages exceeds a specified limit, the system pauses and then sends either a reminder_message if the alert is still active or a done_message if the alert has passed.
Throttling ending message would be great to get as a variable so that you can include it in your reminder_message or done_message and realize that Throttling has been triggered.
Can you describe your use case around throttling? I thought you were trying to keep a database of alert status up to date, in which case tracking events seems to make sense.
The current throttling logic will send a summary notification when throttling ends (assuming the alert isn’t snoozed or disabled or a few other conditions). What is it you want your system to know when throttling ends?
done_message is used only at the time when the alert stops firing. It doesn’t seem conceptually appropriate to send it when throttling ends because that point in time isn’t related to when the alert turned off… But I’m open to a different way of thinking about things.
Not only do I want to keep a database with up-to-date status, but I also want to reduce the number of messages to my telegram or smartphone. I mean the situation when some sensor will be triggered many times in a short period of time is quite real and I would like to have something in the config to skip messages under certain conditions, but in the end for the database I want to know that the alarm is complete.
If I’m understanding you correctly, then it seems you could use the HA Alert2 events to trigger database updates and keep your database up-to-date, and then, separately, use the normal throttle mechanism to limit notifications to telegram/phone. If that’s not what you’re looking for, can you explain your use case in more detail? like maybe lay out a sequence of alert2 events and throttling, and how you’d like your database & notifications to behave?
-J
throttle_fires_per_mins: [1, 1]
summary_notifier: telegram
notifier: notiscript_php
message: >-
{%- set alert_entity = 'alert2.more_than_' ~ entId.split('.')[1] -%}
alert2_entity={{alert_entity}};
condition_entity={{entId}};
error_text={{ state_attr(entId, 'friendly_name') | default('—') }} ({{ area_name(entId) | default('—') }}) — сейчас {{ states(entId) }}{{ unit }} (порог срабатывания больше чем:{{ value }}{{ unit }});
type=Пороги больше чем;
room={{area_name(entId)}};
done=-1;
push=1;
reminder_message: >-
{%- from 'time_delta.jinja' import format_timedelta -%}
{%- set alert_entity = 'alert2.more_than_' ~ entId.split('.')[1] -%}
error_text=🔁Значение выше порога сохраняется {{ format_timedelta(state_attr(alert_entity, 'last_on_time')) }};
alert2_entity={{alert_entity}};
done=-2;
push=1;
done_message: >-
{%- from 'time_delta.jinja' import format_timedelta -%}
{%- set alert_entity = 'alert2.more_than_' ~ entId.split('.')[1] -%}
error_text=Показатель вернулся в норму, теперь он ниже или равен порогу! {{ format_timedelta(state_attr(alert_entity, 'last_on_time')) }};
alert2_entity={{alert_entity}};
done=1;
push=1;
For example, I have a config that sends a message through the notiscript_php script that already sends a message in php to my database and just a regular message to telegram or wherever. Let’s say we have more alarms than 1 time in one minute and it turns out I can end the alarm through some automation, but if again there was an alarm in my database will not know anything about it, if you propose to keep the automation and to end and start alarm alert2, I get to transfer all the messages to these automations and essentially do the same thing twice. That is, if we have throttle_fires_per_mins, I do not know how to make my database to be up to date and not to create automations for all the beginning and end of alert2 alarms because even if I will not receive messages in Telegram, but only maintain my database I need to form a large message in the automation, at the beginning of the alarm I have many variables such as these:
Let me put it simply, yes we can end the alarm through automation, but what to do if the alarm started again during the active break caused by throttle_fires_per_mins: [1, 1] to create automation to start the alarm ? and twice write all the variables that are needed to write the alarm to the database ? I think it is very inconvenient.
I hope I didn’t hastily open a bug ticket at Generator in trigger doesn not work · Issue #12 · redstone99/hass-alert2 · GitHub…
I’m having a problem creating a generator with a trigger and entity_id.
Does dynamically setting an entity_id not work?
I want to trigger alarm only if nobody is at home and somebody opens window then…
This certainly doesn’t work:
- generator_name: window_away_opened
generator:
- { id: gaeste_wc, text: 'WC-Fenster' }
- { id: badezimmer, text: 'Fenster Bad' }
- { id: garage, text: 'Garage' }
domain: window
name: 'alert_{{ id }}_away_opened'
friendly_name: '{{ text }}'
priority: 'high'
trigger_on:
- platform: state
entity_id: 'binary_sensor.aqara_ws_{{ id }}'
to: 'on'
condition_on: "{{ is_state('group.companion_phones', 'not_home') }}"
trigger_off:
- platform: state
entity_id: 'binary_sensor.aqara_ws_{{ id }}'
to: 'off'
- platform: state
entity_id: group.companion_phones
to: 'home'
title: '{{ text }}'
message: 'ALERT | +++ GEÖFFNET +++'
reminder_message: 'WARN | Offen seit {{ on_time_str }}'
done_message: 'INFO | Geschlossen oder Zu Hause'
display_msg: 'ALERT | Fenster in Abwesenheit geöffnet'
Wouldn’t that keep your database up-to-date with respect to what alerts are firing? I didn’t understand your reference to writing things “twice”. Maybe you could give me an example? I don’t think putting structured data in the message fields is a great idea, but if you need to, another possibility might be to add a variable that indicates whether the alert is still firing or not. Then in throttle-ending message you could update your DB with the current alert state.
-Josh
