| Author |
|
phil13
Groupie
Joined: December 19 2004
Location: France
Online Status: Offline
Posts: 60
|
| Posted: December 21 2004 at 02:03 | IP Logged
|
|
|
hi,
Rather make 16 triggers for a code house, i want to make only one trigger and manage the 16 unit codes inside only one macro. This because i think it is easier to maintain.
For example, if i receive any unit of A code, i start a macro "Received A".
In this macro "Received A" i do :
- if i received unit 1 do that ...
- if i received unit 2 do that ...
...
- if i received unit 16 do that ...
I've tried to do that with "trigger any ID number" and "[X10Pi] variables but i can't make it to work ...
I don't understand what is the meaning of any (before buffer) and any (after buffer).
I also don't understand for [X10pi] then meaning of "X10 signal not excluded in the global buffer".
Also, it is possible to do the same with "X10 OUT" ?
In a macro "Send A" i do :
- if i send unit 1 do that ...
- if i send unit 2 do that ...
...
- if i send unit 16 do that ...
Thanks for your help
Philippe
|
| Back to Top |
|
| |
dhoward
Admin Group
Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
|
| Posted: December 21 2004 at 13:32 | IP Logged
|
|
|
Phillipe,
Lets start out with a little X-10 primer and how PowerHome works on the inside  . This may be info you already know, but I'll go ahead and explain so others can learn as well.
What appears as a single X-10 command to most people is actually two separate communications. When you want to turn a light A1 ON, most people will think simply A1 ON. But X-10 really needs this simple command broken into two separate ones. First will be sent an address command. I wont go into too much detail here other than what is sent is a flag letting devices know that this is an address command followed by housecode A, unitcode 1. Any X-10 device at this address is now considered "Addressed". An addressed unit, will now respond to all "functions" that are sent to the same housecode. A unit will remain "addressed" until another address command is sent to the same housecode following a "function" command sent to the same housecode. This sounds confusing, but is actually simple once it's made clear. I'll get back to this in a moment. After we've sent the "A1" address command, a "function" command typically follows. What would be sent next is a flag that identifies this command as a "function" versus an "address" followed by the housecode (A in this case) followed by the actual command (such as "on", "off", "dim", "bright"). In our particular example above it will be "A ON". This "function" command tells all addressed units in housecode A to turn "on" (assuming that the addressed unit is designed to respond to this command).
Now getting back to our discussion above, it's possible to send out multiple "address" commands to a housecode followed by a single "function" command and have all the units respond together as a group (they will all turn "on" together, "off" together, "dim" together, etc). They will continue to act as a group as long as "functions" are sent to that housecode. They will all become unaddressed as soon as another "address" command for the same housecode is received. Keep in mind that housecodes are separate entities and what happens in one housecode has no effect on any other housecode. To illustrate this is an example:
Send A1 A1 is addressed
Send A3 A3 is addressed
Send A7 A7 is addressed
Send A14 A14 is addressed
Send A ON A1,A3,A7, and A14 all turn ON
Send A DIM A1,A3,A7, and A14 all dim
Send B2 B2 is addressed (no effect on housecode A)
Send A2 A2 is addressed (A1,A3,A7, and A14 are all UNADDRESSED now)
Send A ON A2 turns ON
etc.
Now that we have basic X10 operation down, we'll delve a little into PowerHome internals.
To keep track of everything, PowerHome has a number of internal arrays. In basic X-10 we have 16 housecodes each with 16 unitcodes. We can represent this with a 16 by 16 array for a total of 256 possible addresses. Everytime an X-10 address is received or sent, PowerHome tracks this by flipping boolean values in the array. When a "function" is sent or received, PowerHome will then cycle throught that housecodes array elements to see which units are addressed and apply the "function" to the "addressed" units. If a new address command is received after a function command, then the housecode elements are unaddressed.
At a very basic level, this is what is happening within PowerHome. However, PowerHome also provides some additional controls in the form of its X-10 buffers. PowerHome maintains a global buffer as well as buffers for each of the 16 housecodes. These buffers are only populated on incoming X-10 commands. All incoming X-10 commands are placed into the buffers unless they are excluded by placing a checkmark in the "Previous Exclude" field in the X-10 Unitcodes screen in the PowerHome Explorer. Each incoming command will be placed in the appropriate housecode buffer as well as the global buffer. Another setting that is important in this sequence is the "Previous X-10 Incoming Timeout" field in the Setup->Controllers->X-10 section of the Explorer. What this field controls is the number of seconds between incoming X-10 transactions. If the time an incoming X-10 transaction occurs is greater than the number of seconds in this field than the previous transaction, then the previous transaction will be "zeroed" in the incoming buffers. This is useful when checking for pairs or more incoming X-10 transactions needing to be received within so many seconds of one another.
The system variables [X10P0] thru [X10P19] work on the global incoming buffer. To access the housecode buffers, you need to use the ph_multix formula function (you can also access the global buffer with this function). Each of the buffers contain the last 20 incoming X-10 commands. Keep in mind that for each command buffer, there is also a corresponding entry in the incoming X10 time buffer that contains the time of the command. The format of the data in the buffers is the housecode (1 character), the unitcode (2 characters), and the command (2 characters). So are A1 ON example would be A0102.
With that out of the way, this is what happens within PowerHome:
An incoming X-10 transaction is received. In this case we'll assume it's an address command for A1. What occurs in PowerHome is:
1. The internal address array is updated. If "functions" have been received on Housecode A since the last address, then all of housecode A is flagged as unaddressed. A1 is now flagged as addressed.
2. The trigger for Housecode A, Any (Before Buffer), Addressed is checked.
3. The trigger for Housecode A, 1, Addressed is checked.
Next, an incoming X-10 transaction is received for A ON. What happens in PowerHome is:
1. The trigger for Housecode A, Any (Before Buffer), ON is checked. We have no way of knowing at this point what unitcode is involved because we havent yet checked to see what has been previously addressed in Housecode A.
2. Now we check to see what unitcodes have been previously addressed within Housecode A. We do this by starting at 1 and working our way to 16. If a particular unit is addressed, then we make an appropriate entry in the Housecode A buffer as well as the global buffer. We do this by first checking if this house/unit should be excluded. If it's not excluded, it's added to the buffers. We next check the time of the previous command for both the Housecode A buffer and the global buffer. If the previous time exceeds the incoming timeout, then we "zero" out the previous command in the buffer. we then check the trigger for Housecode A, the unit that is addressed, ON.
3. We now check the trigger for Housecode A, Any (After Buffer), ON. When this trigger fires, the incoming X-10 buffers have been updated and we have available some unitcodes. The [TEMP3] system variable will contain the unitcode of the last addressed unit in housecode A.
This last statement will take a little explaining. When multiple units are addressed, PowerHome does not track in what order they were addressed. If incoming X-10 commands A1, A5, A3, A2 were to come in in that order, PowerHome would not know the difference between A5, A2, A1, A3 or any other combination. PowerHome only tracks whether a unit is addressed or not. Consequently, the incoming X-10 buffers will be populated from smallest to largest. If the incoming sequence was A5, A2, A1, A3, AON then PowerHome would set the incoming X-10 housecode A buffer as A0502A0302A0202A0102. This also means that the unitcode that will be placed in the [TEMP3] variable when the incoming X-10 housecode A, Any (After Buffer), On trigger fires will be 5.
What does this all mean? In situations where incoming X-10 commands are generated by palm pads, keychains, motion sensors, etc., the commands will come in unitcode / function order. You can setup a single trigger to handle all incoming X-10 commands for housecode A, function ON by declaring the trigger for Housecode A, Any (After Buffer), ON and accessing the unitcode via the [TEMP3] variable. Typically only another controller would ever send commands as multiple unitcodes followed by a function. In this situation, the Any (After Buffer) trigger would only contain the unitcode of the highest addressed device within housecode A.
In the case of outgoing X-10, PowerHome works in a similar manner.
Sorry to be so long-winded, but it's a difficult subject with no easy way to explain without giving a little detail and background 
Let me know if you need more info.
Dave.
|
| Back to Top |
|
| |
phil13
Groupie
Joined: December 19 2004
Location: France
Online Status: Offline
Posts: 60
|
| Posted: December 22 2004 at 03:33 | IP Logged
|
|
|
Thanks for your explanation.
All these functionnalities are very powerfull.
For the input, all is OK.
Just a question about the ph_multix formula :
If i received a "ALL OFF", i can't have it with the formula ?
For the output, you said :
"In the case of outgoing X-10, PowerHome works in a similar manner."
If i've a trigger on X10_OUT and Any unit, what is the variable with the code unit effectively sended ?
[TEMP3] and ph_multix formula seem to be working only for input ...
Philippe
|
| Back to Top |
|
| |
dhoward
Admin Group
Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
|
| Posted: December 22 2004 at 12:32 | IP Logged
|
|
|
Phillipe,
Glad to hear the input is working for you now
Concerning the ph_multix function...you are correct. It does not pick up the "ALL OFF" command. The incoming X-10 buffers only work with on, off, dim, and bright commands (these commands work with "unitcodes"). The "ALL OFF" command does not require any units to be addressed and will turn off any units designed to respond to the command, addressed or not. You would have to add another trigger using the "Any (Before Buffer)" to pick up this command.
You can however, make it call the same macro as your "on" and "off" commands. There are a couple of ways to determine within the macro what course of action to take. The [TEMP1] system var will contain the ID of the trigger that called it. You could parse off of that to determine how the macro should proceed. You can get even more flexibility by changing the action of the trigger from macro to formula and then calling the macro using the ph_macroparm function. This function allows you to pass in values to the system variables [LOCAL1] thru [LOCAL5]. In the action formula of the trigger, you could use one of these variables to hold the X-10 command. You could even expand upon this and have one of the vars hold the housecode and then have multiple triggers for different housecodes all calling the same macro.
Concerning the X-10 out. The ph_multix function and the X-10 buffers are only for incoming X-10. I checked out the code for outgoing X-10 and see that it only has an "Any" value. This is equivalent to the "Any (Before Buffer)" so the [TEMP3] variable will not have a unitcode  .
However, the code for trigger checking is the same whether it be incoming or outgoing so we can fix this easy enough. All we have to do is add a dropdown for the "Any (After Buffer)" selection (we'll also fix the "Any" so it shows "Any (Before Buffer)" to be consistent). Open the "Direct SQL" window under the "Maintenance" menu and copy and paste the following SQL:
update all_value_data set id = 'A1',key_desc = 'Any (Before Buffer)' where id = 'X-10' and key_number = 0 and type = 33;
update all_value_data set id = 'A1',key_desc = 'Any (Before Buffer)' where id = 'X-10' and key_number = 0 and type = 34;
insert into all_value_data values ('A2',100,'Any (After Buffer)',33);
insert into all_value_data values ('A2',100,'Any (After Buffer)',34);
If you go into the Triggers screen now, the X-10 out trigger should now have both "Any (Before Buffer)" and "Any (After Buffer)" selections and the After Buffer should now contain the unitcode in the [TEMP3] variable.
I am currently at work so cant verify by testing, but this should be the case after verifying the code. Let me know how it goes.
BTW...you'll need to reapply this SQL everytime you rebuild your database. I'll make it permanent in the next version.
Dave.
|
| Back to Top |
|
| |
phil13
Groupie
Joined: December 19 2004
Location: France
Online Status: Offline
Posts: 60
|
| Posted: December 22 2004 at 14:00 | IP Logged
|
|
|
Dave,
Ok i'm going to try but you said "BTW...you'll need to reapply this SQL everytime you rebuild your database. "
heu ... I haven't enough experience to know when i rebuilt the database .... each time i start powerhome, or each time i add code ? does i have to do a special action for rebuilt ?
|
| Back to Top |
|
| |
dhoward
Admin Group
Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
|
| Posted: December 22 2004 at 15:17 | IP Logged
|
|
|
No problem Phil ...the database is rebuilt through the Database Maintenance Utility (phupg.exe). You would really only need to do this occasionally.
One thing I might mention is that your eventlog can grow very large if you are logging every event. What most people do is create a timed event to run every night (say just after midnight) to trim the event log. There is a macro command to do this as well as the ph_trimeventlog function. This will keep the eventlog and consequently the database at a manageable size. If for some reason you didnt trim the log and your database grew to a very large size (> 25 MB is getting large), you would want to do a trim. After trimming however, the size of the DB file does not shrink. This is where rebuilding would be useful. The extra space is reclaimed and your database will be compact.
So, go ahead and apply it. Some people never rebuild the database and chances are you wont before the next release
Dave.
|
| Back to Top |
|
| |
phil13
Groupie
Joined: December 19 2004
Location: France
Online Status: Offline
Posts: 60
|
| Posted: December 23 2004 at 04:38 | IP Logged
|
|
|
OK Dave, it work's fine. Thanks.
|
| Back to Top |
|
| |
|
|
Active Topics 
Memberlist 
Search 
Help
Register 
Login
PowerHome Messageboard : PowerHome Programming
Topic: trigger any ID number
