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.