Active TopicsActive Topics  Display List of Forum MembersMemberlist  Search The ForumSearch  HelpHelp
  RegisterRegister  LoginLogin
PowerHome Bug Reports
 PowerHome Messageboard : PowerHome Bug Reports
Subject Topic: Trigger Action Styles Post ReplyPost New Topic
Author
Message << Prev Topic | Next Topic >>
dhoward
Admin Group
Admin Group
Avatar

Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
Posted: October 25 2001 at 00:34 | IP Logged Quote dhoward

It has come to my attention that there is some confusion over the Action Style of Triggers. The action style can be either Immediate or Queued. Generally, you want your action styles to be queued. The only time you would want your action styles to be immediate would be if the action (macro or send keys) are going to access the multi-X system variables (the previous incoming X-10 stack). Another time you would use the Immediate action style would be to update a global variable immediately which other actions in the execution queue may be dependent upon. If your action does have an immediate action style, the action absolutely must not send commands to the connected controllers. You can execute commands to the controller, but these actions must be queued. A good example of this can be seen in the sample database with the triggers that start with PP K and the macro that they call PP K ALL. The triggers must be immediate because the PP K ALL macro uses the multi-X system variables. However, within the macro, any IR or X-10 send commands are posted instead of immediate.

What happens is that the CM11A can transmit multiple received commands to PowerHome. PowerHome will act upon each command in order, firing triggers as necessary. If one of these triggers is immediate and attempts to send X-10 commands to the controller, the remaining commands in the receive queue will be destroyed and you will get a critical error on line 7 of function f_controllerrecv.

However, you must use the immediate action style if the action accesses the multi-X variables. In the example above, if the trigger is queued and multiple received commands are processed, when the queued action is executed, the multi-X variables will already have been updated by the subsequent received commands.

The other instance where immediate is handy can be seen the sample database with the DSS POWER trigger. This trigger is using a global variable to track the current power state of a DSS receiver. Anytime an infrared POWER command is sent to the DSS receiver, the global variable is toggled between 1 and 0. Since no commands are being sent to a controller, this is safe to do. If this trigger was queued instead of immediate, you could run into a problem with queued macros. If queued macro 1 sent a DSS POWER command, and queued macro 2 had a conditional statement to send a DSS POWER command based upon the status of the global variable, the second queued macro would not respond correctly because the trigger fired by the first macro would not execute until after the second queued macro.

I know this sounds complicated, but when you understand the principle, it actually makes sense.

I welcome any questions or suggestions on this issue either posted or via Email.

Thanks,

Dave.
Back to Top View dhoward's Profile Search for other posts by dhoward Visit dhoward's Homepage
 
dhoward
Admin Group
Admin Group
Avatar

Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
Posted: October 25 2001 at 21:24 | IP Logged Quote dhoward

Changes have been made to remove the critical error you receive when sending to the controller from an immediate trigger fired by a controller receive. All two-way controllers now function such that any send commands while receiving will be buffered and then sent after the receive is completed. This will yield an effect much as if one had posted the controller send commands from the immediate macro. The trigger action style of Immediate and Queued is still intact as you have finer control when working with multiple controllers but you will no longer have to worry about critical errors if you forget. Look for version 0.0.11a within a week.

Also, a lot of you have asked for it, the byte values of received X-10 in the Event log are now decoded. Look for it in 0.0.11a.

Dave.
Back to Top View dhoward's Profile Search for other posts by dhoward Visit dhoward's Homepage
 

If you wish to post a reply to this topic you must first login
If you are not already registered you must first register

  Post ReplyPost New Topic
Printable version Printable version

Forum Jump
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot delete your posts in this forum
You cannot edit your posts in this forum
You cannot create polls in this forum
You cannot vote in polls in this forum