johnnyt

good point. I wanted UD mobile to make things available remotely so never went there. Thanks.

Interesting. I just used the default inclusion on 994i. I think it was S0. I didn't/don't really feel I personally need high security, and question why it should it be needed. It usually adds processing overhead as the trade off and, other than for maybe door locks, which I don't have, I don't see including things with high security as a requirement. None of my neighbors have or care about taking over my lights or HVAC, which is what I use the ZEN17s for. (If I'm missing something on this front, let me know.) I know you're just saying what worked in the end but I'm just saying that it's an issue if the fix is what level of security I used when I included it... I did upgrade firmware to 1.20 before adding to 994i so that's not the issue.

@joembz and @ISY4Me, I just migrated from 994i to IoP 5.6.0 - starting the process that it is late 2 days ago. One of the issues I'm seeing is that, although all my ZEN17 nodes were there on 994i, I lost both sensors and can't seem to get them back using methods other than excluding and reincluding them at this point. I'm saving that as the last resort. Aside from the pain of firing up a laptop to bring my AC close to each device it will break multiple programs that will need to be fixed afterwards. So far UD support suggested power cycling the ZEN17 (after checking that the parameters were ok - they were) but that didn't fix the problem. I've done lots of "Update with Interview", "Update Neighbors", and "Heal Network", as well as querying other device nodes in case that would help but no joy. UD Smart add would certainly make getting close the three ZEN17s I have in use however my portal license didn't move over to IoP despite my following the instructions, so I can't use UD mobile until that gets fixed. I presume UD smart add implies exclude/include process but please correct me if it can do some magic without that. I haven't used UD Mobile for anything but the occasional viewing of some device states, and in an attempt to set up an eisy, which didn't work at all (probably because I have my untrusted IoT devices - where UD mobile runs - are on a separate VLAN/subnet as my HA (ISY) stuff, with both separate from my trusted devices) FWIW, my parameters 2/3 are 10 (dry contact), and params 10/11 are at 0 to decouple sensors and relays. More to come on this.

Am hoping to move from 994i to IoP this weekend. I don't believe any of my zwave devices linked with any security (or should I say they are linked with S0 if I understand correctly). What happens during migration? I'm guessing I end up with all/only S0 security on all my devices and that I would need to exclude/include every device (and fix every programs that points to it) if I wanted to link them with more than S0 security. It's in that context that I ask how important is Zwave security?. I don't have any close neighbors with any zwave devices, assuming that would be part of the calculation. any info would be appreciated.

Consider trying this (at your own risk, of course): Take two backups. With one of the backups, open it using 7z and look for file "NTCLIST.CFG " in the MAIL subfolder. If it's there, delete it and restore that modified backup to see if it fixes the problem. If it causes problems rather than fix them, you will have the other untouched backup to restore. I recently saw my backup shrink without justification and, worried about my upcoming migration to IoP, I looked for file differences between the smaller and last larger backups. I found the smaller one did not have "NTCLIST.CFG ", which was a comparatively large xml file full of my custom notifications. Despite it not being there, all my custom notifications were still there, and a restore of the file on a blank (test) eisy (minus NODES and SCENES because I did not want it to take over my devices) showed the notifications where still there. I asked UDI support about this and they told me the file is "a cached version of some of the information stored in the custom notifications. It may disappear at times but can always be recreated when needed". They may not suggest doing something that requires you to mess with the backup so maybe that's why they didn't offer you a fix. Or maybe it's completely unrelated, but, if it goes as it did for me, you at least won't be any worse off. And if you are worse off, you have the untouched backup to restore. Be warned that ISY backups don't save web server files if you use the built web server for logging as I do. (If you don't know what I'm talking about, it won't be a problem) Hope this helps.

@dwengrovitz Was this fixed in 5.6.0? I don't see it mentioned explicitly in the release notes but was it maybe included under "Minor bug fixes"?

Is there a way - in PG3 - to migrate the node servers I have linked to my 994i to IoP, or do I have to reinstall each one again and configure them from scratch (what I ended up doing in the past during some testing)? Both are using the same PG3 3.1.20 instance on the same Polisy, and both have an active portal license. If this is done automagically during migration from 994i to IoP, that's what I'm really looking for right now. Even if this is the case, knowing how to do this outside the context of a h/w migration would be good to know as I will eventually want to also use some of the NS on IoP on an eisy. Not having to re-install/reconfigure them one at a time would be a time saver. (Any required NS license purchases for new h/w would be done, of course.) Apologies if this is posted somewhere. I looked but didn't find the info.

Thanks for the helpful info @bpwwer. It appears to me that there are more problems (growing pains) with eisy and PG3x than with Polisy and PG3 - at least from the posts I've read. Given PG3x will run on Polisy, this reinforces my thinking to migrate my 994i to Polisy rather than to eisy. For sure I will eventually use eisy and PG3x, but because I have a large system (I won't repeat details here), it's highly valuable to me to be able to reduce the "surface area" for problems and extra work before I migrate. If I can punt something down the road without losing much, count me in.

Thanks for the helpful answer, @Geddy So it's certainly less critical to know what's in PG3x so if there's no one or nothing that can list what's new in PG3x I guess I'll just wait and find out 1-2 features at a time.

Saying that PG3 is deprecated does not answer whether PG3x can be run on Polisy. PG2 is deprecated on Polisy and that didn't prevent PG3 from running on it.

Is Polisy going to be able to move to PG3x?

Hi, Can someone provide (or point me to) a list of the major features and benefits (current and planned) of PG3x compared to PG3? The eisy user guide only tells you how to install it, and the announcement/release notes for PG3x only mention the following: make node servers (and PG3x) more secure Add setClientState API framework to support remote access to PG3x And I don't know if #2 is new or just catching up to PG3. The rest look like fixes or minor enhancements to me. I'm trying to decide if I migrate 994i to Polisy or eisy, and it's my understanding that Polisy will be stuck at PG3. Because I have a Polisy, I'd like to make use of it and if there's nothing I need in PG3x over the next 1-2 yrs I would be fine to stick with PG3. If my understanding is wrong and PG3x will be coming to Polisy, great. I'd still like to know what PG3x will offer over PG3. Any info would be appreciated.

starting yesterday I've been receiving a flood of UD Mobile notifications about ISY going offline and online. I think it's because my ISY is overloaded and can't respond fast enough. Hopefully when I migrate off 994 that will help but I would like to suggest a longer delay in being notified that ISY is offline. Also, I tried to turn off notifications in app but it kept turning itself back on. I had to disable notifications in iPhone settings.

@Geddy 1. The ISY99/994 pre zwave era was GLORIOUS, with typically flawless firmware updates (I think I did every single beta release) and rock solid performance, at least for me. Moving to 994i was pretty simple too. Not saying there wasn't any work to do. But I don't recall it taking more than a few hours. 2. I am NOT expecting perfection. Stop saying that when you reply to my posts. I long ago gave up on expecting the near flawless performance and upgrades after I began using zwave. Seems UDI would have needed a small army to tackle that and clearly that wasn't in the cards. I did my best to support the effort by being one of the first to buy a Polisy. Did the same with zmatter board for Polisy in the Fall, then again recently by buying an eisy and zmatter USB. 3. I have >150 zwave nodes (~40 devices, I think) and over 140 custom notifications (one of the bugs I highlighted is related this), plus nearly 1000 programs - about half of those having a zwave device that may need manual updating. I know I WILL have work to do even if there were no bugs. The things is - as others have mentioned too - it's hard to know if a problem is a bug, a comms issue, missing device support, missing documentation, or a missed or misunderstood migration step (and there are certainly plenty of opportunities for this). A relatively bug free release would be hugely valuable before taking this on. My main point was that with an apparent freeze on releases until there's enough new stuff in it, possibly followed by fixes to bugs in that new stuff, it kills some of the hope of seeing a bug getting fixed quickly when I run into one, which is statistically very likely given the size of my system. Maybe getting new sales is dependent on adding new stuff and I know new sales helps fund development - I did my part - but I am (I think understandably) a little disappointed that fixing the bugs that would make migration easier quickly isn't higher on the list.

I ended sending prematurely there by accident, but maybe that was a sign to stop there. If I keep looking, I'll find more. Also, the whole time it takes for things to finish then to clean things up worries me. I have a ticket open asking how long I should expect it to take zwave devices to update (average and worst case). Yes I know it varies by device so just asked for average and worst case, e.g. timeout. Question was asked almost 2 weeks ago - still waiting for answer

what about this one? and this one? And this one.

So UDI support is (of course) not saying when 5.6.0 will be out. While they mentioned that zwave and other bug fixes will be part of it, they're also working on adding new stuff and putting a push toward zwave certification. So my guess is it may not be out for a while. I mused about a 5.9.9.1 release to finish the list of bugs that interfere/delay with migration but that doesn't seem to be in the cards. Bottom line is that anyone having or finding a bug now is out of luck for a fix until (maybe) all the other new stuff planned for 5.6.0 is ready to go, and possibly later as bugs deemed higher priority come in for the new stuff (that I don't need and can't use until I can migrate off my 994. ) With the 994i EOL date fast approaching, one can only hope there will be priority put on providing a relatively bug free version soon to support those looking for a smooth migration off the 994i so they can move on from it, not to mention consider adding the new stuff.

Exactly where can I get a list of the features that would stop working if UDI decided to stop providing the supporting cloud service, or, gulp, decides to get out of the home automation market? I'm assuming/guessing the following needs a funded cloud service: remote access, the node server store, webhooks, and tie ins to Alexa/Google. While I would certainly miss the NS store for updates and new possibilities, I hope I'm not dependent on it to keep what I have running. The other stuff I listed I either don't use or can get by without. I think this needs to be clear so folks know what they're buying into / sticking with when they use features dependent on a cloud service.

Rebooting due to a portal outage!? That would be a bit harsh. Please say it ain't so. I'm working hard to avoid cloud dependent stuff. I'm okay to use it for value added stuff but not if it prevents me from doing core stuff without it, or causes my system to reboot. It's one of the reasons I've been sticking with ISY despite the problems since zwave addition that are hopefully going away soon so we can get back to the near flawless beta releases of... is it 5 years ago now?

Oh yes, the TPM. Forgot about that. It's an available option - at least in 7.3 - that worked fine for my Win11 VM. There's a highly compatible E1000 network driver that I haven't seen not work. I might try again some day just for kicks. I don't see myself using it, though. It would just be a let's-see-if-I-can-make-this-work kind of thing.

Anyone know the plan for release of 5.6.0? It'll soon be 3 weeks since the release of 5.5.9. While 5.5.9 seems to have fixed many of the bugs in previous 5.5 releases, I'm still reading about some issues and can't help but think waiting for 5.6 would be good my migration. At over 150 zwave nodes, close to 1000 programs, a day job, and a family, I'm looking to minimize the migration issues. But I'm also really looking forward to the promise of running IoP (since last spring, actually) as I have daily issues with my overloaded 994i. I'm weighing the devil I know (and have worked around) against the devil I don't. Will it be days, weeks, or months before we see 5.6?

I tried loading an image of my Polisy on my Proxmox server and it wouldn't start. Didn't spend too much time trying stuff. Here's a thread on the subject I would think that as long as you bought the hardware and aren't using it too it would be okay but I didn't ask as I couldn't even get it going.

Has anyone played with the Zwave Communication Speed option now available with ZMatter dongle? If so, which way did you go (faster or slower) and did it make any difference? Aside from wondering if it helps to change it in general, I'm wondering if changing it ahead of doing 994i migration would help during what is a pretty heavy/intense workload.

Thanks @larryllix Hmmm, I thought the insteon stuff was the least of my worries. My plan is to move the PLM I'm using on the 994i to the Polisy and, if the migration turned out to be a disaster, bring the very same PLM back to the 994i. Are you saying that if I go back after a migration that idea won't "just work"? Note that I wouldn't mind if I just had to restore the PLM and manually update a handful of motion sensors (I've done that many times) but would I have to restore every single insteon device too??

Thanks. So it worked no problem at that time? Do you remember if you had to restore the 994 or just plug it in and it picked up where it left off?