jec6613

My PLM ended up no longer responding after a near lightning strike, so I'm using the USB RF only dongle for now ... I'm hopeful the new PLMs come out soon because the performance is extremely poor compared to the PLM. FWIW, I only had one pre-2016 go dead due to capacitor issues, the other two PLM deaths were both due to lightning. They seem quite susceptible to strikes compared to most other devices, the only other device I had take a dive with a network switch that blew all of its capacitors at once and started leaking electrolyte from the case - the worst case on other devices was a hard reset and a restore.

If you're re-making the injection molds anyway due to wear on the old ones though, you might as well make the simpler relay one as well since it's easier to manufacture with fewer holes. Over the life of the molds I'm sure it saved money.

If you can find them still, Philips Warm Glow work very well. Most Amazon knock-off brands do pretty poorly though.

It definitely is a router firmware bug of some description. The Polisy adheres strictly to the DHCP and DNS protocol, which can cause issues with some buggy DHCP and DNS implementations. Is the Polisy pingable via IP and just not findable? In which case, it's an issue with the DNS not working properly. If not, it's an issue with DHCP not issuing an IP and Polisy being strict doesn't retry for a while.

@Michel Kohanimhas given us most of this info if you go back in his posts. eisy is a more powerful version of Polisy with some other updates, the ZMatter board will work in both Polisy and eisy with an adapter that will be available with the eisy, and you'll be able to transplant the board between the two when you choose to upgrade. My personal take on this is that I'll upgrade my Polisy for now, and upgrade to eisy when convenient to me. As for the lack of Matter devices, currently that is correct, but not for long. There are a number of manufacturers that have release devices that will work with Matter via a firmware update (including the entire Ikea TRADFRI lineup) but November seems to be the launch date for everybody.

Those are standard SMA antennas, you can easily get some 50 ohm sma extension cables.

I did as well. Boo, have to wait until November! I'm impatient and want my intermittent Z-Wave issues fixed!

Both CR and LF and supported in the GSM-7 character set; however, the paragraph mark that's inserted by just hitting Enter to feed to the next line is not. First thing I'd try is to ensure you're using the CR character by typing the message with Shift+Enter for each new line. Another possibility is that you're sending to an SMS gateway that strips formatting - I know Verizon in the US actually has two distinct gateways, one for SMS and one for MMS, that handle pure text messages differently.

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.

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.

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? ?

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.