kclenden

That seems like logical thinking. What ports are you using for SMTP. Most ISP's block some email ports. Here's an example: https://www.xfinity.com/support/articles/list-of-blocked-ports

Yep, that's what I suggested. ?

Well duh! Seems pretty obvious now that you say it. ? So I could get rid of four repeats: Bathroom Light Auto Off 2 - [ID 00B6][Parent 0001][Not Enabled] If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then Repeat 60 times Wait 1 second Set 'Inside / Hallway / Hallway Bathroom Light' Beep Repeat 1 times Set 'Inside / Hallway / Hallway Bathroom Light' Fast Off Set 'Inside / Hallway / Hallway Bathroom Light' Fast On Set 'Inside / Hallway / Hallway Bathroom Light' Fast Off Set 'Inside / Hallway / Hallway Bathroom Light' Fast On Wait 3 minutes Repeat 60 times Wait 1 second Set 'Inside / Hallway / Hallway Bathroom Light'' Beep Repeat 1 times Set 'Inside / Hallway / Hallway Bathroom Light' Off Else - No Actions - (To add one, press 'Action') Although doing it this way prevents you from canceling in between light blinks, but they happen pretty quickly so not really an issue.

They are the only way I could find to get out of the previous "Repeat", but they do have the added benefit of being a time slice surrender.

After evaluating all the feedback, if you still want to implement your two programs, here is what they would look like with my suggested changes, and a couple more: Bathroom Light Auto Off 1 - [ID 00B7][Parent 0001] If 'Inside / Hallway / Hallway Bathroom Light' is switched On Or 'Inside / Hallway / Hallway Bathroom Light'' is not switched Off Then Stop program 'Bathroom Light Auto Off 2' Set 'Inside / Hallway / Hallway Bathroom Light' On Wait 30 minutes Run Program 'Bathroom Light Auto Off 2' (Then Path) Else Stop program 'Bathroom Light Auto Off 2' Set 'Inside / Hallway / Hallway Bathroom Light' Off Bathroom Light Auto Off 2 - [ID 00B6][Parent 0001] If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then Repeat 60 times Wait 1 second Set 'Inside / Hallway / Hallway Bathroom Light' Beep Repeat 1 times Set 'Inside / Hallway / Hallway Bathroom Light' Fast Off Repeat 1 times Set 'Inside / Hallway / Hallway Bathroom Light' Fast On Repeat 1 times Set 'Inside / Hallway / Hallway Bathroom Light' Fast Off Repeat 1 times Set 'Inside / Hallway / Hallway Bathroom Light' Fast On Repeat 1 times Wait 3 minutes Repeat 60 times Wait 1 second Set 'Inside / Hallway / Hallway Bathroom Light' Beep Repeat 1 times Set 'Inside / Hallway / Hallway Bathroom Light' Off Else - No Actions - (To add one, press 'Action') I did find another bug in your original Program #2 - you didn't have a WAIT 1 SECOND during the second round of 60 beeps. I also used FAST OFF and FAST ON for the light blinking to avoid any local ramp rates that might be associated with the bathroom light. Finally, I avoided using a double tap because my guests have enough trouble with my paddle switches let alone learning to double tap. Also, I understand the need for all the "Repeat 1 times" after programming this myself. ?

The way the OP has written the program, I don't think simply pressing the ON again would cancel the waits in Program #2. It would restart Program #1, but it wouldn't stop Program #2. Certainly not before the 60 seconds of beeping ended because pressing ON will make the status of the light ON which is what the second program evaluates in its IF and going from ON to ON doesn't retrigger a program that is looking at STATUS.

Before restoring the PLM, I generally like to look at its Link Table. Goto Tools->Diagnostics->Show PLM Links Table. When the "PLM Links Table" window appears, click "Start". Generally speaking, you should expect to see at least twice as many rows in the table as Insteon devices you have. If you have a lot of scenes or Keypads, it could be quite a bit more than twice as many. Once the process of listing the rows is done, you can click "Save" to save a copy for later diagnosis if need be. If the table that is displayed is empty, or has a lot fewer rows than twice as many, then you are definitely a candidate for restoring your PLM. Losing links in the PLM can be caused by a one-time incident, or could be a sign that your PLM is dying.

I'm confused by things you currently have in both programs. First Program #1 - why do you check for the "switched Off" condition. If the light is switched off, there's no reason to run the 30 minute wait. Now Program #2 - does it even work as is? I ask because the IF condition looks at the status of "Inside / Hallway / Hallway Bathroom Light" and then you change that status within the THEN. The first time you set the status to "Off" and then hit a WAIT or REPEAT the program should reevaluate the IF and execute the ELSE because the status is now OFF. So I can see it beeping 60 times, but does it actually blink the light? If you want to implement exactly what you specified above (beeping but no blinking), you simply take out all the blinking code from Program #2 and add a "Set 'Inside / Hallway / Hallway Bathroom Light' On" and "Stop program 'Hallway Bathroom Light Auto Off 2'" as the first two lines of Program #1 THEN. That way after Program #1 has handed off to Program #2, Program #1 will take control again if the person in the bathroom touches the light switch in any way. If you want to be able to blink the light, then I think you'll need to get rid of the IF condition for Program #2. This would also mean that you need to get rid of the check for "switched Off" in Program #1 as you won't be checking the status before running Program #2 and you would end up with beeping and blinking 30 minutes after someone turned Off the light. Getting rid of the check for "switched Off" would mean the person in the bathroom would need to flip the switch ON to keep the light On. Since you'd be getting rid of the IF condition in Program #2, in Program #1 you'd want to execute the THEN section of Program #2 instead of the IF. Finally, perhaps you want the person to be able to stop the beeping and blinking because they are leaving the bathroom and want to turn Off the light. In that case, instead of getting rid of the "switched Off" in the IF of Program #1, you would change it to "not switched Off". That would mean that if the person actually did flip the switch Off, the ELSE of Program #1 would run, so you'd want to also put the "Stop program 'Hallway Bathroom Light Auto Off 2'" line in the ELSE of Program #1.

Ding, ding, ding! That's what I meant to say.

All depends on how ISY implemented the queue that monitors programs that are waiting. If they simply set up a table with a pointer to the next line of code to execute and the numbers of seconds to wait (which they would then decrement every second) then it should work just fine through DST change. If they set up a table with a pointer to the next line of code to execute, and an actual "time to resume", then that would fail during a DST. Killing all waiting programs would be an ugly way to handle DST changes. Pretty much all they'd have to do is add an hour to the "time to resume" for all waiting programs during Spring Forward and subtract an hour during Fall Back. For efficiency sake, if I had been programming the ISY, I would have chosen to save the actual time to resume so that I didn't have a maintenance task that ran every second.

All of my heartbeat checking programs, which use 26 hour waits, were killed this morning. So my experience agrees with apostolakisl's statement that DST clock kills all waits.

Besides what larryllix said, there's another reason "$.Top_of_Hour Init to $.Top_of_Hour" wouldn't trigger programs waiting for a change of that variable. It's because assigning the same value to a state variable isn't considered changing it and won't act as a trigger. For example, if $.Top_of_Hour contains the value 10 and sometime later a program executes "$.Top_of_Hour = 10", that won't trigger any programs because the value of $.Top_of_Hour" hasn't actually been changed.

Couldn't you just put in a KeypadLinc and link its buttons with the IOLinc? The A button could be a simple ON/OFF and then the other buttons could be configured as ON Only so they send an ON to the IOLinc while the ISY sees their ON and starts a timer, whose length is based on which button was pressed, and at the end the ISY signals an OFF to the IOLinc.

The answer is yes, and ironically that is what both of your programs are doing. In the first program you flash a KPL button LED by turning a scene on and off. In the second, you check the status of a KPL button LED to decide whether you should turn off the basement lights. Neither of the programs actually look at the action of the KPL button. To do that, you use CONTROL instead of STATUS. CONTROL is a one-time event. The device sends a command, usually either ON or OFF. It is an event that signals that something happened locally at the device (e.g. somone pressing a button or the device sending a hearbeat). When you remotely control the device it does not send out CONTROL commands. STATUS is a state not an event. The device remains in that state until changed to another state either by something that happens locally at the device or a remote command. When you check the STATUS of a device within a program, it only triggers your program to run whenever the state of the device changes to the state you specify. So for example, your second program only runs when KPL 8 H changes from ON to OFF. When that happens, you don't know if it was because someone pressed the button, or whether the state was changed remotely, for example by your first program. What's important is that It doesn't keep triggering your program all the time the status remains OFF. If I understand what you're trying to accomplish, I would change the IF in your second program to 'KPL 8 H' is swtiched On Or 'KPL 8 H' is swtiched Off and then add the following to the end of the THEN Set 'KPL 8 - H Basement Lights' Off The reason to check for both switched On and switched Off is because your first program changes the state of the KPL 8 - H button LED and while that doesn't send out any commands it does change what command the KPL 8 - H button will send when you press it. If you press it when it is illuminated, it will send an OFF command, and if you press it when it's not illuminated it will send an ON. Since you can't know at what point during the blinking the button will be pressed, you need to check for both. Likewise, since you can't know whether the button is going to be pressed when it's illuminated or not illuminated, in the THEN you need to go ahead and turn the button's LED off just in case it was pressed when it wasn't illuminated (and thus the actual pressing of the button causes the LED to illuminate).

Those are not acknowledgments from the devices, they are just the ISY noting that the state of the devices has changed as the result of the scene command it has just sent. It all happens internally to the ISY and shouldn't take much time. I hadn't considered that the ISY logs all state changes, and thus has to write each state change to the SD card which takes some amount of time (but certainly not 20-30 seconds), especially if you're having a problem with the SD card as pointed out by larryllix. All of the bolded lines represent communication into or out of the ISY. The lines that end in 14 00 or 12 00 are commands from the ISY to the PLM. the lines that end in 14 00 06 or 12 00 06 are acknowledgments from the PLM to the ISY that it transmitted the requested command. If you try your blink test with a larger number of devices, you should still only see two communication lines before each group of state changes.

That's interesting. My understanding is that the ISY sends only one command (and does not expect acknowledgments) no matter how many devices are included in a scene so adding or subtracting devices from the scene should, in theory, have no impact on how long it takes for the scene to execute. The only thing that should be controlling how long the scene takes to execute is the ramp rate, and as larryllix suggested, using FASTON and FASTOFF will take care of that. I'd be interested in seeing the output from the Event Viewer set to Level 3 when you execute your blink test. Is it possible that you have other programs that are set to monitor the STATUS of some of the devices that are being controlled by your blink scene? If so, then the change of status caused by the SCENE command could be kicking off a bunch of other programs.

Likewise, enabling a folder doesn't cause any of its programs to begin execution. Only the program's actual conditions cause them to execute. Using your programs above as an example, lets say you leave the house at sunset and arm the alarm on the way out. All of the folder programs are now enabled, but they won't start just because the folder was enabled. The "Downstairs Hallway Lights" program won't start running when you leave because its start condition, "Sunset - 1 hour", will have already passed by the time you arm the alarm at sunset. Just something you need to be aware of when creating conditions for the programs within a folder.

Could it be a timing issue? Maybe when your program runs at startup before the ISY has connected to the occupancy node server? Have you tried putting a WAIT in your statup program before querying the node?

This is from the ISY 994i manual (July 11, 2018 V4.6.2) - hope it helps: Also from the manual:

I don't have any Zwave either, but I thought some of the v16 reports were about Insteon open/close sensor of which I have a couple.

Thanks. That is odd. I was expecting to see an "Options" button because I faintly remember using it under V4. I don't have an "Options" button on any of the button pages either. I just checked and my Firmware and UI versions match. I haven't upgraded to V5.0.16 because of some of the bug reports, but I guess I'll do it to see if it gives me the "Options" button.

Well that is interesting. I don't see an "Options" button on the bottom of the page for any of my keypads. I'm using version 5.0.15A of the Admin Console. What version are you using? Here are the buttons that I see:

Sounds like the button is in "Toggle" mode. If you change it to "Always On", using the "Buttons Toggle Mode", perhaps it will work as desired. Then set the button you want to use to make it go down to "Always Off". The KeypadLinc manual references the ability to use software to lockout local programming, but I don't see anything in the Admin Console that allows you to do this. Maybe another forum member knows if the ISY has a way to do this.

A couple things... Based on the copy & paste, you haven't yet set "Start Top Of Hour Clock" to "Run At Startup". In the "Note Top Of Hour" program, I would get rid of the "$.Top_of_Hour > 0" condition and simply put a "Run Program "Note Top Of Hour' (Then)" as the last line after "$.Top_of_Hour += 1". To me that would be more efficient. Your "$.Top_of_Hour" variable not only denotes each new top of hour, but effectively becomes a count of the number of hours your ISY has been continuously running, with the exception that the first hour could have been anywhere from 0-60 minutes. So you may as well save it's value into static memory and report the value via the email sent out in the "Start Top Of Hour Clock" program. As far as the efficiency of a "Wait 20 Seconds" versus a "Wait 1 Hour", the real savings comes in the reduction of lines of code that are being run. There are 180 twenty second intervals in an hour, so by using the "Wait 1 Hour" you're reducing the number of lines of code executed by a factor of 180. Here are the programs with my suggestions: Start Top of Hour Clock - [ID 000A][Parent 000D][Run at startup] If // No need for an IF clause, the THEN clause must be set to // auto start on startup of ISY, i.e. reboot. Then // Notification for courtesy that ISY has rebooted // Then start a loop in 'Find First Top of Hour' program to // find when minutes are zero Send Notification to 'MY_GROUP' content 'ISY_REBOOTED.NTF' $Minutes_of_Hour = [Current Minute ] // Reset Top_of_Hour after reporting it via Email // Initializing it to 0, will allow it to mark the number of hours // since reboot. $.Top_of_Hour = 0 // Save Top_of_Hour to permanent memory $.Top_of_Hour Init to $.Top_of_Hour Run Program 'Find First Top of Hour' (If) Else - No Actions - (To add one, press 'Action') Find First Top of Hour - [ID 000C][Parent 000D] If // With the ELSE clause, this forms a loop until the first // Top of Hour is found after an ISY reboot. $Minutes_of_Hour is 0 Then // The first Top of Hour is found // Trigger that with an increment to .Top_of_Hour $.Top_of_Hour += 1 Run Program 'Note Top of Hour' (Then) Else // Wait 20 seconds between each test of the minutes on the clock Wait 20 seconds $Minutes_of_Hour = [Current Minute ] Run Program 'Find First Top of Hour' (If) Note Top of Hour - [ID 000B][Parent 000D] If Then // Wait one hour before retriggering the THEN clause above. // Other programs testing the state variable .Top_of_Hour // will also be tiggered at each top of hour. Wait 1 hour $.Top_of_Hour += 1 $.Top_of_Hour Init to $.Top_of_Hour Run Program 'Note Top Of Hour' (Then) Else - No Actions - (To add one, press 'Action')

No. A program can exist without an IF clause, but it won't start unless you manually start it, another program starts it, or you have it set to "run at startup" and the ISY starts up (i.e. is rebooted). To start by itself, a program must have a trigger in its IF clause. Pretty much anything you can put in the IF clause will be a trigger with the exception of integer variables. When you put a state variable in an IF clause, it will only act as a trigger when its value changes. So for example if you had a program like "IF ProgRunning is 0 Then do stuff", that program would only run when ProgRunning was some other value and then became 0. So if ProgRunning is set to 0 at startup, that program wouldn't run at startup because the value was already 0. Those program restarted themselves because Time Of Day is a trigger. So when when the ISY rebooted, it watched those programs until the specified time of day arrived and the ISY started the program. The existing program that you displayed in your original post would also have eventually restarted itself after the power failure, but not until 8:00 AM. Your question was how to make the top of the hour a trigger, which if used in your original program, would have restarted it at the next top of the hour instead of waiting until the next 8:00 AM to roll around.