Michel Kohanim

sloop, I am so very glad you are up and running again. From the little I gather from your post, I can immediately guess that you are running out links in your PLM (currently, 417 maximum). SmartHome is testing a new PLM which has support for 1024 links. I shall send you instruction on how to get one. As far as the order in which you put the devices in scenes, YOU'VE GOT IT ... with that order, you have overcome the KPL limitation (load/sub button) while keeping the total time to program devices to the minimum. Thanks so very much for the "retry", With kind regards, Michel

Mark, Cool. It's settled then. We'll try to come up with some type of dialog/text to describe different scenarios. With kind regards, Michel

Rand, And, as usual, you come to the rescue! You are right right on about the pop-up asking the users to air-gap their non-KPL devices when the local settings have changed. As far as the labels, anything that would make it easier for the users to understand the relationship between ISY/devices/scenes is surely a step in the right direction. I think the main issue is that have not been able to efficiently explain this relationship nor has it been captured on ISY in such a way that makes sense. Thanks so very much, With kind regards, Michel

Jon, Just to make sure we are in synch: Movie Scene KPL A -- Controller .... make sure the sub-button is added before the load KPL Load -- Controller SWL -- Controller In the above scene EVERYTHING works except for having KPL A apply a different on level/ramp rate for KPL Load. Other than that, everything else should work. i.e. if you click on KPL A, then KPL Load will turn on/off. Yes, triggers will work but I think they would be an overkill for what you're trying to accomplish. With kind regards, Michel

Mark, Thank you! Anything you do with ISY, and if it has any impact to any device, it's stored. I am afraid that the concept of "Stored" may have some other connotations that would require more explanation rather than acting as clarification. You already have the answer to your last question. The scene itself will ALWAYS run from ISY. There's no other way. The controllers within a scene, will ONLY run if someone actually/physically alters their state. You cannot run controller scenes from ISY. You simply can't because INSTEON does not let you act on the behalf of another device. Now, the last item is the on level/ramp rate for the controller itself when it's controlling the scene. Obviously, since you are physically changing that controller, THEREFORE the on level and ramp rates are the local ones. So, what am I missing? With kind regards, Michel Stored means where the link/level/rate data is stored. You always have a copy of the data in the ISY. You don't always have a copy of the data in the device. As in the case when the keypadlinc load with non-load you don't store the data in the keypadlinc only in the ISY. So your saying these would be the four naming options that would end up over the slider names like I demoed above? Scene == Stored ISY & Device Scene Local == Stored Device Only Controller == Stored ISY & Device Controller Local == Stored ISY Only I can hang with the Scene, Controller, Local idea if that is what you go with. The end result I am trying to reach is a way to see if the scene is going to need me to run it from the ISY directly, because it is not going to run with a complete result from the device.

Jon, My pleasure. INSTEON has a single address for all the buttons on a KPL and, thus, you cannot send a group command from one of the KPL's sub-buttons (i.e. b,c,d, e...) to the load. In short, if you have the KPL load button and one (or more of its sub-buttons) in the same scene as controllers, then when you click on any of the sub-buttons, it can only turn on/off the load to the local preset levels just as if you are clicking the load button itself. With kind regards, Michel

Mark and sceaton, Thank you so very much for the feedback. I think we are close: 1. Mark, I am not sure what you mean by "Stored". ISY stores everything and, as such, the terminology gets more confusing. But, I like the idea of "Local" 2. sceaton, at the moment, I love your idea to spell it out: These sliders adjust On Levels and Ramp rates when controlled by " where controller could either by ISY or the actual controller's name So, this way, we should have the following: Scene - Adjusts the on levels/ramp rates when activated by ISY Controller - Adjusts the on levels/ramp rates when activated by Controller --- Add local when the Controller = one of the sliders on the right What do you guys think? With kind regards,

Jon_W, Welcome! No, your configuration is correct. Here lies the issue that you are running into: You have a KPL (or any other switch for that matter) which is a controller for a scene for which it, itself, is a responder. This means that when you click on that switch physically, you want the "load" for that switch to do something specific (on level/ramprate). This is equal to the local on level/ramp rate for that device (root device config as you referred to it). Please note that you can have a different on level/ramp rate for your KPL's load when you click on the SWL. Furthermore, you can have a different on level/ramp rate for your KPL's load at the scene level (Movie). Please do let me know if this makes sense. Thank you and with kind regards, Michel

Mike, Dim/Bright/FON/FOFF will be added in the next drop. This said, however, INSTEON does not allow sending a group command (to a scene) with the desired on level. That's why device, within a scene, has its own onlevel and ramprate. In short, you cannot issue something like: Set Scene x to 50% You can always do: Set Scene x to Dim/Bright which simply brighten/dim the scene on notch. With kind regards, Michel

Mark, Good idea. With kind regards, Michel

Mark, Sounds good but Global is not the right word since it's only applied at the scene level. With kind regards,

siegeld, My pleasure ... please don't hesitate to contact us with your questions vis-a-vis JSDK. With kind regards, Michel

aLf, You are 100% correct. I am sure that there "must" be a solution out there so let me see if we can come up with it. Thanks and with kind regards, Michel

Hello siegeld, It's quite simple: UDProxyDevice dev = ISYInsteonClient.getDevice(); if (dev == null) return false; dev.queryAll(address, true); Please note the following: 1. ISYInsteonClient is the superclass of your class 2. The first parameter for queryAll method is the address of the device or the scene as a string 3. The second parameter for queryAll is whether or not the given address points to a device or a scene May I humbly ask why you would want to do "schedule" maintenance in the code? You can simply use ISY's Admin Console to schedule the query (for whatever time you wish) on any device, any scene, or even My Lighting (all the devices). As a matter of fact, you should already have a schedule for 3:00 a.m. which does precisely that. The advantages of the above are: 1. You don't have to maintain the schedules in your code 2. Whenever the schedule is run, you are "notified" of all the changes and you can act accordingly through the following callback method: public void onModelChanged(UDControl control, Object value, UDNode node) ; 3. It's much more efficient to have the query schedules since ISY will only query the status if scheduled otherwise it will try to query the on level and ramp rate as well. With kind regards, Michel

aLf, As long as ISY is "part of the outage", then as soon as it boots up it shall a) try to query all your devices for their states run any schedules that you might have set (i.e. from sunrise to sunset). So, you could simply have the Away schedule which turns everything off at sunrise and everything on at sunset. In this scenario, then, depending on when the outage took place, your lights are either turned on/off. I hope this makes sense, With kind regards, Michel

sceaton, My pleasure. You are 100% correct. In every scene, we create the master/slave links for the PLM, and we create the relationships between controllers/responders. Please also note that we are limited by the number of links supported by the PLM, so we did our best to reduce the number of links required in the PLM. In your scenario, you would have to have 3 different scenes, all with the same devices and thus 3 times the amount of links required in the PLM. With kind regards, Michel

shawn, I hope I've been able to answer your question in the other thread. The main reason is this: 1. Coming Home/Leaving Home Scene 2. Assume you have a KPL at the entrance 3. Assume you have a KPL at the exit Now, assume you have a program to turn on your Coming Home/Leaving Home Scene at 5:00 PM everyday to 60% at a ramp rate of 2 mins and turn them off at 8:30 AM. So, for this to work, at the Coming Home/Leaving Home scene, you adjust all the on level/ramp rates for all the responders to 60% and 2 mins. Ok, this takes care of the on level and ramp rate at the scene level Now, assume that on your entrance KPL (when you come home), you want the lights closest to the entrance turn on immediately and the lights closest to exit turn on last (say 2 minutes later). So, now you can adjust all the on level/ramp rates for all the responders in that scene just for this KPL button. And, you can now do the reverse on the exit KPL. So, all and all, you can have different on level/ramp rates at many different levels and all of them are written to devices. With kind regards, Michel

Hello sceaton, You can do all that you suggest and quite easily. If you don't mind, please read this thread http://forum.universal-devices.com/viewtopic.php?t=14 . I think it will surely shed some light on how things work. In summary: 1. Setting on level and ramp rate on devices under My Lighting only impact the local on level/ramp rate; i.e. they take effect if and only if you do something to the device physically. 2. When you click on a scene, adjusting the on level/ramp rate for all the controllers and responders on the scene take effect if and only if they are activated by ISY (such as a schedule that turns on/off that scene) 3. Now, you can click on any controller within a scene, and then you are able to adjust the on level and ramp rate for all other devices in that scene. These settings will only take effect if you do something to the controller (such as your KPL button) physically. In short, you have full flexibility of adjusting on level/ramp rates any which way you want. With kind regards, Michel

Mark, I think we have to go back to the basics: If you click on XYZ, then adjusting the sliders for KPL1.1 and ILL are applied IF AND ONLY IF you scene is activated by ISY If you click on KPL1.B: It can only turn on/off our KPL1.1 (load) --> NO SLIDER The onlevel/ramp rates for the ILL, take effect IF AND ONLY IF activated by KPL1.B (when you click on the B button) Regards, Michel

Mark, The debate to use Else vs. Finally is still open as such we a little hesitant doing cosmetic changes where a functional change is required. With kind regards, Michel Could a hover bubble noting this above statement be added to the "If" text so users could remember its function. Personally I can't remember ever learning about it in all the classes I took so it may be remote concept to most people.

Mark, I think you and I are talking about two different things: Let's say you have a scene: Scene XYZ: KPL1.1 - Controller KPL1.B - Controller InlineLinc - Responder Now: If you click on XYZ, then there are are sliders for KPL1.B If you click on KPL1.1, then there are NO sliders for KPL1.B If you click on KPL1.B, then there are NO sliders for KPL1.1 So, which sliders are you talking about? This scenarios have been tested numerous times. If you see a slider where one should not be, please do send me the screen shots. With kind regards, Michel 1. There is NO slider for the Load button if you click on the sub-button

Mark, Thank you. We'll revisit for the next release. Regards, Michel

Mark, Should already be fixed. Thank you, Michel

Mark, Thank you. Known issue which shall be resolved. With kind regards, Michel

Mark, Thank you so very much. We'll check into the fast on/off issue. But, since relays don't have ramp rates, I am not sure how much sense it makes to have both: they do the same exact thing. Regards, With kind regards, Michel