junkycosmos

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

sharing update so far .. it has been bit of a slow process of back and forth on the ticket with support - did just get lower level Zwave logs back to support during attempt at re-enrollment, hoping Chris finds something useful... So far no progress to report on the older Schlage BE469v5.8 - to EISY we tried increasing the interview timeout to 1 minute / the lock still only enrolls on EISY as 1 node with no functions available. Really does appear to be some issue with ESY on 5.8.4 and the older BE469v5.8, noting that these do and have worked fine on the ISY994 over the past 10yrs (with older zwave board) and on 4.9.0. In other words the variables here are 1. ISY994 Zwave board to EISY Zwave /Matter board , 2. going from ISY v4.9.0 to ISY 5.8.4 (on EISY). Locks are in same location, ISY & EISY are in same location.. I did find this older forum posting that references similar sounding issue from Jan of 2023 and reference to a fix due in Feb, not sure how to confirm that was fixed .. For clarity sake the newer Schlage be469zp (zwave plus) unit I setup as a test lock is still working well on EISY after the suggestions made above by @kandlg (compatibility mode on, confirmations off, re-write all links) - this post is all focused on the older be469v5.8 - original schlage locks us early zwave users were rolling back at the start .. thx

Anyone else run into this .. I'm kinda embarrassed it took me a few cycles to try integrations of the capital for Admin / this is a new EISY on 5.8.4 (bug? = user capitalization here fails login .. must be in lower case for ssh but not for PG3 or Admin) 1. IoX admin console login admin/admin = FAIL Admin/admin = pass 2. Polygolt dash https://192.168.1.##:3000/dashboard admin/admin = FAIL Admin/admin = pass 3. ssh either local or via IP ssh Admin@192.168.1.## / admin = FAIL ssh admin@192.168.1.## / admin = pass Yes, I tried a reset of Admin user and password via Admin consul setting to User ID of Admin/ password of admin

@kandlg - thank you very much for the post here. Indeed your note added 2 steps that I had not tried before of steps 2 and 3. Doing all three here now I can indeed see local status changes made on the new BE469ZP lock on the Admin and they trigger programs too. so fix for BE469ZP to function as expected on eISY 5.8 (where the lock adds as S02) are to .. 1) right+click Z-Wave | Compatability Mode ON 2) right+click Z-Wave | Validation | OFF 3) right+click Z-Wave | Rewrite All Device Links Also noted that 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) This is great as it gives a way forward for most users here who have BE469ZP. <<wonder how this type of info can be on WIKI vs bit buried here in the forum>> ? Does still leave some of us with the question BE469 v5.8 (the units pre ZP) that were used on ISY994 pre 500 ZW boards - older units. When I had tried to add them into eISY from the 994 by removing/then re-adding them things were very messy. I do have a ticket open with Support in hopes they have a path forward that does not involve replacing all my locks at this time. thx J

Coming from ISY994 on 4.9 to EISY on 5.8.4. Been trying to troubleshoot why many of my programs are failing to "Send Notification". In troubleshooting I've torn down a few of the example programs to the only action be "send notification", then I am testing with right click run then. 3 issues - 2 fixed but appear to be as a result of the my migration from ISY 4.9 to eISY 5.8 so maybe migration bugs, 1 issue outstanding which is livable but could use confirmation / checking by others or if something unique to me here .. all three potentials to cause others issues on migration. Issue #1 - Text to SMS/MMS from EISY not working / Group Name needing to be renamed .. Understood it can have issues and sometimes it does but at of this moment I have my ISY994 and my eISY both up, both targeting same address via same mail server an 1 works while the other does not at all. - notification test from eISY to phone works fast shows up - GOOD (this is group ID 4) - have isolated program with no other condition or action other than "Send Notification" to test by right clicking - tried with the content of "Default Template" and my newly rebuild template (see #3 below) - both fail - target is ##########@mypixmessages.com - only has 1 address in this group - recreated a new group (group ID10) for this target phone (was in its own group before) .. and that fixed it .. umm, wow .. - went back to my original group and deleted the recipient, clicked ok, went back into the group, added same exact address back in, closed and hit save at bottom - did not fix it .. so issue here is that the same exact target address in to new group ID10 works while in the old Group ID4 it does not. - When to Group ID4 name = 17 characters long and edited the name - it started working - ok .. wow .. , originally shorted to 15 characters but later changed back to my exact same name it had prior and all has stayed functional. So the fix appears to be related to something in in the group name needing to be edited/changed and then resaved. . ******************************** Issue #2- Send Notification FAILS If Program Names over 31 Characters - Seems there is some new limit or something that breaks which used to work extremely fast on ISY994 (really silly fast as in 1-2sec) I have checked that both the ISY994 and ESIY is using same mail server / password - (not that is should matter) Testing has lead to show that IF a program name is over 31 characters the mail never shows up however, if the program name is 31 characters or less the mail shows up right away. These are both using the Default Template... Example programs 31 passes / 32 character name mail never shows PASS Program Name is 31 character OK - [ID 00DA][Parent 00A6] If Then Send Notification to 'J_Email' FAIL Program Name is 32 character BAD - [ID 00D7][Parent 00A6] If Then Send Notification to 'J_Email' ******************************** ******************************** <Fixed>Issue #3 - EISY is not sending any notifications to email that use my custom template from ISY994 - / new ISY uses slightly different context in the alert variables... Old Customization Template on ISY994 4.9 Subject: ISY ${alert.program.name} Body: ${alert.event} at ${alert.date} ${alert.time24} FIX = recreating my template as the subject format changed when moving to EISY 5.8.4 Subject: ISY ${sys.program.#.name} Body: ${alert.event} at ${alert.date} ${alert.time24}

Found the Configuration Parameters sheet for Schlage BE469ZP - need to convert to dec for ISY use but can do via Set Configuration Button on the node in 5.8.4 - example to change user code length to 6 digit set Par number 16 to 6 - lock now takes 6 digit user codes locally OR via changing on Admin consul. However now that I have user codes working I am running into what was reported in that thread I referenced from Jan 2023, status of the lock does not appear to change on Admin consul when the a user code is entered or the knob is turned manually to lock or unlock... ...maybe what was noted as "a fix coming soon never came ?" or perhaps something else I am missing .. 24352403.pdf