oberkc

A simple method would simply be to initiate a pogram which increments a variable by one each day. When the variable reaches ten, do something. Whether or not this meets yo needs could depend on what you mean bt “10 days”. If you mean exactly 240 hours from the time you press the button, it might take a little more effort. If you simply mean to do something at a fixed time on the tenth day, this simple method might work.

To satisfy my own curiosity...you state that the ISY recognizes the device as a 5-button dimmer. How many buttons were added to the device tree, 5 (main, A, B, C, D) or 8 (A-H)? One factor that may come into play here is that these keypads can be converted from 5-button to 8-button (or reverse). The keypad sure sounds like it thinks it is in an 8-button configuration. I wonder what would happen if you converted it to a 5-button configuration following the instructions from the manual.

I know that I have converted 6-button versions to 8, and used the instructions that came with the keypad. I don't recall that this can be done via ISY. Also, if needed to perform a factory reset, this will bring the unit back to the original button configuration (6 or 8). According to the latest manuals, this conversion capability is still in place. But, yes, it seems that the 2334-222 is the current version of your old 2486D. Why would you be looking for other "options"?

Even if you don't have a spare device, create a scene (as a test) and put the relay in it. From there, send scene ON and OFF commands and observe how the different modes react. I think you will find that the device DOES work as expected from a scene perspective.

No, I do not think you are confused about momentary-A. (Either that, or we are both confused.) My understanding of momentary-A mode is that either (both) ON and OFF commands will trigger the relay to close momentarily. The only thought that I have is that this may work differently when the relay is part of a scene with another insteon device (keypad button, for example) as controller. Is there a chance you have a spare device laying around to test this theory?

Your action first sets the main door open, then waits. Unfortunately, this will retrigger your program and halt further execution of the action, which will now be false and run ELSE. The trick here is to use two programs. One option would be something like: If $Retirement_Garage_Door >= 50 And 'MyQ / Main Door' Door State is Closed Then run next program (then path)Else - No Actions - (To add one, press 'Action') next program: If nothing Then Set 'MyQ / Main Door' Open Wait 1 minute $Retirement_Garage_Door = 0 Else - No Actions - (To add one, press 'Action')

I do not recall a "resume" type of command. While I imagine creative programming techniques could achieve your goal, I am not sure that there is a canned command for this. Without thinking too much about this, I wonder if you could insert a condition in your programs which would trigger them at the conclusion of your 15-minute wait period. What I imagine might be even harder would be to resume prior status, regardless of whether the result of a program, or manual control.

OK. Try mouse-click on the lts low (IRLinc Reciever) within the scene definition. Check to be sure the ramp rates and ON levels match those shown in your snip. (Most likely they do not.) Remember, responder levels can be different for each controller.

I had the same experience as Asbril (though I do not know from where he was talking on the phone). He went well above the call of duty.

I am not in a position to confirm, but current month is one of the system variables, I thought. In fact, I think I use it in one of my programs.

I believe it was available in 4.x, but who wants to update this condition every year if there is a convenient way to avoid doing so.

I have played around now with both echo and google devices. I am underwhelmed by both. My particular hub has a bad habit of reverting back to “set up with google home” messages on the screen, but I think it is related to a particular location in the house (in proximity to ipads and other bluetooth devices). One thing I prefer with the hub is direct control over a roku device. I also find it a little better at recognizing vocal commands than an echo. I like the display of the home hub, also, but find it expensive for the value it offers. I dont like voice control in a bedroom, so I find the hub to be not useful for the obvious location. I dont like thatthere is very limited touch control for some very basic functions (like setting or disabling an alarm). On the echo, I like the “drop in” function as an intercomm. I really dont like that neither can be configured for specific hubs/echos to control specific, but different, harmony remotes. I find both to be roughly equal at controlling my lighting and other devices.

Sure. One first has to create a program which assigns the value of the month system variable to a variable created by you. You would then use that variable as a condition in the program to turn on the pool light.

So...you have three PLMs total.. a plm hooked to the ISY and then one on each end of your rj45 cable?

I don't know how important it is to use the node server, but hue lights can be controlled via network resource also, assuming you have the network module added to your ISY. This approach would, I expect, allow one to cycle through different hue light settings (Color, brightness, etc...) in the way you desire. But, I see you figured this out so...never mind.

Absolutely! If your devices are keypad buttons, this is exactly the way I would do it. The only question is whether you want the button in a perpetual state of ON or OFF. That sure sounds like his suggestion...to avoid consolidation. While I have not tried this program, I must admit that it would surprise me a bit if his concern turned out to be realized. Theoretically, I guess the consolidated program could cause an infinite loop, constantly changing the variable value and retriggering itself, changing the value again, retriggering again...etc.... I was just not sure that theory holds out here, whether by design or just the nature of computer latency. My nature is also to use a single program but, perhaps, it is safest to keep them separate in retrospect.

You may want some parentheses. Furthermore, it might be possible (or even beneficial) to combine your two variable programs (programs 1 and 2): If $KitRopeFav is 4 And ( 'Kitchen Lights / KPL Kitchen - Breakfast / KPL Kitchen - Unused F' is switched On Or 'Kitchen Lights / KPL Kitchen - Breakfast / KPL Kitchen - Unused F' is switched Off ) Then $KitRopeFav = 1 Else $KitRopeFav += 1 As your programs were, both would have triggered and run TRUE if you tapped the OFF side of your switch. Have you checked the value of your variable lately? Might it be higher than 4? Do programs 3 and 4 run properly if you select, right-click, run then?

Or "restore" links. Of course, the motion sensor must be awake in order for this to work. Is this the only motion sensor you have? (Do the others work?) ISY sees comms between all other devices just fine? Can we assume that the PLM is a dual-band version? Can we assume that the PLM is not plugged into a UPS or into a circuit that contains lots of electronic gadgets including UPS, computers, routers, power supplies, etc....?

I recall a thread about the use of 2 ISY devices, communicating with each other via network module. Unfortunately, I cannot find it. Perhaps another can remember it. That seems to me to be the most promising option.

If this fails to work, I would be looking at issues other than programmatic. And, as I said, it depends on your goals. If you want only to trigger when the switch is manually activated, use control conditions. If you want to trigger when the switch is turned on in any way (manually, program, scene) then use the scene condition as suggested by paulbates.

I recall a recent post with similar intentions. Rather than hang the outdoor module from the pole, why not get a short extension cord and plug the module into that. The extension cord would only have to be long enough so that the outdoor module could be sitting on the ground. I have several insteon devices in unconditioned space (no direct exposure to rain or snow). They seem to hold up for me.

Using status may be the easiest approach, but would depend on your goals. If you desire only to track and react to the switch being manually turned on (as opposed to being turned on as a scene responder, for example), another approach could be: if control 'bonus' is switched on and control 'bonus" is not switched off then ….unchanged....

I use, also, a couple of z-wave sensors. I have not noticed one being better than the other as far as battery life. I, too, get much more than a couple of months with both insteon and z-wave sensors. Maybe a year...maybe more.

In the case of ISY-994, a controller is, by default, also a responder.

I don't believe anything has changed due to the major overhaul. I think the advice can still be good, but would depend on conditions. If your conditions can often get triggered, but often false, or if your action can re-trigger the program, it might be good to separate the condition from the action. Such a separate can prevent the triggers from interrupting wait statement and repeats. An example: if time is sunset and status light is off then turn light on wait 2 hours turn light off else nothing When this program triggers true, it will run, but immediately re-trigger (false) and halt the wait statement, re-running the else path. In this case, best separate the conditions and actions.