mwester

Ok - thanks for the clarification! A sensor on the outside of the flue won't have to deal with the flue gas. I had a hot water tank that looked a lot like yours, but the flue made a 90-degree bend a foot over the tank to head to the chimney -- someone decided it would be nice to hang some of the kid's artwork from it. We all learned that the flue itself is extremely hot... so the caution on excessive heat remains. A mitigation might be to get a galvanized metal "L" bracket from the hardware store, and mount the sensor a few inches away from the flue -- the bracket will conduct heat, but hopefully less of it will get to the sensor. You'll have more lag in reporting the failure, but it might prevent the internals of the sensor from melting. Regarding the pilot light failure -- I'm suspecting back-draft based on what you've mentioned... that was a nightmare for me in early fall every year, to the point where I had to crack one of the basement windows open a bit just to change the airflow enough to keep the pilot lit and the unit drafting up the flue correctly. We finally replaced the unit with one that had a blower to assist the venting (high-efficiency too).

(Caveat: I've spent my career closely associated with the "support" side of engineering, so it may be that I'm trained to be overly-concerned about safety and failure modes.) I would NEVER EVER place ANYTHING in the flue of a gas-fired burner. Never. First, there's the safety part of this -- how can you be SURE that EVERY part (down to the epoxy used in the assembly) that you put into that flue is REALLY fire-proof? Then, there's the reliability part of this -- the flue gases are primarily super-hot steam (think rust), but there's also a fair amount of corrosive (acidic) compounds in there as well. The point being that anything placed in the flue needs to be designed specifically to handle that harsh environment -- and what I mean by that is not just reliability, but consider the failure modes as well (the mounting brackets fail, and part of the sensor falls down the flue -- where does it land, and if it lands in the burner, how might it alter/affect the burner, and could that cause fire, or other reliability issues?) The root problem here is the answer the question "Is the pilot light lit?" -- and that question must be answered by most appliances that have pilot lights, lest they leak fuel (natural gas, propane, heating oil) into the burner with no ignition possible. The former two of those are usually handled by thermocouples in the pilot light -- that would be one avenue to pursue. The latter is more interesting -- many oil-burning furnaces use an optical sensor that switches 24VAC (or even 120V) in order to ensure that the blower/pump that pumps the diesel fuel (heating oil is just un-taxed diesel!) doesn't operate unless the pilot is lit. Here's some info on those units (I used to have one of these -- it was a horrifying machine, but astonishing in its reliability... none-the-less, I sleep better now without a gigantic jet-engine burner along with 275 gallons of diesel fuel in my basement!): https://inspectapedia.com/heat/Cad_Cell_Relay_Reset_Button.php I'd pursue the CAD cell and a matching relay/controller, connected to an Insteon IOLinc route -- safer.

Very nicely done! This is an excellent example of how to do it right -- your wiring and layout is professional, and you've clearly thought through the failure modes (something not often done by most hobbyists).

I too see smoke and sadness in your future. Gas-discharge arresters are commonly used by HAM radio operators to protect in such a situation (it's not uncommon for an antenna tower to be hundreds of feet from the actual radio, and it's common for the cabling to include not only RF coaxial cables, but also control cables for antenna rotators, etc.) It's worth noting, though, that lightening protection used in these situations is intended to protect life and limb, and prevent fires -- it does NOT necessarily protect your PLMs! (More specifically, a common gas-discharge arrester trips at ~100V, and your PLM's serial chips will likely fry at 24 - 50V). I use a gas-discharge unit for ethernet on either end of my cat-5 run from the house to the workshop -- but I also use an old scrap 100MBit "sacrificial" ethernet switch at each end to protect the more expensive gigabit switches in each building. I can replace those 100Mbit units for $10 on eBay... Diode-clamping can be used in addition to the arrester -- but frankly, by the time you add all that in, your costs are pretty high. If this was just a detached garage located a few feet from the house, no problem -- but 600' is a long way, and at that distance ground != ground any more. So - minimum suggestion is to use a gigabit-rated ethernet lightening arrester on each end of that 600' run, and be prepared to replace the PLMs periodically.

Let me add to the excellent (and important) advice given by apostolakisl -- since your barn is on a separate panel, it also has it's own ground line, and therefore has it's own idea of what "ground" level, in electrical terms, means. What I'm trying to say is that you MUST ensure that the cable you run to that barn has NO possibility of contacting anything in that barn, especially if it can do so through a human being or an animal. The concept is called "stray voltage" on farms [https://en.wikipedia.org/wiki/Stray_voltage], and is the cause of huge economic losses [https://www.calt.iastate.edu/article/stray-voltage-and-dairy-farms-can-lead-large-damage-awards] -- in trivial situations it causes problems such as distress in animals (due to mild electrical shocks whenever they touch even the walls or structures in the barn, and in more significant situations, it causes death or injury to humans or animals. Best thing to do -- bring that "extension cord" (I hate that term -- it conjures up images of some foolish person running 600 feet of Home Depot orange extension cords across their lawn, or in a trench... gah!) -- anyway, bring that cord end up out of the trench 20 feet or so away from the barn in question inside a heavy, large PVC (not metal) conduit. That conduit length should terminate in a large PVC electrical box (available at any home store), and do the wiring to your RF-capable device inside that box. Make the assumption that the so-called "ground wire" will be just as "hot" as the black and white wires, and let NO metal conductors escape that PVC box! As for the fiber -- optical fiber doesn't conduct electricity, nor does it pick up voltage surges from lightening strikes, so feel free to run that between the buildings and terminate it inside each building without any special considerations. Fiber is a *wonderful* thing that way!

FWIW, I'm also still waiting for an email to tell me what they'll be doing for me -- as this lingers, I'm more and more inclined to stop reporting my weather station to Wunderground, and switch to something else -- there are other, more open, platforms out there (although they currently lack the density and coverage with regard to personal weather stations).

Not sure what part is confusing you, but I'm guessing it's the two hot (line) wires? If so, that's just a common way to continue the hot wire on to other outlets or switches in the room (or nearby rooms). If it's actually got two separate wires under one screw, then I'd suspect that outlet wasn't put in by a real electrician... So, you get the chance to not only put in an Insteon switch, but to correct a sloppy bit of wiring as well! (Note that it's just fine if it's one wire that enters the box, goes under that screw, and continues on out of the box -- that's a lot of extra work for an electrician (it's a PITA to strip wire in the middle of a length and get it under the screw), but meets code AFAIK). The ground wire and the load wire are obvious, I expect -- the white (neutral) on the Insteon switchlinc connects to the bundle of white wires in the box, and the two line wires need to be connected together along with the black line wire from the Insteon switchlinc.

Er, not sure if your municipality has different rules, but in Chicago (the last place I had a water meter), the municipality owned the plumbing up to the meter itself, and it wasn't legal for me to tamper with that in any way (including adding an additional valve). Of course, on the other side of the meter, I could do whatever I wanted...

And keep in mind that with door locks you often need a repeater VERY close to the door itself. Consider that the location and environment for z-wave door locks is very harsh -- first, the door lock itself, in order to be secure, needs to be made of fairly thick metal -- that'll block a lot of the RF signal. Then, the door itself is often metal, or has a thick metal skin on one side. Usually around the door one will find masonry, under the door is often concrete, and the lintel is often a metal angle iron to hold the weight. The optimum location for a repeater will vary, but it's best to have one that is in front of the door, rather than plugged into an outlet on the wall adjacent to the door (the RF signal will have less trouble going through or down a hallway than going through a dense wall to get to the lock). Finally, the z-wave board in the ISY does not communicate well. I know that some disagree (including the UDI folks), but many of us have observed that a secure repeater has better coverage than does the ISY in the same exact physical spot. I made sure to have a secure always-on device in the same room as the ISY to serve as a repeater (I used the external antenna before, but the new ISY z-wave dongle doesn't support that, so I now need another repeater - bummer... but still cheaper than all the useless Insteon filterLincs I need to keep my insteon devices working!)

If everything else is working, it's doubtful that the PLM has failed (yet). The date code says it was manufactured in the 28th week of 2017 -- so it's got a bit more to go in it's anticipated 24 month lifespan. One might theorize that the PLM's RF circuitry failed, but even so if one of your other working devices is dual-band, then the Insteon protocol should have that working device relay to/from the wireless-only motion-sensors -- so, while it's possible that the PLM is the issue, replacing it is not the first place I'd look to solve the issue. Try restoring the PLM to put the link table back -- see if that makes a difference. It's possible that an electrical surge or such corrupted the in-memory link table in the PLM; reloading that from the master copy that the ISY has will resolve that. Another possibility: given that the motion sensors are RF devices, operating in the same frequency band as cordless phones, baby monitors, wireless intercoms, etc, I'd take a look about to see if there's anything nearby (where nearby might be a neighbor's place -- awkward, but RF doesn't respect fences or property lines!). Of course, that said, a spare PLM isn't a bad thing to have on-hand. I've got three of them, plus a USB version -- they're troublesome buggers and SmartHome doesn't seem to be doing the right things to fix the problems with them.

Dunno... So are the other non-motion-sensor devices working well? What's the date code (4-digit number) on your PLM?

So are the other non-motion-sensor devices working well? What's the date code (4-digit number) on your PLM?

Voltage is analogous to water pressure, while current is analogous to water flow. So just like your sprinkler requires the water pressure to be in a certain range, your electrical device requires voltage to be in a certain range. And with the right water pressure, your sprinkler is only going to sprinkle a certain number of gallons/hour (flow), regardless of how much flow your water main (or well pump) might actually be able to deliver. The same is true of your device: when fed with electrons at the right voltage, it will only consume a flow of current (100mA in your case), regardless of how much current your transformer/wall-wart is capable of delivering. Or, short answer: you can use a transformer/wall-wart with a higher current rating with no problems at all.

Because somebody has to say it... this thread seems to have passed the point of easy identification of a common wiring scenario, and is now in the area of experimentation and "try it and see"... Line voltage is dangerous -- not only can you injure yourself, but a wiring mistake may result in a fire hazard. Also know that many insurance companies will not cover damage done if the wiring is not performed by or alternately inspected by a licensed electrician. With that caveat, carry on.

Alas, my phone is not attached to my body in any convenient location -- it's usually in a pocket, and sometimes is over in the other room on the charger. And then, of course, there are all the other phones, over which I have no control to install applications, nor do I wish to grant them access to my home automation. Bottom line: a phone is just a remote control, and while there's some "novelty" factor in using a phone to turn something on or off, that wears off quickly. A wall switch -- old-fashioned paddle or toggle or something like this topic's smart-switch is often the best and most efficient way to offer control for something. There's a fork in the HA road -- in THAT direction are all those who feel strongly that remote control using phones and smart watches is HA, in the OTHER direction are those who have different ideas. It really is that polarized... and as you can probably tell, I believe strongly that a remote control, even if it's a cell phone, is not really what HA is all about. JMO, that and $5 will get you a mocha-latta-frappe-wappa-wappa-wing-ding at your local over-priced coffee shop! ?

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.