johnnyt

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?

Yes, of course. And yes, I do have devices that are different from the ones mentioned so far in posts. Not every single device I have has been covered one way or the other. It would be unreasonable to expect to have every device covered here. Perhaps if I waited 6 months or more but I don't really want to do that. I've also tested still new devices not currently in use with 994i with latest IoP/zmatter board - they link fine (way better than with 994i) and I will import some programs to see if conditions and actions on these devices work. I will do everything I can to mitigate the risk, and I am prepared to live with some issues, but I also want to understand whether or not if, after reading all the posts and all migration user guides, and having done all the prep work I can, should the migration result in show stoppers that can't be fixed quickly enough, is there's a way to back out? There seems to be one but I've yet to hear from someone that's done it. So can I ask that the focus please be on the questions I asked? While I normally appreciate alternatives, right now I really just want to know: Thanks.

Thanks for your suggestion @ShawnW. I will be sure take an inventory using the "Generate Topology" tool, screenshots, and exports of everything that's exportable. I have to wonder/ask where you got the indication/impression that going back would be a huge pain. If, as indicated in the user guide, the process is simply to (not add/remove any devices and) do a restore of the file on the 994i that was created by the 994i in the first place, how could it be such a big pain? It's not even clear why I would need to do the restore because one of the instructions before restoring to the Polisy/eisy is to: Power down your ISY-994 (very important). ISY-994 needs to be powered off because when you migrate, both your ISY-994 and Eisy / Polisy will think they are controlling the Z-Wave network. This suggests to me that I could simply factory reset the Polisy zwave dongle, reset the IoX instance on Polisy (using ssh apt remove/install commands), then plug the 994i back in and it would just see all the devices as its own, blissfully unaware of the attempted coup. Of course the reason I'm asking is that I don't really believe it's quite that simple. But what if it is? Hopefully I'll hear from someone who's done it... or that tried it and can confirm whether or not it's an unmitigated disaster.

Has anyone gone back to their 994i after migrating (or trying) to Polisy/eisy? If so, any hiccups? Did you have to restore your backup or just plug the 994i back in? The migration section of the user guide on wiki as of today does say the following in the "Eisy/Polisy" section. I assume it applies when one comes from 994i, not just between a Polisy and an eisy, but would like confirmation of that from folks who have done it. "If you don't actually change your Z-Wave network by adding/removing Z-Wave devices after migration, you can back out the migration by connecting whatever Z-Wave dongle you were using before migration and restoring the backup you made prior to migration." Also I only see mention of backing out zwave. For Insteon, I assume as long as one uses the same PLM the same applies. Because I have over 150 zwave nodes, almost 190 insteon nodes, close to 1000 programs, and given things haven't gone as smoothly as I'm sure they will one day, I'd like to do a "dry run" to see what things need better support and report them / wait for fixes before I do the real migration. If it's a manageable amount of pain I wouldn't go back, of course. While I will hope for the best, I'm planning for the worst. Any info would be appreciated.

While admittedly a work around, for past few years every time change (spring and fall) at 1:59AM my 994 uses a network resource to call a Webswitch script that powers off ISY, waits 2 mins, and powers it back up. Haven't had a problem since, though I'd rather not have to resort to doing this. Hopefully it does get fixed when I move to Polisy/eisy, or because time changes come to an end, at least in North America, an idea that seems to be getting a lot of attention. Daylight Savings Time Power Cycle If Time is 1:59:00AM And ( $iCal.Month is 11 And $iCal.Week.of.Month is 1 And $iCal.Day.of.Week is 7 Or ( $iCal.Month is 3 And $iCal.Week.of.Month is 2 And $iCal.Day.of.Week is 7 ) ) Then Run Program '1-Save All Counters - for reboot' (Then Path) Wait 10 seconds Resource 'Web Switch Run ISY Polisy and Autelis Power Cycle 2 minutes Script' Else - No Actions - (To add one, press 'Action')

yes i did everything needed to configure it, including setting 10/11 and re-include after. I tried the rest command but only getting errors can you see what I did wrong from screenshots? I also tried with and without "Encode URL" option checked (similar error msg without) and with/without "authorization" (similar error message without). I did double check userid/pw, which are visible so hard to that mess up. I do have other similarly configured network resources that work fine and return an OK message. Don't know what I'm doing wrong here. Could it be querying this type of binary sensor simply does not work on a 994i?

Are you running IoX 5.5.7 on Polisy? eisy? Query using network resources? How do you do that? I have param 2/3 set to "10 - on/off report (dry contact switch/sensor)" Other than 2 and 10 I'm really not clear what the different settings offer/support but I am getting exactly what I'm looking for with setting 10 except for the querying in programs, and the reliability (unrelated to setting I'm thinking). Interestingly I wouldn't need the querying if I had the reliability. That said one of my use case needs a safeguard so I would probably keep the querying for that even if I had the reliability.

I have a number of ZEN17 relays that I've configured as "on/off report (dry contact switch/sensor)" (param 2/3 set to 10) so the sensors on them are independent of the relay. There are two issues I'm finding with them using the 994i that I'd like to know if they still exists in IoX 5.5.7 with zmatter board in order to help me decide whether I buy more of them or not. First issue is that the sensor does not always respond to change. That, or the 994i does not always hear it. Not sure which one it is. Are folks finding the sensors reliable? I have three and they all occasionally fail to react (or be heard). One is 4 feet from the 994i so range should not be the issue. Second issue is that, while I can query the sensor from admin console node, there's no option to select the sensor to query it in a program. I tried querying the relay that's grouped with the sensor in case that also updated the sensor but that doesn't work. Is this still the case in IoX 5.5.7? Is it a device type issue or an ISY device support issue? Any feedback on this would be appreciated.