mwester

Old ones and new ones have both worked side-by-side and interchangeably in my network for years. I lost one due to HW failure just a couple months ago, but have replacement capacitors on-hand to attempt a repair. The circuit boards are different, and the capacitor values are too I think -- but I've observed no differences in fundamental behavior or reliability.

Standard SSD (mSATA if I recall correctly).

Sarcasm, folks. To be serious -- the Nokia name-branding feels like the last gasp of a technology left to die. No amount of naming and branding is ever going to address the fact that the power-line technology used by Insteon doesn't work very well in the face of the "new normal" (switching power supplies muddying the zero-crossing point on the power-line). And opinion: every company I know that is having inventory/availability issues is scapegoating the "chip shortage" -- and I believe that SmartHome is no different. I suspect the truth is that it's a convenient thing they (and some of the smarthome fanbois on this forum) use as a smoke screen to keep some degree of consumer confidence up as they sell off remaining inventory in a desperate attempt to raise the cash necessary to introduce the newly-branded version of the same old (failing) technology. Finally, I realize that my comments are skirting dangerously close to the verboten topic of politics, but the fact is that at this juncture, politics has infected every aspect of life, to the point where neither sports nor my hobby serves as an escape. I've been far less active on this forum because over the summer, I spent a lot more time fishing -- where the mosquitos and leeches are less irritating than even my hobbies have become. I may be forced to take up ice-fishing soon. And for those interested in cross-over stuff -- no, there are no Insteon nor any Nokia fishing products. And neither (yet) are there any node servers for fishing...

Silly people. Nokia is European -- they don't celebrate American (or Canadian) Thanksgiving. Watch for the introductory sales starting for the Xmas season!

Observed here: the UDP packet is sent on the wrong network, or not sent at all, in the case where a given system has multiple networks attached. They don't have to be physical networks -- in my case, they are internal virtual networks created by virtualization software (Microsoft Hyper-V, VMware, VirtualBox, etc) or by Docker implementations.

The behavior you are observing has nothing to do with Z-Wave vs Insteon -- it has everything to do with how the specific manufacturer of that specific Z-Wave module decided it should behave on power-up. Either look for a setting (aka "parameter") for your Z-Wave device to change that, or find another manufacturer of similar Z-Wave devices that behaves the way you wish.

Please be fair about your quoting and comments. The solution you cite involves "the use of a computer" as I stated in my actual post.

There is no workable solution that does not involve the use of a computer (of some sort) between the ISY's serial port and the USB PLM. USB is NOT a peer-to-peer connection, it is -- by design -- a "device-side" and "host-side" connection. USB-to-Serial converters are "Device-Side-USB-to-Serial" converters (and if someone can find one that claims to be a "Host-Side-USB-to-Serial" converter, the way it does so is by embedding a small host computer in the converter, such as a Raspberry-PI-Zero or similar!). My point is to help "un-confuse" any future readers of this thread who may think it's just a matter of the right "gender-changer" adapters and figuring out what the pinous might be -- it's not that simple. Carry on...

From Sunset to Sunrise on the same day -- that'll never happen, because the next sunrise will always be on the next day.

Yep - modern high-efficiency windows use a metallic coating to reflect UV and reduce radiant energy transmission. It has the side effect of reducing RF transmission as well! We're in the "shadow" of the largest cellular carrier's tower here -- and as we built our house it became somewhat entertaining to see a contractor answer his cell phone, struggle to hear the caller, and dash off to stand in front of the window assuming they'd get better reception... only to have the call drop entirely as they got in front of the glass! I've strategically placed my ISY in the walk-out basement so that the signal from the devices in the garage doesn't have to go through windows. I'm going to have to move my tag manager in the spring, when I put a couple of the tags out on the patio -- the patio doors are pretty effective at blocking it right now.

Just adding to Teken's comments on a logical positive things that COULD be done... I often dis on how the Insteon protocol is fundamentally compromised by modern switching power supplies -- a solid "go-forward" plan for power-line communications needs to make changes to accommodate that new reality. Doing so would require a re-vamp of the Insteon protocol, basically using the same techniques things like WiFi-powerline-extenders that manage to put the signal over the entire AC cycle instead of the zero-crossing point. But why stop there? A next-gen Insteon device that could do that would have a lot more processing power and a lot more bandwidth to communicate. I wonder what one might be able to do if you combined a network of "next-gen" sensors that can do what the folks at https://sense.com/ are doing. Consider what a next-gen ISY hub might be able to do with detailed information on the AC waveforms observed by each device. Might it signal impending LED bulb failure? How about being able to detect a sump pump motor that's suddenly free-running instead of pumping? Or a sump pump that's fighting a clogged eject pipe? Or just detect that the garage door is in-motion by monitoring the A/C waveforms on the garage circuit... and get rid of all the IOLinc baloney? There's so much that CAN be done.

wifi is a huge problem for always-connected devices. make sure your HA is on a wired connection.

Replace the power supply first. See the wiki for details -- it'll accept a range of voltages so you should be able to find something in the junk box.

Yes, if you choose to use Insteon IOLincs, you'll need a pair of them. There are other manufacturers that make multiple-IO Insteon devices (commonly used for sprinkler systems, if I recall correctly) -- perhaps someone who owns one of those might comment on their usability for this. As an alternate, if you have z-wave, you might be able to use a MIMO z-wave device. (Looking at the same Dakota device for my looong driveway, probably in the spring when the ground defrosts -- I'd be interested in your comments on how it's working out for you!)

The idea that the electrical "noise" or signal sucker is restricted or blocked by a circuit breaker is largely fiction. In other words, noise on one circuit will happily pass through one breaker into the panel, out the other breakers, and to Insteon devices on that other circuit. In general, it's distance (on the wire) that reduces noise, not breakers. My point is that the two breakers you cite are both even-numbered, which usually indicates they are connected to the same buss bar inside the panel -- so you cannot rule out that the noise is passing from one of those circuits to the other. It's also possible that the noise is originating on one of the other circuits, passing through the breakers, and affecting your Insteon devices. As an example, right now only one of my three Insteon switches for the lights in the back half of the pole shed actually work -- the two that don't are on the same buss bar in the panel as the outlets in the back of that pole shed, into which I've plugged four small lead-acid battery maintainers. Apparently those very small battery maintainers generate enough electrical racket to deafen the switches on the lighting circuit. The fix is simple, but expensive -- I'd have to purchase MORE filterlincs, and plug the battery maintainers into those. Since each filterlinc costs more than the battery maintainers themselves, that's silly - so I'll live with this until springtime. Insteon's power-line technology is just not compatible with common low-cost energy-efficient devices, but that part of the pole shed is out of reach of my z-wave, so for right now, I'm kinda stuck with it. Oh well.

Most certainly yes.

Light vs no-light. 4.55.00 == 300. Z-Wave 21100 doesn't mean either 300 or 500. Dbwarner is absolutely right -- this is a muddled mess of numbering that makes identification frustrating. Right now, all we can post are the helpful "cheat-sheets" and "if you see this over here, and your firmware version is that over there, then you have the 500 series board" sorts of heuristics -- and that's necessary 'cause it's all we have right now. But none of those heuristics really change the fact that what we all need is for UDI to update the dang firmware so that it says "Z-Wave module 300" or "Z-Wave Plus module 500" or in the future "Z-Wave Mega-Stupendous module 900" (or whatever the z-wave folks will call that z-wave version!). The ideal place for that would be in the "About" or "Help" menu choices. Alas, for now, all we have are these infuriatingly-geeky-and-techy heuristics.

That's the wrong url -- missing a folder between pkg.isy.io and update121.sh -- see the other thread for the final posts that contain the full correct URL. (i'd post it here, but i don't trust my memory, and this thread is confused enough!)

You can run the curl command at any computer that has curl installed, including WSL on Windows. Alternately, you can just open the URL part of the command in a browser on any computer. The response is a 302 -- a redirect. Not a shell script. UDI changed something, that URL is not useful any longer.

There's a huge thread on this. Known problem, been around for years. No good solution -- (Not-So-)Smarthome has removed the "all-on" feature from newer devices, but of course that doesn't solve it for large installations. There are some steps in that thread you can use with the ISY to minimize the probability, but in general, just try to remove the wireless-only Insteon devices from your network.

USB-to-Serial converters, at least those I've seen and used, go the wrong direction. If you have a link to one going the other way, I'm interested! I had a need when last my Serial PLM died to put my USB PLM in service, exactly as you suggest. I ended up writing some software on a Raspberry Pi to act as a middleman. The RPi's serial port connected to the ISY, and the USB PLM plugged into the RPI's USB ports. It worked fine for the period of time I needed it (until my replacement capacitors came in and I got the serial PLM repaired). Since then I've wondered if it was possible to swap out the USB daughterboard inside the USB PLM for the serial one from an old (failed) Serial PLM... need to try that at some point.

Replace and rewire the sensor -- if the one you're currently using is a normally-closed, replace it with a normally-open, and vice-versa. Or, use a simple add-on relay circuit to "invert" the sensor before it reaches the IOLinc. I've done this using both approaches on my two garage doors in the past, to work around this very problem. Solve the problem at the source, anything else is a hack (at least with the way the IOLinc works).

Nope. As long as both boxes are fed from the same transformer, it should all "just work" (well, at least as well as it would work if you had a single panel...)

Just another vote for the Philips Warm Glo -- they're not perfect, but they're the best I've found with Insteon. More expensive than the cheap chinese junk on Amazon, but they work, they dim properly, and they mimic the color shift of an incandescent as they dim. Give them a try.

I fixed my daughter's hub -- didn't even bother to test any of the electrolytic caps, just replaced 'em all with whatever I had in the parts bin. It fired right up, and is still working (two years later).