Michel Kohanim

Hello Alex, Thanks so very much. I will add this as a bug. I will check to set whether or not there's and easy fix and/or workaround and let you know. With kind regards, Michel

Hello blueman2, Please review my other post with steps to drastically reduce the probability and possibly completely eliminate these events. As far as disclaimer, all ISYs come with a disclaimer the copy of which is also here: http://www.universal-devices.com/prod-disclaimer.pdf The same disclaimer is presented the first time you access ISY and you must have agreed to it otherwise you would get prompted every time you access the Admin Console. The disclaimer explicitly discusses use cases related to security and health. Do I think the disclaimer is sufficient? Absolutely not. Folks get ISY to automate and garage doors are natural for automation. In an ideal world we would have found a fix alas it is out of our hands. This said - and again - extensive testing has been done and we do know when this happens and thus the recommendation. With kind regards, Michel

Hi alx9r, Thanks so very much for the details. We'll take a look immediately. This said, every time ISY's time is changed, all programs are reevaluated and since this program has no condition, it will stop unless the other program that activates this program restarts it. What you might want to do is add a comdition that is always true. For instance, a state variabe that is not ever changed. With kind regards, Michel

Hello bfish, Teken might be correct. This said would you be kind enough to right mouse click / Z-Wave/Node Info and then send the contents of event viewer to support@universal-devices.com? Please put a link to this post in your subject. With kind regards, Michel

Hi mgithens, Thanks so very much for the details. Appreciate it very much! With kind regards, Michel

Hello theedudenator, Unfortunately not. If you consistently get this error then please contact our support (links below). With kind regards, Michel

Hi Randy, Thanks so very much. Please do keep us posted with what you find out and we'll definitely consider adding support. With kind regards, Michel

Hi ta2four, Unfortunately not possible. With kind regards, Michel

Hi 3gdigital, Thanks so very much. With kind regards, Michel

Hi Joe, Verify means that: 1. Server - when a client (such as your app) connects to ISY, then ISY will ask for a certificate from it and the certificate must be signed by a CA that is stored in ISY (under CA) 2. Client - when ISY connects to a server (such as gmail), then ISY will ask the server for a certificate and the certificate must be signed by a CA that is stored in ISY (under CA) In most cases, Verify should not be checked unless all CAs are stored in ISY. With kind regards, Michel

Hi JSchumann, Only with the ELK module: http://wiki.universal-devices.com/index.php?title=ISY-99i_Series_INSTEON:ELK_Security_Module With kind regards, Michel

Thanks Jimbo! #170 - Low priority. With kind regards, Michel

Hi Blackbird, You are always welcome to contact our tech support team (links below). With kind regards, Michel

Hi Blackbird, Unfortunately not natively. If it does support X10, then you can probably use programs' Send/Received X10 options. This said, I do not recommend it since X10 is not secure. With kind regards, Michel

Hi GaryK4, Unfortunately not. Sorry. With kind regards, Michel

Hi Blackbird, #169 - low priority. V5 soon but no ETA. With kind regards, Michel

Hello pmhgeneral, May I humbly request submitting a ticket if your ISY's time still drifts. Again, this is NOT normal and if hardware related, we'd definitely replace the unit for you. With kind regards, Michel

Hi Blackbird, Hopefully by the end of this coming week. With kind regards, Michel

No, the reply was for "any" ISY. With kind regards, Michel

Teken, We do take security very seriously. As a matter of fact, in our next release the default level will be TLS1.1. With kind regards, Michel

Hi Blackbird, Unfortunately not. I am sorry. With kind regards, Michel

Hello Xathros, thanks so very much. Indeed a typo. Hello fahrvergnuugen, Going back to relays within scenes: as you already know, those relays can their own on/off levels within scenes. So, you can send an On to the Scene and one relay may turn off. Anyway, and since - and with your impressive experience - I am sure you already know the risks of changing a stable, well tested, and understood function and all the regression and bugs that might be introduced. Unfortunately we cannot implement this for scenes. I have however created a product request (#168) to analyze what else we can do with minimal impact to existing operations. With kind regards, Michel

Hi smokegrub, I am not sure I understand what http/https port settings have to do with not using NTP server (which uses UDP). Can you elaborate please? With kind regards, Michel

Hi dbwarner5, Sounds good. Please note that 5.0 will have System Variables (such as Time, Day, Year, etc.) that you can use in your programs. So, you can set a variable to time of day and then change the variable based on other conditions. With kind regards, Michel

Hi fahrvergnuugen, As others have suggested, scenes have native meaning to both Z-Wave, INSTEON, Zigbee, and UPB. Z-Wave/Zigbee are more attuned to what you want done since scene commands (depending on the number of devices in the scene) might be a series of direct commands to each device. Furthermore, there's a little problem with sending 56% to a scene: 1. Do devices that are less than 56% (including off) brighten and devices that are more than 56% (including on) dim? Or is it relative to their current state? I think you are suggesting the former 2. What should happen to devices that do not support dimming such as relays? Do they turn off below 50 and turn on above 50? 3. Based on #2 alone, anything we do with our existing scenes will break what everyone else is using including elaborate scenes with buttons, relays, contact closures, etc. So, if indeed this is something we should consider, then scene (with its current semantics) is not the correct aggregation for it. We have to come up with something else in order not to break existing configurations. With kind regards, Michel