hart2hart

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?

Thanks, @Javi Did you update yours to the latest version 7.46? Alos, did you update the bootloader?

Thanks, Javi. I'm planning to install 3 Long range devices soon. So I'm clear, you're saying I'll need to update the ZMAtter FW to be able to use it -- correct?

Thanks for this post. I’ve just been researching the FW on the dongle as I prepare for ZWave LR.

That’s likely a macOS issue. Apple removed support for Java recently.

Which version are you running? At some point a sunset/sunrise issue was introduced and I think it’s fixed in the staging repository versions.

It supports multiple thermostats. I have 3. I put their IP addresses in config separated by semicolons.

Michel and the UD team provide world class customer service. I too am confident they will deliver eISY-ui as upgrade and replacement for Java based AC. It’ll just continue to get better.

You’ve got pending updates to those battery powered devices. You’ll need to wake them and and then click on the green arrow next to each to update them.

Of the zwave dongle choices listed above, I’d be prone to favor the sonnoff because based on measurements it is possibly that’s a full 1/2 wave dipole antenna. Thoughts?

Do you mean ZMatter board installed in Polisy? I’m not aware of a way to put it in eISY.

I think there is an item in release notes for either beta or staging update repo saying it includes a fix for calculation of sunrise or sunset times.

It’s likely handled as if it were an eISY program behind the scenes.

To be clear, I looked at it on UD Mobile to post about number of Insteon devices. All counts were 0. I then went to restart it and saw it was disconnected and a message about upgrade being available. Upgraded and it still was disconnected.

I’ll definitely post results but sorry to pre-disappoint as they are all mains powered. I had read something similar on the results as they only talk to hub and are not constantly repeating within the mesh. I may consider expanding zwave usage if it all works as expected. I’m a big Insteon user with between75 and a 100 devices. I got into zwave for deadbolts and then expanded it when Insteon SyncroLincs died. At this point, the only important devices are for energy reporting needs. Retired zwave deadbolts a few years ago.

Same here.

Thanks, Michel. They are on my desk awaiting their install!

Thanks. I’m looking so forward to repositioning my very small zwave network from mesh to star topology with 6.1.2 Long Range update. Most of my zwave network is there only to provide mesh for critical devices that provide energy information to detect that the device is currently pulling current.

Did you update date from the Staging repo?