mwester

Voice commands only - not even sure that echo/Alexa can do more than that for HA. I've never even checked, because I strive to make as much of my HA *independent of the internet/cloud* as I possibly can!

Not to worry, Java will continue to be available on the desktop for a long, long, long time. It'll be rather like COBOL -- when the current kids who are coding in Java retire, they'll be called back to do side-jobs maintaining legacy Java applications. There are a lot of reasons for UDI to drop their Java application, but on-going support for Java isn't one of them.

Sooo.... Did you replace the PLM yet? It's showing all the standard, normal, expected failures for a PLM that's hit the expected two-year life span.

It's like a home builder not putting deadbolts on the exterior doors. I expect that you never deadbolt or perhaps don't even lock your doors at night -- but that doesn't mean that others feel quite so comfortable with the situation. And waiting to install deadbolts until after the first robbery in your nice safe neighborhood is a personal choice -- again, other's aren't quite so comfortable waiting for the first hacking event into the ISY portal before we do anything to secure it. There's an old adage about locking the barn door after the horse has escaped.

If they plug into a switched outlet, use an Insteon Filterlinc. If they are wired in, use an X-10 wired-in filter: https://www.x10.com/xpf-20a-wired-in-noise-filter.html

(Edited to clarify) Regarding UDI -- They appear to be reasonably up on the entire security thing, but I've not seen any documentation on what security practices are in place regarding the portal. (I'm not asking for the pen-test results, but I'd sure like to know if the portal code was run through any static-analysis tools, and if it was pen-tested, etc) I too would like two-factor auth for that, if it were available. Commentary on IoT security in general (not specific to UDI or the ISY Portal): Check the commentary on this forum. Some of us (including me) have raised concerns about IoT security in general, but the overwhelming response from forum members is "Why should I I worry, the worst anyone could do is blink my lights." I perceive that the members of this forum are in general far more technically "savvy" than the average population -- and if our demographic doesn't really care, that goes double for the public, and since companies will sell what the public demands, the logical end result is that the market will continue to be flooded with vulnerable devices. There have been many cases that illustrate why vulnerable IoT devices are a problem, including the recent massive Denial-Of-Service attack that was executed by a bot-net of compromised IP Cameras. But, the public continues to buy based on lowest price, ignoring security considerations (heck, they even ignore things like UL and CSA certifications!). The net result: if you are concerned about security (and we ALL should be!), then it's entirely up to you to make it so. Secure subnets, firewall rules, etc are your tools; don't count on the IoT vendors (and don't trust them either -- they may or may not code security, you'll never know since you can't see the source code, so the wisest thing to do is to prepare for the worst (and hope for the best)!). (The above is an opinion, and sadly, one that is not shared by many others.)

Z-wave, smokegrub, z-wave. Given the reliance on the device, I'd suggest you have a second ISY at that location as well. As a simple solution, make that second one do only z-wave, and add only the critical sensors/devices for it to handle. That way you do not "toss out" your investment in Insteon, but instead you can move into a more reliable technology slowly, as the Insteon devices fail. Plus you'll have two ISY units, so even if the ISY (or its power supply) fails, you have another that can make life a little less stressful until you can get up to the remote location to service it all.

Follow-up: I can confirm reduced range. I excluded and included a door sensor, and found I had to be in the same room with the ISY in order to do both operations. I originally included it with the old board from my workshop, across the basement. I spot-checked a few nodes that I knew previously had the ISY listed as a neighbor -- the workshop light switch no longer lists it as a direct neighbor, although the garage door unit still does. So, no big deal since I have enough z-wave devices to have a functional mesh -- but clearly the new board doesn't have the range of the original with external antenna.

Late to the party... Reviewing the previous reports, I took some time before installing the new board to thoroughly document the entire z-wave configuration and map out the network. (I was a bit surprised -- somehow, at some time, as I added more z-wave devices, the Aeotec Siren that I had strategically placed to repeat the secure z-wave signals ended up completely un-used; nothing secure is actually routing through it anymore! Time to find a new place for that device.) As part of that activity, I ended up with one of my battery-powered door sensors stuck in a state where it has writes/updates pending. Couldn't get those to clear no matter what I did (5.0.13 firmware). It's working fine, just endlessly has the green flag indicating that there are writes pending. Waking the device results in the log noting that there's work to do, then it doesn't do any work, and puts it back to sleep. I changed things so that the ISY no longer put devices back to sleep automatically, and told it that the door sensor in question is always awake, and then removed the cover (which puts the device in a "tamper" state and according to its documentation leaves it awake)... the log changed (no longer put the device to sleep) but still nothing to write. I messed with this for quite a while before just leaving it as-is, and putting the z-wave configuration back again. Perhaps I'll start another thread on this issue if anyone wants to dig into it more. The hardware upgrade was easy -- as I removed the old board and disconnected my external antenna, I realized that I hadn't told the ISY to switch to the internal antenna, and wondered how that would work since the new board doesn't have an external antenna connector at all. The lack of the LED on the new board made it a lot easier to install. Power-up was as-expected. My programs that poll a few z-wave devices started logging errors in the log (since the z-wave board didn't yet know about the devices); I took that as a good sign. No antenna selection menu appeared with the new board, so clearly there's no special steps required if one has an external antenna on the old board. The back restored quickly and correctly. I did a query all as soon as that finished, and all was well with the Insteon network, and mostly well with the z-wave network. The battery-powered nodes did not report (as expected), and one of my multi-sensors was likewise blank. Turns out that somehow (probably my error, and nothing to do with the upgrade) that powered sensor got marked as NOT being awake all the time. I fixed that setting, and it queried just fine. The problem with the pending writes to the door sensor remained -- although the door sensor worked just fine with both new and old z-wave board. I checked my secure devices -- since that seems to be what's giving folks difficulty here -- all working fine. So, I did a network heal, and checked again -- all working fine. Next steps: my two z-wave plus occupancy sensors in the basement are not securely enrolled; I'm going to exclude them and re-enroll them to see if that changes now that the ISY is also z-wave plus. I'm dreadfully curious about the bogus pending writes on that z-wave door sensor (nothing to do with the upgrade to the hardware), so I'll probably swap that with a spare, so I can work with the errant device on my workbench. Oh - and I'll have take apart the ISY again to remove the antenna -- I'll want to keep that for my spare/test ISY, since the old board doesn't seem to have the range I'd like without that. I know it varies from situation to situation, but it made a distinct difference for me! In summary - all well with the upgrade so far.

That is correct -- in fact, NO z-wave signals are repeated over the powerline by any devices that I know of, not just the Aeotec repeaters. So, with z-wave you are reliant entirely on the RF mesh.

Consider the layout of your home -- is the wall that forms that "virtual barrier" for the z-wave devices centrally-located? And, if you can check from the basement or crawlspace, do you see ductwork entering/leaving that wall all along its length (you can also infer the ductwork by locating the vents and cold-air returns on that wall or the floor and walls above it)? Another thing to consider is the material and even the furnishings along that wall -- a tiled wall will often interfere with the RF signal, as will a line of metal kitchen appliances (for example). The point is that it's not uncommon to have a wall or a section of a wall in any home that casts an "RF shadow" -- and you'll have to place Z-Wave repeaters in such a fashion as to get around (or over, or under) that barrier. Note that repeaters are a waste of money in general -- I avoided them by simply arranging to ensure that the Z-wave motion sensors (multi-sensors) in the sun porch and garage are powered (instead of batteries), which makes them also serve as repeaters. So -- if your multi-sensors are battery-powered, they're not helping your z-wave coverage, so don't count them. And note that the signal coverage of the ISY is pretty poor, relative to something like the Aeotec Siren (and probably the Aeotec repeater). So, it's probably best to not consider the ISY as part of the mesh either. That would meant that you're trying to cover a huge house, with two z-wave devices... As for how many and where you would need them -- it depends. Even with a detailed floor plan (with furnishings marked on it), there'd be no guarantee that you could get it right without some experimentation. But I'd suggest a minimum of one always-on z-wave device in every room, on each floor, to create a reliable and redundant mesh. Cutting that in half is probably very doable, but you'd have to experiment to find out where to place the devices (especially since it already sounds like you need to get around, or punch a signal through, something that has a considerable RF shadow.

Are you sure you're posting in the right place? This forum is all about the ISY controller for Insteon, not the Insteon hub...

Sorry, I guess you'll have to wait until the industry comes with zed-wave for y'all up there.

Alas, no such thing exists -- if you truly cannot install a JRE, you'll have to do without the Admin Console. I've yet to encounter an organization that didn't allow exceptions, although they may make it extraordinarily painful to obtain that exception... There's just too much enterprise/business software that needs JREs to run. Perhaps it's as simple as putting the JRE on a Raspberry Pi, and calling it an "ISY User Access Appliance". Or perhaps a Docker container or a virtual machine, locked down and isolated, that can do nothing but access the ISY.

Physical proximity is hit-or-miss; the real issue is electrical proximity combined with the nature of the issue (signal being sucked out, or signal being obliterated by noise). So don't get hung up on where things are plugged in so much, it may not help. Modern garage door operators are all high-tech computerized machines, and as such they have the same switching power supplies that plague the Insteon protocol. First thing to try is to get an Insteon FilterLinc, and plug the GDO into that -- see if that resolves much if not all of your issue. (I actually had to also put a FilterLinc on my DeWalt battery charger to get everything in the garage working right -- Insteon is seriously vulnerable to the noise that even tiny switching power-supplies put on the power-line.)

That rating is for *RESISTIVE* loads (e.g. a space heater or automobile block heater). Check the ratings carefully for *INDUCTIVE* loads, which would be the motor. (And for completeness, due to the unique characteristics of a tungsten filament light bulb, there's often a different rating for incandescent lighting loads.)

After some thought, I find I am in strong agreement with @gduprey -- logging of events should be a central concept for home automation. I can see that perhaps the ISY isn't up to the traffic commonly generated with rsyslog, so it makes sense that the ISY delegate the logging to another device (rather like it delegates custom device support to node servers such as polyglot and nodelink). And now that I mention polyglot, it makes sense that node servers should likewise log to the same rsyslog server -- and the Linux system hosting the polyglot server would be a fine place for such a service (rsyslogd) to reside... So, strong +1 for this idea -- rsyslog support for the ISY to log to a remote server. Should be fairly easy to do, since it already has the rest of the protocol stack -- perhaps as part of the network module?

"Run Program" is not like calling a subroutine or function -- it is not intended to be synchronous to anything at all. It's more like launching a Windows service or a Linux daemon. A "WAIT" statement in your program may or may not result in you getting the correct value; it depends on all sorts of things including how busy the ISY is at that moment. In general, the ISY is an event-driven programming model -- it's regrettable (IMO) that they borrowed some concepts from procedural programming models, and forced them into that event-driven model (it doesn't work well and often confuses more than it helps). In such an event-driven system, if you want to model your "call subroutine" approach, you'd have to do it as below. (Note that there are probably better, more efficient ways to do this -- I'm just illustrating how to do the "call", not trying to build a specific optimal solution!) Program A: If Time is 12:00: Run Program "Calc Temp" Program Calc Temp: If <nothing>: <perform computations> <save result in STATE variable RESULT Program A2: If RESULT changes: <continue with whatever you wanted to do after the temperature was calulated>

Perhaps... but if one thinks in terms of "zoning" one's house, I think it's quite do-able. To some degree I've already done that on mine, separating by z-wave vs insteon. The key is to think of zones as defined by traffic and usage patterns rather than by physical rooms. That way the boundaries between the two make logical sense, and there's less cross-zone traffic to worry about.

ANYTHING with a switching power supply (which is basically anything manufactured in the last couple of decades) can be a noise source. Some are less, some (often the cheapo junk devices) are more so. Size or power-draw is irrelevant in my experience, although quality of the device is an indicator -- I've observed that a $9 Chinese knock-off phone charger was capable of taking every Insteon device on the first floor effectively out-of-service. Insteon's protocol was designed back when transformer-based power-supplies were the norm, and it has not scaled well in today's world, particularly given the "race to the bottom" in terms of price for electronic gizmos. Filterlincs will help -- I have my house littered with filterlincs. They sprout on every wall, often connected to power strips so I can use one expensive filterlinc to cover several devices -- which results in the house also being littered with extension cords and power strips, despite have plenty of unoccupied wall outlets everywhere. For a few troublesome wired devices, I use the 20A X10 in-line filter. Despite all those efforts, I still have marginal comms. But at least no flickering of lights. My advice: switch to Z-Wave. Works well with the ISY, and unlike the Insteon protocol (and I fear, the company itself), Z-Wave has a future. It's not perfect, and not a panacea, but once you have a "critical mass" of always-on devices to form the mesh, it's reliable and just works, and far faster than Insteon, plus it has a lot more "cool" devices.

For generic hall-effect flow sensors, one applies +5 volts to the red wire, ground is connected to the black wire, and the yellow wire goes to the input pin for a microprocessor such as an arduino or an ESP8266 (or ESP32) -- the pin should be configured as a input with a pull-up. Each revolution of the spinning magnet inside the flow sensor will cause a momentary pulse (from logic 1 to logic 0 and back to logic 1) on the input pin. Counting those pulses and computing how many per second will yield the flow rate. One way to get this information to the ISY would be to connect an output pin from that same microprocessor to an IOLinc, and trigger the IOLinc when some threshold has been reached. Alternately, if the microprocessor has a network connection (ESP family, for example), you could program it to set a variable on the ISY to reflect the current state of the input logic pulses from the flow sensor. What you cannot do is connect the flow sensor directly to any Insteon device, or to the ISY. I'm not aware of any Z-Wave device that takes a hall-effect flow sensor input directly, but there might be one somewhere...

No google hits for that model...

What sort of flow sensor -- what signal does it send, at what voltage/current, etc?

Please read the topics suggested -- the argument about the range extender has been beaten into the dust in the past; it's a shame to waste good electrons re-hashing that all over again!

Yes, one adds z-wave devices from the ISY console. It will be very unlikely that your lock will communicate reliably without additional z-wave devices. You need a minimum number of devices to establish the mesh required for communications -- usually three or four, depending on the location of the ISY relative to the lock, and other factors. But never fewer than three always-on devices (and the lock is a battery-powered device, and thus is not "always-on" -- so it doesn't count).