matapan

I tried using scenes for button grouping today. The intent was to set up a group where only one button in the group could be on at a time. The scene I created works, except for the fact that the button that is ON can be toggled off, creating the state where all of the buttons in the scene are off. What can I do to ensure one button in the group is always on?

I have a simple program which sends a X10 command when a Keypadlinc button is turned ON: If Status 'KPL A' is On Then Send X10 'A1/On (3)' Else - No Actions - When executed and the Keypadlinc button is turned on, the X10 device that is supposed to respond to the program does not respond. I tried running the Then path of the program manually. This worked just fine. Next, I tried adding delays in the program: If Status 'KPL A' is On Then Wait 2 seconds Send X10 'A1/On (3)' Else - No Actions - This worked, but the delay makes the program unusable in its context. Sending multiple commands seemed to be the only workaround so far: If Status 'KPL A' is On Then Send X10 'A1/On (3)' Send X10 'A1/On (3)' Else - No Actions - Question: Is there a better way to implement this and eliminate the delay or duplicate command? Presumably, this is an artifact of some power line signal collision that is occurring. The event log trace shows the X10 command clearly being transmitted.

Would it be helpful to adjust the timeout period for different periods of the day as a means to account for the amount of activity that may occcur in the home when someone is present? The best example of this is late night, when everyone is sleeping, vs. early morning or early evening, when there might be more activity, where a shorter timeout might be in order.

I second LeeG's suggestion for a programmatic check. If ISY will evolve into a more mainstream consumer oriented device, such checks are particularly useful in reducing the number of calls or posts generated.

I'm using the latest version of the motion sensor now. Three of them. Has anyone experienced any erratic behavior of the motion sensor under very low voltage, real world conditions, or does the unit simply stop working when the battery goes flat? I would prefer having the sensor not send any ON/OFF commands randomly when the battery goes low, instead simply stop sending ON/OFF commands altogether when the device cannot run correctly with the voltage available.

Would it be useful to put a validation check at startup of the Admin Console so the correct version of the AC is run with the correct firmware version? If the AC and ISY firmware versions don't match, return an error showing the firmware version on the ISY and the AC version being run. A reminder to clear your Java cache if you are have loaded an AC version that doesn't match the ISY firmware version might also be useful, if clearing the cache under the circumstances is important.

I recently started to think about the states in which the Admin Console loses its subscription to the ISY device and stops presenting device and program state information. In version 3.1.16, I've distilled down several scenarios and their actual outcomes below: Sleep Level Low - user walks away from computer and screen power save is initiated while Admin Console is session is open. Actual Outcome Upon return, user is prompted to log in to Admin Console (expected result) Moderate/High - laptop clamshell is closed, putting machine in moderate powersave state, or machine is explicitly placed in hibernation while Admin Console is running. Actual Outcome Upon return, user is not prompted to login to Admin Console. State information presented is no longer valid, or is missing. Resolution: Closing the browser completely, and restarting the Admin Console resolves the issue. Is there a way to handle the moderate/high use case described above in a similar manner that the low sleep state use case is handled now? This would be ideal - I'd prefer not to restart the browser if at all possible. I was wondering if this behavior with how the subscription is handled might have some relevance to some of the sync issues I'm experiencing with Mobilinc Pro currently.

LeeG: The Start Linking command was used, to confirm. My understanding is that if the Keypad load button is pressed for 10 seconds, it's supposed to go into linking mode, at which point, the KPD identifies itself to ISY. Isn't that the way it works? I know it does for my other devices, like Switchlincs. I'll try manually adding the device using the auto discover device type setting the next time I'm around the device. Thanks!

LeeG, Regarding Q2: this is the auto discover scenario. 1. Set up ISY to initiate linking via auto discover mode. 2. Set KPD in linking mode. Expect: KPD to be discovered and show up in Admin Console. Actual: No device shows up in the Admin Console. With other devices, the expected result usually occurs.

I am starting to write a lot of programs, organizing them in folders. The programs appear in a reasonable order in the Program Details tab, with related programs in a folder organized under the folder hierarchy. In the Program Summary tab, the individual programs appear in alphabetical order in a flat organization. The hierarchy is displayed in a column which shows the path. This is hard to read and use. Is there any way to display programs in hierarchical order?

I have some old v1.3 Keypadlincs that could not be auto-discovered by ISY when the Keypadlinc was added to the network. I was able to add them manually to the network by providing the address of the device and specifying the device type. ISY99 is aware of these devices and can talk to them. The firmware version shows up as "v00" if one adds devices manually. I've discovered that this is normal from reading the postings here. Questions: 1. Is it possible for ISY to retrieve the device firmware version and update the Admin Console and its own database via an explicit command? 2. Why are some devices not auto discoverable? Is this an artifact of attempting to discover an older device?

Would the last execution time of a selected set of programs provide some indication of activity, particularly if the programs themselves relied on control changes?

I happened to be setting up Notifications on an ISY-26 with firmware version 2.7.15 when I noticed there was no Customizations tab for entering the text to be sent. Was this feature available in firmware version 2.7.15 for ISY-26?

Doesn't the ISY sync its time to a NTP server? I think my Mac and most Windows machines now have the same capability. So, theoretically, the time wouldn't be that far off, would it?

That's also what I've done as well, using checks for Control rather than status. Going further, I check both cases: If Device is Switched on and The devIce is not switched off The resulting program stays using such a check seems to yield results more in line with one's expectations as well.

Would a Dual-Band PLM and an Access Point near the breaker box provide a possible solution in the scenario described?

Thank you for the reply, LeeG. What is the relationship between the columns and the tree below in the same dialog?

I'm still on 3.1.14 and also experienced problems with incorrect Keypadlinc secondary button status. I'll be upgrading to 3.1.15 tonight to see if the upgrade also clears up the problem for me.

I think I understand the differences between creating a scene to handle mutually exclusive buttons and defining them using the feature in the Admin Console. What I want to understand is how to use the Admin Console's button grouping feature. The Wiki page describing the feature does not match the current UI (3.1.15). What are the checkboxes above the tree list for? Also, the UI warns you can corrupt scenes if you're not careful about how you go about performing this operation. Two questions: What are the manifestations of a corrupt scene - how do you recognize a scene has been corrupted? Second: How does one rectify the corruption once it happens? If I understood the consequences better and how to take care of it, I would probably have played around with the UI to figure it out.

Is there a good explanation available on how to set up Keypadlinc button grouping? I looked at the Wiki page on button grouping. It appears to be outdated, as the screenshots used don't match the actual button grouping dialog. The new dialog (I have firmware version 3.1.14) has a number of sections on the top of the screen with checkboxes. The wiki page doesn't show this. According to the wiki description, one simply drags the buttons one wants to group into one of the available scenes. Is this the way it works in the latest firmware release? I am at a loss as to how one sets up mutually exclusive button groups. I want to set up a group of three buttons where only one of the three buttons can be pressed.

Nice to hear a positive review of LED's, IndyMike. I really dislike CFLs for the communication issues they create with Insteon. Also good to hear that LED's are coming down in price. $10! That's much better than the $28 - $50 I've seen in stores lately.

Has anyone installed an LED for over 9 months yet? I'm curious about a couple of things: - Are LED's Insteon-friendly? Do they interfere with Insteon signals in a detrimental way? - If not, do they degrade over time, like CFL's do? - Did you get a dimmable LED bulb? Does it work well? - How do you like the light output compared to Incandescent or Halogen?

If you're going the AirPlay route, note that there is an app called Airfoil that can take input from things beyond iTunes and distribute the audio via Airplay. So, in the example cited previously using Google Translate, you could use Airfoil to distribute the audio wirelessly to any part of the home near an Airport Express connected to a powered speaker. The other advantage of using Airfoil is that it is Applescript-friendly - easier to manage Airplay output sources using this application than iTunes.

Thank you, Michel.

Hi, What is the most effective way to search for forum postings related to a topic? After reading the recent posting regarding a program that would intermittently trigger itself, and the response regarding the Keypadlinc 2D error, I tried searching the forums for this. The searches on the terms 'KPL 2D Keypadlinc' result in errors because the search terms are "too general". Really? What is the KPL 2D error? I've heard it's the culprit for the sporadic communication error messages in the Admin Console. If I read related postings on other sites correctly, other control applications avoid these errors and other similar issues like the v35 Switchlinc errors. Is there a technical reason why the same can't be done with ISY? How does one designate the load device for the topology feature in the Admin Console? The resulting webpage generated is a very, very handy map of an installation. BTW, I noticed some early Keypadlinc devices I have (v.1.3) have firmware versions reported as "v00" - is this normal?