Changelog¶

Every release of HASS.Agent .NET10, newest first. The downloads are on the releases page.

10.10.1¶

Hotfix: who may use the settings, on a PC joined to a domain. Works with the Home Assistant integration 10.6.7 or newer. Signed release.

Fixed: on a domain-joined PC, administrators were reported as users who are not. After the update to 10.10.0 Home Assistant could get a notice that the settings are open to users who are not administrators, naming the PC's own local Administrator and domain users who are administrators. The app told the local profiles from the domain ones by the PC's own SID, and on a PC with no enabled local account, as many domain-joined PCs are, it could not find that SID and took every profile for a domain one. It now asks Windows for it directly. A user from a domain is also checked for membership of the PC's Administrators group, by their own account or through a domain group such as Domain Admins, instead of counting as not known to be an administrator; on a PC where everyone is an administrator there is no notice, and the update limits the settings to them as on any other PC. The notice no longer calls a user it does not know about "not an administrator". Reported in #119.

10.10.0¶

A feature release: a system health pack of sensors, fast sensors down to 1 second and a polling profile of your own per sensor, a Media player page with announcements that are heard, a name of your own above the notifications, a security round with its recheck, and a handful of fixes. Works with the Home Assistant integration 10.6.7 or newer; the announcements, the Drive health sensor, the device classes of custom sensors and the move of the two renamed sensor keys need the integration 10.10.0, out at the same time (an older integration keeps the renamed sensors by their old keys). Signed release.

Sensors

Drive health, a new built-in sensor from the Windows service: Windows' own verdict on the drives from their SMART data (healthy, warning, unhealthy, the worst of them as the value), with every drive in the attributes (drives[N].name, health, temperature, temperature_max, power_on_hours, bus, media) and the system drive's temperature as temperature, one attribute sensor away from a °C entity. NVMe drives report the temperature and its highest value, a SATA drive the temperature and the power-on hours when its controller passes them on, USB enclosures nothing; a field a drive does not report is left out. Service only, since reading it needs administrator rights. Needs the integration 10.10.0 or newer. Requested in #107.
Fast sensors down to 1 second. The fast interval goes to 5 seconds on the Capabilities page (10 stays the default); the Fast sensors below 5 seconds switch on the Danger Zone page unlocks 1–4 seconds, with a note on what that means for the traffic and for Home Assistant's recorder, which writes a row at every change: a sensor you want every second but not in the history goes on the recorder's exclude list. Requested in #108.
The polling profile of a built-in sensor is yours to choose: fast, normal or hourly in the Profile column of the Sensors page (GPU usage on fast, CPU usage on normal, whatever suits the PC); push-driven and startup sensors keep theirs. The three intervals stay global, the choice is which one a sensor follows. A custom attribute sensor on a faster profile refreshes the shared read at its own pace, while the built-in sensor still shows Home Assistant its value and attributes at its own: an hourly GPU usage stays hourly in the recorder even with an adapter's load wanted every second.
A push event refreshes the push-driven sensors only. A volume change, a lock or a media event used to re-read every fast and normal sensor along with it, so on a PC playing media the uptime, the GPU or the drive health arrived far more often than their profile says. Now such a read takes the push-driven sensors alone; the clock-driven ones keep their own pace. Uptime moved to the normal profile (every 60 seconds instead of every fast cycle): its value changes with every tick, so on the fast profile it wrote a new row to the recorder at every cycle for nothing.
GPU usage per GPU. On a PC with two GPUs (an integrated one and a graphics card) the sensor's value and its top-level engines and memory follow whichever GPU is busiest at each reading, so they could move from one to the other. Each entry of adapters[N] now has its own usage, engines (3D, video and the rest) and memory, so gpu_usage.adapters[1].engines.3d follows one card; gpu_usage.name says which GPU the main value follows. Requested in #99. See GPU usage with more than one GPU.
Gigabytes next to megabytes, and totals. memory_dedicated_gb, memory_shared_gb and adapters[N].memory_gb, memory_dedicated_gb, memory_shared_gb on GPU usage, one decimal; the _mb attributes stay, so sensors built on them keep working. memory_usage has total_gb, used_gb, available_gb; both system drive sensors have drive, total_gb, used_gb, free_gb. Requested in #107.
Two sensor keys lost the unit in their name: system_drive_free_gb is system_drive, memory_available_mb is memory_available. With the totals in the attributes a key with a unit in it read oddly: system_drive_free_gb.total_gb. Nothing changes in Home Assistant: the integration 10.10.0 moves the entity over to the new key, with its entity ID, its history and its statistics, and an older integration keeps its entity because the app still sends and advertises the old key next to the new one. An attribute sensor made on the old path follows the rename on its own. Raised in #107.
The attribute list follows this PC. The Attributes button and the editor's list offer adapters[1], displays[1], drives[1] and so on for every item the sensor last reported, instead of [0] only; the second one's sensor gets a 2 after its name. An attribute sensor made from the list gets its unit (°C for temperatures, h for hours, GB / MB for memory, % for loads), and it can only be ticked for a role that reads its built-in sensor (the drive health for the service, the active window for the app).
Custom sensors tell Home Assistant what they measure: a unit of °C, GB, MB/s, h, W, V, A or MHz brings the matching device class (temperature, data size, data rate, duration, power, voltage, current, frequency), so a °C sensor shows as °F where that is the custom, history included, and the unit can be changed on the entity. Also for LibreHardwareMonitor sensors; per-app volumes from the list get % too. Needs the integration 10.10.0 or newer.
Several rows at once on the Sensors page: Shift and Ctrl pick several custom sensors, and Remove and Test work on all of them (removing more than one asks first). Custom commands and hotkeys get the multi-row Remove too.
Fixed: LAN IP could show the address of a virtual adapter. It took the first adapter Windows listed, often a VirtualBox, Hyper-V, WSL, Docker or VPN one. It now takes the adapter Windows routes through, and network_address.addresses[N] lists that one first, then those with a gateway, then the rest. A custom sensor on addresses[0] may therefore show another adapter than before: the real one. Reported in #100.
Fixed: Session locked went back to off a few seconds after locking. The sensor took a locked session to be one whose input desktop the app cannot open. On Windows 11 the lock screen shows on the user's own desktop, so that was true only for a moment while the lock screen came up. It now reads the lock state Windows keeps for the session. Reported in #96.
Fixed: Logged in user was empty and Session state said connected on a PC used only over Remote Desktop. Both read the console session, the PC's own screen, which shows the sign-in screen with nobody in it while you work over Remote Desktop. Now the console's session counts when someone is signed in there, otherwise the active Remote Desktop session, otherwise one that was disconnected without signing out.

Media player and notifications

A Media player page in the app. The media player's switch moved there from Capabilities, with two things that were not there before: Send the cover art to Home Assistant (off, the entity shows no picture) and Announcements: a play_media action sent with announce: true (TTS, a doorbell sound) unmutes the PC and sets the announcement volume for it, pauses what was playing when you want that, and puts the volume, the mute and the playback back afterwards. On by default, because an announcement is meant to be heard; needs the integration 10.10.0 or newer, an older one plays it at the current volume as before. A pause or a stop from Home Assistant while the sound plays cuts it and puts everything back. The idea comes from a fork by @VorlonCD, thank you. The page also tells where turning the PC on and off from the media player is set up (the integration's options) and which of sleep, hibernate and shutdown this PC allows for it. See Media player.
A name of your own above the notifications. Under the notification style on the Capabilities page, tick Custom name and write the name the Windows notifications (and the app's own window) should show instead of HASS.Agent .NET10, for example to tell several PCs apart. One name for all notifications of the PC. Windows reads it again only once the app has no notifications left in the notification centre, so saving a changed name clears them. Asked for in #101.

Security

From a security review of the app, the CodeRabbit remarks on it, and a recheck of what came out of it. Most of it is invisible.

The local HTTP API is off by default. It serves the integration's Local HTTP API mode only (notifications without MQTT or the HA API), yet every install listened on port 5115 with a key in its settings file. It is now a switch on the General page, under Local HTTP API, where the bind address and the port moved too: off, nothing listens and there is no key; on, the app makes a key and shows it. An install from before keeps it on, with its key, so a PC set up in Home Assistant with the Local HTTP API goes on working; turn it off on the General page when nothing uses it. The API also obeys the Notifications switch on the Capabilities page now, like the other two connections: with it off, /notify answers 403 and /info reports notifications: false. See Local HTTP API.
The settings export leaves out the local API key and the LibreHardwareMonitor password too, next to the MQTT password and the HA API token it already left out; the import makes a new key when the API is on, the password is entered again.
A message from the HA API larger than 1 MiB closes the connection instead of being read into memory whole, fragment by fragment too; the MQTT side has had the same cap. Home Assistant's own messages are a few kilobytes.
Writes into the settings folder never follow a link put under the file's name. The log (which the Windows service writes as SYSTEM), the settings file, the device id, the service's version note and its policy, the MQTT packet dump of the Danger Zone and the notice marker are opened on the name itself through one handle: a link or a hard link found there is removed, the name only, and the file is made anew. Until now the log was appended by path, so a hard link made after the folder's rule was set would have taken the service's lines into another file.
Who may use it: the rule is set file by file, and a file it could not be set on is reported. Limiting the folder reset the rule of everything in it with icacls, which would also have rewritten the rule of a file elsewhere that a hard link in the folder named. The rule now goes through a handle on each file itself, and a link or a hard link found there goes, as a junction already did. A file with a rule of its own that keeps even an administrator out is opened with the restore privilege, and what still cannot be done is reported: the window shows the failure instead of success with the folder's rule alone.
Who may use it: a PC with a domain or Entra ID user is not limited by an update on its own, and unticking such a user takes them out of the group. The "every user is an administrator" decision counted the local accounts only; on a work PC the user who actually logs on is from the domain or from Entra ID, so an update could have limited the settings to the local administrators and shut that user out. The users with a profile from a domain or Entra ID now count as not known to be administrators: the update leaves the folder open, the app asks, and the question lists them as DOMAIN\user when Windows can name them. Unticking one takes them out of the group too; only local accounts were taken out before.
Installer: "Only me" names the right user, or says that it could not. The installer asked the user who started it for their name through its own temp folder, which belongs to the account Setup runs as; when an administrator's password was typed in, that is another account, the user could not write there, and the settings were limited to the administrator alone without a word. The name now goes through ProgramData, as DOMAIN\user, and when it still cannot be found the installer says whom the settings were limited to; a limit that fails is reported too, instead of being assumed.
An administrator run says what became of it. The service approval and the install button say when a run was not started because an earlier one is still going, when it is still going, and when it did not finish as asked, instead of promising a result that is not coming.
The CodeQL workflow's checkout no longer keeps the token in the working tree, as the other workflows already did not.

Fixes

Fixed: turning MQTT off while the HA API stays on left the app on MQTT. Saving the MQTT page with the switch off, the app saw a connection that had not changed and kept it; only a restart of the app moved it to the HA API (the service, which starts fresh, went over at once). The app now says goodbye on the broker and starts again on the HA API alone.
No more "Refusing to allow … to subscribe to event hass_agent_command" errors in Home Assistant's log after its restart. A PC with a Home Assistant user of its own reconnected before the integration was loaded, found the integration's subscription missing and fell back to Home Assistant's own, which such a user may not use; Home Assistant logged the refusal, and the PC got in on its next attempt anyway. A user who is not an administrator is only ever set up with the newer integration, so the PC now just waits for the next attempt. An administrator's token keeps the fallback, for an integration older than 10.9.1.
HA API page: the line under the token, "The token is of …, not an administrator", is no longer cut short with a longer user name.
Danger Zone: the note under "Fast sensors below 5 seconds" is shown in full in a narrow window; the box had a fixed height and cut the sentence off.

The betas before it, with their notes as they were:

10.9.3-beta.7: what a recheck of the security round found

The seventh beta of 10.9.3: what a recheck of beta.6's security round found, five points, the service's log writing first of all. Works with the integration 10.6.7 or newer; the renamed sensor keys move over cleanly with the integration 10.9.2-beta.5. Signed release.

Writes into the settings folder never follow a link put under the file's name. The log (which the Windows service writes as SYSTEM), the settings file, the device id, the service's version note and its policy, the MQTT packet dump of the Danger Zone and the notice marker are opened on the name itself through one handle: a link or a hard link found there is removed, the name only, and the file is made anew. Until now the log was appended by path, so a hard link made after the folder's rule was set would have taken the service's lines into another file. Found by a recheck of beta.6's security round.
Who may use it: limiting that could not be set on every file says so. A file in the settings folder with a rule of its own that keeps even an administrator out is now opened with the restore privilege, and what still cannot be done is reported: the command exits with 1 and the window shows the failure, instead of success with the folder's rule alone. The window reads the administrator run's exit code for that; until now any run that ended counted as done. The ownership pass before the rule goes through handles too, with each subfolder held while its contents are done.
Who may use it: unticking a domain or Entra ID user takes them out of the group. Only local accounts were taken out before, so such a user kept access through the group after being unticked.
Fixed: the two renamed sensors, switched off, still went out under their old keys. The filter that leaves switched-off sensors out of the payload removes the key of before as well.
The service approval says when it was not started because an earlier administrator run is still going, instead of promising an approval that is not coming from it.

10.9.3-beta.6: a security round, two sensor keys renamed, two fixes

The sixth beta of 10.9.3: a security round from a review of the app and the CodeRabbit remarks on it, two sensor keys renamed with a migration (#107), and two fixes found on the way. Works with the integration 10.6.7 or newer; the renamed sensor keys move over cleanly with the integration 10.9.2-beta.5, out at the same time, an older integration keeps working by the old keys. Signed release.

Two sensor keys lost the unit in their name: system_drive_free_gb is system_drive, memory_available_mb is memory_available. Since the attributes came (drive, total_gb, used_gb on the one, GB totals on the other), a key with a unit in it read oddly: system_drive_free_gb.total_gb. Nothing changes in Home Assistant: the integration 10.9.2-beta.5 moves the entity over to the new key, with its entity ID, its history and its statistics, and an older integration keeps its entity because the app still sends and advertises the old key next to the new one. An attribute sensor made on the old path follows the rename on its own. Raised in #107.
The local HTTP API is off by default. It serves the integration's Local HTTP API mode only (notifications without MQTT or the HA API), yet every install listened on port 5115 with a key in its settings file. It is now a switch on the General page, under Local HTTP API, where the bind address and the port moved too: off, nothing listens and there is no key; on, the app makes a key and shows it. An install from before keeps it on, with its key, so a PC set up in Home Assistant with the Local HTTP API goes on working; turn it off on the General page when nothing uses it. The API also obeys the Notifications switch on the Capabilities page now, like the other two connections: with it off, /notify answers 403 and /info reports notifications: false. From a security review of the app.
The settings export leaves out the local API key and the LibreHardwareMonitor password too, next to the MQTT password and the HA API token it already left out; the import makes a new key when the API is on, the password is entered again.
A message from the HA API larger than 1 MiB closes the connection instead of being read into memory whole, fragment by fragment too; the MQTT side has had the same cap. Home Assistant's own messages are a few kilobytes.
Who may use it: a hard link in the settings folder is removed, not given the folder's rule. Limiting the folder reset the rule of everything in it with icacls, which would also have rewritten the rule of a file elsewhere that a hard link in the folder named. The rule is now set file by file through a handle on the file itself, and a link or a hard link found there goes, as a junction already did.
The CodeQL workflow's checkout no longer keeps the token in the working tree, as the other workflows already did not.
Who may use it: a PC with a domain or Entra ID user is not limited by an update on its own. The "every user is an administrator" decision counted the local accounts only; on a work PC the user who actually logs on is from the domain or from Entra ID, so an update could have limited the settings to the local administrators and shut that user out. The users with a profile from a domain or Entra ID now count as not known to be administrators: the update leaves the folder open, the app asks, and the question lists them as DOMAIN\user when Windows can name them.
Installer: "Only me" names the right user, or says that it could not. The installer asked the user who started it for their name through its own temp folder, which belongs to the account Setup runs as; when an administrator's password was typed in, that is another account, the user could not write there, and the settings were limited to the administrator alone without a word. The name now goes through ProgramData, as DOMAIN\user, and when it still cannot be found the installer says whom the settings were limited to; a limit that fails is reported too, instead of being assumed.
An administrator run that cannot start because an earlier one is still going says so, instead of reporting itself as still running.
Fixed: turning MQTT off while the HA API stays on left the app on MQTT. Saving the MQTT page with the switch off, the app saw a connection that had not changed and kept it; only a restart of the app moved it to the HA API (the service, which starts fresh, went over at once). The app now says goodbye on the broker and starts again on the HA API alone.
No more "Refusing to allow … to subscribe to event hass_agent_command" errors in Home Assistant's log after its restart. A PC with a Home Assistant user of its own reconnected before the integration was loaded, found the integration's subscription missing and fell back to Home Assistant's own, which such a user may not use; Home Assistant logged the refusal, and the PC got in on its next attempt anyway. A user who is not an administrator is only ever set up with the newer integration, so the PC now just waits for the next attempt. An administrator's token keeps the fallback, for an integration older than 10.9.1.
HA API page: the line under the token, "The token is of …, not an administrator", is no longer cut short with a longer user name; it takes the room up to the button next to it, or the card's width when the button is hidden.
Danger Zone: the note under "Fast sensors below 5 seconds" is shown in full in a narrow window; the box had a fixed height and cut the sentence off. The note now starts with a warning and says what to do about the history: a sensor you want every second but not in the database goes on the recorder's exclude list. Raised in #108.

10.9.3-beta.5: the system health pack, fast sensors and the polling profile per sensor

The fifth beta of 10.9.3: the system health pack from #107, the fast sensors and the polling profile per sensor from #108, and the Sensors page work that came with them. Works with the integration 10.6.7 or newer; the Drive health sensor needs the integration 10.9.2-beta.3 or newer, out at the same time. Signed release.

A push event refreshes the push-driven sensors only. A volume change, a lock or a media event used to re-read every fast and normal sensor along with it, so on a PC playing media the uptime, the GPU or the drive health arrived far more often than their profile says. Now such a read takes the push-driven sensors alone; the clock-driven ones keep their own pace.
Drive health, a new built-in sensor from the Windows service: Windows' own verdict on the drives from their SMART data (healthy, warning, unhealthy, the worst of them as the value), with every drive in the attributes (drives[N].name, health, temperature, temperature_max, power_on_hours, bus, media) and the system drive's temperature as temperature, one attribute sensor away from a °C entity. NVMe drives report the temperature and its highest value, a SATA drive the temperature and the power-on hours when its controller passes them on, USB enclosures nothing; a field a drive does not report is left out. Needs the integration 10.9.2-beta.3 or newer. Service only, since reading it needs administrator rights.
Attribute sensors made from the list get their unit: °C for temperatures, h for hours, GB / MB for memory, % for loads; also when a path is picked from the list in the editor. An attribute sensor can only be ticked for a role that reads its built-in sensor (the drive health for the service, the active window for the app); the other box is greyed.
gpu_usage.name: which GPU the main value and the top-level engines and memory follow.
Gigabytes next to megabytes: memory_dedicated_gb, memory_shared_gb and adapters[N].memory_gb, memory_dedicated_gb, memory_shared_gb on GPU usage, one decimal; the _mb attributes stay, so sensors built on them keep working. The attribute list offers the GB ones.
Memory and system drive totals: memory_usage has total_gb, used_gb, available_gb; both system drive sensors have drive, total_gb, used_gb, free_gb.
The attribute list follows this PC: the Attributes button and the editor's list offer adapters[1], displays[1], drives[1] and so on for every item the sensor last reported, instead of [0] only; the second one's sensor gets a 2 after its name. For the drive health, which the app itself cannot read, it counts the disks Windows lists.
Uptime moved to the normal profile (every 60 seconds instead of every fast cycle): its value changes with every tick, so on the fast profile it wrote a new row to Home Assistant's recorder at every cycle for nothing.
Fast sensors down to 1 second: the fast interval goes to 5 seconds on the Capabilities page (10 stays the default); the Fast sensors below 5 seconds switch on the Danger Zone page unlocks 1–4 seconds, with a note on what that means for traffic and the recorder.
Several rows at once on the Sensors page: Shift and Ctrl pick several custom sensors, and Remove and Test work on all of them (removing more than one asks first). Custom commands and hotkeys get the multi-row Remove too.
The polling profile of a built-in sensor is yours to choose: fast, normal or hourly in the Profile column of the Sensors page (GPU usage on fast, CPU usage on normal, whatever suits the PC); push-driven and startup sensors keep theirs. The three intervals stay global, the choice is which one a sensor follows. A custom attribute sensor on a faster profile refreshes the shared read at its own pace, while the built-in sensor still shows Home Assistant its value and attributes at its own: an hourly GPU usage stays hourly in the recorder even with an adapter's load wanted every second.
Custom sensors tell Home Assistant what they measure: a unit of °C, GB, MB/s, h, W, V, A or MHz brings the matching device class (temperature, data size, data rate, duration, power, voltage, current, frequency), so a °C sensor shows as °F where that is the custom, history included, and the unit can be changed on the entity. Also for LibreHardwareMonitor sensors. Per-app volumes from the list get % too.

10.9.3-beta.4: the Media player page

The fourth beta of 10.9.3: the Media player page. Works with the integration 10.6.7 or newer; the announcements need the integration 10.9.2-beta.2 or newer, out at the same time. Signed release.

A Media player page in the app. The media player's switch moved there from Capabilities, with two things that were not there before: Send the cover art to Home Assistant (off, the entity shows no picture) and Announcements: a play_media action sent with announce: true (TTS, a doorbell sound) unmutes the PC and sets the announcement volume for it, pauses what was playing when you want that, and puts the volume, the mute and the playback back afterwards. On by default, because an announcement is meant to be heard; needs the integration 10.9.2 or newer, an older one plays it at the current volume as before. A pause or a stop from Home Assistant while the sound plays cuts it and puts everything back. The idea comes from a fork by @VorlonCD, thank you. The page also tells where turning the PC on and off from the media player is set up (the integration's options) and which of sleep, hibernate and shutdown this PC allows for it.

10.9.3-beta.3: Logged in user over Remote Desktop

The third beta of 10.9.3: one fix. Works with the integration 10.6.7 or newer; there is no new integration with this one. Signed release.

Fixed: Logged in user was empty and Session state said connected on a PC used only over Remote Desktop. Both read the console session, the PC's own screen, which shows the sign-in screen with nobody in it while you work over Remote Desktop. Now the console's session counts when someone is signed in there, otherwise the active Remote Desktop session, otherwise one that was disconnected without signing out.

10.9.3-beta.2: GPU usage per GPU, the LAN IP, a name above the notifications

The second beta of 10.9.3: a sensor value per GPU, the right LAN IP and a name of your own above the notifications. Works with the integration 10.6.7 or newer; there is no new integration with this one. Signed release.

New since beta.1

GPU usage per GPU. On a PC with two GPUs (an integrated one and a graphics card) the sensor's value and its top-level engines and memory follow whichever GPU is busiest at each reading, so they could move from one to the other. Each entry of adapters[N] now has its own usage, engines (3D, video and the rest) and memory_dedicated_mb / memory_shared_mb, so gpu_usage.adapters[1].engines.3d follows one card. adapters[N] keeps its order and names. Requested in #99. See GPU usage with more than one GPU.
Fixed: LAN IP could show the address of a virtual adapter. It took the first adapter Windows listed, often a VirtualBox, Hyper-V, WSL, Docker or VPN one. It now takes the adapter Windows routes through, and network_address.addresses[N] lists that one first, then those with a gateway, then the rest. A custom sensor on addresses[0] may therefore show another adapter than before: the real one. Reported in #100.
A name of your own above the notifications. Under the notification style on the Capabilities page, tick Custom name and write the name the Windows notifications (and the app's own window) should show instead of HASS.Agent .NET10, for example to tell several PCs apart. One name for all notifications of the PC. Windows reads it again only once the app has no notifications left in the notification centre, so saving a changed name clears them. Asked for in #101.

10.9.3-beta.1: Session locked on Windows 11

The first beta of 10.9.3: one fix. Works with the integration 10.6.7 or newer; there is no new integration with this one. Signed release.

Fixed: Session locked went back to off a few seconds after locking. The sensor took a locked session to be one whose input desktop the app cannot open. On Windows 11 the lock screen shows on the user's own desktop, so that was true only for a moment while the lock screen came up. It now reads the lock state Windows keeps for the session. Reported in #96.

10.9.2¶

Hotfix: camera and microphone on Windows 11 26H2. Works with the Home Assistant integration 10.6.7 or newer. Signed release.

Fixed: Camera in use and Microphone in use stayed off on Windows 11 26H2. Both read the record behind the Windows privacy indicator, and 26H2 no longer keeps it up to date. Microsoft switches this on gradually, so a PC can be fine for days after the update and then lose both sensors. The camera is now read from Windows' camera stack and the microphone from the apps recording on any input device. The apps attribute keeps the same names (the package for a Store app, the exe for a desktop app), so automations need no change.

10.9.1¶

The security release after the feature release: 10.9.0 brought new things to do, 10.9.1 is about who can do them. It is what came out of CodeRabbit's AI Deep Scan of the app, a security review of the Home Assistant integration and another of the app, its installer and the release flow. Most of it is invisible. On a PC with more than one Windows user the app asks once who may use it, and an administrator's token on the HA API can be swapped for a Home Assistant user of the PC's own. Works with the Home Assistant integration 10.6.7 or newer; the HA API without an administrator's token needs the integration 10.9.1, the new entities of 10.9.0 need 10.9.0. Signed release.

Who may do what on this PC

Who may use HASS.Agent on this PC. Its settings, with the Home Assistant token, the MQTT login and the commands it runs, could be read and changed by every user of the PC. They can now be limited to some users. A first install asks (Only me or Every user of this PC); a silent one (winget, a deployment tool) leaves the choice to the app, which asks the first time its window is opened on a PC with a user who is not an administrator. The question names what is at stake: the MQTT password, which opens the whole broker, and what the Home Assistant token can do. It is also under Danger Zone, Users of this PC. Limiting needs an administrator (UAC) and uses a local group, HASS.Agent Users, that an administrator can also manage with Windows' own tools; the ticked users get access at once, without logging on again, and someone left out gets a note once. On a PC whose users are all administrators an update limits the settings to them by itself, which takes nothing from anyone and keeps out a user added later. See Who May Use It on This PC.
The settings folder can no longer be taken over. Every user may create a folder in ProgramData, so another user could have made HASS.Agent's folder before the first install, or made it a link to a folder of their choosing, whose access rule the installer would then have set. Before an administrator sets the rule, the app now removes such links and takes over what another user owns, and users may change what is in the folder but not delete or replace the folder itself.
Fixed: a user of the PC could have a command run as SYSTEM. The Windows service (SYSTEM) ran the custom commands and command sensors the settings set for it, and those settings could be written by other users. The service now runs one only when an administrator has approved it: service-policy.json next to the program, which only administrators can write, approves each by its id and what it runs. A command or command sensor added or changed for the service asks for administrator approval (UAC) when the settings are saved; the prompt shows each one in full, and what is approved is exactly what it showed. An update keeps what was approved before and approves nothing new; the first update from 10.9.0 or older approves the current settings once, so nothing stops working. Until it is approved the service leaves a command to the tray app, and the log says which ones. The editor's Test button runs it as you, never as SYSTEM, and says so when only the service is ticked. See Commands the Service Runs.
Windows tools are started by their full path (sc.exe, schtasks.exe, shutdown.exe, PowerShell and others). A bare name is looked up in the current folder first, so the app started elevated from a folder someone else can write to could run a planted copy.
Setup starts the app as the user who ran it, not with administrator rights.
Uninstalling asks whether to remove the settings, with the tokens in them.

Home Assistant

The HA API no longer needs an administrator's token (integration 10.9.1). The connection used Home Assistant's fire_event and subscribe_events, which only an administrator may use, so the token on the PC was one that can change everything in Home Assistant, and a PC that was broken into gave it away. With the integration 10.9.1 the app uses the integration's own commands instead, which work with a token of a Home Assistant user who is not an administrator; an administrator approves such a PC once in Home Assistant. The app also only gets the commands meant for itself now, not those of every PC. The easy way there: when the app connects with an administrator's token, right after the token is saved or when its window opens, it offers to create a Home Assistant user for this PC (not an administrator, without a password) and switches to its token; the HA API page shows whose the token is and has the same button. An administrator's token keeps working, and with an older integration the app connects as before. How it works, and the way by hand: A Home Assistant user for the PC.
A Home Assistant address typed without http:// or https:// gets https unless it points into the home network. It always got plain http before, so an address on the internet (a Nabu Casa one, your own domain) sent the token unencrypted, or did not work at all. A .local name, a name without a dot, a private IP address and localhost still get http, as Home Assistant answers there by default.
Switched-off sensors stay at home. A built-in sensor switched off on the Sensors page was only left out of what Home Assistant builds entities from; its value still went out with every update, the title of the active window and the logged-in user included. Only the sensors switched on are sent now.
Notifications and media commands over the HA API follow their switches, as they always did over MQTT.
A command sensor's command goes to Home Assistant as a hash, not as its text: the device message stays on the broker, where any client can read it.
Keep the MQTT login to yourself. Whoever can log in to the broker can send the PC commands and notifications; Connecting to Home Assistant says what to do about it. MQTT messages over 1 MB are ignored.

Updates

An update installer runs only when it is signed by the publisher. The app downloaded the installer of a new release and started it without checking it, elevated, and from the service as SYSTEM. It now asks Windows to check the Authenticode signature first (unchanged since signing, a trusted certificate chain, a valid timestamp), requires the signer to be the publisher of the releases (Open Source Developer Viktor Révész, issued by Certum Code Signing 2021 CA), and refuses a certificate that has been revoked. Anything else, a damaged download or a release file replaced by someone else, is deleted and the update stops with the reason in the log and in Home Assistant. The publisher is checked by name rather than by certificate, so a renewed certificate keeps updates working.
The service downloads an update into a new folder that only administrators can use; on older Windows 10 its temp folder let other users get at the installer between the check and the start.
The update prompt only links to GitHub: links inside the release notes are shown as text.
The release signatures (Sigstore) are only made after every file in the zip has been checked: the app with the Certum signature, the bundled WebView2 and ASP.NET Core libraries with Microsoft's, and nothing else that could run.

Also in this release

A hotkey is pressed, not typed, and you see at once whether it is free. In the hotkey editor the combination is pressed in its field (Backspace clears it). The line under it says straight away whether Windows lets HASS.Agent have it, or whether Windows or another program already uses it; it also says when another hotkey of the list has the same combination, and warns about one modifier alone (ctrl+c, alt+f4). A taken combination is kept only when OK is pressed twice; the app then tries it again every minute, so it starts working once the other program lets it go.
The service no longer restarts its connection after an update.
The broker drops the PC with "malformed packet"? On one PC with a Realtek 2.5G network card it stopped once the card's Large Send Offload was switched off; Connecting to Home Assistant says how to switch it off.
The local HTTP API compares the API key in constant time, and a new one comes from the cryptographic random generator.
Notification pictures: at most two downloads at a time, none from this PC itself, redirects checked one by one, nothing over 50 megapixels; old ones are cleaned up once an hour.
Limits on what LibreHardwareMonitor sends: at most 4 MB and 5000 values are read.
The log cannot be fooled by line breaks in text that comes from outside (a notification, an MQTT message).
A contributing guide, and the project has the OpenSSF Best Practices passing badge.

10.9.0¶

A bigger release than the step in the version number suggests: notifications rebuilt on Windows notifications, the display as a light, audio device selects, hotkeys, per-app volume, hardware sensors through LibreHardwareMonitor, a new website and documentation, and the fixes of three betas. Works with the Home Assistant integration 10.6.7 or newer; the new entities (display light, audio selects, hotkeys, set_app_volume) and the notification fields need the integration 10.9.0. Signed release.

Notifications

Notifications as Windows notifications, with pictures and text fields. A notification from Home Assistant is now a real Windows notification by default: it follows Do not disturb, stays in the notification centre, and can carry a picture (image), up to five buttons, and text fields (inputs) whose content comes back to Home Assistant with the pressed button. The app's own window stays as the other Notification style on the Capabilities page, for a notification that is visible whatever Windows is doing; it shows the same picture and text fields, and it no longer takes the keyboard focus when it appears. A single notification can pick its style with style: window or style: toast, so the doorbell can always use the window. Until now a notification without buttons was a tray balloon and one with buttons the app's window. The picture can be a web address; with the integration 10.9.0 also a path on Home Assistant or a camera entity. See Notifications.
The notification action in Home Assistant has fields of its own (integration 10.9.0). image, actions, inputs, style and duration no longer have to be written as YAML inside the action's data object: each has an input of its own in the Home Assistant editor. The old form keeps working. See Notifications.
The app's own notification window: the app icon in its title bar, and the hint of a text field above the field. The hint used to be a placeholder inside the field, which disappears as soon as the field has the focus.

New in Home Assistant (integration 10.9.0)

The display as a light in Home Assistant. Turn on the new Display brightness sensor (tray app, off by default) and the PC gets a Display light: its brightness slider sets the screen brightness, off switches the monitor off, on wakes it. It works with what Windows itself offers: the built-in panel of a laptop, and external monitors that speak DDC/CI. With an older integration the sensor does nothing. With no adjustable display (many TVs, some docks) the light is a plain on/off one, without the slider.
Choose the audio device from Home Assistant. The Audio output device sensor now comes with a select that makes another playback device the default, for "switch to the headset" or "sound to the TV" automations. The new Audio input device sensor (off by default) does the same for the recording device.
Hotkeys that reach Home Assistant. On the Capabilities page you can list key combinations with a name (ctrl+alt+h as "Meeting"); pressing one sends an event to Home Assistant, where the device's new Hotkeys event entity triggers automations on it. Only the listed combinations are registered with Windows, nothing else that is typed is seen.
Per-app volume from Home Assistant. Turn on the new Audio sessions sensor and the apps in the Windows volume mixer show up as its attributes (name, volume, muted, playing); the integration's hass_agent.set_app_volume service sets the volume or mutes one of them, for "turn the game down when the doorbell rings". The state is how many apps play right now.
Hibernate and Log off commands. Two more buttons for Home Assistant, off by default on the Capabilities page.
Hardware sensors through LibreHardwareMonitor. A new custom sensor type reads CPU and GPU temperature, fan speed, voltage and load from a running LibreHardwareMonitor (its Remote Web Server). The editor lists every value it reports and fills in the unit; a Connection... button sets the address and the login if it asks for one. The agent itself stays free of vendor-specific hardware code. See Custom Sensors.

Updates

The service reports a finished update. After an update installed with nobody logged in, the "updated from X to Y" notification used to wait for somebody to log in, because only the tray app sent it. The service now sends it when no tray app is running.
The update report also arrives after a downgrade. The installer now tells the service which version it replaced, so the "updated from X to Y" notification is sent when the previous version was older than 10.9.0, or was installed over a newer one.
The update prompt of the About page is a proper dialog. The version found and the installed one on top, the release notes as readable paragraphs under a "What's new" expander (the hard-wrapped lines of the tag message are joined again, long notes cut at a paragraph), a link to the full notes on GitHub, and Download / Not now buttons in the app's language; the message box used before got its buttons from Windows, so an English app asked "Igen / Nem" on a Hungarian PC. The dialog after the download asks Install now / Later the same way.
A failed update check (right after boot the service often asks before the network can resolve names) is tried again after a minute, three times at most, instead of waiting six hours. The log line says what failed and that it will try again; the earlier "Unable to publish update state" was misleading, the state did go out.

Fixes

Fixed: stale data in Home Assistant after its restart, on a PC that only uses the HA API. What the client sends once on connect (its discovery, the service status, the update state) reached Home Assistant before the integration was listening, and the HA API keeps nothing for latecomers. The device then showed an old version and an unavailable update entity. The client now sends these again when the integration asks (integration 10.9.0), and the tray app sends its discovery again every ten minutes on its own.
Fixed: a message could get lost on the HA API when two were sent at the same moment. Home Assistant wants message ids that grow from one message to the next; two senders could pass each other between taking an id and sending, and the later one was refused with id_reuse. Ids are now taken in the order the messages go out.
Fixed: the Boot time sensor changed every few seconds. The service and the tray app both publish it, each computed it from its own clock a few milliseconds apart, and Home Assistant recorded the two values, rounded to different seconds, as a change on every publish. Both now report the boot time the kernel keeps, which is the same in both.
Quieter log without an audio output. A PC with no default audio output (an HDMI output whose screen is off) logged three warnings on every poll. It is now logged once when it starts and once when a device is back.
When the broker closes the MQTT session over something it was sent (a malformed packet, a protocol error), the log now lists the last packets that went out, with their time, topic and size.
With MQTT switched off, the log says what happens. A failed connection to Home Assistant is logged as what it is (HA WebSocket connection failed) and once, not as an MQTT failure followed by a failed failover, and the service no longer warns that it "will stay idle" when it connects over the HA API right after.

Around the app

A Star on GitHub button on the About page, next to the coffee one. The only place the app asks for it.
New website and documentation. The README is short now and the details live under docs/: Features, Commands, Sensors, Connection and a Coming from HASS.Agent page for people who know the classic client. The website shows what Home Assistant sees and what the notifications look like.

10.8.0¶

Works with the Home Assistant integration 10.6.7 or newer. Signed release.

Custom commands and custom sensors get an editor window. Adding one, or double-clicking a row, opens a window with room for a long command line, a description and an example for the chosen type, a Browse button for programs and scripts, and a Test button: a command runs right away and says what went wrong if it did, a sensor shows the value it would report. For sensors the parameter field also lists what the PC has: the running processes, the installed services, the drives, or the attributes of the built-in sensors. The tables on the settings pages are now just the overview, with the ticks still one click away.
Dashboard popup (WebView). A Home Assistant dashboard, or any web page, in a small window above the tray: set its address and size on the Capabilities page, then open it from the tray menu, or with a click on the tray icon if you tick that. It closes when you click elsewhere, and nothing is loaded while it is closed. There is a matching custom command type, Popup window (WebView), that shows a page in a window of its own, for example a camera when the doorbell rings. Both use the WebView2 runtime that ships with Windows 11; the login is kept per Windows user. Off until an address is set.
Two new custom command types: Key press and Open address. A custom command can now press keys (win+r, ctrl+shift+esc, alt+tab, media and browser keys, or several combinations in a row) or open a link in the default browser, without a script written for it. Both show up in Home Assistant as buttons like any other custom command, and both run in the tray app, since they act on the desktop of the logged-in user. The key names are listed under Custom Commands.

10.7.3¶

Works with the Home Assistant integration 10.6.7 or newer; the Check for updates button and the single update entity need integration 10.7.3. Signed release.

A Check for updates button in Home Assistant (integration 10.7.3+). It sits next to the update entity and makes the agent ask GitHub right away, so a fresh release shows up in Home Assistant without waiting for the six-hourly check or opening the About page. Thanks to @Taomyn for the idea.
One update entity, on both transports. Over MQTT the update entity used to come from Home Assistant's own MQTT discovery, and over the HA API from the integration - so a PC that switched transports ended up with two, one of them always unavailable. With integration 10.7.3 or newer the integration builds the entity on MQTT as well, and the agent removes its discovered one (it announces the change on hass.agent/integration/{id}, retained; an older integration says nothing there and keeps getting the discovered entity as before). The entity now follows the device rather than the tray app, so it stays available, and installable, while only the service runs.
Fixed: installing an update from Home Assistant now works with nobody logged in. The Install button's request was only picked up by the tray app, which handed the actual install to the Windows service. On a PC that was switched on but not logged in there was no tray app, so the request went unanswered, with nothing in any log. The service now takes the request itself when no tray app is running, and it keeps checking for new releases meanwhile, so the update entity in Home Assistant stays current on a PC nobody is logged in to. When a tray app runs, it handles the request as before, since it also has to bring itself back after the install. Thanks to @Taomyn for the report.

10.7.2¶

Works with the Home Assistant integration 10.6.7 or newer (no integration change in this release). Signed release.

Fixed: a large album cover no longer takes the MQTT connection down. The media player published the artwork exactly as Windows handed it over, with no resizing and no size cap. Mosquitto 2.1 (Home Assistant add-on 7.0.0 and newer) rejects any packet over 2 MB by default, and a full-size cover from a browser can exceed that: the broker dropped the connection, the agent reconnected and sent the same picture again, and every entity flapped between unavailable and its state for as long as the track played. Artwork over 128 KB or 512 px is now scaled down to 512 px and re-encoded as JPEG before publishing (a few dozen KB; smaller artwork goes out unchanged), the agent honours the packet size the broker advertises on connect, and anything still over the limit is skipped with a log line. The same cap applies on the HA API transport. Thanks to @j0k34 for the precise report.

10.7.1¶

Works with the Home Assistant integration 10.6.7 or newer; the new sensors need integration 10.7.0 to show up in Home Assistant. Signed release, like every release since 10.6.8 (see Code signing).

10.7.1 replaces 10.7.0, which was withdrawn a few hours after it went out; everything below is new compared to 10.6.9.

Nothing changes for an existing installation. Every sensor you have stays exactly as you set it. The new sensors arrive switched off, and the "off by default" list below only applies to a fresh install.

Five new built-in sensors, all switched off until you enable them on the Sensors page:
GPU usage — GPU load the way Task Manager shows it, from Windows' own counters, so it works the same on Intel, AMD and NVIDIA without any vendor tool. Attributes: load per engine (3d, videodecode, videoencode, …), NPU load, dedicated / shared memory in use, and the installed adapters with their real memory size (WMI stops at 4 GB). Temperature, clock and fan speed are vendor specific and not part of it — use a custom sensor for those.
Sleep blocked — on while something keeps the machine (or its display) awake: a video playing in the browser, a download, a driver. The attributes name who: primary_blocker, and the full blockers list with category, type, name, reason and whether it really blocks sleep. Service only — Windows shows the holders to administrators alone.
Last wake reason — what woke the machine last (Input Keyboard, Power Button, Lid, a device, a wake timer…) with the time, how long it was away and whether it really slept. Works on Modern Standby laptops and on desktops with classic sleep / hibernate. Event driven: the new value is in Home Assistant seconds after the wake, without polling.
Camera in use / Microphone in use — on while an app is using the camera or the microphone, with the apps listed in the apps attribute. Handy for an "in a meeting" light. Tray app only (Windows keeps this per user).
Sensors that are off by default. Not every sensor is for everyone, so a fresh install no longer creates all of them in Home Assistant: besides the five new ones, VPN connected, RDP sessions, Recent Event Log errors, Last shutdown reason and Clipboard text available now start switched off. Existing installations are not touched — a setting you already have is never changed by an update.
A sensor that is switched off costs nothing. The more expensive reads (the power request list, the GPU counters, the wake event subscription) only run for a sensor that is enabled, or that a custom attribute sensor is built on.
The log file no longer grows forever. It was never trimmed and could reach hundreds of megabytes after a few months. The log now starts a new file every day (and within a day once it passes 10 MB); older files are kept next to it as hass-agent-net10-<date>.log and removed after 7 days, or sooner if together they pass 100 MB. The oversized file an earlier version left behind is cleaned up on the first start.
Sensors arrive faster after startup. The Windows Update check takes 5–30 seconds and used to hold back every sensor for that long — at startup and again once an hour. It now runs on its own in the background: the first sensor values reach Home Assistant in about a second, and Windows Update pending follows when its search is done.
Attribute sensors get readable names. A custom sensor created from a built-in sensor's attribute (the + on the Built-in sensors tab) was named after the raw attribute key — Last shutdown reason: reason. The attributes now have proper names in English and Hungarian, and the generated name follows the Home Assistant language setting, since it becomes the entity name there. Sensors you already created keep the name they have; rename them on the Custom sensors tab if you like.
Fixed: a manual update check now reaches Home Assistant. The agent asks GitHub at startup and every six hours, and only those checks were reported to Home Assistant. The Check for updates button on the About page asked GitHub on its own and told nobody - so when a release came out between two checks, the app knew about it while Home Assistant kept showing "up to date" until the next scheduled check or a restart of the tray app. The result of a manual check is now reported the same way. Thanks to @Taomyn for the report.
Fixed: crash on exit. Closing the tray app (also when an update closes it) could end in an unhandled exception, recorded by Windows as an application error: the media session monitor was stopped from two places at once during shutdown. Nothing was lost, since the app was closing anyway, but it no longer happens.
Fixed: starting a service that is already running is no longer an error, and neither is stopping one that is not. The message Windows gives in those cases (and any other sc error) is also readable now on a localized Windows: it was decoded with the wrong code page, so every accented letter came out as �.
Fixed: a refused MQTT login was logged as MQTT connected. A broker that rejects the credentials answers the connection attempt instead of failing it, and the agent took that answer for success — so the log showed a connection that never existed, and the HA API failover kept flapping between the two transports. A refused connection is now a failed one: it is logged with the broker's reason, and the failover stays on the HA API until the broker really accepts the login.

10.6.9¶

Requires the Home Assistant integration 10.6.7 or newer (no integration change in this release).

Installing an update from Home Assistant now works on the HA API (WebSocket) transport with the service installed. Pressing Install started the relaunch watchdog (the brief console window) and posted the "update started" notification, but the actual install command for the service was sent to the MQTT service topic — which, without a broker, was silently dropped. So nothing was installed and the version never changed. The command now travels over the HA API as well, and the service runs the silent install exactly as it does over MQTT.
Without the service, the installer started from Home Assistant is launched detached from the tray app instead of as its child process, so the installer's own close-the-running-app step can no longer take the installer down with it.

10.6.8¶

Requires the Home Assistant integration 10.6.7 or newer (no integration change in this release).

Signed releases. The installer, its uninstaller and the executable are signed with a Certum code signing certificate issued to Open Source Developer Viktor Révész, so Windows no longer shows them as coming from an unknown publisher. See Code signing for how to verify a download.
The rdp_sessions sensor now counts Remote Desktop sessions. It always reported 0: the session's client protocol type was read as a 4-byte integer, but Windows returns a 2-byte value, so the protocol type of every session came back unreadable and no session was ever counted as RDP. Thanks to @ThorgarIV for the report and the fix.
Factory reset now actually resets. Since 10.6.4 the settings file has had a backup and a device-id sidecar so a damaged file cannot lose your configuration — but the Factory reset button only deleted the settings file, and the next start quietly restored everything (connection, credentials, serial number) from those. It now removes the backup, the sidecar and any legacy settings the migration would have picked up, so the device really starts over.
MQTT drops are logged, with the reason, and the reconnect backs off. When the broker closed a session right after connecting (a rejected login, a user or ACL removed from Mosquitto, a duplicate client ID) the log showed nothing but Connecting… / MQTT connected. repeating at full speed. The agent now logs the broker's verdict for a refused connection and the disconnect reason for a dropped one, and waits 5 → 60 s between attempts when sessions keep dying, with a hint about the usual causes.
Release notes in the app. The About page has a Release notes button for the installed version, and the update prompt now shows what changed in the new release before asking to download it.
Support the project. A Buy me a coffee button on the About page links to Ko-fi.
The GitHub links in the app point at the renamed repository (HASS.Agent.NET10) instead of relying on the redirect from the old name.

Thanks to @ThorgarIV for the RDP report and fix, and to @phuzzyday for the migration write-up that surfaced the reset and logging problems.

10.6.7¶

Requires the Home Assistant integration 10.6.7 or newer.

The update entity now works on the HA API (WebSocket) transport. It was built from Home Assistant's own MQTT discovery, so without a broker there was no update entity and no Install button — on the very transport people choose precisely because Home Assistant is not on their local network. The agent now reports the available release over the WebSocket as well, and installs it when asked, so updating from Home Assistant works with or without MQTT.

10.6.6¶

Requires the Home Assistant integration 10.6.6 or newer.

Closing the tray app no longer takes the whole device offline. With the Windows service installed, everything in Home Assistant turned unavailable the moment the tray app was closed or you logged out — even though the service was still running and reporting CPU, memory and disk. Only the tray app ever published the device's availability, so leaving declared the device dead rather than just itself. The tray app and the service are now treated as two independent providers: the device stays reachable while either is running, and each entity follows whichever side actually feeds it. Entities that only the tray app can provide (media player, active window, notifications) go unavailable rather than disappearing, and come straight back when it starts again.
A stopped provider no longer deletes its entities. The service used to report an empty capability list while offline, so Home Assistant removed its sensors instead of greying them out. It now always reports what it handles, and reports separately whether it is running — so its entities stay put and simply show as unavailable. Turning a capability off in the settings still removes those entities, as it should.

Thanks to @Taomyn for the report.

10.6.5¶

Requires the Home Assistant integration 10.6.5 or newer when using the HA API (WebSocket) transport.

Custom commands now work over the Home Assistant API (WebSocket) transport. Pressing a custom command button did nothing when running without MQTT — the log only showed Unsupported app WebSocket command received: <id>. Built-in commands were unaffected. Each transport carried its own copy of the "what does this button mean" logic, and only the MQTT one knew about custom commands; all transports now share a single implementation, so they cannot drift apart again.
Interactive sensors no longer flicker between a value and blank. With system sensors enabled for both the tray app and the Windows service, both published a full snapshot to the same topic — but the service cannot see the desktop, so it sent active window, active process, foreground app, active displays, audio output and user present as empty, blanking out what the tray app had just reported, a couple of times a minute. The service now omits what it cannot measure instead of reporting it as empty, so those sensors keep the tray app's values.
The system service is now a first-class citizen on the HA API transport. It had no channel of its own there — unlike MQTT, where the app and the service each advertise what they can handle and Home Assistant merges the two. Over the WebSocket the service announced itself as the app, advertising the tray app's commands and then refusing them, so with the tray app closed only commands enabled for both sides happened to work, and every button press left a stray warning in the log. The service now has its own channel, and Home Assistant names the side a command is meant for — so each press runs exactly once, on the right side, whether the tray app is running or not.

Thanks to @CookSleep for the report — including the root cause and a suggested fix.

10.6.4¶

Both fixes address the update problems reported in #22.

Updates now start on battery. The one-shot tasks that run an update carried Task Scheduler's default battery conditions ("start only on AC power", "stop when switching to battery"), so on a notebook running on battery the update never started — the tasks just sat Queued. The tasks are now created from an explicit definition that allows battery power, and they still remove themselves afterwards.
"Clean install" is never remembered and never runs silently. The installer remembers task selections from previous runs, so ticking Clean install once made every later update on that machine silently repeat it — wiping the settings and the device id, which is why the PC kept reappearing in Home Assistant as a new device. The tick now always starts unchecked on an upgrade, and an unattended (silent) update can never wipe settings at all.

Thanks to @AdmiralRaccoon for the report and for methodically confirming both causes — registry value and Task Scheduler conditions included.

10.6.3¶

Settings are far harder to lose when an update closes the app. They were written by truncating the file first and then writing it, so a badly timed force-close could leave it empty. Settings are now written atomically and the previous version is kept as a backup, which is restored automatically if the main file ever turns up missing or unreadable.
A lost configuration no longer creates a duplicate device in Home Assistant. The device serial is what identifies the PC, and it used to live only in the settings file — so losing that file minted a new serial and the machine reappeared as a brand new device (with the old entities left behind on the broker). The serial is now mirrored next to the settings and reused. A deliberate Clean install still gives a fresh identity, as it should.
One-shot update tasks clean themselves up. The scheduled tasks used to run an update were left behind in Task Scheduler, where they piled up and invited being run by hand. They now delete themselves after running, and leftovers from earlier versions are removed on start.

10.6.2¶

Fixed a NullReferenceException in the sensor loop that left the device permanently unavailable in Home Assistant. The Windows service runs with interactive metrics disabled, and those fields fell back to the previous snapshot — which doesn't exist yet on the first read after the service (re)loads, so the very first read threw before a snapshot could be stored, and every cycle after it repeated the same failure. Affected setups where the service publishes system sensors; the tray app was unaffected.
Entities no longer disappear from Home Assistant when the app shuts down cleanly. A graceful exit also published an empty capability list, which Home Assistant reads as "this device has nothing left" and deletes the entities. Now only the availability state goes offline, so the entities stay and show as unavailable until the device is back — the same as after a crash or network loss. (Turning off both MQTT and the HA API in settings still removes them on purpose.)
Sensor reads are now fault-isolated: a failing metric read falls back to its previous value instead of aborting the whole cycle, and the log names the exact read that failed — so one misbehaving read can no longer take the device offline, and diagnosing one is much quicker.

Thanks to @Taomyn for the detailed reports and for testing the beta builds — these were tracked down entirely from his logs and feedback.

10.6.1¶

Fixed a NullReferenceException in the sensor loop that could make the device go (and stay) unavailable in Home Assistant, typically after startup or resume from sleep. A transient network adapter with a null name/description (common with VPN/virtual adapters mid-initialization) threw inside the network reads, aborting every sensor cycle. The network reads are now null-safe and fault-isolated.
Fixed GitHub update-check 403 (rate limit exceeded): the update state was queried on every reconnect, which — with frequent reconnects and several devices behind one IP — exhausted the unauthenticated GitHub API limit. The result is now cached/throttled (at most once per hour outside the 6-hour poll).

10.6.0¶

Stable release of the custom commands & command sensors line.

Custom command buttons — run your own programs or PowerShell/pwsh scripts from Home Assistant. You define what runs; Home Assistant only triggers a command by its id (it can't send arbitrary code). Also handles a full command line typed into the command field (e.g. taskkill /F /IM app.exe /T).
Command sensors — a custom sensor whose value is the output of a program or PowerShell script (e.g. GPU temperature via nvidia-smi), with an optional unit that makes it a numeric measurement (graphs & statistics in Home Assistant).
Fixed in-app updates (from the About page) aborting: the installer closes the running app with taskkill /… /T, which also killed the installer when it was launched as a child of the app. It now runs detached, so it survives, installs, and relaunches the app. Updating from Home Assistant was unaffected.
Update the Home Assistant integration too — it's now in the HACS default store, so no custom repository is needed (search "HASS.Agent").

10.5.0¶

Fixed a freeze that could stop all reporting when the monitor powered off: multiple audio components held separate WASAPI COM instances and deadlocked during an audio device change (e.g. HDMI audio disappearing). Audio access is now a single, serialized endpoint, and the device-change handler no longer does COM work inside the notification callback.
The system sensor loop now survives a transient read error instead of stopping, and logs the full stack trace if one occurs.

10.4.0 (Yanked)¶

Added event-driven (push) sensor updates: monitor power state, session lock/unlock, AC/battery power source, and audio (volume, mute, output device, microphone mute) now report to Home Assistant within ~600 ms of changing instead of waiting for the next poll. Rapid changes (e.g. dragging the volume slider) are debounced.
Added enum sensor states: monitor_power_state, power_status, and session_state are now enum sensors, so Home Assistant knows their possible values (selectable in automations; dimmed is a first-class monitor state).
Added device availability: the device publishes an MQTT availability topic with a Last Will, and a heartbeat over the HA API transport. On a clean shutdown — or a crash / network loss — the entities turn unavailable in Home Assistant instead of keeping stale values.
The Sensors page now shows a Push profile for push-driven sensors.
Moved the Bluetooth sensor from hourly to normal polling.

10.3.0¶

Added one-click updates from Home Assistant: the update entity's Install button downloads and installs the new version on the PC — fully silent when the system service is installed, with a UAC prompt otherwise.
Added persistent notifications to Home Assistant for update progress: started, completed (with version), no installer, or failure.
Added the opt-in Danger Zone tab: maintenance and diagnostics tools behind a checkbox on the General page.
Added MQTT maintenance: list and delete retained HASS.Agent messages on the broker (per device or all devices).
Added one-click discovery republish on the active connection (MQTT or HA API).
Added a live debug log viewer with filtering and a runtime verbose (DEBUG) logging toggle.
Added a live MQTT monitor for the hass.agent/# topics with payload preview.
Added settings backup/restore to a portable JSON file (machine-bound secrets excluded).
Added factory reset with double confirmation and automatic app restart.
Added an MQTT connection test button on the MQTT page (matches the HA API page).
Added a beta update channel: opt in to receive GitHub pre-releases from the update checker.
Pre-release versions (10.3.0-beta.1) are now handled correctly by the version comparison and shown in the UI.
The General page warning now also shows when the system service is installed but stopped.
Fixed input fields overflowing on small window sizes across the General, MQTT, and HA API pages.

10.2.0¶

Fixed default language set to Hungarian on non-Hungarian systems; the app now auto-detects the OS language and defaults to English.
Fixed clean install not removing legacy HASS.Agent.Companion directories, causing old settings to migrate back.
Fixed tray icon missing in standalone single-file publish by embedding the icon as an assembly resource.
Removed the "MQTT not configured" warning from the General page when HA API is enabled.

10.1.0¶

Added Home Assistant WebSocket API transport for MQTT failover and MQTT-free remote control.
Added HA API settings, connection testing, HTTP warning tooltip, and setup status banners.
Added HA API cross-check for the installed HASS.Agent Home Assistant integration version.
Added Home Assistant update entity publishing and About-page update checks.
Added multi-value built-in sensor attributes and one-click custom sensor generation.
Added per-sensor polling profiles: fast, normal, hourly, and startup.
Added custom sensor value testing without blocking the settings UI.
Improved Windows Update pending detection and release lookup.
Improved service/MQTT setup warnings, About page actions, and tray service labeling.
Switched MQTT topic routing and HA API command targeting to serial_number so device renames do not break commands.

10.0.0¶

Rebuilt the companion client as a modern .NET 10 Windows app.
Added a Windows tray app for interactive user-session features.
Added a Windows service for system-level features that should work without a logged-in user.
Renamed the modern client to HASS.Agent .NET10 so it is clearly separate from the legacy app.
Moved shared settings/logs to C:\ProgramData\HASS.Agent.NET10.
Added MQTT discovery and dynamic Home Assistant entities.
Added a role matrix so features can be handled by Service, Tray app, or both.
Added a configurable sensor catalog and custom sensors.
Added service-aware shutdown/restart/restart-cancel support.
Added a new Windows 11-style icon.