junkycosmos

@wmcneil - I asked Gemini and it gave me those details. Surprised you could update to 7.45 but not 7.46 / did you confirm the bootloader version updated? You noted the failures are during the % # counting up? For some reason my guess what that the % counting up (was pretty slow for me) was download of firmware from their site to the USB dongle then the dongle restarting to load it. Only reason I think to note this is IF the DL process is still in the flow where you are seeing failures brings their servers back into factor. @Javi - Thank you for chiming in here. Have a question about your earlier statement (of EISY allows you to choose between Mesh and LR) and also what I see in EISY UI (in Zwave region of US or LR) - from what I read on LR it is listed as fully backward compatible to prior ZW. Is that incorrect, or more to the point - IF we set EISY to LR do we expect our mesh ZW devices to keep working as before? Also, in terms of enabling LR - on my EISY UI Zwave page I saw region was set to US LR - however - when I checked z-wave.me web tools page (with USB dongle in PC) the LR option showed unchecked (dongle on 7.46) - So with that in mind I did go to the more options link and "ordered" the option to enable LR, received the email which only included a link order # (no hex code and no QR code) . Clicking the link in the mail gives ""error":"License not found"}" https://service.z-wave.me/hardware/capabilities/checkout/?zme_order_id=##### (redacted my 5 digit order) AND of course, when I go back to the more options link their system shows that my UUID has the LR feature licensed. Any creative ideas on how to push the LR license into my USB dongle ? Thank you again for the inputs J ps. I do see that the web tools page now lists 7.47 but Gemini notes (pasting here since our G buddy can be rather wrong sometimes too) No, do NOT flash 00.00.07.47 - Controller if you intend to use this USB dongle with your Universal Devices eisy. Here is why: IoX Compatibility: Universal Devices' IoX engine on the eisy specifically expects the official Z-Wave 7.42 firmware. Newer Silicon Labs SDK builds (like 7.47) alter low-level Serial API definitions that will cause IoX to fail to initialize the Z-Wave chip or stop communicating with the stick.

Cannot speak to better performance or anything yet - my efforts here are in prep to "move" my old Insteon + Zwave network from ISY994 over to EISY. My current old Zwave stuff here is very old so will be "rebuilding" the zwave from scratch. I did the update on Windows 11 PC - installed the universal driver on the 1st link (in UD WIKI) and then ran the web tools from edge browser (links here ZMatter USB Dongle Firmware Upgrade - (Eisy:User Guide - Universal Devices, Inc. Wiki) /) Sorry cannot answer IF this wiped my controller as I also did a dongle factory reset afterwards

How are you handling multiple phones doing geofences on same 1 EISY with UD Mobile? What is best practice? requirements each phone can update unique variable on EISY 2-3 users/phones per site (each site single EISY) old world moving from the old world of Mobilinc where we had mobilinc on each phone going to ISY under 1 admin user but each phone would set its own geofence and control unique variable on ISY these variables are driving few different programs such as locks etc New World Question Can (should?) each users phone have a unique ID to login to UD Mobile ? - if so what is process to create multiple logins to EISY for UD Mobile Appreciate any suggestions here. I have a few (maybe) logical guesses here but rather hear tips from others in similar situations

I found from EISY migration WIKI the directions to update ZMatter USB Dongle Firmware Upgrade - (Eisy:User Guide - Universal Devices, Inc. Wiki) / Easy enough process to unplug from EISY, then install windows driver, plug into usb port, then web updater) but I am wondering if this is common practice or if many others are doing this step my ZMatter board from UD was purchased early on along with EISY so I was not surprised when found to be on the initial version - but when I did a search on release notes I am wondering IS this Firmware on USB Dongle something EISY should be updating - ? How many of the fixed items are impacting other users around here ? Thoughts on enabling some of the other options- long range? My dongle was Firmware was on 00.00.07.32 so I did he sequential updates to 7.35 then 7.45 then tried 7.46 twice, no error message, download looked normal but when done board still reported as 07.45. Answer was to then update the boot loader from 2.01 to 2.04, unplug for 10 sec then update to 07.46 (1 of the duplicate 07.46 choices in menu Then there were more options in firmware choices too. Also under more options I see some available options such as long range Currently enabled features: ✔ Static mode support ✔ Backup and restore API ✔ Save devices batteries when no PC software is running ✔ Advanced network statistics ✔ Promiscuous mode ✔ Jamming detection You hardware additionally supports: Free Long Range support Add this feature Free UART communications on faster speed Add this feature 99 Zniffer and Advanced Radio Tool Add this feature Maximal power (+7 dBm) Upon request Change vendor ID in Serial API Upon request here is what my search turned on for release notes and such as notes for others Firmware 7.32Baseline SDK Release: Base Silicon Labs 700/800 series Z-Wave controller build handling core S2 security frames, SmartStart inclusions, and Long Range (LR) protocol capabilities. Primary Scope: Handles standard NVM storage management and standard routing table structures. Upgrade to 7.35Routing & Retry Improvements: Improved frame retry mechanics and route-repair efficiency across high-density mesh networks. Buffer & Memory Bug Fixes: Resolved heap allocation edge cases during rapid sequential commands (e.g., rapid scene execution involving multiple nodes). SmartStart Inclusions: Fixed intermittent timeout issues when including battery-powered S2 devices during initial provisioning. Upgrade to 7.45Z-Wave Long Range (LR) & Multi-Region Support: Fixes and enhancements to regional RF channel handling (US LR frequency shifts and European LR frequency preparation). OTA Firmware Transfer Reliability: Fixed controller-side packet-dropping issues when executing Over-The-Air (OTA) firmware updates to target Z-Wave end-devices. Network Recovery & NVM Safety: Enhanced Non-Volatile Memory (NVM) backup/restore reliability—reducing network table corruption during ungraceful reboots or power loss. Upgrade to 7.46Maintenance & Patch Build: Minor point release specifically aimed at stability fixes post-7.45. Serial API Stability: Resolved rare serial communication lockups between the host controller software (IoX / eisy) and the ZMatter radio chip under heavy packet bursts. S2 Boot Bootstrapping: Fixed rare failures during the S2 security key exchange process for 800-series end nodes. Key Takeaway for eisy/ZMatter UsersProgressing through these versions systematically resolves controller lockup issues, network routing drops, and S2 inclusion failures. Keep your eisy IoX software up-to-date alongside board updates, as IoX relies on matching controller driver commands to fully leverage these underlying protocol fixes. And when I searched on Bootloader version .. mine is on 02.01.00.00 The version sequence 02.01.00.00 $\rightarrow$ 02.04.00.05 corresponds to Silicon Labs' Gecko Bootloader (GBL v2.x) releases. While the Z-Wave application firmware handles network commands and mesh routing, the Gecko Bootloader handles hardware initialization, secure boot verification, and low-level serial communication. Moving from version 2.1.0 to 2.4.0.5 includes the following bootloader-level changes and fixes: Core Changes & EnhancementsEnhanced GBL Image Verification & Decompression: Improved validation of payload signatures and CRC checks before flashing application firmware, preventing partially downloaded or corrupted images from flashing. Added support for improved LZMA/LZ4 decompression routines for compressed firmware payloads. Improved UART DMA & Flow Control: Upgraded Direct Memory Access (DMA) handling for the UART serial driver. This resolves baud-rate synchronization glitches and packet overruns during high-speed serial updates between the eisy host processor and the ZMatter chip. Secure Boot & Hardware Root of Trust: Updated cryptographic libraries (upgraded mbed TLS integration) for hardware Root of Trust verification on Silicon Labs EFR32 Series 2 (800-series) chips. Shared SRAM Reset Info Handling: Fixed edge cases in how software reset reasons are stored in the first word of SRAM (0x20000000). This ensures that when the eisy sends a command to reboot the ZMatter board into bootloader mode, the board reliably registers the reset command without hanging. Power-On Reset & Stability Patches: Fixed stability bugs where specific brownout or low-power state transitions could cause the bootloader to trap in a boot loop instead of jumping to the main application image. Do You Need to Update It?If it came bundled with your controller firmware image: Modern flasher tools often bundle the matching bootloader image alongside application releases (e.g., SDK 7.45/7.46 streams). Flashing this updated bootloader is safe when updating via PC/web tools as long as the tool explicitly recommends or requires it. If everything is currently running fine: If your eisy successfully communicates with the ZMatter board and accepts OTA/firmware updates, you do not need to manually force a bootloader rewrite. AFTER update of bootloader unplugged from USB for 10 seconds to ensure it started back up on new bootloader. Why are there two identical 00.00.07.46 - Controller choices? When updating through the z-wave.me web flasher: First 00.00.07.46 - Controller: Standard production firmware release. Second 00.00.07.46 - Controller: Regional frequency variant (e.g., US LR vs. EU/AU static frequency configuration) or a duplicated channel build provided by the tool repository. 03.13.4709 - Z-Uno / repeater: DO NOT select this. That firmware is designed exclusively for Z-Uno custom developer boards acting as standalone sub-nodes/repeaters.

Is there not a way to see if the device provisions as LR in the device zwave details ?

following along here My own setup has a single KLF200 with 5 groups set / then I hard wired 5 Zwave I/O devices to the sense inputs of the KLF200 / assigned these 5 io sensors in my ISY as names that match my 5 groups. It's crude and it works but is only 1 way (the zwave control to KFL controlling the groups of Velux). While I did wire the KLF outputs to the input sensors on the zwave devices I found the "feedback" back to Zwave io to be unreliable. I suspect more of it being the Zwave io devices I used which are old gen1 zwave stuff. Recently was just looking at the KIX300 which would just put Velux directly on my phone w/o any home automation. Not ideal but I did want to mention if anyone picks up the effort to code a plugin interface with the KLF200 would be great since it has the flexibility but the KIX300 seems to be velux's "modern" gateway. Completely different hardware any no idea if there is an open API interface to call etc.

Figured the search showed at least a year old on the topic. Wanted to share that in last 3 months I have had 4 more ISY994 power supplies all die. All had been running continually for 8+ years, all were in ranging envs of heat but all in dry env. Last one was funny in that is browned out - ISY would periodically reboot every 3-12 hours for the last week. After doing an unplug and replug it ran for 3 more hours then died completely. Really kinda speaks to how well the ISY994 was build and its ability to be browned out on power then restarted multiple times with ZERO impact to long term run health. Such a bummer that the new hardware really cannot tolerate power cycles !!

Am I missing something here ? In UDI mobile I can edit or create Program Automations but do not see how to set with a variable. such as IF variable X is set to 1 i know we can do this on admin but not via UDI Mobile ?

Thx and for the 1st time in 15yrs the timeout should be tweaked to be 5 sec instead of good old default 1 sec. Good thing we can handle a potentially extra 4 sec delay in mail messages showing up.

EDIT:: FIXED .. change SMTP timeout from 1,000 to 5,000 is fix for SMTP on 5.9.1 Was there any fix for the SMTP issue? I just updated the EISY today (update went smooth, just used the update package button in AC). I have tried changing the default timeout from 1,000 to 2K, 5K and 20K. Using smtp.comcast.net, was working on 5.8.4 and is still working on my ISY994 on 4.9.1. In the AC, if I go to Configuration > Emails/Notifications > Settings/Groups and click on Test, several seconds go by and then a window pops up with "Mail server failure" and "[[SMTP_ERRORS--1]]" (same as reported in this thread 2/15) EDIT: For me changing the timeout from 1,000 to 5,000 and ensuring I retyped the password correctly (uumm ya, that part is on me..) fixed it. So .. still outstanding Q on what changed for SMTP with 5.9.1 but the work around is to up the timing as prior noted in this thread.

thanks much, do appreciate it - my post here was only after 30mins hunting around on the forums coming from long time ISY994 new EISY user. Not meaning to give anyone a hard time but the branding here needs work ... are these PG3 Nodes, EISY Plugins, or perhaps EISY Integrations .. I suppose part of that is are we running EISY or PG3 and ISY .. or ya we just lost 95% of the new market in this line .. OK for others .. (correct me here if wrong please) ISY -> EISY -> hosting PG3 (which loads NODE SEVERS) as plugins and which the ISY can then pickup. Now is the ISY actually running as a NODE on the PG3 or as image on EISY ? UDI Integration Store / PG3 Node Servers / EISY Plugins https://polyglot.universal-devices.com/ also the store could use some work too example Home Assistant integrations gives https://www.home-assistant.io/integrations/#all

Where is the best place to see the list of available plug-in programs for the EISY?

Interesting idea here. I agree about the confines of Java and also long allegiance to Team UDI. This is an interesting project here - ultimately, I agree. It would be nice to be able to run both in parallel on the EISY - but portability is key for redundancy… Can we talk redundancy here for a minute? How portable is the back up of Home Assistant in this configuration? I.E if the EISY has a hiccup can you get your Home Assistant back up, running on another piece of hardware easily?

@johnstonf - how goes your process here? I can relate, I think I’m in the same spot you posted. I’ve had my EISY for a year now…. My second attempt migrating was following the directions just to move the Insteon on Network with plans to manually reset and manually add all of the Z wave. Glad I did it that way because it was very easy to roll back from and go back to my ISY994. (just moved the PLM back to the ISY994 and plug it back in) Which Z wave locks do you have ?

oh I didn't mention but the cross roads I am at 1x isy994 with 300+ devices = willing to dump all off the Insteon devices for something like Lutron casita OR keep and do EISY 12x other locations with ISY994s in them - some with 2-3 devices or simple setups like monitor for flood / control a light or lack of motion etc. Kinda spendy to buy a bunch of EISYs .. but honestly would IF the readability was close to ISY ... without needing ongoing hobby support .. (wish that was better understood by UDI) .. if we wanted hobby devices we probably wouldn't have bought ISY994 in the 1st place and have been running HomeSteer, HA, or the other junk which was on market. Could do some of these on Home Assistant with cheap Raspberry Pi units to meet the needs and that maybe the way we roll here.