Michel Kohanim

Hello Rand, Yes, unfortunately we still haven't figured out a way to allow more than one button from the same KPL to be in the same scene. Apparently KPL cannot send a group command to itself! Do you have any ideas on how to fix it? As far as release 2.3: yes are up to our noses and have not yet fully tested everything. We are hoping to have it fully tested and published soon. Thank you all for your patience, With regards, Michel

Pioneer, For more technical information, please refer to http://forum.universal-devices.com/viewtopic.php?t=21 . You got it right! All you have to do is to make a scene where A, B, C, and D are all controllers. As far as which settings control what: If you click on the Scene icon on the Nav Pane (to your left), to your right, at the bottom, you are given the option of setting on level/ramp rate for all the members of that scene. Please note that these setting are only applicable if you turn on/off that scene through ISY. Now, for each controller with in a scene, you have the option of having different on level/ramp rates for all the other members of the scene. To do so, within a scene icon, click on the controller icon you'd like to adjust. To your bottom right you will see all the permissible on level/ramp rates that you can adjust for all the other members of the scene. I hope I've been able to answer your questions, With kind regards, Michel

John, we've experienced a lot of communications errors in the presence of malfunctioning X10 devices (they start bombarding the network with noise). Do you always have the problem? Do you remember the name of the person you spoke with at SmartHome? Based on Insteon spec, this does not sound logical at all. I'd like to hear more from the person who gave you this information. I suspect timer switch malfucntion. I am more of the opinion that you have a malfunctioning/intermittent X10 device on the network. -John

No. ISY acts as a liason if and only if you want to use ISY triggers/scheduling/access on the web. Yes, absolutely correct. Partly 100% correct Unfortunately, although the firmware supports it but we had to remove it from the applet as it made everything more confusing; i.e. for each device, go through the linked devices, if there's a controller in the linked devices, do the same, continue till you find all the linked controllers. When done, check each controllers linked responders and figure out which set of responders are the same for each controller and then make a group. In most cases, we ended up with disjoint sets and thus created spurious groups which had to be removed/merged. Yes, there's a much easier way: make A, B, and C all controllers in one scene. In this case, then, all switches will follow the status of one another If I understood your question correctly, what I suggested in the previous step should fix your problems. With kind regards, Michel

John, First of all, I have to address your concern: ISY is in the loop if and only if 1.You are programming (creating scenes, adjusting ramp rates, etc.) 2.You want to use ISY's scheduling/trigger functions In short, when you are done programming switches/buttons/scenes you can simply unplug ISY and all your buttons/scenes should work as programmed. The reason that you cannot see the the state of your KPL button, is that for KPLs, only the load button is associated with a status (on/off/level). The rest of the buttons (A, B, C, D, ...) do not have any states unless they are part of a scene/group. In this respect, then it seems to me that you are trying to use your existing links (between the timer and the KPL) which means that ISY's PLM is not part of the scene and thus ISY shall never be notified of any changes on the KPL buttons (except for the load). If I've been able to allay your concerns vis-a-vis a third item in the loop, may I humbly ask you to: a. Create a scene b. Drop your timer as a controller into the scene c. Drop you KPL button as a controller into the scene d. Right mouse click on the KPL button and choose Restore Device e. Right mouse click on the timer and choose Restore Device In this scenario, everything will work as you suggest + ISY (if plugged in) shall be notified of the changes either on the KPL button or the switch. With kind regards, Michel

John, Thanks so very much for the feedback. I would like to caution that using multiple timer modules in combination with ISY scheduling/triggers might have unpredictable results unless one can make sure that none of the timers and ISY schedules/triggers are overlapping/conflicting; this could become quite a daunting task. ISY in and of itself, tries to minimize overlaps/conflicting schedules. Now, I am very concerned with your statement: It is of utmost import for us to make sure ISY functions properly. Would you be kind enough to elaborate a little on your issues with ISY communications? I would sincerely appreciate it. With regards, Michel

sfhutchi, Yes, you got it ... the time element shall be incorporated into the triggers in our release 2.3. With regards, Michel

Mark, Not that my opinion matters for I am biased! But, why wouldn't you want to try ISY scheduler first and see whether or not it meets your expectations before spending money on a TimerLinc? With regards, Michel

Very interesting! As far as your KPLs not working properly (for the non-dimmer mode/toggle) we should have it fixed in the next release. Thanks so very much for both of your contributions, With regards,

sfhutchi, Consider it done ... With regards, Michel

Hi Rand, I hope you are enjoying it! With respect to having to do an air-gap, you would only need to do it: a. If the controller, within a scene, needs its own on level/ramp rate. The reason for this is that an Insteon Device can not be a controller for itself (the same reason that you cannot put two or more buttons from the same KPL In the one scene). As such, ISY converts your request to a local on level/ramp rate but ONLY for when you are actually/physically clicking on that controller. So, if you have controller A, and 10 other controllers in the same scene, for each controller (when they are the controlling device), the on level and ramp rates are the local on level and ramp rates where as the others are "group" on level/ramp rates b. If the controller is anything but a KeypadLinc. For KeypadLinc, we do Initialize RAM from EPROM which takes the place of the airgap I am not sure why the sliders do not get updated. You might have hit a bug but, unfortunately, I cannot reproduce them here. Would you please give me more details as to what you do and what is not updated. I'd sincerely appreciate it. With regards, Michel

Mark, You are correct. This requirement has been captured and we'll work on it in our coming releases. With regards, Michel

Tom, No, unfortunately ControLinc All on/off cannot be sensed by ISY (we are working on it with SmartLabs). With regards, Michel

Is there a way to Restore a Scene, or does one have to Restore every device individually? Rand Rand, good point! No, at the moment there isn't a way to restore a scene. You have to restore each device or, if you have time, just do Restore Devices (in the File Menu) which restores all the devices from which point on all the devices and ISY configuration will be fully in synch. With kind regards,

Mark, No. ISY does not do anything with toggle mode (yet). The only function it supports, at the moment, is button grouping (mutual exclusivity). Have you reset your KPL? You see, memory locations comprise two types: link database variables Button grouping, toggle on/off, and backlight level are all part of the variables which ISY only touches grouping. On the other hand, when you put a device in a scene, then that's when ISY starts playing with the link-database. As you see, link database and operational variables (as far as we know) are mutually exclusive except for the case when a device is fully reset. Please let me know if this answers your question. With kind regards,

Rand, good to hear but STOP before 256! Thanks and regards,

Won't this limit me to the same light level from both switches? If I want a different level/rate for each switch I will have to do as sfhutchi suggests and create two scenes, right? Rand Rand, No. Within the scene, click on the switch that you want to adjust the on-level/ramp rate. To your right, you can adjust the on level and ramp rate for each individual member of that scene. Please let me know if this helped. With kind regards,

Thartmann, Question: how about fast on/off? i.e. double click on the KPL button really quickly. If fast on/ff controls your lamp then the on level for the lamp for the KPL button is set to 0. To test: 1. Go to the scene where the KPL is the controller 2. Click on the KPL button within that scene 3. Make sure that the on level for the floor lamp is not zero (to your right) If the on level is not zero, then try a Restore Device: 1. Right mouse click on the KPL and choose Restore Device menu option 2. Right mouse click on your floor lamp and choose Restore Device menu options. With regards,

sfhutchi, The proper way for a 3-way (all 3 switches control each other) is to drop all the switches in "one" scene as "controllers". With regards,

Sloop, There's indeed an ISY Startup Trap Error bug which we've fixed in version 2.2. Thanks and with kind regards,

Clarence, Thanks so very much for your vote of confidence and your feedback. As you may have noticed, feedbacks comprise 90% of what's included in our releases. All your requests are queued for version 2.2 (please checkout the topic: What's included in 2.2: http://forum.universal-devices.com/viewtopic.php?t=31) to be released by 6.20.2007. X10 support will be released in our releases 2.3 and 2.4 but no dates have been set yet. In all likelihood, we will have some preliminary X10 support by end of July. With regards, Michel

sfhutchi, You are right ... also, we have taken your suggestion vis-a-vis Wiki and shall implement one within the next month (after we are done with triggers and X10). Thanks so much and with regards,

heatvent, my pleasure. Yes, I think we might have to do as you suggest. We are deliberating! With regards, Michel I have to quote my own quote since I just realized that we do actually provide that feature File->Restore Devices! This feature was put in there precisely because of cases where one needs to synch up Device Links to what's in ISY. For instance, let's assume you had a party where there were a lot of INSTEON experts and they decided to go around your house and do some manual linking (which would not be reflected in ISY). So, after the party, all you do is File->Restore Devices and all your devices will be in synch again with ISY. With regards,

heatvent, my pleasure. Yes, I think we might have to do as you suggest. We are deliberating! With regards, Michel

sfhutchi, We acknowledge the fact that starting afresh is a drawback of using ISY. As a side note, the functionality to "interrogate" a device is already there and that's what we started with but after a few use cases we realized that it's going to cause more confusion than good: If you have a scene with more than one controller and some responders then, interrogating is not sufficient; you would also have to "figure out" if all the responders really belong to the same scene which is something non-trivial. In most cases, we ended up with many disjoint scenes for the same group only because "one" of the devices had an inactive link (for each controller, keep an array of all its responders. At the end of interrogation, go through all the responders for each controller with the same group and see if the resulting set is the same). To make the very long story short, we pulled out the functionality because the users would then have to "merge" scenes and "delete" those not working properly. I hope this clarifies the situation further. With regards,