mwester

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!)

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.

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).

Not that I can tell. But then, I've no sense of style in the first place, so I'd be unlikely to tell!

A couple minutes with an abrasive-based cleaner (I use what I found under the kitchen sink -- something called "Soft-Scrub") takes off the lettering very nicely.

No, neither the polyglot framework nor individual node servers are aware of everything the ISY does (i.e. the websocket thing) -- in fact, it's quite the opposite -- the ONLY thing that Polyglot-the-framework knows about are the events about the nodes (administrative activities) and the specific commands that are sent to the node servers by the ISY. These commands are explicit requests for data or explicit commands to the node server -- with no information outside of that node server's set of commands or values. (In fact, for this node server, since there's no means in the Node Server API, I suspect that the author has had to use the general ISY REST API to "go around" Polyglot-the-framework in order to access variables. The Node Server API is, by design, extremely limited -- it's designed so that a node server could work as a "device driver" for some other HA system, not just the ISY...)

Yes.

I'm not Brian H, but I can tell you what sort of delays I see from the ISY994i and various devices... generally the ISY is notified of an event almost immediately - one can see the delay, but it's far less than a second. The big problem is that it isn't always so. Sometimes, it's a full second until the ISY appears to notice the event. The worst case is when one has Insteon traffic underway -- it's slow, and I've seen multi-second delays when (for example) I'm syncing the link table on an older Insteon device. So, it might work if you had a one-second delay, or perhaps seconds. But it won't be completely reliable.

I'd second that -- don't do port forwarding, not for anything anymore. VPNs are becoming easier and easier to set up, and often are built-in to better-grade router/firewall devices.

As others have noted, rebooting the ISY is not a good idea -- it's rather akin to solving an occasional stall by having your local dealer remove and re-install your car's engine every night. And querying the devices more often -- that's just a hack, rather like "if the light switch doesn't click when you turn it on, jiggle it and turn it on and off until it does" -- it solves the symptom, but the light switch is bad, and until you fix it, it's just going to get worse. In the case of the ISY, if it's missing status updates, something is causing that -- and it's not going to get better with time. See the numerous threads here on dealing with "noise" and "signal suckers" -- you probably will need one or a dozen of the Insteon FilterLinc devices to clean up your power-line signal. Welcome to Insteon's special little version of hell!