Jump to content

Michel Kohanim

Administrators
  • Posts

    26775
  • Joined

  • Last visited

Everything posted by Michel Kohanim

  1. Hi Ed, No! We found the source of the lockup and we are currently testing it. With kind regards, Michel
  2. Hi Rich, Please contact IES and ask for the POE version. We should have full support for them within the next month. With kind regards, Michel
  3. sloop, We have to solve the puzzle! May I humbly suggest 4 AccessPoints? You can trade your SignaLincs for AccessPoints and thus we can remove yet another variable in your environment. With kind regards, Michel
  4. Digger, Yes ... Thanks and with kind regards, Michel
  5. Digger, I cannot say it's a bug since we do not yet have the memory map to ascertain whether or not this is a bug! With kind regards, Michel Is this a bug in the Keypadlinc relay? If so I might as well return mine before I put them in.
  6. HokePerogi, I don't think IRLinc can interfere with your devices. The main question is: if you double tap on a switch does the local load turn on to 100%? With kind regards, Michel Ok Michel, I will try that when I get home today. One more thing to point out, I do have an IRLinc as well. I can see the blue led blinking when I single tap or double tap. Do you think the IRLinc could be interfering with the Togglinc double-tap?
  7. Hello dss, KPL 1.4 issue is a bug which was introduced in 2.6.3. KPL Relay is an open question to SmartLabs for which we do not yet have answer. With kind regards, Michel
  8. Hello sloop (or should I say pen poem?), You forgot to mention: Now, you have to get a plane ticket for someone from UDI to come over and fix all the problems! Are the communications problems isolated to a finite number of devices or are they random and different devices? How many SignaLincs do you have and how many AccessPoints? With kind regards, Michel
  9. Ed, Thanks so very much for the offer; I might take you up on it if we cannot find a resolution shortly. The reason that ours works better than what's out there is because the ISY in the lab has many modifications to the code. With kind regards, Michel
  10. Ed, Excellent idea. Thanks so very much for the information. I do have a huge log of your activities on our ISY and I am going through it as we speak. The problem has been now narrowed down to a limited set and hopefully we can find the solution soon. Thanks again and with kind regards, Michel
  11. Hello HokiePerogi, If you cannot even do a fast on on the load switch, then I suspect you have defective switches. You might want to try: 1. Factory reset both switches 2. Do a Restore Device on each With kind regards, Michel
  12. sloop, You do not have to redo everything. I should have mentioned that request failed is only for the failed device and thus others should be working properly. Do you know which one(s) failed? With kind regards, Michel
  13. Hi sloop, What failed exactly? With kind regards, Michel
  14. wjoel, That's entirely possible if you have other devices on your network which use port 443 and which your router has that port dedicated to them. To fix this issue, you can: 1. telnet to isy 2. change your HTTPS port to something other than 443 Your url will be of the form https://your.external.ip:your_new_port . With kind regards, Michel
  15. sloop, It's about 30 hours and where are we? With kind regards, Michel
  16. clark21236, You cannot make an InlineLinc a controller simply because it cannot control anything else except its own load. Are you trying to have an indicator for the pool pump (whether it's on or off)? If so, how are you going to turn on/off your InlineLinc in the first place? i.e. what controls your InlineLinc? With kind regards, Michel
  17. Illusion, File->Restore Devices restores the PLM links as well. And, you are correct: you do not have to redo everything that you have already done. We are simply ensuring that what you have in ISY is equal to what's out there in the devices. With kind regards, Michel
  18. Dave, You are 100% correct ... this HTML is just the beginning. We shall make it more user friendly with every new drop. Please keep the requests/suggestions coming since that's our only vehicle for implementing user requested changes. Thanks and with kind regards, Michel
  19. Sloop, You are right on. Also, have you considered getting the latest PLM (v. 2.75)? With kind regards, Michel
  20. Hi Andy, I already responded to your post in the other forum which I hope you'll find useful. If a device does not respond to a scene command - and if there are no comm problems, then in all likelihood we have one of the following two cases: 1. There is no PLM link in the device (unlikely) 2. The on level is either 0 or ramp rate is 9 minutes for that device in that scene Is it at all possible to login remotely to your ISY? This would make everything much easier. With kind regards, Michel
  21. Andy, We are dealing with two problems here: 1. Communication problems 2. Managing scenes Is it possible to login remotely to your ISY and checkout what scenes you have? If so, please send the remote access URL to support@universal-devices.com with your credentials. In most cases - and in the absence of communication errors - it is possible that either the on level is set to 0 or the ramp rate is set to 9 minutes for those devices in scenes. As far as dimming a scene, each time you dim by 3% so, in effect, you would have to repeat a dim about 30 times to get to off. This is not a good solution. As far as PLC/Timer Software vs. ISY/PLM, my only comment is: ISY reports comm errors as they happen while most of those are ignored by the Timer Essential/PLC. As far as documentation, we are working on it. Our Scenes tutorial is one of the most comprehensive documents found with regards to INSTEON scenes/groups anywhere. We are working on documentation for programs. And, finally, please do not hesitate to call us and thus make it easier to diagnose and resolve all problems that you are experiencing with ISY/scenes/programming. With kind regards, Michel
  22. sloop, As usual, quite enlightening ... Well, before you start on creating programs instead of scenes, please do the following: 1. Do a Query on the Network tree node. Write down the devices that have comm problems 2. Let's figure out why they have comm problems 3. Factory reset your PLM (if you hadn't done so before) 2. Do File->Restore Devices This makes sure that what you have in ISY is equal to whatever is already out there + we are not going to have network comm problems. After the above, PLEASE do go ahead and create your largest scene and not a program. I am very confident that creating a program instead of scene is going to make things much worse. Please trust me on this. Thanks and with kind regards, Michel
  23. Illusion, Please do the following before adding your scenes: 1. Reset your PLM (just to be in the safe side) 2. File->Restore Devices With kind regards, Michel
  24. Hi Illusion, You are 100% correct and apologies for the omission. I am going to edit the post. Thanks and with kind regards, Michel
  25. Hi sloop, I think at the end of your endeavor, most your devices will be so exhausted from so much programming that they'd have no more strength to do anything else! May I humbly suggest the following: When you get your setup full working the way you want it (it might be impossible), please do not start from scratch! Every time you have a problem, simply let us know and we'll work through it to figure out the cause and not cover up the symptoms. As far as your question: Restore Device restores all the links for that SPECIFIC device (the affected device upon which Restore is being performed). If write process fails, then the state of the device is depended upon what failed; if 3 retries fail, and if we cannot revert back, then the state of the link table is purely random. As such, it's always best if you could factory reset the device, and retry. This said, however, there are no reasons for the Restore to fail unless there are communication problems which we would have to find and fix. With kind regards, Michel
×
×
  • Create New...