Unavailable / Unknown Entity Monitoring - Template Sensor

Share your Projects!
178

Exactly. The example in the Feature Request uses a variable to report which input_booleans are on. Regardless of how many input_booleans are turned on/off/on, the Template Trigger fails to detect the state-changes.

I’m not so certain about that. The variable’s template would be the same one you would normally use in the Template Trigger. Here’s your example without a variable:

trigger:
  - platform: template
    value_template: "{{ states('input_number.radio_volume')|int == 0 }}"

Same template but not in the variable; overhead is the same.

As for the concern about the overhead of multiple variables, only the variable(s) used in the Template Trigger needs to be monitored for state-changes.

Anyway, short story is variables aren’t assigned listeners when used in a Template Trigger … so if you want it, please cast your vote for the Feature Request (i.e. throw a virtual coin in the fountain and hope the wish comes true). :slight_smile:

179

I used this to test a few types of entities:

- alias: Funky Template Trigger
  trigger:
    - platform: template
      value_template: "{{ states('input_number.test') }}"
  action:
    - service: persistent_notification.create
      data:
        title: Funky Stuff
        message: "{{ now().timestamp()|timestamp_local }}"

These can trigger the automation:

      value_template: "{{ states('input_number.test') }}"
      value_template: "{{ states('counter.test') }}"
      value_template: "{{ states('light.test') }}"

The first two trigger regardless of the reported numeric value. However, when using light it triggers only when state changes to on but not to off.

These do not trigger the automation:

      value_template: "{{ now() }}"
      value_template: "{{ states('sensor.time') }}"

At first I thought this behavior might be due to the fact that templates now support native types. Maybe the template’s result is (somehow) converted into a binary true/false value … but that now seems like a stretch.

Anyway, this doesn’t behave consistently nor does it comply with the documentation. You should definitely report it as an Issue in the Core repo.

180

You should slide it to and from 1 to trigger it. This is always true unless the slider is on 1…

But maybe you did that too?

181

My test with an input_number involved changing its value from 5 to 6 to 7 and then back to 5. It triggered on each state-change.

182

Done.

2 Likes
183

yeah, nice test set up, and clear for the issue in core.

maybe we should add this Use new template 'expand' functionality in automation trigger? to it, now we’re talking triggering templates, and the dust on the expand() functionality has settled down, maybe try to expand using expand in a trigger template once more…

1 Like
184

This would eliminate half my groups!

185

I don’t understand how you expect that to work.

Your example creates a list of entities in a Template Trigger. You’re expecting the Template Trigger to behave like a State Trigger. However it has never worked that way. A simple state-change is what a State Trigger considers sufficient to trigger but that’s just enough for a Template Trigger to evaluate its template (and trigger only if the computer template’s result changes).

Perhaps what you are looking for is the ability to template a State Trigger’s entity_id. The expand function would be a good fit for that.

186

That is what I was looking for :wink:

187

Well apparently we’re wrong. No explanation there that makes much sense to this blockhead, but whatevs.

image
image699×255 14 KB

188

but also this: https://github.com/home-assistant/core/pull/46423

which at least would suggest the Bug to be recognized and being worked on

189

I saw that after I commented on the git. So this behaviour was known, and known to be counter intuitive. They agree it’s a “bug” hence the “bugfix”, but at the same time is “working as intended” and “not a bug”. Cool beans. Anyway, sounds they know about and are working on it.

The behavior we’re talking about doesn’t affect me, none of my templates are structure like that. However the PR you mentioned just might!

I have an issue where for some reason or another, if any of my zwave motion sensors are dead the motion boolean is in the on state. This means on a restart, my house alarm triggers if any of those zwave nodes are dead. Problem was discovered at 4:00am burning the midnight oil playing with my config. Wife wasn’t very impressed. Problem reoccurred again a week later when the power flickered at - you guessed it - 4:00 am! Wife was even less impressed.

My “bugfix” for this was if the alarm triggers after a restart, it disarms and then rearms itself, thus saving me from my wife’s wrath. I also finally bought a UPS for the RPi.

Curious if that PR will prevent me from getting tied up by my 'nads again? :crazy_face:

190

I read the responses to your Issue and adminiuga’s reply is notable:

A non zero values are evaluated as True.

This leads me to believe that the unexpected behavior (i.e. it differs from the documentation’s description) is a side-effect of supporting native types. As long as the template generates a result that is a non-zero value, it is interpreted as True (and will trigger). That’s definitely not how it used to work as is described in the documentation which predates the introduction of native types.

It also explains why I observed that it would trigger only when a light changes state to on but not when it changed to off. The on state is equivalent to boolean True or a value of 1 whereas off is boolean False or 0.

When Frenck replied it is “the correct behavior and thus not a bug” that’s 'technically the truth` now. However, it’s not how it used to work (ostensibly prior to support for native types) because you, I, Marius and others have never known it to work like this and our Template Triggers were never written to work that way. This is new behavior.

1 Like
191

Thank you. The false if 0 else true isn’t what threw me off here. That’s a pretty common convention and honestly what I would have expected. It was the triggering on state changes to and from non-zero values.

I had basically wrapped my head around the essence of the issue after reading PR#46423 a couple times. Your reply helps solidify it for me. At least I know I’m not crazy now. The initial “that’s the way it’s supposed to be” response without further explanation really threw me off because it clearly was not the documented behaviour to my understanding.

192

I have received a few of those and it can leave one a bit frustrated. In one case, the individual confirmed they didn’t even try to replicate the bug. :man_shrugging: Anyway, that’s not the norm and most replies are helpful.

193

Where and how do you add this?
Recent migrator to HASS, I assume I copy the package_unavailable_entities.yaml to the config folder and then reference it in configuration.yaml somehow?

I’s like to implement it as I have random disconnects on some Tasmota devices which I think is related to my WiFi but need to track them.

194

You can either copy the code from the gist and place it in your configuration.yaml or add it as a package. I recommend using the package method.

  1. Create a folder named “packages” in your config directory.
  2. Add this to the homeassistant section of your configuration.yaml
homeassistant:
  packages: !include_dir_named packages
  1. Create a new file named package_unavailable_entities.yaml in this directory.
  2. Copy the RAW contents from the gist file into your new file. Save it.
  3. Add any entities you want to ignore to the group section in your new file.
group:
  ignored_entities:
    entities:
      - binary_sensor.updater
      - sensor.temperature  etc.  etc.
  1. Restart HA.

You should be good to go!

There are some pretty good hints in the gist comments.

2 Likes
195

Thanks got it up and running in seconds.
“Packages” is another thing I have to learn about now :slight_smile:

196

Thanks, exactly what I was looking for. Great job.
Is there any way to ignore all entities of a certain type? Etc media_player.?

197

Add the domains you wish to ignore to the filter which excludes groups.

Change this

|rejectattr('domain','eq','group')

to

|rejectattr('domain','in',['group','media_player'])