Michel Kohanim

Hi golfleep, Thanks so very much for the update. Would you be kind enough to try the following URL instead (you might get a request failed dialog that you can ignore): http://www.universal-devices.com/99i/2.7.7/admin.jnlp . With kind regards, Michel

Hi Illusion, You are very correct. The main question is whether or not you want the On action on the KPL to always cause an X10 to be sent between 9:00 PM and 7:00 AM regardless of the status of KPL A. If yes, then one should use Control. If no, then the program should work fine. Thanks and with kind regards, Michel

Hello golfleep, I do apologize for the inconvenience. Please try http://www.universal-devices.com/99i/2.7.6/admin.jnlp and let me know if this problem goes away. If so, then it would be best to upgrade your ISY to 2.7.7 (currently in alpha) when it comes out shortly in beta. With kind regards, Michel

Hello DEGoodrich, I am so very sorry to hear this. The iLinc/HTTPS issue was a bug that has already been fixed. It seems that the main problem is the communications with the PLM. Do you get Not Connected on all of your PLMs? Are they all versions 52 and above? Unfortunately you cannot import 99i backup into 26 due to memory constraints. With kind regards, Michel

Hi aLf, This error basically means that a subscribed client did not respond to the published events. In short, if you are using iLinc when away, and if you lose network connectivity, then ISY will drop the subscription since it can no longer talk with iLinc. I wouldn't worry about it. With kind regards, Michel

Hi, This will execute between 9:00 PM and 7:00 AM next day if and only if the status of the KPL A is "changed" to On. So, if the status if KPL A is already on, and then you press KPL A, this will not execute. If you want that to happen then you must use Control instead of Status. With kind regards, Michel

Hi fastbird1, Actually those programs should work as is since the use Control and not Status. Control means that you will get the Fast On Signal regardless of the current state of the switch. So, even if you switch is ON and if you double press the switch, you WILL get the DFON signal. I hope this answers your question. With kind regards, Michel

Hi David and happy Thanksgiving to you too! 1. The default uses our servers under the covers. So, what you've done is correct 2. Currently the format is hard coded and therefore No 3. That would be a LOT of traffic. You can use two programs one for On condition and one for Off condition. For the condition, you should just OR all the devices With kind regards, Michel

Hi ryarber, Thanks so very much. At this point, my only recommendation is to upgrade to 2.7.7 (though I do not think it's going to help). In the meantime, I have opened up a bug with high priority. Thanks and with kind regards, Michel

Hello all, Just a note on the issue of querying the IOLinc's sensor. SH engineering team let us know that: Only IOLinc versions 31+ (92+ for betas) posses the capability of returning the status of the sensor when queried. As such, if you do not have these versions of IOLincs, please do note that a query will always return the status of the relay and never the sensor. With kind regards, Michel

Hello Kevin, No apologies necessary. You have Vista's User Account settings ON. This prevents ISY to write into any directory except the temp directory. What you might want to try is this: 1. Control Panel | User Accounts and Family Safety 2. Click on User Accounts 3. Click on Turn User Account Control on or off (at the lower half of the screen) ... turn it off Retry the backup and if you are satisfied then leave this feature off. With kind regards, Michel

Hi George, Those error indicate one of the following: 1. ISY is not connected to the network ... in your case, this cannot be the issue since you can already connect to your ISY 2. For some reason your router is refusing to renew your DHCP lease ... if you can actually get to your system, then I would really not worry about this since ISY keeps asking for a lease renewal and will eventually get it With kind regards, Michel

Hi Kevin, Those files are the state files and not backup files. The backup file names have the following format: ISY-Backup.yyyy-mm-dd.hh.mm.ss.zip. Please ensure that the file is not actually backed up in the directory that you chose during backup. And finally, are you using Vista? With kind regards, Michel

Hi ryarber, If you have DHCP I would not change it. Can you tell me if you can synch with pool.ntp.org? Or, have you setup notifications and whether or not you get them delivered? With kind regards, Michel

Hi again, Thanks! Here's the link to errors: http://www.universal-devices.com/mwiki/ ... r_Messages -60001 = NTP Address Resolution Failed -60006 = NTP Server Not Responding Would you be kind enough to let me know what you are using for DNS server for your ISY? If you are using DHCP, you should be OK. But, if not, then, in all likelihood, the DNS setting is pointing to a server outside of your LAN and hence the issues. With kind regards, Michel

Hello Kevin, Can you post back name of these files? Back up should ALWAY - and without exceptions - produce a zip file. With kind regards, Michel

Hi smithjoy, Wait is interrupted if the condition becomes false. With kind regards, Michel

Hi ryarber, It should work. I just tested an IP address and it works fine. Questions: 1. Is your ISY on the same network as your router? 2. What do you see in your log. I am especially interested in errors with -6000x prefix With kind regards, Michel

Hi jcip, I am so very pleased to hear that everything is working out. Chris, 2.7.7 should solve this issue. With kind regards, Michel

Hi jcip, By brute force I mean: 1. You use Add New INSTEON Device 2. You do not use Auto Discover (you use the list and pick your device) In some cases, when #2 tries to get the firmware version from the device, the device does not respond back and thus 0.00. In some cases (such as motion sensors and triggerlincs) you do not have a choice but to use brute force. I doubt that the problems with your system are related to this. ISY uses firmware version only in a very few places and especially for KPLs to figure out what functions are supported. With kind regards, Michel

Hi jcip, I see the problem: you have added this KPL using brute force and unfortunately ISY was not able to retrieve its version number. Although quite painful, but may I humbly recommend the following: 1. Upgrade to 2.7.7 to ensure you have the most up to date device support 2. Remove your KPL from ISY and then add it back using New INSTEON Device | Auto Discover or Link Management | Start Linking I am so terribly sorry for the inconvenience. With kind regards, Michel

Hi jcip, Thanks for the info and yes it does make perfect sense in the following case: Your KPL is firmware 1.5 or below (about 2 years old) Only the newer KPLs allow for the load button to be controlled by a sub button. With kind regards, Michel

Hi Joe, Apologies for the inconvenience. Please try the following URL instead (at home): https://www.homeorchestrator.com/ssl/insteon/ With kind regards, Michel

JacquesB, Thanks so very much. This is indeed very important for security reasons. We are still trying to figure out why the IOLinc always returns the status of the relay and having this workaround helps a lot. With kind regards, Michel

Hi Mark, If your controller is a keypadlinc, then you can use the Non Toggle feature of any button from that KPL to either always turn a scene ON or OFF (non toggle). The catch is that you have to make sure you do not have any TOGGLE controllers in the same scene (such as SWLs, etc.). With kind regards, Michel