kclenden

Then I would classify the problem as a bug in the ISY coding. Perhaps the 'DarkSky / Forecast 0' Rain Today Inches value is a different precision and IF comparisons simply round the program constant to match the node precision. Or maybe this is only a problem when 'DarkSky / Forecast 0' Rain Today Inches is equal to 0 in which case maybe it's not really a 0 but a NULL value and the ISY doesn't handle that in its IF routines but does handle it during variable assignments. Whatever the underlying cause, it appears the ISY handles it correctly for variable assignments, but not for IF comparison.

Did it run false for values of 0.500 and greater? It seems like there is some funkiness going on with how the ISY handles comparisons between a node value and a program constant. What happens if you change your process and first set a variable to equal 'DarkSky / Forecast 0' Rain Today Inches and then use that variable in your program's IF statement?

You were a Z80 programmer? Me too. Still my favorite assembly language, but they say you never get over your first.

Nothing has changed. This was in their confidentiality request:

Not sure if you're still working this issue, but everything you've posted suggested that there is a communication problem between the ISY/PLM and the Balance Dimmer light. When you send a single device On/Off, I believe the PLM uses Insteon retries if it doesn't get an acknowledgement from the device. I know for certain that when you send scene On/Off, the PLM does not attempt any retries. And definitely device to device (e.g. switch to Balance Dimmer) communication uses retries. You should open the Event Viewer and set the level to 3 and then try having your program control the light, both as a single device and then as within a scene). That should give you some idea about what kind of communication is going on between the PLM and the Balance Dimmer.

In the "Family models declaration letter".

I don't think the IGs were listening. It's described as a 4-button KPL.

Do your home and cottage ISY's using a different path to the internet? Any chance that sending through comcast, gmail and att are using TLS and you haven't checked the TLS option on the ISY?

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.