apostolakisl

There is a clear history of GFCI breakers nuisance tripping due to fluorescent lights ,tread mills, tools etc. I do believe that your statement makes point that "all kinds of things make noise". As per your generalization, all kinds of other things apparently do make noise ("fluorescent lights ,tread mills, tools, etc."). Enough noise, in fact, per you, to pop some GFCI's. And enough amplitude to bury the Insteon 3.2vpp message per the fact that that is just a fact. Fortunately i don't own any of those "well known" gfci's. I suppose these would not be very good gfci's since these things would not put a differential current across the neutral/hot differential coil. Some of those things aren't even grounded so there wouldn't even be a path for a ground fault. A poorly designed gfci controller would be to blame if noise on the power line caused it to erroneously open the circuit. No ground fault actually occurs and the differential coil that compares the hot/neutral could not actually read a potential if there is no actual ground fault. The differential coil is a very simple thing that works on a very simple principle and I don't see that it would be possible to "trick" it. If current of any amplitude and any frequency is matched on both sides (which is the only possibility if no ground fault exists), then no potential can be made on the coil. If an insteon device is causing a GFCI to pop, then, as you mentioned, many other things would as well, and that would be a good brand of gfci to avoid. Since all GFCI's don't pop under the same circumstance, then it follows that it must be a poorly designed gfci controller activating the solenoid in the absence of a ground fault. But in short, if the only thing you have in your house that pops the gfci mistakenly is an x10 device, or an Insteon device, I would be inclined to blame the x10 or Insteon device as actually having a ground fault. But maybe your house just doesn't have any of the things you listed that also could erroneously pop gfci's. I would also ask that **-hole statements like "do you even know how a GFCI works" should be left at home.

If it is intermittent, then there is a good chance it is a communication issue. Especially if the log says the program ran. Is every device in the scene not turning off or just some of them? If it is just some of them, then you for sure have a comm issue.

Many electronic devices produce noise at the same frequency that insteon and x10 operate. This is the entire purpose of the noise filters that we so often have to buy. This is how x10 devices can turn on/off without any proper source of an x10 signal. Some transformers/ballasts are very noisy in that range, yet you don't see GFCI breakers popping when you plug a noisy fluorescent light in. GFCI breakers would be going popping all the time if all it took was stuff happening in the 131khz area regardless of whether you have Insteon/x10 in your house at all.

There are posts in here somewhere describing doing what you are doing with variables. But basically it is something like this: If $i.3scenes = 0 And Control kpl is switched on Then set scene x on set $i.3scenes = 1 If $i.3scenes = 1 And Control kpl is switched on Then set scene y on set $i.3scenes =2 If $i.3scenes = 2 And control kpl is switched on Then set scene y off set $i.3scenes = 0 You need to change the kpl button settings to always turn "on" with a button press. Of course your 3rd option then will have trouble. You can use your programs to turn the button on or off even when set to always turn on with a press but there will be a delay. For example, if you have the kpl button always set to turn on with a press, and you get to your 3rd press where a program shuts things off, when you press the button, the program will trigger, but it will take a second or two before the program executes and everything shuts off (the entire scene which I would include the kpl button in).

Michel, Kind of blurring together two threads, but this is what I am talking about. This user might have been reminded of what the triggers were if things were color coded.

The notification substitution variables wiki page is not complete. Somehow some people knew that you can put "sys.program.#.enable" and get the enabled/disabled status of a program. Also there are tons of things in the drop down menus that are not on the wiki. And a lot of things in the drop down menu aren't self explanatory, so it would be nice to have the wiki outline what each does. And I also wonder if there are other things that are not in the drop down menu or on the wiki page that I could put besides sys.program.#.enable

If it can be done at all, I would expect ${sys.var.1.1.name}

Yes, in notification email settings.After hitting add variable this appears in the body ${var.1.91}. How did you modify that line to show the variable Name in the email/text? Just delete type it in manually ${sys.program.name} Or delete the var.1.91 and replace it.

I figured there was a conversion somewhere. As for the return, yes mine has them just fine. It is likely lost in the cut/paste process from the forums. I actually created an excel sheet to do all the numbers, and then copied those rows directly into the notification email. The email I got was 1 line per program. For the forums I copied it from the program and into here. I pasted it into MS word and turned on the feature that shows all hidden characters. What I got from you was line breaks at the end of each line and a paragraph break at the end. Both line breaks and paragraph breaks had to be deleted for it to work. Even if I manually typed it in with a "return" it simply didn't work. I don't get how you can do it but I can't.

For some reason I can't get that to work. The carriage returns are screwing it up. If I delete the carriage returns it works. Are you able to have it send with carriage returns? I guess I'll have to go through and delete all of them? EDIT: I used MS word to replace all the line breaks with a "*". Then after I got the email I did the process in reverse putting line breaks back in. So I'm good now. But I don't understand how yours works with the line breaks in place and mine doesn't. EDIT AGAIN: If you just convert the hex value on the program summary page to integer it works fine without having to do that gigantic email For example, 001B is program 27.

Thanks. I don't know why the wiki does not include all of the custom notification variable subs. I am curious as to what else can be subbed in that I don't know about.

If all you are looking for is a daily email with the enabled state of a program, just make a daily notification program. The customized notification text would have something like: ${sys.program.#.enabled} ${sys.program.#.name} y Replace the # with the number of your program. I would also include the Name in there until you are sure you have the right program, as this is a number and I don't think adding the letters in from the ID works. Also note with this, you'll recieve either a True or a False for the enabled status. I don't think you can not send the email if it is false unless you get deeper than I am with network resources and do some trickery there. 2 questions. 1) Where did you get those variable substitutions. This is all that is on the wiki. http://wiki.universal-devices.com/index ... _Variables 2) on my system it is only working on programs with decimal ID. In other words, 001B does not work, but 0012 does

The only way I can think of to test the enabled status of a program is to include something in the If of that program that is a trigger event and use the other program to create a trigger event for the first program. Then that program would trigger an email from the else clause only if it is enabled. If it weren't enable you would get no notification. If Time is whenever you want to irrigate and state.variable.a = 1 Then irrigate Else notify . . . If time is whenever you want to be notified Then state.variable.a = 0 state.variable.a = 1 optionally add a notify here to remind you that if you don't get a notify from your irrigation program that it must be disabled. Unfortunately this will send 2 notifications, but that is all I can think of right now.

The washer should be easy since the pauses are short and the machine shuts off completely when the cycle is over. You might have more issues with the dryer since it is gas. You won't be able to set the threshold high enough to only recognize the heat elements. You need it to recognize the drum turning motor. You would want the notification to occur the first time the drum stops turning. But then it will trigger again like it is a new load when the drum turns for the wrinkle guard. The key I think here would be to have it not send a notification until it has been on for a period of time that exceed the wrinkle guard run time. Lets say wrinkle gaurd runs for 30 seconds. If status synchrolinc is on Then wait 40 seconds enable program 2 Program 2 If status synchrolinc is off Then notify disable program 2 I believe this should solve the problem. You will need to manually disable program 2 the first time you do this. After that it will disable itself. EDIT: I just checked out the synchrolinc page at SH, and it looks like it has a built-in delay on it. That may solve your issue right there, unless the wrinkle guard runs longer than the 38 second max delay time. I thought it might be nice for my house as well, but I have a 240 dryer which would complicate matters seeing as synchrolinc is 120.

IF from time a to time b Then set light on Else wait 30 minutes random set light off The above turns lights on at time a and off at time b plus 0 to 30 minutes at random.

For what its worth, I have used Insteon appliance links and lamp lincs on GFCI plugs inside my home without issue. The GFCI outlets are 4 years old. I assume the x10 modules were popping the gfci because they were allowing some current to go to ground. x10 or Insteon signals themselves should not affect gfci. All kinds of things produce noise in the same frequency area as Insteon/x10 produce their "meaningful noise" and I have never plugged anything into a gfci breaker that popped it no matter how old the breaker or how old the device unless it was leaking current to ground. I have had lots of issues with my outdoor gfci's popping when things get even the slightest bit wet. Very annoying!!!

I only think that this would be necessary if the washer/dryer for some reason consumed power intermittently when not in use. I don't think they do this, but there are lots of brands with lot of different ways they function. I do know that the amount of power consumed while in use goes up and down by a lot depending on what cycle and if it is in one of the short pauses between cycles. Perhaps all of these issues can be rectified by simply fine tuning the power threshold that synchrolink sees as "on" or "off".

You might put a wait in there because of pauses between cycles. This may or may not be necessary depending on how much power the washer draws while it pauses between cycles. If status synchrolinc is off Then wait 30 seconds notify In this example, the synchrolinc would have to be off for 30 continuous seconds before it sends the notify. If it were to turn back on before the 30 seconds, it would never send the notify. The next time it shuts off for 30 continuous seconds it would send.

No. But if you used the "then" section of program 2 and put Then Wait x minutes Set bathroom fan off it would.

http://wiki.universal-devices.com/index ... _Variables

Perhaps you didn't put in the "not" IF status bathroom light is NOT off

You don't need any variables for this. If status bathroom light if not off Then wait 5 minutes set bathroom fan on Else blank The above program will turn the fan on if the bathroom light is on for 5 continuous minutes. The fan will run until manually turned off. If you want the fan to shut off automatically: If status bathroom light is not off Then wait 5 minutes run program 2 "else" clause Else blank Program 2 If control bathroom fan is switched on Then -blank Else set bathroom fan on wait 10 minutes set bathroom fan off The above 2 programs will turn the fan on after 5 minutes and run it for 10 minutes. If you click the "on" paddle of the fan switch it will abort the timer and the fan will keep running until manually turned off. Also if you turn the light off then back on it will reset the whole process.

I had just opened a program from the programs tree. In the "program content" box, I clicked on a line of the program to which I wanted to make a change. I believe it was a "wait 1 second" that I was changing. I changed the "1" to a "2" in the "action" box at the bottom of the screen and hit "update". At this time, the "program content" box did NOT change the "1" to a "2". However, the green arrow in the programs tree box DID put an arrow next to the program, despite not having actually made any change. Because the green arrow popped up, I know that it was not a failure to click "update". When I hit "update" a second time, it did post the change. This is one example where I know the details because I was watching carefully. However, I have had several times where I wasn't watching the "program content" box as carefully and did not notice if the change had actually posted. In those instances I had gone ahead and hit "save" and then was surprised when the program didn't work. Then I went back and saw that the changes I thought I had made weren't there. At the time, I chalked it up to an error on my part. However, I now suspect it was not an error on my part after this most recent event. In this most recent event I was watching very carefully as I hit "update" and saw that nothing changed in the "program content" box but did see that the green arrow popped up simultaneously to me hitting "update". So I know that it was not a failure to hit "update" properly. When I hit "update" a second time (just clicked the left button again, this is a laptop so the arrow didn't move even a tiny bit) the change did register. EDIT: I just updated to 4.1.0 today. I don't have any programming changes to make right now to see if this problem persists. Maybe I am can think of some stuff to change just for the heck of it.

This version really seems to work. If Control 'Back Hall / Back Hall Ext Door-Breezway' is not switched On = = = This forces a false (abort timer)with a click of the "on" And ( ( Elk Zone 'Back Door' is Violated = = = These 3 lines always runs a true if the light is off and the door opens at night And Status 'Garage / Third Garage-Breez L' is Off And Program 'Dark Outside' is True ) Or ( Program 'back door' is True = = = These 2 cause the timer to start over on any trigger when already running (see last line of "then") And Status 'Garage / Third Garage-Breez L' is not Off = = = except because of a status change to off ( allows manual turning it off) ) ) Then Set Scene 'Breezway S' On Wait 5 minutes Repeat 15 times Set 'Back Hall / Back Hall Ext Door-Breezway' 250 (Beep Duration) Wait 2 seconds Repeat 1 times Set Scene 'Breezway S' Off Run Program 'back door' (Else Path) = = = This causes the program to be listed as "false" except when it is actively running Else - No Actions - (To add one, press 'Action') The above program always terminates when I hit the "on" paddle of "back hall exit door breezway". So I can always abort the timer if I realize I need some time with the light on to do something after the timer gets going. It always runs false when it is not dark outside so it has no affect on manual operation during the day. It always runs false with manual control at night if the program isn't already running, so manual operation at night without having opened the door isn't affected. It only runs the program if it is after dark and if the light is off to start with. So if you had manually turned the light on for a reason (doing something out there), opening the door is not going to start the timer and shut your light off on you after 5 minutes while your in the middle of something. All of the items that are triggers will reset the timer if it is already running, except for turning the light off or clicking the on paddle of the one switch. So if you keep going in and out of the door, the timer keeps resetting. The timer will also reset at the time the dark outside program changes from true to false (in the am), this is maybe not perfect as you would probably just want the light to turn off when it becomes light out, but at least it doesn't abort the timer and leave the light on all day. The only "weird" thing about this program is that if you change the status manually to anything but off (dim the lights) while the program is already running, it will restart the the "then" which causes the light to go back to full on.

I don't exactly understand the architecture of java, but I assume there is a local file that java is saving all the work in progress and then when I hit "save" it transfers to ISY. It is the updates to the local file that appear to be missing sometimes. The "saves" to ISY do accurately save whatever is in the upper pane, it is just that what is in that upper pane is not necessarily what I thought it was. I do know for certain that the local Java session recognized that I hit update because in the last instance, this was the first update I did to that program. And it registered in the program tree that a change had occurred and needed to be updated to ISY (the green arrow popped up). Except no change actually had occurred. When I hit "update" a second time, then it did update. So, I don't think it has anything to do with ISY/local machine comm (ie firewall issue) since "saves" seem to always accurately transfer what is showing on my screen to ISY. But like I said, the java thing is not necessarily properly understood by me. I did recently switch to windows 7 pro from xp pro, so I don't know if that has anything to do with it.