Avoid to configure hardware triggers if the developers know what behavior must be addressed

Describe the aim of the proposed feature?
This feature allows to avoid XML hardware triggers creation for protocols that 
know the final value fom a behavior.

Describe how you would implement this feature
From Gabriel's mail:

About the trigger configuration, my idea with the "autodefine" protocol is that 
the same way the protocolEvent needs to know about the objectClass, it would be 
great if we could just add to the protocolEvent the "behaviorName" that the 
event is going to change.
As always, if the behaviorName is not defined, we could use the normal trigger 
configuration.

This way the protocolEvent could send somethig like:

ProtocolRead event = new ProtocolRead(this, "X10", "A01");
event.addProperty("object.class", "Light");
event.addProperty("behaviorName", "powered");
event.addProperty("behaviorValue", value);
event.addProperty("object.name", "My X10 Light");
Freedomotic.sendEvent(event);

I know that this would couple the hardware with the object abstraction, but I 
think that in the moment we use the object.class  (or the join device feature) 
it is already coupled, so it could use also the information if it is already 
there.

List external resources that can be useful

How much you feel this feature will be useful for the project?

[ ] Optional
[ ] Usefull
[X] Can make the difference
[ ] Necessary

Original issue reported on code.google.com by enrico.n...@gmail.com on 29 Nov 2012 at 11:18

akipta / freedomotic

Avoid to configure hardware triggers if the developers know what behavior must be addressed #208