AllDigital

I tried this with my Garage keypad, since it is the only one with F keys showing up in the EISY/Elk and it did not trigger the alarm. I'd like to try it with my other keypad, but the F keys don't show up in EISY even though I confirmed they are programmed and working. Any obvious reason triggering a keypad F2 wouldn't work from a program? Everything else communicates well between the Elk and the EISY. Also, do you know any way I can force the node server to pick up the F keys on my master bedroom keypad? I am leaving on a business trip for a while, but when I get back I can do more troubleshooting with the node server logs. Troubleshooting this is tricky, since the alarm is "hot", lots of people in the house, etc. I need to coord with the monitoring company and the family

Thanks @DennisC and @kzboray. These were both helpful, but not exactly what I need. In my situation I have a keypad by my garage door and one in my master. It turns out they both have function keys already programmed and I have tested that they work. Let's call "F2" the police/burglary button. In another bedroom I have two physical push buttons that go to a Zooz relay that triggers EISY programs. One turns on every light in the house and the other is intended to be a "Panic" button. So, from a program I need to be able to trigger the Elk alarm police/burglar event from a THEN statement. On the EISY side I can see under Actions > Your Devices > both keypads. On the garage keypad (M1KPNAV) I get options for Query, Chime, Star, F1, F2, F3..F6. So I figured if I "actioned" the Garage Keypad F2 in a then statement it should activate the police alarm, but it does not. On my master bedroom keypad, which I tested F keys yesterday with the monitoring company, on the EISY side I only see query and chime options (it is a M1KP Elk keypad) I already take actions if the Elk alarm is triggered with other programs, but I don't have a way to actually command a police alarm. Thank you for any thoughts or ideas.

I have a scenario where I want my EISY to trigger a "panic" (24h burglary) event on my M1, so the monitoring company gets notified. It has been a long time since I set up my M1, but I am pretty certain I do not have any function keys programmed for panic on the keypads. I have two keypads, an M1KP and an M1KPNAV touchscreen. If I program one of the F keys on the keypads will I be able to trigger them through the PG3 Elk "devices" on the EISY? I can see that the F keys show up, but are the actions associated with them the same as pressing them IRL? The other option I considered was setting up a 24h burg zone, but I am out of zones on my M1. Thanks for any ideas or feedback.

I assume the Java applet is initially contacting or searching for "eisy.local" on port 8443. What is supposed to be doing the IP name resolution for eisy.local? Is it assumed that the local router will being doing the DNS resolution? In my router the name ID is "eisy", but all my clients are set to use 8.8.8.8 for name resolution. So, hard coding the name resolution in the host file is a bit of a hack, but it works. Should I be using a different friendly name ID for the device on my router?

I did the 5.5.9 upgrade and deleted all three java caches while it was upgrading. Once it came back online, I pulled down a new start file and IoX launcher. To my surprise, when IoX launcher came up after the upgrade it worked correctly and it found my EISY. I had tried upgrading in earlier versions and it didn't work, so I thought this was the fix. But then it asked me to do the reboot after the upgrade. About 20 min after the reboot I came back and launched the IoX Launcher and it had reverted to not being able to find the EISY. I opened it manually and all was well with the EISY, so I closed and reopened a few more times and sure enough, it wasn't working. So, I went to the troubleshooting wiki. I made sure my host name was the only thing registered to 127.0.0.1 and then I dumped cache, rebooted, reinstalled the start file, etc., but that did not make a difference. Since the IoX Launcher seemed to be looking for eisy.local I added that to my host file with the (DHCP) IP address of the EISY. Without flushing cache or downloading a new file I launched IoX Launcher and SUCCESS!!! It now works 100% of the time and it finds the EISY every time I launch IoX Launcher. I am not sure how the Java applet is working behind the scenes, but for some reason it cannot find or resolve the host name on my computer. For future travelers that have the same problem this might help you if the other steps fail to help.

I have had a similar problem with EISY and the IoX Launcher for the last few months. In my case, when I launch the IoX launcher the EISY is listed with the proper UUID and URL, but it has no type or version number. If I click it won't give me the option to launch the admin console, because technically it can't find it (??). As a work around, I can either manually add it (time consuming) or I've saved a file and I can just load it each time and it finds it right away (see two screen shots below). On the second "manual" entry I can launch the Admin Console without issue. I have unplugged it and left it off for 15+ minutes and deleted all three sets of Java temporary files a bunch of times and downloaded the new Start file and IoX launcher at least five times. Nothing seems to work, so I assume it is some setting in the EISY or an obscure network setting blocking the name resolution or scan. I am running Mac Ventura (although same issue under Monterey. I am running Java 8/321 and IoX 5.5.4 on the EISY. Thanks for any suggestions. On first launch: EISY info is correct, but it does not find it. After I manually enter the IP or load from file it works just fine.

EISY users are better looking, nicer, and more interesting. Happy Valentine's Day.

@gzahar that is the same behavior I observe. If I go into the customizations tab and then back to the programs it seems to be ok and the programs appear to execute the right thing regardless. I did delete my java cache/applications again and then reinstalled Admin Console and I see the same thing. So, somewhere the EISY must be saving the old customization names. It isn't local.

In my scenario, I had (no longer, so can't post it) a program X that was triggered by a momentary motion sensor. It had 4-5 lines of actions (no waits) then it was calling another program Y that would disable program X, wait ten minutes, then enable program X. The issue is that sometimes the program wouldn't get to the end of the THEN statement to fire off Program Y. I suspect it is because the motion went off before the THEN actions could finish and the program stopped. I've since moved 100% of the actions, along with the wait, into Program Y and all is good.

Did you enroll it in a free trial first? I had the same issue and found I had to enroll it in a trial first even though I was transferring a portal license from an old 994i.

I've got 49 Int variables and 18 state variables. After a migration from an 994i to Eisy I did some clean-up on the variables (deleted some) and added others in support of new programs. Over the last few weeks I notice that when I go into my programs some lines that reference variables are corrupt. New programs that reference new variables show an old variables name. Then in the program IF > Condition > Variable drop down the new variables do not show up, but either do the old variables. If I go into the variables tab everything looks clean with the old variables deleted and the new variables updated. I've tried to force updates to the variable table with multiple saves, additional adds/deletes, etc. but I still seem to get corrupt names. It only appears to corrupt with new variables that I've added. I am having a similar issue with notification customizations. My customization table looks clean under configuration, but when I go to edit my programs the notification customizations show up as "default" or sometimes by the customization number. I'm on IoX 5.5.4, on the desktop Admin console on a Mac. Is there a way to force a refresh of the variable table? Is there a corrupt cache somewhere I can delete? Thanks!

I believe that @MrBill is correct and that the THEN stops executing if the IF triggers change regardless of a wait statement. I have a program that does a lot of actions when motion fires and in extensive testing I notice that it doesn't always finish all of the actions. In my case it is sending notifications, executing other programs, and setting variables. Sometimes it will stop after sending me notifications, but before launching the other programs -- without any wait calls in the logic path. I tried to create a test program to capture the behavior with about ten lights and setting a state variable, but I am not fast enough on the state variable change to catch it. With more time this should be straight forward to test.

Thanks guys. These clarifications help a lot and I believe I have an understanding of the logic flow and I can code/configure around the behavior. It will force me to rethink some of my programs where the trigger could bounce a lot and/or where the trigger only lasts a few milliseconds. In the later case, it would be a risk to put a lot of actions into a then statement or actions that took longer to execute than the trigger condition takes to reset. It still seems to me that from an IoX design perspective the THEN logic should execute 100% once the IF conditions are met. If the triggers are reset and met again and again and again in succession then the whole of the THEN actions should fully execute over and over. I could see some rationale for stopping the THEN statement, like if I turned on a switch that then commanded ten lights to turn on -- if it was halfway turning on the lights and I turned the switch off the code would be justified to run the ELSE and command ten lights off. Is there any other design rationale I am missing that justifies stopping the THEN actions midway?

Yeah, this is really inconsistent behavior. I have a bunch of other programs that I've been running for 5+ years that use wait statements with Insteon motion sensors. I just double-checked the logic and in those programs and the if statement is not getting re-evaluated during the wait (see program below). Those motion sensors act similar in that they go on, but then quickly go off. Those programs turn on lights, wait ten minutes, then turn off lights. During the "wait 10 min" the if conditional is going negative because the motion sensor went off, but the lights always go off in ten minutes. Very reliable. Go figure... I just did some more testing and I found the easiest solution is to use a int variable in the conditional, but move the wait statement and the variable reset to a then statement in a second program (with an empty if conditional). The trigger program fires the Then statement in the wait program. I like your approach @vbphil of disabling the trigger program, but I'd be concerned if the power went out and the trigger program stayed disabled. Either way, it does seem like a hack to have to use two programs. I will be very wary of wait statements going forward.

Oh, yikes! That is good to know. I am not aware of any programming language that would re-evaluate the conditional once it dropped into the action, unless it was being treated like a while(X) instead of an if. I'll need to play with some small programs to see what works best for an anti-bounce timer. Thanks for the quick response @jwagner010