apostolakisl

And yes, if no current flows to ground, then by definition there is no ground fault. But a device that has no conductive surface on it and isn't grounded via the electrical plug, has no path to ground fault no matter how screwed up it is.

Proof you are not aware and contributes nothing to anyones better understanding. I bow down to you ohh enlightened one. Perhaps you need to start your own website where only you answer the questions.

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.