mwester

No, you're not sorry. You're just being argumentative. Let people work the issues and share their opinions and experiences - there's really no need to quibble and argue each and every single point, like you're a lawyer on some legal case! This is a forum, not a courtroom.

Central Wisconsin, in the 608 area code, for one. That change was made a couple years ago. So much dismissal of other's experiences on this forum lately... it's depressing.

It's worse than cloud-dependent. Being cloud-dependent just means that *my* device is unable to use or access services over the internet for some period of time, but it continues to function for other services. So we've just learned that UDI has the ability -- and will exercise that ability without notice! -- to cause the ESIY to cease providing *any* services (however briefly it may have been this time). This crosses the line from being dependent upon cloud services to being a service in and of itself. So think of the EISY as being a chunk of hardware that *enables* you to use UDI's services. This isn't a surprise; the OS vendors have moved to this "OS-as-a-service" model years ago. But to be honest, this is the very last thing I expected from UDI; it's the very antithesis of what the ISY was. Ah well, progress for all the young'uns... I'll stick with my ISY. Have a great day folks, got to get the horses hitched up to the wagon, need to get to town for some shopping. You crazy kids with your new-fangled inventions...

My daily job involves people who work in SCIFs (https://en.wikipedia.org/wiki/Sensitive_compartmented_information_facility). I acknowledge the reality that most people willingly trade their privacy for convenience and cost, but I also understand that there are those who either cannot or do not desire to do so. This thread is disappointing. The O.P. has strong opinions, but given that we do not yet understand the total impact of our diminishing privacy, it's far far too soon to be mocking those opinions. I hope that some day in the future we WILL be in a position to laugh about "unfounded fears". And I surely hope that those who are turning their homes into the private citizen version of a SCIF are wrong. But I dare not discount their concerns. Carry on, folks. Mock me as well, if you all wish -- I'll be dumping the portal and Alexa as soon as the HASS project gets their non-cloud voice project functional, so perhaps I too am becoming one of those "1990" luddites you're all poking fun at! I also hope that in 20 years, you'll all be proven right.

a) There is no VirtualBox binary for FreeBSD. b) There is no Docker support for FreeBSD.

The highlighted words imply that your controller requires something that has a simple relay, aka "dry contacts" rather than something that switches 120VAC line voltage. Assumptions can be expensive and deadly with line voltage -- you need to obtain the real specs for the controller, so we can see what, exactly, the referenced lines from the controller require. If they need 120VAC provided to them (very unlikely) then the micro on/off is an option. If they are dry-contact lines, with 24VAC (typical thermostat/doorbell types of signals), then the Insteon IOLinc is the only thing offered by Insteon. If they are dry-contact but provide 120VAC (line voltage), then you'll need full UL-rated dry-contact switching, and that might require z-wave or similar devices. So - specs required.

This thread is kinda humorous to me -- this is what happens when you post on a forum full of techie geeks! 🙂 Everyone is trying to help, but I think that what you wish is simply validation of your issue: the pulldown menu to manually add a device by device type is poorly sorted. Yes, I agree! (Regardless of whether anyone on this forum uses that menu item or even if they think it's a dreadful menu item to have, it's still poorly sorted!) 🙂 Filing a bug via a support ticket with UDI is probably not a bad idea.

I had a lengthy argument with UDI on this very topic when Policy was first being developed. In a nutshell, the stated problem is fear of the GPL license. One can argue the point (as I did), but the fact remains that even if nothing UDI does triggers the undesirable parts of GPL, there are still costs associated with legal advice to ensure same (costs that largely don't exist if one goes with the BSD license). The technical criticisms remain -- while it's true that FreeBSD has a stellar history as a network device, it's just different enough from Linux to make things difficult, and some things (the very things I wanted the Polisy to be able to do) actually impossible. I'm not the only one who's shifted their technical work away from the UDI ecosystem because of FreeBSD -- but the blame, ultimately, lies at the feet of Richard Stallman and the horrible GPL license, not with UDI.

Yep - completely counter-intuitive. I know none of *US* purchased the ISY due to it's UI -- but this is one of those unforced errors that reflects poorly. As trivial as it may be, it's one of those things that's kinda like buying a porsche except everyone knows the door handle falls off if you turn it to the left instead to the right.

Incorrect assumption, Larry. It's not about "commercial" -- indeed, most commercial and even industrial implementations will use DHCP. There are select cases where DHCP is not suitable -- one can generalize these as devices that should function even when the DHCP server is not functional or has been misconfigured or has failed. Courses on DHCP are entirely irrelevant -- this has nothing to do with knowing HOW to use DHCP, it's about using select equipment when DHCP is unavailable or has been misconfigured. Siimilarly with power steering and rustproofing iron -- while interesting, neither of these has anything at all to do with home automation nor with DHCP, and not even with networking. I'm not posting this to argue with you, Larry -- you've clearly made up your mind. Rather, I'm responding to underscore this need to Michel and the crew at UD. Manual network configuration is a requirement for critical services, even if one "hides" that option so that it is not exposed to the typical user.

There are sound reasons why one might choose to NOT rely on a DHCP server to reserve IP addresses. Especially so for critical infrastructure that needs to survive network disruptions of all sorts... and I'd put one's primary Home Automation server in that category. Indeed it is true that for MOST users, IP addressing is so confusing that they're far better off relying on a router. But in fact, for those who indeed "have all that experience", is quite "simple ... to understand how to make use of a DHCP server", and it is also quite reasonable for someone with "all that experience" to not wish to rely on that service. The same is true of DNS and time server addresses, as well as the gateway address (and network netmask). All of this needs to be made available (albeit hidden behind a "pro-only" feature, that makes some sense).

No. There is no ethernet involved in connecting the 2413S. Ethernet and RS232 (aka "serial") can be thought of as the electrical waveforms on the wires. Even though the connector (RJ45) and the cable look identical to the cable used by ethernet, the electrical signals on the wires are very different between an ethernet port and an RS-232 serial port. The 2413S cannot speak ethernet, and no ethernet converters will do the job. The 2413S speaks RS-232 serial. What looks like an ethernet port is actually an RJ45 connector on which the RS232 serial electrical signals appear. So, since the EISY provides only USB ports, you will require a USB to serial converter in order to be electrically compatible. Most of these converters provide the more common DB-9 or DB-25 connectors, so the final part of the solution is a cable that terminates on one end in a matching DB-9 or DB-25 connector, and at the other in an RJ45 male connector. The earlier posts in this thread note that UD sells a kit for this. You can also do it yourself if you are handy and not afraid of creating custom cables. The correct pins to match up between the DB-9 and the RJ45 have been noted by others in other threads on the forum; a little searching will find those should you choose that course.

This is a good short-term fix. However, you need to find the root cause and fix that. By analogy: You are in charge of a large interstate highway bridge. At 3AM every morning, portions of the bridge have been falling out of the superstructure into the Mississippi river beneath -- coincidentally, at 3AM every morning, a convoy of heavy trucks from a local manufacturing company crosses that bridge. Of course you'll immediately stop that convoy from crossing the unsafe bridge and causing more damage. But obviously, just because nuts, bolts, braces, and beams have stopped falling off the bridge when you stopped that 3AM convoy doesn't mean that the bridge is safe -- it's just a matter of time until some group of traffic on that bridge (or your Insteon network) arrives that has a similar load and/or vibration, and once again more of your bridge splashes into the river. That 3AM query is tough, and represents the most sustained high-load activity your Insteon network is likely to experience, but all that traffic is completely within spec -- and whatever specific signal or sequence is causing your trouble can also appear in other traffic throughout the day. It's just a matter of time until it does, and things go wonky again. So, keep hunting.

I used a USB-to-Serial converter with TTL-level serial pinouts -- the one sold by Adafruit, if I recall correctly. I do not have the photos and documentation on my system any longer (I no longer have a Polisy, so I probably left those behind when I upgraded my laptop last fall). The serial port is a set of 4 or 5 pins near the edge of the board, on a white connector as I recall. You'll need only three of them (txd, rxd, and gnd). The documentation for the motherboard is available online from the board manufacturer, which is where I got it.

There's an internal serial console port. I wrote a "How To" post describing how to find the connector and gain access to this, but it's not showing up in the searches, so it's either been removed or locked down.

The voltage on the powerline reverses direction, aka "alternates" -- hence "AC" or Alternating Current. If one plots the voltage over time, it forms a sine wave, with peaks at about 170 volts positive and 170 volts negative (the "average" -- actually RMS -- value is about 120 volts). The Insteon power-line signal is injected onto the power line during the period where the signal crosses the zero volts mark -- it's at this point in time that it's: a) easiest to synchronize all receiving devices so that they're listening at the correct point in time, and b) the relatively weak Insteon signal (a few volts) is more easily discerned. The Insteon power-line system doesn't know anything about "clear", whatever that might mean -- the only thing it knows is the zero-crossing point occurring at about the right time according to its internal timers. This has worked well up until the last decade or so, since the "purity" of that zero-crossing (meaning that it is both unambiguously detectable and at the correct time) was preserved by most transformer-equipped power supplies, and of course incandescent light bulbs had no effect on the waveform either. What's changed in the past decade is that switching power-supplies have become ubiquitious. And these devices have characteristics that distort the sine wave, making the zero-crossing point difficult to detect and even appearing to "jitter" around, showing up at the wrong times. Insteon devices on the power line get quite confused by this. None of the above has anything to do with RF. Unfortunately, though, it seems the *implementation* of the dual-band devices connected the RF and the power-line, at least in terms of timing. For some reason, when the devices get the timing on the electrical line messed up due to inability to find the exact zero-crossing point, they also seem to lose the ability to correct decode incoming RF signals. Perhaps they also mess up sending the RF -- I'm not sure anyone has studied that too much. Note that the dual-band devices were designed before switching supplies became part of pretty much everything in the home, including each and every LED light bulb, so one can't really blame the designers. It was less than ideal, and I'm sure they knew their implementation was flawed, but it probably saved a few dollars and worked well enough. The point is that the RF/Powerline interconnect thing is almost certainly solveable, if someone was willing to do so. Net of all this: the modern electrical system in a typical house is no longer suitable for Insteon's power-line signal and that same electrical system effectively renders Insteon's RF implementation unreliable as well. This can be fixed. Let's see if anyone in the new Insteon management will do so.

Would be nice to add this to Policy or to the ISY. HomeAssistant can do this, so clearly there is support for this on at least some if not all of the z-wave dongles.

The message is irrelevant -- it's simply telling you that the ISY was unable to read a response. The ISY doesn nothing at all with the response, and as long as the message was sent correctly, the device is unaware that the ISY didn't get a response, or didn't process it. Network resources are one-way, and it's not exactly clear why the ISY even bothers trying to read a response in the first place. So, check to see if the device is behaving as you expect - and if it is, then ignore the message. If it isn't, then you'll need to do some debugging to figure out what the device is getting that's different -- I'd suggest Wireshark on a linux laptop connected to the network switch (not wifi), boot off a LIve USB stick if you prefer not to install Linux.

Just take the paddle off of a dimmer, and what you're left with looks pretty much like the inlinelinc dimmer - and act pretty much the same too! I have a box of these where the buttons on the paddle have failed, so they only function as inlinelincs now.

This is way better than attempting to jam them both into the back of the Polisy -- BUT: Both Z-Wave and Insteon RF are in the 900 MHz band, so they are very susceptible to interference from each other. Even if they are on different "channels" or frequencies, the two radio receivers are subject to "de-sense" or overload from the adjacent USB device's transmitter. You'd be far better off with a 2-meter (6 foot) USB2 extension cable for at least one of them. Ideally for each of them, and keep the two radios several meters (10+ feet) apart. This applies to the ISY as well as the Polisy -- my ISY with the embedded z-wave is 10+ feet away from the PLM. It's in the joists in the basement ceiling, so I also made sure that there's a metal heating duct in the line-of-sight between the PLM and the ISY.

As do I. I checked listings for variants of "insteon hub" including the model numbers; they are all going for much higher prices than you'd expect if users understood they are mostly useless now. Since there was no announcement, and the status page still claims (wrongly) that all services are up, I wonder if there are a lot of people assuming their hubs have failed and are flocking to eBay to buy a replacement. They are going to be very very unhappy...

Rumor has it that this has been done. I've a family member with a hub, and if I can find the details on how to do this, I may attempt it. It'll take some time, though.

Yep. XML is much better.

The relay welds shut because the current is NOT a constant value with a switching power supply, which is what's inside LED light bulbs. When the power is turned on to the bulbs after they're "cold", there is an instantaneous inrush of current because the capacitors in those power supplies have no charge whatsoever. Thus, the LED bulbs look like a dead short circuit for a fraction of a second -- during which time you may have (depending on the wiring and length of the cable run from the breaker box) potentially 100 amps or more flowing. That's enough to "arc-weld" the contacts together. Note that not all switching supplied do this -- some have their circuits designed to soften this inrush current. But many that are designed for low-cost and/or light-weight sacrifice such a circuit. Try this with your laptop power-supply: unplug it from the wall while it's powering your laptop, wait a few minutes, then plug it in slowly. Watch for a flash/spark as you plug it in -- that's not the constant current, that's that "inrush" current. If you have a very high-quality power supply, you may not see this, but most of the lower-cost (and almost all of the no-name replacement ones) do this.

If I had to do over again, I'd go with this: https://www.functionaldevices.com/products/building-automation/details/RIB01P30 At the time I implemented this, I used a Functional Devices relay, but could only find a 24VAC coil version with the right contact rating, so the NEMA box includes a 24VAC transformer along with the relay. The above link is a single box that should be able to do it with no outboard components. You'll just need to find the right place to wire it in.