apostolakisl

I have had another documented issue that I believe is this same problem. The following program was running with every query of the device, even though the status was off before and after the query. If Status 'Downstairs Washer' is Off Then Wait 1 minute Send Notification to 'lou gmail' content 'Laundry Downstairs' Set Elk Speak Word '_Custom1' Else - No Actions - (To add one, press 'Action') I didn't get it, it shouldn't trigger on a query if the status didn't change. Then I noticed that when I clicked on the " Status 'Downstairs Washer' is Off" in the program, the working section at the bottom showed it as "responding" not "off". Please note, this is a fresh opening of the admin console and I made no changes to anything. I just opened the window. Something is up where what is showing in the "add to program" section, and the actual program, and what is displayed in the "program content for. . . " is out of sync. EDIT: And, the only way to fix the problem was to delete the program and start over from scratch. Each time I tried changing it to "off", it seemed to work as it showed "off" everywhere. But the program still triggered on a query. When I closed the admin console and re-opened it, once again it showed "responding" at the bottom of the screen and "off" at the top of the screen. EDIT EDIT: Except that the problem isn't fixed. It is indeed displaying "off" now everywhere. But, a query of it while it is "off" and it stays "off" still triggers a true response. Why are these things triggering on a query with no status change? EDIT EDIT EDIT: Well it is back to "responding" even though the program specifies "off". After I close and re-open the admin console the gui goes back to the photo above.

It is different and it upsets a lot of people because they want it to be the same thing that their brain is already use to. They have something of a point. But this works well in the environment it was designed to function in. Regarding disabled programs: Disabling ONLY stops a program from self-triggering. It can still be hit with a "run if" "run then" or "run else". It just won't do anything of its own volition.

This works too, but remember that the first program needs to be set as "disabled". I kind of like my way better because it is faster to write. Since the programs are almost identical, once you write the first one, you just copy it and make the couple edits. And you don't have to disable anything which comes in handy if you ever need to "disable all programs" when trouble shooting something. When you re-enable, you have to remember which ones to not re-enable.

You have to write 2 programs. Having the "status" of the lamp in there will force unwanted triggers of the else clause. Here is one of my examples. If IR 'IR_003' is Pressed And Status 'Family Room / Family Room-Ceiling L' is Off Then Set Scene 'Family Rm Ceil S' 100% Else - No Actions - (To add one, press 'Action') If IR 'IR_003' is Pressed And Status 'Family Room / Family Room-Ceiling L' is not Off Then Set Scene 'Family Rm Ceil S' Off Else - No Actions - (To add one, press 'Action')

In addition to what Lee said, it could be that the light is a noisy fluorescent or have some other noise producing transformer or whatever. The light turns on fine, but once on, the power line noise it generates may prevent the Insteon command from reaching its target and turning it off. A simple way to check this is to manually turn it on and off from the ISY main console. If that works fine, then it must be your program. For sure you don't need the line that says "if status is off". If it is already on, sending another "on" command does no harm.

as I recall, someone correct me if wrong, at reboot the ISY will query all devices so it knows what state they are in. Then it checks programs and places them at true or false depending on the If condition. It does not run them unless specifically set to run at startup. That would be worth checking. I can tell you that I have a program that every once in a while runs at 3am when the system does a query all and ISY had the Wrong status prior to query. Not sure if a status of "blank" changing to "something" is considered a change and thus a trigger. A UPS is still a nice idea. It really keeps your programs straight after a power cycle. And as mentioned, ISY only uses a few watts so that thing would run a long time. The number 5 watts rings a bell but that is just a vague recollection.

One option is like Oberkc said and wire the light hot all the time and put an inline linc at the light. Another would be tear out the box and put a 5'er in.

Put your ISY on a UPS, but not the PLM. In my experience, ISY never reboots except on power cycles.

ISY can't respond to response messages like that as far as I know. You would need to use REST commands, and I don't know that it is possible to get the itach to do that. You would probably have to use an intermediary, like a PC.

To add another advantage. A scene is one Insteon command sent over the power line no matter how many devices, a program controlling individual devices is one command for every device. As you get more devices, the transmission success rate will suffer.

If you were to add more conditions or if you were to call the program from another program, then the else could run. It is not ruled out as a possibility. Furthermore, it is just a "form" of sorts. You don't always need all the blanks on a form, and you don't necessarily need all the options in an ISY program. And if you want to substitute other terminology for the word "if" in your own mind, then fine. Like "in the event that" Elk, which uses similar event driven programs using the term "whenever" instead of "if"

Please read what I wrote again. You are being oddly judgmental for someone who is asking for help as a beginner. The fact is, ISY is event driven. Programs calling programs is a fundamental part of how ISY works in more complex situations. If you don't like it, tough luck. Don't use ISY. And, to your second question. ISY does not always run false because like I said, it is event driven. The only trigger for a "control swithed on" is receiving a "switched on" signal from the switch. How would it ever be false? It either receives that signal and the "event" triggers the program, and it is true, or no trigger ever occurs and the program simply doesn't run. The else clause has lots of value, but not in a single line "control switched" program.

As oberkc mentions, it does work and it follows its logic. But it is a different language. Don't try to just apply the usual stuff. Programs calling programs or programs checking the true/false nature of a program is very common with people who take the programming past the total beginner level. Understand triggers and you will get most of it. Important concepts. 1) "control" statements are triggers on ISY receiving that command. ie "control switched on" means someone must push the on paddle. Otherwise it is false. It will always be false if something else triggers. 2) "status" statements trigger on every change of the status no matter what it might be. It could be true or false if it is its own trigger or if something else triggers. 3) All of the conditions are equal as far as potential to be triggers. The first or the last statement makes no difference, a trigger causes the entire program to stop (if it is already running) and evaluate the entire "if" clause. 4) Conditions will be triggers whether you want them to be or not. In other words, you can't shut off a condition as far as being a trigger. This is when you use multiple programs where one calls another. It is a bit of a workaround. The program that you want to disable the trigger clause is set as "disabled" so it never self-triggers. Disabled does not stop a program from running, only self triggering. 5) Time commands are triggers as noted earlier. ISY is very powerful. But it is definitely different.

If Time is x This program will only self trigger at that time and be true (run then). It will never run the else clause on its own. If anything else causes it to trigger, it will only run the else clause since you could never have an external trigger happen exactly at time x. This program will also always be "true" when left to itself. Again, if some other program triggered it, then it would be false. But there really is no reason to ever do that so it would almost certainly have a blank Else clause. If Time is x And some other condition You can "and" a single time clause to other clauses, in this case the time trigger would likely be the important trigger and the "anded" items would be secondary conditions that you might want to also be true at that time in order to execute. If the "anded" items trigger, then it will run false because the time would not be true at that instant. It is very unlikely that you would ever use the "else" clause in a program like this. If time is from x to y This has 3 useful functions. First, it triggers a then at the from time, and an else at the to time. It also will be true between the times, so another program can reference it. You would pretty much always have a "then" and "else" clause for this program. Leaving the "else" blank would more or less make it the same as "if time is x". The exception would be if another program calls it. If time is from x to y and other condition You can have other conditions "anded" to it and still get either a true or false response. This program will often have both "then" and "else" conditions, but not necessarily. You may just want "then" clause conditions to execute at time x and between times x and y whenever the other condition is also true. But you may just want nothing to happen outside of that window.

I don't know why resistance would simulate short to ground. After all, everything that you plug in to any receptacle has resistance, and all of your low current stuff has extremely high resistance. Do I understand correctly that you have: 1) Hooked up the hot and neutral from your branch circuit to the normal locations on the GFCI breaker 2) That you have attached the GFCI's coiled white wire to the normal neutral bus in the breaker box 3) The instead of attaching the ground wire from the branch to the ground bar in the breaker, you have attached it to the same neutral bus slot as the wire in #2 above So, #3 above would be the only thing you did differently than per normal installation, correct? And somehow that doesn't pop the GFCI, but attaching the ground to the normal ground bus does pop it. Electrically, the only difference between proper wiring and what you have done, is the few inches of metal connecting the ground bus and neutral bus inside your breaker box. Have you confirmed that it is the activation of the relay that is popping the GFCI and not the Insteon command? This can be checked by doing a query on the device without changing its state. If a query fails to pop the GFCI, then it leaves all of the other electronics in the Insteon device as the problem (the circuitry that activates the relay in response to an Insteon command and the relay itself). I think you have ruled out an actual ground fault since: 1) you checked the gfci breaker in its current wiring scheme and it popped 2) it doesn't pop with this same wiring scheme when you activate the Insteon device plugged into it.

I understand it to run on an Android platform. At least that is what they told me when I met them at SXSW last year. I wouldn't be surprised if it takes someone writing an app for it. But maybe I am wrong. How do you interface with the device? Does it have a USB port or is it just wifi?

On at least 2 occasions over the last 3 years, I have had to reset my access points (probably only one of them failed but reset both at same time by flipping the 220V breaker that powers their dedicated circuits). I believe both occasions were preceded by brownouts but can't swear to it at this point. -Xathros Interesting. I ditched all of my access points after I installed about 10 of the dual band switches. Things actually seemed to work better without the AP's. Sadly, I have about 4 swtches in my house that are very hit or miss with comm. I can not for the life of me figure it out. I even replaced a couple of them with dual band switches and they still miss about 25% of the time (and yes I put several dual band switches in places that never have trouble). Always the same ones and in the same part of the house. But I can't find the noise/sucking.

IE exploring stopped supporting the username pasword in the url several versions ago. If you can post your rest commands from a browser on the same network as the UBI, I doubt it has anything to do with your ISY or your network. I would put my money on the username password issue. The UBI would have to support that function in the URL and I bet it does not. No doubt there has got to be a way to authenticate your UBI to the ISY, but I don't know what it would be. You would really need to get on a UBI forum to work that out. I don't believe there is a way to turn off ISY's authentication, but if someone knows of a way, it would be worth turning it off temporarily for testing purposes.

The equation is Vrms = IR, not Vpp = IR Vrms for 3.2Vpp is more like 1.14, so current would be .228 amp But more to the point. You seem to be be saying that the .228 amps (or .640) would be a differential current. That would mean that all GFCI's would rightfully trip when an Insteon device is plugged in. But we know that not to be the case. Insteon devices do not use the ground lead to complete their circuits. They function strictly off of hot/neutral. So why would you believe that the Insteon signal would not be completing the signal circuit to the neutral and thus no differential? We know that the device does not complete a circuit to ground since Insteon devices function normally with no ground connected (or alternative path to ground). There must therefore be 2 other options: 1) The circuit is completed using Neutral (likely) 2) The circuit is not completed, the device holds a static charge. I think it is highly unlikely that the device is holding a static charge, but have no testing to prove that, except that Insteon devices almost always don't trip a GFCI. So it leaves only that the circuit is completed to neutral. Thus a GFCI that is properly designed and functioning, should not pop since there is no differential across the hot/neutral. The only explanation is that the GFCI circuitry is either malfunctioning or poorly designed such that an Insteon signal is falsely energizing the solenoid via a mechanism other than a differential current. A GFCI designer may not have considered that there will be activity at anything other than 60hz and the activation circuitry may not be properly designed to not falsely activate on current at other frequencies even if it is not ground faulted. Since noise at all kinds of frequencies exist in homes today, that would be a poor design. Either that or the Insteon device in question actually has a ground fault. My suggestion to the OP would be 1) Buy a GFCI tester and test all of the GFCI's in the house. .. they are known to fail and stick in the non-popped position. This is just a general good idea 2) Plug the Insteon device into several of the GFCI's that have been tested. Do they all pop? 3) Plug other Insteon devices into the same popping GFCI's. Do they pop? If only the one Insteon device pops multiple GFCI's, then I suspect an actual ground fault If multiple Insteon devices pop only the one GFCI, I suspect a bad GFCI either in design or in current operational condition. If multiple Insteon devices pop multiple GFCI's, are they all the same brand/vintage. If yes, suspect a design flaw in that model and would suggest buying a single new one and testing it. If all is well go ahead and replace all that malfunction.

Yeah, I would first type it into a browser using spaces and test it. Then you can cut and paste into UBI with the %20 instead of a space letting the browser do the swap out for you. It gives me a headache looking at it with all those %20's.

If resetting the AP fixed the problem, then it sounds like you had a comm issue. But I don't know why your access points would have needed resetting and if this will recur. If you already have dual band devices and the system is not working without the AP's, then apparently you are not getting the coverage with the dual band devices. All the stuff Xathros said.

1) The reason to have multiple programs is to prevent a re-trigger of a program when it is running wait or repeat commands. Mostly this is an issue when using "status" since any status change will re-trigger and stop any further wait. To prevent this, the first program calls a "then" or "else" clause on the second program. In the event of using "control", there won't be any benefit to doing that. In your program above, I don't see value in using 2 programs. 2) Status is used if you want the program to trigger on any change. Also status is how you check the status of a device as a secondary condition. For example, if the time is 9pm and status of a device is off, then do something. You could not use a "control" statement here. Control statement only are true when the actual control command is sent (ie when you push the button on a switch) 3) ISY reacts to all incoming Insteon commands and checks them against all the programs to see if any action should be taken. It does not poll devices for the sake of a program. If a device changes status, then the device sends an Insteon message out and ISY picks that up and reacts to it. If ISY has an internal trigger (like time is 9pm), and a program that triggers needs to know the status of a device, it does not poll the device. It uses its internal records to know what its current state is.

Xathros is correct except you have to put the last digit of the node in. The node as listed on the device usually has a "1" after it. For example, this turns a light fast on in my house where the isy is at 192.168.1.9. http://192.168.1.9/rest/nodes/12 24 95 1/cmd/DFON This is the device whose address is 12.24.95 But it has a "1" after it. don't know why? You can query the ISY using rest http://192.168.1.9/rest/nodes/ And it will list everything and the node. Your web browser will replace the space in the address with %20, so no need to do that. Now, the tough part will be figuring out how to get Ubi to put you user/password in. I can't help you on that.

Do I understand correctly that they do turn on every day per an ISY program, it is just that they aren't turning off? What are the loads? Can you turn them off from the ISY admin console? A highly probable issue is that you have something with a ballast or transformer that when turned on is causing noise. You have no problem turning it on, but once on the load is scrambling or attenuating your Insteon signal and thus you can't turn it off. Try turning each device on/off one at a time from the admin console. You might find that one of them is the culprit. You would need to filter whichever one is making the noise.

Doesn't mean it isn't a comm issue. Are all of the devices on the same circuit? Do you have any other devices around the house fail at a similar time? Do you have other programs running at sunset that might be resulting in clashing signals or noise generation at that time.