IndyMike

It's possible that the "missing this record" message on the isy link table is simply a difference in presentation between the ISY and PolISY. Beyond that, I do not see anything in your device link table that indicates the scene should be turning on buttons 3, 4, 5,&6 at the same time. If deleting/re-installing doesn't work, you may need to try a different device.

You have missing/incorrect records immediately after a restore. That's not good. I'm surprised you didn't get any write errors. This would normally imply device communication issues. How do your Comms look in the event viewer? What I have never seen is the errors on the left (ISY link tables) side. It almost seems that the ISY is saying it's missing records (SDcard issues?) Curious if you see this on different devices. The following is a scan of my test KPL. I turned the "KPL High" scene on from the Admin Console. The event viewer showed this as scene 00.00.37. Inspecting the KPL link table I can see where Scene #37 is set to turn button 3 on (FF) and buttons 4, 5, 6 off (00). Your scene #48 appears to do the same. Curious if things behave differently now.

@apostolakisl, in a word "Yes" the above should work. I have similar KPL's all over my house. I use the Non-Toggle Off in my installation but understand why you are using Non-Toggle On. Just to be certain, I set up an old 6 button test KPL using your configuration. And yes, we are not crazy. It works, both from the KPL and the admin console. Based on the screenshot in your post, I do not understand why your "Exercise Rm Fan High" scene would activate all of the buttons. My configuration - ISY994 V5.3.4 KPL - 2486D (6 button), FW V.41, V6.0, D.C. 1213 Ideas (SWAGs): 1) Since you are re-purposing, wouldn't hurt to delete the device from the ISY, factory reset, re-include. 2) For this to be happening, the scene responder link in the KPL would need to be missing or incorrect. Could you do a device link table scan and provide the results? I would explain why the KPL isn't responding properly. It would not explain why it wasn't written properly. 3) Not sure if you are using a Eisy, or Polisy. I would think the scene management would be the same, but maybe the integration of Zwave and other technologies has broken something.

The I2CS protocol increased security - Incorporated @ FW V.41/ Rev 6.9 in late 2012 (madreporite) Removing the All-on/All-off command seems to have been incorporated @ FW V.45 / Rev 7.8 in the 2016 time frame. Beyond that, there "may" have been power supply capacitor changes to improve durability (similar to the changes in the PLM). I do not have information on that. @Brian His a good source for hardware information on many of the devices. Hopefully he can educate us on any improvements that may have occurred. IM

@gweempose, not sure exactly what you are looking for. I believe all of the 2477D's were dual band. The following link lists I2 and I2CS introductions for the device: http://www.madreporite.com/insteon/Insteon_device_list.htm Beyond that, I ran some testing on my 2477D devices to determine if Smartlabs had removed the "all-on/all-off" broadcast commands. From what I saw, devices with a FW level V.45 did NOT respond to the All-On/All-Off broadcast: https://forum.universal-devices.com/topic/41651-all-on-removed-in-what-firmware-version-of-switchlinc-dimmers/?do=findComment&comment=369748 Not sure if that's what you were looking for... IM

@Merlin - Thanks for the response. Another device to investigate - oh well. I am curious how you are powering the devices (and hiding wires) in your installation. Would you mind describing or providing a photo of your wired device? Thanks, IM

I agree that the ISY cannot directly address a KPL secondary button. In order to control a secondary button, it needs to be included in a scene. I am curious why the ISY isn't creating a "scene" for Insteon devices and an "association" for Zwave devices. Either way, it should be an easy thing to determine from the event viewer when the scene is activated by the Z-wave controller. Scene Activation - The 00.00.XX device address is indicative of a Scene. The "CF" flags also specifies a scene command but I am to lazy to decode this AM. Fri 12/01/2023 09:15:15 AM : [INST-TX-I1 ] 02 62 00 00 13 CF 11 00 Fri 12/01/2023 09:15:15 AM : [INST-ACK ] 02 62 00.00.13 CF 11 00 06 LTONRR (00) Device Direct Addressing: The 1A.5D.C7 address is an individual device in my system (member of the scene above). The "0F" Flag also specify a "direct command". Other indicators of a direct command are the 3rd line (02 50) which is a response from the target device. Scene commands (above) do not request a response. Fri 12/01/2023 09:16:24 AM : [INST-TX-I1 ] 02 62 1A 5D C7 0F 11 F7 Fri 12/01/2023 09:16:24 AM : [INST-ACK ] 02 62 1A.5D.C7 0F 11 F7 06 LTONRR (F7) Fri 12/01/2023 09:16:25 AM : [INST-SRX ] 02 50 1A.5D.C7 53.BC.3A 27 11 F7 LTONRR (F7) Fri 12/01/2023 09:16:25 AM : [Std-Direct Ack] 1A.5D.C7-->ISY/PLM Group=0, Max Hops=3, Hops Left=1 I do not know/understand how the ISY is activating Zwave "associated" devices. I do not currently have a Zwave/ISY installation to test. But I am very curious for future installations. One last comment - I do remember a @lilyoyo post from years ago indicating that Zwave controllers should be added to a scene 1st. I had always abided by that when I had my mixed system. Have no idea if it still applies. IM

@djones1415, I apologize if my response implied in any way that you required this type of response. Being an Engineer (and working with Engineers) for 40+ years, pictures and screen captures are my go to. My friends and family would attest that I am uniquely qualified to provide idiotic responses. Glad it helped. In retrospect, Lou's (Apostolakisi) response was exactly correct. Had I seen it, I would not have replied. Geddy's response was "most" correct - pointing to existing Wiki documentation rather than re-inventing the wheel. I need to remember that. IM

Device replacement steps - This only works with similar device types (dimmer to dimmer/switch to switch) 1) Factory reset your new switch. This removes potentially unwanted settings from the new device (X10 addresses, etc). Manual : 2466 Toggleinc 2) Link the new switch and use the "Remove Existing Links" option. There should not be any links after resetting, but... (belt and suspenders). Name the device something similar to your old device - add a "#" or a "new" to discriminate between them. 3) Right click on the "old" device that you want to replace. It should now show the recently added device as an option for replacement. IF IT DOES NOT your old device is in a sub-folder or a different device type. If in a sub folder, move to the root folder. Device in sub folder will not show replace option After moving to the Root folder: replace is now an option 4) After performing the "replace with" you will be prompted to re-boot the ISY. Following the re-boot, the new switch should be in place and all of your programs and scenes should be updated. 5) Re-name the new device if you wish. All the programs and scenes will be updates.

@paulbates, Nicely done. I'm assuming you are using a "legacy" on/off module (not the newer I3). Nice wire solution to the dusk/dawn issue. Thanks for updating, IM

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')

@elvisimprsntr I apologize. My earlier response came off as dismissive. I do use the location based dusk/dawn for all of my outdoor lighting. I also use it for indoor lighting, but in conjunction with local light level measurement. Today is another day when my local light level measurement will enable motion based lighting throughout the day. I use it for all hallways, stairs, and kitchen. We're just in a different environment than you're accustomed to.

Hey Paul, I had forgotten about the Micro Modules. Connecting the sensor output to the sense input on the Micro Module is actually rather elegant. You will need to watch for leakage current on the Dusk/Dawn sensor. I've never actually measured this on my post lamps, but it's not enough to light the LED bulbs that I use. If necessary, you could add a load to the sensor to keep the current/voltage below the sense input turn on threshold. Let us know how things go. https://cache.insteon.com/documentation/2443-x22-en.pdf

I see that you are from Florida. You are correct for locations that receive sunlight on a regular basis. Both Paul and I are on the lee side of lake Michigan. We are currently enduring the time of year that I refer to as "Perma-cloud". Based on the current forecast, we will not see the sun until Monday. Once we hit November, things get far worse. It's nice to have a system that responds to current ambient light during our dark days. While the lake may give us clouds and snow during the winter months, it also keeps us much warmer than locations to the West (Chicago, Green Bay). Clear days in Jan/Feb look nice - but that's when the temps plummet.

Hi Paul, Understand that you are trying to re-create the dusk/dawn feature. I am not sure if you are looking for Insteon hardware or are looking at other technologies. Also not sure what platform ISY you are using. The Insteon MSII sensors can work, but require external power and a lot of finagling (normally accompanied by the use of bad words). There are several Zwave motion/temperature/humidity/light level sensors that could be added (Zwave dongle or Eisy Matter module). I currently use Zooz ZSE40 700 and like them a lot for motion detection, temperature, and battery life. I can't comment on the luminescence feature as I don't utilize it. If you're interested, I could start charting it. Wireless tags are another way to get Motion, Temperature, Light, and Open/Close information into the ISY. I have not used them as yet. Many forum members have and could provide guidance if this is a direction you are interested in. Tags can be found here: Wireless Tag's. There is also a forum topic dealing with the Tag nodeserver and integration. Give us a bit more information on how you envision this system integration. I'm sure this forum has the expertise to help. IM

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