johnnyt

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.

I'll add that my Polisy is at 5.4.5. I don't think I've updated it since last spring, adding to my worries that Murphy's Law will apply here.

Oh, no! This is not good news. At over 900 programs I find the 994i excruciatingly slow to load (and back up). I was really counting on Polisy speeding things up. Am just waiting for stable zwave migration as I have way too many to start over from scratch. Is it slow on eisy too?

@lilyoyo1 I'm referring to updating my Polisy, not my 994i. I mentioned the 994 to make the point that I'm not using IoP on the Polisy. (I probably should have just said that.) If possible, I'd like to try the zmatter board to confirm it works before I even attempt a migration, not to mention make sure my Polisy upgrades okay. I think I read of some ending up bricked doing upgrades relatively recently. Mine bricked doing BIOS upgrade several months ago because I have one of the early models that needed a special chip mailed to me in order to get the latest BIOS installed. Then, when I got it, there was a picture of where it goes but no instructions that said I had to remove it after it finished booting. I ended up with NO Polisy / Node Servers for about a month while I waited *twice* for the chip to get to me. What if something else related to early h/w version (or any other multitude of reasons) causes a problem not caught yet because so far everyone else trying is not in same situation I am? With the following amount of stuff running on my 994i, I'm definitely waiting until things are more stable before I do the migration but am also in a hurry to get there because the 994i is (has been) struggling to say the least. I'm also going to do as many steps as I can *before* I do the migration to rule out or solve problems that might occur before what I fear will be - assuming no hardware problems - a multi day process.

I'm still on 994i and only using Polisy for PG3/Node servers. Can I just upgrade to latest version (5.5.4 as of today) and everything should work fine? Or am I committed to doing a migration if I do that? I'm not sure if there's anything to gain in terms of bug fixes but thinking this is a way to take a baby step to get that part of the process done and make sure everything works fine starting with that. Then, as a subsequent baby step after that, could I install my zmatter board and test it with IoP and a couple of devices not in use with 994i, i.e. starting from scratch as though I had just bought the Polisy?

I've changed a couple of my Airthings (AT) devices using the AT web dashboard "settings" option (not the app, which is a more drastic update that archives the device readings up to that point and resets the calibration period) but the names don't change in NS Nodes panel or ISY. Yes, I have the NS configured with change_node_name set to true For example, I dropped an apostrophe for 2 devices in the AT Dashboard but the apostrophe remains in NS and ISY. Is that because we're talking about an apostrophe, i.e. a special character? I didn't test that theory but think this should be fixed anyway so figured I would report it. That or a clear warning should be put in a highly visible spot that warns against the use of any problematic characters if that's the case to give people a chance to rename any offending device before they start the NS.

ok, this one reads more like the original that has proven to work, is cheaper than the other one I found and will get to me reasonably soon https://www.amazon.ca/gp/product/B01MCV52TH/ref=ox_sc_act_title_1?smid=A3TUR5JBYCEPNE&psc=1

good idea. would this adapter work? It would be a bit cheaper (in Cdn $) and get to me faster. It reads like it would also be compatible with more SSDs... https://www.amazon.ca/gp/product/B075FR3ZD4/ref=ox_sc_act_title_1?smid=A1X7UA978W3K5N&th=1 The one in previous post says: "only supports mSATA SSD (3cm*5cm), and does not support SATA Mini PCIE/PATA mini PCIE/RAID MINI PCIE SSD." while this one says "Support full size mSATA ssd 51mm(L) x 30mm(W) x 3.8mm(H). Supports 3.3 Volt Mini PCI-e SSD mSATA Module" Is this one compatible with more SSDs than the one above, or is this comparing an apple to an orange and it won't even work with Polisy SSD?