oberkc

I recall having some of mine where the backlight level is completely off. I never liked them this way, so I quickly readjusted them. Also, because of my mixed success with adjusting backlight levels via ISY, I have always adjested this manually via the method in the manual ( page 12 in the latest manual) setting the brightness level completely off. I havent done this in quite a while. Perhaps this ability is differernt in older versions of keypad. Perhaps I remember wrong. Unfortunately, I am not in a position to verify.

Is your motion sensor also part of you scene "motion"? If so, remove it from the scene. (I cannot help but suspect that it is, and that this is the root cause of your problems.) Eliminate your FIRST PROGRAM. It serves no purpose, nor does it have any affect on any device. In your SECOND program, use "control" rather than"stauts".

It seems to me that when one sends an OFF command ( including via a keypad configured to send OFF commands) the normal and expected response would be for lights to turn off. Also, I have had mixed success adjusting the backlight levels of a keypad. Have you tried using the manual method as described in the user manual for the keypad. I can tell you that my understanding is that keypads CAN be set to zero backlight. Having said this , the ISY would allow you to accomplish that which you seek, but would require the use of a few programs to make it happen, rathther than using the keypad button as a controller in a scene. It would look something like: If Control keypad is turned off Then Set scene off Else

I like the iPad, as well. I use one daily. However, I find that it does not offer enough flexibility for my tastes to act as a whole-house controller. For that purpose, I use android tablets. Still, based on the image you posted, this looks like little more than an app for each function, whether lighting, TV, security, music, etc.... an iPad should be able to handle that. For lighting (insteon/ISY-99 based), I use mobilinc, as well. For the rest (TV, music, security, HVAC, camera) there can be, but need not be, any relationship to insteon. For those functions, in my mind, finding the right app would be dependent on the system and hardware you have or are willing to purchase. I control my tv/theater system through a logitech review and app called "Able Remote". I don't do HVAC nor security. For music, I have a simple system based upon a Grace media streamer and use an android app from Grace to control this. For IP camera viewing, I use an app called "IPCamviewer". I also employ an app called "Tasker" to automate the display of various widgets, firing of apps, and modes based upon time of day. To emulate what you show regarding the control4 app, it would be a simple matter to create a home screen with these apps on it. Most of those apps are completely unrelated to my lighting system or insteon. The need to integrate many of those functions with insteon is simply if you have a desire to trigger security, TV, music, etc... from an insteon device or switch. The ISY controller can also help bridge communication between some of those systems. If, however, the only relationship you maintain between the various systems is the fact that all are to be controlled via a single tablet, then I see little need for all to be able to speak insteon.

Keep in mind that insteon motion sensors can be configured, just like those that are x-10. When an insteon motion sensor is configured to send only ON commands, the ISY will show a motion sensor as ON. I am not sure that insteon motion sensors will behave any differently. The question I have is why do you percieve the "status" of a motion sensor to be important? Are you trying to get a sense of how recently motion has been sensed? For me, I have simply accepted the fact that "status" has no meaning for certain devices, including motion sensors, remote controls, and IOLinc relays.

I use some x-10 motion sensors. Mine can be set up to send only ON commands, I recall. If set up in this way, LeeG's explanation is consistent with my understanding. The ISY status reflects latest command recieved.

Good. I was starting to wonder if I was missing something. Also good. I was concerned that the OP appeared to have had a much broader set of conditions, including some where the device was changing state. Fortunately, it appears that jwagner010 has gotten things working again. It is certainly difficult to diagnose problems when there are intermittent device failures thrown into the mix.

My keypad buttons ARE lit when off, albeit at a reduced level. Have you tried manually setting the brightness levels, based on the instructions in the manual? The ISY does have the ability to set backlight levels, both for ON and OFF, I believe. My experience with this is mixed, but I believe that this is due to the varying age of my keypads. Older versions, I have been told, do not support this. Regardless, I do not believe the keypad can be prograamed such that the backlight levels are the same brightness when off as for on. The level, even when on will be at a reduced level.

Xathros, You are not the only one who has posted that they use this construct. Based on my limited testing and subsequent theory, this looks to work for when the status and control conditions are the same and no change of state is initiated. Off-to-off. On-to-on. I am concerned that this onstruct starts to fall apart umder certain cases where status changes, such as If status xxx is off And control xxx is switched on When the switch xxx is switched from off to on, I believe this will return a quick TRUE and a subsequent false. I am also suspicious that this might act funny when a dimmer is used and conditions other than full on/off are introduced.

That is consistent with my current working theory: condions with status and control of the same device will always trigger twice when there is a change of status. First because of the control. Second because of the status change. They will always return FALSE the second time, regardless of final state and input condition. I don't think I will be using this construct any time soon. Until I better understand it.

Except that I tried two cases...off>on and on>on. In neither case did it trigger twice, even though there WAS a change in status.

OK...I did a little testing. I created a program. To ensure I am not missing the point, my understanding is that I am trying to better understand the reaction of a program when a "status" and "control" for the same device are in the same program, and what happens under various combinations of off->on, and on->on. The program: If Status 'Kitchen / SW KTS Kitchen Sink' is On And Control 'Kitchen / SW KTS Kitchen Sink' is switched On Then Set 'X-10 Controls / Battery Chargers (A1)' On Else Set 'X-10 Controls / Battery Chargers (A1)' Off When the 'Kitchen / SW KTS Kitchen Sink' is switched from off->on, the status was false. When the 'Kitchen / SW KTS Kitchen Sink' is switched from on-> on, the status went true. For those interested, the event log is below: 02 50 12.C9.76 00.00.01 CB 11 00 LTONRR (00) Mon 03/04/2013 10:02:07 PM : [std-Group ] 12.C9.76-->Group=1, Max Hops=3, Hops Left=2 Mon 03/04/2013 10:02:07 PM : [ 12 C9 76 1] DON 0 Mon 03/04/2013 10:02:07 PM : [iNST-SRX ] 02 50 12.C9.76 0D.FE.30 41 11 01 LTONRR (01) Mon 03/04/2013 10:02:07 PM : [std-Cleanup ] 12.C9.76-->ISY/PLM Group=1, Max Hops=1, Hops Left=0 Mon 03/04/2013 10:02:07 PM : [iNST-DUP ] Previous message ignored. Mon 03/04/2013 10:02:07 PM : [X10-RSP ] 02 63 66 00 06 Mon 03/04/2013 10:02:07 PM : [ E EF 55 1] ST 255 Mon 03/04/2013 10:02:07 PM : [ 12 C9 76 1] ST 255 Mon 03/04/2013 10:02:08 PM : [ 17 89 51 1] ST 255 Mon 03/04/2013 10:02:08 PM : [ X10] A1 Mon 03/04/2013 10:02:08 PM : [ X10] A1/Off (11) Mon 03/04/2013 10:02:08 PM : [ FF 01 01 1] DOF 0 Mon 03/04/2013 10:02:08 PM : [ FF 01 01 2] DOF 0 Mon 03/04/2013 10:02:08 PM : [ X10] A1 Mon 03/04/2013 10:02:08 PM : [ X10] A1/Off (11) Mon 03/04/2013 10:02:08 PM : [ FF 01 01 1] DOF 0 Mon 03/04/2013 10:02:08 PM : [ FF 01 01 2] DOF 0 Mon 03/04/2013 10:02:08 PM : [X10-RSP ] 02 63 63 80 06 Mon 03/04/2013 10:02:09 PM : [X10-RSP ] 02 63 66 00 06 Mon 03/04/2013 10:02:10 PM : [X10-RSP ] 02 63 63 80 06 Mon 03/04/2013 10:03:09 PM : [iNST-SRX ] 02 50 12.C9.76 00.00.01 CB 11 00 LTONRR (00) Mon 03/04/2013 10:03:09 PM : [std-Group ] 12.C9.76-->Group=1, Max Hops=3, Hops Left=2 Mon 03/04/2013 10:03:09 PM : [ 12 C9 76 1] DON 0 Mon 03/04/2013 10:03:09 PM : [iNST-SRX ] 02 50 12.C9.76 0D.FE.30 41 11 01 LTONRR (01) Mon 03/04/2013 10:03:09 PM : [std-Cleanup ] 12.C9.76-->ISY/PLM Group=1, Max Hops=1, Hops Left=0 Mon 03/04/2013 10:03:09 PM : [iNST-DUP ] Previous message ignored. Mon 03/04/2013 10:03:09 PM : [X10-RSP ] 02 63 66 00 06 Mon 03/04/2013 10:03:09 PM : [ X10] A1 Mon 03/04/2013 10:03:09 PM : [ X10] A1/On (3) Mon 03/04/2013 10:03:09 PM : [ FF 01 01 1] ST 255 Mon 03/04/2013 10:03:09 PM : [ FF 01 01 1] DON 255 Mon 03/04/2013 10:03:09 PM : [ FF 01 01 2] ST 255 Mon 03/04/2013 10:03:09 PM : [ FF 01 01 2] DON 255 Mon 03/04/2013 10:03:10 PM : [X10-RSP ] 02 63 62 80 06 I was unable to observe the program in action, due to the location of switch not being in proximity to the event viewer. I had performed another experiment, with another switch (keypad button) as trigger where I could observe the program in action. If Status 'Office / KP OFC Desk Lamp' is Off And Control 'Office / KP OFC Desk Lamp' is switched On Then Set 'X-10 Controls / Battery Chargers (A1)' On Else Set 'X-10 Controls / Battery Chargers (A1)' Off Interestingly, I found that this one, when a toggling a button from OFF->ON, first evaluated as TRUE, then quickly back to false. I can only assume that the control triggered an evaluation prior to a status change (TRUE), and the status change quickly triggered a second evaluation (FALSE). the log from this example: 02 50 0A.D7.5F 00.00.01 CB 11 00 LTONRR (00) Mon 03/04/2013 09:43:20 PM : [std-Group ] 0A.D7.5F-->Group=1, Max Hops=3, Hops Left=2 Mon 03/04/2013 09:43:20 PM : [ A D7 5F 1] DON 0 Mon 03/04/2013 09:43:20 PM : [iNST-SRX ] 02 50 0A.D7.5F 0D.FE.30 41 11 01 LTONRR (01) Mon 03/04/2013 09:43:20 PM : [std-Cleanup ] 0A.D7.5F-->ISY/PLM Group=1, Max Hops=1, Hops Left=0 Mon 03/04/2013 09:43:20 PM : [iNST-DUP ] Previous message ignored. Mon 03/04/2013 09:43:21 PM : [ A D7 5F 1] ST 255 Mon 03/04/2013 09:43:21 PM : [X10-RSP ] 02 63 66 00 06 Mon 03/04/2013 09:43:21 PM : [ X10] A1 Mon 03/04/2013 09:43:21 PM : [ X10] A1/On (3) Mon 03/04/2013 09:43:21 PM : [ FF 01 01 1] ST 255 Mon 03/04/2013 09:43:21 PM : [ FF 01 01 1] DON 255 Mon 03/04/2013 09:43:21 PM : [ FF 01 01 2] ST 255 Mon 03/04/2013 09:43:21 PM : [ FF 01 01 2] DON 255 Mon 03/04/2013 09:43:21 PM : [ X10] A1 Mon 03/04/2013 09:43:21 PM : [ X10] A1/Off (11) Mon 03/04/2013 09:43:21 PM : [ FF 01 01 1] ST 0 Mon 03/04/2013 09:43:21 PM : [ FF 01 01 1] DOF 0 Mon 03/04/2013 09:43:21 PM : [ FF 01 01 2] ST 0 Mon 03/04/2013 09:43:21 PM : [ FF 01 01 2] DOF 0 Mon 03/04/2013 09:43:22 PM : [X10-RSP ] 02 63 62 80 06 Mon 03/04/2013 09:43:23 PM : [X10-RSP ] 02 63 66 00 06 Mon 03/04/2013 09:43:24 PM : [X10-RSP ] 02 63 63 80 06 What remains a mystery (at least until I return home from a ski trip or someone else cares to explain) is why this second example appeared to trigger two evaluations and the first program never did this. It is getting late, and I leave early tomorrow. I hope this helps.

OK. That makes sense. I don't see anything in your programs affected by "away" condition, nor anything that would change your thermostat settings based upon being away. Given this, in what way is your existing program better than this: If On Mon, Tue, Wed, Thu, Fri time is 5:00:00AM And Module 'Climate' Temperature < 60 °F then... else...

Forgive me, but I don't have the climate module. What does the temperature variable represent? Outside temperature? Why is it important that this temperature be at or above 60 degrees for you to want the thermostat set points to change? What would happen if you take the temperature condition out of the program? Does the problem persist? Is it possible that you have other programs controlling thermostat set points? The only thing that I see could force this program to change thermostat set points past 0500 is if climate/temperature changes between 0500 and 0800, triggering a program evaluation. I don't believe that this program is reacting to local changes of the thermostat. I am curious why you use a from/to condition for time. What are you trying to achieve that could not be achieved simply by: time is 0500 and temperature >= 60

If there is still concern that there are some dynamic reason that the sensor is oscillating between ON and OFF, I think I would investigate by watching the LED on the IOLinc for any flashing, and/or check event viewer for signs of a stream of status indications. If not, then is it possible that the KPLA button is still configured in a non-toggle mode? (Non-toggle buttons will flash when pressed.)

LeeG, I will keep everyone advised of anything I find out. This one surely has my interest piqued. Because my mind is evil, I cannot help but take this type of scenerio to an extreme and wonder what would happen if one had two controls or two status conditions, or some other combination of conditions triggered by the same device.... if control deviceA is switched on and control deviceA is switched on then... else... or if status of switchA is on and status of switchA is on then... else.... Should the experiments so far be taken to suggest that there is some heierchy of conditions, such as control before status. I wonder where that might leave a variable whos value changes based on switchA. I also wonder if this hierchy is simply a natural outcome of timing, or whether it is hard-coded. But then, I realize that life is sometimes too short to spend a lot of time worrying about such things.

Thanks, LeeG and TJF1960. This is certainly NOT what I expected. However, knowing this creates some methods and tricks for programming that I had not considered. I am probably still curious enough about this that I might try another similar experiment to see if the order (status--->control versus control--->status) matters. I also assume that this is near 100% repeatable, and that there are no timing issues that can affect this. JWagner010, I guess this means that my concerns are demonstrated nonvalid. Perhaps it is communication problems (whatever they may be) that are the sole cause of your difficulties.

I hope, for jwagner010' sake, you are correct. I can tell you that, were each of these conditions in a separate program, they would both evaluate as true. Given this, I expect that both conditions in a single program would, therefore, be true. I have not, however, run an experiment to confirm. So your experience suggests that both conditions are not evaluated simultaneously. Do you suppose order of the conditions matters?

The sensor reports ON-OFF-ON, or the KPL? I find it hard to believe that the sensor, itself, reports that status. The behavior sounds as if you have your KPL in a non-toggle mode, where the KPL will flash a couple of times. How do you know that the sensor reports ON-OFF-ON? Do you, sometimes, have to press the KPL more than once in order to activate the door? In momentary A mode, it will responde to EITHER (but not both) ON or OFF commands. It sounds as if you have yours configured to respond to OFF. This would explain why the door would not respond to your KPL when configured in non-toggle ON mode. Does this sound plausible? This could depend on your program for sending text notifications. Is this program triggered off sensor status or KPL status, or something else? Have you actually experienced reciept of three text messages? This tends to suggest that your "momentary A" setting will respond only to OFF commands. I noted that LeeG suggested momentary B mode, but you chose different. Is there any particular reason you chose momentary A? I have found that the garage door case is a relatively complicated setup, where every setting and installation is related to the other, and attention to details matters. Location of sensor is non-trivial. It matters whether sensor is ON or OFF when door is closed. Momentary mode of the relay is related to mode of the KPL and of the sensor status relationship to door. My recommendation for garage doors matches the wiki: a) locate the sensor such that is is closed when the door is FULLY closed. Check the LED indicator of the IOLinc to be sure. wire the sensor such that it is ON when the door is open (rather, not closed) and off when fully closed. c) configure your relay to respond to ON commands, and: d) configure your KPL to be non-toggle ON e) create a scene with KPL as controller and relay as responder f) create a scene with sensor as controller and KPL as responder. If you follow these steps, pressing your KPL will cause the door to open or close. The KPL will flash a few times, but remain lit if the door is open or turn off if closed. Each of these steps is related to others. If you fail to perform any one step correctly, the door/KPL will not work properly. If you have questions about any of those steps, let us know.

I think this is where the confusion lies. In fact, the light is ON when the program triggers for evaluation, because turning the light on is the action triggering the evaluation. I believe this to be the root of your program problem in this example. Of course, communication problems could also be in play, here, as suggested by LeeG. To use an example in an attempt to explain, how would you expect the following program to react (true or false?) when toggling the switch from off-to-on? if status downstairs-kitchen is on then ... else ... I believe you will find that it evalates TRUE! Given this, how would you expect this program to evaluate when toggling the switch from off-to-on? if status downstairs-kitchen is on and control downstairs-kitchen is switced on then ... else ... I believe you will find that this evaluates TRUE, as well.

I would not be so certain. I attempted to offer an explanation in an earlier (if lengthy) post. Perhaps rereading this would help. In my mind, this program will trigger true going from off-to-on, assuming the variable is zero. From off-to-on, both control and status conditions would evaluate as true. If the variable is zero, then all three conditions are true, thus the entire program would be true.

( Status 'Downstairs - Kitchen' is 100% And Control 'Downstairs - Kitchen' is switched On ) And $SB_DN_Kitchen_OnOff is 0 Of those three conditions, which do you believe should prevent the execution of the THEN statement? (I am a little unclear about what causes the variable to change value.) BTW, the parentheses are no longer needed.

That was one of my original concerns. I wonder if breaking it down further may help both of us with understanding this. Consider this simple program: if status downstairs kitchen is on then .. else ... When the downstairs kitchen is turned on from off, this program will trigger and evaluate true, correct? Let's consider a second simple program as follows: if control downstairs kitchen is switched on then ... else ... This program would ALSO evaluate as true when the kitchen is turned on from off, correct? What happens when one combines these two conditions into a single program: if status downstairs kitchen is on and control downstairs kitchen is switched on then ... else ... Would this program also not evaluate as true (both conditions are true) when the downstairs kitchen is switched from off to on? Given this, is it easier to see how the "music - kitchen Down - On" program might evaluate as true?

to double check, I was looking at my admin console. I am trying to find "group devices". In retrospect, I don't see it and want to be sure we are talking about the same thing. Can you be more specific where you see this "group devices" in the admin console?

While I did not intend to offend, part of the reason I stated this was because extra lines that, after your follow-on evaluation, you admit that were unnecessary. They just struck me as extra lines without much functional purpose (which was true). Perhaps I should have been more tactful, but this still strikes me as overcomplicated. I missed that part in the original post. So, you know that these programs once worked, but now do not. I do not believe that programs, in general, quit working. I would focus on other possible explanations for why a program once worked but would stop. OK. I cannot help but wonder how you want these programs to react when the kitchen light is <99% but >1%. But, since the programs worked as you wanted at one point, I would focus more on the change and what affect it had on your programs. I would focus on whether your ISY is seeing correct status from the new devices, or even from the old devices. As a diagnostic tool, I would try a couple of things. I would temporarily disable all but one of the programs and determine if each is consistently reacting as you believe it should. If not, I would observe the input conditions (kitchen light, mostly) and see if the ISY is correctly seeing the status. If not, find out why. Once you have confirmed each program is working again, try re-enabling the remaining programs, one at a time. Are they still working? If not, I wonder if having multiple programs triggered from the same device (kitchen light) is causing some sort of interaction between them.