Michel Kohanim

Just Another Joe, Ok, yes. It must have been. Would you be kind enough to notify us in case you find any problems with 1.6.03? Thanks in advance, With kind regards, Michel Hi Michel. I had JRE 1.6.0_02 until about a week ago, when it notified me of an available update, and I updated to JRE 1.6.0_03-b05. So, I guess the problem must have been a. cached version of applet. Though recycling the ISY didn't help, the problem disappeared after turning the computer off for the night, then back on today. So far, it appears to be working correctly.

mdcastle, I apologize for the troubles you've been experiencing. If you get a lot of "Request Failed" messages, then it could be one of the following three things: 1. Signal issue; Please do be kind enough to plug an AccessPoint or a SignaLinc right on top of your PLM 2. You linked devices and "brought existing links" ... if your existing links have a conflict with what you are trying to do with ISY, then the device simply rejects the request. This happens very often with devices that have been linked using HouseLinc (half links/orphaned links) 3. As sloop suggested, your PLM is "tired" ... believe it or not, that's precisely what happens when the PLM is confronted with a lot of operations We can certainly walk you through all the issues and setup problems regardless of the cause. If you need further assistance, please do not hesitate to contact us directly by phone or email. With kind regards, Michel

sfhutchi, Mike B, Rand, and Mark: Thank you so very much for the feedback and the brainstorming. I must admit that on this point I am more in tune with Rand. This said, however, I do understand that switches/lights would never stay at their preset levels especially if you have kids. The technical difficulty is not about coding; it's about managing the resources while being the least obtrusive. Let me elucidate: Let's assume you have 40 devices and a trigger that turns on a scene with 20 of your devices. Let's assume that these devices each were at different levels prior to the trigger. Now, let's say you want to store the state of each and every device. This means that ISY has to send 20 commands to 20 devices which should take approximately 15 to 20 seconds if you have a flawless INSTEON network. If you don't, then add 4 seconds for each "misbehaving device". Now, during these 20-25 seconds: a. All the schedules are delayed 20-25 seconds (have to wait for the queue to finish) b. Any communications from Admin Console to INSTEON will be queued and thus delayed 20-25 seconds (you won't even be able to do it since the System will be busy!) So, the more devices you have, the more the delay, the more the likelihood of communications errors, etc. If you add more of these triggers, then there's nothing to prevent this scenario to completely hog the network/ISY resources and stop all other activities. And, this is precisely why group commands/scenes are so wonderful: they only take one operation. Similar ideas which are less obtrusive could be: 1. Capture and apply the current state of the devices within scenes. So, for instance, your kids adjust the levels for your dining room scene to a level that makes the most sense. You simply go to the controller for that scene and apply the current state of each device to that controller 2. Some type of pattern recognition based on ISY's log entries With kind regards, Michel

Just Another Joe, Yes, absolutely acceptable. The only problem arises if a) you are using DHCP and your ISY's DHCP lease expires in which case, your link will no longer work. To alleviate this, you can make ISY use a static IP address. Please consult Advanced Configuration Guide (http://www.universal-devices.com/resources.htm) to configure ISY with static IP. With kind regards, Michel

Mark, Thanks so very much for your help. Just Another Joe, In all likelihood, the problems are/were: a. Cached version of the applet (Control Panel->Java->Settings->Delete Files) b. You must have an older JRE. Please try JRE 1.6.02 ... you can download it directly from our website @ http://www.universal-devices.com/resources.htm Please let us know how it goes. Thanks and with kind regards Michel

siegeld, What type of conditions? Are these conditions the same as those used by our programs or others? Right now, if you implement onTriggerStatus, and if in the shell you turn on DBG 1, you will be notified of all button presses and state changes. Are you interested in any other specific events? With kind regards, Michel

MikeB, Aha! That makes sense but a little difficult to implement mostly due to limited resources on the box. We shall investigate since I think this would be a great feature. Thanks and with kind regards, Michel

Hi sfhutchi, Interesting but why would you want to change the settings? If you do an All On (My Lighting->On), then all devices will turn on, ISY is updated with their status, and when you turn them off, ISY is updated yet again with the correct status. Would you be kind enough to elaborate a bit? With kind regards, Michel

black_fx_35, My pleasure! The IR version should suppor any remote with signals at 36-7KHz (most universal remotes) and should be seamless. We have not tested with Logitech yet but it's a universal remote running within those frequencies. With kind regards, Michel

black_fx_35, We do have an IR enabled version planned for later this year. The price is going to be a little higher. Or, if you don't want to wait, you can always use an IR/X10 bridge and use the X10 to trigger INSTEON actions. With kind regards, Michel

sfhutchi, Yes, you are right! With kind regards, Michel

Hi Mark, No. Not fixed yet ... it's pretty hard to reproduce. With kind regards, Michel

siegeld, Excellent. We shall have it out to you by the end of the week. Thanks so very much, With kind regards, Michel

sfhutchi, Eventually, YES but not yet in this drop. With kind regards, Michel

siegeld, We are testing it as we speak. Do you currently create/manage schedules/triggers from within the JSDK library? If not, then we can possibly have something available with in a couple of days. With kind regards, Michel

jlevans, Apologies for the inconvenience. Please send an email to tech@universal-devices.com and we shall send you the latest update which fixes this "bug". With kind regards, Michel

Mark, Thanks so very much. The colors are pretty much consistent. I am still a little baffled by: ISY Local/Scene ISY Local What do they mean? With kind regards, Michel

Rand, Excellent suggestion ... I've put it on our list to review. With kind regards, MikeB, Part of the problem with Dim/Brighten a scene is that all devices step to the next of 32 levels. Some devices may change as much as 3% and others only 0.39% So, Yes, you are most likely to be happier with a new scene. Along with Set All Devices I would like to see a slider to modify the levels of all the devices in a scene using a percentage. Perhaps 0-100% slider with a toggle next to it to select Dim or Brighten. Dim would start at 100% and brighten would initially be 0%. Using Dim for example: Set the slider to 50% and devices that were 79% become 39.5%, 64% becomes 32%, etc. Dim and Brighten All Devices In A Scene was next on my list for Group Commander. I think after you get the ratios correct among the devices in a scene it could come close to being a mirrored dimmer or brighter scene. Something logarithmically related to light output versus power level would be more accurate. That could keep the ISY team busy for a while I'm not sure if anyone would have a use for the same function with ramp rates, that is already proportional to the level. Thank you, Rand

Mark, Thank you. It shall be analyzed and resolved. With kind regards, Michel

C Martin, Thank you for the suggestion: we have now made it bold (in the next drop). With kind regards, Michel

sloop, I am so very glad you are up and running again. From the little I gather from your post, I can immediately guess that you are running out links in your PLM (currently, 417 maximum). SmartHome is testing a new PLM which has support for 1024 links. I shall send you instruction on how to get one. As far as the order in which you put the devices in scenes, YOU'VE GOT IT ... with that order, you have overcome the KPL limitation (load/sub button) while keeping the total time to program devices to the minimum. Thanks so very much for the "retry", With kind regards, Michel

Mark, Cool. It's settled then. We'll try to come up with some type of dialog/text to describe different scenarios. With kind regards, Michel

Rand, And, as usual, you come to the rescue! You are right right on about the pop-up asking the users to air-gap their non-KPL devices when the local settings have changed. As far as the labels, anything that would make it easier for the users to understand the relationship between ISY/devices/scenes is surely a step in the right direction. I think the main issue is that have not been able to efficiently explain this relationship nor has it been captured on ISY in such a way that makes sense. Thanks so very much, With kind regards, Michel

Jon, Just to make sure we are in synch: Movie Scene KPL A -- Controller .... make sure the sub-button is added before the load KPL Load -- Controller SWL -- Controller In the above scene EVERYTHING works except for having KPL A apply a different on level/ramp rate for KPL Load. Other than that, everything else should work. i.e. if you click on KPL A, then KPL Load will turn on/off. Yes, triggers will work but I think they would be an overkill for what you're trying to accomplish. With kind regards, Michel

Mark, Thank you! Anything you do with ISY, and if it has any impact to any device, it's stored. I am afraid that the concept of "Stored" may have some other connotations that would require more explanation rather than acting as clarification. You already have the answer to your last question. The scene itself will ALWAYS run from ISY. There's no other way. The controllers within a scene, will ONLY run if someone actually/physically alters their state. You cannot run controller scenes from ISY. You simply can't because INSTEON does not let you act on the behalf of another device. Now, the last item is the on level/ramp rate for the controller itself when it's controlling the scene. Obviously, since you are physically changing that controller, THEREFORE the on level and ramp rates are the local ones. So, what am I missing? With kind regards, Michel Stored means where the link/level/rate data is stored. You always have a copy of the data in the ISY. You don't always have a copy of the data in the device. As in the case when the keypadlinc load with non-load you don't store the data in the keypadlinc only in the ISY. So your saying these would be the four naming options that would end up over the slider names like I demoed above? Scene == Stored ISY & Device Scene Local == Stored Device Only Controller == Stored ISY & Device Controller Local == Stored ISY Only I can hang with the Scene, Controller, Local idea if that is what you go with. The end result I am trying to reach is a way to see if the scene is going to need me to run it from the ISY directly, because it is not going to run with a complete result from the device.