MWareman

Well - physics says that wires will melt when the high current causes the conductor to heat - melting the insulator (possibly causing a short, spark and possible fire) and (ultimately) the conductor itself (causing a break). This takes time. The material in the wire cannot heat instantly. Fortunately, surges from most events like lightning are just too darn quick to allow such heating to generally occur. I suspect that the rated wire used in this example can in fact handle this - especially since it's the manufacturer that stated so.

Just more FUD and non-truth. This was NOT stated at all. Please cease from making such statement without any basis in truth. to remind you what I actually posted: This was a ridiculous small gauge of wire stated as an example of a connection less than the 10' which passed your stated directive (many time) of "less than 10 feet" without providing any guidance yourself on gauges acceptable. Witness: Another example where you imply that only length has any implication for impedance. Another lie: Yet another - this time a true statement - again omitting the need to ensure wire gauge is large enough: The first example where you claim that as long as it's less than 10 feet - the connection is fine: You then go on to suggest that gauge of wire has no effect on final impedance by claiming it's irrelevant to the discussion. It is not. you you rightly state - the NEC has a lot to say about minimum wire gauges for this purpose - yet you have repeatedly only posted the 10' distance figure with zero advise on wire gauge - something that's very dangerous to do to a non-professional electrician who may well just visit the local home depot and buy the cheapest wire found thinking is satisfies the need. To assert my point clearly. Length absolutely affects impedance (shorter wire = lower impedance for a given wire gauge). However - so does wire gauge (smaller AWG number = bigger wire = lower impedance for a given wire length). The two are related. 10' max for this purpose is sound advise for sure. but you need to also specify a minimum gauge as well.

And I feel that this is the issue here. You have sent this thread well away from what the OP asked about. Keeping threads on-topic is what will help OPs learn. Trying to 'bludgeon' others to learn beyond what they are asking about by taking a thread on a tangent is not the best way to approach this. If you feel you have something to share about primary lightning protection (and it's clear you do - though I wouldn't rely on links to posts Reddit that you authored yourself) - may I suggest you start your own thread about it. I'm sure there is a lot we can agree on with regards to primary lightning protection. This is a subject of value to this community - it deserves it's own thread.

LOL. I had a whole response typed out - reread it - and then decided to delete it. Sometimes, some things are best left unsaid.

Impedance is not defined (solely) by distance as a certain poster implies - nor has it been stated what impedance is acceptable for a correct ground able to withstand lightning level surges. A 22 gauge wire at 10’ will not do what’s being claimed - but a much large gauge will work fine out to much more than 10’. The idea of anything within 10’ is OK is a false (maybe not entirely false - but certainly misleading) statement. For protecting against surges - you also have to consider induced surges in wires running parallel to the path to earth. That’s not mentioned either. FUD is also being added. OP asked about surge protectors. Not direct-strike lightning protection. Completely different risks. The latter is much harder (and much more expensive) to protect against. Buying insurance is likely a cheaper option for the average homeowner. For a TV Station, phone company etc - protecting against the direct strike is paramount. Personally, I’ll do my own extensive research and not waste cycles on unsolicited partial information such as posted here...

I've never performed "File/restore devices" myself - and handled this device-by-device the one time I had to do it. This allowed me to handle the many battery devices more gracefully. As I said - you have to put each battery device into linking mode first. This requires a visit to each battery device and hitting it's button - then the restore must be initiated before linking mode times out. You cannot go around the place putting all devices into linking mode before the first devices timeout so a global restore is never going to work in this scenario.

Right-click each switch, sensor, light, device (etc) and select 'Restore'. If it's a battery device - it will have to be put into linking mode first.

It sounds like you may have started a second restore PLM before completing the first restore PLM operation. It’s important to follow the process completely and ensure all devices are updated! (No 101010 icons) after the restore was started. Yes, but that will write half of each link - and not likely fix the underlying issue. There are two records of each link. One in the PLM per device it’s linked to (letting the PLM know the address of each device it’s linked to) and one in every other device on your Insteon network (letting it know the address of the PLM). If you changed your PLM - you can write your PLM config many times and it won’t change that your devices still don’t know the new PLM address - so the links will stay broken until all devices have a record of the new PLM address. Your devices are probably still sending their updates to the old PLM address - causing all your programs to fail (no triggering events are being received). Restoring all devices other than the PLM should restore the other side of the link to those devices.

And to expand a little on what Larryllix said... If you were to add other triggering conditions to the If clause - then when that triggering condition occurs outside of the timebox, the Else will execute. Within the time-box, then either Then or Else will execute based on the logic of the other triggering condition you added to the If clause. Adding a Wait complicates things as well - the Wait will be terminated if any triggering condition in the If changes.

Have you written the new PLM to all your devices yet? They may still be trying to communicate to your old (dead) PLM. Try a ‘Restore Device’ On one affected device - and if that solves it you will need to go around each individual device and restore it.

By ‘running on the ISY’ (and by saying you are using the REST API) - can I assume that you have the ‘Host’ field set to the actual IP address of the ISY in the network resources (and not 127.0.0.1 or localhost). Using any kind of loopback interface has been known to cause deadlocks and crashes in ISY - and that could be the cause of your issues.

Another thing to bear in mind (this has caught many out). The Elk network interface can only accept a single client. If you have a connection open from your phone, ISY will not be able to connect. Make sure ALL other clients of the Elk are disconnected!

That’s probably a symptom of the device you are controlling not telling ISY that the device has changed state (as it was put to market before the patent that protected the idea expired). Before the patent expired, devices used various workarounds and not all of the workarounds work anymore. Best way is probably to modify your spoken to drive a program in ISY (instead of the device directly) and have the program turn the fan on or off. That way (since the ISY is controlling the fan) it will update the status.

Unfortunately, one of the limitations (of Ring) is that you cannot directly get an image from the camera. There is a functionality request formerly submitted to their team to add this functionality - but it's not there yet. I have a separate Foscam that looks out the sidelight of my front door. This resource I reference is a network resource that calls a .php script on my internal server. This .php script obtains a snapshot from the Foscam camera and sends it as an attachment to my Pushover account.

On Windows machines, you can add a secondary IP address to the network stack - so your computer can communicate on either IP network. Then, use the old IP to access the ISY with the Admin Console, then logon and Change the IP of ISY.

That almost always causes issues. If you have not disabled the 3am “Query All”, you will get the state reversing at this time. This is because trigger reverse causes notifications from the sensor triggering to be reversed, but the answer to a query will not be reversed. Of course, you can disable the 3am query. But then devices can get out of sync and will not get get synced up until the device is triggered.

The Ring devices that use the hub were purchased by Rng and use a different protocol. They modified things to have them work with the same app but likely work very differently to the Ring native spotlights and floodlights that don’t need the hub. How to they show up in the PGC log?

That’s awesome. Especially if a javascript function can be pushed down to th google home devices to process spoken commands locally and make relevant api calls directly to the ISY. That way, if the Internet connection goes down the Google Home integrations will still function - at least those driving ISY devices, scenes and programs.

@TomL - you would need to start by posting the log from the nodeserver so it can be seen how the devices differ (during setup). Further - when motion events are detected there will also be log activity. Those events would be needed as well. I cannot speak to @bmercier's time commitments though...

I don’t have any of the devices that use the bridge, but recently worked with Benoit to add lighting support to the Ring nodeserver for the native Ring devices that have lights (the Floodlight and Spotlight cams). If you have the devices, why don’t you give it a go?

Agreed on the IOLinc. That's a neat device where the device you are monitoring produces audio. Personally - I'd still prefer hardwired for safety of life systems (I have devices wired to my Elk generally as non-alarm zones - but setup to call my phone if violated). What I couldn't remember earlier was the zwave product I'm using with much greater success (compared to IOLinc devices) in some places in my home - the Fortrezz Mimo2 (https://www.amazon.com/FortrezZ-Z-WavePlus-MiMO2-Interface-Module/dp/B008D5066C/ref=sr_1_10).

There are some gas leak detectors out there with dry contact outputs (like this one: https://www.amazon.com/dp/B07Q3567DZ/ref=cm_sw_r_cp_tai_Sv7hDb0WVCYHX). You could hook the dry contact output up to an iolinc or zwave equivalent to connect to the ISY - or connect to a zone on an Elk panel.

I do not know about any devices outside of the devices I have. None are battery powered, not do I have any of the first gen stick-up cams. I suspect they would be fine. If not, the nodeserver log will contain the details necessary for the events to be captured.

After installing the nodeserver - you should get a blue notification in PolyGlot Cloud prompting you to authenticate to your ring account to provide access. It asks for 'Read' access - but this is all that's needed for the nodeserver to send commands. The really important thing to know is: When authenticating to your Ring account - you *MUST* use your primary Ring account username and password. Secondary accounts (or devices shared to you from another account) will show as nodes - but will NOT receive events. This is a limitation of the Ring API I am told. The nodeserver does NOT see or store your Ring password. The integration uses a technology called 'oAuth 2' to authenticate - which keeps your Ring password safe. After linking - your Ring nodes are pulled in: The 'Front Door' device is the doorbell. It has two nodes - a 'Motion' node and a 'Ding' node. Flood and Spot lights show two nodes and the newer stick up cams show one (they have no light). You can then create a program and use these two events to trigger it.. Here is one for the 'Ding' (bell-push): and one for motion events: For Ring light control (the flood and spot lights), I have a micro-module behind a conventional switch that is used to drive the outdoor lights at the rear of my house. I added controlling the Ring lights to this with the following two programs. The first tracks the state of the switch - turning the Ring lights on if switched on, and off when switched off. It also updates a variable used to track what state I want the Ring lights in.. The second program triggers on the variable being set to 1 - and repeats as long as the variable is 1: This is to override the ring behavior that turns the light off after a couple of minutes when I want the lights to stay on.. Michael.

Well - the latest I have is the issue I was having is solved - it appears to be working to the capability of the API... ISY can easily drive programs based on dings or motion events. Additionally, you can turn Ring Flood or Spot lights on or off (but not tell their current state). I'm in the process of migrating some of my programs over (I currently use some motion sensors outside in some areas that I'm going to replace with Ring motion detect events) and so far I'm getting programs triggering a second or two faster than triggering from motion sensor events. Pretty slick! The only downside - the Ring API does not provide details of which motion zone the motion was detected in. So - to automate from events you are going to need to reduce the detection zones to limit the number of events generated. Otherwise - you'll be triggering events whenever a car passes on the street... Might just be worth a try now!