jec6613

Following, because I haven't installed my eisy yet for similar reasons. Also because Polisy is still actually really good hardware.

IKEA FYRTUR and TREDANSEN blinds (I believe these are functionally identical): https://www.ikea.com/us/en/p/fyrtur-black-out-roller-blind-smart-wireless-battery-operated-gray-50417464/ https://www.ikea.com/us/en/p/tredansen-black-out-cellular-blind-smart-wireless-battery-operated-white-50512437/ Controls of full up, full down, and set percent up/down; feedback of blind level when adjusted manually at the blind, and battery level. Basically: control like a dimmer.

If you're on WiFi the AVR-X1200W sleeps the telnet connection over WiFi and because of a firmware bug needs a connection on one of its HTTP ports to keep it open consistently.

Sort of? I've tried HA several times, their rollback doesn't work well unless you're in a VM template. pfSense, which runs on FreeBSD like eisy and Polisy, have some other rollback features. Either way though, an unexpected restart from an update is going to cause me problems.

There's a hardware TPM it's expecting, I don't recall that Proxmox handles that well. Some versions of Hyper-V can virtualize the TPM transparently, ESXi not so much. Further up the stack, you'll also need the drivers for things like NICs and other hardware you're passing through that aren't in the repo. And at the end of all of this, I'm not sure what you gain ... failover requires so much extra hardware to handle the TPM (at least two clusters) that you'd be better off with a recent backup and a cold standby eisy.

If you want to give it a shot trying to run it in a VM, why don't you just ask them for permission?

I have a 5 gallon expansion tank, and still just remove power to the well pump rather than attempt to drain the system. It's not enough to make much of a difference once a leak is detected.

I have three, unsure of firmware revisions but the two I've re-joined as S2 as well as my remaining S0 leftover don't send status updates at all, and I haven't tried setting user codes yet. Currently, they're extremely buggy ... fortunately I'm WFH and they still work as coded door locks so I'm alright for the moment. Working with support on all of this, obviously.

Contact support, they need to send you some updated code.

Why not just use one of the calendar node servers? It can provide day of the week, week number, and all sorts of other nodes you can trigger on. Want something to fire on the second Tuesday of the Month because you like Microsoft? Pretty easy to do when you have that as a node.

I'm young enough I can still spot the difference unmagnified, but I have made the mistake a couple of times. I just take a closer look and voila!

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.

R = Refurbished, it's the same as a 2477D.

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.