stevesreed

adding the following to /etc/rc.conf got me back up and running: vm_enable="YES" vm_dir="zfs:zudi/vms" vm_list="homeassistant" NOTE: my zfs setup is a bit odd, it's probably vm_dir="zfs:/storage/vms" for anyone who set it up with the script that was available later to set things up.

Everything is running now, except I've lost my Home Assist VM. Trying to recover that now.

I was also having issue with loging in to PG3x, so I assume UDX was not working for some reason. A full system reboot seems to have fixed both the PG3x login issue and the update not working.

I clicked the "upgrade packages" button in the admin console, but nothing seems to happen. The console never closed or became unresponsive. The version in the admin console "About" dialog box is still v5.8.4 and the unix version is still "FreeBSD eisy 13.2-RELEASE-p11" What the best way to see what happening?

I got that initially, but I tried again later and it worked fine. I'm not sure what changed. Maybe it was fixed with 2024.4.2, which came out yesterday, but maybe after my first attempt and before my second?

I had Schlage connect previously and the battery levels were coming through. I currently use Yale Assure locks, with the 700 series Z-Wave modules. It's possible the separate sensor was added when I switch to the HACS version of ISY integration, but there was some sort of battery info available before that. I switched to the HACS version to fix an issue with lock batteries showing up in Homekit as 0% (though they were correct in HA), and have not had any issues with it.

Z-Wave lock battery levels show up for me as a sensor in HA. Isy's lock "ZY 091 Front Door Lock" battery status shows as "sensor.zy_091_front_door_lock_battery_level" in HA. I am on the HACS beta version of the ISY integration, so YMMV.

Quick update: After using pkg update -f. I ran the script again, modified for 4GB memory and 500G disk space, and it worked perfectly. I restored a current back up from the RPi4 HA setup and it worked perfectly. All integrations, including HACS integrations, and add ons, automations, etc. just worked, no adjustments needed. And HA seems faster than previously on the RPi4. I've now removed the RPi from my network altogether, and have IoX and HA running on eisy for a nice, clean, one box solution. Very cool!

"sudo pkg update -f" fixed the issue for me. Thanks!

{ url: "http://pkg.FreeBSD.org/${ABI}/latest", enabled: yes, priority 1 }

I was trying the suggestion from @ndfan77, to get past the issue without renaming the /usr/local/etc/pkg to get past the no packages available issue when running the script. pkg: No packages available to install matching 'vm-bhyve' have been found in the repositories pkg: No packages available to install matching 'edk2-bhyve' have been found in the repositories pkg: No packages available to install matching 'wget' have been found in the repositories pkg: No packages available to install matching 'qemu-tools' have been found in the repositories

I'm stuck on the no package available issue as well. I tried "sudo pkg refresh -f", but I get: "pkg: unknown command: refresh" So I'm stuck.

Thanks. That kills the node process, but editing rc.conf does not seem to stop it from restating on the next reboot. though the overall memory usage seems to be down now. I'll see if it goes up over time. last pid: 4593; load averages: 0.19, 0.16, 0.08 up 0+00:05:27 07:01:41 41 processes: 1 running, 40 sleeping CPU: 0.0% user, 0.0% nice, 0.1% system, 0.0% interrupt, 99.9% idle Mem: 184M Active, 98M Inact, 23M Laundry, 599M Wired, 6730M Free ARC: 123M Total, 21M MFU, 89M MRU, 219K Anon, 1447K Header, 8165K Other 85M Compressed, 210M Uncompressed, 2.48:1 Ratio Swap: 4096M Total, 4096M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 1898 isy 30 20 0 256M 86M nanslp 2 0:08 0.63% isy-freebsd-x64 2636 isy 1 20 0 31M 18M select 2 0:00 0.05% mosquitto 1206 nobody 1 20 0 20M 7716K select 0 0:00 0.04% mosquitto 3430 polyglot 11 20 0 4459M 124M kqread 2 0:01 0.03% node 3469 admin 1 20 0 14M 3764K CPU2 2 0:00 0.02% top 1549 root 6 52 0 81M 15M uwait 1 0:00 0.01% udx-freebsd-x64 1186 ntpd 1 20 0 21M 5396K select 2 0:00 0.01% ntpd 3192

I have not set up the HA VM yet, but I checked HA running on my PI4, and it's using 1.5G, so I'll probably set the VM to 2G. The eisy only has 8G, and since I don't have any node running, it's currently using only 3.4G. so there should be room to borrow 2G. Ideally, I'd like to give even more memory to HA, since most of my complex automations are run from HA (node red is super powerful compared to if-then programs on IoX) @Michel Kohanim A large portion of the 3.4G memory usage on eisy seems to be from the node server. If I don't have any nodes, is that something I can disable, or does it always have to be running for IoX to work?

It could just be my imagination, but rebooting does feel faster. That's the only difference I've noticed so far.

I was trying to avoid changing the script file, but if you're editing it anyway. You can just add a single line to the end of the script: setup_nvme_boot which will call the function to start the process.

after running with bash -c "source ~admin/setup_nvme_boot.sh; setup_nvme_boot" everything works correctly. rebooted and everything is up and running on a big, fast SSD [admin@eisy ~]$ gpart show => 40 1953525088 nvd0 GPT (932G) 40 131072 1 efi (64M) 131112 1927282688 2 freebsd-zfs (919G) 1927413800 8388608 3 freebsd-swap (4.0G) 1935802408 17722720 - free - (8.5G)

To get the script to run I had to use: bash -c "source ~admin/setup_nvme_boot.sh; setup_nvme_boot" To get the function to be called in the shell script.

It looks like it might not work actually, due to the portal migration not allowing you to go back to an old ISY once migrated away from it. "Please note that a license transfer is permanent. It will not be possible to migrate the license back to the original ISY."

I'm moving to eisy this week, and was wondering if I should keep the polisy as a back up incase the eisy ever goes down. Has anyone restored an IoX backup that was made on an eisy to a polisy? I don't have any plugins, just a bunch of Insteon and zwave devices and a few simple programs (most complex automation is done in HA) Since the my Insteon PLM and Zmatter board are usb, moving them back and forth is easy and quick. If recovering from a failed eisy is as simple as updating the polisy to the latest and restoring a IoX backup, it seems like keeping it is worthwhile.

I had the same failure on Friday. 100% full SSD. Michael checked several things, and we decided corupted SSD/file system is the likely cause, so restoring SDD from an image was the best course of action. Here the process, though I'd wait until support contacts you, just incase they want to see if they can find the source of the missing disk space: https://forum.universal-devices.com/topic/42174-polisy-ssd-image-restore-process-for-a-corrupt-ssd/ My eisy arrives tomorrow, so I'm glad to hear the restore from polisy backup to eisy should be smooth and painless...

I removed and re-added my i3 Paddle after upgrading to 5.6.3, but it still says it's an i3 Switch in AC, and there is no % dim value shown, just on/off status. Are you seeing the dimmer values somewhere else?

That is a great idea! Thanks. I have a notification when I leave the door unlocked for more than 5 minutes, and they are getting annoying. This should "fix" the issue for now.

The thread you linked from @bumbershoot is talking about the i3 Dial working as expected. I have not seen any posts about the i3 Paddle working, nor has it been listed as working in any release notes.

I did not open a ticket, since they never listed it as working yet. As a software engineer, I hate getting bugs reports about planned features not working when that have not been released yet.