kclenden

I don't think the issue is validating more than one set of credentials. It's more likely the necessity of defining a security structure and then building it. First you have to define what levels of access are going to exist, then define which devices and actions fall under which access levels, and then create a structure and methodology to enforce the different levels. Sure, based on what you're asking for, you could probably just create two levels (one with total control and another that lets you do everything but program) but you effectively already have that based on whether you're using the Admin Console or just web access. More likely, even with just two levels of security, you'd want the ability to assign devices and scenes to either the ANY (anyone can control) or ADMIN ONLY (only Admin can control) level. To do that, you'd have to modify the UI, and underlying ISY operating system. You'd have to review every possible usecase and decide how security should handle it (e.g. should an ADMIN ONLY device be allowed to exist in a scene with an ANY device?) And even after doing that, you'd be left with a kludge since Insteon doesn't support different levels of security, so even just having the lowest security level (ANY) would give you a theoretical avenue to controlling ADMIN ONLY devices that you're not supposed to be able to control.

@larryllix You may be right, but your test is not an apples to apples test. Your test uses two variables for which the ISY knows everything because it created them. The OP is using a node that was not created by the ISY and comparing it to precision represented by trailing zeros after the decimal point. I can easily see why the ISY would handle your variables differently than it handles the OP's comparison. A problem with that conclusion is that the OP says that if the node value is first put into a variable, and then the variable is used in the IF the programs run correctly. The ISY seem to be able to understand the node value well enough to put it into a variable, but not understand it well enough to use the node in a direct comparison. One possible explanation for that is that the ISY takes a zero (whose precision it doesn't fully know) and forces it into the precision of the variable it is being assigned to, while doing something different when using the node in a direct IF comparison. I'm sure there are other explanations, but only @Michel Kohanim or @Chris Jahn can tell us.

That might indicate that the ISY is rounding the IF conditions "i.e. 0.400" to the precision shown by the node (i.e. 0). Mathematically, probably the correct thing to do since you can't infer more precision than is present, but not what one might expect based on common sense. What happens if you add an additional check to the IF to make sure the node isn't 0? Like so: AA Weather Test - [ID 004C][Parent 0254] If 'PolyGlot / WeatherPoly_Acuparse / WeatherPoly / Precipitation' Daily Rainfall >= 0.400 Inches And 'PolyGlot / WeatherPoly_Acuparse / WeatherPoly / Precipitation' Daily Rainfall < 0.550 Inches And 'PolyGlot / WeatherPoly_Acuparse / WeatherPoly / Precipitation' Daily Rainfall is not 0 Inches Then - No Actions - (To add one, press 'Action') Else - No Actions - (To add one, press 'Action') @Michel Kohanim can you explain how the ISY deals with precision differences between different components of an IF comparison?

I applaud your diligence in trying to run down unexpected results before submitting a bug report. I see two problems with this approach though: Let's say you factory reset and reload everything and now the programs work. What has that done? It's left you with a working system that you can't trust because you don't know what caused the original problem or when the problem might come back. Additionally you've removed any evidence that UDI might have been able to collect to determine the root of the problem. Your time is worth something. If you've narrowed down the problem to something that you can repeatedly duplicate then why not notify UDI to see if they can duplicate it on their system? Either they do, in which case you'd have been wasting your own time resetting and reloading everything, or they don't in, which case they might want to look at your system while it's still in a state that you can repeatedly demonstrate the problem. I'm not saying your way is wrong, but I'm saying it's right either. ?

But his original programs didn't use a variable in their IF statements. They made comparisons directly to 'DarkSky / Forecast 0' Rain Today Inches. So there could be no unknown interactions causing a program to run TRUE when it should have run FALSE. In an earlier post, he indicated that he checked the "Last Run Time" of the programs after his tests which would tell him if one of them might possibly have affected the test variable. And finally, all of his programs set the variable equal to 'DarkSky / Forecast 0' Rain Today Inches. So even if they had run inadvertently, he would still be seeing the value his wanted to see. Your suggestions for more testing would certainly arrive at a more definitive conclusion, but I don't think they are necessary for before he submits a bug report to UDI.

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?

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.

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.