junkycosmos

@Guy Lavoie no, I have not added any Long Range Devices yet. Was just hunting a good device to test with, open to suggestions. Looking at the Aeotec Multisensor 8 Aeotec Multisensor 8 or the Aeotec Siren 8 Aeotec Siren 8 Agreed on the LR "enabled" . one of the notes I did get back from Zwave-me email support after I had fixed made a comment that EISY "can apply" the LR license into the dongle. As above I can note my EISY had not applied the LR license into my dongle however I had not tried to enroll any LR devices .. (maybe EISY only applies LR into dongle when you try to enroll a LR device?) I do think this raises a few Qs about LR on EISY - a. do EISY users need to update Zmatter dongle to X firmware or only if XYZ (LR bugs? LR needed. or ???) b. do EISY users need to "purchase" (its free) but a separate step to "enable" the LR license to your USB dongle UUID c. IF something goes sideways on step b (enabling LR) is only way out is using Zsniffer tools as I did or when would the EISY push license into USB? - IF the EISY does not really push it to USB then would really recommend doing "Purchase" of LR on zwave-me via web tools / more options BEFORE using web tools to update firmware - since I was told doing a firmware update also pushes latest licenses into the USB dongle. Also agreed things changed on Firmware in Z-wave.me site / when I updated there were 2 versions of 7.46 but week later there was only a single and 7.47 with a caution of only using 7.47 with other setups.

Hi All Wanted to report back that I have had success adding in a few of my Zwave devices after going to the newer version. Have only tested with a few but all going smoothly. Even the adding the dreaded Schlage be469 locks, which appear to be working OK. All of that said I did want to post a comment here for others to please take caution on any of this USB Firmware updating - knowing it is pretty low level - and also do please read and pay attention to what @Javi very politely noted above of:: "I must emphasize, the only thing needed is in the provided Wiki instructions. I am unsure of outcomes if anything else on the dongle is changed. We have not tested other versions or other features." as a reference to others the direct link to instructions is https://wiki.universal-devices.com/Eisy:User_Guide#ZMatter_USB_Dongle_Firmware_Upgrade (no one asked me to post this caution but seemed to be prudent) - I do think this brings up an interesting Q on support guidelines and boundaries too and my usual thank you to the solid UD Gang

Was able to enroll a be469 ZWP lock on EISY via Admin consul, prompted for code and enrolled quickly. Question: For Schlage ZWP BE469 on EISY do we still need to perform these additional steps after install? 1) right+click Z-Wave | Compatibility Mode ON 2) right+click Z-Wave | Validation | OFF 3) right+click Z-Wave | Rewrite All Device Links I know EISY on 5.8 (with ZWave USB Dongle on 7.32) with BE469 (FW11.0 sticker) they were required to get EISY to see status changes on lock - However .. I just enrolled a new lock BE469 (FW12.4 sticker) on EISY 6.1 (with Zwave USB Dongle on 7.46) and the lock is reporting status in Event viewer without doing these steps. All I have done so far is enrollment and the lock is reporting status of manual handle turn, keypad lock and user code unlock. Did something change in EISY 5.8 to 6.1.2 for this ... ? (or maybe it is the newer Schlage FW or maybe the USB Dongle update ?) Couple quick details 1 EISY UI allows you to set a 4-10 digit code via UI however the lock does not actually take the code length until you manually set the config parameter to the length you want. UI there is a bit misleading as it prompts to set code 4-10 and will take a length wrong for lock setting without giving any error A pre step that must be performed set the parameter in lock to code length desired (default is 4 digit) IF someone wants to change their lock to use a 6 digit code instead of a 4 digit code then set Par number 16 to 6 - (lock now takes 6 digit user codes locally OR via users button on eISY Admin consul) 2 Easy mistake of using wrong pin/enrollment code when trying to enroll - do not get "wrong pin code" Wish I could edit my post on this thread of January 19, 2025 to note the secure enrollment code for ZWave Plus (the code you need to enroll the lock on your EISY) is NOT the 6 digit code on the sticker back of lock case but rather a 5 digit code that came on a card/instruction in the box. - I suspect some of the users here are incorrectly trying to use the "Programming code" on that sticker on lock as the security code during ZWave enrollment - I can confirm you get no error message with the wrong ZWPlus enrollment code - the lock just fails and the EISY adds a blank node. old reference thread - Schlage Be469 v5.8 (non Z-wave Plus) / trouble adding to Matter Z-Wave / Q on status S2 - ZMatter - Universal Devices Forum Both 1&2 could be quick addition to the wiki UD Mobile - Universal Devices, Inc. Wiki ************************ Here is how the nodes show after enrollment with the correct ZWP enrollment code (on the lock instruction card - not the code on the back case of the lock)

Hi All Per my own strange case where I tried to "enable" Long Range Support via https://z-wave.me/support/controller-tools but then had it fail and not push the license into my USB dongle - noting all of this was on the win11 pc (not EISY) Evidence of was that web tools https://z-wave.me/support/controller-tools shows LR as unchecked however going to move info https://z-wave.me/hardware-capabilities/?uuid=YOURUUIDHERE showed Long Range as enabled. The fix = download the Zniffer / Advanced Radio Tool https://z-wave.me/support/downloads/... use it to connect to your USB dongle (mine was at com4 port and baud 115200) , once you could see your UUID listed you know Zniffer sees your dongle, then click the i button and because the license was already provisioned on Zmatter server it a box popped up and downloaded the license. To confirm I closed radio tools and web back to web tools - and now finally Long Range shows X as enabled. Hopefully others do not run into this but polite reminders Webtools https://z-wave.me/support/controller-tools actually queries the USB card directly to pull what it knows is enabled Viewing "more info" or Hardware Capabilities https://z-wave.me/hardware-capabilities/?uuid=YOURUUIDHERE pulls the licensed data for that UUID from Zwave-me servers (not from your usb stick) @Javi - I do thank you for the reply and does sound like EISY might be able apply the license as well .. but it clearly had not as USB Dongle was in EISY online a few days in between my attempts here. However I did not try to add a ZW Long Range device as you suggested prior as I do not have one on hand. - Just noting for your info - I do appreciate the help.

@Guy Lavoie and @Javi The problem I have is my USB ZMatter Dongle does not have Long Range Enabled (as is verified by web tools and no checkmark on the LR option). However when I go into More Options link (which shows the options purchased for account belonging to UUID of USB) it shows Long Range shows as purchased. This mismatch is because I purchased it, received mail but the link in mail goes to "cannot find license" .... SO .. I am a bit stuck .. ? I cannot "re purchase it" since the option to purchase is gone .. but I do not know how to "enable it" on the actual USB Dongle. Have mail out to zwave-me but no response (sent Tuesday) Anyone with other ideas here ? Appreciate any suggestions

@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.

Also long time user here, just trying to count, ummm 16yrs here. Started with ISY99 .. Here this will date me .. ONE OF THE FIRST users to have the ALL ON events after moving to the ISY994 and battery powered devices. RIGHT not UDI's fault on the ALL ONs .. just same as the bad SD cards (use of fake SD cards permitted the market and killed many products) .. but I would put it this way. When someone steps out into a busy street - do you try to avoid them if you can or do you just say 'oh not my fault' and mow them down. Right, even if you are one of those guys you probably chicken out last minute and do the right thing. So to Michel's credit UDI did a crap ton to hold up Insteon over the years. I am not in the position to say if more could have been done on the topics of: ALL ON, random link losses, PLM deaths due to overheated capacitors, poorly implemented firmware options in devices. Enter Zwave - huge credit on to UDI for jumping in - a solid jump in, how many different Zwave boards did they do? Ok now ISY hardware often struggling on larger setups but super reliable - yank the power and you can always expect your ISY to restart (ok if your power supply hasn't overheated, your SD card isnt fake) .. and, as a user with 300+ devices, 15 minutes for startup and query all but you could count on it. Honestly that is the amazing ISY brand rock - solid. Only thing I have ever seen better are some elevator control boards from the 90s running in their isolated environments. Now enter EISY - during a market time of a very useable Home Assistant community device - dropping prices of the extreme commercial systems (have you seen the Lutron Caseta system) or even drop in price of the RA2 pro stuff. Oh yeah then let's mention Alexa of the casual user requiring nearly no "hobby support time" / Insteon goes bankrupt with a nice community support pickup but long overdue. Again, I am outside here, with have a ton of respect for the Gang at UDI, all of whom I would give a large hug but their world they are operating in has changed a ton / ummm the world us users are asked to navigate which @Toddimus opening post had me think of. I bought a EISY with wellness to send the $400 just on principle to support UDI - but my efforts to test it out over the last year have been sadly challenging. First issue was after pulling power from it when moving it around my network cabinet - completely corrupted free BSD and EISY needed to be shipped into UDI - but noted that was only after Michel spent 3 hours on a Sunday night remotely connected to it attempting to fix .. dang! However that doesn't make up for the loss in reliability hit - when designing EISY (or in testing) was a requirement missed -users will yank power - device needs to live through random power outages... Curious where others land on this too. I get the ISY994 is outdated hardware wise .. sad but true - although some of your favorite elevators are probably running firmware from 1999 on them still today ..

@Nitemare - indeed you are on path here trying to add slightly different lock (ZP which is on v.11 vs my older nonZP on v5.8). Main difference is that indeed EISY flow for you is S2 (secure) vs mine being older non secure S0. I did have easy success in adding a BE469ZP v11.0 from the admin consul - I did not try mobile. My EISY is in crowed (electrically noisy) rack about 20 feet from where I did the initial enrollment. However the settings change (compatibility mode and validation, parameter change) and all other testing of unit have been done with unit 60 feet from EISY. Noted my test was a "new" lock out of the box which had never successfully enrolled on my ISY. I note never successfully since I had tried but learned my ISY on 4.9 would not support ZP devices. I never migrated from v4.9 up to v5.x (which I recall was required to run ZP devices). Also note sure what version my Zwave board is on the my ISY v4.9, I know it was one of the 1st mass sale units but early on. Given your note that you were running BE469ZP on ISY I am guessing you were on V5.x Interesting what @Javi notes about doing a factory reset; that would not hurt but I would suggest ensuring to do a Zwave \ Remove a device - then on lock clicking enrollment button - just help clear prior association attempt. As for my own issues on BE469v5.8 move from working great on ISY994 v4.9 to over to EISY on v5.8 where it will not enroll - just tried new enrollment attempt with same failure after ensuring ISY994 was unplugged, doing remove/exclude, setting interview time to 2 mins and comm speed to 20 (all per suggestion of Mr Chris who is working my ticket) - he noted Zwave library Team to have a look after I had sent lower level diagnostic from SSH session. Part I am perplexed on is how well this lock works on ISY994 but fails on EISY.

hi @Nitemare - are you 100% sure that our locks are BE469ZP and not BE469v5.8 ? Reason I ask is that your comment of only getting a single entry, no control for the lock on EISY but worked fine on ISY is the exact same I am running into with my BE469v5.8 Also I tested a BE469ZP unit and they add into EISY fine, it asked for ZP security code, adds multiple nodes as expected. After that does require additional steps after enrollment of turning on compatibility, turning off confirmation, and rewriting links (see several posts above). I can understand how people are likely confused on which version of the BE469 the might have (as the locks look identical on the outside of the units) AND most retailers just started selling the new version w/o much notice.. BE469v5.8 = S0 device, worked on ISY994 v4.9 older Zwave board, when attempting to add into the EISY the EISY does not ask for security code, removing battery cover of the lock there is NOT and enrollment button (instead Zwave enrollment is done by typing 8 digit code then 0 on the lock keypad BE469ZP (Zwave Plus)= S2 device, does NOT work on ISY994 running v4.9 (might work on V5.x not sure), when attempting to enroll on EISY will ask for Secure code (code is sticker on part of lock that mounts to door that holds outside keypad on -remove lock to see it), to enroll the lock there is a button under the battery cover. Please reply back to confirm which version you have. Also if you have other examples in forum of those stuck getting the single node you mentioned and can easily find pls reference here. thx cheers

Sure .. agreed the newer Zwave Plus stuff has security. Those add to EISY with S2 while the non security devices add as S0. These BE469v5.8 are before z wave plus was a thing and add as non secure. The ISY994 v4.9 was indeed non secure non zwaveplus (on the 1st non beta board) .. and the BE469v5.8 are very happy there. Now onto EISY where S2 (secure) and zwave plus is the norm.. however it does claim support older non secure S0 enrollment or at least it tries to and has options to …but that is crux of the space I’m stuck in. Given roll out timing of EISY and when Schlage updated their own BE469 models from v5.8 to ZP (zwave plus) years ago .. I really suspect most users and testing probably skipped this use case (older be469v5.8 on EISY). Also most on forum posts on Schlage in EISY all focus on lack of status change alerts .. which again confirms those users were on BE469ZP - since we know fix for that (in post) At least the EISY is not asking for s2 code on the be469v5.8 and does start the interview, but then it fails to communicate properly with the lock and enrollment fails.

thanks @firstone - indeed had not thought of going the Home Assistant route to try enrolling my BE469v5.8. Thank you for the idea. Noted this same lock enrolls great on ISY994 v4.9 and runs well (last 10rs have 9x of them at this location). So the variables here are EISY Zwave board and V5.8.... and my existing network. While I do understand these locks are older (ie when Zwave really stabilized), since they run fine on ISY994 v4.9 this seems to be an issue of incompatibility how the EISY Zwave board, v5.8 or how it is implemented or something on existing network (largest variable). The existing Zwave network does have 30 or so devices some of which are S0 repeaters for the other locks. My original plan was to completely wipe the ISY994 v4.9 Zwave network and re-enroll everything "clean" on the EISY v5.8. Did one lock to "test" on EISY before wiping all from ISY994 so I could roll my migration back .. and hit this road block. I did do an exclude on ISY994 for this lock, then powered down the ISY994 .. but back of my mind I am wondering if the other devices and repeaters (still enrolled with ISY994) could be interfering with the ESIY enrolling this lock. Suppose I could remove this lock from the door, take it and the EISY to middle of a quiet parking lot, then try the enroll process .. kinda a pita. Appreciate the Home Assistant Idea - would need to pick up a Zwave USB dongle which is no big deal. J