Automation: trigger: In 'numeric_state' condition: no entity specified

Configuration
1

Hi,

I have a very simple sensor that has as a state the days until the SSL cert expires. On that I have an automation that should send out a notification when the value drops below a certain value.

When parsing/reloading the sensor config I get the following error message in my logs:

image
image1338×568 69.1 KB

It is weird that I get the automation error when reloading the COMMAND LINE ENTITIES and not when reloading the AUTOMATIONS under Server Controls.

My config looks like this:

Sensor:

- platform: command_line
  name: SSL cert expiry
  unit_of_measurement: days
  scan_interval: 10800
  command: "/ssl/ssl-cert-check -b -c /ssl/fullchain.pem | awk '{ print $NF }'"
  value_template: "{{ value }}"

Automation:

- alias: Try refreshing SSL certs
  id: refresh-certs-79378917-95c5-45ba-88a7-0ae30e7f743b
  trigger:
    - platform: numeric_state
      entity_id: sensor.ssl_cert_expiry
      below: 90
  action:
    - service: hassio.addon_start
      data:
        addon: core_letsencrypt
  mode: single

Most of the code was just slightly adapted from snippets online, but I compared with the docs and it looks good to me.

The sensor entity show up fine in Developer Tools - States

I found a similar (just slightly more complex) problem, but that was never solved : Warning; numeric_state condition: no entity specified

Any ideas what I could try or change to get this working?

2

But is it actually working?

Because it happens when you reload the command_line sensors it sounds a bit like the sensor disappears from HA for a moment when it reloads. But it that only happens on a reload I would just ignore it.

3

Unfortunately it is not working.
The trigger is below: 90 and the current state of the entity is 80 but it has never triggered.

4

if the state was already below 90 when you created the automation it won’t trigger the automation because the state has to transition from above 90 to below 90.

to test it you should change the below value to something less that 80 (the current value you report) and see if it triggers when it gets below that value.

1 Like
5

And if it does not work when it does fall below, can you check the history of the sensor? If the sensor goes 90 → unavailable → 89 it will probably miss it as well.

1 Like
6

Oh thanks. I will check this out. I assumed “change” meant it will check the trigger every time the state value changed. Not that it actually has to cross the threshold. I will set the value now to 100 via developer controls and then within 3 hours the sensor value should update.
I’ll report back.

7

@finity That was it. I changed it the state value via Developer tools above the threshold and then reloaded the sensor via YAML configuration reloading and it worked. The automation triggered and I got my notification.

@septillion Is onto something as well, since I not only got my notification but also the error message again. So I assume it went through unavailable during the reload of the YAML.

When I look at the history of the entity I only see a graph, so it is hard to see times of when it went through unavailable, but it seems to only pass through unavailable when reloading YAML by hand and not during “normal operations”. (super tiny gap in the graph when I reloaded, but I can’t see that gap every 3 hours when the sensor refreshes).

Is there a way to force the numeric history

image
image800×708 25.3 KB

into a “textual” history that I can see timestamps when things changed?
image
image800×980 49.3 KB

The logbook has no entry for this entity (even for longer time periods)

image
image1810×364 23.1 KB

(besides looking into the SQL database)

8

Not super easy to do but when you hoover over it, it will draw a dot for the update. If you also make a graph of just 3 hours instead of 24 you might be able to spot possible unavailable states.

You could also try to make an automation that makes a persistent notification which includes the state and trigger that when the state isn’t a number.

Although having said that, the error looks more like the sensor is temporarily removed from HA when it’s reloaded which seems like a bug to me.

9

Yeah that I did. Then I saw that there was a gap in the graph.

10

You’re not the first person to make that assumption (and not the last). I have seen, and helped, numerous users understand how the Numeric State Trigger works. I am now convinced they either aren’t reading its documentation or don’t comprehend the meaning of its very first line:

Fires when the numeric value of an entity’s state (or attribute’s value if using the attribute property) crosses a given threshold.

What do you suggest the documentation say to make it clearer that it only triggers when crossing the threshold and not the way you assumed it would work?

11

I think it is a mix of both your suggestions and also I give you a 3rd option:
They are new to HA and read like 100 pages of documentation and are a bit swamped in information. I definitely remember being on that page and reading the “NOTE” box below it. When starting out there is so much to learn/read that not everything can be 100 % parsed correctly. I think I went back to the page when my automation didn’t work, but then I definitely didn’t read again the first paragraph.

It is a lot of text and 1 single word “crosses” needs to be read, parsed and stored correctly. This is very hard to achieve when starting something new.

So my suggestion would be to put it into a NOTE or INFORMATION/CAVEAT box. And maybe have a 2nd sentence that just points to the importance of the meaning of crosses and give an example. The example that is actually in the NOTE below I remember reading and thinking “Yeah… that is how I expect above/below to behave”. So I feel it would make more sense for an example of the threshold than of the normal language behavior of above/below.

12

So your suggestion is to add more text? :wink:

The issue is that users appear to be misunderstanding, or ignoring, the significance of the word “crosses”. However, if you feel further clarification would help everyone then you are free to add it to the documentation. Anyone with a GitHub account can submit corrections/improvements. Your submission will be vetted by the development team.

13
14

Thing is, most people starting out just don’t get the difference between a trigger (a single event with no duration) and a condition (a state that can be true for some time). Keeping that in mind for a trigger the “crosses”-part is just logical.

I’m not sure how you could write that more clearly then it is now. Any idea on that as well?