Make an input boolean helper and make that part of the condition.
There’s no such property (attribute) that I’m aware of. You can make an input text helper and use that in your alert as the message and anywhere else you’d like to. Am I following you now?
@Some-dude, notifications for an Alert2 entity can be disabled, if that’s what you’re looking for. Click on the entity (eg in the Alert2 Overview card) and there will be an option next to snooze to disable notifications.
@hobex46, it sounds like you’re trying to display an Alert2 alert, including the display_msg, on a remote device, is that right?
Alert2 communicates display_msg to the HA frontend using essentially a web socket, and bypasses the HA machinery around states. The reason was so that you could show a frequently-changing value without slowing down the rest of HA / UI.
There currently isn’t any easy way to access display_msg yourself. If you’re running your own JS from with an HA UI, you could open a websocket and do the same thing Alert2 js code does. And you could certainly move the display_msg to a template sensor as @parautenbach suggests and then access is much easier.
Another option is to change Alert2 to make it easier to access display_msg.
Can you describe more what you want to see on your Geek Magic?
Josh
Yes, correct. Currently, this is more for playing around.
I made it render - sorted by a priority- lines of text. Each line has a left and right aligned field. There is a automation in home assistant that runs whenever alert 2 fires, or every 10 minutes. I filter for those “on” or those that are off, not acknowledged but should be. There is prio 0 level, for “fun info” (e.g. solar power), so the display is not empty. (Also also have a flex-table card to render the same content on my dashboard) See photos here
I also wanted to keep the system as easy as possible. So I only wanted to have to change the alert 2 config to get everything done and consistent. Another set of template sensor for each alert is error prone…
My original idea was this
Other idea: Make Alert 2 give the things a friendly name like Battery Low __ 10% and the
But changing the friendly name so often is probably a bad idea.
As I run a automation anyway - a action alert2.get_display_msg with target the respective alert 2 could do the job for me. I would then only query the display message for those few alerts showing and not so frequent either. At this point, I’m more playing around, so don’t implement stuff making things more complicated for you.
Ah, I took a look at your ultra-smart-01.yaml in that link. So in HA (via an automation I presume) you’re generating a json blob with a bunch of state in it, publishing via mqtt, then your embedded device (running ESPHome I think) subscribes, gets the blob and formats it for your display. Right?
I’m totally open to adding an interface to get display_msg. I’m wondering if there are other fields worth exposing as well. I could add a alert2.get_alert_json that dumps the entire internal alert state as json, though that may be a lot of info.
Maybe I’ll add an alert2.get_alert_json that for now just exposes display_msg but to which we can add other fields later.
EDIT: Actually, I’m not sure exporting as json is a great idea for generality (eg if you don’t want json). Maybe I’ll just stick with get_display_msg and keep it simple for now.
-Josh
Yes, thats right. My esp home code accepts [{prio: <>, name: <>, msg:<>}, ...] to then show this on the two displays I run and on the flex table. To make the flex table work -I needs a MQTT sensor that receives the sent message back. Thats less efficient, compared to the alrt2 UI, of course, but consistent with the esphome display
{# prios 4= High, 3=Medium, 2=Low, 1=Task, 0 = Info #}
{%set ns = namespace(payload=[]) %}
{%set items = states| selectattr("domain",'search','alert2')|
selectattr("attributes.ack_required",'search','True')|
selectattr("attributes.is_acked",'search','False')|list%}
{% for i in items%}{% set ns.payload = ns.payload + [{
'name': i.name,
'msg': 'neu',
'prio': 4}]%}
{% endfor %}
{%set items = states| selectattr("domain",'search','alert2')|
selectattr("state",'search','on')|
selectattr("attributes.is_acked",'search','False')|list%}
{% for i in items%}{% set ns.payload = ns.payload + [{
'name': i.name,
'msg': '',
'prio': i.attributes.priority|replace("high",4)|replace("medium",3)|replace("low",2)|int}]%}
{% endfor %}
{%set items = expand(
device_entities('783f72177aeb0ec8601f3a64f8dd99e7'))|
selectattr("state",'search','on')|list%}
{% for i in items%}{% set ns.payload = ns.payload + [{
'name': i.attributes.friendly_name,
'msg': '',
'prio': 1}]%}
{% endfor %}
{% if state_attr('sensor.waste_rest','daysTo')|float(10)<=3 %}
{% set ns.payload = ns.payload + [{'name': states('sensor.waste_rest'),'msg':state_attr('sensor.waste_rest','daysTo')|string+" T",'prio':0}]%}
{% endif %}
{%- set dt = (states('sensor.kamin_temperatur_temp_object_change')|float(0))/4-%}
{% if dt >0 %}{%- set dt =min( dt+0.5 ,3) |round %}{%set dt_a = "+"*dt%}{%- else -%}
{% if dt <0 %}{%- set dt =min(-(dt-0.5),3)|round %}{%set dt_a = "-"*dt%}
{%- else -%} {%set dt_a = "="%}{%- endif -%}{%- endif -%}
{% set ns.payload = ns.payload + [{'name': 'Kamin','msg':"dt "+dt_a+" | "+states('sensor.kamin_temperatur_temp_object', with_unit=True) ,'prio':0}]%}
{% if states('sun.sun')=='above_horizon' %}
{% set ns.payload = ns.payload + [{'name': 'Solar','msg':states('sensor.solar_power',with_unit=True),'prio':0}]%}
{% endif %}
{% set ns.payload = ns.payload + [{'name': 'Gas','msg':states('sensor.gasverbrauch_sum_24h',with_unit=True),'prio':0}]%}
{% set ns.payload = ns.payload|sort(attribute='prio',reverse=True) %}
{{ns.payload[:10]|tojson}}
type: custom:flex-table-card
entities:
include: sensor.homestatus_data
columns:
- data: data.prio
- data: data.name
- data: data.msg
css:
thead: display:none;
tbody tr:nth-child(even): "background-color: #a2542f6;"
td: "min-height: 20px"
alternatively i played with this flex card, just for the fun
type: custom:auto-entities
filter:
include:
- options: {}
entity_id: alert2.*
state: "on"
attributes:
is_acked: false
- options: {}
entity_id: alert2.*
state: "off"
attributes:
is_acked: false
ack_required: true
show_empty: true
card:
type: custom:flex-table-card
sort_by:
- is_acked-
- priority-
columns:
- data: priority
hidden: true
modify: if(x=="low"){"2"}else{if(x=="medium"){"3"}else{"4"}}
- data: friendly_name
align: right
name: Alert
tap_action:
action: more-info
- data: state
modify: if(x=="on"){"aktiv"}else{"inaktiv"}
- data: is_acked
name: gesehen
align: right
modify: if (x) {"Bestätigt"}else{"unbestätigt"}
hold_action:
action: perform-action
perform_action: alert2.ack
css:
thead: display:none;
tbody tr:nth-child(even): "background-color: #a2542f6;"
td: "min-height: 20px"
mqtt:
sensor:
- name: "homestatus_data"
state_topic: "homestatus/display/rawdata"
value_template: '{{value_json|count}}'
json_attributes_topic: "homestatus/display/rawdata"
json_attributes_template: "{{ {'data': value_json} |tojson}}"
Hi All,
I just released Alert2 v1.18 and Alert2 UI.
name using umlautes (eg ä, ö, ü) and the other doesn’t. So now you should be able to rely on an alert producing the entity_id you expect, without a _2 or _3 appended to it.notifier: notify.telegram_bot_xxx_yyy. Notifications are sent to them using notify.send_message. NOTE that notify.send_message currently only supports the message and title fields. You can’t yet set e.g. a data field using notify entities.reminder_message can now access a function, get_message() that renders the message field. This is useful if you want to set your reminder message to contain the original message without duplicating config code.alert2.get_display_msg action to on-demand render an entity’s display_msg field.reminder_message.@hobex46 , give the alert2.get_display_msg() action a whirl and let me know how it goes.
-Josh
works perfectly thanks
I have discovered that when I set a repeat interval to an empty list, on any alert, that alert fires, but then its state immediately goes back to off.
I spent a good half an hour evaluating the templates that I was using to activate the alerts, and they were all coming on, but the alerts themselves were off.
Then I remember that I set them to not repeat themselves so they would stop annoying me every day about things that I had planned not to do anything about, a repeat which I think by default is every day or so. I did this by setting the repeat interval to an empty list.
Lo and behold, instead of just influencing how often they repeat their announcements, instead what they do is they make them fire and immediately stop firing. What’s worse is that the activity list does not show the alert firing, even though I can see it firing because it is calling the alert script I had configured for it to send me alerts.
Anyway, I think the configuration setting is not meant to do that, or at least not meant to have that side effect. And if that could be fixed, that would be great. If this is not a bug, then it should be clearly documented that setting an empty repeat list for repeat intervals causes the alert to fire and immediately go back to off, with no evidence of that event being shown in the activity list.
Hi @Rudd-O - bug confirmed. Specifying an empty list causes the code to throw an exception and partially abandon the state update, leading to that weird UI behavior. Fix coming. For the moment, you could specify a very long reminder frequency as a work-around.
-Josh
I just released v1.18.1 which fixes the issue when reminder_frequency_mins is the empty list and one other issue. And updated the docs.
-Josh
At what time(s) will this template be evaluated? Was thinking about making the window open alert time GUI-configurable for non-techy users - with a slider on the dashboard modifying an input_number.
I created the generator with the input_number being 600, then changed it to 60, and having a window open, no alert happened after 60s 
So I guess delay_on_secs is not “monitoring” the template? Or should it, and I’m doing something else wrong?
Hi, delay_on_secs at present is only evaluated when the generator creates the alert, not in an ongoing way. I think it probably makes sense to change that so it’s treated like any other template and monitored continuously. Will look into it.
J
Hi All,
I just released v1.18.2:
delay_on_secs can now take a template and the template is monitored continuously. (It used to be that a template could be passed only when used with a generator, and the template was evaluated only when the alert was created by the generator)alert2.toggle_ack to toggle the ack status of an alert.@SyndromeCower - give it a whirl and let me know if it doesn’t work for you.
-J
Awesome! Working just as I was hoping. You made that improvement faster than I could open a window to test it 
Hi All,
I just released Alert2 v1.18.3 and UI.
generator_name is now optional. If not specified, no entity for the generator itself will be created.exception_ignore_regexes allows you to not send notifications for exceptions that happen if the exception + stack trace matches any of the regexes specified. Intended to suppress notifications due to known faulty components. Only allowed for alert global_exception spec and any alert with name=“unhandled_exception” (intended for use by people writing components and using alert2 create_task)Hi,
I just release Alert2 v1.19 v1.19.1 and UI.
This alert fixes bugs and changes the way UI alert edit operations work. Previously, in the “Alert Manager” UI, if you click on an alert and then click “Delete”, it would delete the UI alert with the matching domain/name. Now, each UI alert entry has a unique uiId, and it is the uiId that is used for matching. The uiId persists for the entry even if you change the domain/name and click “Update” or “Delete”. This change cleans up the logic a bit, particularly around managing anonymous generators.
This change involves an Alert2 internal database migration for UI alerts, which happens automatically.
EDIT: As a reminder, you can click on the “Alerts” header of the Alert2 Overview card to see if your browser has updated to the new 1.19 version of Alert2.
friendly_name works to rely less on unstable internal HA interfaces.domain or name parameter.-Josh
Hi @redstone99 I’m seeing in my global exception alert, alerts like this: “unhandled_exception: ‘ConditionAlert’ object has no attribute ‘threshold_exceeded’”. I’m not sure if that error message can be enhanced to provide which ConditionAlert (and to augment other exceptions as needed) is having the problem to track down the issue? I looked in the logs and can’t find much more than that same text.
Hi @tman98,
Is there any stack trace in the logs? And are you running v1.19.1 ?
I took a quick peek at the code and didn’t see any obvious bugs, but clearly something’s going on.
-Josh
@redstone99 Would you be open to work on (or accept a PR) to add another level “info” (aside low medium high) to priority? (Or make it possible to enter a float (and map like “low if floor (prio==1)”, “medium if floor (prio==2)”)?
My case is e.g. for a window. If open then this is just a info, if it’s open for longer than 10 minutes it is low, if it rains medium and high if the water sensor fires.
Hi @hobex46 - I’m open to expanding priority, whether via PR or otherwise.
So I can understand your use case, are you thinking of utilizing the “supersedes” option? Also, what effect do you want higher/lower priorities to have? At the moment, I think it just affects the UI Alert Overview card - the sorting of alerts and color of the badge next to each alert.
We could add a single extra category like “info”. Or I could imagine supporting a priority that is a float / integer, though in that case we’d have to figure out a mapping to color in the UI.
-Josh