johnnyt

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

Is there a way to upgrade to this version without upgrading Polisy/IoP to 5.5.7 at the same time? Right now, I believe if I do as instructed, i.e. I will be upgrading Polisy to 5.5.7. Would like to wait until there are fewer bugs in 5.5.x branch. Also, given I'm still at 5.4.5, I expect it will likely take a loooong time to update. Need to plan for the outage and the possible hands on tech support needed afterwards.

Thanks @DennisC, @lilyoyo1, @oberkc for the detailed responses. I'm certainly leaning towards a full 'sink or swim' migration for myself but it's disappointing if all my hard work of the past decade+ can't be "bottled" into a template as I was hoping. For context, I use my ISY to control all my HVAC (on top of lighting), which includes heat/cool, furnace fan, 2-speed HRV, whole home humidifier, 2-speed whole home HEPA filter, 3-speed duct fan, and a couple of dehumidifiers. It's much more involved/complicated than controlling lights because there are so many permutations and combinations when you factor inside and outside temp/humidity, forecast, air quality, time of day, season, etc. I think 75-80% of my 990 programs and at least 90% of my variables and email customizations are related to HVAC. The thing is, I will soon be starting to do low-cost air quality assessments by lending out (for a fee) some Airthings sensors, for which there is an API and a Node Server. This will lead many with air quality issues to want to improve their HVAC, with which I could help, including using the Airthings sensors in the automation. But without being able to avoid days of tedious work just reentering core, device independent things in my automation like my 400 variables and 150 email customizations, I'm not going to want to do many of those, if any. I'd need to have a lot of the work done for me already, i.e. by being able to load a template on a new eisy, before I would want to do it.

But did you restore your 994i for all its programs, variables, network resources, email customizations, etc.? That's where I want to end up (but without the device nodes.) I do not want to exclude any of my devices from the 994i, First of all, the 994i still needs them to continue to run the house while I'm playing with IoP / zmatter board. Second, the idea of creating an IoX template of existing variables and related email customizations is to have a jumping off point for adding NEW devices for use in a NEW house, not the ones in my house. I should probably also mention that simply deleting the nodes in IoP after the restore is not practical because I have 520 nodes. Unless I just didn't find how to do this, I found I can't simply select all / delete all my device node in two clicks, like I was able to do with my programs (and variables if I had wanted to). While I can see why it is the way it is (there are PLM/zwave links to delete too), it means I have to go to each one of my nodes and delete them one by one. Each one is 3 clicks for a total of ~1500 clicks, and it won't be quick as each delete tries to communicate with devices that aren't there. And not just once for testing my eventual migration to IoP but every time I want to update the template I'd like to have for replicating my installation on a new eisy for a whole new setting. Also, the other way to come at this would be to start blank and import everything, but I only see the ability to import programs and network resources. That would mean manually creating almost 400 variables and 150 email customizations one at a time for testing and each time I want to update my template. I think this would be even more tedious, not to mention error prone, than deleting 520 nodes.

During a restore/migration from 994i to IoP, can one bypass the loading/migrating of all the Insteon and Zwave devices by simply not enabling support for them in IoP? Would like to do a fresh start device wise (i.e. no devices) but have everything else brought over to avoid having to redo a whole bunch of work. I know I can start from a blank IoP and import programs and network resources, but I don't see a way to import my nearly 400 variables and 150 custom emails. (Am I just missing how to do that?) In addition to wanting to do a fresh start for some zmatter board testing before I migrate anything, I'd like to have a way to build an eisy "template" that I can use to resell pre-configured/customized eisy's to other people without having to manually re-enter all my variables and related email customizations. Since the template would evolve based on my own Polisy work, I'd like the ability to restore my always changing latest backup without restoring any of the devices to the new eisy.

What makes me feel better is confirmation that I don't have to pull the board once I've put it in. If all else fails I would ask UD support but I don't want to bug them with questions I figure could be answered in the forum. They have their hands full right now. Add to this the fact that others with the same question will also avoid bugging UD support and it just seemed like the better thing to do.

Thank you @ShawnW for re-asking the questions that got buried in my "Baby Steps" thread, which was closed before they could be answered. In fairness I should have started a "Baby Steps 2" post for them because I was looking ahead beyond the plain OS-only upgrade I was asking about in my original post. I know people are quick to say "RTFM - it's all there" but the manual, which I did read, 1) covers 3 variations of hardware 2) covers do-it-all-at-once migration, which is not what I want to do 3) has so many extra steps not typically not seen in s/w upgrades that vary by hardware variation (different number of button pushes, long waits, reboots, then power cycles, then install board, then reboot again, then possibly uninstall board (still not clear on that), then load this or that, then reinstall board, etc.) Now add to the above a still alpha release upgrade process that has significant bugs and inevitably one wonders 'is there a bug or is it a missed step?' I don't think anyone should tell anyone to RTFM for asking that some things be confirmed for their particular combination by others who have more experience with the migration. Just confirm or deny them. If you want to add the reference go ahead, but consider skipping the lecture for all the reasons mentioned here. So the answer is clear that the zmatter board gets overwritten as opposed to the very valid concept of adding or appending. Note that the instructions do say "A migration backup is different than a regular backup". So not crazy to think (hope, actually) that maybe an append was being done. At any rate it really helps knowing this with certainty. I'm still not quite clear on what has been confirmed to work for the situation where the zmatter board has already been been installed for pre-migration testing. Maybe I just ended up cross-eyed reading the various do-it-all-at-once instructions, but, sorry, I'm not seeing where this particular scenario is covered. An interesting possibly was mentioned by @DennisC that would certainly make things easier. He says "Just leave the Zwave support box unchecked until you are told to make sure it is checked." Does that work? DennisC, have you done it this way yourself? Has anyone? "Add board" (found in the instructions) has different implications than "check box". The former has low level OS impact while the latter is an IoP logical concept. Given the complexity/fragility of the upgrade process, I would really like some confirmation that I can have the board in for my testing and all I will need to do is uncheck "Zwave support" box before I start the migration process. Then , when the instructions say "add board", I just need to check the box and reboot, as implied by what would happen if I was to add the board at that point. Any info that confirms or corrects this would be appreciated.