| Author |
|
jeffw_00
Super User
Joined: June 30 2007
Online Status: Offline
Posts: 929
|
| Posted: February 02 2008 at 23:25 | IP Logged
|
|
|
I was mucking a bit with PLC groups to try to get what Dave had described working for KPL buttons (which I did), and somehow I did something really bad. Whenever someone presses a Controllinc button (but not a KPL button), I get an extra Group Broadcast command in addition to the normal Group Cleanup command, like
Incoming Insteon received on Insteon DM controller POWERLINC. From Address:[09.C9.94] To Address:[00.00.02] Flags:[207] Cmd1:[17] Cmd2:[0]. Decode: Group Broadcast. From: KOFFICEKEYPAD Group: 2, On &nbs p;107
and this causes the Trigger (which senses "Insteon Device Change" to detect the button press TWICE! So every press triggers the corresponding macro twice.
I rolled back my pwrhome.db file to before I started mucking. I've cleared the PLC and re-added IDs (min), I've exited/restarted powerhome, and rebuilt the links to the Controlinc. No luck, though. It still happens.
I compared pwrhome.ini to an older version. The only non-obvious, non-trivial change is that in [Insteon Explorer], linksh1 changed from 1188 to 1616
it seems that I have somehow changed Powerhome's behavior.
Before, it would detect only a Group Cleanup command generated as a result of a Controlinc keypress, and use that as a Trigger. Now, it ALSO detects a Group Broadcast command which is apparently also generated as a result of the same keypress, and it also uses -that- as a trigger. So one keypress causes 2 triggers.
I finally fixed it by changing all the Controllinc triggers from "Insteon Device Change" to "Insteon Group In", but I don't understand what changed the way PH was responding....
Any ideas on what happened?
Thanks!
/j
Edited by jeffw_00 - February 03 2008 at 00:54
|
| Back to Top |
|
| |
jeffw_00
Super User
Joined: June 30 2007
Online Status: Offline
Posts: 929
|
| Posted: February 03 2008 at 12:37 | IP Logged
|
|
|
One thing that may have caused it... I had a controlinc linked to the Powerlinc that was defective. Yesterday afternoon I replaced the controlinc in Powerhome with a new one, and so the powerlinc showed up linked to both, with one of them showing up red and unidentified in powerhome. Things didn't start being funky after the replacement, but one thing I did in the evening was that I deleted the defective one from the LINKS tab in powerhome, as well as cleared/refreshed the powerlinc as mentioned above, so maybe the delete operation tripped something?
/j
Edited by jeffw_00 - February 03 2008 at 12:38
|
| Back to Top |
|
| |
dhoward
Admin Group
Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
|
| Posted: February 06 2008 at 15:24 | IP Logged
|
|
|
Jeff,
I can explain the behavior. What you're describing is perfectly normal. The Insteon Device Chg trigger will fire on *any* Insteon command that could cause a change in status for a device.
So, in a normal setup, when a ControLinc or KeypadLinc button is pressed (that is linked as a controller of other devices), the first thing sent out will be a group broadcast command. When PowerHome sees this, it will fire the appropriate Insteon Device Chg trigger (the command *could* cause a status change). Normal Insteon behaviour is to follow the Group Broadcast command with group cleanup commands to each device within the group (as determined by the link table in the ControLinc or KeypadLinc). If PowerHome hears these group cleanup commands, it will also fire the Insteon Device Chg trigger so normal behaviour is for the Insteon Device Chg trigger to fire twice.
What can happen however is that the Insteon Group Cleanup commands may not get sent because of other Insteon traffic. So, the Group Broadcast should be transmitted. If another Insteon device (say the PLC in response to a trigger, etc.) starts to transmit ANY Insteon traffic, the group cleanup messages will be aborted and not sent. However, I don't think is what the problem was in your case.
What I think happened with you is that the ControLinc (perhaps the defective one) was not properly linked to it's controlled devices. There is a little known (or understood) anamoly about Insteon called "one way links". A normal link is two-way in that a controller has a link record in it's database declaring it as a "controller" link. The responder device ALSO has a link in it's database declaring that it is a "responder" link. It's "two-way" because there are two database records...1 in the controller device and 1 in the responder device. When the controller controls a "group", it sends a group broadcast to the group number (and doesnt need to know or "check" it's internal "controller" link). All devices then "check" their internal database to see if they've got a matching "responder" link. If they do, the react appropriately. After sending the group broadcast, the controller will then "scan" it's internal link database and send group cleanup commands for each matching record (as long as other Insteon traffic doesnt interrupt this process). A "one-way" link is when either the controller or responder link of a normal "two-way" link is missing. As you can see from above, if the "controller" link is missing, but the "responder" link exists, the group still works. The group broadcast command will be sent, but NO group cleanup commands. This *may* have been your problem. The other "fly in the ointment" is that the links in the ControLinc may actually have existed, but it's internal memory may have been corrupted (Ive personally witnessed this). The ControLinc is unique in that it has a special memory location where it store the *number* of controller links it has for a particular button. If this memory location *counter* is set to 0 (or less than the actual number), some or all group cleanups may not be sent (even though the links actually exist). The way it works, the ControLinc ONLY checks for group cleanup command to send until it reaches the number stored in the memory location. So, if button 2 has 10 total links and the memory counter for button 2 contains a 1, then you'll only ever get a single group cleanup command (for whatever is the first link in the list).
Anyways...it's easy enough to handle this and get the desired effect of ONLY executing the Insteon Device Chg trigger once. Just place the formula:
[LOCAL9] <> [LOCAL10]
in the Boolean field of the trigger. [LOCAL9] contains the previous status of the device and [LOCAL10] contains the new status. This formula will cause the trigger to ONLY fire if the status actually changes (as PowerHome sees it...it doesnt do an actual status query). For example: DININGLIGHT is a responder to CONTROLINC and is currently off. A button is pressed on CONTROLINC and a group broadcast is sent. DININGLIGHT hears the group broadcast and activates accordingly. When the trigger fires, [LOCAL9] will be 0 and [LOCAL10] will be 255. They're different, so the trigger fires. The CONTROLINC then sends the group cleanup command. The trigger fires a second time, but this time, [LOCAL9] is 255 and [LOCAL10] is 255. They're the same, so the action does not execute.
Hope this helps,
Dave.
|
| Back to Top |
|
| |
jeffw_00
Super User
Joined: June 30 2007
Online Status: Offline
Posts: 929
|
| Posted: February 06 2008 at 15:48 | IP Logged
|
|
|
Ok - thanks Dave - What is odd to me is that PH changed its behavior in how it responded to any button press on ANY of my 4 Controllincs (but oddly, not from KPL presses).
Still, changing all the Controllinc triggers from "Insteon Device Change" to "Insteon Group In" has fixed it.
Thanks!
/j
|
| Back to Top |
|
| |
Lenny
Senior Member
Joined: January 06 2008
Online Status: Offline
Posts: 102
|
| Posted: December 28 2008 at 22:48 | IP Logged
|
|
|
dhoward wrote:
Anyways...it's easy enough to handle this and get the desired effect of ONLY executing the Insteon Device Chg trigger once. Just place the formula:
[LOCAL9] <> [LOCAL10]
in the Boolean field of the trigger. [LOCAL9] contains the previous status of the device and [LOCAL10] contains the new status. This formula will cause the trigger to ONLY fire if the status actually changes (as PowerHome sees it...it doesnt do an actual status query). For example: DININGLIGHT is a responder to CONTROLINC and is currently off. A button is pressed on CONTROLINC and a group broadcast is sent. DININGLIGHT hears the group broadcast and activates accordingly. When the trigger fires, [LOCAL9] will be 0 and [LOCAL10] will be 255. They're different, so the trigger fires. The CONTROLINC then sends the group cleanup command. The trigger fires a second time, but this time, [LOCAL9] is 255 and [LOCAL10] is 255. They're the same, so the action does not execute.
|
|
|
Dave, I tried this and it doesn't work. I dumped all locals to globals in the formula being executed by the trigger so I could see them...
ph_setglobal_a ( "L1", "[LOCAL1]" ) etc...
locals9 & 10 are always the same...
Any thoughts?
|
| Back to Top |
|
| |
BeachBum
Super User
Joined: April 11 2007
Location: United States
Online Status: Offline
Posts: 1880
|
| Posted: December 28 2008 at 23:15 | IP Logged
|
|
|
If the trigger is set to any then outgoing traffic will also trigger it and that is probably what you are seeing. Dave’s work around works fine for incoming.
__________________
Pete - X10 Oldie
|
| Back to Top |
|
| |
|
|
Active Topics 
Memberlist 
Search 
Help
Register 
Login
PowerHome Messageboard : PowerHome General
Topic: double commands...
