IndyMike

Hey Jeff, The most recent table is "better". The first link @address 0FF8 shows that your device is a responder(A2) to group 0 device 70.1A.5A - your PLM I presume. What I don't see is a corresponding link where your device is listed as a Controller to the PLM. This would be 0XXX: E2 XX 70.1A.5A. What you have in the table is a HALF link. The PLM can control your device, but the device can't issue control events back. Again, you can probably rectify this by deleting/resetting/relinking your device. If you have many devices that fall into this category, a ticket might still be a wise course of action.

Ok, so I looked a little more. I'm thinking something is hosed with your link tables. Normally the first entries are links back to your PLM. The link table below is for my "all-on" detector. It's only linked to my PLM @53.BC.3A. Your device appears to be linked to address 00.00.00 - Not Good. If this were just 1 device, I would suggest deleting/reset/relink for this device. If your entire system has this issue (you can look at the tables for a number of devices) I would again suggest opening a ticket.

Hi Jeff, Your event viewer above has a "Link for responder... not found" entry that I have never seen before. Basically, you executed a Scene (00.00.28) and requested status (something the ISY normally doesn't do for scenes). The Eisy did not expect to see the responder @1C.47.5E. Something appears to be out of synch between your Eisy/PLM/devices. You have a device that believes it's part of scene 00.00.28 but the Eisy doesn't know about it. I don't have the Eisy, but would guess that something went wrong during the migration. The fact that you do not see Control triggers in the event viewer is also indicative of missing links in the PLM/Eisy. I can't help much past that. Unless someone else has experienced this, it may be time to open a ticket...

Don't know the answer to current offering from Insteon. Loosing two accesspoints is definitely telling. I still don't understand why your 2477D's aren't communicating across the phases. Is it possible that you had an electrical event that took out multiple devices? If you have "damaged" insteon devices hanging on the powerline they might not properly repeat the signal (rf or powerline) and could instead appear to be signal absorbers.

Actually, half red/ half green is ideal. You are communicating across both phases with the range extender in that location. Is that the location where your failed AccessPoint was? Do you see any correlation between Red flashing or Green Flashing devices with devices that you can't restore? If all of your problem devices are on one phase that would give us a direction to pursue. You could remove your range extender and run the 4-tap test on your PLM. If devices in your garage don't flash (or only flash red or green) it would be another indication that your PLM signal isn't making it there.

Marcus, Your garage fan restored, but it is marginal. There were numerous ISY retries during the restore process. This device will not be reliable in Scenes (the ISY does not check status/retry communications in scenes). Your garage device made it further than it had previously. There were a number of retries. Can't tell why it failed as it's only a partial log. The fact that your Accesspoint died may be the smoking gun we were looking for. Try moving the range extender to it's location. It does not need to be linked to repeat signals. The Range extender will operate the "4-tap test" by itself. Tap it 4 times (quickly) and it will start beeping and sending out signals: 1) Devices on the same phase will flash red (including your v.45 dimmers) 2) Device on the opposite phase will flash green. 3) No flashing indicates no signal reception or does not support the test. Investigate the devices that don't flash to determine their firmware level. We should be able to determine whether they support the test or not. You can actually run the 4-tap test from any enabled device (as Techman indicated above). This includes your PLM and your 2477D Dimmers. The dimmers can be a bit tricky to activate since you need to push the set button 4 times quickly. I was able to do this on a dimmer after removing the front plate.

Your garage light is going to be problematic. It essentially has poor communication in both directions. What is puzzling is the fact that all of the Dimmers you've listed so far are V.45 dual band devices. If there are were problems with noise of absorption on your powerline, the PLM should communicate through RF. Techman's suggestion of the 4-tap test is an excellent one. If will tell you which devices are on the same phase as the PLM (flashing red) and the opposite phase (flashing green). I would infer that a device that doesn't flash at all (steady green) either does not support the test or is not communicating.

The Log above shows that you successfully linked device @ address 41.AC.90 (Switchlinc dimmer?). It also shows that your wrote the updates to the Switchlinc dimmer @40.FA.88 (previous device you were writing to). That sounds like a big success. That would indicate that your original PLM location is suspect (noise/absorbers)

Hello again Marcus, I wanted to show you what is going on in your system. I found a V.45 switchlinc dimmer in my stock - identical to the one you tried to link. I factory reset it, and then linked it to my ISY/PLM In the graphic below, your device log is on the left/ mine is on the right. The normal sequence of communication is : [INST-TX-I1] (or I2): ISY communicating to the PLM [INST-ACK]: PLM acknowledging the ISY command [INST-SRX]: Target device responding to command (switchlinc dimmer). The RED highlighted sections below are instances where the ISY did not receive a response from the Switchlinc (4 total). The ISY will re-send the information until it gets 3 no-responses. In the case of your Switchlinc, 3 ISY got 3 consecutive no-responses and declared a fault. What is curious is that when the device DID response, it showed 3 HOPS remaining. It doesn't get any better than that. The device appears to be having problems "hearing" the PLM. When it responds, the communication is excellent. Your KPL showed similar issues. Numerous no-reponses, but good HOP levels when it did reply. This is why I am asking about signal absorbers, phase coupling, or other changes to your system.

Hello Marcus, You are absolutely having communication issues. Your KPL appeared to accept writes properly, but then failed to respond to tree successive retries from the ISY. What I find ODD is that your retries (no response from KPL) is followed by a good response in terms of HOPs. The below shows a timeout followed by a very good response (2 HOPS left). It's almost as if the KPL doesn't hear the PLM periodically. When it does hear the PLM, it responds well. Check to see if there are signal absorbers plugged in near your PLM. Unplug or filter if you find any. I know you tried moving your PLM once already, consider trying again with a shorter cable. Thu 08/10/2023 11:48:37 AM : [INST-TX-I2CS] 02 62 40 FA 88 1F 2E 00 01 05 1F 00 00 00 00 00 00 00 00 00 00 AD Thu 08/10/2023 11:48:37 AM : [INST-ACK ] 02 62 40.FA.88 1F 2E 00 01 05 1F 00 00 00 00 00 00 00 00 00 00 AD 06 (00) ###########@ Timeout - Should be a [INST- SRX ] here ######### Thu 08/10/2023 11:48:46 AM : [INST-TX-I2CS] 02 62 40 FA 88 1F 2E 00 01 05 1F 00 00 00 00 00 00 00 00 00 00 AD Thu 08/10/2023 11:48:46 AM : [INST-ACK ] 02 62 40.FA.88 1F 2E 00 01 05 1F 00 00 00 00 00 00 00 00 00 00 AD 06 (00) Thu 08/10/2023 11:48:48 AM : [INST-SRX ] 02 50 40.FA.88 70.16.CE 2B 2E 00 (00) Thu 08/10/2023 11:48:48 AM : [Std-Direct Ack] 40.FA.88-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Your second device also failed to respond after 3 retries. It was far worse and did not accept any data. Have a look at your Insteon Messaging Settings under "Link Management\Advanced Options". Let us know what your current setting are. Consider using moving a plug in device (lamplinc/appliancelinc) next to the PLM and restoring that. Trying to figure out if you have a problem with your new PLM, your installed electrical circuit, our your phase coupling.

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