jec6613

You'll need to contact support, install an updated pkg they'll provide, and then manually pick the port. They have a procedure though, so I'd expect you'd have a quick answer Tuesday (or Monday if they're working over MLK).

Update: after working with support, they have a test workaround for this behavior. It had to do with board detection on startup.

They actually did offer all that through the Hub... for the original Hub when it launched over a decade ago - heck, it even had a basic HTTP interface for the whole setup that exposed everything. Before that was the networked PLM that you could use with PC software (HouseLinc? I think) to configure it and it would also expose everything over a standard basic HTTP interface so anything could hook it. And a number of AV vendors took advantage of it before they got into their own lighting - Elan and URC, among others, used it as one of their lighting options before they brought more sophisticated control in house. The Hub 2 and MSII came out relatively close to each other and were when things locked down, but what you're asking for existed for the bulk of Insteon's history.

I mean, not exactly true... for most of its existance Insteon was quite open about things, it's only the last few years (relatively speaking) that have caused issues. Which I guess is 6 or 7 years now with the MSII launch.

Yep, I tried pulling the plug. No change. It's integrated on Polisy. Edit: I suspect the board is stuck in some sort of unusual state given it was 100% OK until restarting ISY as part of the update, so more likely software. Either way though, I'll report back.

I haven't had a reply to my ticket yet, but just in case anybody has seen anything similar, this is in the ZWAY.LOG and seems interesting: [admin@polisy ~]$ -- UDZWay - onIsyStartup() - initialize port - Start [2023-01-10 13:31:32.173] [W] [isy] [ZMATTER-ZWAVE] Cannot convert port name [/dev/ttyu0] to cua [2023-01-10 13:31:32.173] [I] [isy] [ZMATTER-DETECT-PORT|/dev/ttyU0] Start ZMatter Z-Wave port detection [2023-01-10 13:31:32.583] [I] [isy] [ZMATTER-DETECT-PORT|/dev/ttyU0] Clearing serial data (6 bytes) [2023-01-10 13:31:32.634] [I] [isy] [ZMATTER-DETECT-PORT|/dev/ttyU0] Requesting device information (1) [2023-01-10 13:31:32.635] [I] [isy] [ZMATTER-DETECT-PORT|/dev/ttyU0] Unexpected reply, not ZMatter Z-Wave port [2023-01-10 13:31:32.655] [I] [isy] [ZMATTER-DETECT-PORT|/dev/ttyU1] Start ZMatter Z-Wave port detection [2023-01-10 13:31:34.029] [I] [isy] [ZMATTER-DETECT-PORT|/dev/ttyU1] Clearing serial data (21 bytes) [2023-01-10 13:31:34.082] [I] [isy] [ZMATTER-DETECT-PORT|/dev/ttyU1] Requesting device information (1) [2023-01-10 13:31:36.144] [I] [isy] [ZMATTER-DETECT-PORT|/dev/ttyU1] Requesting device information (2) [2023-01-10 13:31:36.146] [I] [isy] [ZMATTER-DETECT-PORT|/dev/ttyU1] Unexpected reply length, not ZMatter Z-Wave port [2023-01-10 13:31:36.148] [I] [isy] [ZMATTER-DETECT-PORT|/dev/ttyU2] Start ZMatter Z-Wave port detection [2023-01-10 13:31:38.150] [I] [isy] [ZMATTER-DETECT-PORT|/dev/ttyU2] Requesting device information (1) [2023-01-10 13:31:41.182] [I] [isy] [ZMATTER-DETECT-PORT|/dev/ttyU2] No reply, not ZMatter Z-Wave port [2023-01-10 13:31:41.183] [I] [isy] -- UDZWay - onIsyStartup() - initialize port - Complete

I will update. I've opened a support ticket and I do have an up to date Java AC.

After upgrading, I can't query or send commands to any Z-Wave devices. Doing a Z-Wave X-Ray on DH All Devices and DH Controller give the following: <?xml version="1.0" encoding="UTF-8"?><RestResponse succeeded="false"><status>404</status></RestResponse>

Not scenes in the Insteon sense, but since it's IP based the speed should be sufficient to make it irrelevant assuming the controlling device has a reasonable IP stack, even before the multicast support. On a 60 Hz AC system, assuming devices respond in less than 16 ms they'll all start a dim/brighten on the same A/C cycle, which for dimmers means at exactly the same time. For our friends on 50 Hz systems, that's 20 ms. If the controlling device can issue commands in sequence in the sub-ms range, it'll appear to be a native scene. There are a lot of dependencies on how good your Wi-Fi is and how congested it is, of course, but even if they respond within 100 ms that should be fine for most people to avoid visible popcorning. Additionally, Matter can be exposed by an Insteon, ZigBee/Thread, Lutron, or similar hub device which does support native scenes. For larger installs, this is a much better choice than native Matter devices to keep latency low and keep from overcrowding the IP network (even a /23 fills up fast with HA devices) and more importantly the Wi-Fi network where each device demands a timeslice on the WAPs.

3M command strips. The heavy duty velcro ones would be my choice so I could take it down.

Now to see if they actually do it, and if UDI has the capability to add them to their code base in a reasonable time with all of the z-wave and matter stuff going on right now.

Well I'm excited. Aside from critical breaking issues, the rest of my experience with ZMatter has been excellent. Even my Insteon network is working much better, and there's really no cause for that.

Login to the AC using admin/admin, your password is reset. And make sure to go and make sure Insteon support is enabled, then restart IoX once the Z-Wave interviews have finished.

No change.

New issue: Z-Wave devices are no longer adding nodes at all. I've tried restarting IoX and the entire Polisy, and when I add devices they fail to create anything anymore. I've tried several, not sure what's going on.

I'm hopeful. For those it's not impactful but just a bit annoying.

Count me as another having issues with the Aeotec Range Extender 7's not showing as a node. Perhaps because there's nothing really to control, they do appear to route and everything correctly at least, but it would be better if they showed as a node. They're also some of the few devices that failed to come back after the automated transfer, which caused a number of downlevel devices that needed interviews because there was no viable route.

You can run them just fine, but the amount of manual programming is pretty extreme if you want them to share devices. To my knowledge the only way to do this programmatically was using an Insteon TouchLinc when using the HouseLinc software, which would manage multiple controllers as one unified system. UDI could theoretically add a feature to IoX to manage the link table on a 2448A7 as a secondary controller, and it probably wouldn't even be that much work, but they've never indicated a wish to do so, and have indicated the future for UDI is not Insteon. For independent devices where each controller has independent client devices, they see each other's traffic and do collision avoidance, so it works 100% fine. Insteon devices actually support a few hundred endpoints as controllers, with the precise number varying somewhat and available in the spec sheet. A PLM is no different from any other device it pairs to in this regard, it just has a relatively large link database table.

It's not changed in 5.5.0, and probably won't change if at all. IoX = "ISY on Anything", it's a change from IoP = "ISY on Polisy" to accommodate the eisy | home box they've started selling. ISY is still in the name

My experience: I had updated my Polisy earlier today, so I was as up to date as I likely could be. Clicked the Upgrade Packages button, then waited an hour. ioX never came back up and checking in top showed no activity on pkg or anything else related. Gave Polisy a soft reboot (sudo reboot), after about 5 minutes IoX came up, but after another hour Polyglot3 hadn't started. Clicked the Upgrade Packages button again, within 2 minutes Polyglot was up and running. I haven't switched to the new ZMatter board and have both it and Zooz installed, but am still working on the Zooz for the moment until there's some more migration experience for me to read up on. Once it got up and running, it runs basically like 5.4.5.

Works fine with Polisy so I'm going with yes. Do note that it's much slower and less capable than a dual band PLM, but for smaller networks it works very well.

It honestly looks a ton like a NUC 11 Essential, right down to the price point. It looks like UDI only put in a small markup (or got a good deal on trays of 1k units): https://www.intel.com/content/www/us/en/products/sku/217669/intel-nuc-11-essential-kit-nuc11atkc4/specifications.html The N5105 has an extremely long support tail, since its target markets include embedded, IoT, and routers. Long term prospects are much better than Polisy, not the least of which is because it has enough CPU power and RAM to go forward with. For the curious, the Atlas Canyon CPUs are basically one of the quad E-Core bundles lifted out of Alder Lake (12th Gen), with an 11th Gen dual channel memory controller, and modern Intel GPU onboard. Unlike the AMD chip that runs Polisy where it was a modestly updated older design, this Intel chip is really cutting edge.

I interpreted this comment about upgrading the firmware on the Z-Wave devices themselves, which is definitely a pain for both Polisy and ISY994. Though, in my experience, at least with the old ISY Z-Wave 500 board, a firmware update would cause a decent size Z-Wave network to positively crawl (1 minute or so delays to commands) for an hour or two after startup while the ISY queried the whole Insteon and Z-Wave networks. Not so much on Polisy though.

I'd say the biggest things that the polisy gives you are much better performance, the ability to use USB PLMs and the like which expands the pool of available PLMs, and much better Z-wave support once the new daughter board (Zmatter? MatterZ? Whatever it's called) including firmware updates. You can use the Polyglot on Polisy in addition to your ISY, but there's no benefit to keeping the 994 around once you migrate to IoP/IoX. My 994 got shipped to my mother's place after her hub went offline, and before that it was sitting on a shelf for months.

I have a tool just for attaching those connectors, it's the same used when replacing a laptop WLAN or WWAN card.