jec6613

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.

I didn't say pause, just queue. Writing out to a device is likely less important than accepting new alarms, and this behavior was in the ISY994 as well.

3. Much more reliable integration into the PG2/PG3 on Polisy. But holy cow is it much faster. Nighttime automations that would take 20 minutes during which automations could lag up to 30 seconds, are now done in 5 minutes and no commands lag in the meantime. I have ~700 nodes, so that may be part of my issue, but still.

Because said nodeservers won't respond while you're doing the add/remove, I'd hazard a guess. The ISY has a good queuing system, and I'd rather it not miss a potentially important notification.

Outlook.com is way more secure than you think it is. Since the ISY doesn't support modern auth (modern auth = a specific Microsoft term referencing a method of securely connecting to a service using cryptographic tokens rather than passwords), you'll need to jump through some slightly unusual hoops to get it set up. Anyway, long story short: you need to update your SMTP server info: https://support.microsoft.com/en-us/office/pop-imap-and-smtp-settings-for-outlook-com-d088b986-291d-42b8-9564-9c414e2aa040 And you need to set up an app password: https://support.microsoft.com/en-us/account-billing/using-app-passwords-with-apps-that-don-t-support-two-step-verification-5896ed9b-4263-e681-128a-a6f2979a7944