How to make a door sensor presentation... better?

[tidal badge]

This is a simple battery-powered door sensor, the short log gets spammed because it is shown as unavailable now-and then when inactive. I see that yellow is open, gray is closed, and the only issue is really to relax the logging of unavialiable.

[thick sentinel]

"what integration?" is the key question.

[tidal badge]

Zigbee2MQTT

it seems to repeat with a period of 4hrs unless active. the sensor has an option to report luminance every 60min , but It does not seem to do anything

[thick sentinel]

Seems like you have set passive availability to 2hr. Go to Z2M dasboard => Settings => Availability. Or disable it all together or under Passive set a more reasonable amount like 8hr.

Hole issue is, Zigbee has no option for availability and can´t poll a battery device. So it can only assume unavailable if there has been no reaction. But if you set that assume time lower then the actual normal response time it will time out and thus render unavailable.

[tidal badge]

@thick sentinel Thank you, I increased the timout. I see you say "or disable it all together" which seems to be the default. - how does people then monitor battery devices if that is disabled? is there some other thing one could read to detect not change, but still know if a sensor had no new output for a day, but is still "alive"?

[thick sentinel]

Honestly, I just replace the battery when I notice it not working 😅 Not very advanced or great tactic but works for me. But yeah, you can tweak the timeout but it really depends on which devices you have

In yaml it's possible to specify availability and timeout per device but seems this isn't available in the UI

[tidal badge]

The problem is that some things are inconvenient to discover that way: temperature sensor that dies would make the output side of a thermostat setup be always on / always off, and a dead door sensor in the garage would be discovered by light not turning on. (that's why I like to monitor the sensors)

[thick sentinel]

Yeah, don't say it's ideal 😋

But know the limitation that availability for Zigbee battery devices is just a work around. And the timeout need to be larger then the largest interval a sensor might need. That's why the default is 25hr. But you can go lower and just use the device yaml if only a single device has a very large interval for example.

[indigo sequoia]

I just wanted to drop my two cents on how I monitor entities. This may not work for you, though, if your entities are frequently going unavailable for no real reason. My method consists of four parts: entities labeled to be monitored, a template sensor that watches the entities to be monitored, an automation, and a dashboard card. This method, IMO, requires minimal upkeep and it is easy to add or remove monitored entities.

Part 1: Label your entities

Part 2: A configuration template sensor added to your configuration.yaml ```yaml
template:

• trigger:
  • platform: time_pattern
    minutes: "/5"
    variables:
    unavailable_entities: |
    {{ label_entities('Monitored') | expand() | selectattr('state' , 'in' , ['unavailable','unknown']) | sort(attribute='name') | map(attribute='name') | list }}
    unavailable_entity_count: |
    {{ unavailable_entities | count }}
    unavailable_entity_list: |
    {{ unavailable_entities | join(', ') }}
    sensor:
  • name: Unavailable Monitored Entities
    unique_id: 6fa6ca0b-0c4e-49e5-b95b-c4f3a28719fb
    state: "{{ unavailable_entity_count }}"
    attributes:
    monitored_entities_count: |
    {{ label_entities('Monitored') | expand() | map(attribute='name') | list | count }}
    unavailable: |
    {% if unavailable_entity_count | int > 0 %} {{ unavailable_entity_list }} {% else %} No unavailable entities {% endif %}
    previous_state: |
    {% if this.last_changed == this.last_updated and this.state == this.attributes.previous_state %} {{ this.state }} {% else %} {{ this.attributes.previous_state }} {% endif %}
    previous_unavailable: |
    {% if this.last_changed == this.last_updated and this.state == this.attributes.previous_state %} {{ this.attributes.unavailable }} {% else %} {{ this.attributes.previous_unavailable }} {% endif %}

Part 3: The automation. It's too long to post here but I can break it up if you need to see the whole thing. Basically, when the sensor.unavailable_monitored_entities changes not_to: "0" send a notification that there's a problem. The not_to part is important because it allows for subsequent notifications is something else goes unavailable later. (The previous attributes are going to be used to determine what has started working again by comparing the two states, but, like I mentioned, this doesn't work yet.) There's a trigger for state change to: "0" which sends an "All is good now" notification. A third trigger fires every day at 6am, just because. Here's the problem notification which will tell what entity is unavailable from the template sensor. ```yaml

• action: notify.mobile_app_s25_ultra
  data:
  title: >
  <b><span style="color: red">Unavailable Monitored
  Entities</span></b>
  message: >
  {{states.sensor.unavailable_monitored_entities.attributes.unavailable
  }} is not responding.
  data:
  color: "#2DF56D"
  timeout: 3600

The final part is a simple Markdown card on my dashboard. ```yaml
type: markdown
content: |
{% set e = "sensor.unavailable_monitored_entities" %}
{% if states(e) | int == 0 %}
<center><font size=5 color="green">All Good!</center>
{% else %}
<center><font size=5 color="red">Unavailable: {{ state_attr(e, "unavailable") }}
{% endif %}