Michel Kohanim

Hello Mark, Thanks so very much for the offer but I think that we don't have enough time to collect enough votes. In all likelihood, we will have a 2.3 release before the triggers release. Thanks so very much, Regards, Michel

Hello Mark, In short, at the moment, we are running a little late on the new triggers/scheduling functionality mostly due to our desire to add as many new requested functions (almost on a daily basis) as possible before the release. At the same time, release 2.3 has a lot to offer including expanded support for Linksys and Buffalo routers, multi-select drag/drop, many firmware enhancements and bug fixes, etc. As such, I think we'll be releasing 2.3 without the new triggers/scheduling by the end of the week. Thanks and with kind regards, Michel

sfhutchi, Yes, that would work but then again, how would that notify the other devices of the status? i.e. they all have to master so that the status is synched up between all of them. With regards, Michel

Backlight will be supported in either 2.3 or 2.4 release. I have added your request (schedule/trigger) to our list of requirements to discuss in our weekly meeting. Thanks for the feedback, Regards,

No, I have no idea how to fix it. Triggers would be counter-productive. I think a work-around would be to create a new Scene by copying the Responders from another scene. (Copy of ...) Then one could select a new Controller (different button) and set new levels for the Responders. It would be more convenient, if not quicker, than doing it manually. Thank you, Rand Rand, I do understand and agree. Thanks so very much for your continued support, Regards, Michel

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,