I noticed that my TCP/IP capture/analysis program was crashing every 120 minutes. It turns out that there is a short form version of the SDP that has a payload size of 30 bytes that gets sent every 2 hours - on the dot. The short packet was causing my conversion routines to throw an exception on the missing data. I assumed the "01:01" packet always had the same length binary payload. I was wrong...
The data in the short-SDP has some invariant fields, but most of it changes in subsequent transmissions from the GW to the LCX server. Interesting... Could this be the only Sensor Data packet that gets sent if you are on the Basic Service plan?
This packet needs to be analyzed by someone and have the fields identified for later parsing. Later, I will add parsing rules to my app for this packet.
The HTML header for this short packet has the same packet type identifier as the SDP:
HTTP_IDENTIFY: 8009A417:01:1ACD276DFAC43232:01\r\n
But instead of a Content-Length of 197, it has a length of 30.
I also found out that the 64-bit hex number found above changes during the registration process, so it is some sort of server-issued key Probably used to verify that you have completed the registration process - or to tie your sensor data to your user account.
The GW does some crazy things with DHCP during the registration process too. It requests new IP addresses from your DHCP server, hopping from from IP to IP 3 times (for no apparent reason). It should be happy with the first one. Maybe a firmware bug?
There were several new HTTP_IDENTIFY packet ID codes that are only used during registration. I'll smoosh the the leading/trailing hex together, since everyone's 64-bit ID number (stuffed between the two numbers) will be different:
0010 - some sort of registration preamble
0020 - actual registration request
0030 - registration complete/finalize?
7F10 - 13 bytes sent - mysterious stuff
0114 - 14 bytes sent - more mysterious stuff
0001 - 210 bytes sent - even more mysteries