mwester

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.

Yep, it's a dreadfully awful idea -- but it's better than nothing, and I expect there were other reasons why the engineers were unable to implement a better solution at the time (keep in mind that they didn't have access to the wealth of low-cost RF solutions and low-cost small-form-factor computing chips we have today). As for the remotelinc -- the devices are indeed capable of receiving messages that are not synced to the power-line. It seems that the issue is related to re-transmission of same. The Insteon protocol is designed such that multiple devices can transmit the same message at the same time (avoiding the need for concepts such as "healing" the network in z-wave, etc). Doing this requires that all devices that might transmit at the same time be synced to an external timing reference -- the chosen reference for Insteon is the zero-crossing point of the AC cycle. The problem is that devices using switching power supplies (as well as some dimmer circuits) do not pull power from the AC line linearly, which (skipping a lot of gory detail) results in the waveform being distorted such that the zero-crossing becomes quite indistinct, and in fact can appear at slightly different points in time at different points in your wiring. I suspect that there are other restrictions with regard to the RF to power-line mechanism that result in the infamous "all-on" problem. I've never seen a documented case of an "all-on" being triggered by a remotelinc, but I suspect that's because we probably don't trigger them as often as other Insteon wireless sensors like motion sensors (plus we probably replace the batteries more often in the hand-held devices than in the often-forgotten door and motion sensors). It seems a missed opportunity for Insteon -- a "gen2" of the hardware and firmware, with (limited) compatibility for existing devices but making use of vastly improved RF, compute, memory to fix a lot of these issues. But the technical possibilities require business vision, and that's clearly been lacking at not-so-Smarthome.

No. The Polisy runs a subset of the FreeBSD operating system, and cannot support any of the currently-available means for making Home Assistant work on it. There may be a possibility that someone could fork and modify Home Assistant so that it would work with the Python that's available on the Polisy, but given my experience with FreeBSD, that's going to be a lot of work, and for a very small market.

Communicating "via the common wires" is a marketing simplification. All comms requires a difference of some sort, so the question becomes what the signal on the neutral is relative to: the hot, or the ground? If it's the ground, well, that's kinda silly, since the ground is effectively "shorted" to the neutral at the breaker panel (in US and CA residential wiring). Not impossible, I suppose, but suspicious - don't know about the comms they use. But, we DO know about Insteon -- we like to say it puts the signal on the "hot", but because of the need for a difference, one can equally well say that the signal is on the neutral, but inverted -- since (for example) a +5 volt signal at zero-crossing on the hot, relative to neutral, is indistinguishable from a -5 volt signal on the neutral at that same point in time. The conclusion: Insteon most definitely DOES put a signal on the neutral -- it's the inverse of the signal it puts on the hot. Thus it is quite possible the two are interfering, and also quite possible that the things that interfere or negatively impact Insteon reliability may also impact the fan signal in a similar way. (I may edit this post if I get the urge to dig into what that fan company's protocol really is on-the-wire... but right now, I've got other things to do, so if someone would like to beat me to it, please do so by all means!)

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.

Mr. Bumbershoot is exactly right -- just set up the custom URL calling feature, and have your tag manager update a variable in the ISY. I got rid of the node server, and went back to that approach -- it's simpler all around, and in the end, while it might sound daunting, it's proven to be less work than installing, configuring, and managing a polyglot instance just for CAO tags.

You'll need one (or several dozen) FilterLincs. I started with a couple of them, which lessened my problems with Insteon enough to make me order a few more... fast-forward, and my house is littered with FilterLincs. They're everywhere, because everything anymore has a switching power-supply that puts noise on the electrical lines. Hope you can get away with just one or two of them...

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.

I'm using the Aeotec z-stick. I found the multi-color LED thing cheezy as heck, but since it's on the end of a 3 meter USB cable extension, it's up in the basement ceiling anyway! Range is excellent.

HA is the UI for all home automation now. The moment the wife saw the UI, she said "THIS is what I expected when you started this HA stuff!" -- so, that's where everything is going. The hiccups with z-wave support over the past two years has resulted in all my z-wave going to HA as well. I can't say if the current version (5.3) is on-par with HA, since I'm not upgrading to that version -- but the HA support has "just worked" for the past two years, and that's what's important, and why all my z-wave has slowly been migrating. I've mentioned before that my Insteon devices are slowly, room-by-room, being replaced with z-wave -- along with that, since the z-wave is on HA, all other non-insteon automation is also moving to HA. Automation with HA is different from the ISY. Learning the peculiarities of the ISY programs has a steep and challenging learning curve, but HA automations have their own challenges (one of which is that the built-in automation "language" is somewhat limited, and you have to switch to scripting externally if you want something really sophisticated). By the new year, I expect that the ISY will be almost entirely a management console for the Insteon devices, and everything else will be on HA -- and my winter project is a wall-mounted graphical UI for all home automation (15" touch-screen monitor), something that'll take HA to do. Finally, I'll note that while node servers are cool, the extension mechanism on HA is more flexible, and easier to implement. In particular, if you have a device that speaks MQTT, the MQTT support is amazingly good.

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

I've three of these in use, with the companion 3-way switch. They work wonderfully, although they show some odd nodes that you have to experiment a bit to figure out. Turns out that in my locations, my primary need was to turn on/off the light, which the switch does perfectly without any programming. The secondary need is to monitor the lights, and for one of them to turn it on for a while near dusk and dawn. Works great for that purpose. I pretty much ignore all the sensor nodes in the ISY. So, I've never really tried to use the motion sensing with the ISY. And given the numerous changes to z-wave handling in the ISY between 4.x, 5.x, and the latest release that's actually certified, I suspect using the motion sensing would be dependent in ISY firmware version. In other words -- buy one, and try it.

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.