kclenden

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.

There has to be a list, even if it's just a list of programs. Whether there's an index by time, though, is another question. ?

That's why I wrote the program the way I did. You only have a repeating counter for at most the first 60 minutes of ISY uptime. After that the repeating counter stops and you're left with the next program that only triggers once an hour. I'm guessing that it's way more efficient than that. There's probably a sorted time queue that any program in a WAIT state, or with a TIME trigger gets put on. That way, only the very first program has to be checked every second. If it's not time to trigger the first program then you know it's not time to trigger any program with a later time.

Seems like your program runs the way you want it to once it's started, so all you need is an automated startup. To do that you could create a simple program that uses the Current Minute in some way to signal that your existing program should start. So how about: StartHourlyProg Init - [ID 00B4][Parent 0001][Run At Startup] If $iProgRunning is 0 Then Run Program 'Prog Init' (If) Else Wait 60 seconds $iProgRunning = [Current Minute ] $iProgRunning *= -1 Run Program 'StartHourlyProg Init' (If) with a slight modification to your existing program: Prog Init - [ID 00A2][Parent 0001] If ( $iProgRunning is 0 ) Or ( Time is Last Run Time for 'Prog Init' + 1 hour And $iProgRunning > 0 ) Then $iProgRunning += 1 // Execute Stuff Else - No Actions - (To add one, press 'Action') These two programs depend on your ProgRunning variable (my $iProgRunning variable) being an integer variable (or more specifically not a state variable), and you having its INIT value set to -1 so that when your ISY reboots the variable is initialized to a -1 (or more specifically not 0). It also depends on the "StartHourlyProg Init" program being set to run at startup. When your ISY reboots, "StartHourlyProg Init" will run and with $iProgRunning being initialized to -1 it will run its ELSE. That will set $iProgRunning to the current minute times -1. This will result in a value from 0 to -59. As a final step, "StartHourlyProg Init" will run its own IF. This continues until the current minute is 0 at which point the THEN will be run which executes the IF of "Prog Init" and then ceases execution of "StartHourlyProg Init". The "Wait 60 seconds" is in the ELSE so that the program doesn't take over your ISY, starving other programs of time, until the current minute is 0.

Interesting. I'm using V5 (but admittedly only 5.0.15A) and "Copy to Clipboard" works for me. I get all the programs and folders beneath "My Programs".

The #1 thing I would suggest is to make a text copy of all your programs and folders. Having a backup allows you to go back to what you had before, but it doesn't help you debug what you see in V5, while a text copy of your V4 programs does. To make the text copy, right click on the very top folder of your "Programs" tree (in my case "My Programs") and choose "Copy to Clipboard". Then open an editor, like Notepad, and select "paste". Now you have a text copy of all your programs and folders, as well as their specific settings (e.g. folder conditions, run at startup, disabled). Now when you're debugging in V5 you'll be able to see exactly how a program was setup in V4. Here are several examples: A program that was set to run at startup: ISY Uptime - [ID 008E][Parent 0077][Run At Startup] A program that was disabled: Z10-DR-Chandelier - [ID 0004][Parent 0001][Not Enabled] Generally speaking, the most common things that people complain about the transition from V4 to V5 are programs that were disabled becoming enabled, programs that were set to run at startup no longer running at startup, and a couple Zwave oddities that I don't recall because I don't have any Zwave devices. Your text copy of your programs will allow you to deal with the first two most common complaints.

At their very basic, Insteon scenes are a relationship between one controller and one or more responders. For each device activated by that controller, you define the desired ON value and Ramp Rate. This allows you to send out one command, scene ON or scene OFF, and have many devices be activated at the same time. With the ISY, a scene can have many controllers, but at the low level it's still a bunch of one controller to multiple responder scenes. So in your programs, you need to specify the scene, controller and device to adjust ON and Ramp Rate. You might think, but I have only one controller in my scene - the Motion Sensor - so why should I have to specify the controller? That's because you really have two controllers in your scene - the motion sensor and the ISY. To set what happens when the scene is activated by the ISY the scene name and controller name will always be the same. I don't remember whether the ISY tried to write scene updates to the MS's in V4, but you're not the first one to have this recollection, so you're probably right. It is normal in V5 though. If your MS's are battery operated, you really should update your scene change program to only run when the MS is awake. This will prevent a host of possible undesirable consequences later, but is problematic as your MS's probably won't be awke at the time you want to change your scene, and really the only way to know your MS is awake is to wait until it sends out an ON or OFF command.

In which case, I start to wonder if it is even worth automating. I might argue that it's the rare case that is most worth automating because you are most likely to not check for it manually. Both of my switches are only acted upon by my "All Off" keypad button that we hit on the way out the door. So programs will only change the state of these switches if they are in the ON state when the "All Off" button is pushed. That doesn't happen very often because my wife and I are very good at turning the lights OFF when we leave those rooms. It generally only happens when we have guests over and they venture into one of these rooms and exit without turning the light OFF.

Yep. That scenario would require me to flip the switch UP and then DOWN again to actually turn the light OFF. Both modes will result in the switch being out of sync if a program or scene acts on the device. In the 3-way mode my switch will be out of sync until a program or scene again acts upon the device, nothing I do at the switch will get it back in synch, but with the 3-way mode disabled the switch is back in sync as soon as I use the physical switch again. In the case of both switches, they are acted upon by a program or scene probably less than 2% of the time, so the way I have them set up means they'll be in sync the vast majority of the time whereas having them in 3-way mode would result in them being in sync for long periods of time followed by them being out of sync for long periods of time.

That's how my switches are programmed. They come programmed for latching mode by default. They also come programmed for 3-way toggle mode by default whereby they act like they're in a multi-switch setup. I turn the 3-way toggle mode off so that the switch being UP means ON and the switch being down means OFF.

Doesn't really seem like a feature request to me. Seems way too simple to be considered a feature. Not really a bug either since the FASTOFF being sent seems to be undocumented.