mwester

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

Probably before you add the lock (they seem temperamental devices), it'd be best to install your other z-wave devices first, in order to establish the mesh you'll need for the lock to work reliably. When adding a device, it's best to attempt to "exclude" it first -- often that doesn't appear to do anything, but it helps to ensure the device isn't already added to some testing system they used at the factory, etc, etc. When you get two or three non-battery z-wave devices added (battery-powered devices don't act as repeaters, and therefore aren't really part of the mesh), then add the lock -- use the same process (attempt an exclude first, then an include), but make sure that the z-wave option to include *securely* is set (so that the lock and the ISY exchange security keys at time of inclusion, which is required for the lock to function with the ISY).

Oh yes, LED bulbs can indeed be noisy -- they have the same switching power supplies that other electronic devices have (and size of the device is NOT an indicator of the noise introduced, rather it's dependent on design, and usually correlates with quality...) I use the Philips Warm Glow LED bulbs, they are pretty well behaved. I've had mixed results with others. They also fail in odd ways -- my Insteon switch for the outdoor lights on either side of the garage door suddenly wouldn't turn off anymore -- went deaf, but only when it was turned on -- turned out that one of the 25-w LED bulbs had failed in such a way that while it still delivered all the light that it should, when it was on it generated enough noise to render the switch controlling it completely unusable. Switching to a better LED bulb fixed that.

Reasonably stable -- there's a handful of relatively minor bugs, and I suspect the real reason it's still not released is based on some features yet to be added, not based on lack of quality. Read the thread carefully, especially the part about your passwords being reset, and go for it.

Insteon as we knew it is dead. The new Smarthome, with new leadership, doesn't know who UDI is, what an ISY is, and they don't care either. The new MS (and any other Insteon device they might happen to release) won't ever have it's API released to UDI, because that's just not in the business plan for the new Smarthome. The above is not really my opinion -- I know that there are those who vehemently disagree (they'll be posting shortly on this thread) -- but I think putting the above on a post-it note on your computer monitor is wise, just so you can make absolutely certain that you really want to do this when you click "Buy Now" on that order for more Insteon MS devices... (My real opinion FWIW: the new Smarthome is still thoroughly confused by what they bought when they acquired Insteon, the PLM, and all the users that come along with it -- somebody thought they were just getting into the way cool, awesome IoT market, and discovered that there's more too it than little boxes and cloud servers, and that it's those little details like capacitors and noise and FCC approvals and UL certification and, etc, etc. that matter. So, not really a matter of kicking UDI and all of us to the curb as unwanted customers, but in the end, the effect is the same -- make sure, absolutely sure, you really want to invest further, especially with devices that aren't supported now, and may never be... (and I'd love to be proven wrong on that point, let's see if 2018 will bring an API document to UDI...)

Time lag, excessive Insteon traffic, and general uncertainty (is the door open, or closed, or should you wait a few more minutes and check again -- and if you can't rely on it, why automate it in the first place???)

No, the "10110" icon indicates that the ISY has queued up updates (such as a parameter change or a link-table update) for the device, but for some reason or other, it has not yet been able to do the update of the device. This is often associated with "link mode", but the ISY does not require a device to be in linking mode for the update -- it's just that when in link mode, a battery-powered device stays awake, making this update easier to perform.

And, if you think about this carefully, this seems almost tailor-made for malware... if you can somehow sneak a simple trojan into someone's home, it needs only the most rudimentary code to exercise this same uPnP code to ask your router to open up a port for some hacker to use, and then take the IP address so graciously offered by the router after it flings the doors wide-open, so-to-speak, and present that IP like the keys to the castle gates to said hacker for his/her enjoyment. For that reason, you should ALWAYS disable uPnP on your router!

If you are using the portal, there's nothing at all that needs to know your public IP address -- the ISY makes an *outbound* connection to UDI's portal servers, which obviates any need for anything to know your public IP.

There's another thread here where I've described my solution in detail -- the syncrolinc failed miserably because it's fused, and caused a failure. In a nutshell, what you want is to search eBay or Amazon for a "current-operated switch" -- these are squarish plastic-encased devices with a hollow center through which you run an insulated conductor (either the hot or the neutral, doesn't usually matter) for the line you wish to monitor. It has a couple of screw terminals on the top, which are connected to an internal solid-state switch that turns on or off (depending on model) when the current exceeds a preset threshold, usually adjustable via a screw and set of jumpers. Connect those screw terminals in the correct fashion to an IOLinc, and you have a far better solution for current sensing than the Syncrolinc ever was.

People seem to think in terms of "things" -- and as long as the conditions and actions associated with "things" are relatively simple, the "thing" approach offered by the ISY's programming language works just fine. If you have non-simple things -- lots of other conditions, or where the "then" or "else" clause has waits embedded in them, etc, then you quickly find that ISY's programming language just makes your head explode. In those cases, programming in terms of "events" is almost always easier, and almost always results in fewer "surprises" (aka bugs). At least in my experience -- I suspect this varies based on how one learned logic and coding, and may even vary depending on how individual brains are wired...