Michel Kohanim

Hi jwagner010, Yes, the files are restored. All you need is to ask to have your modules transferred: http://wiki.universal-devices.com/index ... r_ISY-994i With kind regards, Michel

Hi Tim, Please telnet to ISY, login, and then type: RF /CONF/29.PRP With kind regards, Michel

Hi Michael, I do not dispute that we need to be more clear with https/networking. If you pour through the forum, there has been only 3 instances of HTTPS issues reported with Networking Module. And, we have NO issues reported to us directly that has not been reported on the forum. Based on the number of modules we sell, 3 is not even 0.01%. Even 100 is an extremely low rate. So, I hope that you can eventually wrap your head around the fact that 99% of Network Module users only do things on the LAN. Apart from updating our documentation and advertisement, the licensing shall remain as is because, otherwise, we will be penalizing those who do not need to pay for additional security. As always, thanks so very much for your feedback. With kind regards, Michel

Hi Xathros, Thank you. No, this is not the intended behavior. BugID #56. With kind regards, Michel

Hello oberkc, There are a lot of misconceptions about Z-Wave compatibility. For certain, each manufacturer can have additional/extended functionality for which we have to write code. For instance, association (i.e. linking devices to one another) is not mandatory. This said, all device command classes have base functionality that should be the same across manufacturers. As such, the base functionality for all dimmers, relay, thermostats will be functional in ISY. We have actually tested with 4 different thermostats and they all worked fine. All Schlages should work fine. Yale should be supported in the next firmware release and QuickSet to follow. With kind regards, Michel

Hi Scott MS, You should be able to. BugID #55. With kind regards, Michel

Hello oceanman93, Is it possible to capture traffic to your iMac? I really think your iMac is actually sending 300/301. With kind regards, Michel

This is me - and the answer is 'Because I need to be able to connect TO the most possible remote HTTPS services to actually USE the networking module. I, as ythe customer, don't have control over the cipher suites those servers need. To restrict the cipher suites the HTTPS client can connect to simply means it cannot connect to most HTTPS destinations. That the situation people are finding themselves in with Pushover. I do not think you read #3 thoroughly as it does not characterize you. i.e. LAN only. Agreed. We shall make it more clear. Not at all. See #3 above: those who use it to communicate to LAN devices internally Same as above. Penalizing those who do not need high security because all they do is communications with their gadgets on the LAN Yes, good idea. With kind regards, Michel

Hello oceanman93, Your resource is returning 300 or 301 as status. What is this device? Is it on your network? With kind regards, Michel

Hi all, we'll try to have another release as soon as possible. Xathros, can you check the Program Summary tab and see the last runtime/finish time for this program? With kind regards, Michel

bsobel, thank you. You are 100% correct. MWaverman, I am not sure what you are suggesting: that all Cipher suites should be included in Network Module? Please note: 1. There are customers who want neither so why should they pay for either/all? 2. There are customers who never use Networking module but need the strong cipher suites (Commercial OpenADR) so why should they pay for Networking module? 3. There are customers (actually the majority) who use Networking module solely for communications with LAN devices and do not even know what high security means. So, why should they pay for strong security features? 4. And there are customers (like you) who need both The bottom line is that we are trying to lower the burden on those who do not need ALL the features ALL the time. With kind regards, Michel

Hi Rick, Nothing should happen in either case. What you need to happen to test is actual smoke/C02 ... With kind regards, Michel

Hello Envirogreen, Unfortunately apart from getting your own weather station, there's not much you can do. Please do note that we have satisfaction guarantee policy and thus if the module does not meet your requirements, simply ask for a refund from our sales (sales@universal-devices.com) dept. With kind regards, Michel

Hi Nick, BugID# 51. The thermostat issue is already fixed in 4.0.2. The only issue is that we don't want to have beta releases every week without substantial improvements. We'll see how many bugs we can fix by Friday and then decide whether or not to release 4.0.2 by then. With kind regards, Michel

Thank you. This is indeed a bug and has already been fixed in 4.0.2. With kind regards, Michel

Hi Xathros, You should not be worried because they seem to be related to Z-Wave and not INSTEON. In any case, BugID#50. Thanks so very much and with kind regards, Michel

Hello philgood, If you are going to splurge may I humbly recommend upgrading to 994 instead? viewtopic.php?f=44&t=10771 With kind regards, Michel

arw01, It's a good dream and one which I personally share with you. This said - and given our resources - I really do not think that we would be focusing too much on the UI. On the other hand, we do spend (to the point of obsession) a lot of time getting the whole system perfected, reliable, and with well defined APIs so that other more artistic souls can come up with a perfect UI. With kind regards, Michel

Hi Rich, You have to remove and add it back. With kind regards, Michel

Hi Xathros, thank you. NTP would not be an issue. Checking for updates is done from the Admin Console and not ISY so that should not be a problem either. With kind regards, Michel

Hi RichTJ99, Yes, but you will have to remove your Leak Sensor and then add it back in so that you get a heartbeat node. With kind regards, Michel

Hi matapan, Do you mean you want to remotely communicate with your ISY? If so: http://wiki.universal-devices.com/index ... PnP_Router With kind regards, Michel

Hello matapan, As far as I know, it used to work but I am no longer certain with all the changes to PLM and i2cs messages. With kind regards, Michel

Hi Guys, Thank you. Bug ID #44. With kind regards, Michel

Hi bsobel, Xathros is correct: the state remains as is but two things will happen: 1. The node is flagged as being in communication error (the flag in ) 2. The control/action event ERR/1 is sent (and captured) so that you can use Is Responding/Is not Responding in your programs With kind regards, Michel