Michel Kohanim

Hi Illusion, Thanks so very much for the feedback. This is probably another case of firmware idiosyncrasies between devices. Hi Troy, There was indeed a problem with releases starting at 2.7.8 where LED brightness would not work on certain KPLs. This has been fixed in 2.7.15 (which should be our official release). In short, this is how it works: 1. You have Off Level ... i.e the brightness level for when the button is in the Off mode 2. You have On Level ... i.e the brightness level for when the button is in the On mode 3. And, the most important thing to note is that the On Level is a function of the Off Level. So, the lower the Off Level, then the lower the On Level With kind regards, Michel

Hi Nick, Please note that even if a device reports i2 it does NOT mean that the device supports i2 programming for link database. This is why we had to introduce automatic mode since except for motion sensor, triggerlinc, and some function of thermostat, i2 commands were NOT reliable and caused more harm than good. If you can add motion sensors/triggerlincs, and thermostats then I would strongly advise against using the device reported mode since it's basically quite unpredictable. With kind regards, Michel

Hi Dan, There are certain cases that query will help: 1. If you use a lot of dim/brighten locally on your switches, the status might be up to 5% off. This may cause your programs that use specific values (instead of a range) not to work properly 2. If you adjust the on level/ramp rate of a device locally (not through ISY), ISY will not know about it. Query helps rectify this issue With kind regards, Michel

Clarence, Yes, yes, and NO. In short, please do not waste your time trying to figure out why V35s are not behaving reliably. Just have them replaced and you'll have saved 10s of hours of debugging. With kind regards, Michel

Hi Brian, Thanks for the update and I must say that I feel a lot better (even though things do not work anymore) mostly because I cannot stand unpredictable behavior. Consistency is quite important in code development. What you are describing is precisely how all KPLs have worked since they introduced the load control by sub-button in 2A+ firmware. When we read the memory locations for those that were setup manually, we noticed that the on level used was NOT 0 but a very low on level. That's why we put that dialog box in there. In short, there's only two memory locations that decide what the load should do and they are set properly by ISY. You had this setup using non-toggle buttons. Did you change the non-toggle state? With kind regards, Michel

Hi Mark, Looks good. Thanks so very much! With kind regards, Michel

Hi mitch236, Since you are sending one command at a time to your thermostat, and since thermostat modules are a little slower than other modules, what I recommend are: 1. Adding a delay of 3 to 5 seconds between each call OR 2. Make a scene with those settings and activate that scene instead With kind regards, Michel

Hi, Good question as we still haven't found the algorithm which converts one to the other! With kind regards, Michel

Hi Simon, Thanks so very much for the update. Perhaps we should do a constraint check in the code as a workaround. I hate this solution because it does not address the main issue of the thermostat sending the wrong data but it seems that we do not have a choice. With kind regards, Michel

Hi Brian, The main issue is this: You cannot send an On command to a scene and have a KPL sub button turn off (as well as the reverse). This problem is not limited to ISY scenes. Consider adding another KPL button from another KPL as a controller. Now, although you can control all the responders within the scene properly but the status of "other" KPL sub buttons is EQUAL to the command sent. That's the crux of the problem and has been an outstanding issue for over 2.5 years. With kind regards, Michel

Hi Gary, There's another explanation: you had pending device writes and ISY was writing to devices. Did you have any green 0101 icons at any moment in time? With kind regards, Michel

Hi Terry, Thanks so very much for the update and I am so very glad to hear of your progress. The next issue might be related to a firewall software if you have any. If you do, it would be best to put your ISY in the white/trusted list/zone. For a list of firewall issues/resolutions, please checkout this forum: http://forum.universal-devices.com/viewforum.php?f=3 With kind regards, Michel

Hi Brian, Unfortunately I cannot give you any expert advice on the setup. I can only answer your last question: That's precisely what ISY is doing: that's why the KPL has to be in a scene since all those interactions are accomplished via group commands. With kind regards, Michel

Hi, Do you have access to your router? The best thing to do is to see if you see ISY26-HOME-AUTO as one of the clients in the DHCP client table. If not, then in all likelihood your 26 is set with a static IP address which is not in the same subnet as your network. The only way you can reset that is through the shell (hyperterminal): http://www.universal-devices.com/mwiki/ ... _ISY_Shell With kind regards, Michel

Thank you. So, basically, you cannot login since you are not being prompted to enter your userid/password. Do you see My Lighting in the Network? Also, if you have access to your router, you may want to check the DHCP client table to see if there's a listing for ISY26-HOME-AUTO. I am thinking that either your computer is not on the same network as ISY OR maybe ISY has a static IP address (from the previous owner) that is not in the same subnet as yours. The last thing I would like to know is the sequence of lights on top of the unit when powered up. With kind regards, Michel

Hi ryarber, We do NOT!!! I think it's an excellent idea and we'll work on it but, before that, we have to learn how to use it! With kind regards, Michel

Hi kingwr, You can do that via programs ... the only issue is that the analog input can only be read using i2 and we have yet been able to extract that information! With kind regards, Michel

Hi hemants, That's odd ... please make sure you forward port 443 and not 80. With kind regards, Michel

Hi cslee, right now there is not a way to use error conditions in programs but it's surely in our requirements list. With kind regards, Michel

Hello terrygb2000, Welcome to the forum .... Would you be kind enough to let me know what you mean by "nothing"? Can you access the Admin Console? Can you login? And, if so, what's your ISYs firmware version? With kind regards, Michel

Hi Tim, This might indicate SD Card issues but I really doubt it. Please try httpS next time and let me know the outcome. With kind regards, Michel

Hello hemants, Welcome to our forum. 1. If File | Enable Internet Access fails it means that a) your router does not support UPnP and your ISY is not accessible via the Internet 2. You will have to setup manual port forwarding the instructions for which you will find here: http://www.universal-devices.com/mwiki/ ... PnP_Router Once you have that setup, then the IP address will be your Roger's IP address for your home. You can usually find this IP address by either going to the Status page on your router OR you can go to http://whatismyip.com. Once you have port forwarding working, then you can access your ISY using: https://your.external.ip.address With kind regards, Michel

Hi kingwr, Thanks so very much for the feedback ... the main issue is that we cannot guarantee smooth interoperability with SHN devices. I was told that they were going to fix it but have not heard back since. With kind regards, Michel

Hi Gary, Yes, that would be a solution but not ideal since you cannot actually use the analog values coming off the sensor as such you are bound by On/Off based on set temperatures. There has to be analog INSTEON sensors ... I believe this is one thing that is missing from the product line. With kind regards, Michel

I totally agree ... to more generic, there should be INSTEON analog sensors which can be used for all purposes. With kind regards, Michel