IndyMike

Hi @Merlin, Unfortunately, I can't help with inclusion issues as I don't have the Eisy. I do have a number of the ZSE44's and am happy with them in general. They do have a lot of "nodes" as you refer to them. On my ISY994, I believe I was able to "group" nodes by right clicking on the main node (1) and selecting "group devices". This would move the secondary nodes under the main node in the device tree (make them less obvious). As I indicated, I have a number of the ZSE44's. I am happy with them except for my "outdoor" devices that consume batteries. The issue here is that I have devices outside the house that go through wide temperature swings this time of year (40" degrees). This drains a lot of battery. Devices in the house run ~1 year on a CR2450. Outside, less than 1/3 during spring/fall. I am posting because I am interested in the Aeotec Mutisensor 7's that you have coming. Then have an advertised life of 3+ years. The are similar to my Zooz ZSE40's that I have been happy with (motion, temp, humidity), but have a much better advertised battery life. Please do report back how you like the Aeotec devices. If you have further questions on the Zooz ZSE44's, I'll help where I can. IM

Wow, after reading @Geddy's post I logged into the admin console to re-checked my Scheduled execution times (no changes). They are back to being correct down to the tenth of a second. Wild and wondrous - I guess that's why they call it software.

Hey @paulbates, Let me start by saying that I have the ISY994. I have two programs that run nightly at sunset, and 30 minutes past sunset. When I looked at the program summary tab, both programs were set to run @EXACTLY sunset and 30 minute past. My sunset is at 5:36:10 (I'm a little West of you). Since my programs are slightly different from your Time = Sunset, I decided to add a test case. That's when things got weird. After saving my test program, ALL of my sunset programs showed a "Next Scheduled Run" time that was 4 minutes, 4 seconds early. I expected 5:36:10 PM (sunset) for my sunset programs, but got 5:32:06. I expected 6:06:10 PM for my night program (sunset + 30 min), but got 6:02:06 PM. All that I can think of is that the next run is "predicted" when you save the program. It is then "refined" after the program executes (or perhaps at the end of the day). Definitely not the result I was expecting and in line with what you are seeing. Original Sunset Program: Fires @5:36:10 Outside Sunset - [ID 0015][Parent 0002] If From Sunset For 1 minute Then Set 'Outdoor / SC Outside Sunset' On Else - No Actions - (To add one, press 'Action') Original Night Program: Fires at 6:06:10 Outside Night - [ID 0016][Parent 0002] If From Sunset + 30 minutes To Sunrise + 5 minutes (next day) Then Set 'Outdoor / SC Ouside Night' On Else Set 'Outdoor / SC Ouside Night' Off New Test Program: Fires at 5:32:06 Outside Sunset1 - [ID 0011][Parent 0002] If Time is Sunset Then - No Actions - (To add one, press 'Action') Else - No Actions - (To add one, press 'Action')

@madmartian There is a discussion of SIS and SUC Z-wave controllers over here: https://www.vesternet.com/en-us/pages/your-guide-to-a-user-friendly-stable-z-wave-network What I gather from this is that the SIS controller is the "repository" of all device node information in the Z-wave network. If you had other controllers in the network, they would be unable to operate after you reset the SIS. This is my first exposure to the SIS concept. Since you are resetting your entire network (all devices and dongle), I don't believe there is an issue. Curious if anyone has a different take...

Hey Andy, Given that you apparently have an Insteon door Open/Close sensor (there I go ASSuming again), I would tend to agree that this appears to be a Eisy issue. If you could perhaps post some "level 3 event viewer" traces, with manual Vs door operated triggers, someone with a Eisy could chime in on the issue. Not much, but the best I can offer for now.

Edit: after re-reading your code, the "Switched on" control action in the If clause should prevent multiple triggers. Unless the door is cycling open - closed - open, etc. I'll leave the original post below. It's something to try for troubleshooting purposes. I have used the "Beep" calls with the ISY994 for years with no issue. I don't have a Eisy to test... Just guessing here... Since things work when you trigger the programs manually, it seems that the alarm system integration may be the issue (ELK?). One of the differences in the Eisy is the use of a node sever for the Elk integration. The ISY994 used a "built in" integration. You may be getting multiple triggers or other timing issues when your door opens. You could try locking the program out using a variable or by testing that the program isn't already running. Waits could also be used to make things easier to test. Something along the lines of: If 'Lwr Ground Floor / Backdoor-Opened' is switched On and $Status.ProgramBeep is not $Status.Running Then $Status.ProgramBeep = $Status.Running Wait 1 second Run Program 'Beep' (Then Path) Else - No Actions - (To add one, press 'Action') BEEP ProGRAM If Then Beep Beep Beep $Status.ProgramBeep = $Status.Idle Else - No Actions

The following is what I use for polling my outdoor lights. The If statement you are looking for is "Time is Last Run Time for {program name} + 30 minutes". You will also need to make sure that "run at startup" is checked in the program "summary tab" Outside Daytime Poll - [ID 0030][Parent 0002][Run At Startup] If From Sunrise + 30 minutes To Sunset - 10 minutes (same day) And Time is Last Run Time for 'Outside Daytime Poll' + 20 minutes Then Set 'Outdoor / SC Ouside Night' Query Else - No Actions - (To add one, press 'Action')

UltraLoq U-Bolt Pro. I installed a WiFi set at my daughters house and Z-Wave in mine. We both love them. The locks are 700 series and paired to my Zooz 700 series Z-Stick from their remote locations (75+ feet). I was impressed.

I was using a very similar setup (BE469/300 Series/ISY994) that worked reasonably well. I upgraded to the 500 series dongle on the ISY and things went downhill. Tried a 700 series Z-Stick on Home Assistant and it failed miserably. Upgraded the locks and everything worked. The 300 series BE469 is marginal at best on send and receive. If you happen to have a steel entry door, you are already at a disadvantage. I hope Techman's suggestions work, but in my experience, you are fighting a loosing battle with that lock. If your lock responds to commands from the Eisy, I would eliminate the "If - Status Z-Wave/Lock - Front Door is unlocked" qualifier. You will be triggering when the Elk indicates the door status changes to "closed". You will not detect a local lock/unlock. Not optimal, but you will have some functionality.

Hello Geddy, You are correct that I was referring to the "new" Pop-up "Not Found" bug. What is confusing to me is that the bug crept in with no changes on my end. IoX launcher is from 5/20/23. ISY994 is the latest (last) V5.7.4 (Firmware and UI dated 7/7/21). At the moment I view this as yet another nail in the ISY994 coffin. I plan to keep using it until it gives up on me.

I'm wondering if we aren't over complicating this. My IoX finder routinely "forgets" my ISY address. I either add the address manually or load from a saved file. As you mentioned, the IoX finder recently began giving me "not found" errors. However, I can still manually enter the IP address for the ISY and connect to the admin console. I'm ignoring the "not found" errors for now. Try the following: https://forum.universal-devices.com/topic/39489-iox-finder-not-found/?do=findComment&comment=354467

Thank you for the link to the backup routine. That looks very useful. I have been using the Sandisk A1 microSD cards in my cameras and Pi since 2019. Very good experience with them. I've been out of the industry since 2019, but it's hard to believe that things haven't improved in that time... I did check my ISY994 card - it's a run of the mill Sandisk (reputable name) with no speed/endurance markings. It is the original card. Sorry for taking the thread sideways...

@MrBill, your experience is very different than mine. I've never had a SDcard issue. I have had multiple power supply failures over the years. Your comment on the node servers is interesting. I have not used them and did not realize that they exercised the SDcard to that extent. I did opt for a high endurance SDcard for my Home Assistant installation on the Raspberry Pi 4. I knew I would be logging temperature data and exercising the card. If what you are saying is true, the calculus for the memory card may have indeed changed. Should we be putting out a general recommendation to the ISY community to upgrade their cards to High Endurance versions? High endurance cards for ISY are moderately priced. This could be cheap insurance for the ISY.

@bw23198, as @hart2hart indicated, you likely have a corrupted file system on your SDcard. The "bad areas" likely existed prior to you restoring your backup. Now when you try to perform a backup the ISY cannot read the file structure. Option 1 - While SDcards can go bad, it's somewhat rare. Normally it's a power event while the card is being written to that causes corruption. The failure rate of your power supply is far higher than the SDcard. If you have seen "other problems" (reboots, warning lights, etc) check your power supply. Spec's are on the Wiki. There's also a thread here: Option 2 - card contact issue Remove the card/clean the contacts/re-install several times to see if it is a contact issue. Re-install your backup Re-try backing up the system to see if you have file errors. Option 3 - bad card (cards are pretty inexpensive). @MrBillhas a rather nice post on upgrading the MicroSDcard here: Best of luck - let us know what you find.

Nice -glad it worked. The UD folks are good at coming up with magic. That's why we all here.

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.