Ok, I implemented that. I just parrot back the account ID from the HTML header after replacing the 2 leading bytes with 7FFF.
I tried that but it didn't work for me. The value that did work was contained in the 38-byte 14:01 clock-set packets from weatherdirect. It was also contained in a single 14:00 packet that came from weatherdirect before any of the 14:01 packets. Mycal thinks this is what actually sets that ID in the console/gateway. That makes some sense because after the 14:00 packet, the GW immediately responded with a 01:14 packet (confirmation?) containing that same ID. Then the server answered with a 1C:00 packet. Mycal thinks the 1C:00 packet is to "seal the deal" on registration.
Other than the above packets, I don't see the ID that worked anywhere else in my captures. This may be a problem if you (or your users) don't have any captures from which to grab that ID. What may work is to somehow reset the ID in the console, then either go through the registration process again with weatherdirect while capturing packets. You could make Skyspy into a full proxy, then go through the registration process again and grab the ID as it goes by. Or you could reset your console and see if you can force an ID code into the console from Skyspy. Maybe the "factory reset" described in the manual would reset the console's ID.
Did that.... Its not working though.
Here is my current RTC response packet structure:
Here's mine:
|00|01|02|03|04|05|06|07|08|09|0a|0b|0c|0d|0e|0f|10|11|12|13|14|15|16|17|18|19|1a|1b|1c|1d|1e|1f
00 - |01|7f|ff|14|76|3c|3b|5b|61|00|32|00|0b|00|00|00|0f|00|00|00|03|00|3e|de|09|47|11|28|04|14|53|07
20 - |04|00|00|00|05|ad
Are you doing anything with the epoch bytes? Epoch increments slowly over several weeks/months until it wraps at 7FFF
I haven't yet but I just had a look at what they were in the captures when connected to weatherdirect. I do see them incrementing by 0x12 (hex, not decimal), sometimes every 2 hours, but not at other times. And in the first 15 minutes after registration, these two bytes jumped a lot. Always increasing, but by large values, and always a multiple of 0x12. Once it increased by 0x2520 in 3 minutes time. The capture spans the change to DST, so that may add oddities. I think time zone and DST info are probably embedded in there somewhere.
Right after registration the GW sent out 01:00 (time request) packets every couple minutes (8 over 15 minutes), and the server responded with 14:01 packets. I think this makes sense. Unless they implement something like NTP that can deal with latency, and packet loss and retransmission, they'd have to get a number of clock-set packets to be sure they have the time right. After the first 15 minutes, it settled down to 3/hour or so.
That 15-minutes coincided with the storm of 210-byte 01:01 packets every 2 seconds.
If the packet storm only happens on initial Internet connection or after a registration, then it is probably no big deal. That said, I had to replace my outside temp/humidity sensor batteries today, after only 4 months of use.
Trouble is, the 01:01 packets every 2 seconds hasn't stopped in 4 days. I think something must not be happy with what I'm sending it in the 38-byte clock-set packets, or that it's not getting a proper confirmation somewhere.
Here is a link to my two capture files, which starts when I first plugged the GW into the LAN, and goes through the registration process. There is a gap between the files when I accidentally stopped the capture and restarted it again. The time change to DST occurs during the second capture file, and there's some funny business in the times around there that I haven't figured out yet.
http://www.keckec.com/weather/files/capture_2014-03-08.zipHere is the PHP file as I have it now. Much of it is from mycal. This is a work in progress, and a lot of clean-up is needed. This is my first time doing any PHP code, so go easy.
http://www.keckec.com/weather/request.breq