v1.5.8 fix for #171 is incomplete: same set -e pattern still aborts collector via dnf-automatic check on Debian/non-RHEL hosts

[Jayjay-sraw]

Describe the bug

v1.5.8 fixes the grep -c '^-A' abort from #171, but the collector still silently aborts on Debian-family hosts (Proxmox VE, Synology-adjacent Debian boxes, etc.) — same failure signature: most sensors go unknown, collection_error shows bash: line 1: powershell: command not found, last_collection_failed is true.

Root cause (found by reading + tracing with bash -x)

Same class of bug as #171, different line. In remote_collector.sh, read_unattended_upgrades_status:

run_limited 3 systemctl is-active --quiet dnf-automatic.timer 2>/dev/null
dnf_status=$?

[ "$dnf_status" -eq 0 ] && unattended_upgrades_active=1

dnf-automatic.timer doesn't exist on Debian-family systems, so systemctl is-active returns 3 (unknown unit). The subsequent [ "$dnf_status" -eq 0 ] test is then false, and — because this bare [ ... ] && ... is not inside an if/while guard — its own exit status (1) is what set -e sees, aborting the whole collector right there. Confirmed by tracing with bash -x remote_collector.sh on a real Proxmox VE (Debian Trixie) host: execution stops exactly at that line, before any JSON is emitted.

To Reproduce

1. Run the collector (v1.5.8) against any Debian/Ubuntu/Proxmox host (no dnf/dnf-automatic present).
2. sensor.<host>_collection_error shows the same misleading bash: line 1: powershell: command not found, sensor.<host>_last_collection_failed is true.

Fix that resolves it locally

[ "$dnf_status" -eq 0 ] && unattended_upgrades_active=1 || true

Verified end-to-end: with only this one-line change, the same script exits 0 and emits full JSON (CPU/mem/disk/etc.) on the same host that was failing before.

Suggestion

Given this is the second instance of the same "bare [ cond ] && ... under global set -e" pattern breaking non-default hosts (first firewall detection in #171, now the unattended-upgrades detector), it might be worth a quick audit of remote_collector.sh for other bare [ ... ] &&/[ ... ] ||-without-guard occurrences outside of if/while, rather than patching them one at a time as they're found.

Environment

• Home Assistant: Core 2026.8.3
• Integration version: v1.5.8 (installed via HACS)
• Operating system of the affected monitored host: Debian Trixie (Proxmox VE); also reproduced on a second Debian-family host monitored by the same integration instance

Additional context

Not filing a suggested patch PR here on purpose — just flagging what was found, same as #171.