Hmm yeah, I can see why. SSH connection fails and it doesn’t try to automatically reconnect. Reloading does and thus fixes it. I’ll push a fix for this once I’m able to reboot my UNAS and actually test it, most likely some time around Saturday/Sunday.
And don’t take this the wrong way, but just curious as to how come you’re rebooting your devices this often? It really is valuable input given that I did try to cover most cases of UNAS/HA reboot combinations, but apparently not all of them, so it’s good to have someone point these issues out. But just wondering…
I installed the UNAS but I’m still waiting for my drives to arrive.
So I inserted the one drive I have and started playing with the home assistant integration. And since it’s not doing anything I turn it off after playing with it
Haha, alright makes sense. Since you’re already playing around and rebooting often anyway, would you be up for trying the fix since I can’t verify it myself right now? It would definitely help figure out if there are any issues with it quicker + you’d potentially have a working/fixed version. I pushed it to the develop branch, it just requires installing manually instead of via HACS: GitHub - cardouken/homeassistant-unifi-unas at develop
I’m happy to try but I’m not so familiar with HA so sorry for these basic questions.
I downloaded the ZIP via the green <> Code button on Github and located the custom_components/unifi_unas folder.
That folder seems to contain many more files than what I downloaded.
Should I delete all the content and replace it with the downloaded files?
It should be the same minus the __pycache__ directory on the HA instance.
Might be simpler if you just take the __init__.py and manifest.json files from the downloaded archive (only files that changed, the rest is the same) and overwrite those files on your HA instance in config/custom_components/unifi_unas. Then reboot HA and it should show version 0.8.2-dev.
But deleting is otherwise fine too, I’m just not 100% sure what you’re seeing, but if it’s the pycache directory files you meant then yes, all good to delete and just copy everything over as well.
I replaced the two files (it showed version 0.8.2-dev) and I ran the test 3 times.
Every time the UNAS sensor reading showed up when starting the UNAS after the HA reboot. Nice!
I also observed a new behavior: After the HA reboot when the UNAS was still off the sensors were showing the last readings again. Even when these were at “unavailable” (UNAS is off) when HA was rebooted. These go back to the expected “unavailable” after 2-3 minutes.
Could you expand on this part a bit more, just so I fully understand:
I also observed a new behavior: After the HA reboot when the UNAS was still off the sensors were showing the last readings again. Even when these were at “unavailable” (UNAS is off) when HA was rebooted. These go back to the expected “unavailable” after 2-3 minutes.
You mean all sensors (not just fan control/curve parameters) were showing old values for 2-3 minutes after HA restart? Were those readings the last values reported from when the UNAS was on? And you were definitely not experiencing this with v0.8.0 or v0.8.1?
If so, then I probably have an idea as to what’s happening. It’s now allowing MQTT subscriptions even when it can’t connect to the UNAS via SSH to allow for sensor data to start coming in once the UNAS comes up, so I’ll have to tweak it a bit more then.
This has been running successfully through a few cycles (I’ve manually kicked it off)… now I just have an issue with the Proxmox integration not starting the LXC properly
Yes, all values like CPU usage, CPU temperature and so on (also for the disk).
I can’t say if they are identical to the values at shutdown but they are sensible values.
I am pretty sure that this was not the case in the older versiosns
Can you try now? Same develop branch, but need to replace the mqtt_client.py file this time. It will still show as 0.8.2-dev after HA reboot, but it will apply the change which should fix it I think.
I replaced the mqtt_client.py file, did a few runs and it worked!
No old values showed up after rebooting HA and it reconnected to the UNAS automatically after the NAS booted up.
Many thanks!
Great! I’ll be able to run some tests myself later tonight hopefully and if all is good, push a new release today/tomorrow. You should just see a new version update via HACS to update to with these changes included.
Did some testing myself as well and it does seem like it’s working now. Thanks for noticing these and helping with testing!
Just deployed release v0.8.2, once HACS updates (or you force a refresh) then you should just be able to update from 0.8.2-dev to 0.8.2 normally via HACS.
I’m very tempted to try this integration, but because it installs scripts and daemons on the UNAS via SSH, I’m still on the fence.
I mean, I’m afraid to crash my recently acquired and configured UNAS-Pro as well as to loose any support from UI if a support file reveals the system has been tampered with.
So, is there some kind of button to “undo” all changes made via SSH ?
I’ve seen in the readme that deleting the integration should do that automatically but I don’t understand how ?
I thought deleting an integration did just that, deleting, so is there a special mechanism that allow an integration to “know” it is being deleted and triggers a housekeeping task ?
Could you elaborate a bit on this matter ?
Thanks.
Home Assistant provides an async_unload_entry callback that integrations can hook into when they’re removed, which is where all the cleanup runs. The removal logic and everything that gets removed can be seen in the code here. In short, when you remove the integration through HA, it SSHes into the UNAS and removes the two systemd services and their supporting files, uninstalls the 3 dependencies (mosquitto-clients, paho-mqtt, python3-pip), and resets the fans back to UNAS Managed mode. Everything in /tmp would get wiped after a reboot anyway, but I included it all in the cleanup so it’s easy to see exactly what the integration creates on the device.
If HA can’t reach the UNAS during removal for whatever reason, you can always SSH in and run those commands manually to get back to stock. A firmware update would also restore it since it wipes all installed dependencies and services (only the two script files in /root survive, but without their systemd units or dependencies they do nothing). So from Ubiquiti’s perspective, the device would look completely untouched after a firmware update unless they have some very detailed support file somewhere - but given how difficult it has been to find some system logs older than 1 day on the UNAS, I’m not too convinced about that…
Overall the integration is fairly non-invasive. The only thing that modifies anything on the UNAS is using a fan mode other than UNAS Managed. Everything else is just read-only monitoring with standard Linux tools (df, smartctl, /proc/stat, etc.).
