UNAS Pro integration - monitoring and fan control

cardouken · January 7, 2026, 9:57pm

Since there is still no official support for the UniFi UNAS Pro via the UniFi Network integration, I’ve built a custom integration for it to have monitoring and fan control in Home Assistant.

Available data includes drive temperatures, SMART data, CPU temps, memory usage, storage pool metrics, and fan speeds. All sensors appear as proper HA entities with automatic MQTT discovery.

The fan control system has three modes: let the UNAS manage fans natively (whichever mode is selected in the Drive UI), use a custom linear temperature curve with configurable parameters, or lock to a fixed speed.

Setup is straightforward: the integration automatically deploys monitoring and fan control scripts to your UNAS via SSH, configures systemd services, and handles MQTT auto-discovery. The scripts are designed to survive firmware updates and auto-recover if needed. Everything that was installed by the integration onto the UNAS will also be removed from it when uninstalling the integration.

Key features

One-click deployment of monitoring and fan control scripts
Complete drive metrics: temperatures, SMART health, power-on hours, bad sectors
System monitoring: CPU, memory, storage pools, uptime
Three fan control modes with configurable temperature curves
Automatic recovery after firmware updates
Native HA devices and entities

Requirements

MQTT broker (Mosquitto add-on recommended)
MQTT integration installed
SSH access to UNAS Pro

Currently a known issue to watch out for is that storage pools can be named incorrectly as there’s no real way to pull the storage pool name via SSH. All storage pools are enumerated and then sorted by the storage pool’s UUID where Storage Pool 1 will be the older UUID, etc. This should work in most cases, but can introduce edge cases. The simple fix for this is to just rename the entities to what they should be if they’re set up wrong on initialization.

The integration is available via HACS as a custom repository or manual installation. Full documentation and setup instructions are in the GitHub repository.

GitHub: GitHub - cardouken/homeassistant-unas-pro: Monitoring and fan control for UniFi UNAS Pro with native Home Assistant integration

This has only been developed for and tested on the original UNAS Pro with 7 bays, I’m not sure if it will work on the UNAS Pro 4/8 or the UNAS 2/4. I suspect it might actually work for the UNAS Pro 4 and 8 out of the box as the firmware should be pretty similar between all of them, but it might require some extra configuration on my end to get drive mappings correct if they’re different. It will definitely miss at least 1 drive out of 8 for the Pro 8 since it’s currently only set up to map 7 drives.

It’s very much a beta implementation for now but seems to work overall for myself and the few users who’ve tried it, so I’d be happy to get feedback on things that could be improved or need fixing.

Foeh4mmer · January 11, 2026, 4:40pm

It would be amazing if you managed to implent the ssh shutdown function to connect with a USP / NUT server. Maybe an option to select a entity for a smart switch to turn it on after graceful shutdown

cardouken · January 11, 2026, 6:55pm

I actually have an automation for this myself where my NUT integration connected to the UPS will trigger an SSH command to gracefully shut the UNAS down.

I’m not sure how much of this should be on the UNAS integration side vs just providing an option to shut it down in general. Right now I didn’t implement a reboot/shutdown option just out of abundance of caution, but it would be trivial to just add a button that could then be used with automations/NUT integrations.

Or were you thinking of something else and I’m not following?

Foeh4mmer · January 12, 2026, 7:44am

This is exactly my desired usecase. I have next to no ssh/linux experience, so a work out of the box solition would help alot. But I’d also take your homemade solution as standalone (or the guide you followed^^ )

cardouken · January 12, 2026, 12:37pm

Well my automation would require you to add your HA instance’s SSH key to the UNAS, so if you said you have next to no SSH/Linux experience then that might not be the best approach. I also didn’t really have a guide I followed, it’s just UPS → NUT integration → automation → triggers some shell commands in configuration.yaml → shuts down the UNAS via SSH.

But sure, I can add a shutdown and reboot button to the integration in the next release, not a problem. You’ll just need to use it with some sort of automation and/or NUT integration to make it work however you want.

As for turning it on afterwards using a smart plug, I think that would also fall under the category of things to use an automation for.

Foeh4mmer · January 12, 2026, 12:47pm

That would be amazing. I’m currently stuck ond the shell commands, automations are easy and NUT is up and running to shutdown other appliances.
For the Smart plug I had the Bambulab Card in my mind, but thats just a card config - does not fit into an integration.
I’ll run it over a Tretakt or Inspelning. Thanks!

cardouken · January 12, 2026, 1:40pm

Just added both shutdown and reboot buttons in the latest v0.5.2 release.

Both do it gracefully, i.e. terminate all processes, etc. the same way as shutting down or rebooting via the UNAS would.

Maarten-CH · February 1, 2026, 9:05am

Great integration, loving it!
Yesterday I noticed that when I restart the UNAS Pro (7-bay) I had to manually reload the integration to see any data. I think I didn’t notice this behavior before but I’m not sure. Is there a setting to adjust to auto reconnect and do other users see the same?

Running version 0.7.5
Core 2026.1.3
Supervisor 2026.01.1

cardouken · February 1, 2026, 2:46pm

Hi Maarten, did this happen just once or was it reproducible? Do you remember how long the UNAS was actually already up and running without any data still coming into HA - was it more than 2-3 minutes with no data in HA?

I did make some changes a while ago to how polling for drives works, but it shouldn’t affect polling after reboots - it should just start reporting sensors as soon as SSH becomes available on the UNAS after a reboot. I can check tomorrow if this also happens with my setup, but any info about how exactly it happened for you in the meanwhile would be useful to know.

Maarten-CH · February 1, 2026, 4:06pm

Yes, it is reproducible.
I just did a test and waited 10 minutes after turning on but no entities became available. After these 10 minutes are reloaded the integration and 30 seconds later all readings appeared.

cardouken · February 1, 2026, 4:30pm

Thanks, that’s helpful. I think I might have some idea of why it might be happening. Will check on my UNAS tomorrow and hopefully push a fix asap.

cardouken · February 2, 2026, 10:17am

Hey, found the bug, fixed it and just and pushed a fix in the latest v0.7.6 release. I also fixed a related issue where the chosen fan mode and fan curve settings were reset to defaults after a UNAS reboot, now it should remember what the last HA states were and use those, as originally intended.

Thanks for bringing this up! I did test this on my setup a few times to ensure it works, but do let me know if you still have any issues.

Maarten-CH · February 2, 2026, 5:35pm

I just ran a test and the data showed up within two minutes after booting up.
Thanks for the fix!

andrew6 · February 3, 2026, 2:50am

This looks great and I’ve just installed it. One thing I’ve been looking into is backup status and/or triggering backup tasks

Key example I have is that I can start/stop an application via HA (in this case by stopping the Proxmox LXC) and would like to be able to stop the LXC, run the backup and then start the LXC after the backup is complete. Is this accessible via SSH to include in the integration?

cardouken · February 3, 2026, 10:49am

So I did some digging and to my surprise, it is actually possible and not all that complicated. I thought this would have been only possible via the OS/Drive UI, but there are some internal API-s that allow fetching and triggering existing backup tasks.

Doesn’t seem like there’s any easy way of checking the backup status to see how far along a backup is exactly like it does in the UI, but it can report the current status, timestamp of the last completed run, etc. So it should be possible to create some sort of automation for this that would check for those timestamps/statuses.

I can take a stab at it, but I would want to test this for a while first and iron out any potential bugs before putting it into a public release. If you’d like to be able to test drive it before I release it publicly, then once I have something that looks like it could work, I can give you a link to a feature branch in the repo that you could install to your HA instance manually?

Edit: was simpler than I thought and since it’s not really affecting anything else in the integration, I can probably push an initial version of this later tonight in a public release. Just need to work out some minor issues, will let you know when it’s available.

Edit 2: Available now in the latest v0.8.0 release. I was only able to test this with Google Drive and on my specific setup, so do let me know how it works on yours (and if using another cloud service/destination then if everything is good with those too).

It will show up under the UNAS integration as a separate service, one for each backup task that’s configured on the UNAS via the Drive UI.

andrew6 · February 4, 2026, 5:57am

Thanks a tonne! Wow that was fast… Just went into HA at lunch time and saw the update and related notes… I’ve already upgraded and it looks pretty good

Will do some changes tonight and let you know in the morning the outcome of the backup automation mentioned

andrew6 · February 4, 2026, 6:20am

FYI - here is the automation I’ve put together. So far I have disabled the schedule via this integration and also tested triggering a backup which looks good

Here is my automation in YAML:

alias: "M-NAS Backup: Immich"
description: ""
triggers:
  - trigger: time
    at: "03:00:00"
    id: Start
conditions: []
actions:
  - action: button.press
    metadata: {}
    target:
      entity_id: button.lxc_aw_immich_110_shutdown
    data: {}
  - wait_for_trigger:
      - trigger: state
        entity_id:
          - binary_sensor.lxc_aw_immich_110_status
        to:
          - "off"
        for:
          hours: 0
          minutes: 0
          seconds: 30
  - action: button.press
    metadata: {}
    target:
      entity_id: button.unas_backup_immich_to_s_nas_run_backup
    data: {}
  - wait_for_trigger:
      - trigger: state
        entity_id:
          - sensor.unas_backup_immich_to_s_nas_last_run
        from:
          - unknown
        for:
          hours: 0
          minutes: 0
          seconds: 30
  - action: button.press
    metadata: {}
    target:
      entity_id: button.lxc_aw_immich_110_start
    data: {}
mode: single

M-NAS is my primary UNAS (UNAS-Pro)
S-NAS is my secondary UNAS (UNAS-2)

This is a screenshot of a backup in progress (“Source” hidden for privacy but shows all paths correctly)

During a backup task, “Last run” becomes “Unknown” and “Last run duration” becomes “Unavailable”

Once complete, these fields populate so this is what I’ve used to confirm the backup is finished (regardless of completion status)

cardouken · February 4, 2026, 9:25am

Glad the integration is working for you so far, and with UNAS to UNAS backups too!

I’d actually advise against using those unknown/unavailable statuses for automations. That’s an oversight on my part I plan on fixing in a patch release in a few minutes so it would always use values from the latest started backup task.

It works for now in v0.8.0, but it’s clunky since unknown/unavailable can mean almost anything, and with unlucky timing could even trigger one of your automation steps if the entities go unavailable for some unrelated reason and come back up within your specified time window.

Best to use the status entity directly, trigger when it changes from in-progress to a terminal status like succeeded, partially-successful, or failed. The full list of statuses (named exactly as they appear on the UNAS):

pending (task created, but no backups ran yet)
in-progress
succeeded
partially-successful
failed

andrew6 · February 4, 2026, 11:32am

Thanks, and I’d definitely prefer the specific options as you mentioned, but without knowing the exact detail I went with “safe enough” and the automation ran successfully this evening (manually triggered so the 3am trigger will run for the first time overnight)

Have now adjusted based on the above statuses

alias: "M-NAS Backup: Immich"
description: ""
triggers:
  - trigger: time
    at: "03:00:00"
    id: Start
conditions: []
actions:
  - action: button.press
    metadata: {}
    target:
      entity_id: button.lxc_aw_immich_110_shutdown
    data: {}
  - wait_for_trigger:
      - trigger: state
        entity_id:
          - binary_sensor.lxc_aw_immich_110_status
        to:
          - "off"
        for:
          hours: 0
          minutes: 0
          seconds: 30
  - action: button.press
    metadata: {}
    target:
      entity_id: button.unas_backup_immich_to_s_nas_run_backup
    data: {}
  - wait_for_trigger:
      - trigger: state
        entity_id:
          - sensor.unas_backup_immich_to_s_nas_status
        for:
          hours: 0
          minutes: 0
          seconds: 30
        to:
          - succeeded
          - partially-successful
          - failed
        from:
          - in-progress
  - action: button.press
    metadata: {}
    target:
      entity_id: button.lxc_aw_immich_110_start
    data: {}
mode: single

Maarten-CH · February 5, 2026, 9:23am

Maybe an edge case but…
When HA is rebooted when the UNAS is off it will not automatically connect when the UNAS turns on again and a manual reload of the integration is then needed.
I tried twice with the same result using version 0.8.1.