Michel Kohanim

Hello Marko, I am so very sorry to hear this. Yes, FIRM 56 does support more than 417 links (close to 2000 links). Would you please let me know precisely what you are trying to do when you get "Request Failed"? Are you trying to add one device into a scene? With sincere apologies, With kind regards, Michel

yardman 49, At the moment there's not an easy way of accomplishing this feat except for what you have already outlined. We might include this functionality in a later release but, currently, it doesn't seem likely. With kind regards, Michel

lafleur, I am a little confused: What are the other loads beyond KPL A? Are we talking about just one KPL with 8 buttons or 8 KPLs with 8 buttons? Are you adding them into a scene? Would you be kind enough to send me a screenshot of what you currently have? With kind regards, Michel

Rand, Thanks so very much for your vote of confidence!!! As always, With kind regards, Michel

RLIKWARTZ, For us, it is not good that you would have to do it manually twice a year. As Rand/Subroutine once said, home automation should be something that you do and then forget about! In any case, apologies for the inconvenience; this bug has been fixed/closed for the next drop. With kind regards, Michel

GPG, Please do not do a swap yet ... it does not work as designed in this release but it's already fixed in the next drop. In short, if you do a swap in this release, you would have to reboot ISY for the changes to take effect (which is not very desirable). Thanks so very much, With kind regards, Michel

Marko, You're 100% correct. This is a regression and has already been fixed. Unfortuantely, you cannot save your notifications setting on this release unless you already had one stored. Or, if you wish, you can use http://www.universal-devices.com/beta just to save your configuration settings and then revert back to your default URL for ISY. With kind regards, Michel

sloop, Yes, it is valid as long as you are not trying to enforce those onlevels to the KPL load from the buttons on the same KPL. So, you could have an off scene which turns everthing off regardless of what the controller sends. i.e. if the controller sends on, then the scene on levels make all the devices to go to 0% (= off). If the controller sends off, then all the devices will turn off! In short, everything off. With kind regards, Michel

MikeB, Thanks so very much! We appreciate it. With kind regards, Michel

lafleur, Yes, we actually had this fucntionality and removed it due to pool servers not responding (once in a while) and thus causing problems. It's on our list of bugs to look at. Thanks so very much, With kind regards, Michel

jgraziano, Unfortunately, we do not have official (or otherwise) support for EZxxx devices. At the moment, X10 motion sensors are the only ones that can be supported. With kind regards, Michel

marko, Excellent. Thanks so very much for letting us know. With kind regards, Michel

Jim, Got it ... it shall be reviewed and decided upon shortly. With kind regards, Michel

jgraziano, You are not missing anything ... that's precisely the function of the folder condition: to limit the run time of the programs within. You may also want to add other programs in the same folder which are constrained by the same condition as well as use your current program (the output) in other programs (resuse your programs). With kind regards, Michel

jgraziano, Let me see if I got it correctly: You simply want a tab where you can tabulate your X10 codes and assign them names. Then, you would like to use the names, as assigned in the tab, for your triggers. Right? With kind regards, Michel

Hello jgraziano, We have never tested it with 2000 so I do not know! I am so very sorry that you are experiencing this issue. With kind regards, Michel

Frank, Yes, you are correct! With kind regards, Michel

Hi Marko, We did find a bug in ISY. By any chance, did you add your devices using "Add New Insteon Device"? If so, this feature does NOT overwrite existing links and that's what's causing all your problems. As a work-around for corrupted devices, would you be kind enough to do the following: 1. If you are adding your devices by Address, make sure to follow them up with a Restore Device OR 2. Add your device using the "Start Linking" method Please do be kind enough to let me know how it goes. With kind regards, Michel

Frank, I wanted to verify that there's indeed a bug in ISY when: 1. Using "Add New Insteon Device" 2. Choosing "Overwrite existing links" Using the above scenario, existing links are NOT overwritten. This said, however, if you choose the "Start Linking" option and then choose "Overwrite existing links", then existing links are indeed overwritten. You can also follow up "Add New Insteon Device" with a "Restore Device" after the addition into ISY. Thanks so very much for finding this bug. It shall be fixed in the next release. Furthermore, it seems that 350 M.S. actually works all the time with PLMs v56 and above and intermittently with PLMs version 52 and not at all with PLMs version 4A. This is quite interesting and something that we would have to investigate more since, at the moment, this behavior is unexplainable! With kind regards, Michel

Mark, Thank you. Done and included in the next release. With kind regards, Michel

RLIKWARTZ, Please read: http://forum.universal-devices.com/viewtopic.php?t=459 Apologies for the inconvenience, With kind regards, Michel

Hello GPG, This is indeed interesting. None of the past releases have changed anything by the way of communicating with devices. The only change was that ISY "considered" devices with 00 in first/second byte as "group" commands and thus didn't update the status "in ISY" correctly. This had nothing to do with communications on the "outbound" pipe. Please do let us know of the outcome of your experiments. Thanks and with kind regards, Michel

Marko, Thanks so very much for taking the time and going through the trouble of diagnosing the issues. If I understand it correctly, your PLM is reset, your ISY is factory reset, your KPL/SL are reset, and in the first scene you create, the controllers do not control each other but ISY can control both. If this is the case, then the PLM is NOT the culprit simply because ISY can control the scene. Device to device links (i.e. your KPL to SL) do not require PLM to be functional. So, this leads me to believe one or more of the following: 1. We have a bug in ISY ... for which I have already started the root cause analysis 2. Are you sure you are putting both of your devices as "controllers" in the scene? 3. If 2 is "true", then could it be that "one" of your devices (the responder usually) is defective The next step is please allow me to figure out if we have a bug in ISY. This should not take longer than late tonight or early tomorrow morning. If we cannot find a bug/reproduce the probelm, and if the answer to #2 above is "yes", then we have to figure out which one of your devices are causing the problem. Again, please accept my sincere apologies for the troubles you're experiencing. With kind regards, Michel

Rand, You are 100% correct. The minimum delay IS 500 mS. Anything lower simply confuses the PLM and only "random" data is written to the network. The commands to change the delay/timeout/baudrate have been removed from the shell menu system but they are still accessible if you know them! With kind regards, Michel Where did you find the option for Requests Delay? I thought 500ms was the minimum for Insteon (send/receive), but only nerdlincs need to know this. You have confused me now! Rand