| Author |
|
judetf
Senior Member
Joined: January 23 2008
Online Status: Offline
Posts: 234
|
| Posted: April 13 2009 at 07:57 | IP Logged
|
|
|
Again the caveat that I've been dealing with some noise and inconsistencies on my Insteon network recently:
A couple of times now I have noticed that Insteon "Group In" triggers are not firing when I press KPL buttons (but normally they do work). When that happens the logs show a Group Cleanup from the device/button, but they don't show the Group Broadcast that typically precedes the Cleanup.
I found this recent thread which seems to be semi-related, but as best as I can tell Pete's problems were consistent whereas mine are periodic. Additionally, I actually performed an 'add full' on the PLM this weekend, and I just saw the problem again this morning.
Thoughts? Is it time to dive into Jeff's 'error recovery' macro to understand it and implement something similar? Since PH is seeing _something_ that shows the device and the the command I sent, should I just figure out how to trap that rather than figure out why the full signal isn't being seen by PH?
Thanks,
jtf
PS - related to another thread, but I would happily join a weekly PH fireside chat to contribute whatever I might.
|
| Back to Top |
|
| |
BeachBum
Super User
Joined: April 11 2007
Location: United States
Online Status: Offline
Posts: 1880
|
| Posted: April 13 2009 at 09:02 | IP Logged
|
|
|
I believe Jeff’s and my error recovery procedures address commands sent not those received. When I had the Group In problem I circumvented it by switching to Device Chg and it worked fine for me although that doesn’t address the problem. Lee may be right when he says the Broadcast is sent without verification, if I worded it right, and that’s why the Group Cleanup is performed.
__________________
Pete - X10 Oldie
|
| Back to Top |
|
| |
grif091
Super User
Joined: March 26 2008
Location: United States
Online Status: Offline
Posts: 1357
|
| Posted: April 13 2009 at 10:07 | IP Logged
|
|
|
The Group command sequence is made up of two messages. A Group Broadcast message is sent on the powerline to no specific device. Every device on the powerline that receives the message will check its link database to see if it should respond to the message. It is this message that allows devices in a Group to turn On/Off nearly simultaneously. Because it is not addressed to any specific device, there is no ACK associated with it and therefore no retry by the sending device. A solid failure to receive the Group Broadcast message by PowerHome was determined earlier as being caused by the PLM not being written with the Add Full option. Apparently the logic in a PLC would allow a minimum of link records to be written and still work. The PLM does not work that way and requires all expected link records to be written in the PLM.
There are always possible conflicts on the powerline. Buttons on more than one switch are pressed at the same time. A Timed Event fires at the same time the Group Broadcast is being sent. Because there cannot be any retry of a Group Broadcast message, these conflicts will occur from time to time but I would expect them to be rare. On the other hand, if the powerline communication is marginal because of noise issues or signal attenuation, then the Group Broadcast will be lost more often.
As mentioned at the beginning of this post, a Group command sequence is made up of two messages. The second message, a Group Cleanup Direct, is always sent by the controller device to every responder device in the Group. Each of these messages is addressed to a specific device in the Group and is ACKed by the respective responder. If the controller device fails to receive the expected ACK it retries the Group Cleanup Direct message several times. Between the Group Broadcast message and the Group Cleanup Direct message with its associated retries, Insteon is a very reliable protocol. Generally a given responder will receive both the Group Broadcast message which caused the responder to turn On/Off, followed by the Group Cleanup Direct which is generally ignored (but still ACKed) because the responder has already reacted to the preceding Group Broadcast message. If a Group Broadcast was not received by the responder device, it will react to the Group Cleanup Direct message, turning On/Off as directed by that message.
Triggering off an Insteon Group In provides faster response time but can be intermittent when powerline issues exist. Triggering off a Dev Chg is probably more reliable but there may be some delay.
Send Group Broadcast
Send Group Cleanup Direct to device A
Receive ACK from device A
Send Group Cleanup Direct to device B
Receive ACK from device B
Send Group Cleanup Direct to device C
Receive ACK from device C
If the PLM is device C and the Group Broadcast is not received by the PLM, you can see that reacting to a Dev Chg from the Group Cleanup Direct will be noticeably slower. The most reliable is to trigger from both, as an Insteon hardware device does. React to the Group Broadcast and ignore the Group Cleanup Direct unless the Group Broadcast was not received in which case the Group Cleanup Direct causes the action. I have found my powerline network reliable such that Inteon Group In works fine but that will very much depend on the individual powerline.
__________________
Lee G
|
| Back to Top |
|
| |
judetf
Senior Member
Joined: January 23 2008
Online Status: Offline
Posts: 234
|
| Posted: April 14 2009 at 09:00 | IP Logged
|
|
|
Okay, this is fascinating and helpful, and I think I followed most of it.
Both of you seem to agree that device change triggers will be more reliable, and I am more than willing to make that switch (and am doing so as I type this).
Lee, are you suggesting to create both a Dev Chg and a Group In trigger for the same event? Assuming I had both, how do I "ignore the Group Cleanup Direct"?
|
| Back to Top |
|
| |
BeachBum
Super User
Joined: April 11 2007
Location: United States
Online Status: Offline
Posts: 1880
|
| Posted: April 14 2009 at 09:08 | IP Logged
|
|
|
I found the easiest way to disable a trigger is in the Boolean field using ph_disabletrigger. Just don’t forget to enable it.
Check out Dave's suggestion:
http://www.power-home.com/forum/forum_posts.asp?TID=2132&KW= disabletrigger&TPN=2
Edited by BeachBum - April 14 2009 at 09:10
__________________
Pete - X10 Oldie
|
| Back to Top |
|
| |
grif091
Super User
Joined: March 26 2008
Location: United States
Online Status: Offline
Posts: 1357
|
| Posted: April 14 2009 at 13:40 | IP Logged
|
|
|
Which trigger you use and if you check for both depends on the individual situation. Is the Group In reliable, how much delay is acceptable, what are the implications of missing a Group In. My powerline network is reliable because I have taken the time to make it that way. Smarthome FilerLincs have helped a great deal in that area. Also, if I miss a Group Broadcast message when my garage doors are moving, the only thing I miss is an audible TTS message that tells me the doors are moving. Just depends on what you want to do with the Group Broadcast message. Missing a motion detection at night, failing to turn on illumination lights could be more important.
There is an inherent delay when firing a trigger and have the trigger/macro respond by turning another device on/off. You just cannot compete with the near instantaneous response you get when the controller Group Broadcast directly controls one or more responders using direct links. This delay bothers some more than others and depends on the usage. Walking into a dark room, pressing the On paddle of a switch, some would like the room light(s) to come on as though you were using a mechanical switch. Others are not bothered by a slight delay. In the case of motion detection turning on outside floods for example, even a few second delay would probably be perfectly acceptable.
Powerhome is so flexible that generally there are multiple ways to accomplish any given task. Dave has published a technique and so have others on the same subject. Pete's post has a link to Dave’s suggestion.
__________________
Lee G
|
| Back to Top |
|
| |
BeachBum
Super User
Joined: April 11 2007
Location: United States
Online Status: Offline
Posts: 1880
|
| Posted: April 14 2009 at 13:55 | IP Logged
|
|
|
Lee is correct with the difference between linking the device directly to another device as compared to acting on a trigger to accomplish the same. In most cases I get my responses at lightning speed but when the system is bogged down in a queue of stuff I’m at the mercy of the system speed to go through the execution queue. If I link a device to a controller and also send a command to the same device as a result of a trigger I then randomly experience collisions on the network resulting in the module reacting weirdly. I therefore have PH do 99% of my commands to all modules in order to have complete control. I do have controllers linked to most devices but only use them in place of a system failure.
__________________
Pete - X10 Oldie
|
| Back to Top |
|
| |
judetf
Senior Member
Joined: January 23 2008
Online Status: Offline
Posts: 234
|
| Posted: April 14 2009 at 14:40 | IP Logged
|
|
|
Good food for thought. For the time being I am switching to Dev Chg triggers... Those that I already had in place seemed to create delays that I found entirely acceptable, and I'd rather have those delays than commands which are missed entirely.
(Unfortunately, while I can do my coding during the day from work, I can't ever test things until I'm home in the evening. So the triggers are all changed; we'll see how it works.)
|
| Back to Top |
|
| |
Active Topics 
Memberlist 
Search 
Help
Register 
Login
PowerHome Messageboard : PowerHome General
Topic: Group Broadcast not being captured
