oberkc

I have used groupings in the past, as well, but prefer scenes so I do not use them now. Never saw a problem, but never made changes or replaced such a device. Be sure to take advantage of the tools. Select the device in question and it will show the scenes in which it is a part. From the programs list, there is a "find and replace" option that is very helpful for finding where certain devices are contained in a program.

I understand. I suggest, however, that if your intentions are simply to "turn of lights" (per original post), then the only harm is that the ISY will send an OFF command to lights that are already OFF. To me, that is harmless enough. If your new program fails to achieve your goals, you might try this approach as an intermediate step. This could help troubleshooting.

Doug95630 I suspect you problems have less to do about motion sensor reliability and more to do with programming logic. Do you know about parentheses in programs? Try putting parentheses around the last seven lines of your program condition. Alternatively, what harm do you see in completely eliminating the last seven lines of your program?

Like Brian H, I am unaware of any method one can use to eliminate a device or node from the ISY admin panel. The method I use is to name it something like "fanlinc light (unused)" and move it to a folder of unused devices.

Some have said they use zwave exclusively with the ISY controller. I do not. My perceptions are that it could work well but youwould be near fully dependent on programs. I do not believe the ISY has the ability to create direct scene relationships between zwave devices. While i still use more insteon than zwave, I have liked both. Until the point the ISY supports zwave scenes, though, I would probably continue to favor insteon and use zwave selectively.

While I own two of the WF2IR devices, I use them with other software and have only performed limited experiments using them with the ISY994. I am a little fuzzy on what the flex device does and how that compares. My impressions are that one could use the WF2IR and learn specific codes from an ir remote, but that it takes some effort (and the network module) to get things working. If you are willing to experiment a bit, however, I expect that this would work. The one concern I have is that some ir-controlled devices can use codes that appear to be non static and that may create some complications. On the other hand, if you were able to learn the command on your harmony, I doubt this is a concern. Is there some reason you have not chosen the irlinc transmitter? While I do not own one, this seems to me to be the obvious option. (Perhaps there is some limitation with ISY of which I am not aware?)

When you have noticed comm issues with this device, is the prblem normally the pump failing to come ON? If so, then I would be focusing on factors external to the pump, itself. This is definitely a relay outlet, not dimmer. Correct? Also, be sure to do your best to ensure PLM is on a clean circuit. No other gadgets and computers/ups/routers/modems. Right? Do you ever use filters?

Some folks have downloaded the data describing the meaning of all this. I have not done so yet. Stiil, I believe the fouth line may be the axknowlegement from the responder and the hop count suggests pretty good communication at this point in time. Did your outlet turn on? Given appearances that comm is good at least some of the time, I would be considering what intermittent devices (HVAC, washer/dryer refrigerator, etc..) that might explain why comms would be good some time and not others. Also, see if comms are as good when turning OFF the fountain. If not, this could suggest that the fountain pump, itself, could be contributing to comm errors

My initial assumption in cases like this is to treat as a communication problem. My understanding is that ISY will assume commands issued are followed, and device status tracked according to those assumptions. Even if expected confirmation from device is not recieved, device status will be updated based on assumed response to commands. Obviously, ISY status and truth can conflict when the device failed to respond as expected. Given this, I would start troubleshooting effort to identify comm problems.

I ran a minor experiment. In fact, if a device is a scene controller, you can use it in both places (controller and responder). Assuming that 'lum. salle de bain' is a scene controller, I suggest the action: in scene 'lum. salle de bain' set 'lum. salle de bain' 40% If it is not currently a scene controller, create a scene, with it as scene controller, and no other device. Then use the action statement, above.

A more accurate statement of this action context would be: In Scene 'name_of_scene_controller' Set 'name_of_scene_responder' 40% (On Level) Of couse, "name of scene controller" can be the name of the scene, itself, if looking to adjust the response to ISY programs or commands.

Ok. So...instead of changing scene responder level of 'lum. salle de bain' , we need to find a programmatic way to change responder levels when applied locally. I have never needed to do this, so I am uncertain how. The ISY user manual claims that the "adjust scene" action can be used to adjust the ON levels for devices or scenes, so I assume it can be done. Unfortunately, I see no instructions how this is done. is "lum. salle de bain" already a scene controller? If so, use the adjust scene like: In scene 'lum. salle de bain set lum. salle de bain" XX%. If not already a scene controller, perhaps creation a new scene with the single device as controller and use the same action, above.

I dont know whether your problem is related to the speed of the ISY (doubt it) or the nature of insteon devices to complete one task before starting the next. Yes, this can be fixed, and I think stusviews is on the right track here. I believe that you should change responder levels at 8:00pm to 40% and back to 100% at sunrise. Modifying stusviews ideas: If From 8pm To Sunrise (next day) Then In scene 'scene nommer' set 'luminieres/liminiers ineriures/lum salle de bain' 40% Else In scene 'scene nommer' set 'luminieres/liminiers ineriures/lum salle de bain' 100% Sorry for my language skills. I dont speak anything but english, and probably not well.

Regarding speed, the thing that I notice that seems to slow program response is communication problems. While it seems a response of a second or less is tough to improve, longer response times may be an indication of communication difficulties.

I do not believe that scenes, alone, can accomplish your goals.

Nice!

Logically, i suppose you could try: If $allowtorun is 1 Then Repeat 4 times Set outlet on wait 2 hours Set outlet off Wait 1 minute Repeat Run next program (then path) Else Halt next program Next program: If Nothing Then Wait 16 hours Run last program (if path)

Chris932, I apologize. I was, apparently, remembering things that did not exist. The user manual and wiki are definitely a good resource, but I cannot find a specific example regarding fanlincs. The problem, oftentimes, with smarthome instructions, is that they are often based without automation in mind. The instructions that come with the insteon devices are all based on having no controller and linking devices directly (manually). The problem with the instructions you linked is that relying on the mutually exclusive relationship (called "radio buttons" in the keypad manual) will cause the keypad to become out of sync when you want to control the fan via another method, such as a second device, from the ISY control panel, ISY program, mobile app, etc... You see, the radio button relationship is enforced only when manual presses on that specific keypad are used. Otherwise, the buttons are free to get out of sync. Stusview started to hit on the issue. In this case, I believe it best NOT to use the mutually exclusive options here, and handle the button relationships via scenes. You will also have to put the buttons into non-toggle (ON) mode. I am out of time, but I hope you are making progress and this little hint helps. Otherwise, I will be back.

I use a ketpad button as the key indicator for home/away. I can certainly control it rematelt, but I have not automated the status...all manual. If I were to automate it, i might do so via mobilinc ad location. I might actually prefer it based on schedule, but i do not see a practical solution to make that happeb. I have decided it is simply too easy to press the button when i leave for vacation.

Chris932, I add also that the instructions you used will work fine so long that the keypad is the only method you ever use to control the fan. Should you ever desire to turn on the fan via a program or another device or via some app, I expect that yoy will find that the keypad lights will not stay in sync. Is his support site by smarthome (I am not sure I have ever seen it)? If you are using the ISY controller, you may be better off using the universal devices wiki, where you can find user guides and articles for common use cases, including a ceiling fan example.

If you have an unswitched hot and neutral at this location, plus two travelers, it may be possible to identify the traveler that is currently routed to the common\fixture at the unidentified switch location and hook that traveler to the switched output from the new insteon switch. Still, I am curious about your wiring configuration. How many cables are there entering the switch box. How many conductors are in each of those cables? Is this the only switch in this switch box? Do you have a voltmeter and know how to use it? Are you able to identify a neutral (color is not conclusive)?

Is it possible for the 3:00 am query to cause a change in status on any given device? Yes (an indication of communication problems). Is it possible that the change in status causes a program to run? Absolutely. It is likely that a change in status at 3:00am caused a program to run at 3:03? Unlikely, in my mind. Is this happening at your house? Hard to say without seeing the programs and logs. Were there any programs that ran just prior (seconds before) the 3:03 program? Does your event log show activity at 3:02 or 3:03? So...I would be starting with the program in question and asking myself what could trigger it. From there looking for other programs that may cause such an event that would trigger it. I would be watching also for devices with inaccurate status.

I would state it slightly different. While it may be true that the ISY has no way of knowing the state if a scene, I would go further as to suggest that there is no such thing as a scene state within the very definitions of insteon. Regardless of yhe controller chosen, there is no concept of scene state.

I like it, too. Personally, I probably would not include the first two conditions of the second program, but I am funny about such things.

A few quick thoughts: Keypad buttons in their default state will toggle between ON and OFF. There is typically no logical statement that is equivalent to "keypad button is pushed". One can put the button into a state where each push is ON or where each push is always OFF. In such a state, the program would then look for the ON or OFF command, as configured. Furthermore, you might actually be able to do this in a single program. ISY has THEN and ELSE paths. In the logical form, it might be something like: if keypad button is pressed ON (keypad button configured to always send ON commands) and status outlet is off then turn on outlet push relay else push relay wait xx amount of time turn off outlet turn off keypad button I suspect, however, that you will want to add further stuff which could drive you to multiple programs. Things always get more complicated after you try things out and come up with new requirements. Also, if it is imperative to wait for direct feedback from the computer being off, this will likely drive you to a second program.