Michel Kohanim

fasttimes!!! You are indeed quite fast! This is a hotly requested feature and we will indeed include it in one of our releases in the near future. With kind regards, Michel

Hi fasttimes, I do apologize for a tardy reply ... Using Event Viewer/Level 3 you would know exactly what is causing request failed. What seems to be happening is that due to the failures, some links have not been removed. Currently, the easiest way to remove them is to: 1. Create a dummy scene 2. Put both your RL and the device that responds to RL 3. Make sure that the RL is actually controlling that device 4. Event Viewer/Level 3 5. Remove the scene altogether ... please make sure to save the Event Viewer log and send it to us in case this procedure fails We are currently working on a more direct way of removing unwanted links ... we just haven't figured out the best way of doing so without jeopardizing the synchronization between ISY and the devices. With kind regards, Michel

Hello UDNewUser, I am so very sorry to hear about all the problems you are having. Please note that 2.7.0+ had a bug with SSL and, for sure, iLinc could cause it to crash. The main question is whether or not reboot solves the problem. If the reboot solves the problem then I strongly recommend upgrade to 2.7.7 (please send an email to support@universal-devices.com). If the reboot does not solve the problem, then I must say that this is the first ever case that two units would just die irrecoverably. When you reboot, what's sequence of LEDs do you see? With kind regards, Michel

Hi tome, Grouping is only organizational and has no impact on anything else. Originally, we didn't show the status for sub buttons but due to very popular demand we had to add that feature. With kind regards, Michel

Hi fasttimes, We have considered so many different possibilities including a semi/protected virtual machine ... at the end of the day, though, we just need more resources to help with development. With kind regards, Michel

Hi fasttimes, Are you certain that the size of the second zip file was zero? Please note that Windows has a problem unzipping a zip within a zip (you need WinZip or AllZip). Not all files are in XML. There many low level files that are in binary. On the other hand, you can get device configuration, nodes, and other system settings by using either our Web Services or REST interface. As such, you can still get access to the information you want but NOT by reading the contents of the zip file. With kind regards, Michel

Hi sanders2222, Thanks for the update. If ISY still has a hard time writing the links, I am bound to assume we have signal issues. Is it possible at all to move this device (even temporarily) close to the PLM and see if it exhibits the same behavior. During Restore, ISY drops all the links from the PLM, defrags the device database (getting rid of 22s), and recreates everything from scratch. So, if the process is interrupted in the middle, some of the links may not be recreated (as such you may assume they have been dropped). With kind regards, Michel I did the factory reset at the device. But the restore device on the console shows the same error message. That would mean the device is OK. When I list the PLM Links, the only lines I see for the device are: 002A : E2 00 12.60.E0 01 01 37 002B : E2 00 12.60.E0 01 01 37 This indicates my PLM lost the ‘A2’ link. The device worked properly earlier today. What is the reason a link is suddenly dropped in the PLM?

Hello jsmith6, We should have 2.7.7/2 out by the weekend, a week of testing, and then Beta. With kind regards, Michel

Hi Brian, Yes, this is correct. You can supply ISY with up to 30 volts and it should work fine. The minimum is 5Volts, 300 mA, and 2 mm barrel connector. With kind regards, Michel

Hi fasttimes, Good question! The answer is basically limited resources ... ISY firmware is quite complex internally with quite a number of modifications in the OS/kernel to achieve network performance and concurrency. Although everything can be ported to Linux or Windows CE, the major hurdles are integration and reliability testing for which we currently do not have any resources. With kind regards, Michel

Hello backinthelab, Actually, firmware version 2.7.7 is much more stable than 2.7.6 and as such I certainly recommend upgrading. With kind regards, Michel

Hello capsterx, Would you be kind enough to let me know the firmware version of your SWLs. You can find this on the top center of the Admin Console screen when you click on that device. In some rare cases, SWL 35s exhibited some signal sensitivity issues. With kind regards, Michel

Paul, Rest assured that we are working on it ... the main issue right now is time/resources and the level of complexity attached to supporting variables. It's our practice to either do something 90%+ or not do it at all. Thanks so very much for your patience. With kind regards, Michel

Hi rogressem, Yes, one responder can be controlled by many scenes and many controllers. With kind regards, Michel

Hi to both, Please note that our next release 2.7.7/2 would allow for the thermostats to be in scenes as both responders and controllers. With kind regards, Michel

Hi fasttimes, for IR input/multiroom - and although more expensive - I recommend IRLinc. With kind regards, Michel

Hi backinthelab, ergodic is 100% correct: Motion Sensors are responder only and, on top of that, they are battery operated which means that they do NOT hear anything while they are in sleep mode. With kind regards, Michel

Hi guys, Network module can be purchased by going to Help | Purchase Modules on the Admin Console. The price is $49.00 and you would need 2.7.7. Here's some documentation: http://www.universal-devices.com/mwiki/ ... Networking With kind regards, Michel

Hi Paul, The errors with a very small batch of SWL35s were mostly signal sensitivity and unreliable group handling issues. Some of your SWLs might be from that batch but the best way to test is to do a Scene Test (Tools | Diagnostics | Scene Test) for one or more of your scene wherein there's at least one SWL35 and one non-SWL35. If the SWL35 fails randomly but the other device does not, then in all likelihood the switch itself is the issue. If you have used the third option (import existing links) when you added your devices to ISY, that would explain why you would get spurious links when you restore. Although it might take longer, but in the long run, you will be spending a LOT less time if you started from scratch for your most important devices. With kind regards, Michel

Hi Moshe, thanks. I do not think the problem was Cisco related. It's surely network related but we didn't have enough constraints in ISY to throw away bad NTP dates. With kind regards, Michel

Hi fasttimes, In ISY, the process is quite simple and done it 4 steps 1. Highlight all those switches and drag and drop them into a scene 2. In the next dialog, make all of them controllers 3. Have coffee while ISY programs all these devices with cross links To make all of the switches have the same on level ramp rate: 1. Adjust the on level/ramp rate at the Scene 2. For each controller that you wish to have the same on level/ramp/rate click a button called "Apply Attributes from Scene" For more information, please checkout our Wiki: http://www.universal-devices.com/mwiki/ ... ide#Scenes With kind regards, Michel

Hello jimkoke2, Unfortunately ISY does not yet have variable support. It is in our roadmap for version 2.8+ (currently 2.7.7). With kind regards, Michel

Thank you both ... support should be available shortly. With kind regards, Michel

Hi Paul, We have had cases where SWL 35s were the actual culprits. And, I am specifically talking about v35 ONLY. How old are you switches? Would it be possible to get replacement for them? With kind regards, Michel

Hi Moshe, it's possible that your ISY has gone back to 1941 (please check your logs to ensure this is the case). If so, this is a know issue and fixed in 2.7.7. If you are interested, please send an email to support@universal-devices.com. With kind regards, Michel