
oberkc
Members-
Posts
5857 -
Joined
-
Last visited
Everything posted by oberkc
-
I like the flexibility that the zwave board gives. I use several zwave motion sensors. I cannot say whether they are more reliable than insteon, however. I have had no failure of any motion sensor, including x-10, insteon, or z-wave. Neither am I confident a zwave sensor can be used in a scene relationship, so there may be those program delays so many seem to dislike. The other hesitancy I would have about a "new-and-improved" insteon motion sensor is compatibility with the ISY. It seems to me that there can be a delay between release of the new device and ISY ability to recognize it. Most of the time, however, it seems pretty quick.
-
This is all from memory, but I recall that the ISY would also write updates at next opportunity. I understand that such opportunities can occur during a short time after motion triggers and, once triggered and the write-update window opens, the ISY would initiate the update. I assume, also, that the automatic update buttons would need.yo be enabled. Or...It could be a looming device failure.
-
My understanding of the meaning of these little icons appears is same as yours. The only thing that I can think might have recently changed would be that you have disabled automatic write updates at the ISY admin panel. This assumes you have the pro version. This setting is global and there is one for battery devices and one for external powered devices. It is a little icon along the top menu bar.
-
Yes, there are such settings and, yes, they are configurable via ISY. Check out, also, the jumper settings as described in the motion sensor manual. One (believe it to be jumper 5) need properly set to allow configuration control via software such as ISY.
-
Certainly it would eliminate spurious openings by the iolink. Those spurious openings caused by gremlins and ghosts and sunspots would likely persist.
-
A little premature, in my estimation. If all you want is, as stated earlier, knowledge of when the door goes up or down, simply disconnect the iokinc relay connections from the opener.
-
I believe the answer to that question depends upon which ISY firmware version you are on. If 4.X, my experience is that zwave devices behave fine as scene responders, but cannot act as scene controllers. Perhaps this is device dependent...I have tried only two zwave devices in a controller mode. To trigger a scene via zwave device requires a program, and only then based upon status (versus control) of the device. I understand that firmware 5.X improves upon this, but use of this firmware is not for the faint-of-heart or those who are easily frustrated. Version 5 is still in development mode.
-
With the ISY, a controller device is, by default, a responder device also. Given this, if something turned off the room scene, I would expect button D to be off, since it is part (controller, you say) of the room scene. Did you use the ISY to create these scenes, or did you do it manually via the devices set buttons?
-
I think I am loosing track of your scenes. You say something turns off the "room" scene, but "toggleD" scene is still on? I don't see how both can be true. If the "room" scene includes all all three lamp modules, button D, and the main button, would not turning off the room scene, by default, turn off the toggleD scene also?
-
In my mind, best approach is to use an ISY program to control the timing function and when to reset. It is much more flexible.
-
I think it might be something a little different. I understand that, in "sense" mode, the motion sensor will send ON commands at each detect, regardless of the timer. I am a little fuzzy about the effect of the timer, but assume that the internal timer would be also reset. If you don't want the ON command sent until after the timeout, then you do NOT want it in "sense" mode.
-
Sachelis, of course I agree with the concerns expressed about stealing neutrals fro other circuits. It is my hope that, were you to find the cable that was originally connected to the "elsewhere" wire, you would find a white wire bundled together with the black wire connected to "elsewhere".. This is the neutral that you should use. If such a white wire is not there, be careful. Sometimes wires can get connected together and this can be hard to identify.
-
If I had to guess based upon the diagram, I would say that the B cable is to the fixture, and the "elsewhere" wire is connected to a line supply cable somewhere in the back of the box. Black B is connected to common screw, as is black C. In other words...hot into black A to switch2, red/white are travelers back to switch1 and switch1 common to load. No? Is the white wire from B connected to a white bundle in the box somewhere?
-
Quick plug for tasker here, also. Between that and widgets and access to the file system, I cannot imagine why I would go iOS. (Now...If I can only figure out what to do with those iPads I own.) Regarding the original request, is it even possible that Alexa (or something similar) can be trained to recognize the alarm sound from an iPhone?
-
I am glad you have it working. I did not look too hard at Gary's suggested program but, after only a quick glance, I wonder why the second program would not retrigger the first program once the 5min wait is over and the status of 'garage entry' changes from ON to OFF? If all continues to work...Great. if you later find some unexpected, we can look a little harder.
-
I also don't think it helps that smarthomes' definition of "scenes" has morphed over the years. My impressions are that they are now using "links" and "groups".
-
Yes, I realize these things. The quoted problem was that the keypad button (on and off only, as you remind us) was not ON. I was relating that to a toggleinc (also, only on and off). Perhaps I miss your point.
-
Another possibility I recall...at what point is a keypad button "on"? 20%? Anything over 1%? I recall a similar situation at my house where I was using a togglelinc relay as a scene controller. I had come to believe that the togglelinc relay would show ON only as the responding device reached about 50%. Clearly I am speculating at this point, but it may be worthiwhile considering that possibility.
-
Cqn you not include the kpl in the echo group?
-
It certainly was a good reminder that we could no longer assume that everything is insteon, and that there are more ways to control a garage door than the iolinc.
-
To elaborate on Gary Funks's response, one must understand what "events" will drive program evaluation. Your original program would be driven by garage doors changing status (from open to close and vice versa). In addition, it would have driven (or triggered) at sunset and at sunrise, and at change of status of the entry door. At each triggered event, the condition is evaluated and appropriate path (then or else) taken. If it were triggered during a 5min wait, the wait would have been halted and the new path taken. Most likely your program was triggered during a wait, evaluated false, and executed the THEN path (which is nothing). In addition to Gary Funks suggested approach, you might also consider using a CONTROL condition, rather than STATUS. CONTROL ON condition will only trigger upon receipt of an ON command, whereas STATUS condition will trigger upon any change of state. Another feature of CONTROL conditions is that they are only TRUE when triggered. At all other times, they will evaluate false. STATUS conditions evaluate false any time evaluated and the expected condition (ON or OFF) exists. One problem you may run into with status is that your program will also trigger by sunrise and when triggered at that time with the garage door opened, it will trigger the porch light program. I assume you do not want this to happen.
-
Deuce, Sensing mode MAY help but I consider it unlikely to be the root of your problems. In addition to the parentheses, I recommend use of CONTROL rather than STATUS for your two program conditions. You also have a potential problem at 11:29pm if your program is in the wait state. Make sure your motion sensors are NOT in a scene controlling the lights. Do you want to turn the lights off after wait timeout, or dim?
-
I can tell you that I have several wall switches that, when toggled from off to on, will go to the defined on level rather than last known state. As I read the manual for the "insteon wall switch", I see that they have different modes, including a "resume dim" feature that can be selected or not. It sounds to me as if your switch is in this mode. I do not recall whether this setting is configurable from the ISY admin panel, but would be surprised if not. Regardless, it appears that you can get the behavior you desire by reconfiguring a switch setting.
-
To/from conditions will trigger twice (and only twice)...once at from-time and once at to-time. It will evaluate TRUE at all times between those two point in time, and false at all other times. Your specific program will simply turn the lights ON at early evening and OFF later at night. I believe you misunderstand how this program will work. Your program will NOT turn your lights off in the middle of the day, nor will it turn the back on after the initial trigger (should you manually turn them off early). Your program will simply turn them on once and off once.
-
For this to happen, you must select (click on) each of the controller devices within the Scene "Living Room Main" and check for the same settings as the scene: 8 button dimmer button 1 (LOAD)(Controller) ::Set for on=75% ramp rate=4.5 paddle switch 1 (Controller) ::Set for on=75% ramp rate=4.5 paddle switch 2 (Controller) ::Set for on=75% ramp rate=4.5 8 button dimmer button 2 (Responder) ::Set for on=0% ramp rate=0 Make sure you select the "button 2" of the "movie scene" and ensure the responder settings are consistent with the scene settings. It seems to me that you have the scenes set up correctly. No, I do not think your problems have anything to do with the way the ISY handles scenes, and I believe what you want to happen can, and should, be done with scenes only. No programs needed. The only way that I know of for the ISY to actually change scene responder levels is via a program. Please make sure you don't have unexpected program responses to pressing of any of those buttons or paddles. If you are unsure how to check this, let us know.