jec6613

I assure you that I will be among the first to order. For the Matter(ZigBee) portion of it, will it be able to join devices right away or will that be pending future firmware updates? For instance, can it take over the role of a TRADFRI or Hue hub?

I agree, it's not a good idea, just one that is technically possible. People also use male-to-male extension cords for Christmas lights ... just don't do it in the house next door to me. As long as you have constant power to the receptacle you can put it in the same box as the outlet, then there's no need for the 3 wire cable, just a few inches of pigtail. If your home uses some of the non-standard outlet shapes, it's a great trick to Insteon or Z-Wave enable them, and is also what many of our friends overseas do in order to get smart outlets.

A pair of diagonal cutters fixes that post haste - you can run each socket on a different input no problem.

You can enclose it to make it outdoor rated. Another option would be one of the Z-Wave or Insteon micro dimmer modules - though this runs into the, "You're dimming a receptacle and that's not at all to code," problem, so remember to rip it out if you ever sell the house.

Given that your customers likely have more devices on average, they may see quite a bit of benefit to helping you because we can and will purchase many of the Nokia devices if ISY/Polisy/Eisy support them. I'm hopeful but definitely not counting on it.

I mean, $200 to not have an entire Insteon network end up unable to talk to a controller seems perfectly reasonable, but that's why I'm not a business owner.

My own wife might object to that. I'm just picky about how my laundry is done.

If their dryers are newer, many have the ability to have a bolt-on wifi module that does exactly that - notification to the phone. It's what I do since my laundry is in the basement and the living spaces are all upstairs, buzzes my phone and watch when a cycle is done.

In keeping up with the latest news, both Intel and AMD have now both forecast about a 20% downturn in near future chip production due to so many ongoing order cancellations. So you can probably spread that across most of the chip production industry. Not a good sign for the tech economy but it does mean that some orders are probably moving to the front of the queues. Of course that is probably only the tip of the iceberg as many buyers were placing duplicate and triplicate orders with multiple vendors hoping Intel's fabs have one customer: Intel. So order cancellations aren't the problem for the, they're not a foundry (yet, they are entering that business). For Intel this is about demand softening. AMD produces no chips, so is also 100% about demand softening. Other orders are moving to the front of queues, but nobody puts in orders across different manufacturers for the same product as they're not interchangeable. One cannot simple swap from a 35nm Samsung to 35nm TSMC node, the chip needs to be redesigned with the target fab and node in mind. This is why when the GlobalFoundries fab in upstate NY was closing, the USAF put in an emergency $1Bn order for chips that could only be made there as the last fab on that particular process to keep a number of chips in stock through the end of life of the equipment they were installed in.

I'd love it if it could be used to pipe output from Blue Iris, or just have some sort of dashboard with a 10' UI or touch screen UI. The Niles touch screens I've put in have met with a ton of spousal approval. A lot of options, but all require a lot of work.

You can just get the Aeotec door sensor and put an arbitrary long sensor on it. The new Aeotec leak sensor and door sensor are the same device, one just has a water sensor soldered on where the other had screw terminals.

The door sensor was originally the TriggerLinc and they advertised it more heavily - you can use it to handle any dry contact switches including a simple push button, which I've used in a few locations either with a remote reed switch itself could be subject to weather (and therefore bad to have the door sensor itself on it) or to use a pair of reed switches to detect either of a pair of doors using a single door sensor - though in this case either door closing would show the sensor closed, it's still effective in certain situations - in my case, double door reach-in closets where the light only turns on with both open, and will turn off with either closed. Unless I'm doing a direct link to a light switch though, nowadays I use the Aeotec Door Sensor 7 Pro, which is smaller and performs just as well.

You know that with a simple remote probe that the door sensor becomes a leak detector, right? ?

Exactly, the voltmeter you're using needs a power source to send the update. There are any number of devices that can be battery or or UPS powered but can detect voltage presence external to their own power source, but this isn't one of them. Side note: Those nifty Z-Wave replacements for IOLincs (ZEN17 comes to mind) can do this, as they can be externally powered and detect a 12-24V signal, such as your doorbell transformer provides - though lacking that any old 12-24V wall wart with the connector cut off would work.

Except what's powering the switch to send that?

How would this work, exactly? Once the Smart Switch 7 looses power, it won't report anything, so if it's before the UPS then you'll just get no report at all from it (which could be done with almost any device, not just a smart switch 7). If it's behind the UPS, it'll just be reporting the line voltage out of the UPS. The only effective way I've found of reporting on an outage is to use a Ping Node server to poll a device that only has A/C power. Or simply to query the UPS itself if it supports such reporting - better ones do.

This also has less obvious but more important uses than that - if you have an Elk alarm system or similar critical device that you've linked to the Polisy, the built-in switch means that you do not rely on the rest of your network being up at all for that integration to work properly. Depending on how robust your network is, that may be pretty important!

Are you on WiFi? The AC is very sensitive to even a momentary connection drop, I had to disable all of my NIC's power saving to keep it from disconnecting periodically - but since then, well, I launched it 2 days ago and it's still open and connected.

As the end of June is upon us, any news on this? I don't actually expect to have it in my hands for a few months, but I'm ready to whip out the credit card and upgrade my original Geek Batch Polisy.

WiFi (802.11n era) needs to give the clear to send signal at minimum intervals for all STAs. Once you're on 802.11ac with MU-MIMO, or 802.11ax, the problem mostly disappears. That's why in 802.11ac Wave 2 was such a boon for dense configuration. But, most IoT are still 802.11n 2.4 GHz only. As for the backhaul, on good mesh devices, it's a dedicated radio so there's nothing eating up bandwidth. As an example, the Netgear RBRE960 sports: 2.4 GHz 802.11ax for clients - 4x4 (1200 Mbps PHY) 5 GHz 802.11ax for clients - 4x4 (2400 Mbps PHY) 6 GHz 802.11ax for clients - 4x4 (2400 Mbps PHY) 5 GHz 802.11ax backhaul only - 8x8 (4800 Mbps PHY) Now, obviously, in a normal mesh configuration you'd be using a 600 Mbps 20 MHz channel for 2.4 GHz so you could get an aggregate 1800 Mbps across three WAPs, but, yeah. Good wireless backhaul can outperform Gigabit Ethernet. Yes it can, although in IPv4 nobody's done it, it's been used in IPv6 for some experimental uses and backhaul among networks. This depends on the vendor, but the high quality ones use similar auto channel selection to a traditional Cisco controller - which means normally yes, different channels. They also use the power back strategy on a per radio basis, and on newer WiFi 6 devices they dynamically adjust power based on which STA are currently connected and reduce power to radios on other WAPs.

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.