Michel Kohanim

Hello Eakin, We are going to have a fix in our next release (within the next couple of days) which should fix this problem. With kind regards, Michel

Hello Mônica, Yes, there is and here's the link: http://www.universal-devices.com/mwiki/ ... o_Your_ISY Again, our offer stands: if you are still having problems getting this to work, please contact us and we'll walk you through it. With kind regards, Michel

Hi LeeG,dnl, We are talking about InLine Relay with Sense, correct? All other ILLs are responder only. With kind regards, Michel

Yes, consider it done. With kind regards, Michel

Hello mitch236, Please check your device tree and make sure you do not have any green 0101 icons. Furthermore, would you please let me know what you mean by replacing the PLM? Did you actually follow through with File | Restore Modem ? polexian, local on level is not supported in programs because in older devices setting on level/ramp rate required an airgap. With kind regards, Michel

Hello andyf0, Is the problem the Device List (Navigation tree) or the Topology? In both cases, yes there's a perfect reason: it's a bug! With kind regards, Michel

Hello apostolakisl, Although unrelated, most time servers have limits on the interval between each request. Some are as high as 2 hours and some are as low as 10 minutes. pool.ntp.org is 10 minutes. With kind regards, Michel

Hello jkuzmick, Please do be kind enough to try manual port forwarding: http://www.universal-devices.com/mwiki/ ... o_Your_ISY With kind regards, Michel

Hi Jim, Go for the upgrade. You should be OK. With kind regards, Michel

Hi Joe, 1. If you want to start fresh, then use Tools | Erase Log 2. You can change the limit of your ISY logs, currently at 3 Mega Bytes, by a. Telnet to your ISY and login ( http://www.universal-devices.com/mwiki/ ... o_Your_ISY ) b. Type CL and change the log limit With kind regards, Michel

Hi thruster999, Thanks. We'll check into it. With kind regards, Michel

Hi Jim, Please go to https://your.isy.ip.address and see if you are prompted to accept a certificate ... please click on the certificate button on your browser to view the certificate and if it is UDI Default Certificate, then you are OK. With kind regards, Michel

Hello oberkc, You can use this calculator to get an estimate of the number of links that you should have in your PLM: http://www.universal-devices.com/tools/ ... _links.htm Unless you have small number of scenes with small number of devices per scenes, I think the count is a little low. With kind regards, Michel

Hello thurster999, Thank you. Would you be kind enough to let me know if the SWL in question has BEEP support? It seems that only SWLs with BEEP support backlight. With kind regards, Michel

Hello Monica, I do apologize for the inconvenience. If you are still having issues after following oberkc's instructions, please do call our tech support and we'll walk you through it. With kind regards, Michel

Hello oberkc, How many devices/scenes do you have? With kind regards, Michel

Hello seacordean, In the case where device did not respond, you do not get a -2 for device communications error? If you do not have a -2, how certain are you that the device was not already off. Would you please scroll up the log and find the last Status event for that switch and make sure it was not 0(off)? ISY does not retry commands that are sent through programs or web. The only commands retried are those impacting the database and configuration of devices. With kind regards, Michel

Hello orberkc, I agree with LeeG. In addition, I recommend doing a PLM Link count to make sure your PLM links are still there (Tools | Diagnostics | Show PLM Link Table). With kind regards, Michel

Hello seacordean, Please note that in the log: 1. The first entry is "what the program tried" 2. The second entry is either failure (-2) or the status change if the status ACTUALLY changed. So, if you do not see a -2, it probably means that the unit was already off I totally agree with LeeG with respect to using the Event Viewer to see what's being transpired. With kind regards, Michel

Hi ernie, Thanks so very much. That's quite odd because in addition to UPnP we also use another UDP packet to find ISY on the local network. I guess we have to do more research and figure out why we cannot find ISY. With kind regards, Michel

Hello seacordean, My pleasure. First, please look at the logs. You should see an activation/deactivation (on/off) for that device, initiated by Program, at that time. If the action was successful, the log would be followed by a Status entry for the same device. If not, on the same entry, you would see a -2 in the last column. If the action was against a scene, then it's quite possible that your devices within the scene are not responding. You might want to consider doing Scene Test on those scene within which devices are not responding. Scene Test: right mouse click on the Scene and then choose Scene Test. With kind regards, Michel

Hi ernie, Thanks so very much for the clarification. No, I do not think you should update the procedure. Personally, I think the /99i/admin.jnlp is much more useful since it's not tied to a specific IP address (Admin Console searches for ISY on the network). Is there a problem using /99i/admin.jnlp with Linux? Thanks again and with kind regards, Michel

Hello seacordean, Programs continue their normal execution regardless of error. As a matter of fact, based on input by porscheguy, we are going to make Device Error a condition which can be used in programs. With kind regards, Michel

Hello ernie, THANKS SO very much for your feedback and instructions. One question though, can't you go directly to: http://your.isy.ip.address/admin.jnlp instead of pointing to /99i/admin.jnlp and then editing the JNLP file? With kind regards, Michel

Hello all, We had to put a workaround for SyncrhoLinc since it seems that our initial understanding (documented) that extended messages (i2) would be only in response to extended messages has proven to be wrong for the second time. In SyncrhoLinc version 82, everything should work fine (except setting the options) simply because PEEK and POKE respond with PEEK response and POKE response. In version 8C, PEEK and POKE respond with extended messages that ISY DOES NOT expect. This basically throws off ISY and thus all the spurious messages. Incidentally, iMeter has the same paradigm: it responds with extended messages when given standard commands. I have notified SmartHome to make sure this is indeed what they had in mind. Rod, you do not have to worry about i1 and i2. It's just different methods of communicating with INSTEON devices. With kind regards, Michel