jec6613

That's ... literally what the IP broadcast address is for. If you have a network, 192.168.0.0/24, with 192.168.0.1 as your router, then by sending a packet to 192.168.0.255 it lights up every single device on that subnet. For Layer 2 devices, if you send to MAC FF:FF:FF:FF:FF:FF, then it hits every port on your L2 broadcast domain. There's also IPv4 multicasting, which take advantage of the above to deliver messages to only subscribed clients. And, finally, IPv6 uses multicasting to address multiple devices at once, since IPv6 lacks a broadcast address since a standard residential /64 subnet could contain up to 18 quintillion devices (future proof much?)

They do in fact do all of the above. The controller functions are now so light relative to modern processors that they use one of the mesh nodes to act as a controller - exchanging keys and everything. Cisco has had this for over a decade on their small business line of traditional WAPs (they called it "Single point setup") Only fast roaming (802.11k/r) and assisted roaming requires a WiFi controller, devices can roam just fine by trying to figure out what's best by themselves, it's just that they necessarily are horrible at it.

Bandwidth in WiFi is a fickle thing. Technically, you can move some obscene amount of bits around - but after the protocol overhead and weak signals, there be dragons. @larryllixIn 802.11n, used on the 2.4 GHz channel by WiFi 5, each device beacons and exchanges L1 and L2 data on a set interval. To solve the hidden station problem, these are the same length of time regardless of how much data is actually transmitted. That means if you have 100 IoT devices on a normal 2.4 GHz WAP with 200 maximum devices, half of the WAP's time and therefore potential bandwidth is spent transmitting literally zero data, just with the devices confirming there is no data to be sent. So if you take a typical 300 Mbps 802.11n 2.4 GHz deployment, add 100 IoT devices to it, you now have a theoretical maximum of 150 Mbps available to that 101st device that's streaming Netflix. Add in the various protocol overheads to ensure reliable data transmission, and you're now at about 80 Mbps. And now that 101st device is a Roku stuck behind a TV with terrible interference and can only reach 1/4 of its maximum rate, and now it's 20 Mbps. Not actually enough for 4K streaming. The long of the short of it is: the more associated STA, the less of your actual bandwidth your devices have available. And, by the way, all of the above is shared with all WAPs that your WAP can see sharing its channel, as they arrange who gets which timeslice in a particular channel. WiFi 6/802.11ax solves this by using a few methods - first, by making it work on 2.4 GHz as well for all those cheap IoT devices that use 2.4 GHz (the higher data rate means more room to start with), adding MU-MIMO support, and then it also uses sub channels and target wait times so that when a bandwidth hungry device demands the WAP's attention, it actually does receive close to the WAP's maximum available bandwidth despite so many other devices being connected. But legacy WiFi 5 installs, or legacy WiFi 5 devices connecting to WiFi 6 networks, still suffer this problem. @RPerraultMesh devices work generally by emulating what a traditional multi-access point setup would do - allowing devices to roam between them as required for coverage and bandwidth. Like a traditional multi-AP setup, their software manages channels and client devices for optimum performance. Most of the time, they're on independent channels for the client devices to connect to. Their trick is that they use WiFi to transmit data back to the main router, rather than moving it over more traditional wired Ethernet (though many can and will happily use Ethernet if you have it available. Why this is great with a lot of IoT devices is that 1) it solves the above mentioned timeslicing problem on the networking by simply brute forcing it with large numbers of WAPs, each able to use optimal channels, 2) the higher WAP population means the average power transmission so less interference with other WAPs sharing the channel and, 3) by using a closer WAP, the average data rate tends to be much higher for devices that do transmit a lot of data. Even though the backhaul uses WiFi, it's only a handful of devices communicating, with the clearest possible channel, with highly optimized antennas and very fast radios (8x8 is normal). And because no clients are on them, the "I have nothing for you" packets that are between the clients and WAPs simply never get transmitted across the backhaul connection except by the other WAPs in the mesh.

Z-Wave Association is better, as it's faster, but it's still sending multiple commands over a routed network with hops and full traffic control, so it reduces but doesn't eliminate it.

For me, Z-Wave popcorning (and latency in general) always depended on how big the network was and what devices were in it. I just moved everything that was latency sensitive off of Z-Wave and used Insteon, worked much better. As for WiFi, as you mention, Netflix doesn't use much actual bandwidth, but with WiFi 5 (802.11ac) and earlier every single device connected to the WAP uses a percentage of available airtime on that channel. And with out of the box config, it usually is about a full percent just to have an associated device. If you put 50 802.11ac home automation devices on a modern router capable of 600+ Mbps PHY rate in 2.4 GHz, and put all of your devices an average of a room away so almost nobody is running at the full PHY, add in beaconing and other WAP overhead, now you have a total of ~20-30 Mbps available for that Netflix device. Add somebody working from home over Zoom and some remote desktop things, and now Netflix is buffering and stuttering. Of course, the above scenario doesn't have to be the case and is a bit extreme - adding another access point relieves a lot of that - even if that's just a 5 GHz access point in the same physical router/WAP to make it dual band, but you can see how traffic of a bunch of IoT devices can bring WiFi to its knees rapidly. This isn't without solutions though: Surprisingly, this is how a wireless backhaul mesh helps a ton - because you're putting a 2.4 GHz WAP every couple of rooms throughout your home, the individual AP can run at much lower power and still maintain a faster base data rate and much more efficiently use the spectrum. In terms of IoT device scaling, most homes installing mesh will scale their IoT capacity linearly through about 5-6 root and extender APs, and this doesn't depend on whether or not you're using wired or wireless backhaul. The other technology that's slowly making its way in is 802.11ax (WiFi 6) on the IoT clients as well as the APs. This allows each associated device to not have a full beacon time slice and frees up significantly amounts of bandwidth and air time on the WAP. This is because WiFi 6 clients, when communicating to a WiFi 6 AP, can set a non-standard interval for communication, requesting that the AP only communicate with them once an hour or even once a day unless there are incoming messages. Compared to the constant communication (and therefore air time) usage of WiFi 5, this is a huge improvement for IoT.

This is why I said it may not necessarily be cheap, and specified, "Unusual," requirements: 4a - is normal nowadays. This is a memory and to a lesser extent storage bound problem, not CPU, and even a $50 router can handle the table load now. DHCP table size is a complete nonfactor ... what is a factor is how large the table is specified to be by the firmware. 5 - is also normal nowadays. App based installs make it trivial, though are only on better products. 6 - as I said, it may not be cheap.

Overcoming the normal WiFi limitations isn't even that difficult, it's just not necessarily currently cheap. The only unusual requirements: WiFi 6/802.11ax on both the client and access point side. A sufficiently large IPv4 broadcast domain, or IPv6. Pervasive coverage that survives things like interference from a microwave oven or large sacks of mostly water roaming around the house (e.g. humans) A sufficiently large routing table to handle all of the connected devices. And ... that's it. It obviously isn't quite that simple in practice, but you can go and buy a system 100% compliant with these requirements, out of the box, today - Orbi and Google come to mind but I'm sure it's not exclusive to them.

Wow, haven't seen that one in a minute.

The opposite occurred, Insteon in early days did have some reasonable commercial installs, the UK Embassy in DC was the one they kept hammering on about. For about the first year or two (2005-2007), they were actually a reasonable competitor in this space, especially for retrofit applications. The traditional commercial lighting providers were caught a bit off guard, but recovered pretty quickly. After that they were pretty big in large homes for quite a while, providing lighting for Crestron, Elan, and related systems around that time (remember, at this point you could DIY a Crestron system). The last of the pivot towards general consumers and away from large installs was around 2014 when the app and hub came out and they started EOLing a lot of their higher end products such as HouseLinc and TouchLinc. This is also when the long discontinuation of a lot of the ancillary devices (think color change kits) started.

My preferred brand of Z-Wave dimmer is to not use Z-Wave, and use Lutron instead. Solves all of the problems you describe, just ... costs a lot of money.

Citation needed? But if so that's very cool for my future lighting.

You can take the courses to get access to the RA3 software yourself, much like RA2Select. RadioRA3 requires cloud for the app, but the API is local for automation systems with no cloud dependency. RadioRA2 is commonly used with the likes of Crestron and Elan with full offline control (Caseta is too, for that matter). Provided you're not using the Lutron app for your schedules and primary UI, you'd never know if the cloud went fully offline.

There's also a Caseta node server, so you can use Lutron Caseta. Depending on your timeframe, Lutron Sunnata and Lutron Maestro (via RadioRA3/RadioRA2) are also a possibility. The Maestro are the closest to Insteon I've been able to find in terms of how they function, with Maestro having a better dimmer and more luxurious feel (except for the button click for some reason).

I have no trouble with my T6 Pro like you're describing, either with the ISY994iZW Pro or the ISY on Polisy. Queries work fine, and since it's configured properly for my HVAC system, I don't have any short cycle or long delay issues. Of note, however, if it's not configured with the correct CPH and other settings (and there are ~100-ish on this thermostat) I would expect to have odd behavior. Out of the box with all default settings, I will indeed have quite poor thermostat behavior for both comfort cycle delays.

Lutron is different, and has a few product lines, from their training: Caseta: up to 75 devices and 1 repeater, 400 MHz RA2Select: Up to 100 devices and a pair of repeaters, 400 MHz RadioRA2: Up to 100 devices and a pair of repeaters (dealer only), 400 MHz RadioRA3: Newest, up to 100 devices on 2.4 GHz + 100 RadioRA2 400 MHz devices and every device with a neutral wire is a repeater QS: up to 10,000+ devices (I'm not familiar with it) If you want more info, please take their trainings - most of them are free for at least the basic product info, and go into a good amount of detail without being over-involved. For a quick list of pros/cons: Lutron does lighting and HVAC only, Z-Wave as a myriad of oddball devices like door locks and mouse traps. Lutron is a single vendor, if you don't like their aesthetics or assortment than you're SOL. Lutron's lighting system is just plain better. It's the only competitor to Insteon that avoids popcorning, and it's extremely reliable when installed correctly. Z-Wave is significantly less expensive. Z-Wave has longer reach if you have a strong mesh than all but RadioRA3 or QS systems. For my money, when I switch off of Insteon in the future, my lighting will go Lutron and my other devices Z-Wave.

The 2242 hubs had this has a built-in function, since it also functioned as a replacement for the 2412N. Full local web UI, even, you could have built a stack of networking modules into an ISY and used it as a PLM out of the box. Not sure how many of those are still kicking around though, most I've heard of in the US ended up getting swapped for 2245 hubs due to 2242 failures.

Odd to me that if it doesn't include a power supply, it doesn't have a DIN rail option at least. Would make total sense in a big DIN enclosure.

The network design itself: Peer to peer, and point to multipoint scenes. No popcorn and high reliability.

To my knowledge Lutron does not make any Z-Wave devices, they have their own proprietary RF technology that offers functionality on par with Insteon (e.g. no popcorning and so on), though the tech is very different under the hood. Could you be confusing Lutron with Leviton? Leviton does indeed make a very large variety of Z-Wave and WiFi devices.

For lighting systems, Lutron's are the best replacement (Z-Wave is still way behind). For everything else, Z-Wave is where it's at.

First, this is what I get when I put in the configuration information. I've sanitized MAC and IP, obviously 022-04-21 14:11:30,003 MainThread udi_interface INFO __init__:<module>: UDI Python Interface for Polyglot version 3 3.0.40 Starting... 2022-04-21 14:11:30,255 MainThread udi_interface.interface INFO interface:__init__: Initialization received from Polyglot V3 3.0.56 [ISY: 5.3.0, Slot: 4] 2022-04-21 14:11:30,257 MainThread udi_interface.interface INFO interface:__init__: Connect: Network Interface: {'addr': '192.168.xx.xx', 'netmask': '255.255.255.0', 'broadcast': '192.168.20.255'} 2022-04-21 14:11:30,259 Interface udi_interface.interface INFO interface:_startMqtt: Connecting to MQTT... localhost:1888 2022-04-21 14:11:30,268 MainThread udi_interface.interface WARNING interface:db_getNodeDrivers: controller not found in database. 2022-04-21 14:11:30,269 MainThread udi_interface.interface WARNING interface:send: MQTT Send waiting on connection :: {'config': {'version': '3.1.6'}} 2022-04-21 14:11:30,316 MQTT udi_interface.interface INFO interface:_connect: MQTT Connected with result code 0 (Success) 2022-04-21 14:11:30,318 MQTT udi_interface.interface INFO interface:_connect: MQTT Subscribing to topic: udi/pg3/ns/clients/00:0d:b9:52:bf:7c_4 - MID: 1 Result: 0 2022-04-21 14:11:30,334 MQTT udi_interface.interface INFO interface:_subscribe: MQTT Subscribed Succesfully for Message ID: 1 - QoS: (0,) 2022-04-21 14:11:33,284 MainThread udi_interface.interface INFO interface:addNode: Adding node DysonFan(controller) [None] 2022-04-21 14:11:34,918 Thread-4 udi_interface ERROR dysonfan:dysonConnect: Error connecting to 192.168.xx.xx, 'NoneType' object has no attribute 'connect' 2022-04-21 14:11:34,920 Thread-4 udi_interface ERROR udi_interface:write: Exception in thread 2022-04-21 14:11:34,921 Thread-4 udi_interface ERROR udi_interface:write: Thread-4 2022-04-21 14:11:34,921 Thread-4 udi_interface ERROR udi_interface:write: : 2022-04-21 14:11:34,922 Thread-4 udi_interface ERROR udi_interface:write: Traceback (most recent call last): 2022-04-21 14:11:34,923 Thread-4 udi_interface ERROR udi_interface:write: File "/usr/local/lib/python3.8/threading.py", line 932, in _bootstrap_inner 2022-04-21 14:11:34,927 Thread-4 udi_interface ERROR udi_interface:write: self.run() 2022-04-21 14:11:34,928 Thread-4 udi_interface ERROR udi_interface:write: File "/usr/local/lib/python3.8/threading.py", line 870, in run 2022-04-21 14:11:34,932 Thread-4 udi_interface ERROR udi_interface:write: self._target(*self._args, **self._kwargs) 2022-04-21 14:11:34,933 Thread-4 udi_interface ERROR udi_interface:write: File "/var/polyglot/pg3/ns/00:0d:b9:52:bf:7c_4/nodes/dysonfan.py", line 71, in start 2022-04-21 14:11:34,934 Thread-4 udi_interface ERROR udi_interface:write: self.dysonConnect() 2022-04-21 14:11:34,935 Thread-4 udi_interface ERROR udi_interface:write: File "/var/polyglot/pg3/ns/xx:xx:xx:xx:xx:xx_4/nodes/dysonfan.py", line 98, in dysonConnect 2022-04-21 14:11:34,936 Thread-4 udi_interface ERROR udi_interface:write: LOGGER.debug(f"Auto Mode is {self.dysonData.auto_mode}, Night Mode is {self.dysonData.night_mode}") 2022-04-21 14:11:34,937 Thread-4 udi_interface ERROR udi_interface:write: AttributeError 2022-04-21 14:11:34,938 Thread-4 udi_interface ERROR udi_interface:write: : 2022-04-21 14:11:34,938 Thread-4 udi_interface ERROR udi_interface:write: 'NoneType' object has no attribute 'auto_mode' 2022-04-21 14:11:57,798 Thread-5 udi_interface ERROR dysonfan:dysonConnect: Error connecting to 192.168.xx.xx, 'NoneType' object has no attribute 'connect' 2022-04-21 14:11:57,800 Thread-5 udi_interface ERROR udi_interface:write: Exception in thread 2022-04-21 14:11:57,801 Thread-5 udi_interface ERROR udi_interface:write: Thread-5 2022-04-21 14:11:57,801 Thread-5 udi_interface ERROR udi_interface:write: : 2022-04-21 14:11:57,802 Thread-5 udi_interface ERROR udi_interface:write: Traceback (most recent call last): 2022-04-21 14:11:57,803 Thread-5 udi_interface ERROR udi_interface:write: File "/var/polyglot/pg3/ns/xx:xx:xx:xx:xx:xx_4/nodes/dysonfan.py", line 106, in poll 2022-04-21 14:11:57,805 Thread-5 udi_interface ERROR udi_interface:write: if self.dysonData.is_connected is False: 2022-04-21 14:11:57,806 Thread-5 udi_interface ERROR udi_interface:write: AttributeError 2022-04-21 14:11:57,806 Thread-5 udi_interface ERROR udi_interface:write: : 2022-04-21 14:11:57,807 Thread-5 udi_interface ERROR udi_interface:write: 'NoneType' object has no attribute 'is_connected' 2022-04-21 14:11:57,808 Thread-5 udi_interface ERROR udi_interface:write: During handling of the above exception, another exception occurred: 2022-04-21 14:11:57,808 Thread-5 udi_interface ERROR udi_interface:write: Traceback (most recent call last): 2022-04-21 14:11:57,809 Thread-5 udi_interface ERROR udi_interface:write: File "/usr/local/lib/python3.8/threading.py", line 932, in _bootstrap_inner 2022-04-21 14:11:57,813 Thread-5 udi_interface ERROR udi_interface:write: self.run() 2022-04-21 14:11:57,814 Thread-5 udi_interface ERROR udi_interface:write: File "/usr/local/lib/python3.8/threading.py", line 870, in run 2022-04-21 14:11:57,818 Thread-5 udi_interface ERROR udi_interface:write: self._target(*self._args, **self._kwargs) 2022-04-21 14:11:57,819 Thread-5 udi_interface ERROR udi_interface:write: File "/var/polyglot/pg3/ns/xx:xx:xx:xx:xx:xx_4/nodes/dysonfan.py", line 113, in poll 2022-04-21 14:11:57,821 Thread-5 udi_interface ERROR udi_interface:write: self.dysonConnect() 2022-04-21 14:11:57,822 Thread-5 udi_interface ERROR udi_interface:write: File "/var/polyglot/pg3/ns/xx:xx:xx:xx:xx:xx_4/nodes/dysonfan.py", line 98, in dysonConnect 2022-04-21 14:11:57,824 Thread-5 udi_interface ERROR udi_interface:write: LOGGER.debug(f"Auto Mode is {self.dysonData.auto_mode}, Night Mode is {self.dysonData.night_mode}") 2022-04-21 14:11:57,825 Thread-5 udi_interface ERROR udi_interface:write: AttributeError 2022-04-21 14:11:57,825 Thread-5 udi_interface ERROR udi_interface:write: : 2022-04-21 14:11:57,826 Thread-5 udi_interface ERROR udi_interface:write: 'NoneType' object has no attribute 'auto_mode' Second question, how can I put in multiple Dyson devices?

The 240V load controller, DIN rail equipment, and so on were there to retrofit homes that did not have dedicated hard wired centralized lighting - or if they did, needed it upgraded/replaced. During the first years of Insteon, there was a huge market for Insteon-enabling homes with a custom integrator using custom controls and an Insteon PLM. You may recall that the UK embassy in DC was (is?) an 100% Insteon shop, but they weren't the only ones ... hundreds of devices into a home at once. You sometimes see the bulk removals on eBay of a bunch of older equipment. The only other competitor at the time was RadioRA, which was/is a very different sort of system - lighting only and professional installer required.

Exactly this. For something to go hard-off, it must have either: 1) A return path for current via a neutral wire, or 2) be powered by an external power source (this is how Z-Wave valve closers work).

Assuming that the original patents and IP were protected properly, "Pulling a Compaq," and cloning the IBM PC Insteon equipment might still be illegal, but either way would be an expensive court battle.

I mean, JMHO, but Michel has said several times that Insteon was not the future of UDI - but if having a PLM and some other devices available sells more Polisy devices and lets users move gracefully, it's a smart business decision. Time will tell what happens.