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

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

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.

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.

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.

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

Yep. XML is much better.

The link database in the Synchrolinc is, for whatever reason, quite wrong. From the ISY's point of view, it should have nothing by the PLM's address, but it seems to have something rather different there. First thing to do is to reload the Synchrolinc's link DB (IIRC that's an option on the diag menu for the Synchrolinc in the UI). Next question is how it got that way -- might be a failing power supply in the Synchrolinc that is corrupting the link db, but could also be noise on the power line.

Login as "admin" No ip address, just the word admin.

https://devices.zwave-js.io/ And a page pointing to other sources of data: https://zwave-js.github.io/node-zwave-js/#/config-files/importing-from-others The task, then, becomes figuring out how an end user might be able to use a script or tool to update their UI periodically as this information is updated (I'm not convinced the world needs Yet Another Database for the same info, when an aggregation tool might do the job). And of course there's the licensing aspect, but as long as the end user runs the tool and the DB is not distributed with the product, there's probably no insurmountable issue no matter how the data source is licensed.

There are two additional USB2 ports on the Polisy internally -- perhaps an upgrade option for UDI would be to offer the cable harness and a modified case to expose them. However, as long as none of your USB devices require high-bandwidth, USB hubs worked fine when I tested them early on. Make sure you stick with USB-2 hubs, and unless your devices are ALL very low-power, make sure the hub is powered.

BSD is not the same as Linux. Both can be called "unix" in a sloppy sort of way, but one cannot usually expect that a program compiled for one can run on the other. One can have "source" compatability, meaning that when the code was written, care was taken to ensure that it would compile on both BSD and on LInux (and usually on other "unix-like" operating systems). In this case, you would look for a binary version of your software that would run on FreeBSD 13 on a 64-bit Intel platform. Binary compatability is possible, in limited cases. In this situation, you would need to obtain a copy of the binary code for your software suitable for 64-bit Intel, in a "non-installer" format (e.g. a tarball or zip archive -- it's unlikely that any normal Linux installer (e.g. rpm/apt) would run on BSD). You would need to install the linux-compatability packages (there may be a number of these) required to suppot your software -- there's no good way to know the full set of libraries, nor how to go from an error message to the correct BSD package to install. The good news is that it's possible to do this; I've done it. The bad news is that it's not something you want to do on the Polisy. NFS works, although like any shared network filesystem, that poses risks to the stability of the Polisy due to "funny stuff" that can happen on your network -- I'd suggest treating the Polisy like you'd treat any server in a datacenter, and not add any dependencies that you don't absolutely need. Stick with REST calls and SSH/SCP.

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.