hart2hart

I don’t know if it makes a difference but in the Key, I have “hostname” and you have “IP addresses(es)”

I believe my parameter Key is called hostname not IP addresses

Thanks for the info!

I’m in US. How about $100 plus shipping of buyer choice.

Knowing these are EOL, I found my original Polisy that was only used for about a year. Don’t want to throw it away so does it have value to anyone?

Also what did you migrate from to get to the eISY? Do they have different IP addresses? Has eISY been registered in UD Portal?

Have you installed the latest version of UD mobile?

Ditto what Guy said. It’s what I do for many automations. One question are you wanting to create a favorite tile in UDM so you do it in one step? If so, virtual device plugin is way to go if not you can use Run Then from the program itself.

Sorry unless there is a trick I’m not aware of, eISY will only replace like with like. If they are in scenes remove the old and note adding new into the same scenes. I always do a top level Copy Folder to Clipboard and paste into a text editor for programs os I can search for programs that are impacted. Also I’ve got some REST command that I look through to confirm the old have not been referenced and make plans to update if it is.

FWIW This is what AI says: This message means that the ZFS storage subsystem on your FreeBSD system has run into a severe input/output (I/O) error that it could not recover from, and as a safety measure, it has temporarily frozen (suspended) all read and write operations to the zudi pool. (Note: The prefix Solaris: WARNING is a legacy artifact in OpenZFS code inherited from its original Solaris roots, even when running on FreeBSD.) What is happening under the hood? The Trigger: ZFS tried to read from or write to one of the physical drives (or virtual devices) in the zudi pool, but the underlying storage controller, disk, or driver returned a hard error (e.g., a timeout, CAM subsystem error, or disconnected device). The Suspension: Because ZFS couldn't complete the I/O operation and couldn't safely bypass it without risking data corruption or silent data loss, it suspended the pool. This stops applications from writing half-baked data or reading corrupted state. Current State: The pool is effectively locked in a read-only/unresponsive state until the underlying hardware issue is fixed and ZFS is manually or automatically signaled to resume. Common Causes Hardware Failure: A failing or completely dead hard drive or SSD belonging to the zudi pool. Loose/Faulty Cabling: A loose SATA/SAS data cable, bad backplane, or failing power connector causing the drive to intermittently disconnect. Controller/HBA Issues: An overheating, crashing, or misbehaving disk controller (HBA, RAID controller in IT mode, or motherboard SATA chipset) accompanied by CAM (Common Access Method) kernel timeouts. Driver/Firmware Bugs: A glitch or bug in the FreeBSD storage driver or the drive's internal firmware. How to Troubleshoot and Recover Check System Logs for Clues Look closely at your console output or check /var/log/messages right before the error occurred. You will likely see FreeBSD CAM subsystem errors (such as device timeout, ahci reset, or drive offline) that point to which specific disk caused the failure. Inspect the Pool Status Run the following command to see the state of the pool and identify the offending device:zpool status zudi Check Physical Connections Power down the system safely (if possible, though a hard reboot may be forced since the pool is hung). Reseat or replace the SATA/SAS data and power cables for the drives in the zudi pool. Ensure your HBA/controller is firmly seated in its PCIe slot. Test the Hardware Run a SMART long test on the drives (smartctl -t long /dev/adaX) to check for surface errors or failing hardware. Look for controller firmware updates. Clearing and Recovering the Pool Once you have fixed the underlying hardware issue (e.g., reconnected a cable or replaced a dead drive), you may need to reboot the system or clear the error state to force ZFS to resume the pool:zpool clear zudi If a drive has permanently failed and your pool layout allows for it (e.g., it's a mirror or RAIDZ), you will need to replace the failed disk using zpool replace.

I upgraded today and all zwave devices are working well. The only thing I’d mention for others is that it listed the same firmware version like 3 times in the pick list which I’d assume is different download endpoints. Also, the download portion failed a few times before it finished but eventually got to 100% and the actual FW update/flash was very fast as in only 5-10 seconds. Thanks to others for researching and blazing the trail.

@Javi which version of eisy-ui has the LR capabilites?

Thanks, did you install the 32 or 64 bit version? Clearly out of curiosity, why did you select that one? My only guess is it was 6.7.6 vs other one was 6.7. EDIT: Just reread the thread and I now see you listed the 4th one down and 64bit version

@junkycosmos @Javi @Guy Lavoie Thanks for blazing this trail for me. I'm ready to update FW on the board in prepeartion to adding 3 ZWave LR devices but want to ensure I'm using the cprrect download file from wiki referenced site for the VCP drivers. From following screenshot, can you confirm which is correct from 4 highlighted options. Based on an installer being included in the second option (CP210x VCP Windows) I'm guessing that's the one, but the dates on it are older than the first one. Can you confirm the correct one?

Did you update the bootloader as suggested by original poster?