| Author |
|
fasttimes
Groupie
Joined: March 12 2006
Online Status: Offline
Posts: 63
|
| Posted: October 09 2006 at 23:28 | IP Logged
|
|
|
I just programmed a bunch of switches to a button on my KPL.
When I press that button, everytrhing works fine, but the button blinks about 10 times after the command. Anyone else experience this?
|
| Back to Top |
|
| |
crisx
Groupie
Joined: September 14 2006
Location: United States
Online Status: Offline
Posts: 72
|
| Posted: October 10 2006 at 02:31 | IP Logged
|
|
|
I have one button on one KPL that does this. It blinks 2-4 times. I read something somewhere that explains and/or fixes this, but I can't remember where right now.
|
| Back to Top |
|
| |
cmhardwick
Senior Member
Joined: July 08 2006
Location: United States
Online Status: Offline
Posts: 290
|
| Posted: October 10 2006 at 11:14 | IP Logged
|
|
|
I THINK the blinking is letting you know one or more devices aren't acknowledging the command sent by the KPL. You might look for broken links, etc.
__________________
Cicero, Enjoying automation!
|
| Back to Top |
|
| |
dhoward
Admin Group
Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
|
| Posted: October 10 2006 at 14:22 | IP Logged
|
|
|
Hmmm...I tested this on my own older KPL and can confirm this behaviour. However, I think it has to do with the Group Cleanup messages. Ive got a couple of buttons that only control one other device. When I press these buttons, I don't get any noticable blinking. Ive also got a couple of buttons that control up to 7 other devices. When I press these other buttons, shortly after pressing, I'll get numerous blinks on this button. If I watch the SDM log during this activity, they seem to coincide with the group cleanup messages.
What happens when a KPL button or switchlinc, etc. button is pressed is that the first command that is sent is a group broadcast command (this is unacknowledged). After this command, the switch then sends an individual direct group cleanup message to every device in the group (this is acknowledged). You can interrupt this group cleanup process by using another device (or another button on the KPL) to send any other Insteon message and you'll also see that the button blinking will stop.
This is happening on my older KPL. I have not yet tested to see if this is the same behaviour on the newer KPL's. I know there was a blinking issue with Insteon traffic on older KPL's but don't know if this is related or not.
Dave.
|
| Back to Top |
|
| |
cmhardwick
Senior Member
Joined: July 08 2006
Location: United States
Online Status: Offline
Posts: 290
|
| Posted: October 10 2006 at 16:59 | IP Logged
|
|
|
The reason I was thinking it was some indication of communication failure was because the times I've seen it was on a KPL where I pressed the button that controls an In-LineLinc unit that had the power cut to it, and I got the multiple blinks after pressing it. power restored back to the In-LineLinc, no blinking.
I've very rarely had it occur on another KPL button linked to 2 or 3 switches.
__________________
Cicero, Enjoying automation!
|
| Back to Top |
|
| |
fasttimes
Groupie
Joined: March 12 2006
Online Status: Offline
Posts: 63
|
| Posted: October 10 2006 at 21:29 | IP Logged
|
|
|
Dave,
Speaking of "group cleanup", could you please explain what each of the checkboxes are for on the insteon explorer?
|
| Back to Top |
|
| |
dhoward
Admin Group
Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
|
| Posted: October 12 2006 at 15:05 | IP Logged
|
|
|
Cicero,
In that situation, it would definately be related. If a device is communicating and responds quickly, the group cleanup command is sent and answered with very little communication. If the device is off and not responding, the group cleanup command would be repeated by any listening switch and would cause more communication on the line so I could see this happening as well. Good point  .
Fasttimes,
Certainly. The Poll Interval is how often (in seconds) that PowerHome will attempt a background process. Background processes are what appear in the "Pending Operations" window. Control commands coming from PowerHome (either direct or group) take priority over the background operations and do not appear in the "Pending Operations" window. The default is 10 seconds and PowerHome will perform a queued background operation every 10 seconds. You can change this value (and tab off of the field) and the change will take place immediately. If you set this value to 0, no background operations will be performed.
The "Status Scan" box enables or disables the "Poll Status" background operation. The Poll Status operation gets the current level status as well as the database changes flag (which lets PowerHome know if database changes have occurred and whether PowerHome should rescan the links).
The "Level/Ramp/X10 Scan" goes hand in hand with the "Status Scan". If Status Scan is disabled, then this flag has no effect. If Status Scan is enabled and Level/Ramp/X10 Scan is enabled, then when a "Poll Status" operation is performed, PowerHome will also scan the "local" level, ramprate, and X10 address.
The "Link Scan" flag controls whether PowerHome will scan a remote devices link database. PowerHome will scan a devices link database when it thinks changes have occurred (as determined by the Status Scan and Poll Status operation) if this field is checked.
The "Write Level/Ramp/X10" field controls whether PowerHome will attempt to write the "local" settings for level, ramprate, and X10. This is determined by a "difference" in the "Local Level" and "Desired Local Level", etc. fields in the Devices tab. It's usually best to keep this flag disabled and let PowerHome scan the current settings. In a fresh system, PowerHome will set the "Local" and "Desired" fields to the same "scanned" value. If you wish to change the currently stored value, set the "Desired" field to the desired setting and save your changes. Then enable this field and PowerHome will program all devices where the local and desired fields do not match. When done, disable this setting and airgap the affected switches. You could leave this field always checked and PowerHome will always overwrite any scanned values with the desired values but these writes will not take effect until the switch is airgapped.
The "Update on ACK" column controls how PowerHome updates it's internal database of device status. The earlier version of PowerHome would ONLY upate on an ACK. What this means is that PowerHome would send a direct Insteon command to a device. Since Insteon is inherently two-way, PowerHome would wait to receive an ACKnowledge command from the controlled switch before updating it's internal status. With this flag on, then PowerHome would only set it's device status if a switch actually responded to a sent command. This caused problems with the web-based Device Status screen where you would send an Insteon command, the page would be refreshed and the device would show the state as unchanged. If you refreshed a second time, then the status would be correct because the ACK would have been received by now. It was also a problem because sometimes the device would receive the command and control OK, but the ACK message would be lost due to noise or some other factor (yeah, I know, isnt supposed to happen  ). Leaving this box unchecked, PowerHome will update the internal device status when the command is sent (in addition to also updating on ACK). It's a tossup as to which mode is more accurate because you can control a device and the controlling command is lost or you can control a device and the responding ACK is lost. Most people are probably content to leave this box unchecked because they're already used to X10 and the fact that it is inherently only 1 way.
The "PLC Group Cleanup" flag controls whether PowerHome will send group cleanup messages after sending a group broadcast command. The previous version of PowerHome had this hardcoded as checked. The Insteon protocol states that after sending a group broadcast command, a device would then follow this up with individual group cleanup commands to each member of the group. Group cleanups cause a lot of addtional Insteon traffic and it's up to the user if he wants them or not. The way a group command works is that the PLC sends a single group broadcast command that it is turning on it's group 5. Group Broadcast commands are NOT Acknowledged so the PLC doesnt know if the command is heard by every device or not. Any device hearing this command will search it's link database to see if it's supposed to respond or not. This is the main command that will make all lights appear to act in sync. Since the broadcast is not acked, you can have the PLC send individual group cleanup messages. These group cleanup messages are direct commands and ARE acknowledged. These happen sequentially one after another. You'll see this behaviour when switching a KPL or SwitchLinc that controls multiple devices. If all is working well, all lights come on together. Occasionally though, you'll see most of the lights come on together followed by one or two lights coming on afterwards sequentially. These one or two lights are the result of the group cleanup commands.
The "Scroll Log" flag determines whether the "Insteon SDM Log" window will auto scroll as commands are sent/received. If you're trying to read the log data, it's hard to scroll back without it scrolling forward when new data arrives. Unchecking this box will still allow commands to be logged, but the window will now no longer auto scroll it into view.
The "Tab Scrollbars" option adds horizontal and vertical scrollbars to the tabbed window in the Insteon Explorer. This would just be a personal preference and primarily useful for people running very low screen resolutions and the default Insteon Explorer screen does not fully fit within the window.
Whew! Hope this helps,
Dave.
|
| Back to Top |
|
| |
|
|
Active Topics 
Memberlist 
Search 
Help
Register 
Login
PowerHome Messageboard : PowerHome General
Topic: Blinking button on KPL
