
apostolakisl
Members-
Posts
6943 -
Joined
-
Last visited
Everything posted by apostolakisl
-
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.
-
Using an Insteon DIN On/Off Realay with a GFCI Breaker
apostolakisl replied to ejh3's topic in ISY994
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.
-
Using an Insteon DIN On/Off Realay with a GFCI Breaker
apostolakisl replied to ejh3's topic in ISY994
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.
-
Using an Insteon DIN On/Off Realay with a GFCI Breaker
apostolakisl replied to ejh3's topic in ISY994
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. -
Using an Insteon DIN On/Off Realay with a GFCI Breaker
apostolakisl replied to ejh3's topic in ISY994
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. -
Using an Insteon DIN On/Off Realay with a GFCI Breaker
apostolakisl replied to ejh3's topic in ISY994
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.
-
Using an Insteon DIN On/Off Realay with a GFCI Breaker
apostolakisl replied to ejh3's topic in ISY994
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.