| Author |
|
dhoward
Admin Group
Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
|
| Posted: July 12 2007 at 14:15 | IP Logged
|
|
|
Sorry to take so long in getting this information out...
The UDP Broadcast server sends 4 types of PowerHome messages throughout your internal network via UDP. In the PowerHome Explorer under Setup|Broadcasts, you can send these 4 message types all to the same port or to 4 different ports (the default).
The UDP messages consist of a header followed by the data. The Header of each UDP message is unique with each UDP message being broadcast a total of 3 times (the header will still be unique however with a single byte changing representing the Message Number).
The structure of the message header is as follows:
Code:
The ASCII message type (PHCONTROL, PHTRIGGER, PHDEVICECHG, PHCCCHG)
Line Feed
Message Number (1 to 3)
Numeric message type (10, 11, 12, 13)
The numeric "Day" value (1 to 7. Sunday is 1).
The message sequence for the day (Sequence starts at 1 and resets to 1 each new day)
Line Feed
|
|
|
An example message header is below:
The above message header represents a PowerHome Control message. These messages are sent when PowerHome starts up, reinitializes, turn Timed Events on/off, etc. The ASCII message type is: PHCONTROL
This is followed by a line feed (ASCII char 10) followed by the message number...in this case, a 1. This lets you know that this particular UDP broadcast is the first message sent and is not a repeat message. If the message number had been a 2 or a 3, then it's a repeat message.
Following the message number is 10. This is the numeric representation of the message type (PHCONTROL).
The next value is a 2 which represents that the message was generated on a Monday.
The next set of numbers is the message sequence number (135). This represents the 135th PHCONTROL type message sent on this day (Monday). The message sequence is reset on each new day and will increment as high as necessary for any particular day. This sequence is followed by another line feed (char 10).
This particular message header will be unique for at least a week. It will not appear again until at least the following Monday.
Following the message header will be the message data. The message data layout differs based upon the type of message. But follows a consistent format of a row of data terminated by a carraige return / line feed pair (char 13 followed by char 10) with individual data elements separated by a tab character.
In the case of PHCONTROL messages, the data consists of a simple ASCII representation of the action such as TIMEDEVENTSON, STARTUP, and SHUTDOWN.
More info to come. If anyone has any specific questions on the UDP message structure, please feel free to ask.
Dave.
|
| Back to Top |
|
| |
cmhardwick
Senior Member
Joined: July 08 2006
Location: United States
Online Status: Offline
Posts: 290
|
| Posted: July 12 2007 at 19:42 | IP Logged
|
|
|
Can you give examples of the message data for say Timed events, Switches on/off, groups on/off, etc? This would let us know exactly what to look for and how to parse it.
Thanks for this feature!
__________________
Cicero, Enjoying automation!
|
| Back to Top |
|
| |
TonyNo
Moderator Group
Joined: December 05 2001
Location: United States
Online Status: Offline
Posts: 2889
|
| Posted: October 04 2007 at 23:06 | IP Logged
|
|
|
If a trigger calls a macro, isn't the macro name passed in the Trigger Message?
10/03/07 22:44:46: frmUDPListener->sockPHTrigger_DataArrival, Trigger Message,
PHTRIGGER
1114232
8 D 100 & nbsp; 2 0 ; 4 0 &nb sp; ,
|
| Back to Top |
|
| |
TonyNo
Moderator Group
Joined: December 05 2001
Location: United States
Online Status: Offline
Posts: 2889
|
| Posted: October 22 2007 at 20:31 | IP Logged
|
|
|
Bump... 
Plus, is this format still valid?
|
| Back to Top |
|
| |
dhoward
Admin Group
Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
|
| Posted: October 29 2007 at 12:37 | IP Logged
|
|
|
Whoops, sorry guys  .
The PHTRIGGER broadcast does not pass the name of a macro. This broadcast is not sent when a trigger is fired...instead, this broadcast is sent *anytime* an action occurs that causes a trigger to be checked...whether a trigger actually exists or not. In other words, it's at a much lower level and is a direct pipeline into the guts of PowerHome. If an X10 command is sent (or received) or a global variable is changed, or any condition occurs that PowerHome has triggers for, then a UDP PHTRIGGER broadcast will be sent...even if a trigger for it isnt specifically declared within PowerHome. This allows for remote applications to know at a very low level what is occurring within PowerHome (and react) without having to preconfigure PowerHome to specifically act on that triggerable instance. Since the PHTRIGGER UDP broadcast is being sent on *any* action that may cause a trigger, no macro ID is sent because a trigger may not have even been defined for the action (the UDP broadcast is sent before PowerHome even knows that a trigger exists or not).
More to come...I'll document the PHTRIGGER layout within the next couple of hours.
Dave.
|
| Back to Top |
|
| |
dhoward
Admin Group
Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
|
| Posted: October 29 2007 at 16:33 | IP Logged
|
|
|
Ok,
While researching this, I did come across a bug. The PHTRIGGER messages will only be sent if "Control" UDP messages are enabled in addition to PHTRIGGER UDP messages. I'll get this fixed for .13.
The structure of PHTRIGGER UDP messages is identical to whats been detailed above (the UDP message header). The ASCII message type will be PHTRIGGER and the numeric message type will be 11.
The message data for PHTRIGGER messages (the data following the header) will consist of 9 fields of data, each separated by a tab character and terminated with a carriage return/line feed pair.
The first parameter will be a number and tells you the specific type of trigger that is being checked. A table of these values is below:
1 IR Out
2 IR In
3 X10 Out
4 X10 In
5 Digital Out
6 Digital In
7 Analog In
8 X10 RF In
9 Virtual X10
10 WM_COPYDATA
11 WM_USER
12 Socket
13 X10 RF In Ext
14 Global Variable
15 Analog Out
16 Insteon Group In
17 Insteon Group Out
18 Insteon Direct In
19 Insteon Direct Out
20 Insteon Device Chg
22 Multi-State In
23 Temperature
26 Generic Controller
27 Generic Plugin
28 Insteon Broadcast In
29 Insteon Broadcast Out
30 Insteon Direct In (ACK)
32 System Process
After the trigger type will be a string representing the "Trigger ID". Next will be a number for the "Trigger ID Value". This will be followed by a number representing the "Trigger Value". These first 4 values are what is passed to the internal PowerHome trigger evaluator to determine if a trigger has been defined for the criteria.
The remaining 5 values will be dependant upon the type of trigger being checked and can be either blank or zero. Normally these values will include additional data that is made accessible to the trigger in the [TEMP] variables.
Hope this helps and let me know if there is additional info you would like.
Dave.
|
| Back to Top |
|
| |
TonyNo
Moderator Group
Joined: December 05 2001
Location: United States
Online Status: Offline
Posts: 2889
|
| Posted: October 29 2007 at 19:34 | IP Logged
|
|
|
Thanks Dave! 
|
| Back to Top |
|
| |
eHomeCreations
Groupie
Joined: February 02 2007
Location: Ukraine
Online Status: Offline
Posts: 64
|
| Posted: November 06 2007 at 14:54 | IP Logged
|
|
|
Question.
What is the best way to retrieve ALL device status's at one time? Like the first time my app starts up.
Thanks.
Edited by eHomeCreations - November 06 2007 at 14:55
__________________
--Steve http://www. ehomecreations.com
|
| Back to Top |
|
| |
dhoward
Admin Group
Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
|
| Posted: November 06 2007 at 16:39 | IP Logged
|
|
|
Steve,
The best way is to probably make a request to the PowerHome Socket Server. The Socket Server is documented in the current PowerHome Users Manual (at least most of it is) and a sample VB program complete with source is available on the download page that shows how to use and format commands to the Socket Server.
The part that isnt yet documented, is the actual SS request to retrieve Device Status info. There is a recent command called GETDS that will return entire Device Status info in either XML or CSV format. This command is shown below in the standard SS format which is closely modeled after standard HTTP requests:
GETDS~nAuthorization: Basic USERID:PASSWORD_IN_BASE64~nContent-Length: LENGTH_OF_REQUEST_DATA~n~nREQUEST_DATA
The REQUEST_DATA consists of 5 tab separated numeric values. The first value is either 1 or 2 and determines the structure of the returned data. A 1 will return XML data and a 2 will return CSV data which should be in the same format as the UDP message. The remaining 4 values are the numeric values of the colors to be applied to the returned rows. This data is probably not useful to you so you can instead supply 4 tab separated zeros. If you are interested, the first color value is for even rows foreground color, the second color is for even rows background color, the third is for odd row foreground colors, and the fourth is for odd row background colors. A complete SS request command for CSV data without regard for color would look like this:
GETDS~nAuthorization: Basic USERID:PASSWORD_IN_BASE64~nContent-Length: LENGTH_OF_REQUEST_DATA~n~n2~t0~t0~t0~t0
Hope this helps,
Dave.
Edited by dhoward - November 06 2007 at 16:39
|
| Back to Top |
|
| |
eHomeCreations
Groupie
Joined: February 02 2007
Location: Ukraine
Online Status: Offline
Posts: 64
|
| Posted: November 06 2007 at 17:01 | IP Logged
|
|
|
Thats just what I needed.
Thanks Dave
__________________
--Steve http://www. ehomecreations.com
|
| Back to Top |
|
| |
eHomeCreations
Groupie
Joined: February 02 2007
Location: Ukraine
Online Status: Offline
Posts: 64
|
| Posted: November 07 2007 at 10:57 | IP Logged
|
|
|
"CSV data which should be in the same format as the UDP message."
It was off just a hair but no problems otherwise.
__________________
--Steve http://www. ehomecreations.com
|
| Back to Top |
|
| |
cmhardwick
Senior Member
Joined: July 08 2006
Location: United States
Online Status: Offline
Posts: 290
|
| Posted: November 07 2007 at 13:53 | IP Logged
|
|
|
Hmm, could be usefully for when i starup xLobby to get the current status of all teh devices. After that, it's fine as they change, etc. Have to look into this one 
__________________
Cicero, Enjoying automation!
|
| Back to Top |
|
| |
eHomeCreations
Groupie
Joined: February 02 2007
Location: Ukraine
Online Status: Offline
Posts: 64
|
| Posted: November 10 2007 at 20:12 | IP Logged
|
|
|
Good morning again!!! Its only 3am 
Question.
Is there a way to grab global VARS on startup? Maybe something similar to the 'GETDS' function?
Thanks again! I really got to go to bed...
__________________
--Steve http://www. ehomecreations.com
|
| Back to Top |
|
| |
eHomeCreations
Groupie
Joined: February 02 2007
Location: Ukraine
Online Status: Offline
Posts: 64
|
| Posted: November 14 2007 at 20:31 | IP Logged
|
|
|
eHomeCreations wrote:
Good morning again!!! Its only 3am
Question.
Is there a way to grab global VARS on startup? Maybe something similar to the 'GETDS' function?
Thanks again! I really got to go to bed...
|
|
|
OK, its 3:30am... Any ideas on this?
I guess I could write a macro but would hate to re-invent the wheel.
__________________
--Steve http://www. ehomecreations.com
|
| Back to Top |
|
| |
TonyNo
Moderator Group
Joined: December 05 2001
Location: United States
Online Status: Offline
Posts: 2889
|
| Posted: November 14 2007 at 21:45 | IP Logged
|
|
|
I just made a potentially helpful post on your forum...
|
| Back to Top |
|
| |
dhoward
Admin Group
Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
|
| Posted: November 15 2007 at 13:26 | IP Logged
|
|
|
Steve,
Ive been thinking about this and no real good way currently exists. No reason why I cant add a new command to the socket server though that will return the global variable data in the same format that the device status comes now. The only problem is, it won't be available until I get the next version out  .
However, I have been able to come up with something that may work for you until then. Make a call to the Socket Server as a formula type and pass the following formula:
Code:
| ph_rtne(ph_sqlselect(10,"select * from global_variables")) + ph_gethtmldata(10) + ph_rtne(ph_sqldestroy(10)) |
|
|
This will return all of the global variables in a single string formatted as an HTML table. You should be able to parse it out without too much trouble.
Sorry I couldnt come up with anything better.
Dave.
|
| Back to Top |
|
| |
eHomeCreations
Groupie
Joined: February 02 2007
Location: Ukraine
Online Status: Offline
Posts: 64
|
| Posted: November 15 2007 at 13:49 | IP Logged
|
|
|
dhoward wrote:
Steve,
Ive been thinking about this and no real good way currently exists. No reason why I cant add a new command to the socket server though that will return the global variable data in the same format that the device status comes now. The only problem is, it won't be available until I get the next version out .
However, I have been able to come up with something that may work for you until then. Make a call to the Socket Server as a formula type and pass the following formula:
Code:
| ph_rtne(ph_sqlselect(10,"select * from global_variables")) + ph_gethtmldata(10) + ph_rtne(ph_sqldestroy(10)) |
|
|
This will return all of the global variables in a single string formatted as an HTML table. You should be able to parse it out without too much trouble.
Sorry I couldnt come up with anything better.
Dave.
|
|
|
This is just fine. And i am learning more and more about powerhome everyday. I think between the 2 'homies' my head is going to blow up!
__________________
--Steve http://www. ehomecreations.com
|
| Back to Top |
|
| |
TonyNo
Moderator Group
Joined: December 05 2001
Location: United States
Online Status: Offline
Posts: 2889
|
| Posted: February 11 2008 at 14:18 | IP Logged
|
|
|
How about the format of the X10 RF In broadcast?
It looks like the five blocks are something like:
<house code><???>
<house code><unit code>
<house code><???><status>
<house code><unit code><status>
<house code><???><status>
|
| Back to Top |
|
| |
TonyNo
Moderator Group
Joined: December 05 2001
Location: United States
Online Status: Offline
Posts: 2889
|
| Posted: February 14 2008 at 17:19 | IP Logged
|
|
|
Dave?
|
| Back to Top |
|
| |
dhoward
Admin Group
Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
|
| Posted: February 19 2008 at 10:09 | IP Logged
|
|
|
Here goes...
Ive looked through the code and I see only two ways that X10 RF would be broadcast. The first way would be through the DEVICECHG UDP broadcast. This should be identical to every other device since every device at this level is essentially the same. However, a device *must* be defined in order for the DEVICECHG broadcast to be sent. So if you have an X10 RF come in on C3 on, if you don't have an X10 device defined for C3, then you won't get a DEVICECHG trigger. If it is defined, it should be no different than a regular X10 device.
The second way to catch incoming X10 RF would be via a TRIGGERS UDP broadcast. The TRIGGERS broadcast exactly matches the internal processing for PowerHome and each type of trigger has it's own set of values and types. A single Insteon command will fire multiple trigger checks...with each trigger check generating a UDP broadcast whether or not an actual trigger for that particular type exists. X10 triggers will fire a completely different set of values than Insteon (but it shouldnt be too different for RF and PL versions of X10 triggers). He probably only needs to listen for one particular type of X10 RF trigger in order to know what has happened. I'll try to detail this below.
The first part of a trigger is the trigger type. For incoming X10 RF, this type value is 8. The second part of the X10 RF in trigger is the housecode. Before we get into the other values, it's best to go over what are the triggers that are actually fired when X10 RF is received.
X10 RF always consists of a housecode, possibly a unit code, and a function. Certain commands such as All Lights On, do not require a unit code. Unlike PL X10, RF X10 always has a function sent. With PL X10, you send first a house/unit followed by a house/function. The PowerHome triggers are setup to work with this behaviour. Even though RF X10 doesnt separate the address from the function, the X10 RF In triggers still mimic the PL X10 triggers.
Ok, with that out of the way, when incoming X10 RF comes in, the trigger checks (and hence the TRIGGER UDP broadcasts) that will be fired depend somewhat on the actual incoming RF command. If the incoming RF is an On or Off command, you will first get a incoming X10 RF In trigger (trigger type 8) with the housecode, a unit of 0 which is the (Any) Before Buffer, followed by 100 which is "Addressed". So the first trigger check is X10 RF In, Housecode, (Any) Before Buffer, Addressed. The actual unit value will be in one of the TEMP variables which will be a data parameter in the UDP broadcast. The next trigger check will be X10 RF In, Housecode, Unit, Addressed (100). The extra parameters (TEMP variables) will be either 0 or blank.
The other incoming RF commands don't have a unit value (Bright, Dim, All Lights On, All Units Off). In the case of these types of RF X10 incoming, the first two trigger checks detailed above are not fired. The next trigger check detailed below is fired for ALL RF commands.
The next RF trigger is RF In (8), Housecode, 0, function (2 = on, 3 = off, etc).
In the case of dim and bright commands, even though an actual unit code is not part of the command, the RF commands mimic their PL counterparts so PowerHome tracks the last device addressed within the housecode in question and uses that as the unit code. The last two trigger checks detailed below, will fire for any command with a unit > 0. This should be on,off,dim,bright but not All units off or All Lights on.
RF In (8), Housecode, unit,function
RF In (8), Housecode,(Any) After Buffer (100),function. The "unit" will be passed as a parameter.
So, you can see it's actually pretty complicated. There are 5 total trigger checks possible for a single incoming X10 RF command (which also means 5 UDP broadcasts). To catch incoming on and off commands (the most common), I would probably only monitor for the last trigger check. The one with a "100" as the third parameter (Any, After Buffer). This single broadcast will contain the housecode, unitcode, and the function. This will also catch the dim and bright commands. To catch the All Lights On, and All Units Off commands, you'll want to monitor the 3rd trigger check (the only one that fires for these commands). This trigger will have a 0 in the third parameter and either a 0 (All units off) or a 1 (All lights on) in the 4th parameter. The other broadcasts or triggers will have either redundant or partial information and are not necessary.
Hope this helps some.
Dave.
|
| Back to Top |
|
| |
Active Topics 
Memberlist 
Search 
Help
Register 
Login
PowerHome Messageboard : PowerHome Programming
Topic: UDP Broadcast Server Documentation
