Michel Kohanim

Hi Wayne, Are you saying that "without doing any type of programming" RemoteLinc has now developed its own links? If so, then this is surely a firmware bug in the RL. If not, then would you be kind enough to let me know the steps you took before this happened and the symptoms? siegeld, Did you get a chance to talk to Steve L? I think your devices are defective OR you would need AccessPoints to make sure the signals get to your switches. Please do keep me posted as it's very important for me to get to the bottom of this. With kind regards, Michel

Hello Jim, Thanks so very much and you got it right. Please do be sure to keep us posted. Mike and Jim (Mass), Thanks so very much for the confirmation. Mine also works ... I'll try to figure out what's causing reakhavoc's issues. With kind regards, Michel Yes, Michel - and thank you for taking the time to explain. The bottom line seems to be - .14 may, or may not, fix group com issues with new devices. I have a good test switch that has been a prime example of the group com problems. I'll see what happens and let you know. It will take up to a week for me to be sure - due to the intermittent nature of the problem. Jim H.

Hi reakhavok, -14 means that your login was not accepted (authentication failure). I think there might be a bug we've introduced. Would you be kind enough to contact me via email? I am going to try and have a build for you test (tech@universal-devices.com). With kind regards, Michel

Hi reakhavok, Thanks so very much for the update. We added a little more debugging information in the log. Would you be kind enough to retry a notification, check the log, and see if there are any errors? Thanks and with kind regards, Michel

Hi reakhavok, Would you be kind enough to let me know whether or not you are using gmail? Also, just to make sure it's not network related, would you be kind enough to try Synchronize with NTP button and see if it fails? With kind regards, Michel

Hello AD8BC, Yes, please do so! With kind regards, Michel

dss, I am not going to talk on the behalf of SmartHome, but from what I see, CRC and error handling IS the problem (especially in LampLincs where duplicate records are created). i.e. in light of transmission errors, what should the device do? I cannot make any other comments beyond that mostly because it will be taken out of context in other forums. Jim, I am so very sorry for not answering your question. From my perspective, there are sensitivity issues with some of the newer devices which can be solved by using Access Points. This said, however, if you've had signal issues and used 2.6.13, then on top of signal related issues, you would also experience programming and corruption issues. The core issue is signal/error handling and 2.6.13 just exacerbated it. So, now, if you have factory reset your device, restored it using 2.6.4 (in automatic mode), and still have intermittent scene activation and group commands - and if they used to work properly using older devices - then the only answer - unfortunately - is the addition of more access points. If I manufactured accesspoints, I would send all a couple for free. Does this answer your question? With kind regards,

Hi Jim, It is usually very convenient for all to declare victory and point fingers. Since 2.6.14 is EQUAL to 2.6.13 in i1 mode (only), therefore, I can only conclude the following: 1. Programming database records using extended messages does not work and it may corrupt the device ... the only solution is factory reset of the device and not to use extended messages for programming purposes (2.6.14/automatic mode, uses standard messaging for everything except motion sensors) 2. In 2.6.13, most new devices were being programmed in i2 (automatic mode), and thus the likelihood of corrupted devices 3. In our test experiments with real installations (not test lab), most (not all) of these issues were solved by adding access points As such, and at the moment, I think the problem is that extended messages are NOT being correctly repeated by i1 devices and thus sensitivity issues. I do take the blame for using extended messages for programming purposes in the first place and I attribute it to lack of clear and definitive cooperation between SH/UDI. All this said, however, missed scene commands/activations have nothing to do with i1/i2 modes. So, if factory reset and restore do not help (in case the device is corrupted), then one might need extra AccessPoints. And if that doesn't work, then it might be noise, and finally if all fails then it's a defective device. So, in short, 2.6.14 may have solved the programming issues but the signal issues are completely beyond the control of ISY and 100% in the realm of device to device communications. With kind regards, Michel

Hi Tim, I do apologize for the inconvenience. Please choose one of your problematic devices (hopefully the lamplinc), remove it from ISY, do a factory reset on it, and then add it back in ISY. If this does not solve the issue - and if possible - please move your device close to your PLM. If this solves the issue then - as much as I hate to say it - the problem is that the signals are not getting to your device (not being repeated). If not, then you have a defective device. In all likelihood, the problem is signal related and the messages are not being repeated. With kind regards, Michel

Hi Robert, Please make sure you have remote access enabled, and then send your URL/credentials/address of the KPL in question to support@universal-devices.com . We'll check it out remotely. With kind regards, Michel

Hi Robert, This is the strangest thing ever ... would you be kind enough to send me the two digit cat.subcat that you see in the top center (right below the name) of the Admin Console for this device? In the meantime, I am going to send this issue to SH to see if they know of anything that might have caused this. With kind regards, Michel

Hello Robert, Would you be kind enough to use Link Management->Start Linking instead? With kind regards, Michel

Hi, 9-5 Pacific Time Monday/Friday Saturday closed Sunday email only With kind regards, Michel

Hello CompKing, Thanks so very much for the update. With kind regards, Michel So far, so good. Been almost 24 hours, and no zero's noted. Fingers crossed

Hi to_lighter, Thanks so very much. If you have not yet enabled internet access, then, please do so ( http://forum.universal-devices.com/viewtopic.php?t=635 ). Then, when ready, please give us a call at 818-631-0333. With kind regards, Michel Hi Michel, Let me know how to proceed so that you can connect to my ISY. Cheers!

gregoryx, As per SH's recommendation, we have reverted to doing i1 for link management for all devices except for motion sensors. As such, yes, it's 100% normal to have "reads" to be much longer since in i2, you can get a record in one call. In i1, you have to do 3 operations to get only 1 BYTE (each record has 8 BYTES). With kind regards, Michel

Wayne, Thanks so very much. Found it and fixed it. With kind regards, Michel

Hi wjoel, I do not think your port is 587 nor should you use TLS. Please try the following: port 25 (default) Userid: you should get from Verizon ( http://www.emailquestions.com/verizon/5 ... tings.html ) Password: you should get from Verizon TLS: unchecked With kind regards, Michel

Hello gregoryx, Thanks so very much for the update and do be kind enough to keep us posted. With kind regards, Michel Not that I recall... but I'm not going to swear to anything. I realized later where the 100 links might have gone: I changed two rather large scenes and consolidated them into one; which I suspect lowered the link count quite a bit. I'll keep my eyes open for any other scene issues; that one really surprised me. Steve's coming by tomorrow to see that weird KPL in action; he has an idea what's going on (as Michel knows). Just thought I'd let others know. ON TO 2.6.14!

bigDvette, You should be OK. Please do be kind enough to upgrade to 2.6.14 before you attempt anything with these switches. As far as EZIO, I am so very sorry. As much as I want to immediately add support for them, I am so very frightened of all the bugs in might introduce in the process. As soon as we have a stable INSTEON environment, we'll start working on it again. With kind regards, Michel

Hi Joe, I am so very glad you were pleased. First of all, it seems that the lockup bug (0,0) has not been fixed. So, if you encounter it, please do be kind enough to send me a screenshot before rebooting. This has to do with the PLM having a spike which throws ISY off and ISY cannot recover from. Now, as far as IOLinc, unfortunately I really do not know what these options mean. Some of the options are in the quick start guide (momentary mode, etc.) but others are just those I took out of the API docs. I would be very interested if anyone could enlighten all of us as to what these options mean. With kind regards, Michel

Hi Wayne, Thanks so very much. Would you be kind enough to let me know how to reproduce it? I just changed the name of devices/scenes and the associated membership nodes got updated immediately. With kind regards, Michel

Hi Robert, If the extra links start with 0 or 22 you can safely ignore them. i.e. 0x0FF8 0x00 .... 0X0FF0 0x22 ... You can safely ignore the above two. With kind regards, Michel

Hi Gary, Aha, I see the problem ... I do apologize for the run around. This is a bug which appears to happen only with i1 KPLs ... thanks so very much for finding it. With kind regards, Michel

to_lighter, I think the best thing to do would be for us to connect to your ISY remotely and see what's going on. I have gone through all the possible test cases and they all work fine; there is something that does not evaluate to true and that's where all the problems lie. sk8er02, Which URL are you using to upgrade your ISY? Are you using http://www.universal-devices.com/99i? If not, please do give it a try. If yes, then please try the direct URL from ISY and let me know. If all fails, please do be kind enough to enable remote access and then call our tech support so that we can inspect it remotely. With kind regards, Michel