jec6613

If I had to hazard a guess, it wasn't selling as well as the other i3 devices simply because they already had a really good paddle switch and dimmer.

It doesn't persist, and there's no way to programmatically set it. Either would fix the issue.

Yes, this exactly!

With eisy-ui coming along and the Admin Console going away eventually, I figured now would be a good time to ask about this. I have a number of scenes where I update the action response to battery operated motion sensors, so on every boot of IoX (or ISY from 5.x onward, this worked without issue in 4.x) I have to go in and manually disable automatic writes to battery powered devices, otherwise over the course of a week or so the performance goes off a cliff due to all of the pending writes. Does anybody have a way of doing this using a program? The option isn't in the eisy-ui at all, and frankly after years of this it's getting old and I want to remove one more, "After power loss.." things from my life.

Didn't realize that had changed, apparently with the 6.0.0 release - go figure. My polisy got turned into a backup router after an SSD failure (and a second eisy as a backup controller).

The only big difference at this point is that the eisy supports eisy-ui, a new web-based GUI, which while it doesn't fully replace the Java admin console yet, it will be in the future. From an automation perspective, they're identical, as is the new eisy V2, including Z-Wave handling. Though I will note that because the Z-Wave is external in the eisy, you can relocate it to a more advantageous location.

I think you mean bridge mode, not broadcast mode, but, yes, Optimum does that to reduce their own support calls.

As others have said - filters. If you need more than 10A, an ordinary X10 noise filter does about 90% of the job of the Insteon FilterLinc, and are available at 20A and more.

Quite a bit later, but on a related topic I really wish that the UD Mobile favorites config could just be a bunch of XML or similar so I could just edit it with a keyboard.

So, shocker, Wi-Fi 7 does make a difference for home automation. There's an update in the spec where devices can sleep and be woken, unlike on previous versions where every device constantly sent beacons and filled up the airwaves. This lets you put more HA devices onto Wi-Fi. But the Wi-Fi 6 in the current eisy only runs at Wi-Fi 5 anyway.

Since Wi-Fi 5 barely has support in FreeBSD 15, we're probably 3-4 years away at least until either of these changes make a difference in how the device behaves. However, if it really bugs you, you can always just take the WiFi card out of the old eisy and put it in the new one, it's just an E-key M.2 card if memory serves.

Very much seems like MeLE stopped making the old hardware, so just pick and validate a new one. It's a big advantage of moving off of the ISY994 and later apu2 (Polisy) hardware, it's quite easy to move to a new platform as hardware ages. The CPU is of course tons faster in IPC (the N150 has a new core design from Alder Lake), so that's a good thing, as is lower power consumption from the new process node.

I haven't checked the portal UUID or looked at what the UID coming to my DHCP server is since I changed the reservation, but yes I can confirm that I have an IPv4 address.

It's sending a unique ID, not its MAC address, to supported servers. This has been the new standard for a few years now to support IPv6 - that unique ID is not dependent on the NIC but is for the entire system, so a well designed system can multi-path over multiple NICs with multiple IPv6 addresses.

I had the same issue - see my post earlier about DHCP changes with the OS update.