I’ve got around 30 things on my LAN now — cameras, plugs, a couple of ESPHome boards, the TV, the vacuum. Most of them I didn’t really choose; they came bundled with something else.
Two things I keep running into:
a sensor stops responding and I only find out days later, when an automation quietly stops firing
something opens a port it didn’t have open before, and nothing anywhere tells me
My router notifies me when a new device joins, and that’s it — it keeps no history, so anything that changes after that first join is invisible to me.
I know about the ping and nmap tracker integrations — what I’m really after is whether anyone keeps any history of this, rather than just a sensor that flips to “away”.
So I’m curious how the rest of you handle this:
Do you track it with something (and if so, what?), or do you just find out when something breaks?
Is “this device has been quiet for three days” something you’d actually want to be told about, or would it just become noise you mute after a week?
I ask because I’ve been building something small on a Pi to keep an inventory of all of it, and before I sink more evenings into it I’d like to know whether I’m solving a problem only I have. Happy to be told it’s already solved.
I have a vibration sensor that I use to detect if my AC is stuck on when it shouldn’t be.
However that sensor eats batteries (about every 5-6 weeks).
- binary_sensor:
- name: "Invalid Run Dining AC"
unique_id: invalid_run_dining_ac
device_class: power
delay_on:
minutes: 1
state: >
{{
is_state('binary_sensor.dining_ac_vibration', 'on') and
is_state('input_select.front_ac_active', 'Off') and
30 > (now() - states.sensor.dining_ac_y_axis.last_updated).total_seconds()
}}
Hence the three conditions are:
Is the AC actually running - there is vibration.
Is is meant to be running - more specifically is it meant to be Off.
Have I received the update from the sensor in the last 30 seconds.
There is also a delay_on to prevent false positives from something knocking the sensor.
Anyway the point of this is to prevent false positives because the battery died while the AC was running - hence the sensor keeps reporting the AC as running.
TL;DR - If you have a pattern where you should see activity over some period of time, you can use the last_updated to see if you have received an update - effectively it acts as a heartbeat that the sensor is still alive.
For something like a door or presence sensor you would probably expect to see activity at least once per day, hence it may take a bit of time before you notice the problem, but its better than nothing.
PS I don’t use battery level because there is always a period where the battery reports low (even 0%) and the device is still working.
Although originally conceived as a way to track entities or integrations that you might have changed or no longer feature in your setup, the custom Watchman integration also creates diagnostic sensors which will give you a live update of the number of entities that have gone unknown or unavailable.
I have them on one of my dashboards which I check periodically to see if anything is missing. You can exclude or include specific entities.
You could even automate that by using a state or attribute change in one of the diagnostic sensors as an automation trigger to send you notifications.
I create binary sensors for every device that tells me whether it’s online and working. When it’s not I get a telegram message. The way you do this depends on the integration. It’s essential in my view.
I’m using uptime kuma for tracing devices for years know.
It is all around monitoring tool so you can track your zigbee devices and wifi devices in one place.
It also support notification.
I use NetAlertX App on alexbelgium’s repo for Wi-Fi device monitoring with a HA webhook that parses new device activity, device disconnects, and device reconnects using a choose block automation and sends me a mobile notification.
For zigbee, specifically for zigbee2mqtt, I use a template on sensor.z2m_devices_offline and if it evaluates to true it’ll send me a mobile notification of which device/s are offline.
This integration brings interesting features; one of them is “Sentinel,” which regularly checks HA states. Thanks to this, we don’t need to create various automations to get notified when something is wrong.
I have started using the Device Sentinel HACS integration. It’s a fairly new tool, and is in active development right now. It does some pretty cool things, like figuring out the normal “rhythm” of a device – how long is it “normal” for this thing not to be reporting? Or is it frozen / stuck, and still just reporting its last known value? Some devices only check in a couple times a day, and it’s normal to have same reading for long time. On other devices, it’s good to be notified right away when they’re frozen.
The tool also does some other cool stuff around keeping track of connectivity strength (Wi-Fi, Zigbee, Z-Wave, …), to know when things drop off, and when they seem to be having trouble maintaining connectivity. Similarly, it keeps track of battery health --some battery types show declining voltages over time; some show “full” most of their life, then abruptly drop off near the end.
And besides its notifications and its dashboard, it does keep history of these events: daily summary, weekly summary, 30-day summary, a “to-do” list for items that need to be addressed, etc.
Also take a look at Spook. In a recent release Frenk has added tools to do exactly what you are looking for. In the docs, under ‘other features’ look at entity_came_back and entity_fell_silent.
Spook has become a very useful tool for those who are looking for a more detailed notification of devices, sensor and other things that occur ‘under the covers’.
I don’t think it has anything for your ports, but there are lots of port tools that might be worth a look. Most run in a Docker container, so you’d need the basic skills for that, but honestly, it isn’t all that hard if you can follow along with clear directions. Check out https://mariushosting.com/ for lots of info.
I have an automation that runs once a minute and creates a persistent notification with the list of devices or entities that are unavailable. If I don’t want a device or entity in the list, I can label it with ignore_unavailable and it’s filtered out of the list. As things go back online, they’re automatically removed from the notification list, so it’s easy to treat it as a “todo” list.
It’s heavily cribbed from someone else in this forum
alias: Unavailable Entities
description: ''
triggers:
- seconds: '0'
trigger: time_pattern
conditions: []
actions:
- variables:
ignore_seconds: 60
ignored_label: ignore_unavailable
ignored_domains:
- button
- conversation
- event
- group
- input_button
- input_text
- scene
- update
entities: >
{# Build the ignored list #}
{% set ignored = namespace(list=[]) %}
{% set ignored.list = label_entities(ignored_label) | list %}
{% for device in label_devices(ignored_label) %}
{% set ignored.list = ignored.list + device_entities(device) %}
{% endfor %}
{% for area in label_areas(ignored_label) %}
{% set ignored.list = ignored.list + area_entities(area) %}
{% for device in area_devices(area) %}
{% set ignored.list = ignored.list + device_entities(device) %}
{% endfor %}
{% endfor %}
{% set ignored = ignored.list | unique | list %}
{% set ignore_ts = (now().timestamp() - ignore_seconds) | as_datetime %}
{# Filtered unavailable entities (same rules as before) #}
{% set unavailable = states
| rejectattr('domain', 'in', ignored_domains)
| rejectattr('last_changed', 'ge', ignore_ts)
| rejectattr('entity_id', 'in', ignored)
| map(attribute='entity_id')
| reject('has_value')
| list %}
{% set result = namespace(lines=[]) %}
{% set handled = namespace(entities=[]) %}
{# Fully unavailable devices → one linked line each #}
{% set device_ids = unavailable | map('device_id') | reject('none') |
unique | list %}
{% for did in device_ids | sort %}
{% set relevant = namespace(list=[]) %}
{% for eid in device_entities(did) %}
{% if eid.split('.')[0] not in ignored_domains and eid not in ignored %}
{% set relevant.list = relevant.list + [eid] %}
{% endif %}
{% endfor %}
{% set relevant = relevant.list %}
{# All relevant entities unavailable long enough #}
{% if relevant
and (relevant | reject('has_value') | list | count) == (relevant | count)
and (relevant | select('in', unavailable) | list | count) == (relevant | count)
%}
{% set name = device_attr(did, 'name_by_user') or device_attr(did, 'name') or did %}
{% set result.lines = result.lines + [
'[' ~ name ~ '](/config/devices/device/' ~ did ~ ')'
] %}
{% set handled.entities = handled.entities + relevant %}
{% endif %}
{% endfor %}
{# Partial / no-device leftovers #}
{% for eid in unavailable | sort %}
{% if eid not in handled.entities %}
{% set did = device_id(eid) %}
{% if did %}
{% set name = device_attr(did, 'name_by_user') or device_attr(did, 'name') or did %}
{% set result.lines = result.lines + [
eid ~ ' ([' ~ name ~ '](/config/devices/device/' ~ did ~ '))'
] %}
{% else %}
{% set result.lines = result.lines + [eid] %}
{% endif %}
{% endif %}
{% endfor %}
{{ result.lines | join('\n') }}
- if:
- condition: template
value_template: '{{ entities | count > 0 }}'
then:
- action: persistent_notification.create
metadata: {}
data:
notification_id: unavailable_entities
title: Unavailable Entities
message: '{{ entities }}'
else:
- action: persistent_notification.dismiss
metadata: {}
data:
notification_id: unavailable_entities
mode: single
Thank you all — this is a far better set of answers than I expected, and it has
already changed what I thought I was doing.
Summarising for whoever lands here later: Watchman and Spook (entity_fell_silent /
entity_came_back), Device Sentinel and Device Pulse, Uptime Kuma, NetAlertX as an
add-on, plus several home-grown automations on unavailable. @tim.plas — the
“work out the normal rhythm for this device, and tell frozen apart from silent”
idea in Device Sentinel is roughly the thing I was about to build badly. Good to
know it already exists. And @tmjpugh , fair point on UPnP, that one’s on me.
One follow-up, because it’s the only thing I didn’t see mentioned: everything
above watches things that are already in Home Assistant. Does anything you use
tell you about something on the LAN that isn’t in HA at all — the guest’s
phone, a camera you never integrated, a plug that only talks to its own cloud?
Or is that simply not something you worry about?
Since @tim.plas mentioned Device Sentinel, which I’m writing, I’d like to answer @max2055’s question. Take my answer with that in mind.
No, Device Sentinel doesn’t see anything outside of Home Assistant. It watches devices inside HA and learns how often each one normally reports. It tells you when one goes quiet for longer than its own rhythm, becomes unavailable, its battery is low or falling, or has a bad or failing signal.
A guest’s phone or a cloud-only plug is invisible. For those, something that scans the LAN, like NetAlertX from your list, may be the right tool.
The integration is in testing on a handful of houses at the moment, Tim’s among them. I’ll post properly once it’s in the HACS default list. In the meantime, he linked the repository above for anyone curious. PM me if you have questions or would like to help test it in your home.
I did try out Device Sentinel and while the information you can get from it seems absolutely fantastic ---- it did crash my system 3 times in the space of 2h.
HA became completely unresponsive the first time around and I had to shut down the server completely to get it back to working conditions.
On the second and third attempt, it slowed everything down to a crawl.
I then de-installed Device Sentinal - everything went back to normal.
Not sure what exactly the problem area was - on the 3rd attempt, I tried to access my Eufy Cameras, but that could have been a coincidence.
I know it is anecdotal and I did not have the time or appetite to investigate and/or collect data, so this is just a heads-up if someone experiences the same issues.
And before anyone says - well maybe you have a shady HA setup.
My HA has been running with 100% availability for the last 12 months or so .
Not a single problem in that time frame.
That’s close to my Approach, HA has various ways of autodetect devices, some pops up in integrations-page(add them or ignore them), other which are not autodetected(add them manually, if possible, or Ignore them)
Make i.e templates for those you find vital to be notified about if they go “off-line”
As for i.e WIFI/Ethernet device, if your Router-Integration don’t provide you with the information you need ( then have a look in /Settings/System/Network>>>scroll down to “DHCP Browser”
Uses i.e card’s such as auto-entities (for Device/Entities You have Installed)
A Decent Router Integration should be able to “serve” your needs for the IP-Devices purposes , via i.e device-trackers (regardless if the Device is Added)
You can also create “legacy-groups” for your IP Device ( list “known” , “Wired” “WIFI” , “Unknown/Guests”, 2.4gHz, 5.0gHz etc. etc. (check the Attributes of a Device_tracker) , And have “Notifications” in either a “Count or Warnings” on dashboard, or send to your phone etc. etc.
So all above “Solutions” is still a fraction of what the imagination can count of options in HA
