IndyMike

Glad you got things working. For reference - the "Identical/Ignore" entries shown above that have the ": 22" are devices that were deleted from a scene. When a device is deleted from a scene the ISY writes a "22' to the entry to get the device to ignore it. Much quicker than re-writing the entire link table. When you do a restore, the ISY "consolidates" the link table and removes the "22" entries.

You are of course correct Brian. I could have sworn that my V1.0 2413S was powerline only. I was wrong. I was thinking about my 2412S. Sorry to confuse...

Hello MarcusD, At this point I would NOT recommend switching to the Eisy/Polisy. It would further confuse things. You appear to have some basic communication issues with your system of the PLM. These will still exist with the Eisy/Polisy. Your previous post included the event viewer results from a "write updates" and "device restore" session. I didn't see any communication errors in either of those logs. You are apparently getting them now. Starting to wonder whether you have somehow lost your phase bridging. Questions: You mentioned that you had gotten a "new" 2413S. Is it really new or rebuilt? Can you post the version/firmware and date code? Trying to make sure that it's really a dual band PLM ( there were older 2413's that were not dual band). Is it possible that you had a power event that may have damaged some of your devices? This could affect your bridging and mesh. Mr. Bill determined that you don't have the ability to "turn off" device updates - that's unfortunate. What you CAN do, is disable devices so you are only working with one at a time. This will limit the confusing ISY update action in the event viewer. A few recommendations: I would suggest that you disable all devices with "pending writes" and "errors". Select one device to restore. Enable that device, and restore with the Event Viewer on level 3. Post the event viewer contents here. If you continue to have issues with communications, try updating Lamplincs/ApplianceLincs by plugging them in next to the PLM. Always use the device restore.

Hello Marcus, You posted two logs above. The first was from a "write changes to device attempt" [40 5E 46 1 ] Link 0 : 0FF8 [A2007016CEFF1F01] Writing [A2007016CEFF1F01] [INST-TX-I2 ] 02 62 40 5E 46 1F 2F 00 00 02 0F FF 08 A2 00 70 16 CE FF 1F 01 A4 [INST-ACK ] 02 62 40.5E.46 1F 2F 00 00 02 0F FF 08 A2 00 70 16 CE FF 1F 01 A4 06 (00) [INST-SRX ] 02 50 40.5E.46 70.16.CE A7 2F FF (FF) The device that you are trying to update (40.5E.46) is apparently an I2CS device. This device requires that it be linked BEFORE it will respond to communications. It is responding to write request with a NAK and indicating that your PLM is NOT linked to it. This device is still linked to your old PLM. The second log you provided is a "restore" session to the device. Here the PLM correctly identified and linked itself to the device. This session appears to have completed correctly. Does that device now operate properly? My guess is that you have a mix of I2 and I2CS devices. The I2 devices May operate correctly if you simply try to "write updates". The I2CS devices will not. You will need to Restore these devices so that the PLM link record is properly written to them. I am not sure how you got to this place. If you performed a "Restore Modem" the address of your new PLM should have been written to all of the devices. It is possible that errors occurred during the update, leaving devices with the "1011". For I2CS devices, you apparently need to perform a "device restore". Here are the developer notes discussing the I2CS protocol: https://cache.insteon.com/developer/i2CSdev-022012-en.pdf

Understood that both of your devices were working fine on the isy994. Also understood that one device is working on zmatter, but both Zooz and Aeotec devices are over-reporting on Matter. My experience base is the isy994 and Home Assistant. I have had both the Zooz and Aeotec sensors on these platforms and they worked well. I do not have the Zmatter board. My point above was that Zmatter board may not be addressing the sensors correctly (accessing incorrect memory locations). An exclude/factory reset should correct any incorrectly written data. Re-include and watch behavior WITHOUT modifying any values.

Hello Johnnyt, That wake up interval is wild. I have six of the ZSE44's running on HA and love them. They are programmed for a wakeup interval of 21600 seconds (6 hours). All of my devices report at 6 hour intervals like clockwork across multiple firmware rev's. I woke up one of the devices below manually to perform a firmware update. Home assistant allows you to modify the wakeup interval but it's not documented in the Zooz settings. Not sure if that is any help. It's possible the value got scrambled at some point. I'm assuming that Zooz Tech support had you try a factory reset. If not, here's the procedure: How to factory reset the ZSE44: Power on the sensor Click the Z-Wave button three times, holding the third click for 10 seconds. The LED indicator will blink steadily. Once the LED becomes solid, within 3 seconds, click the Z-Wave button twice more to finalize the reset. The LED indicator will flash 3 times to indicate that the reset was successful I have also not experienced "over-reporting" with any of the firmware versions. If you are seeing this on both Aeotec and Zooz then the ZMatter dongle seems like the common thread. Battery life on my devices has been very good. Indoor devices have lasted 8+ months. Outdoor devices have lasted 6 months (high reporting due to temperature swings). I calibrated all of the sensors when I installed them Oct of last year. All have held true over that time.

A query to a scene will interrogate all of the scene members with one exception. You cannot query secondary keypad buttons. DennisC answered your question on creating a device folder in the Admin tree. Unfortunately, I don't know of a way to query a sub-folder, al least not with the ISY994. You can absolutely use a program to query a scene and it will iterate through each member

I would view a second scene off command as far less abusive (far less traffic) than the individual off commands - probably won't hurt anything. I you are curious, you could turn the scene off, wait, query the scene, then run a program to check for lights still on... Scene xx off wait 30 seconds query scene xx {test to see if any switch is still on} If Device xx is not off or device yy is not off or device zz is not off then Scene xx off inc retry_count

As Lilyoyo1 indicated, programming beauty is in the eyes of the beholder. On the other hand, if you believe that collisions are causing your issues, using a scene is the way to go since it uses only one transmission from the PLM. Your approach using waits can be made to work. The waits give the PLM time to execute group/device cleanup commands and perform retries (if necessary). Unfortunately, it's dynamic and could require different wait times under different signaling conditions. You may want to start with a long wait (10 seconds) to be sure that the PLM has completed it's cleanup. There are very few tools available for Insteon. One of the tools that UDI did give us it the "Scene Test" (under "Tools/Diagnostics/Scene Test"). This would allow you to test the scene repeatedly, and at different times of the day, to see if you have a failing device or changing environment. Below are the results of a scene test that I ran on my BSMT Scene. I have one device that fails this test somewhat consistently (not 100%). The device will periodically fail the 3:00 AM query, but generally passes a query from the ADMIN Console. The device has no load (controller only) and is in the same box as other responders. It's an old 2476D that is likely starting to loose it's power supply. Thu 03/09/2023 09:24:41 AM : [GRP-RX ] 02 61 27 13 00 06 Thu 03/09/2023 09:24:42 AM : [INST-SRX ] 02 50 20.73.18 53.BC.3A 65 13 27 LTOFFRR(27) Thu 03/09/2023 09:24:42 AM : [Std-Cleanup Ack] 20.73.18-->ISY/PLM Group=0, Max Hops=1, Hops Left=1 Thu 03/09/2023 09:24:42 AM : [INST-SRX ] 02 50 13.0A.51 53.BC.3A 65 13 27 LTOFFRR(27) Thu 03/09/2023 09:24:43 AM : [Std-Cleanup Ack] 13.0A.51-->ISY/PLM Group=0, Max Hops=1, Hops Left=1 Thu 03/09/2023 09:24:43 AM : [INST-SRX ] 02 50 41.1E.09 53.BC.3A 65 13 27 LTOFFRR(27) Thu 03/09/2023 09:24:43 AM : [Std-Cleanup Ack] 41.1E.09-->ISY/PLM Group=0, Max Hops=1, Hops Left=1 Thu 03/09/2023 09:24:43 AM : [INST-SRX ] 02 50 1A.4F.19 53.BC.3A 65 13 27 LTOFFRR(27) Thu 03/09/2023 09:24:43 AM : [Std-Cleanup Ack] 1A.4F.19-->ISY/PLM Group=0, Max Hops=1, Hops Left=1 Thu 03/09/2023 09:24:45 AM : [INST-SRX ] 02 50 16.5C.BF 53.BC.3A 65 13 27 LTOFFRR(27) Thu 03/09/2023 09:24:45 AM : [Std-Cleanup Ack] 16.5C.BF-->ISY/PLM Group=0, Max Hops=1, Hops Left=1 Thu 03/09/2023 09:24:45 AM : [INST-SRX ] 02 50 0B.B7.F8 53.BC.3A 65 13 27 LTOFFRR(27) Thu 03/09/2023 09:24:45 AM : [Std-Cleanup Ack] 0B.B7.F8-->ISY/PLM Group=0, Max Hops=1, Hops Left=1 Thu 03/09/2023 09:24:45 AM : [INST-SRX ] 02 50 1F.BE.7A 53.BC.3A 65 13 27 LTOFFRR(27) Thu 03/09/2023 09:24:45 AM : [Std-Cleanup Ack] 1F.BE.7A-->ISY/PLM Group=0, Max Hops=1, Hops Left=1 Thu 03/09/2023 09:24:46 AM : [INST-SRX ] 02 50 17.F7.B6 53.BC.3A 65 13 27 LTOFFRR(27) Thu 03/09/2023 09:24:46 AM : [Std-Cleanup Ack] 17.F7.B6-->ISY/PLM Group=0, Max Hops=1, Hops Left=1 Thu 03/09/2023 09:24:46 AM : [INST-SRX ] 02 50 41.21.01 53.BC.3A 65 13 27 LTOFFRR(27) Thu 03/09/2023 09:24:46 AM : [Std-Cleanup Ack] 41.21.01-->ISY/PLM Group=0, Max Hops=1, Hops Left=1 Thu 03/09/2023 09:24:46 AM : [INST-SRX ] 02 50 1D.B0.00 53.BC.3A 65 13 27 LTOFFRR(27) Thu 03/09/2023 09:24:46 AM : [Std-Cleanup Ack] 1D.B0.00-->ISY/PLM Group=0, Max Hops=1, Hops Left=1 Thu 03/09/2023 09:24:46 AM : [INST-SRX ] 02 50 1C.DE.23 53.BC.3A 65 13 27 LTOFFRR(27) Thu 03/09/2023 09:24:46 AM : [Std-Cleanup Ack] 1C.DE.23-->ISY/PLM Group=0, Max Hops=1, Hops Left=1 Thu 03/09/2023 09:24:47 AM : [INST-SRX ] 02 50 58.A3.F7 53.BC.3A 65 13 27 LTOFFRR(27) Thu 03/09/2023 09:24:47 AM : [Std-Cleanup Ack] 58.A3.F7-->ISY/PLM Group=0, Max Hops=1, Hops Left=1 Thu 03/09/2023 09:24:47 AM : [INST-SRX ] 02 50 58.B0.78 53.BC.3A 65 13 27 LTOFFRR(27) Thu 03/09/2023 09:24:47 AM : [Std-Cleanup Ack] 58.B0.78-->ISY/PLM Group=0, Max Hops=1, Hops Left=1 Thu 03/09/2023 09:24:47 AM : [CLEAN-UP-RPT] 02 58 06 Thu 03/09/2023 09:24:47 AM : [INST-SRX ] 02 50 1C.DF.01 53.BC.3A 65 13 27 LTOFFRR(27) Thu 03/09/2023 09:24:47 AM : [Std-Cleanup Ack] 1C.DF.01-->ISY/PLM Group=0, Max Hops=1, Hops Left=1 <html><font color="red">----- SC BSMT Test Results -----</font></html> <html><font color="red">[Succeeded]</font> BSMT Game Sconce (58 A3 F7 1)</html> <html><font color="red">[Succeeded]</font> BSMT Fam Rm Sconce (41 1E 9 1)</html> <html><font color="red">[Succeeded]</font> BSMT Video Cans (17 F7 B6 1)</html> <html><font color="red">[Failed]</font> BSMT Stair (1A 5D 6D 1)</html> <html><font color="red">[Succeeded]</font> BSMT Back Room Load (16 5C BF 1)</html> <html><font color="red">[Succeeded]</font> Basement Bed (13 A 51 1)</html> <html><font color="red">[Succeeded]</font> BSMT Storage (1F BE 7A 1)</html> <html><font color="red">[Succeeded]</font> BSMT Game KPL Overhead A (1C DF 1 1)</html> <html><font color="red">[Succeeded]</font> Furnace Room (20 73 18 1)</html> <html><font color="red">[Succeeded]</font> BSMT Game KPL Overhead B (1C DF 1 2)</html> <html><font color="red">[Succeeded]</font> BSMT Fam Cans (1A 4F 19 1)</html> <html><font color="red">[Succeeded]</font> BSMT Back Room (B B7 F8 1)</html> <html><font color="red">[Succeeded]</font> BSMT Game Kit overhead (58 B0 78 1)</html> <html><font color="red">[Succeeded]</font> BSMT Kitchen Ceiling (1D B0 0 1)</html> <html><font color="red">[Succeeded]</font> BSMT Game KPL OFF G (1C DF 1 7)</html> <html><font color="red">[Succeeded]</font> BSMT Game KPL OFF H (1C DF 1 8)</html> <html><font color="red">[Succeeded]</font> BSMT KPL Game (1C DE 23 1)</html> <html><font color="red">[Succeeded]</font> BSMT Kitchen Cans (41 21 1 1)</html> <html><font color="red">----- SC BSMT Test Results -----</font></html> Thu 03/09/2023 09:24:54 AM : [INST-TX-I1 ] 02 62 00 00 27 CF 13 00 Thu 03/09/2023 09:24:54 AM : [INST-ACK ] 02 62 00.00.27 CF 13 00 06 LTOFFRR(00)

Hey bmarsh, I'm a windows user that hasn't played with Linux for years. My Win10 system does regularly "forget" the ISY location. I normally "Load" from a saved file, or "Add" the location manually. Assuming you know the local IP address for the ISY, you can simply "Add" as follows as shown below (use your own IP address of course). Note that the "HTTP://" is mandatory. If you want to add with security, simply use "HTTPS://" If this works, save yourself some headaches in the future by using the "Save" button to save the file to a convenient location. You can then "Load" at some point in the future when the loader forgets the settings.

Just realized that this was occurring. During a query of "My Lighting" the ISY interrogates battery powered MS-II Sensors. As shown below there is no response to the query (as expected). The ISY does not appear to flag this as an error, nor does is query my MS-I sensors. It does introduce a rather long delay in querying the system while it waits for the 3-retries to time out. Multiply this by 5 sensors and you have close to 2 minutes waiting for timeout. It does not interrogate the sensor if it is disabled. Unfortunately, 3 of my sensors are used in programs. I plan to get around the problem by creating a "My Lighting Query" scene that doesn't include the motion sensors. Not sure if this occurs on other revisions of the 994, IoP, or the Eisy.

I used the Schlage for years (300 series). Upgraded to the Ultraloq 700 series Zwave. Could not be happier. With a 700 series controller, the lock included using network inclusion 75' away through a fire wall. Disclaimer - I am using these with a 700 series Zooz Stick on HomeAssistant. Cannot testify how well they will operate on a 300/500 series system. https://www.amazon.com/gp/product/B09Q5QTSQS/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&th=1

OK, I lied. I couldn't let things go. I ran a histogram on the last Error data set. My errors peaked in late summer and dropped off significantly during fall. Two things were changed in this time frame: 1) I removed my Schlage Z-wave lock from the system in Mid August. It was a problematic 300 series device and may have been loading the ISY with retries (programmatic) . 2) I was running a ~20 minute timer program cycling my AC to prevent Evaporator Freeze up (15 minutes on/5 off). This would have stopped in the September time frame (New HVAC). I am thinking these errors are environmental. I don't remember the flow control between the ISY/PLM and am wondering if asynchronous events (motion sensors) may be colliding with synchronous events (timer programs). Either way, I am generating far fewer errors now than I was in July with no change to PLM/ISY994 hardware. I like that direction. Thoughts, comments, catcalls appreciated...

I, for one, have no clue what the implications of the -10 error are. I have apparently had this occurring for around 12 years with no observable problems. At this point I am in about the same position as you. I have a number of spare PLM's and very little incentive to investigate this further. I do have one advantage - advanced age. I'm thinking I'll allow CRS to take over (Can't Remember S#*5). Tomorrow I'll be feeling great again.

I will start by confessing that I didn't know what the -10 error meant. After reading your posts, I went back through a number of error logs that I had saved. FWIW, the -10 errors are rather common on my system. I have not noticed any performance issues over the time frame covered below. The 4.8 errors per week are lower than my most recent log, but higher than the previous. I am not sure what to make from this. I have never experienced a PLM failure. I've replaced several units over the years due to various improvements, but no failures. I seem to be blessed by "good" power (Hate letters to the normal Email please). I also have logs going back to the 2011 time frame that show the -10 error. They seem to come in clumps, with no particular day/time preference. If I weren't old and lazy I would try to run an analysis on the data to see of there was a correlation with other events going on in the system... I'd be interested to know if there appears to be a time/day preference for your errors. If you are having errors across several PLM's, MrBill's advice is sound. Submit a ticket to try to determine if the errors are due to hardware or environment. Firmware Start Date End Date Days Errors Errors/Day V5.3.4 7/15/2022 11/29/2022 134 125 0.9328358 V5.3.4 10/5/2020 7/13/2022 638 270 0.4231975 V5.3.4 12/8/2019 3/7/2020 89 239 2.6853933

I'm probably beating a dead horse here. I agree that the ISY should be a standalone system that requires very little maintenance. Barring updates or technology expansion, it should just run. Unfortunately, a number of the "modules" have gone away over the years leaving customers stranded. UD has tried to make new options available to replace the disappearing modules, but that isn't always possible within the confines of the given platform. Maybe I misread the OP's post. The words "running again with my ISY" signal to me that he had the NuHeat module running on the ISY994 and it died (presumably when PG's died). Geddy did an excellent job of laying out the events that led to the demise of PG2/PGC and options for getting things running again (PG2 on Rpi or PG3 on Eisy). Unfortunately, there doesn't appear to be a solution using the OP's existing ISY994. I can understand his frustration. It worked previously, but now he needs to buy a Polisy (can't get) or an Eisy (not available yet). Does that mean that he wasn't paying attention? He wasn't involved enough with the forum to understand that things were breaking and being deactivated? You and MrBill are extremely well versed on the technology and various platforms. I enjoy reading your explanations of the various problems and workarounds. In short, I've learned a lot from both of you. Unfortunately not all of us are as up to date on the ISY, PGC, PG2, PG3, Polisy, Eisy happenings. We do have jobs, families, and little distractions that take time away from keeping on top of the technology. Please treat us gently. We often do not have the time to invest in reading years worth of posts trying to find a solution.

Let me start by saying that I've been a UD customer since 2007. In my mind, UD helped to take Insteon from a well engineered but haphazardly deployed product to an Integrated system. I still use my ISY994 for Insteon and the Elk Module integration daily. So, what is my point in posting? I have to object to a number of the posts above that indicated that the OP "you haven't been paying attention" or that "it's on the consumer to keep up as things can change significantly". I would be shocked if UD were in agreement with this. In contrast, their website advertises the products as standalone devices that are stable and do not require babysitting (see below) This device should not require constant maintenance or vigilance. That's why we purchased a dedicated hardware device (not cloud services). If you do not make changes to your installed system, hardware/software changes and upgrades should not be required. By indicating otherwise, you are alienating UD customers that have come here for help. If I am wrong in assuming that this should be a low maintenance product, please correct me. I will immediately begin looking for hardware replacements that fit the description below: UD Webiste Ad Automation | Energy Management | IoT | AI We invented and commercialized the first low cost, embedded, and fully standalone home automation controller in 2007. A few inventions later, 10s of 1000s of rock solid installations later, our ISY994 Series line of products embody the perfect marriage of Automation, Energy Management, IoT, and AI Assistants. You can easily consider ISY as your sidekick@home. You can program your ISY with what needs to be done and it does it. Literally and forever unless you instruct it otherwise. You can count on it. Your ISY does not need to be babysat, it is not a glorified remote control app on your mobile phone. Neither is it some magical essence in the cloud that might take a break once the Internet is down. Your ISY can notify you of major and important events, you can talk to it, and it can talk to you. Yes, via natural voice using Alexa and Google Home. Your ISY can even help you save money, save energy, conserve water, and save the earth! Why should you trust us? Because we stand behind you and our products. Don’t take our word for it. Take a look at our Testimonials

Hello balli, I have had nothing but good experiences with the Zooz gen7 devices. I do not have any Zen76, but do have 4 Zen77 (dimming version) as well as a number of battery devices and a Zooz ZST10-700 controller. As Techman implied, I would submit that your problem is the 500 series controller in the ISY994. I struggled with this for years with my system. Kept adding repeaters to the system trying to fix intermittent problems. I finally moved to the zooz 700 system (controller, locks, switches) and have been extremely happy. Most of my battery devices now direct connect to the controller. To put that in perspective - my controller is in the basement, battery devices are in the garage (75', attic 35', 1st floor, 2nd floor). It may be painful, but I would suggest moving on from the 500 series controller. I moved to Home Assistant on a Raspberry PI for my Zwave devices. I am still using the ISY994 for Insteon. Home assistant interfaces nicely with the ISY994 (I can share scenes, and actions). To be clear - your Zwave communication problems are not the fault of the ISY. It is the 500 series Zwave controller that is constraining things. Unfortunately, the ISY994 does not support 700 series Zwave controllers. The following Zwave network map doesn't show that well. Items on the 2nd level down have direct communication to the 700 series controller in my basement (10 devices). 3rd level devices require 1 hop to make it to the controller (4 devices). Keep in mind that I only have 4 wired devices (repeaters). Everything else is battery. Hope this helps, IM

You need to think in terms of current imbalance rather that power usage. A few milli-amps imbalance (fraction of a watt @120V) is enough to trip a GFCI. A length of buried cable that is leaking to earth can produce enough imbalance with zero load. It sounds like you have a number of devices and cable runs that could contribute to the leakage. Unfortunately, the leakage is small and difficult to detect. I would suggest using the process of elimination to isolate which device(s) are leaking. I say devices because it could be multiple underground cable runs that are contributing to the leakage. The underground cable to my post light lasted 20 years before it had issues. 1) With everything installed on the circuit, force run your 3am query to verify that you can trip the breaker - this is your detector. You can also query "my lighting" from the admin console tree. 2) Remove al of your outlets and loads from the GFCI circuit and repeat the query. Hopefully the GFCI will NOT trip. 3) Begin adding loads back to the circuit, repeating the query process. If you find a load/device that trips the GFCI, try it by itself. Remember that the leakage may be "additive" across a couple or several loads. This could be easy, or really complicated. Let us know what you find.

Hello rssorensen, Just a few addition comments to the good items provided above. To start (and not to be insulting) GFCI devices trip if there is and imbalance between the hot/neutral current. They are very accurate and fast. Insteon communications (130 KHz vs 60Hz) can cause a higher leakage if the path is capacitive. I have had a HP printer that had "high" leakage to ground and would intermittently trip a basement GFCI. I cured this with a filterlinc (isolated the printer from the 130KhZ Insteon). 1) The "Query all" program includes everything in "My Lighting" (excludes battery devices). This includes Insteon, X10 , and Zwave. You can create your own "house query scene" to limit the devices. I created my own query scene years ago when my 2-way x10 devices were having issues. It does require maintenance - you have to add new devices - and it is a patch - it does not solve your root problem. 2) I have had problems in the past with a garage circuit tripping the CFCI when my outdoor post lamp was on (photo cell) and there was insteon communication. I narrowed this down to a bad underground wire that was leaking to ground (or earth) during communications. Insteon communication is higher frequency an will cause higher leakage to earth (or ground) during communication. As ELA idicated, If you have high leakage on a circuit, the additional Insteon communication could be enough to trip the CFCI. 3) Recently I had installed a 2 prong Zwave repeater on my garage circuit. Soon after the GFCI breaker tripped. Reset the breaker, and noted that It tripped whenever my Zwave garage lock operated. Moved the repeater to another circuit and the problem when away. I bring this up because I did not expect it. I would not expect a 2 connection device to trip a GFCI unless it significantly delayed the current draw. This is not necessarily due to the Insteon device. You mentioned that your GFCI was on an outdoor circuit. Have a look at any outdoor devices that may have degraded over time (transformers, underground cables, smokers, etc). They can all contribute to leakage to ground. IM

JTsao, Thank you for the post. I had bought the WiFi version of this lock for my daughter when she purchased her new condo last year. She loves the smartphone/alexa integration as well as the fingerprint access (2 room mates). I'm not a WiFi fan and was exited when I saw the Zwave Plus V2 lock become available earlier this year. I was just waiting for the correct post to push me into buying it. Your post got me moving. Like you, I have 2 Schlage (original) BE469 deadbolts. The high maintenance unit is located in the garage ~ 75 feet from the ISY in my basement. The garage is also lined with foil backed foam on the inside, and stucco on the outside (Faraday cage). My zwave access is through the door window between the house and garage. I was constantly moving repeaters around hunting for the sweet spots to made the garage deadbolt reliable. I installed the Ultraloq Pro Z-wave deadbolt yesterday. I have only the ISY994, so I chose to pair the lock with Home Assistant and the same Zooz ZST10 that you used. It took roughly 30 minutes to install, setup on the phone APP, and pair with Home Assistant. The real kicker was that I included the lock in the garage location with my Rpi4 home assistant 90 feet away in the basement. I was astonished. I could not believe that it could be that easy. All the years of fighting with the Schlage using multiple repeaters, including with extension cords/cat 5 extensions so that I could include "in place", and the Ultraloq included in place with 2 Zooz Z77 switches as repeaters. The cherry on top is that the Ultraloq comes with a door sensor (magnet) to detect when the door is actually closed. I programmed it to autolock 5 minutes after closing. I had been using my ELK-M1 door switches to tell the ISY994 when the doors were closed. My programs on the ISY would then lock the door after 5 minutes and indicate the status on various KPLs. The ELK integration was one of the things that was keeping me from moving to the Polisy. I was worried that I would not be able to accomplish the same integration/timing on the new platform. No longer a concern. At this point, the second Ultraloq is on order (front door - easy one). Just need to figure out how to "back communicate" lock status to the ISY994 so my KPL security monitors display properly. Thanks again for the push in the back, IM

Apologies if this has been previously reported... As shown in the graphics below, the "my lighting" folder contains the buttons "Query, All On, and All Off" in the folder window. These buttons are functional. The folder windows also contain the "Query, All On, and All Off" button. They are not functional in any of the folders. The folder All On/All Off would be useful in determining which modules have the Insteon fix to NOT Respond to a ALL On/All Off. Windows 10 Running 5.0.16C

Hello oberkc, You may be correct. My experience is from the original ISY back in 2006 (very dated). At that time it was possible to set up a race condition in the manner that I described without a wait. Many things have changed since that time. I do not think we can test this without seeing the "security - back timer program". There may be issues where communication failures/re-tries factor into the program timing. In general, it's never advisable to modify the trigger conditions within the program. We may need Chris to weight in on whether this specific implementation is a problem with Ver 4.7.3. Realistically, I'm thinking he busy working on our 100's of other requests. Sincerely, IM

In general, you should not modify the state of your "IF" conditions within the program. It will cause the program to re-trigger. If you put a delay (1 sec) after the "Set dining room" statement, this program would exit 100% of the time. Without the delay, you have a race condition. Hard to say if the re-trigger will take effect before you make it to calling your other program. You may be getting "lucky" on your other program. Regardless, the "responding" drop down in the lower pane has no bearing on your saved program. It is simply an option for modifying/adding to the program. Please let us know if the modification works. It's possible you have another race condition in your called program.

Hello proj964, The lower panel is an "Action" panel for changing or adding to your program/conditions. The fact that it shows "responding" indicates one of the options for adding to, or modifying your existing program. Your existing program (if saved) is shown in the upper pane. Bottom line - the lower pane is distracting you from the real problem. 1) Your IF statement checks the "dining room/outside light switch" status to make sure it is off. 2) Your program set the "dining room/outside light switch" to "ON". This causes the program to re-trigger, and the "IF" statement is now false. 3) The program MAY exit before executing the remaining statements. It's basically a race condition. You could move the "dining room/outside light switch" ON statement to your "Security back timer" program to prevent the re-trigger.