sfhutchi

My understanding is that you must add that button to a scene. That KPL button may be the only thing in the scene, but it will then turn 'on/off' when you call that scene.

I mainly added the 'wait 1 hour' and turn off bath light as a safety net to ensure that I didn't leave the light on. Normally, I would turn off the morning program as I leave the bathroom. I have this as a 'toggle' button on the KPL. I could let it turn off on its own, but I am usually there in much shorter of a period of time. Eventually I will try to add a motion sensor in the mix and play with this. With the current code, when I press the 'Morning' toggle on the KPL to 'end' it early, the 'Else' runs and the bath light immediately turns off. It doesn't seem to retain the same 9 minute ramp that I see if a separate program sends the 'off' command.

Thanks for the suggestion Rand. This is exactly what was happening. This must be an anomaly of the KPL or Insteon? Since the 'Else' worked perfectly by simply setting the device to 'off' (with no long ramp rate), it is odd that another routine essentially doing the same thing will use the last long ramp rate.

I have two programs that don't appear to play nice. This first one is a 'morning program' triggered by a button on a 8 button KPL (that also controls the bathroom light). By itself, the program works well. If I let it runs its full course, it will leave the 'Bath Light' on for an hour. If Control 'Master Bath Light - Morning' is switched On And Control 'Master Bath Light - Morning' is not switched Off Then Set 'Master Bath Light' 20% Wait 20 seconds Set 'Master Bathroom Fan' On Set Scene 'Slow Master Bath Light' On Wait 1 hour Set 'Master Bath Light' Off Set Scene 'KPL - Morning' Off Else Set 'Master Bath Light' Off Set 'Master Bathroom Fan' Off I have another simple program triggered by a double-press off at a normal Switchlinc Dimmer. If Control 'Master Bedroom Light' is switched Fast Off Then Set 'Master Bedroom Fan' Off Set 'Master Bath Light' Off Set 'Master Bathroom Fan' Off Else - No Actions - (To add one, press 'Action') If the 'Morning Program' is still running (Bath Light is on), triggering the second program will turn off the 'load light' for the Bath Light on the KPL... but the Bath Light will stay on. Do I need to have this second program 'stop' the first program if it is running? How do I properly handle this? If the second program is sendind a 'Bath Light' off command, why does it stay on?

Good to know. Some retries on programs would be great. I have found Insteon to be fairly reliable, but I am shooting for 99.99% since I am comparing this to hard wired. I am actually considering running some timed programs more than once just to be sure that all lights in a scene or in a program get at least 2 opportunities to run. I know that it isn't clean, but like I said... I am looking for 'rock-solid'.

I only ran it for less than 2 days. I will upgrade to 2.4.12 and see if there is anything. Possibly my PLM was on the fritz also.

I understand. Thanks for considering it though. The more I play with the Insteon stuff, it is clear that it is fairly stable... but since I am not upgrading from something less reliable like X10 (as I hear), it still is clear that it is not perfect. I am hoping that something like the ISY can take Insteon to the next level of reliability by highlighting devices that are historically unreliable, monitor scene commands for success, and even include some built-in retries for commands that are unsuccessful outside of the Insteon redundancy. I know that this is a lot to ask for, but UDI has proven that they are at the fore-front of this stuff, so if there is any chance of it happening, I am sure that it is here.

If a program includes multiple item in the 'Then' section, and one or more of them fail, it would be helpful to have an indicator of this in the console? Right now, it simply shows that the program was run, and completed. If one or more of the devices didn't respond.. then it is not clear.

Yes it is a problem that I had seen in the past, but this was resolved with the Signalinc on top of the PLM. It has been solid since. The current issue appears to be related specifically to 2.4.11. Even devices that don't report as non-communicative can't be controlled by the console. Switching back to 2.4.10 resolved it.

Well... I am officially back to 2.4.10 now. Before doing this I cleared the browser cache, opened and closed the console multiple times, left it alone overnight to rest , rebooted ISY, restored PLM. Finally reverted to 2.4.10 and things are back to normal.

Well... C Martin did call it 'Problems'... so you could say that he gave it the benefit of the doubt. I too had problems with the initial install. Even after things have 'died down', I can't communicate to the switches from the console. The schedules are working though. I did not see this with any of the previous upgrades. I will continue playing around with it.

Well... With a few more closing browsers and logging back in.. I can get the programs enabled... but I am randomly losing communication to devices that historically have been rock-solid. I even have devices that are side by side where one lost comm and the other is still there. Have to LampLincs plugged together at the pass-through where one lost communication. Before returning to 2.4.10... I will reset the PLM and ISY. Does anyone have a trouble-free 2.4.11 setup?

Yes... Definitely something going on here. I can't enable the programs either. Clearing the cache has no effect for me. Also, every other time that I log on (out of 5 times), 10-20% of my devices are no communicating with ISY.

The persistant 'query' window continues to be an annoyance. I am not sure of the value of continually forcing this to the foreground is. Unless this is a Windows issue, I suggest removing this... or simply adding something to the main console to show that there is activity in progress. As an example, after I upgraded, I queried the system and it took about 4-5 minutes. Not really a big deal because I could switch to other programs on my desktop... Unfortunately, the 'query' window continually closes and then opens another that forces itself to the foreground. Certainly not a show stopper, but annoying nonetheless. *After I first installed 2.4.11 about 20% of my devices could not be communicated to by the ISY. I closed everything and reloaded and then didn't have any problem. Not sure that this is an issue, but thought I would mention it.

I understand. I guess that it is a good sign that we have already been talking about new features... meaning that we are very comfortable with the current functionality.

My current thought is to at least try this with a very limited implementation. For example, allow the ability to save and resume just 1 or 2 devices to start. Maybe this is something for a parallel Beta (or Alpha) activity??

I second that!! Awesome little box!

That is a good idea, though it should not be considered an annoyance. The ISY makes it very easy to change scenes or create new scenes. Yes... I don't mean that creating a new scene is an annoyance, I meant that if the system allowed you to take actions for specified activities and then return to whatever state they were in... this (in my mind) is less of an annoyance then it always returning to what I (the scene programmer) thinks that it should be at that time. I want my programs to be able to react to the changing environment. For example, Right now I have some hall lights come on at a very dim level at some time in the evening. This works fine, but many times people are turning them up... or off. No problem... that is what switches are for. My next step is to add some motion sensors to these areas so that I know when people are in this area. Based off their presence, I will want to go to a higher brightness level for a period of time and then return to wherever it was previously set. This is less obtrusive (and more adaptable to the standard home environment) than returning to the scene that was originally scheduled at that time. Possibly there are ways to get closer to where it was by creating multiple programs with one looking for a light off, and one looking for a light on and then at least trying to match it a bit closer there. I'll have to experiment a bit with it... but it certainly would be nice to be able to return to the 'level' in progress.

I like it Mark. This is probably something for a future version as I know that these guys are interested in releasing 2.5... but I hope that it becomes feasible to do this at some point. It is amazing as I look back though at the major functionality improvement that we have seen with the ISY. It went from a nice standalone scene editor with basic scheduling and triggers to a full-blown complex programmable home automation appliance for Insteon and X10. This all in such an incredibly short time. I can't wait to see the future innovation out of these guys!

My thought is that the 'reality' of a household is that the wife, the kids, and the guests use switches and dimmers as they see fit. If I have a triggered event, I would like things to go back 'as they were'. My general theme on any of the automation that I am doing is to make it as unobtrusive as possible. I think that you solution is good, but there will likely be those scenarios where someone changes one of the settings and then you return to your programmed scene. Eventually after enough annoyance, you will adjust your scene to match the new 'preference'.

Exactly. I realize that it would require some resources to do it, but maybe something like this could be implemented in a limited fashion. I realize that there are some ways to implement some programs to return to some level... but in each of these cases you have to 'assume' what the settings were.

With the current functionality, you must click on the scene and adjust the sliders from there..... Also, if you want the controller to have the same 'scene' settings, you need to click on the controller and either manually adjust the sliders to match or use the 'copy settings' button. I agree that this isn't very intuitive. Theoretically there are times that you might want slightly different settings from a scene whether you call the scene by name or by on of its controllers... but I think that this just adds confusion. In my experience, I think that when you drag a controller to the scene, that controller should take on the settings of the scene. If someone needs another similar scene, I think that another should be created. Keeping it simple. If people don't want to completely recreate one... just use a 'copy scene' function.

I know that there is a function to query certain devices (or all devices), but can these be saved? For example, if I have something trip a certain scene like an 'all on' for security purposes (say a motion sensor trip)... can I change the settings of these devices but then return them to their original settings when the program was first triggered? For example: Query Device A Query Device B Query Device C Run Program Security Lights Wait 10 Minutes Resume Device A Resume Device B Resume Device C

Good to know. Sounds like it is at least worth $20. Does anyone have experience with any other route? Is the delay avoidable?

Excellent tip... Thanks!