johnnyt

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.

ok things are NOT looking good here and in the IoX 5.5.5 support thread looks like I'll be waiting for a stable 5.5.6 to come before I take my first baby step.

From other posts it appears the 5.5.5 issues are related to PG3x 3.1.22 only, i.e. affecting eisy only - not affecting Polisy/PG3 users. This one below confirms there is an issue with eisy, and there are others from folks in that thread who said they are on Polisy/PG3 and everything is fine for them.

and it looks like the only way to get to 3.1.17 is to do IoX upgrade to 5.5.x. Am at 5.4.5 / PG3 3.1.16 and I see there's an upgrade available but no instructions on how to get there. In the past wasn't it done automagically with a Polyglot restart? If so, not working that way now.

Thanks @Geddy, @ShawnW for your replies. Yes, the idea of not falling too far behind is definitely part of my motivation. When I asked about cost, I didn't mean monetary cost. I meant time cost due to instability, bugs, or loss of functionality. And for sure I will use the Upgrade Packages button provided in IoP AC after doing a backup. Plus, I've noted the warning about how really long it could take. Thanks again. As my next baby step after upgrading IoP/Polisy to 5.5.5 and confirming everything works fine following that baby step, yes I was planning to install zwave board and a couple of zwave devices that are not currently connected to anything just to test things. My question there is related to the ISY migration instructions (for later) that said "do not install zmatter board until told to do so". Just to confirm - does that mean when I'm ready to migrate 994i to IoP I'll have to uninstall the zmatter board then reinstall it when told to do so, or was that step (or should I say delayed step) just to get through the addition of some core 5.5.x new stuff and not applicable anymore? And second, would the devices I had linked to IoP/Zmatter show up after the migration, or will everything on the zmatter board get overwritten (or the board get factory reset) by the ISY migration process? It would be nice if they remained connected as it would offer the possibility of setting up a bunch of things before I migrate that I could actually use after I migrate without having to uninstall (exclude) and reinstall (re-include) those devices and lose the device IDs I had used in programs. I know (or at least think) any programs would be overwritten so I would just export those then import them after the migration.

Let me ask my question differently. Given I'm not yet using IoP but I am using PG3 for 6 node servers (on a Polisy) and those need to keep working, does upgrading to the latest IoX version - now at 5.5.5: 1) offer any benefits, other than getting it out of the way (since I do plan to move to IoP)? 2) have any cost? I did see there were problems using PG3 when 5.5.5 came out but appears those were fixed a week ago now.

Weatherflow support confirmed that one is not able to see other station data with API, even though the data is available via browser for all to see. Aside from asking them to make other station data available through API (limit it to a few, if needed) I also asked them to consider making the error message reflect what the error actually is, e.g. "NOT AUTHORIZED" or something like that, instead of "NOT FOUND".

Okay. maybe Tempest doesn't let my API see this data (even though I can see it on the web). I'll report this to them and see what they say.

have done update, turned on debug level, and restarted NS. see attached log segment. weatherflowremotenotworking.txt

NS been working great. Today I added a remote station ID and the NS added all the ISY nodes as expected but gave the message "Failed to get station units, unable to continue" and the ISY node values are 0. I restarted the NS and waited a couple of short polls in case things self corrected but still not working. Is it because I'm not authorized to get that data, even though it's available on the web at https://tempestwx.com/station/77677/ or something else? I've attached relevant chunk of log (with api x'ed out) weatherflow-addedremote.txt

Not expecting any support for that, of course, but (getting ahead of myself) would expect to be able to have a different MAC whitelisted as long as I had purchased hardware. Only reason for doing it (if it's even possible and worth the trouble) is for the horsepower I could put behind IoP (once I migrate to it). I have 172 insteon nodes, 152 zwave devices, 990 programs, 5 node servers, with two very chatty ones shoveling lots of data. My 994i is struggling to process stuff and has been for a while. Although by all accounts things should be better once I move to Polisy (IoP), no one can reassure me it will be fast enough CPU-wise to cope because, from what I can tell, I'm the only ISY user with this much stuff. (I'm surprised by that every time I think about it.) Another reason for doing it could be for high availability, which Proxmox can offer in a way that having 2 Polisy's (or 2 eisy's) cannot, although I'm getting WAY ahead of myself even thinking about that.

Inspired by the baremetal backup idea posted here, I made an image of Polisy then tried to run it as a VM in Proxmox. According to @ase in the above thread: Using an X86-64 host running Proxmox hypervisor I tried a couple of different ways to import the .vhd file I created with Rufus (raw, converted to .qcow2) but it doesn't work. While lots of the early messages seemed to work successfully (couldn't capture them so might have missed an error), here's where things landed in all my attempts so far: Anyone try it? Or anyone familiar with Proxmox running Linux VMs able to suggest how I might need to configure the VM. Here's what got me this far: Like I said it appeared to work until it needed to mount the 'zudi' zfs pool.