Michel Kohanim

Hi jmed999, What operating system? With kind regards, Michel

Hello overkill82k5, I am so very sorry to hear about all the problems you have been having. At the moment the best recourse would be to contact our support (links below) so that we can help you more expediently. With kind regards, Michel

Hi paauto, Yes, we have had this reported on multiple occasions and it's related to PLM's signal handling. If you have any programs that check the status of "something" (especially motion sensor) and then turn on/off the backlight on a KPL, then please do make sure you put a delay (Wait) before activating each button. With kind regards, Michel

Hi Barry, I am not sure what type of information you are looking for. You do get all of those with ISY and 2441TH. With kind regards, Michel

Hi Chris, O, I am so very sorry as I didn't understand the question. Unfortunately there's nothing that would suspend communications with the PLM. If you are thinking of putting the PLM on a switch, I must advise against it since there have been many cases where the PLM just dies after reboot (I guess the same is true with generator?). Would you be kind enough define "going crazy" a little more specifically? Is it always the same devices? With kind regards, Michel

Hi Chris, If you have the ELK module, you can have an ISY program that is based on any ELK input/output. With kind regards, Michel

Hi bsobel, Thanks so very much for the feedback. Steve contact our support and we figured out the issue: most of Steve's devices were added with brute force method and thus had 00 for firmware version and thus all the issues. With kind regards, Michel

Hello Smile4yourself, We have already gone through the Access Logs and this issue is not at all related to a remote hacker. This is very much related to ISNTEON signals being "misinterpreted" as all on/all off in very special cases that include KPLs and Motion Sensors in the mix. With kind regards, Michel

Hi Joe, No plans whatsoever! I had not even heard of them till the advertisement today. And, looking at their solution, I think they are very much ingrained into their portal/service charge and would not let us to circumvent it. With kind regards, Michel

Hi jmed999, Thanks so very much for the update. This is rather strange and thus let's give it a week before declaring victory! With kind regards, Michel

Hello shifmeister, Welcome to the forum and apologies for tardy reply. There are two questions here: 1. Can ISY communicate with BGE, well, I do not think so if they do NOT have a process to pair the meter to another device (basically the meter needs to know the EUID and Install Code for ISY). So, unless you can figure out a process by which they linked the thermostats to the meter, I pretty much doubt you can do anything 2. Can ISY communicate with the provided meter? Unfortunately not since, SEP 1.1, does not allow an end node to control another end node. Only the coordinator/ESI (in this case the meter) has that authority So, if you wish, you can find their technical contact on the HAN side and we would be delighted to talk to them. We did the same with Oncor and they have been more than helpful. With kind regards, Michel

Hi mountainman3520, In the instructions there's a link to the dashboard (http://isy.universal-devices.com/99i/dashboard.jnlp) . That's what you should use to install certificates. With kind regards, Michel

Hi Hydrographer1, Are you certain you are on the right forum? With kind regards, Michel

Hi Steve, Do you have the same problem locally? If your programs do not work, then the problem is NOT network related. Have you looked at your error log? In short, what you are experiencing is NOT normal. With kind regards, Michel

Hi CaptFisk, That's 100% normal because you are using a self-signed certificate. Please do make sure that the certificate is indeed for ISY. Even this is more secure than accessing ISY on port 80. With kind regards, Michel

Hi rohan208, Did you try again and did it work? With kind regards, Michel

Hi rohan208, This basically means that your computer cannot access http://www.universal-devices.com ... this is where the Admin Console checks to see whether or not there are any firmware updates available for your ISY. What's your UI version (Help | About)? With kind regards, Michel

Hi captfisk, This is related to the firewall software on your computer. What you need to do is to make sure both of your ISY's are included in the trusted zone or exclusion list in your firewall software. If you are using HTTP to access ISY, I strongly recommend changing it to HTTPS: it's more secure and most firewall software are more lenient with https traffic. With kind regards, Michel

Hi oronomus, What you outlined is the correct procedure. To power cycle ISY, unplug the power cord from it and then plug it back in. With kind regards, Michel

Hello mountainman3520, First of all - and as you suggested - please do NOT forward to port 80. This will expose ISY's traffic to hackers. For https, please do make sure you have the latest Java (that supports TLS) and then: 1. Clear your Java cache 2. Go to http://isy.universal-devices.com/admin.jnlp ... this will install the Admin Console icon on your desktop 3. Once you get the ISY Finder dialog, then click on the Add button and then enter the remote URL (https) for your ISY With kind regards, Michel

Hi Steve, Questions: 1. Are you accessing ISY using HTTPS? 2. If so, what's your Key Strength? With kind regards, Michel

Hi johnnyt, Not even SDIO is going to help since the problem is NOT bandwidth as each file is less than 1K. With kind regards, Michel

Hi hbsh01, File | Enable Internet Access does not have any bearings on this issue UNLESS you have recently changed your router. You can certainly use 99 in the office since most of these issues are related to UPnP media server/streaming. With kind regards, Michel

Hi gregmac, There are many variables at play here: 1. Making sure IRLinc TX is indeed capable of storing and repeating the IR commands necessary for your LED strips 2. You have the latest shipping versions of IRLinc TX 3. The distance/noise considerations between IRLinc TX and the LED I would start with #1 and then go from there. With kind regards, Michel

Hi johnnyt, Throwing more CPUs will not at all help with INSTEON communications which MUST be serialized and tracked. To make matters more interesting, INSTEON does not have a transaction ID so, for every request, we literally have to jump through hoops to make sure the response is actually the response to the command sent. GUI load/etc., unless you are using HTTPS, I think additional CPU resources is not going to help at all since the bottleneck is the file system read operations (one file at a time). With kind regards, Michel