Michel Kohanim

Hello All, 2.5 Beta is now available with the following enhancements: 1. X10 Support 2. Enhanced Triggers/Schedules 3. KPL Relay, OutletLinc, SWL 2.0, and INSTEON thermostat (beta) support 4. Full integration with ELK For details on the New Triggers/Schedules read the Wiki http://www.universal-devices.com/mwiki/index.php?title=New_Triggers/Schedules&oldid=1667 Please contact tech@universal-devices.com for instructions. With kind regards, Michel

Mr. Nichols, First of all, apologies for a tardy reply. To be honest, we never thought about it and now that I read your post, it makes 100% sense: we are doing things backwards! Your requirement has been added to our list and shall be reviewed and implemented as time/resources permit (after 2.5). Release 2.5 Beta is ready and is being sent to a select few who are interested in our Beta. If you are interested, please send an email to tech@unviersal-devices.com. In short, these are the new features: 1. X10 support ... you can trigger X10 devices or use them as triggers 2. Trigger schedules and schedule triggers 3. Add wait, repeat, random to your sequences + a lot more. Thanks so very much for your feedback, With kind regards, Michel

siegeld, Unfortunately, INSTEON does not allow sending preset dim levels to a scene. As per philosophy: that's why each device belonging to a scene already has a preset DIM associated with it! We would've it loved if your scenario worked as we do get a lot of requests for that functionality. With kind regards, Michel

alf, Hello and apologies for a tardy reply. With respect to your question, we do have pre-2.5 (beta) release coming out shortly (early next week) which allows you to do as you described below + a lot more. With kind regards, Michel

Dave, Thanks so very much for the quick feedback. Here's what's going on: - For devices that may never be controllers such as LampLinc, InlineLinc, and lately OutletLinc, ISY solely depends on the linkages as they are made during the linking session; i.e. ISY does not create a Master link in the device and a Slave link in the PLM. As such, if these devices are not part of any other scenes, therefore they will not respond to All On/Off command issued from the PLM. - ISY does create master/slave links when a device, regardless of its type, is put inside a scene and, therefore, all the devices that are already part of a scene will respond to All On/Off command. To test this scenario, please create a dummy scene and put one of your non-responding devices inside that scene. Please ldo be kind enough to let me know of the outcome. Again, thanks for your feedback, With kind regards, Michel

Hello Dave, Thanks so very much for the update. May I humbly ask a few questions: 1. Did you import existing links from a previous installation? 2. Did you do a File->Restore Devices (not individual Restore Device)? As far as your question, here's the only reason why an INSTEON device would respond to on/off from the device page but not from All On/All Off: When you are on the device page, ISY is sending a direct command (through the PLM) to the device. This does not require any linkages to be set in the device and, thus, it works. When you send an All On/All Off command or when you send a group command (from the scene page in ISY), then the following conditions should be met: 1. The PLM should have an existing link for that device 2. The device should have a slave link for the PLM (device is acting as a slave) So, if any of the above conditions are not met, then the device will not respond to All On/All off. Now, here are more questions: 1. Would you be kind enough to inventory the list of devices that do not respond to the All On/All Off command? 2. For all those devices, would you please let me know if they already belong to a scene (you can check that out by looking at the device page and to your right you have another tree which shows whether or not this device belongs to any groups) After receiving your input, I'd be in a better position to recommend a corrective measure. I believe the issue is due to some existing links which cause a conflict with the PLM. Again, thanks so very much for the feedback, With kind regards, Michel

Hello All, Apologies for the long silence as we've been heads down with the 2.5. Rand, Thanks so very much for your quick responses. As usual, you've been instrumental in making ISY a better product. MikeB, I am not sure why previous releases of SL do not have any feedback. riceman and marksanctuary, Thank you so very much for reporting this issue. This must be a bug which we are going to analyze and find the root-cause + resolution. At the moment, it seems to me that you have a defective PLM ... as such, please do be kind enough to report any other anomalies. In the meantime, we are going to test all new releases of SL + KPL. Again, thanks so very much to all for reporting this issue and apologies for the inconvenience. With kind regards, Michel

Hello Dave, If you have SwitchLinc versions above 2.4, you should immediately see the feedback (when you do anything on the switch). For SwitchLinc version below 2.4, you will never get the status back and thus you would have to manaully query. Unfortunately, at this point, the only thing I can suggest is to get an upgrade for your SwitchLics. Thanks and with kind regards, Michel

linuxguy, You are correct: ISY can turn on/off the load but we cannot set the timer. With kind regards, Michel

MikeB, Apologies for the misunderstanding. In that case, this is a BUG simply because the scheduler task has to run all the schedules in its queue. With kind regards, Michel

MikeB and jbev, Here's what happens: Since ISY shows that the schedule was actually run, therefore I conclude that the message was sent out but due to a lot of network activity (programming your RL), the destination device(s) did not receive the message. Is this a scene schedule or a device schedule? With kind regards, Michel

wjoel, Thank you for the update. When you say "Admin Console doesn't show", does it imply that you get the splash screen with the Universal Devices logo and "Please don't close this window"? If so, plus the fact that you can get Admin Console using the remote URL in your own network, leads me to believe that at the remote location you have a router which blocks Java applets. If you wish, you can send your remote URL to tech@universal-devices.com and I can tell you whether or not we can access it from here. With kind regards, Michel

Hello All, Apologies for a tardy reply. Yes, this is indeed an issue due to our "simplification" methods which consider all "controllers" to be always on and able to respond. This issue has been logged as a bug and shall be fixed in the next release (if not sooner). Thank you so very much for all your feedback, With kind regards, Michel Michel has been emailing me, and has confirmed this is an issue that they will fix with their next update. Hopefully he'll post in this thread.

wjoel, I am so very sorry for the inconvenience. Would you please let me know whether or not you can access ISY using the icon in Network [Vista]/My Network Places [XP]? If you can access ISY using the icon, then the problem is that of port forwarding issue in your router. Do you have a UPnP enabled router? i.e. do you get the remote URL (http://##.###.###.###:#####/0/x'>http://##.###.###.###:#####/0/x) by performing File->Enable Internet or have you manually added port forwarding in your router? If manual, please make sure: a. You configure ISY with static IP address b. Forward all traffic [TCP] to ISY port (:#####) to ISY's static IP address c. Make sure your router does not block "Java" applet downloads from external URLs If you wish, you can send me an email (tech@universal-devices.com) with your phone number and the best time to call and we'll walk through it together. With kind regards, Michel

jbev, NO. No need to factory reset all of your devices. I just posted a reply to your last posting. Please let me know if it's clear. With kind regards, Michel

Rand and sfhutchi, Thanks again and we will surely try to keep it up. With kind regards, Michel

Rand, Thanks so very much for the feedback. You are 100% correct, we never do a poll except for the 3:00 AM schedule (which is simply there to make sure we are 100% in synch). As far as analysis, I think you are right. At the same time, we have a history of the number of failed operations per device, I think we can extrapolate some minimally useful information. Thanks again, With kind regards, Michel PowerHome does polling, the ISY does not, so these figures will probably not be as useful from the ISY. I guess you could do a Query every so often, but... Michel has promised a Copy Scene, AFAIR. Using a PLC and my Group Commander program it was not a problem to create links between another PLC and other devices. The ISY PLM has no problems communicating with the PLM in my EZIO with the limited testing I have done. I hope you find the ISY to be as useful as I do to program your Insteon devices, I think it is a fantastic Insteon tool! Thank you, Rand

jbev, Apologies for a tardy reply. Here's the situation: 1. If you bring existing links, then those links are copied unadultered and the "meaningful" ones are used to create scenes/relationships. But, the links remain specifically due to siutations such as those described by MikeB. 2. If you do NOT bring existing links (choosing options 1 and 2 during link), then ISY overwrites existing links and then when you do Restore Devices, all the devices will by in synch with ISY. I hope this answered your question. With kind regards, Michel I have a bunch oif links left in my system too and restore device seems to not do anything to them. I thought restore device was supposed to resync the device with the current link information in the ISY or did I miss something?

Mike, Thank you so very much for the quick reply. Please see my comments below. With kind regards, Michel I would love to check out these links but I wonder how David would feel about this. I will have to get his permission. I had a chat with our CTO and I was wrong: ISY does not delete existing links as long as they were brought in by the crawl function. I know this is too much to ask, but is there anyway for you to verify? Also, I have added your request vis-a-vis adding links to other PLMs and it will be reviewed in our next requirements meeting. Thanks again Michel!!!

MikeB, Thanks so very much for your thorough feedback. Here are my comments: 1. Color: you are 100% right. Initially, at least, we have changed the pink! 2. Java socket error: ISY is busy and didn't have enough time to respond to a status request. It's being fixed as we speak. 3. Statistics. I guess we can do the same; we already have the log file in Excel (under tools). We could possibly create some Excel macros to extrapolate the number of successful vs. failed communications for the same device. Do you have an example of the statistics you would like to see? 4. A device to be controller for two scenes: unfortunately, early on, we had to make a design decision which precluded this scenario. The reason: less complex code for 95% of the functionality. If we do get a lot of requests, we will surely put the time and effort to implement it 5. Timed events shall be there as you described in 2.5 6. Wall mounting: you are 100% correct. It shall be done 7. KPL button not showing up: this is related to our client (GUI) code suppressing the "same" error for the same "device" within 2 seconds (considers it duplicate) ... we are working on a "predictive" solution 8. Fast on/Fast off triggers ... in 2.5 9. PLM stopping is a known PLM bug especially when confronted with a lot of operations ... working with SmartLabs for a solution 10. Creating links to other PLMs: quite feasilbe; the only problem is that they have no limitation: they can respond to 255 groups and control 255 groups. But, surely doable ... can't guarantee that we'll actually implement this functionality since we prioritize based on the the number of feedback for the same functionality 11. Floorplan: experimental, rather toy-like, and mostly cosmetic; it's slated to be completely removed. Thanks again for your feedback, With kind regards, Michel

Thank YOU very much. It could've never been possible without all the help, feedback, and suggestions from you and others who've done the same throughout. Thanks again and with kind regards, Michel

MikeB, My pleasure. I am going to start a topic to address this bug. With kind regards, Michel

Mark, Yes, thanks to outstanding feedback from our customers and users! THANK YOU ALL, With kind regards, Michel

Yes, Lutron has a patent on receiving status back from devices when controlled by a controller. With regards, Michel I'm puzzled by that, as well.

HAS, As you may already know, INSTEON - including others except Lutron - does not respond back with the status of the command that was issued; it simply acknowledges the receipt of the command (like echo). [Lutron is suing anyone who does]. As such, the only way to retrieve the current status of a device is by explict request for status which is a very expensive operation (2-3 seconds per command). Therefore, and in order to make ISY more responsive, the state of all the devcies in ISY is determined by algorithmic "predictions" of what the outcome of any command should be (regardless of where/how it was issued) and not by explicit status requests. These predictive alogrithms are accurate 99% of the time with a deviation of +/- 1%. The scheduled query is there to do: 1. Address that 1% of the time where the device does not acknowledge the command but it actually performs the operation or vice versa 2. The +/- 1% deviation 3. Allow you to note if any of the devices have stopped responding (red exclamation marks) If you are not running any "level" sensitive triggers and do not actively seek the most accurate state of all your devices, then you may safely remove this schedule with no impact to anything else. You can then manually run a query in case you think ISY is out of synch with the devices. I hope this answered your question, With kind regards, Michel