Teken

@gregkinney Tight Loop: Generally speaking anything that makes the controller receive or do something in a short period of time will cause a tight loop. Say create a program to count something every second that would be a tight loop. Now, if all you had is a single program doing that the system would be OK. When you have more than one you run into serious issues. What most people see are programs, scenes, network resources, are slow to react or at all. Another is when you log into the AC (Admin Console) and you will notice the system is slow to load or even at all. You can create another situation which is similar to a tight loop but not and this is by sending / receiving REST. If you ever review the error logs you may see lots of Queue Full messages. Remember the ISY Series Controller is essentially a small clock which has to share time (resources) to accomplish all the different things we ask of it. It also operates on the FIFO (First In First Out) principle. So what ever tasks it has been assigned to do is performed in order . . . Anything it can't do it places it in a virtual queue (back of the bus) until it can complete the same later. As noted early on the controller (generally speaking) doesn't really have a problem sending / doing outbound tasks. What really impacts the controller are / is anything that comes inbound to the controller which ties up lots of I/O and resources of the system. One key thing about any inbound REST call is you must insure you stagger the requests by several seconds otherwise you will have conditions where the controller appears bricked and sometimes self reboots. Short Version: Allow enough time between program activation, REST calls, and schedule folders to be disabled so there are more quiet times in the 24 hour period than active. Also, if you have any programs that make the Insteon network beep, blink, flash, use them sparingly. ie. You're asleep so anything that has to do with Home Remote should be disabled. Schedule the same folder to activate during your waking hours.

Any specific reason not to mount and install one of these eight button dedicated remotes?!? https://www.smarthome.com/collections/insteon-keypads/products/insteon-2342-222-mini-remote-8-scene If you wanted a hard line than a 8 button KPL with custom keys would be ideal held in one of the stands.

No worries . . . Also keep in mind you can place a schedule time for an entire folder to become active (true / false). Placing a condition on a parent folder allows you to manage program(s) in a global manner while also offering you an opportunity to kill a *Tight Loop* race condition. You'll really be happy to have conditioned folders when the controller is really locked up!

I can only suggest things I've done from past experience having seen the same: - Tight Loop: You may see this phrase bounced around in this forum once in awhile. Generally speaking it means not having programs or network calls whether they be inbound / outbound that happen in rapid succession or in short intervals. You can have a tight loop simply by telling the controller to execute a program 1~5 second. The same can be had where you send in bound REST calls to the controller. - Schedule: Always try to spread out program execution in longer intervals - Wait: Incorporating a wait statement is good practice to allow the controller to catch its breath. - Repeat: Use repeats when and where appropriate but use caution to not abuse this statement as it can lead to *Tight Loops*. - Disable: You can have a program disable another program to insure the system is idle when it should. - Folder Color: Once you activate the folder status indicator if you see what some of use term *Flutter*. Where you see the folder alternate from solid / half solid this is a really good indicator that programs resource is causing unexpected traffic / processing. - Pending Writes: Always insure all hardware is fully operational and no pending writes are in queue. If you're on 5.XX firmware there is a known bug were the Motion Sensor II will constantly try to write to this battery operated device if it has some kind of scene adjust involved. The band aid is to disable the battery write if you have the Pro controller.

If you have a lot of inbound network traffic to the controller this is one possible reason. This sort of problem will also happen when there are lots of overlapping programs completing tasks like blinking lights, beep, flash LED. Programs that have very short counting say less than 5 seconds. If you have any sort of pending writes this too can cause the same. Rebooting the controller is a band aid to a much larger problem as all you’re doing is flushing out the memory / network cache queue. Until it becomes full again and the system grinds to a halt. [emoji52] Sent from my iPhone using Tapatalk

This is a valid concern but I understood the OP simply wanted the original program structure to save time writing from scratch. [emoji2369] I would think any required changes to calling resources / hardware is something that would be tailored prior to deploying. [emoji848] Sent from my iPhone using Tapatalk

I believe whatever is the last (5.XX.16) release is perfect. [emoji106] I was just busting your chops about the user name. [emoji869][emoji481] Sent from my iPhone using Tapatalk

One thing you could also try is set the switch to 10 / 100 vs 1000 - if supported. Some network appliances won't be visible if set to 1000 but in the case of the ISY Series Controller that is a slim chance. But, worth trying out . . .

When you plug the ISY Series Controller to the new router do you see a link light in the rear of the controller?!? If so, once the system has connected to the network do you see traffic whereby the LED's blink? Some basic trouble shooting I would follow is check the first two items I listed out. Go into the router and verify you don't see the MAC address for the controller which is printed on the bottom. Next, I would connect the controller to a computer system using a cross over cable. Assuming the controller is set to DHCP and you make the appropriate changes in the network connection tab. I would expect to see the NIC on both the computer and controller indicate status and traffic. If the controller shows up ping the controller and see if it replies.

As of this writing given the 5.XX firmware is so solid it makes little sense to leave one box on 4.XX. Going this route will save you time, hair, and stress - trust me! Lastly, my user name is Teken not Taken. ? As I have not taken anything from you or the dog . . . ? I have on the other hand *Bestowed powerful knowledge upon you* = Teken . . . ? Tekken <- Is the video game character and some would infer I look very similar in likeness and animated charisma! ?

If both controllers are on the 4.XX firmware the transfer should be fine. If one of the other box's is on the 5.XX firmware that could pose an issue. I would reboot the controller that received the new folder in case it needs to be updated so it can be viewed.

Yes, ideally both systems would be using the same firmware release. Using two computers and placing the exported file on a removable media or shared folder would be the route I would take. Clipboard: Please keep in mind all this does is copy the information into RAM. You need to paste the information to notepad for viewing.

You have four options to accomplish this goal and comes down to preference: 1. Manual: Manually replicate the program while viewing and editing on two computer systems. 2. Export: Right mouse click and select export 3. Clipboard: Right mouse click and export to clipboard 4. Clipboard: Right mouse click and copy to clipboard

If the bulk of your Insteon network is still power line only hardware. It’s imperative to have proper coupling / bridging in all areas, zones, floors. As you noted if there are noise makers / signal suckers placing them on a Insteon filter Linc is key. Placing the dual band plugin module somewhere near the pool switch was intended to confirm if the AC was now operating better in terms of comms. Ideally, that plugin module should be on the opposite electrical leg to help couple the single split phase system. Sent from my iPhone using Tapatalk

Looks much better now so is the new switch out by the pool now? If so can you place that (plugin) dual band module somewhere outside to see if everything operates as expected? [emoji848] Sent from my iPhone using Tapatalk

A couple things in the log so any insight would be great. You have a device that is pending a write and failing. Have you identified what that is and tried to resolve it?!? Pending writes will cause you nothing but grief. On the left hand side of the device tree will indicate which hardware is pending with a green 1011 icon. Once complete if you have a dual band plugin module place it near that offending switch and let us know if it improves. Sent from my iPhone using Tapatalk

I am still using this fantastic solution this very day from our dear friend Stu! [emoji869][emoji8][emoji110] Sent from my iPhone using Tapatalk

Tools -> Diagnostics -> Event Viewer -> Level 3: Device Communications Events. Clear the log before starting and initiate the switch via AC / Manual. You can save the results and load them to the forum for others to review.

Open the AC and set the error logging to level 3. Activate the offending switch via the AC and watch the level 3 logs for errors. If you see lots of 0 hops left there are issues in that path that need to be resolved. Noise makers / signal suckers . . . Always confirm you have proper coupling / bridging via the 4 tap beacon test as outlined in the full users manual for that specific Insteon hardware. Complete the 4 tap beacon test both ways to observe pass vs fail. All of the newer 2477D incorporate a dual colored LED of green vs red. If the device blinks red this normally indicates a comm failure, missing or broken links, or zero hops left. In the worst case scenario a red LED can also mean a failing switch . . . Keep in mind the 2477D is not formally rated to support any load other than incandescent - even though lots of us do so with varying degrees of success! Completing a scene test while you view the level 3 logs can also offer some insight as to how the system is operating or the lack there of. Anytime I have to come on site to resolve a comm issue I always ask what has been added recently. If the answer is nothing I have the client remove every plug in device and watch the results. If it resolves the issue we simply plug in one item until comms begin to degrade / crash. If we see no improvement turning off individual breakers until a positive result is seen is the next step. Going this route obviously impacts the coupling / bridging so be aware as things could get worse (that is expected) but more often than not you find that noise maker / signal sucker this way faster. If you have any LED fixtures as painful as it is removing them all and watching what happens is really the only way to know. Any LED fixture that makes any sort of noise from buzz, hum, hiss, regardless of (IF) they ever created problems should just be removed. If a fixture flickers, blinks, strobes, well that's a given for removal . . .

The Insteon 2868-222 can be configured for either siren or chime: https://www.smarthome.com/collections/insteon-security/products/insteon-siren-2868-222 Almost any flood light can be used so long as it doesn't use dual bright technology. Almost everyone today who tries to integrate with Insteon / 3rd party flood lights use the Micro 2443-222 or 2442-222 when space is limited. In the past many of us installed the 2475SDB (ILL) Insteon Inline Linc relay or dimmer version when the Micro module wasn't available and space wasn't a limiting factor.

Yes, dealing with plaster, no neutral, and shallow boxes will be a pain. Regardless, good for you and congrats on the new purchase!

Sounds good, what's in store for you now the old place is sold?!? McMansion with some new toys for a fresh start?

This gets more aggressive if they pass the breach line . . . Perimeter_Motion_Detected_5.wav

I would send in a Technical Support Request (TSR) to UDI so they can remove your personal details and update the same for the new client. Generally speaking very few companies transfer warranty / licenses to someone who isn't the original owner. But, UDI has been really great at doing so on a case by case basis . . . Lastly, assuming the new owner is even remotely interested in Home Automation and the system you have left behind. Provide them the links to this forum should they run into future issues.

Welps, once you can get inside the box you will know for certain its not present. I honestly can't say if the blue LED is present for all Z-Wave cards as UDI iterated a couple times. Regardless, if in doubt there are a couple of things you could do to make it a little more painless. - Send the unit back insuring you document the UUID and submit a technical support request to have the Z-Wave license revoked and refunded. - Keep the unit and create a technical support request with UDI and provide them the Amazon invoice, UUID, and they could ship out the missing dongle.