apnar

This was unfortunately the last straw for me. After 15+ years on ISY, then polisy and then eisy, I gave up and moved to the native Insteon integration in Home Assistant. My house is currently in shambles automation wise as I work to reconstruct everything that I used to have on the eisy in HA and NodeRed but hopefully when I'm done it'll be more reliable. I was very close to pulling out the old 994i, installing a pre-node server firmware (4.x if I recall correctly) and letting that handle my Insteon network as I have such fond memories of how reliable that was. I decided to go the HA route though and try to contribute there to make it into a better product. It seems what I want to use the eisy for, rock solid Insteon network management, and what Universal Devices wants it to be (adding in matter and all the various other plugins and such to be a full automation hub) just aren't aligned anymore and the direction they're taking is negatively impacting what it used to do so well. It used to take 5 minutes to replace a failed device now it's over 30 minutes and doesn't always work. I've had the isy part of the eisy hang multiple times where I can SSH to the box no problem but the isy software is unresponsive. And now these 0 sized device records have forced me to remove and readd a handful of devices which was quite time consuming. I even just renamed a device in the console and the System Busy prompt popped up for like 5 minutes. It used to be such a time saver and now I find myself cursing at it. Anyway, apologies for the rant. Best of luck getting your system stable.

Yes. I deleted and redid my fan button scenes and they seem to be behaving now so that may have just been a fluke.

Long time user with lots of Insteon equipment and what I thought was pretty reasonable knowledge of the Insteon protocol and isy software but I'm running into some issues so thought I'd come back to the forums and see if anyone has some thoughts. I've moved mostly to home assistant but still love the eisy for insteon management and use it primarily for that so don't spend as much time in the interface as I used to. I feel like I may be running into some bugs in the eisy and would like to get a sense if other people are having these issues or it's just me. I had a power outage and it seemed to have fried my PLM (eisy is on UPS and stayed up), I replaced it with a spare and used the eisy to do the swap. Most of my house seemed to get updated fine with the new PLM address but for some reason most KPLs didn't and I've been having to factory reset them and restore them. This brings me to my first odd issue, some of my KPLs have had their database record in the eisy zeroed out. Logs complain about not being able to read the file and if I look in /var/isy/FILES/CONF/ on the eisy I see the file (XXXXXX.REC) there but of zero size. This happened once before and I removed those devices and readded them to fix it. This time it was three different KPLs. Both times it only happened to KPLs. My next odd issue is these are all 6 button KPLs tied to fanlincs, so the 4 middle buttons have mutually exclusive buttons for fan speed. I've done it the exact same way with a scene for each speed for 15+ years. When I readd these KPLs and set them up from scratch the buttons don't work correctly anymore. When you hit Fan Low instead of that light coming on the other three do. Fan High turns them all on. I've double checked my scenes and they look the same as other ones that are working. I'm wondering if some how the eisy isn't setting up the insteon scenes properly any more. Lastly, everything is soooo sloooow and it didn't used to be that way on the old 994i. Things should be so much faster on the new hardware. I don't even know what it's doing I just stare at the "System Busy" progress bar which very slowly goes to 100% then happily starts over again and again. I pull up the event viewer and there is nothing going over the wire. I look at the OS and it's using barely any CPU. I had to do a switch swap and it took over 30 minutes. Anyway I'd love any thoughts or suggestions on how to stop the database from becoming corrupt or fixing my KPL scenes.

@bmercier Is this the future direction of the platform or just short term for easy testing? One of the main appeals for me of the ISY devices over the years is they can be run 100% locally with the cloud stuff being optional. Tying local device management to cloud credentials would obviously contradict that. Regardless, exciting to see a replacement for the admin console in the works. I have a straight forward all Insteon setup and the install went smoothly. Only annoyance was having to add a manual entry for 8443 back to the launcher finder as mentioned by others.

It won’t help but I had the same issue using the hue emulator built into Home Assistant. Stood it up and the harmony didn’t detect it. I eventually gave up and just used an automation based on something else in the system turning on/off.

That sucks. Are you still running in mirrored mode or did you move fully to nvme?

What is the issue that is making you think you need to revert?

@tazman thanks for giving it a try. Took me a bit but I tracked down the issue. I use a significantly bigger sized virtual disk in my setup but had dropped it down to 16GB when I uploaded it to match what was in the original script. Even though the OVA file from HA is only 800MB they have it configured as a 32GB virtual disk so when it was trying to be copied to the smaller 16GB volume it errored out. Guess that's what I get for thinking a small tweak wouldn't cause any issues. As to the error on line 126, I'm not seeing that but suspect it might be related to posting the shell script on the forum. So I added some extra quoting and I'll upload it as a file here in addition to pasting it. Updated version: #!/bin/sh # Where do we want to storge VM resources (ZFS pool name and mount path) VMFILESET="storage/vms" VMDIR="/storage/vms" # Home Assistant VM name and how much resources to allocate HA_VM_NAME="homeassistant" HA_VM_CPU="2" HA_VM_MEM="1G" HA_VM_DISC="32G" # specify network interface - by default it's Ethernet re0 INTERFACE="re0" if [ $(id -u) != "0" ] then echo "Must be run with sudo" exit fi # Automatically pick the latest release from https://github.com/home-assistant/operating-system/releases/ HA_IMAGE_URL=$(curl -sL https://api.github.com/repos/home-assistant/operating-system/releases/latest | \ grep "browser_download_url.*haos_ova.*qcow2.xz" | sed -e 's/.*: "\(.*\)"/\1/') # Internal variables TMPDIR=`mktemp -d` IMAGE_NAME="${TMPDIR}/haos_ova-x86-64.img" VM_CONF=${VMDIR}/${HA_VM_NAME}/${HA_VM_NAME}.conf # make sure ifconfig_DEFAULT is not set as it causes tap0 interface issues # ensure re0 is set to DHCP sysrc -x ifconfig_DEFAULT sysrc ifconfig_re0="DHCP" echo "Make sure necessary packages are installed" pkg install -y vm-bhyve edk2-bhyve wget qemu-tools echo "Prepare /etc/rc.conf" sysrc vm_enable="YES" sysrc vm_dir="zfs:${VMFILESET}" # this makes Home Assistant VM start up automatically on boot, comment out if this is not desired sysrc vm_list=${HA_VM_NAME} echo "Create ZFS fileset for VMs and prepare templates" zfs create ${VMFILESET} vm init cp /usr/local/share/examples/vm-bhyve/*.conf ${VMDIR}/.templates/ # create VM networking (common for all VMs on the system) vm switch create public vm switch add public ${INTERFACE} echo "Downloading image" wget -O ${IMAGE_NAME}.xz ${HA_IMAGE_URL} echo "Extracting..." unxz ${IMAGE_NAME}.xz echo "Creating a VM" vm create -t linux-zvol -s ${HA_VM_DISC} ${HA_VM_NAME} echo "Image info:" qemu-img info ${IMAGE_NAME} echo echo "Copying image... (may take a bit of time)" qemu-img convert ${IMAGE_NAME} /dev/zvol/${VMFILESET}/${HA_VM_NAME}/disk0 rm -rf ${TMPDIR} GRAPHICS=0 echo -e "\n\nDo you want to enable unauthenticated VNC access to your Home Assistant virtual machine? (y/N)" read answer if [ "$answer" = "Y" ] || [ "$answer" = "y" ] then GRAPHICS=1 sysrc -f ${VM_CONF} graphics="yes" fi ## Initial setup TMPDIR=`mktemp -d` # set zvol to full so partitions are visable zfs set volmode=full ${VMFILESET}/${HA_VM_NAME}/disk0 sleep 2 # set baud rate for serial console mount -t msdosfs /dev/zvol/${VMFILESET}/${HA_VM_NAME}/disk0p1 ${TMPDIR} # add serial console to linux boot command line sed -i '' -e 's/console=ttyS0/console=ttyS0,115200/' ${TMPDIR}/cmdline.txt # umount device umount ${TMPDIR} SSH=0 echo -e "\n\nDo you want to enable SSH access to your Home Assistant virtual machine? (y/N)" read answer if [ "$answer" = "Y" ] || [ "$answer" = "y" ] then SSH=1 ## SSH Access # install ext4 fuse driver and load it pkg install -y fusefs-lkl kldload fusefs # mount vms /root/.ssh directory lklfuse -o type=ext4 /dev/zvol/${VMFILESET}/${HA_VM_NAME}/disk0p7 ${TMPDIR} sleep 5 mkdir -p ${TMPDIR}/root/.ssh chmod 700 ${TMPDIR}/root chmod 755 ${TMPDIR}/root/.ssh # create a new SSH keypair and at it as an authorized key in the VM ssh-keygen -t ed25519 -N "" -C "Access Home Assistant running on eisy on port 22222" -f /home/admin/ha-ssh-key cp /home/admin/ha-ssh-key.pub ${TMPDIR}/root/.ssh/authorized_keys # set perms so admin user can access the ssh keys chown admin:admin /home/admin/ha-ssh-key* umount ${TMPDIR} fi ## Clean up # switch zvol mode back to normal zfs set volmode=dev ${VMFILESET}/${HA_VM_NAME}/disk0 sleep 5 rmdir ${TMPDIR} sysrc -f ${VM_CONF} loader="uefi" sysrc -f ${VM_CONF} cpu=${HA_VM_CPU} sysrc -f ${VM_CONF} memory=${HA_VM_MEM} vm start ${HA_VM_NAME} vm info ${HA_VM_NAME} vm list echo -e "\n\n##########################################################################\n" echo "Please wait about 10 minutes and follow instructions at https://www.home-assistant.io/getting-started/onboarding/ to get your Home Assistant setup" echo "ISY integration: https://www.home-assistant.io/integrations/isy994/" echo -e "\nIf you need console access to the HA VM you can run \"sudo vm console ${HA_VM_NAME}\" then log in is as root. Use \"~~.\" to exit." if [ "$GRAPHICS" -eq "1" ]; then echo -e "\nYou can access your HA VM via VNC on port 5900 at your eisy's IP address." fi if [ "$SSH" -eq "1" ]; then echo -e "\nYou can access your HA VM via SSH using \"ssh -p22222 -i ha-ssh-key root@{HA VM IP}\"" fi md5 of script is 93f64d030f2531578df06c46d35c8056 create_ha_vm.sh

I finally had a few cycles to take a look at this. I wrote up a modified script that will use the VM based Home Assistant images instead of the one meant for bare metal. I also added some other tweaks that allow you to choose to enable access to the VM via console, VNC, and SSH during install. Unfortunately there isn't an easy way to "fix" an existing install so you'll need to start from scratch or you can try backing up and restoring your HA config but no guarantees there. To start this will delete your current VM and all related configs. It will completely destroy your existing Home Assistant VM so only run this if you want to start fresh or are sure you have all the backups you need. sudo vm poweroff -f homeassistant sudo vm destroy -f homeassistant sudo vm switch destroy public sudo zfs destroy storage/vms Here is a new create_ha_vm.sh script. Save it and run it with sudo. see updated version below @Michel Kohanim it might be worth updating the blog post with this script so new installs get the proper image.

The error is legit, but it is just a warning. The script on the blog uses the generic x64 OS image instead of one of the VM tailored images. They don’t have a FreeBSD VM image specifically but when I have some time I’ll see if I can get one of the other VM images running instead. For now it should be reasonably safe to ignore.

Looks like the partition table on your NVME drive is corrupt somehow. You can try recreating it with: sudo gpart destroy -F nvd0 sudo gpart create -s GPT nvd0 Then reboot and retry the same commands from my message above to see if you get better results. Might also be worth trying reseating the NVME drive physically.

The scripts as they exist today appear to all be one way. If you want to go back to a mirror I could likely put together some commands you could run. If your drive dies support should be able to help you get the base OS back. You should be backing up your configs though.

What does “sudo gpart show nvd0” show? And “dmesg | grep nv”?

I suspect that this will be an issue for anyone with a zpool beyond the default eisy one(zudi). So folks that still boot from eMMC and add a drive, folks that mirror or boot from NVME and added an extra pool. Basically anyone that has an extra zpool (most likely called /storage). Easy enough to test, just reboot and see if /storage is there (or visible is in “zpool status”). Should be no harm in creating the directory: “sudo mkdir /etc/zfs” You may need to do a “sudo zpool export storage” then “sudo zpool import storage” to then get the correct cache file created once the directory is there.

@Michel Kohanim Ran into another small issue. On reboots my zfs pool /storage wasn't mounting automatically. It worked fine if I did a "zpool import storage" after boot. I tracked down the issue to a missing /etc/zfs directory which stopped the creation of the normal zpool.cache file. It's possible that it's something I missed in my manual steps recovering from the issue above but I don't see it created in any of the scripts. So I'd suggest adding a line to the scripts somewhere to creates /etc/zfs.