Michel Kohanim

Mark, We do not use XML in the logs. With kind regards,

DEGoodrich, This device is not supported! Brian H, please do let us know what you find. In most cases, for devices that are unsupported we simply use on/off metaphor. With kind regards, Michel

jgraziano, I don't think this is a CL issue simply because out of the two devices in your scene one works and one doesn't. I believe it has to do with the device itself not getting the group command (or not responding to it). My suggestions: 1. Check your logs for -2 and see if you have any for that device (device comm error) 2. If you do, try an airgap/reboot on the device in question and follow it up with 4 or 5 queries 3. If 1 does not fix the problem, try Restore Device Please do let me know what you find. With kind regards, Michel

d_l, I am so very sorry for the problems and issues. If you do not have Excel (and are running Windows), currently the only way to get to your logs is as jgraziano suggested. On MAC/Linux, you are given the log file as is. We do have a requirement to provide this function without Excel on Windows so, please do be kind enough to use jgraziano's suggestion as a workaround. With kind regards,

Hello maui4marko, I wished you had taken our advice (about 2 months ago) and upgraded your ISY to 2.6 which has a lot of work arounds for PLM spikes due to power outages (and especially those lasting more than 10 seconds). If we can get your system up and running again, the first thing we should do is the upgrade to 2.6. Secondly, please note that when there's a power outage your cable/dsl router is also impacted therefore it's always very important to make your ISY use static IP addresses and thus when it comes back on, it doesn't have to go and reconfigure your router. If your subsequent dim/bright do not work (you keep getting the system busy dialog) then, in all likelihood, your PLM is gone. To troubleshoot, unfortunately so, we have to have your neighbor power on/off and let us know the status of the RX/TX/MEM/ERR lights on ISY. If RX is blinking every 4 seconds, rest assured that your PLM is probably defective. Please do keep my posted. With kind regards, Michel

maui4marko, Thanks so very much for the update and so very sorry for the inconvenience. I have captured it as a bug and we shall take care of it as soon as possible. With kind regards, Michel

Hello gwarthur, Please find my comments below. With kind regards, Michel Yes! Mostly because otherwise you are going to have links in devices that ISY does not know anything about and therefore, upon programming, is going to overwrite links and thus cause unexplained behavior: lights that used to turn on no longer turn on or other lights that never turned on now turn on. With kind regards, Michel

evarsanyi, Now I understand! We shall be working on Trigger 2.0 and some X10 enhancements in the next releases! Thanks so very much, With kind regards, Michel

Hello again, Ok! Now I understand ... thanks so very much for the clarification. With kind regards, Michel

Hello evarsanyi, So, you want the status of the program to be true only for 5 seconds? With kind regards, Michel

evarsanyi, Would you be kind enough to do me a favor: Can you please make sure the status of ISY gets updated when you physically turn on/off your SWLs? It's true that you cannot send immediate commands (they have to be around 500 m.s. apart otherwise sometimes the PLM does not hear them --> ISY does not hear them) but I believe the likelihood of being to accomplish that feat is low. So, there might be some other problems we are dealing with here namely: ISY's status is not updated when physically change the status of your switches. Also, if I am not mistaken, you are using PLM v.52 (or below) some of which had a problem with X10 sensitivity/lockup. With kind regards, Michel

evarsanyi, I am not sure why you would even add the wait in the "Then". The status of a program is independent of it performing any action. With kind regards, Michel

Hello HAS, Long time no see! I don't think this is possible with one command unless your Daughter's night light has a preset dim value of 10% in which case you could use the Preset Dim command. Otherwise, you can use Off and then repeat n number of Bright commands to get to 10% (depends on the light). With kind regards, Michel

Hi All, I didn't want to disrupt the exchange of ideas suffice it to say that I do find this topic very interesting as well. We can maintain the state of a scene internally and it has already been captured as an enhancement feature. I must add that since for ISY there's only a logical difference between a scene/device/button (they are all nodes) thus we do have the concept of implicit states. All we have to do is to make sure the implicit state is actually something useful/intuitive and not one that causes confusion. Thanks again for all your feedback and please do continue! With kind regards, Michel

Hello edfinley, You are correct and we are very very close: we had to change direction due to the very high cost of SSL certificates ($90.00 per year per unit). But, we are very close and you will be able to access your ISY from any mobile phone. With kind regards, Michel

Hello aanthony, Yes: http://forum.universal-devices.com/viewforum.php?f=20 (under help). With kind regards, Michel

Hello gwarthur, Ummm .... based on your statements, I am a little confused as to what you use ISY for? Timers/programs only? My comments below. With kind regards, Michel Yes, correct! When you linked your devices into ISY, did you "...bring Existing Links"? If so, that might explain why your KPL didn't show up in the scene. Under the scene, is the color of the SWLs RED? In all likelihood, ISY does not know about all the manual linkages and thus overwrites what was previously a working version. If you have two isolated switches, I do recommend removing them from ISY, adding them back in using the First Option (do not bring in the links), and try another scene. This will be the ultimate test as to what the problem could be.

Thom, Thank you for the update. It would be very hard to argue with your logic, but please keep in mind that 2 out of the 3 ways above have the word "predict" in them. i.e. ISY predicts what the outcome should be and thus your issue falls within them. Here's how All On/Off works from Insteon perspective: each device turns on to the on level/ramp rate for the FIRST ever entry for the controller in that devices database. So, since those devices do NOT actually turn on, this leads me to believe that one of the two following things are the cause: 1. ISY is predicting incorrectly ... but if your devices are in ANY scene, then that would be quite unlikely 2. Your devices do not have a SLAVE link for the PLM for the initial scene and/or any other scene 3. You have random communication issues between your PLM and those devices. If query works for those devices 99% of the time and/or if you can turn on/off those devices through a scene 99% of the time, then the problem has to be either 1 or 2. To isolate: 1. Do a restore device on one of your devices. If that fixes the problem, then we know that we had a missing link 2. If not, try airgap on your device I have started a root cause analysis to see if we can repeat this problem. With kind regards, Michel those devices are missing the SLAVE link for the PLM. What I suggest is: 1. Try restoring one of the devices, if it works, then we have found the problem 2. If it doesn't, take the device

Wayne, I am sorry for the delay ... I can vividly remember replying to this post but ... umm! Anyway, please find my answers below. With kind regards, Michel Due to a minor bug in 2.4 releases, we could not have modifications (such as 2.5.1) work with AutoUpdate so we had to renumber everything to 2.6. So, the release you are looking for is 2.7.

AD8BC, Thanks so very much. I shall make this topic into a sticky as I am sure most people will find useful. With kind regards, Michel

Thom, Thank you for posting your issues in our forum and I do hope they will benefit everyone. My assumptions (which may be wrong) that you have a program turning these devices on/off is based on the following: ISY updates the status of devices on the Admin Console if and only if: 1. You physically turned on/off a device, PLM sensed it --> ISY sensed it, updated the status, checked to see whether or not this is a controller for a scene, and predicted the status of all the devices in that scene 2. You turned on/off a device through ISY (either web or program), in which case, ISY waits for response back from the device and if one received, updates the status of that device ONLY. If not, you get device comm errors. 3. You turned on/off a scene (including All on/All off) through ISY (either web or program), in which case ISY waits for a confirmation from the PLM (that it has send out the command) and then predicts the status of the devices in that scene Unless there's a bug that we cannot reproduce here (but will continue trying), it seems that somehow ISY believes that the status of those devices have changed and, as I mentioned before, there are only 3 cases which this takes place. With kind regards, Michel

Mike, Thank you so very much for helping us test the unit and all the bugs you found have truly made a major difference. Furthermore, thanks so very much for composing the Quick IR tutorial: http://www.universal-devices.com/mwiki/ ... R_Tutorial . With kind regards, Michel

jgraziano, Yes, creating a scene in ISY would indeed give you the correct status. Furthermore, creating a scene in ISY is not less efficient simply because 1. The devices are linked as if you were linking them manually 2. You would know the approximate (to within +/- 5% accuracy) status of all your devices regardless of how they were turned on/off 3. You have immediate access to what controls what and what is controlled by what devices/scenes in both the Topology as well as the tree to your right With kind regards, Michel Definitely make sure you create your links on the ISY. If you link 2 devices together, but not to the PLM, they will only inform themselves of any status changes. The PLM will not know you've turned them on or off unless the devices are also linked to the PLM. Creating links within the ISY ensures that the proper links are created between both the switches AND the PLM. I've only been using scenes in the ISY for actual scenes the ISY is to control. If I want to control one lamp with one button on the CL, I've been doing it manually. In that kind of scenario, should I create a scene with one lamp and one button? Seems kind of inefficient to me, but if it does indeed give me status correctly, I guess it's worth it.

Hello jgraziano, You might want to add a delay between your X10 and INSTEON setting scenes. Now, my main question is: 1. If you turn scenes "SC-Pre Sunset Lightup" and 'SC-Master Bedroom Lamps On' from ISY, does ISY get updated with the right status? 2. If you have any controllers in these scenes, and if you physically turn on/off your controllers, does ISY get updated with the right status? With kind regards, Michel

Hi Glenn, Yes and I already replied. With kind regards, Michel