---The part that is making me return this device and look elsewhere for this
5)The octet stream is not in any way human readable, so I tried other possible encodings.
It is not UTF-8
It is not ASCII
It is not JSON compatible
It is not MIME
I've got the new GW that came with the new system and will register that before I go back to MO. It wouldnt register but it does communicate with the server so perhaps if I register it here it'll work with the system back in MO. Ive got part of the registration captured with wireshark from back in MO if you think thatll help.
0x46 for Inside Humidity
0x53 for Outside Humidity
0xA7 Barometric Pressure MSD
0xA8 Barometric Pressure Center Digits
0xA9 Barometric Pressure LSD (only the upper nibble is used)
0xAA Barometric Pressure Delta since last reading MSD
0xAB Barometric Pressure Delta since last reading LSD
0 = N
1 = NNE
2 = NE
3 = ENE
4 = E
5 = ESE
6 = SE
7 = SSE
8 = S
9 = SSW
A = SW
B = WSW
C = W
D = WNW
E = NW
F = NNW
I am already working on the next generation of this app. It will probably use a database to store raw data, HTML headers and sensor readings.
That said, do you really need to have that granularity of sensor information? The SDP actually contains averages, as well as the current readings. I am not sure which ones get displayed on the La Crosse server.
Can I suggest that it have the ability to choose where the output goes? My preference would be to simply append the data in CSV format to a user-specified file. This would allow the user to post-process as desired.
Can I suggest that it have the ability to choose where the output goes? My preference would be to simply append the data in CSV format to a user-specified file. This would allow the user to post-process as desired.
Serial console?
Serial console?
Yes so far no joy.
Serial console?
Yes so far no joy.
I would be surprised if you could get anything out of it via serial comm. All the GW smarts are devoted to TCP/IP. You probably found a firmware programming port or maybe a production-test I/O port.
Mycal,
That is some very strategic potting compound over the GW processor and RF circuitry. :grin: I wonder whats underneath?
Do you think the connector you hooked up to is actually a JTAG header? If so, you need some different hardware to snoop it. Also, you could brick the GW in a heartbeat. Be careful.
I saw a hack for a different model home-weather station where the guy tapped into the data stream coming out of the receiver for all the wireless sensors. The wireless data signal was simple ~915 MHz, PCM modulation.
Since all of the sensor data is routed through the GW, you might be able to do a complete end-run around the whole TCP/IP web server thing. You would need some sort of hardware UART or do some clever software to turn the PCM bits into bytes and then parse all of that back into sensor readings. I don't know what would be harder - hacking the hardware or snooping the TCP/IP #-o
If you haven't registered already, how about capturing the GW TCP/IP conversation during registration. Wireshark is a good tool, if you are not already using it. I have only one sample right now, and it would be interesting to compare more.
I sent you a PM.
1) One is build the interface into your software to be a proxy, this way we can tell the gateway that your software is the proxy, you add the socks proxy bits, but you get all the packets from the gateway, and forward them on.
2) Might be simple, just act as a router and point the weather gateway config to your software. So instead of your router, the packets get sent to your software, then you just forward them on to your gateway. (you'd have to handle reply packets too.)
Your software should be able to automatically configure the gateway for this using the UDP config protocol.
Quote2) Might be simple, just act as a router and point the weather gateway config to your software. So instead of your router, the packets get sent to your software, then you just forward them on to your gateway. (you'd have to handle reply packets too.)
Won't work, because the GW wants to carry on a specific conversational "dance" with the LCX Cloud server. I'd have to simulate the server in order to fool the GW into submitting data. My guess is the GW/Server designers already thought of that and made it a bit complicated to protect revenue. Remember that they do charge you money for accessing that server.... Not that it could not be done.
Ok, I guess I misunderstood. I am working on a couple major software development projects right now (not related to SkySpy) and mental multitasking isn't working for me this morning :-)
Can you tweak the outbound MAC address without messing with the NIC settings?
Yes I have a 10/100 hub
With the replacement cloud server will we still need the hub?
If I've understood correctly the GW will be told to use a proxy (not sure how that is done) and the "proxy" will be the replacement cloud server.
With the replacement cloud server will we still need the hub?
Nope. Just use the GAS utility to set the "proxy" IP address to a PC on your LAN that is running the replacement "cloud server" (I hate that name BTW :-) )Quote
Have you considered using the GAS utility and just set the Gatway to your software device? In this case you will get all the packets bound for the service but on the link level they would be sent to you. You could then just sniff the packets, replace the destination MAC address to your real gateway (your router) and send it on. This way you see everything, and you don;t have to emulate a proxy. The replies would bypass your device and go straight to the gateway. All you need is the raw send function of winpcap to send the packets.
I will be back in my lab tomorrow, so I can look at this.
It may be possible to use the clone as a personal web server, as well as a data bridge for the Gateway. I think it could display real-time weather sensor readings on a mini-web site, store your weather data to a database, possibly send warning emails, and post updates to Wunderground.This is an cool set of features! I hope that you make it selectable which ones a user enables. For example I don't want to set up a mini-web site since I'd be happy getting the data from the Wunderground. And I try to minimize the number of ports I open on my PC.
This is an cool set of features! I hope that you make it selectable which ones a user enables. For example I don't want to set up a mini-web site since I'd be happy getting the data from the Wunderground. And I try to minimize the number of ports I open on my PC.
Trellend,
The C84612 weather station ships with an included Internet Gateway containing a built-in RF interface. There is no need to listen in on the sensor RF signals.
My latest software works with the hardware that ships with the weather station - you don't need to buy anything else.
Might be a nice alternate route as I don't have a dumb hub,
my router won't fake DNS,
and port 80 is occupied on my machine.
Perhaps when you make the kind that skips LaCross all together, you could do it on a USB NIC direct to gateway. Something like that.
Alright, I'll pick up another NIC next trip to civilization, I'll be ready to test in a 2-3 weeks.
I got the SkySpy Server talking to Wunderground tonight! \:D/ I can't fully test it, since I don't have an account with them yet, but the Wunderground server does complain that I have an invalid station ID or password - I have both :lol:
The next release will allow you to enter your station ID and password. SkySpy Server will then update Wunderground at the interval you specify - around 2 minutes minimum, even if you have a rapid fire account. That is the fastest this weather station can go :-)
Those of you on the SkySpy Server beta program should update when I make the new release - probably tomorrow night, west coast time.
https://www.dropbox.com/s/35f3wbf57pam7ri/wundergroundsetup.png (https://www.dropbox.com/s/35f3wbf57pam7ri/wundergroundsetup.png)
I opened a new Wunderground account this morning. I then configured SkySpy Server to send data to the Wunderground PWS server.
Success!
Wunderground accepted my actual sensor readings!
https://www.dropbox.com/s/ol5gvsssr20hay6/WundergroundSuccess.png (https://www.dropbox.com/s/ol5gvsssr20hay6/WundergroundSuccess.png)
I have one minor tweak to do to the formatting of the sensor readings, but things are looking very good for a new release tonight. =D>
Woohoo! Simple, effective and I'm up and running already, first update showed in wunderground moments after the install finished. So much better than the lacrosse solution.
All your hard work is greatly appreciated and yes you do make us happy. I have been running ssCapture and ssMonitor for over two weeks and find it very useful. =D> I am looking to the release of your ssServer software and can't wait to try it.Woohoo! Simple, effective and I'm up and running already, first update showed in wunderground moments after the install finished. So much better than the lacrosse solution.
Thanks for the kind words. I've been working on this for quite a while - since just before Christmas in almost every free moment until now. I hope it makes people happy.
Ever think about allowing read only access to your remote database? Then we can pull some reports too.
All your hard work is greatly appreciated and yes you do make us happy. I have been running ssCapture and ssMonitor for over two weeks and find it very useful. =D> I am looking to the release of your ssServer software and can't wait to try it.
As far as preferences are concerned, I run my own servers and would really like the ability to keep the database local.
This also increases the flexibility for future use.
Including the mini website and the ability to also upload to WU is fantastic.
So I'd vote no change to these existing features that you've currently included.
Running the server as a service with an associated configuration app is a great idea!
I'm glad you like it! I am holding off on doing a wide release of the server until I can settle on a feature set.
I need to get a consensus:
1) I am considering removing the database completely and have ssServer submit it's samples to Weather Underground (WU) exclusively. I might remove the mini-website feature too. Your thoughts?
You would have to download a CSV file from WU if you wanted to run special reports.
2) I want to turn ssServer into a Windows Service that runs invisibly in the background on your computer. I will probably add a companion program used to configure ssServer and maybe display the last sensor readings. The companion program can be run continuously or only as needed. The service would run just fine without it.
A service would survive being rebooted when Microsoft automatically updates Windows in the wee hours of the morning - you would not lose more than a couple minutes of sensor data on WU, even if you got logged out of your windows session. It would also continue running if you log out, or someone else logs in to your computer.
I think the transition from desktop app to Windows Service is important, so that is tops on my list. I really want to wrap this thing up quickly, so that is my motivation for paring down the feature list to the minimum everyone wants and can actually use.
Feedback is appreciated!
I hope it makes people happy.
As far as preferences are concerned, I run my own servers and would really like the ability to keep the database local.
This also increases the flexibility for future use.
Including the mini website and the ability to also upload to WU is fantastic.
So I'd vote no change to these existing features that you've currently included.
Running the server as a service with an associated configuration app is a great idea!
Ok. Lets get some more votes :-)
I don't want to host the DB forever - too much responsibility :-|
The current product is MySQL-based. For speed and efficiency, SkySpy uses a native MySQL TCP/IP interface (no DLLs or ODBC).
I am not too motivated to change DB engines, since that is the database I program with at my day job and other consulting work. I know it inside out and backwards and am not too keen on learning a new one. The good news is that the community version of MySQL is open-source/free.
The trouble with a local/remote DB is you have to log in to use it. I suppose I could save login credentials in the registry, but that is not too secure. You would need some sort of automatic login, in a service environment.
You can use your own DB right now - just change the host name / port # using the Advanced button on the Login form. Note that you would have to create and populate a bunch of DB tables before use. I have not published the DB schemas and tables, but I could if there is any interest in private / local MySQL servers.
Retaining the ability to upload to WU would accommodate those that don't want to maintain a local instance would be the best of both worlds.
So I'd vote no change to these existing features that you've currently included.
Running the server as a service with an associated configuration app is a great idea!
I'm with 10ACTony in preferring to host the DB locally on my own server, as well as hosting a web page to display the output dynamically.
Retaining the ability to upload to WU would accommodate those that don't want to maintain a local instance would be the best of both worlds.
Can the skyServer mySQL credentials be kept in an .ini or .conf to be passed at startup? It's no more secure than the registry, but it might be less
work. In this mode, you could do what you like with the data.
I started working on the SkySpy Server-Service (that is a mouthful!) tonight.
The plan (although things may change):
1) The service runs in the background and does all the non-visual stuff that ssServer does now - GW comm, WU Update, Mini-web site, DB update.
2) A Small app will configure the service/show the latest sensor readings in real-time if you leave it running on your desktop. This is optional - except for initial setup. Might be good to let you know if your sensors are working OK and if communications are happening in a timely manner.
3) The database will work in one of two modes:
3a) The service will be able to use stand-alone database tables (no MySQL database install required). This mode does not allow external programs to read the database tables: Data is for the exclusive use of the service.
3b) The service will be able to use a local or remote MySQL database engine (but not mine). Login credentials will be stored in the registry. You can do what you like with the data in the tables.
4) All configuration information will be stored in the registry. Update it with the small setup app.
5) Absolutely No Promises, but I am looking at a Cumulus interface. If it turns out to be a pain, this will be the first thing to get tossed overboard.
I started working on the SkySpy Server-Service (that is a mouthful!) tonight.
The plan (although things may change):
1) The service runs in the background and does all the non-visual stuff that ssServer does now - GW comm, WU Update, Mini-web site, DB update.
I started working on the SkySpy Server-Service (that is a mouthful!) tonight.
The plan (although things may change):
1) The service runs in the background and does all the non-visual stuff that ssServer does now - GW comm, WU Update, Mini-web site, DB update.
2) A Small app will configure the service/show the latest sensor readings in real-time if you leave it running on your desktop. This is optional - except for initial setup. Might be good to let you know if your sensors are working OK and if communications are happening in a timely manner.
3) The database will work in one of two modes:
3a) The service will be able to use stand-alone database tables (no MySQL database install required). This mode does not allow external programs to read the database tables: Data is for the exclusive use of the service.
3b) The service will be able to use a local or remote MySQL database engine (but not mine). Login credentials will be stored in the registry. You can do what you like with the data in the tables.
4) All configuration information will be stored in the registry. Update it with the small setup app.
5) Absolutely No Promises, but I am looking at a Cumulus interface. If it turns out to be a pain, this will be the first thing to get tossed overboard.
I started working on the SkySpy Server-Service (that is a mouthful!) tonight.
The plan (although things may change):
1) The service runs in the background and does all the non-visual stuff that ssServer does now - GW comm, WU Update, Mini-web site, DB update.
I just discovered this thread. Your program looks great, and I appreciate all the hard work that you've put into it. I have a new LCX station and was getting ready to connect it to their server, but really would like to keep the data local so I can access it whenever I want.
I would use your program, but I only use Linux. I would like to write a server like you've done, but using python in linux and have it write data to a local MySQL server. Then write some PHP scripts to view data and graphs with a web browser. I've done this sort of thing before in python and in C. Is it possible to get the source for your program, or perhaps the part that communicates with the gateway device and keeps it happily sending data.
I'm happy to help this project however I can, and of course make available any code I write.
Thanks a lot for your help.
FYI, I've written parts of the server in PHP already, that allows you to register a gateway and a weather station to the php server.
Currently it doesn't do anything with the data, but it handles the packets and responds keeping the gateway and weather station happy.
I have a few more things to document, but I post the source code in a day or two. Probably save you a lot of time for you to run on your
linux box.
Skydvrz has the .php server code, but I don't know what he thinks of it.
If someone uses the local DB, will the monitor program still work if it's directed to the local DB?
Is it possible to get the source for your program, or perhaps the part that communicates with the gateway device and keeps it happily sending data.
If you have more than one LCX station/gateways (1 remote - 1 local)...
would it be possible to create/run separate instances of the SSS-S, on the same physical server - each SSS-S instance
having a unique (configurable) service name and associated registry configuration entry?
If unique service names & configs are a problem, we could always run two servers, (maybe 1 physical, 1 VM) each with their own SSS-S installations.
Skydvrz has the .php server code, but I don't know what he thinks of it.
I'd like to see more development on this, and I "speak" several computer languages. I would love to see more research done on the unknown SDP fields, and the meanings of some of the other packet that are currently ignored. Please pass along anything you learn and I'll update ssServer - with attribution if you like.
I did this in Delphi (Object Pascal) because I use it daily for other projects. So, if you can read Delphi then here is the source for you or anyone else that is interested. Note that a lot of 3rd Party component libraries are not included, so you probably can't compile it even if own Embarcadero Delphi XE or higher. They are up to XE5 right now.
ssMainForm.pas handles the TCP/IP, HTML, database login, and the packet handshake logic side of things;
ssDataModule.pas handles SDP packet parsing, writing to the database, mini-web page HTML generation, raw sensor data to American units conversion, spoofed GW packet creation, Wunderground PWS updates, and other housekeeping methods.
This is just the server code - the SkySpy Monitor program is composed of some really expensive components that I cannot publish, so there wouldn't be much point in releasing the remaining 10% of non-copyright code for that. If you want to see SQL queries to read the data back and graph it, then write me privately. Most of the SQL queries will be self-evident when I get around to publishing the MySQL schemas. That won't come until I ween everyone off my personal MySQL server. :grin:
Also... This is a work in progress: The server software is in the process of having a massive rewrite and I won't be updating the version found in the RAR.
I see in the readme the GW must be registered with Lacrosse. I assume there may be hashes exchanged to authenticate, maybe in both directions. Is the registration still necessary or does your code handle that now? And do you know if the GW requires the registration to be renewed after some period of time?
Does the GW only use HTTP to send data, or does it open other TCP/UDP connections to the server as well?
ssServerSim - 1.1.0.14 (Released 2014-03-06) [ View Issues ]
============================================
- 0000123: [Bug] Web update fails to restart ssServer properly - resolved.
- 0000121: [Bug] WU update is not sending software version - resolved.
- 0000122: [Bug] WU Update is using 24 hour rainfall window - resolved.
- 0000119: [General] Not receiving or sending data - resolved.
- 0000117: [Bug] Setup form needs to deactivate server while it is visible - resolved.
I can see why they would do it that way, to make sure what is displayed on the console is the same as displayed from their "cloud". However, seems very inefficient and results in spectrum pollution from duplicate rf transmissions of the same data.
I got the Service version of SkySpy Server mostly working tonight!
It is busily receiving GW packets, updating Weather Underground and serving up the "mini web site" when requested.
I made a lot of progress on SkySpy today. I have the new ssServer nicely integrated with ssMonitor. I have updated both ssServer and ssMonitor to work in both full-blown MySQL database mode as well as "embedded" mode that does not require installation of the MySQL database server. There are some minor bugs that need fixing, but I am on target for a major release sometime in the next few days.
Added, but not finished is an alert system that compares sensor readings with user-settable min/max/range values. If a sensor reading is outside the range, then ssServer will send you an email. I have the min/max/range setting code done in ssMonitor and will implement the messaging system in a later release.
https://www.dropbox.com/s/xqj0w58rshou6y3/alerts.jpg (https://www.dropbox.com/s/xqj0w58rshou6y3/alerts.jpg)
You are REALLY going to put those moron software developers from Lacrosse to shame. I can't wait to try it out. Thanks Skydvrz!
You are REALLY going to put those moron software developers from Lacrosse to shame. I can't wait to try it out. Thanks Skydvrz!
Yeah, that web site of theirs is a train wreck. Be glad, because it was an inspiration for SkySpy :grin:
Ok,
I have been locked in mortal combat with the $%&*# installer, trying to get it to do a nice smooth installation of SkySpy on a variety of Windows versions. I am not having much luck. ](*,)
If you are technically savvy and a brave soul, then you can do a manual install. It is tricky, since the new ssServer is now a Windows service. Services do not install like normal applications.
So, would you rather wait until I figure out how to use this install builder and make a nice neat, professional looking install/deinstall, or would you prefer immediate gratification, a somewhat difficult install, and a really difficult de-install should you decide to back out of it?
I would like to get some beta testers up and running with the new version, but with the above caveats.
Let me know your thoughts...
I'm willing to give it a try I would be installing on XP Home & XP Pro
Some of the installer issues I am struggling with are specifically related to XP, so I am not sure I can support that platform. SkySpy will work OK on XP, but the old installer software I am using is pretty clunky and balks at the differences between XP and Win7.
I did make a little headway last night with the installer and mods to SkySpy to help it straddle Windows versions, so stay tuned.
I recommend you upgrade ASAP to Win7 for lots of reasons. Win8 would not be my first choice in upgrades though - no Mr Gates, I don't want my desktop to look like my cell phone. #-o
XP's life is about to come to an end in about a month. That will leave your system open to any vulnerabilities.
Actually XP's end of life is today. :shock:
Actually XP's end of life is today. :shock:
XP's life is about to come to an end in about a month. That will leave your system open to any vulnerabilities.
Actually XP's end of life is today. :shock:
BTW, most of the free anti-virus programs are not very good - you get what you pay for.
So if I want to start tinkering around should I just wait until your latest beta (from which it appears is almost ready) be released or proceed with downloading your server app from post #76 (page4)? Thanks! Can't Wait! :lol:
Hi there.
Also, I presume since I'm basically changing how/or where it is sending its data that I will no longer be submitting it to my lacrossalerts site. What if I wanted to (even if temporarely) reconfigure it to submit the data to LacrosseAlerts ? Would I use the GAS to do so or do I have to register it per the la crosse docs)
Thanks for any help!
Mark
I've skimmed this thread a few times and verified my ssServer settings over and over but something isn't right. I followed the instructions in the readme file a few times now trying to pinpoint the issue. I configured the ssserver to idk.serveftp.net port 3307 and logged in with my acct from skydvrz.
I ran and configured the GAS as instructed but no data ever shows in the SSserver window fields.
Also, I presume since I'm basically changing how/or where it is sending its data that I will no longer be submitting it to my lacrossalerts site. What if I wanted to (even if temporarely) reconfigure it to submit the data to LacrosseAlerts ? Would I use the GAS to do so or do I have to register it per the la crosse docs)
Also, you guys will be hosting your own mini-databases in the next version - no more free rides :-)
And the upload to Weather Underground is working also! SWEET! This is sooooo cool!
is there a way to configure the time zone?
The ssServer shows Rain Fall .45 (in). The La Crosse PWS Display shows Total Rain Total of .44.
FUNCTION TsssDm.GetRainfallIn(RF : TRainFallArray) : Double;
BEGIN
Result := ((DisplayToDigit(RF[0]) * 10.0) + (DisplayToDigit(RF[1]) / 10.0) + (DisplayToDigit(RF[2]) / 1000.0)) * 0.0393701;
END;
One thing I noticed is that the BCD temperature outputs seem to be in tenths of degrees C. In the equation:
Result := (I * 0.18030) - 40.15
the 0.18030 may actually be a degree C-to-F conversion scaled to 0.1 deg (9/5 * 0.1). Also, 40.15 probably should be 40.0. It appears they avoid negative numbers in the BCD data by adding 40 deg C to temperatures before the gateway sends it out, then subtract it in software downstream. Anyway, I think (I / 10.0 - 40) will get degrees C. Then make the standard conversion to F.
The transaction problem I'd really like to solve is the 5-byte send / RTC response packet. This is the 38 byte 01:01 packet the server is supposed to send in response to the Gateway sending an 01:01 5-byte request. The clock on my LCD display is slowly drifting, since it is not getting valid Real Time Clock (RTC) reset responses from SkySpy. SkySpy puts the correct time in the RTC packet, but the LCD display ignores it since there is some sort of handshake problem.
Could this be a checksum problem? Does the gateway use any other data that you send it, which might confirm that it is happy with the checksum?
mycal appends a straight 8-bit sum when he sends packets to the gateway. Using that algorithm doesn't seem to match the checksum in the post data I receive from the gateway. I've also tried an 8-bit exclusive or but that doesn't agree either. I'll experiment with some others.
No Luck. Closed previous running and working ssServer and installed the new SkySpy. Opened the monitor and after 25 minutes the readings still haven't updated. The Last Packet Type has shown everything from Ping Received, to DSP Received, to RTC Packet Received but after 25+ minutes still no updated weather readings. Rebooted and same behavior. Any suggestions?
Windows 7 Home Premium, 64 bit
---
I stopped the SkySpy Server Service and closed the monitor. I launched the ssServer instead this time and within 5 minutes it was filled with data. Hmmmmmmmmmmm.
http://dev.mysql.com/doc/mysql/en/ANSI_mode.html"
Beautiful work! I could use my SQL Server Express local Dbase correct?
I have never used mySql but use MS SQL all the time at work and SQL Express. The script file you provide won't work with these without some modificcation. From my own research I found this
"I think, you can start mysql in ANSI mode and generate the scripts
with this standard which is ready to use in SQL server with no
modification. see the following page for more details:
http://dev.mysql.com/doc/mysql/en/ANSI_mode.html"
I know you are busy so please no hurry, but would you be able to provide this script so it's compatible for us with MS SQL ? Thanks a ton.
Beautiful work! I could use my SQL Server Express local Dbase correct?
I have never used mySql but use MS SQL all the time at work and SQL Express. The script file you provide won't work with these without some modificcation. From my own research I found this
"I think, you can start mysql in ANSI mode and generate the scripts
with this standard which is ready to use in SQL server with no
modification. see the following page for more details:
http://dev.mysql.com/doc/mysql/en/ANSI_mode.html"
I know you are busy so please no hurry, but would you be able to provide this script so it's compatible for us with MS SQL ? Thanks a ton.
No Luck. Closed previous running and working ssServer and installed the new SkySpy. Opened the monitor and after 25 minutes the readings still haven't updated. The Last Packet Type has shown everything from Ping Received, to DSP Received, to RTC Packet Received but after 25+ miWnutes still no updated weather readings. Rebooted and same behavior. Any suggestions?
Windows 7 Home Premium, 64 bit
Hmm. It should start working within 5 minutes or so. What wasn't updating? WU? You do need to run the setup in the new SkySpy monitor and configure your WU Station ID, Etc. Did you do that?
If you are seeing packet updates in the new Monitor then things are working perfectly.
I could use my SQL Server Express local Dbase correct?
No Luck. Closed previous running and working ssServer and installed the new SkySpy. Opened the monitor and after 25 minutes the readings still haven't updated. The Last Packet Type has shown everything from Ping Received, to DSP Received, to RTC Packet Received but after 25+ minutes still no updated weather readings. Rebooted and same behavior. Any suggestions?
Windows 7 Home Premium, 64 bit
No data at all either on the current data page or anything in the remote database. The last update for WU and Sensor never changes and is back in March on mine so it's not even the last data from the the old server program. But the data that was equivalent to the old debug data (showing different packets and times) did change. Running on old server now. Willing to try anything and get you whatever data you need, real time if necessary. I did do the setup in the service.
Boy am I the unlucky one :-)
I uninstalled and rebooted and then re-installed. Same symptom. Unfortunately for me the only fields that update under the Service Readings tab are the Last Packet Type and Last Packet Time. They cycle through the Ping Received, SDP Received, and RTD Packer retrieved items. The Last WX Data and Last WU Update Date fields have a static value from 3/26/2014. Not sure where it gets this from as I only just installed my PWS last week and configured it for SServer shortly there after. Even though the readings never update (besides the packet type and type fields as mentioned above) I did proceed to configure WU. Yet, WU never gets any updates. Also of note the Use Embedded MsSQL box is checked and all the other values below it are the defaults. Did look over the INI file but nothing looks out of wack to me anyways. I'm stumped.
The Last WX Data and Last WU Update Date fields have a static value from 3/26/2014.
Even though the readings never update (besides the packet type and type fields as mentioned above) I did proceed to configure WU.
Did look over the INI file but nothing looks out of wack to me anyways.
Howdy! thanks. Yep I even renamed that file and stopped / started the service and restarted the sky monitor and it rebuilt this file from scratch.Watch out - SkySpy will fill in all default values for your settings if you delete this file. Default settings WILL NOT WORK. Settings are NOT imported from previous SkySpy versions!
QuoteYet the Last Packet Type and Last Packet Time continue to show it's communicating with the gw to some degree.
Make sure you click the Ok button on the setup screen, not the Cancel or "red X". Settings are only saved if you click OK.
Important Note!
You cannot run both ssServer v1.1 and the new SkySpyService v1.2.0.X at the same time. They will fight over TCP/IP port 8000 and stop working.
Make sure you nuke the old version before trying to install the new version because the installer launches SkySpyService immediately. The service will never be able to grab port 8000 until you kill the old program and restart your PC (or manually restart the service).
Just exiting the old server should kill it right, no need to reboot before installing the new service.
I want to say that is what I did last night, but thinking about it makes me wonder if I didn't stop the server until just after installing the new service. If so, would that be why the ini file still had your defaults in it this morning???
From your PM. No I am not running both versions at the same time.
Rains moving in :-0
Just exiting the old server should kill it right, no need to reboot before installing the new service.
I want to say that is what I did last night, but thinking about it makes me wonder if I didn't stop the server until just after installing the new service. If so, would that be why the ini file still had your defaults in it this morning??? But I did see the last packet (ping RTC and SDP) displayed with the correct time, so the service must have been running, right??
Everything is now working normally again.
=D> =D> =D> =D>
skydvrz must be keeping the configuration for monitor in the registery and the configuration for the service in the ini file.
Clicking OK on the Setup screen doesn't always seem to save the changes if any.
I'm running Windows 7 64 bit home premium.
Yep no odd / non-standard configs.
So it appears just by having mySQL installed it fixed the issue even though I'm currently NOT using the Embedded mySQL option. Whoo hooooooo
I am going to have to duck out of here for a couple days. I have step-daughter and grandkids visiting so I have to go play granddad to a couple little boys. We are having big fun on my hobby farm, playing with ducklings, chicks and bunnies - not much software development going on :-)
Any suggestions if currently running the prior version before installing this version? Do we need to uninstall it first? Can we upgrade on top of the existing? If so, should we stop the windows service? Thanks again for the great work!
Sorry! I forgot to mention that the SkySpy.ini file is now kept in
c:\programdata\SkySpy
I have started working on the "GAS" feature of SkySpy Monitor. It will replace the LaCrosse GAS utility, allowing you to switch between SkySpy and the LaCrosse web site (although I don't know why you would want to do that) 8-)
It will let new SkySpy users to do one-stop-shopping when configuring their weather station for use with SkySpy for the first time.
Were you using skydrvz server initially? If so, when you start the Monitor program did you change the server address there? Click the button on the left (Advanced?). Change that to your MYSQL server address.Yes I was using skydrvz server initially and yes I changed the server address to my server address by clicking the Advanced button. And that is when I get the error report on logging in.
I then closed the monitor and opened it again and changed back to logging into my server and get the error report and when it logs in still no ping data or current data but if I click on the graph tab it sends a error report but then load a graph of my data from when I installed the new skyserver but if I go to the history tab it only shows the error report and then no data.
skydvrz, I hope you're having fun doing this because it sure seems hard :)
I still haven't got this working on my Win 8.1 box. The ss monitor never shows any data except pings, packet requests and so on. The mini web server doesn't show anything. However WU did get two updates earlier this evening. I've tried both the embedded server and mysql.
I noticed that I could only get ping requests if Windows Firewall was completely disabled. That didn't seem right so I took a look at the connection logs. First thing I noticed is that when the firewall was enabled, the listing for skyspy was garbled with chinese characters. Once I wrote a rule for it with the actual name, it started showing activity. Looking back over the past couple of hours, I see outbound traffic originating on a variety of ports but all headed to 127.0.0.1 port 1000. Inbound traffic is headed to port 8000 from the gateway.
Does that 127.0.0.1:1000 seem right to you?
Also when skyspy is running, the C84612 display doesn't show that it's connected to the internet.
A few observations this morning.
Looking at the SkyMonitor it shows version 1.1.0.71
Looking at the Local Web Server it shows version 1.2.0.43. Must not have downgraded after I reinstalled an earlier version last night.
It has been raining most of the night and morning.
SkyMonitor shows 0.00 for both Rainfall 1 hour and RainFall Today. Weather Underground has been receiving correct data it appears, so that is GOOD! Looking at the local web version it is showing the Total Rainfall field being populated and incrementing as the rain fell.
Looking at the tables in mySQL instance it is getting data but looking at the sensorvalues table there are no entries with Sid values between 10-13 which from what I can derive by looking at Sensors table are the rain values (9 - rainfall total, 10 - rainfall 1H, 11 - rainfall 24H, 12 - Rainfall Wk , 13 - rainfrall Mo). Am I seeing this correctly or not understanding your table design. Also loooking at the database 'weather' in MySQL Workbench is there a way to see the relationships between the different tables (primarykey - foreign key like in a design view?)
FUNCTION TsssDm.RainFall(Hours : Integer) : Single;
VAR
Q : TQ;
BEGIN
Q := TQ.Create(Self); // create a query component on the heap
TRY
Q.Add('SELECT max(value) - min(Value) as rf'); // build the query
Q.Add('FROM packets p, sensorvalues sv');
Q.Add('where p.stationid=:stationid and sv.id=p.id and sv.sid=:RFID and DATE_ADD(p.Timestamp, INTERVAL :hours HOUR) >= now()');
Q.SVP('stationid', OprLoginId); // set the SQL query parameters
Q.SVP('rfid', ORD(SRainInTot)); // use the total rainfall sensorvalues records; rfid=9
Q.SVP('hours', IntToStr(Hours)); // number of hours to use
Q.Open; // execute the query
Result := VDQ(Q, 'rf', 0); // get the calculated rainfall for the requested period. Use Zero inches if no matching records
FINALLY
Q.Free; // free up memory
END;
END;
The new script worked like magic. Thanks!
All it took (I think) is the correct checksum in the last 2 bytes of the 38-byte 14:01 packet. I initially had the 8-byte station id wrong. Once that was right, the console beeped once and its clock was synced.
The console/gateway has now gone into another mode, sending 210-byte packets about every 2 seconds, along with the 197-byte SDP once every 4 or so minutes as before. I saw this in my captures when it was talking to the LCX servers. Haven't tried to decode this 210-byte packet yet. I see what look like dates and times that are advancing each packet. It like might be sending historical data, to bring the server up to date?
Station ID? What fields/offsets are you talking about?
I have updated SkySpy Service to use a 16 bit additive checksum. I assume you meant additive and not CRC16.
This may be alarm packets sent by the console. You can configure the console to trigger on various min/max sensor values. I shut all of mine off, since the packets were not very useful (at the time).My alarms are all off as well, so I don't think it's that. In the capture while connected to weatherdirect, it sent these packets for about 15 minutes right after initial registration, then never again.
This is the 8-byte field that starts at byte 1 (counting from 0) in the 38-byte 14:01 packet type that sets the clock. The ID starts with 0x7f 0xff as the first two bytes. From Mycal's instructions it has to match the ID of the gateway/console. I copied my ID from a capture of data coming from the weatherdirect servers. According to Mycal, it's an ID field that gets stored in the console/gateway after being sent from the server during the registration process. Once set, I'm not sure if there is a way to reset or change it.
Yes. It is a 16-bit sum (not crc) of the first 36 bytes in the packet, and is placed big-endian at the end of the packet to make 38 bytes.
TDateArray = ARRAY[0..2] OF Byte; // YMD
TServerTimeOfDay = ARRAY[0..2] OF Byte; // includes seconds
TTimeOfDay = ARRAY[0..1] OF Byte; // HM
// server sends local date/time to GW in this format
TRTCRec = PACKED RECORD
ServerTime: TServerTimeOfDay;
ServerDate: TDateArray;
END;
TResp0100Packet = PACKED RECORD // 38 byte reply from server
UnknownByte: Byte; // $0 either $1 $2
AcctID: UInt64; // $1-$8 some sort of registration ID?
Unknown4: ARRAY[1..7] OF Byte; // $9-$F invariant in all the dumps I have seen
Unknown5: ARRAY[1..6] OF Byte; // $10-$15 invariant
Epoch: word; // $16-$17
ServerDateTime: TRTCRec; // $18-$1D backwards from normal date/time arrangement
Unknown6: Word; // $1E-$1F $5407 on mine, different on other gateways
Unknown7: LongWord; // $20-$23
Checksum: word; // $24-$25
END;
This may be alarm packets sent by the console. You can configure the console to trigger on various min/max sensor values. I shut all of mine off, since the packets were not very useful (at the time).
My alarms are all off as well, so I don't think it's that. In the capture while connected to weatherdirect, it sent these packets for about 15 minutes right after initial registration, then never again.
I'm a little concerned all this RF traffic might decrease battery life of the console, since it's sending data every 2 seconds instead of 4 minutes. I'll look to see if there is something else in the original capture that might convince the console to give it a rest.
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.
Did that.... Its not working though.
Here is my current RTC response packet structure:
|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
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.
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.
Hmmm. Something funny is going on. I implemented your 38 byte packet, letter perfect (using my LCX-assigned StationID) and it does not reset the RTC or light up the Internet indicator on my console. I even checked back in to the La Crosse server to capture some authentic packets and compared SkySpy packets to LCX. They are identical.... There is something else that we are missing.That is odd. I implemented the epoch code, but it didn't seem to make a difference. I verified that the console's time is being set from the 38-byte packets -- if I change the console time with the SET button, it changes back after a few seconds. Then I changed what time is being sent in the 38-byte packet, and the console time followed it.
My guess is the 5 byte packet, the ping response or something else modifies a state machine in the GW.I've looked at that, but I don't see anything significant. Originally, mycal's php code inserted the http 'content-type' header on all outgoing packets. I disabled that when there is no content, to match what I saw from LCX, but it didn't seem to matter.
I have not reviewed your PHP code - I was busy with the 38 byte packet tonight - Maybe there are some clues there. I will try to devote some time to it tomorrow.Thanks for looking at that. I'm going to see if I can find anything significant in the 210-byte packets. Maybe there's clue there.
Aha!
When describing your process you left out the part about offsetting the 38 byte packet checksum by 7. I will try that tonight when I get home.
Finally getting around to connect the gateway for the first time and of course I have misplaced my activation code. LaCrosse support will not give me a new one, instead I should purchase a subscription.The PHP code has a place for the serial number, near the top. The gateway sends a 7F:10 packet (http header), and the php code (if enabled) sends a 14:00 packet, which contains the serial number, date & time, and some other stuff. The gateway sends a 00:14 packet, and the php code returns a 1C:00 packet. There looks like a place in the PHP code to enable this, but it's untested by me. All this is derived from captures of the registration process with LCX, and I don't think any of us have done it ourselves. You can have a look at this in my capture file here:
I plan on registering the gateway and weather station using Mycal and keckec's php file from yesterdays post. Any advice or gotchas I should look out for?
Thoughts about setting a serial number? I am not worried about never using the LaCrosse services.
$csum=checksum16($reply)+0x17;
$reply.=chr($csum>>8).chr($csum&0xff);
$station_serial=pack("H*" , "7fff201404292594");
$register_this_serial=1;
if($register_this_serial)
{
// Do you really want to do this?
$do_reply=1;
}
// Checksum
//$reply=$reply.chr(checksum8($reply));
$csum=checksum16($reply)+0x17;
$reply.=chr($csum>>8).chr($csum&0xff);
Initially on the Gateway the red LED was flashing. I pushed the button after using the Gateway Advanced Setup and after a while the red LED went solid.You might try adding the following code right before the comment that says "All output created here", near line 1128 on mine but our line numbers probably differ at this point. You'll have to adjust the curly braces. This should log any other packets the gateway sends along.
dump.log wrote out 3 entries:
2014-04-29 21:18:47 Packet Type 00:10 Length: 0 bytes
No Data
2014-04-29 21:19:22 Packet Type 00:20 Length: 0 bytes
No Data
2014-04-29 21:19:28 Packet Type 00:30 Length: 0 bytes
No Data
I then held the Rain button on the weather station until it beeped.
REG flashed for a few seconds the there were 2 beeps and INTERNET flashed.
dump.log now has:
2014-04-29 21:19:38 Packet Type 00:70 Length: 0 bytes
No Data
No matter what I do I only get packet types 00:70.
Stuck and looking for ideas?
} else {
// Log any other packets that come along
$postdata = file_get_contents("php://input");
write_dump_log($postdata,$id1.":".$id2);
}
Maybe it isn't happy with the serial number you're using. You could try the serial number I used, 7fff14763c3b5b61. It's quite possible this number is derived from some other part of my initial exchange and won't work for you. Do you have Wireshark or tcpdump (Linux) available? If so you could capture the actual exchange. This is all new territory, and maybe there's something else we don't know about. Also, check the logs from your web server to make sure there isn't some other problem.$do_reply=1;
if($do_reply)
{
// Reply with 14:00 and 38 bytes of data. This data is likely configuation of the WS
header('HTTP_FLAGS: 14:00');
// $reply.=$station_serial;
$reply.=chr(0x7f).chr(0xff);
$reply.=chr(0x20).chr(0x14).chr(0x04).chr(0x29).chr(0x25).chr(0x94);
// Checksum
$reply=$reply.chr(checksum8($reply));
// $csum=checksum16($reply)+0x17;
// $reply.=chr($csum>>8).chr($csum&0xff);
2014-04-29 22:47:50 Packet Type 00:70 Length: 0 bytes
No Data
2014-04-29 22:49:02 Packet Type 7F:10 Length: 13 bytes
|00|01|02|03|04|05|06|07|08|09|0a|0b|0c
00 - |01|02|03|04|05|06|07|08|02|00|22|73|4d
2014-04-29 22:49:03 Packet Type 01:14 Length: 14 bytes
|00|01|02|03|04|05|06|07|08|09|0a|0b|0c|0d
00 - |7f|ff|20|14|04|29|25|94|02|00|22|14|5e|63
2014-04-29 22:49:06 Packet Type 01:01 Length: 197 bytes
|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|64|14|01|01|30|10|10|03|51|30|10|10|01|06|18|00|61|20|06|18|00|01|30|10|10|00|11|30|10|10|00
20 - |16|11|00|61|10|0a|a1|00|01|30|10|10|00|11|30|10|10|00|16|11|00|61|10|0a|aa|a0|13|01|01|00|01|13
40 - |01|01|00|35|36|29|29|13|01|01|00|01|13|01|01|00|01|32|32|aa|00|00|00|00|00|00|00|00|00|00|00|00
60 - |00|00|00|00|00|00|00|00|00|00|13|01|01|00|01|00|00|00|00|00|00|13|01|01|00|32|00|00|00|00|00|00
80 - |00|00|00|00|00|a0|00|00|00|13|01|01|00|00|00|00|00|00|00|00|55|00|bb|bb|13|01|01|00|01|00|00|00
a0 - |00|00|00|15|00|bb|bb|02|99|21|01|32|02|99|11|01|28|02|99|31|01|35|13|01|01|00|01|13|01|01|00|31
c0 - |05|53|07|e9|1f
2014-04-29 22:49:15 Packet Type 01:00 Length: 5 bytes
|00|01|02|03|04
00 - |41|64|15|c0|f9
2014-04-29 22:49:15 Packet Type 14:01 Length: 38 bytes
|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|20|14|04|29|25|94|00|32|00|0b|00|00|00|0f|00|00|00|03|00|3e|de|10|49|15|29|04|14|53|07
20 - |04|00|00|00|05|18
2014-04-29 22:49:17 Packet Type 00:70 Length: 0 bytes
No Data
2014-04-29 22:53:18 Packet Type 00:70 Length: 0 bytes
No Data
2014-04-29 22:53:21 Packet Type 01:01 Length: 197 bytes
|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|64|14|01|01|40|42|91|05|31|30|10|10|01|06|18|00|61|20|06|17|00|01|30|10|10|00|11|30|10|10|00
20 - |16|11|00|61|10|0a|a1|00|01|30|10|10|00|11|30|10|10|00|16|11|00|61|10|0a|aa|a0|13|01|01|00|01|14
40 - |04|29|10|53|36|29|29|13|01|01|00|01|13|01|01|00|01|32|32|aa|00|00|00|00|00|00|00|00|00|00|00|00
60 - |00|00|00|00|00|00|00|00|00|00|13|01|01|00|01|00|00|00|00|00|00|14|04|29|10|52|00|00|00|00|00|00
80 - |00|00|00|00|00|a0|00|00|00|13|01|01|00|00|00|00|00|00|00|00|55|00|bb|bb|13|01|01|00|01|00|00|00
a0 - |00|00|00|15|00|bb|bb|02|99|31|01|35|02|99|11|01|28|02|99|31|01|35|13|01|01|00|01|14|04|29|10|53
c0 - |04|53|07|a4|bc
2014-04-29 22:57:19 Packet Type 00:70 Length: 0 bytes
No Data
2014-04-29 22:57:35 Packet Type 01:01 Length: 197 bytes
|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|64|14|01|01|40|42|91|05|41|30|10|10|01|06|18|00|61|20|06|17|00|01|30|10|10|00|11|30|10|10|00
20 - |16|11|00|61|10|0a|a1|00|01|30|10|10|00|11|30|10|10|00|16|11|00|61|10|0a|aa|a0|13|01|01|00|01|14
40 - |04|29|10|57|36|29|29|13|01|01|00|01|13|01|01|00|01|32|32|aa|00|00|00|00|00|00|00|00|00|00|00|00
60 - |00|00|00|00|00|00|00|00|00|00|13|01|01|00|01|00|00|00|00|00|00|14|04|29|10|56|00|00|00|00|00|00
80 - |00|00|00|00|00|a0|00|00|00|13|01|01|00|00|00|00|00|00|00|00|55|00|bb|bb|13|01|01|00|01|00|00|00
a0 - |00|00|00|15|00|bb|bb|02|99|31|01|35|02|99|11|01|28|02|99|31|01|35|13|01|01|00|01|14|04|29|10|57
c0 - |04|53|07|f1|8f
Finally got it to work:Outstanding work!!! =D>
After this it still didn't work so I left the above and set the serial manually here:Where did you get the serial number? Did you just make it up?Code: [Select]// $reply.=$station_serial;
$reply.=chr(0x7f).chr(0xff);
$reply.=chr(0x20).chr(0x14).chr(0x04).chr(0x29).chr(0x25).chr(0x94);
Looks like it registered and INTERNET is showing on the WS. It also correctly set my date and time which I manually messed up first.Congratulations. Looks like you're set.
Where did you get the serial number? Did you just make it up?I made it up - 7fff201404292594
I'm curious if your gateway is sending out 210-byte 01:01 packets.Yes it is, in less than 10 hours the postdata210.bin file has grown to 2.2 MB
That's great news. I was hoping we could choose anything. The numbers we've seen from LCX all start with 7FFF, so that may be important.QuoteWhere did you get the serial number? Did you just make it up?I made it up - 7fff201404292594
7fff - Someone said they all started with this
20140429 - Yesterdays date
2594 - My address :-)
You can disable saving that data if you want. It probably won't do you any good unless you want to analyze it. What it writes is the system date as a 4-byte integer, followed by the 210-byte payload from the packet. Each time your GW sends one of these it adds another 214 bytes to the file. You can turn this off by commenting out the following line near the bottom of the file:QuoteI'm curious if your gateway is sending out 210-byte 01:01 packets.Yes it is, in less than 10 hours the postdata210.bin file has grown to 2.2 MB
file_put_contents($filename,$packtime.$postdata,FILE_APPEND);
That line saves all the packets we haven't really figured out yet.Connection: close
Content-Type: application/octet-stream
Content-Length: 38
Cache-Control: private
Date: Thu, 01 May 2014 00:45:15 GMT
X-Powered-By: ASP.NET
X-Aspnet-Version: 2.0.50727
HTTP_FLAGS: 14:01
Server: Microsoft-IIS/8.0
Cache-Control: private
Content-Length: 38
Contenty-Type: application/octet-stream
Server: Microsoft-IIS/8.0
X-Aspnet-Version: 2.0.50727
HTTP_FLAGS: 14:01
X-Powered-By: ASP.NET
Date: Thu, 01 May 2014 00:45:15 GMT
Connection: close
For the record, SkySpy sends this in each header (I may have not capitalized the text correctly - I was working from hand-written notes):Here are the headers, in order, that my php code is sending out:Code: [Select]Connection: close
Content-Type: application/octet-stream
Content-Length: 38
Cache-Control: private
Date: Thu, 01 May 2014 00:45:15 GMT
X-Powered-By: ASP.NET
X-Aspnet-Version: 2.0.50727
HTTP_FLAGS: 14:01
Server: Microsoft-IIS/8.0
What IIS Sends:Code: [Select]Cache-Control: private
Can somebody check if an out-of-order header causes the GW to ignore the 38 byte packet?
Content-Length: 38
Contenty-Type: application/octet-stream
Server: Microsoft-IIS/8.0
X-Aspnet-Version: 2.0.50727
HTTP_FLAGS: 14:01
X-Powered-By: ASP.NET
Date: Thu, 01 May 2014 00:45:15 GMT
Connection: close
Date: Thu, 01 May 2014 14:05:12 GMT
Server: Apache/2.2.22.(Ubuntu)
X-Powered-By: ASP.NET
HTTP_FLAGS: 14:01
X-ApsNet-Version: 2.0.50727
Cache-Control: private
Content-Length: 38
Connection: close
Content-Type: application/octet-stream..
This is setting the clock, but obviously something is wrong since it keeps sending the 210-byte packets out. I tried changing the php code to make the headers just like IIS, but failed miserably. From what I read, PHP doesn't have full control of headers either. Apache puts in its own before sending the packet out, and it removes any conflicting ones from PHP.This is setting the clock, but obviously something is wrong since it keeps sending the 210-byte packets out.
SeedDate := EncodeDate(2014, 5, 3) + EncodeTime(15, 10, 00, 0);
StartingEpoch := $7da8; // my epoch value on 3 May 2014 at 15:10:00 local time
ElapsedTime := (Now() - SeedDate); // calc integer days plus fraction of 24 hours
ElapsedEpochs := TRUNC(ElapsedTime / (2.0 / 24.0)); // Epoch updates every 2 hours
RawEpoch := ElapsedEpochs * $12; // Epoch increases by 0x12 each period
RawEpoch := RawEpoch + StartingEpoch; // calc new Epoch
RawEpoch := RawEpoch MOD $7FFF; // Epoch rolls over at $7FFF so use modulus
R.Epoch := SwapWordBytes(RawEpoch); // Make it big-endian and write it to offset 0x16..0x17 in the RTC payload
Ok, I figured out what the problem was with my 38 byte packet generator. The HTML/TCP/IP library I am using was encoding the bytes as UTF-8 instead of raw binary. This tweaked exactly one byte - right in the middle of my serial number. Not only did this invalidate my serial number, but it also affected the checksum since the byte was tweaked after it was calculated. I only caught it by running Wireshark and snooping my own packets.Contratulations!!!! And welcome to the club :-|
I started using streams instead of a string for a buffer for the 38 byte payload and things started to work - this bypasses the encoder. I got a beep, the display contrast changed, the clock reset, and the Internet indicator turned on. Yaaay! =D>
Unfortunately, this triggered a storm of 210 byte packets. Boooo! #-o
The current version of SkySpy uses a bad SN (and my personal Epoch number), so you don't get jabbering.I found that giving it an incorrect checksum would do the same thing.
Should that be RawEpoch MOD $8000Code: [Select]RawEpoch := RawEpoch MOD $7FFF; // Epoch rolls over at $7FFF so use modulus
I know you PHP guys have figured out a way to simulate a registration. Does this initialize the Epoch to zero, or does it retain the original value?I haven't actually done this. I think to do this the GW must be reset and maybe the console too.
If it set the Epoch to zero, then we are in Fat City - because everyone can use the same StartingEpoch. If not, then something else will have to be done. I would like to remove all dependency on the LCX cloud server.I'm not sure about the 2-hour period for incrementing the epoch. Looking at the 38-byte packets in my capture from LCX cloud, it seems to match for a time, then something changes and the next group of packets match a slightly different StartingEpoch. It seems like the time might be something slightly different than 2 hours. I only have about 60 captured 38-byte packets from LCX, so it's hard to tell.
I have begun working on a web based presentation layer. I won't be able to spend much time on it this week so I thought I would give you a sneak peak, and perhaps some of you could improve on it. :grin:
I tried MyCal's method in SkySpy and noticed the same thing. This needs more research.
He also says he could adjust his LCD clock, but I have not been able to duplicate that result. I'd like to see some code that uses dynamic values instead of hard-coded constants like MyCal's example.
Shoot me some PHP code if you make any progress. I speak PHP.
Hi MyCal, great to see you back.
Has anyone looked at the 18-byte 70:00 packets sent from LCX in response to the 00:70 packets from the GW? I see several kinds of data in them, which looks like possibly a bit mask. Maybe a way to remotely reset stuff on the GW or console?
T210ByteSquawk = PACKED RECORD
Unknown1: word; // 0-1
Unknown2: word; // 2-3
CurrentEpoch: word; // 4-5
Unknown3: ARRAY[1..204] OF Byte; // dont care
END;
FUNCTION TsssDm.CalcEpoch : word;
VAR
ElapsedTime : TDateTime;
C,
ElapsedEpochs : Integer;
StartingEpoch,
RawEpoch : word;
SeedDate : TDateTime;
Strg : STRING;
BEGIN
Strg := VarDefault(GlobalSetting['EpochCusp'], '');
SeedDate := TD24StrToDateTime(Strg);
Strg := VarDefault(GlobalSetting['CurrentEpoch'], '$0');
Val('$' + Strg, StartingEpoch, C);
ElapsedTime := (Now() - SeedDate); // days plus fraction of 24 hours
ElapsedEpochs := TRUNC(ElapsedTime / (2.0 / 24.0));
RawEpoch := ElapsedEpochs * $12;
RawEpoch := RawEpoch + StartingEpoch;
RawEpoch := RawEpoch MOD $8000;
Result := RawEpoch;
END;
I am successfully setting the clock, lighting up the Internet indicator and preventing jabbering of large packets. The trick is to let it jabber (from a bad RTC packet/invalid epoch) and then parse the 210 byte packet. It contains several copies of the Epoch value. Grab one and save it to non-volatile storage (I use the DB). Also note the date and time - save that too. Each time the unit requests a 38 byte RTC packet, then use the DB values to calculate the correct Epoch - remember, it changes every 2 hours. Send that value and the jabbering stops completely.
If it ever restarts jabbering, the state machine mentioned above will stop it. Also, this algorithm should work on anyone's unit, no matter where in the Epoch cycle they are.
Epoch information is also sent by the GW in the 30 byte 0101 packet. It should be fairly easy to derive the interval from that. The 30 byte packet is not sent very often though.Following is my take on what some of the various length packets are about, including the 30-byte packets. I think the 30-byte packets are the last packet of a longer dump of history data, which starts with a 210-byte packet if there is enough data to fill one. The 30-byte packets start with 0x2164, same as the 210-byte ones, which I think this is a data type indicator. In each of these the first 8 bytes are a header. Bytes 4 & 5 of that are the epoch, which I think might actually be the address in memory where the next piece of history data will be written.
I think that in the context of a single user system with either an embedded database or a local MySQL DB engine, a server app will not have the same problems LCX does. Things like oversubscription and flaky software. Is it worth putting a lot of effort into parsing the historical data when we have everything we need in the 197 byte 0101 packet?I agree. I wasn't suggesting to include it in anything you're doing. It was mainly to share what I've found, in case it would help anyone.
I am busy with the next release!
UNIT sssSDP;
INTERFACE
TYPE
TDTBytes =
(
DTYr,
DTMo,
DTD,
DTH,
DTM
);
TBCDDateTime = ARRAY[TDTBytes] OF Byte;
TRainArray = ARRAY[0..11] OF Byte;
TWindHist = ARRAY[0..3] OF Byte;
TKWord = ARRAY[0..1] OF Byte;
TRainElement = ARRAY[0..3] OF Byte;
TBP = ARRAY[0..1] OF Byte;
// self-reading record - conversion done elsewhere
TSDPRecA = PACKED RECORD
PRIVATE
Flags: ARRAY[0..196] OF Byte; // payload goes here
FUNCTION GetBCDDateTime(CONST Index : Integer) : TBCDDateTime;
FUNCTION GetBP(CONST Index : Integer) : TBP;
FUNCTION GetByte(CONST Index : Integer) : Byte;
FUNCTION GetRainArray(CONST Index : Integer) : TRainArray;
FUNCTION GetRainElement(CONST Index : Integer) : TRainElement;
FUNCTION GetWindHist(CONST Index : Integer) : TWindHist;
FUNCTION GetWord(CONST Index : Integer) : TKWord;
PROCEDURE FillResult(VAR R; CONST BuffSize, aIndex : Integer);
PUBLIC
PROCEDURE Dump; // debug only
PROCEDURE WriteProp(VAR F : TextFile; CONST PropName : STRING; VAR Prop; PropSize : Byte); // debug only
// index is $OOOOOOLL where O=field offset in nybbles into payload and LL= length in nybbles of the field
// Property getters shift all nybbles in a field to the rightmost position (on odd length fields)
PROPERTY PacketID: Byte index $0002 Read GetByte;
PROPERTY Status: TKWord index $0603 Read GetWord;
PROPERTY DTMaxIT: TBCDDateTime index $090a Read GetBCDDateTime;
PROPERTY DtMinIT: TBCDDateTime index $130a Read GetBCDDateTime;
PROPERTY MaxIT: TKWord index $1d03 Read GetWord;
PROPERTY MinIT: TKWord index $2203 Read GetWord;
PROPERTY CurrIT: TKWord index $2703 Read GetWord;
PROPERTY DtMaxOT: TBCDDateTime index $2d0a Read GetBCDDateTime;
PROPERTY DtMinOT: TBCDDateTime index $370a Read GetBCDDateTime;
PROPERTY MaxOT: TKWord index $4103 Read GetWord;
PROPERTY MinOT: TKWord index $4603 Read GetWord;
PROPERTY CurrOT: TKWord index $4b03 Read GetWord;
PROPERTY DtUnknown1: TBCDDateTime index $510a Read GetBCDDateTime;
PROPERTY DtUnknown2: TBCDDateTime index $5b0a Read GetBCDDateTime;
PROPERTY DtUnknown3: TBCDDateTime index $650a Read GetBCDDateTime; // invalid date in test case
PROPERTY CurrOT2: TKWord index $6403 Read GetWord;
PROPERTY Stat2: Byte index $7202 Read GetByte;
PROPERTY DtMaxIH: TBCDDateTime index $740a Read GetBCDDateTime;
PROPERTY DtMinIH: TBCDDateTime index $7e0a Read GetBCDDateTime;
PROPERTY MaxIH: Byte index $8802 Read GetByte;
PROPERTY MinIH: Byte index $8a02 Read GetByte;
PROPERTY CurIH: Byte index $8c02 Read GetByte;
PROPERTY DtMaxOH: TBCDDateTime index $8e0a Read GetBCDDateTime;
PROPERTY DtMinOH: TBCDDateTime index $980a Read GetBCDDateTime; // this may have wrong offset - invalid date in test case
PROPERTY MaxOH: Byte index $a202 Read GetByte;
PROPERTY MinOH: Byte index $a402 Read GetByte;
PROPERTY CurrOH: Byte index $a602 Read GetByte;
PROPERTY DtUnknown4: TBCDDateTime index $d40a Read GetBCDDateTime;
PROPERTY DtLast1HrRain: TBCDDateTime index $ea0a Read GetBCDDateTime;
PROPERTY DtLastRainReset: TBCDDateTime index $1010a Read GetBCDDateTime;
PROPERTY RainHistory: TRainArray index $10b17 Read GetRainArray; // break elements into separate properties?
PROPERTY RFTotal: TRainElement index $11208 Read GetRainElement;
PROPERTY AvgWind: TKWord index $12204 Read GetWord;
PROPERTY WindDirHist: TWindHist index $12a06 Read GetWindHist;
PROPERTY DtMaxGust: TBCDDateTime index $1300a Read GetBCDDateTime;
PROPERTY MaxGust: TKWord index $13a04 Read GetWord;
PROPERTY CurrGust: TKWord index $14004 Read GetWord;
PROPERTY WindStat: TKWord index $14404 Read GetWord;
PROPERTY WindDirHist2: TWindHist index $14806 Read GetWindHist;
PROPERTY CurrBP: TBP index $14f04 Read GetBP;
PROPERTY BPDelta: TWindHist index $15306 Read GetWindHist; // this is a guess
PROPERTY MinBp: TBP index $15904 Read GetBP;
PROPERTY MaxBp: TBP index $16304 Read GetBP;
PROPERTY DtUnknown5: TBCDDateTime index $16c0a Read GetBCDDateTime; // bp related?
PROPERTY DtUnknown6: TBCDDateTime index $1760a Read GetBCDDateTime; // bp related?
PROPERTY CheckSum: TKword index $18604 Read GetWord;
END;
IMPLEMENTATION
USES
dgLib,
SysUtils;
{ TSDPRecA }
// debug only - not typically used
PROCEDURE TSDPRecA.Dump;
VAR
Dt : TBCDDateTime;
R : TRainArray;
Wh : TWindHist;
W : TKWord;
B : Byte;
F : TextFile;
BP : TBP;
BEGIN
AssignFile(F, 'junk.txt');
Rewrite(F);
B := PacketID;
WriteProp(F, 'PacketID', B, SizeOf(Byte)); // Byte
W := Status;
WriteProp(F, 'Status', W, SizeOf(TKWord)); // TTemp
Dt := DTMaxIT;
WriteProp(F, 'DTMaxIT', Dt, SizeOf(TBCDDateTime)); // TBCDDateTime
Dt := DtMinIT;
WriteProp(F, 'DtMinIT', Dt, SizeOf(TBCDDateTime)); // TBCDDateTime
W := MaxIT;
WriteProp(F, 'MaxIT', W, SizeOf(TKWord)); // TKWord
W := MinIT;
WriteProp(F, 'MinIT', W, SizeOf(TKWord)); // TKWord
W := CurrIT;
WriteProp(F, 'CurrIT', W, SizeOf(TKWord)); // TKWord
Dt := DtMinOT;
WriteProp(F, 'DtMinOT', Dt, SizeOf(TBCDDateTime)); // TBCDDateTime
W := MaxOT;
WriteProp(F, 'MaxOT', W, SizeOf(TKWord)); // TKWord
W := MinOT;
WriteProp(F, 'MinOT', W, SizeOf(TKWord)); // TKWord
W := CurrOT;
WriteProp(F, 'CurrOT', W, SizeOf(TKWord)); // TKWord
Dt := DtUnknown1;
WriteProp(F, 'DtUnknown1', Dt, SizeOf(TBCDDateTime)); // TBCDDateTime
Dt := DtUnknown2;
WriteProp(F, 'DtUnknown2', Dt, SizeOf(TBCDDateTime)); // TBCDDateTime
Dt := DtUnknown3;
WriteProp(F, 'DtUnknown3', Dt, SizeOf(TBCDDateTime)); // TBCDDateTime
W := CurrOT2;
WriteProp(F, 'CurrOT2', W, SizeOf(TKWord)); // TKWord
B := Stat2;
WriteProp(F, 'Stat2', B, SizeOf(Byte)); // Byte
Dt := DtMaxIH;
WriteProp(F, 'DtMaxIH', Dt, SizeOf(TBCDDateTime)); // TBCDDateTime
Dt := DtMinIH;
WriteProp(F, 'DtMinIH', Dt, SizeOf(TBCDDateTime)); // TBCDDateTime
B := MaxIH;
WriteProp(F, 'MaxIH', B, SizeOf(Byte)); // Byte
B := MinIH;
WriteProp(F, 'MinIH', B, SizeOf(Byte)); // Byte
Dt := DtMaxOH;
WriteProp(F, 'DtMaxOH', Dt, SizeOf(TBCDDateTime)); // TBCDDateTime
Dt := DtMinOH;
WriteProp(F, 'DtMinOH', Dt, SizeOf(TBCDDateTime)); // TBCDDateTime
B := MaxOH;
WriteProp(F, 'MaxOH', B, SizeOf(Byte)); // Byte
B := MinOH;
WriteProp(F, 'MinOH', B, SizeOf(Byte)); // Byte
B := CurrOH;
WriteProp(F, 'CurrOH', B, SizeOf(Byte)); // Byte
Dt := DtUnknown4;
WriteProp(F, 'DtUnknown4', Dt, SizeOf(TBCDDateTime)); // TBCDDateTime
Dt := DtLast1HrRain;
WriteProp(F, 'DtLast1HrRain', Dt, SizeOf(TBCDDateTime)); // TBCDDateTime
Dt := DtLastRainReset;
WriteProp(F, 'DtLastRainReset', Dt, SizeOf(TBCDDateTime)); // TBCDDateTime
R := RainHistory;
WriteProp(F, 'RainHistory', R, SizeOf(TRainArray)); // TRainArray
W := AvgWind;
WriteProp(F, 'AvgWind', W, SizeOf(TKWord)); // TKWord
Wh := WindDirHist;
WriteProp(F, 'WindDirHist', Wh, SizeOf(TWindHist)); // TWindHist
Dt := DtMaxGust;
WriteProp(F, 'DtMaxGust', Dt, SizeOf(TBCDDateTime)); // TBCDDateTime
W := MaxGust;
WriteProp(F, 'MaxGust', W, SizeOf(TKWord)); // TKWord
W := CurrGust;
WriteProp(F, 'CurrGust', W, SizeOf(TKWord)); // TKWord
W := WindStat;
WriteProp(F, 'WindStat', W, SizeOf(TKWord)); // TKWord
Wh := WindDirHist2;
WriteProp(F, 'WindDirHist2', Wh, SizeOf(TWindHist)); // TWindHist
BP := CurrBP;
WriteProp(F, 'CurrBP', BP, SizeOf(TBP)); // TKWord
Wh := BPDelta;
WriteProp(F, 'BPDelta', Wh, SizeOf(TWindHist)); // TWindHist
BP := MinBp;
WriteProp(F, 'MinBp', BP, SizeOf(TBP)); // TKWord
BP := MaxBp;
WriteProp(F, 'MaxBp', BP, SizeOf(TBP)); // TBP
Dt := DtUnknown5;
WriteProp(F, 'DtUnknown5', Dt, SizeOf(TBCDDateTime)); // TBCDDateTime
Dt := DtUnknown6;
WriteProp(F, 'DtUnknown6', Dt, SizeOf(TBCDDateTime)); // TBCDDateTime
W := CheckSum;
WriteProp(F, 'CheckSum', W, SizeOf(TKword)); // TKword
CloseFile(F);
END;
// fill output buffer R with the contents of the payload, at the given offset
// and expected field length
PROCEDURE TSDPRecA.FillResult(VAR R; CONST BuffSize, aIndex : Integer);
VAR
I,
NybOffset : Integer;
NrNybs : Integer;
Mask : Integer;
INyb : Integer;
Nt,
B : Byte;
Buff : TByteArray Absolute R;
IBuff : Integer;
BEGIN
NrNybs := aIndex AND $FF;
NybOffset := aIndex SHR 8;
IF (NrNybs SHR 1) > Buffsize THEN
RAISE Exception.Create('Buffer Overrun Detected');
FillChar(Buff, BuffSize, 0); // clear the buffer - set it to all zeros
// field is located completely on natural byte boundary, so just copy bytes
IF (NOT Odd(NybOffset)) AND (NOT Odd(NrNybs)) THEN BEGIN
FOR I := 0 TO (NrNybs DIV 2) - 1 DO
Buff[I] := Flags[(NybOffset DIV 2) + I];
EXIT;
END;
// field was not on byte boundary, so do nybble copy
FOR INyb := NybOffset TO NybOffset + NrNybs - 1 DO BEGIN
// get the nybble we want from the flag array and put it into Nt
B := Flags[INyb DIV 2];
// calculate where we want to put the nybbles in the output buffer
IBuff := (INyb - NybOffset) DIV 2;
IF Odd(INyb) THEN BEGIN
Nt := (B AND $F); // get the right nybble
Buff[IBuff] := (Buff[IBuff] AND $F) OR (Nt SHL 4); // or it into the proper place in the output buffer
END
ELSE BEGIN
Nt := (B AND $F0) SHR 4; // get the left nybble
Buff[IBuff] := (Buff[IBuff] AND $F0) OR Nt;
END;
END;
// shift all nybbles 4 bits to right, if there is dead space on the far right of the output buffer
IF Odd(NrNybs) THEN BEGIN
// go backwards through the output buffer
FOR INyb := NrNybs DIV 2 DOWNTO 1 DO BEGIN
Buff[INyb] := Buff[INyb] SHR 4; // shift it right one nybble
B := (Buff[INyb - 1] AND $0F) SHL 4; // get neighbor low nybble on left and shift it to high nybble
Buff[INyb] := Buff[INyb] OR B; // move it to current byte
Buff[INyb - 1] := Buff[INyb - 1] SHR 4; // shift neighbors upper nybble into lower nybble
END; // shampoo, rinse and repeat
END;
END;
FUNCTION TSDPRecA.GetBCDDateTime(CONST Index : Integer) : TBCDDateTime;
BEGIN
FillResult(Result, SizeOf(Result), Index);
END;
FUNCTION TSDPRecA.GetBP(CONST Index : Integer) : TBP;
BEGIN
FillResult(Result, SizeOf(Result), Index);
END;
FUNCTION TSDPRecA.GetRainArray(CONST Index : Integer) : TRainArray;
BEGIN
FillResult(Result, SizeOf(Result), Index);
END;
FUNCTION TSDPRecA.GetRainElement(CONST Index : Integer) : TRainElement;
BEGIN
FillResult(Result, SizeOf(Result), Index);
END;
FUNCTION TSDPRecA.GetByte(CONST Index : Integer) : Byte;
BEGIN
FillResult(Result, SizeOf(Result), Index);
END;
FUNCTION TSDPRecA.GetWindHist(CONST Index : Integer) : TWindHist;
BEGIN
FillResult(Result, SizeOf(Result), Index);
END;
FUNCTION TSDPRecA.GetWord(CONST Index : Integer) : TKword;
BEGIN
FillResult(Result, SizeOf(Result), Index);
END;
PROCEDURE TSDPRecA.WriteProp(VAR F : TextFile; CONST PropName : STRING; VAR Prop; PropSize : Byte);
VAR
B : TByteArray Absolute Prop;
I : Integer;
BEGIN
Write(F, PadTrim(PropName, 20));
FOR I := 0 TO PropSize - 1 DO
Write(F, IntToHex(B[I], 2) + ' ');
WRITELN(F);
END;
END.
Here is my current layout for the 197-byte data packets.
http://www.keckec.com/weather/LCX_Data_Layout.pdf
Do you have a spreadsheet version of that PDF?The spreadsheet is here:
There may be a problem with Min Outside Temp at nybble-offset $46. Mine calculates out to -15F. The display says my min OT was 35F. All the other temps seem OK so far.Hmmm. It seems to be working here. My raw data right now is 0x542, which is coming out to 57.56F. Here is the php code that converts to deg F.
function bcd2int(&$nybs,$startn,$len)
{
$retval = 0;
for ($i = 0; $i < $len; $i++)
{
if ($nybs[$startn+$i] > 9)
{
return -1;
}
$retval = $retval * 10 + $nybs[$startn+$i];
}
return $retval;
}
function temp2str(&$nybs,$startn)
{
$retstr = "";
$val = bcd2int($nybs,$startn,3);
if ($val < 0)
{
return " N/A ";
}
$otemp = $val / 10.0 - 40.0;
$otemp = $otemp * 9.0 / 5 + 32.0;
$retstr .= sprintf("%6.2f",$otemp);
return $retstr;
}
I made a correction to the layout. The all-time minimum outside temperature should be at nybble 0x6a, not 0x181, and it's actually wind chill. I don't know what the 3-nybble field at 0x181 is, but it still looks like a temperature. I've updated the spreadsheet:
http://www.keckec.com/weather/LcxLayout.ods
There are a few minor problems with some of the new fields. The one I mentioned before remains, plus I noticed a couple others. I have circled them on the screen shot of the new SkySpy tab found below. OT Min is at (nybble) offset $46. OT All time low is at offset $6a. Unknown date is at offset $112. OH Min Date is at offset $98The unknown date is the same in your data as mine. Somewhere I saw in LCX documentation that the initial value for dates is 1/1/2013. I assume this date is unused.
by nyb |0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1|2|2|2|2|2|2|2|2|2|2|2|2|2|2|2|2|3|3|3|3|3|3|3|3|3|3|3|3|3|3|3|3
te ble |0|1|2|3|4|5|6|7|8|9|a|b|c|d|e|f|0|1|2|3|4|5|6|7|8|9|a|b|c|d|e|f|0|1|2|3|4|5|6|7|8|9|a|b|c|d|e|f|0|1|2|3|4|5|6|7|8|9|a|b|c|d|e|f
00 000 |0|1|6|4|1|0|2|1|0|1|4|0|5|1|6|1|7|3|5|1|4|0|5|1|7|0|7|3|0|7|0|7|0|0|5|8|9|0|0|6|4|5|0|0|0|1|4|0|5|2|6|1|7|3|8|1|4|0|5|2|6|2|3|0
20 040 |1|6|6|6|0|0|5|5|4|0|0|5|8|8|0|0|4|1|4|0|5|1|5|1|2|2|1|1|4|0|5|2|5|1|8|1|1|8|3|6|0|0|4|3|6|0|0|5|8|8|0|0|1|4|0|5|2|5|2|2|3|8|1|4
40 080 |0|5|1|7|0|7|2|9|5|7|2|0|5|1|1|4|0|5|2|7|0|6|3|1|1|4|0|5|2|6|1|7|4|1|8|7|5|1|8|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0
60 0c0 |0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|1|4|0|3|0|1|0|3|5|9|0|0|2|6|0|5|0|0|0|0|0|0|1|4|0|4|1|9|0|9|0|3|0|0|1|0|0|6|0|0|0|0|0|0
80 100 |0|1|4|0|5|0|1|1|7|3|1|0|0|0|0|0|0|0|1|3|0|1|0|1|0|0|0|0|0|0|0|0|0|0|0|0|f|c|0|0|5|0|2|4|4|4|4|3|1|4|0|5|2|7|0|6|2|6|0|4|5|c|0|0
a0 140 |0|1|b|0|0|0|1|0|2|4|4|4|4|3|0|2|9|9|5|1|0|1|4|2|0|2|9|6|9|1|0|0|5|5|0|3|0|2|9|1|0|2|5|8|1|4|0|2|2|8|1|6|2|4|1|4|0|1|1|3|1|0|1|9
c0 180 |0|4|5|3|0|3|7|2|c|f
Thanks for the info, but you do know that the spreadsheet errors when opening because it can't access your note file.Sorry, I renamed one of the files but didn't update the one on the web site. I think this should work...
10ACTony,
Thanks for sending the data packet. Here's what I see in it for the fields Skydvrz found to be out of range.
Min outside temp at nybble 0x46: raw=0x302 -> 14.4F (at 3/3/14 07:46)
All-time Low OT w/wind chill at nybble 0x6a: raw=0x225 -> +0.5F (at 3/3/14 07:03)
Date/time of min outside humidity at nybble 0x98: 3/26/14 14:09
I don't know where you are. Do these values look at all reasonable?
Skydvrz's data packet had some odd values for those fields.
Val Interval
0 1 minute
1 5 minutes
2 10 minutes
3 15 minutes
4 20 minutes
5 30 minutes
6 1 hour
7 2 hours (saves on even hours, local time)
There may be valid higher values for these bytes, and there may be a value which disables saving history altogether. This might stop the epoch from incrementing. I haven't looked for that.I added a second weather station using this software to Weather Underground.
http://www.wunderground.com/personal-weather-station/dashboard?ID=KCACLEAR4
I had a few hrs to work on the code today, I took a snapshot that keckec has updated and modified it to upload to weather underground.
It doesn't have the fix to stop sending 210 byte packets or anything, but it does seem to work well:
http://www.wunderground.com/personal-weather-station/dashboard?ID=KCAPETAL29
Code Snapshot is here:
https://github.com/lowerpower/LaCrosse
Start | End | Description |
0 | 2 | Maybe rainfall, ranges from 0x000 to 0x003 in my data |
3 | 3 | A wind gust direction? varies from 0x0-0xf, but varies little from one to the next |
4 | 4 | Wind direction: varies from 0x0-0xf, often greatly from one to the next |
5 | 7 | Wind gust speed; 3 nybbles in .01 kph |
8 | 10 | Wind speed; 3 nybbles in .01 kph |
11 | 12 | Outside relative humidity(%) |
13 | 14 | Inside relative humidity(%) |
15 | 19 | Barometer in .1 mbar |
20 | 22 | Outside T in .1 degC + 400 |
23 | 25 | Inside T in .1 degC + 400 |
26 | 35 | Date as ymdhi |
I just uploaded some stuff that might help.
Reviewing what you guys have done, it has really come along. I am interested in
the Linux side of the house (only run Win7 in a VM every once in a while), indeed
I want to see if I can cram enough of it into a Raspberry PI to operate as the back
end and have a larger machine pull off the data every so often, or just try to set it
up to where the RPI does the updates. If I need to capture more history than the
RPI can hold I can just dump it to a db on a big machine and be done with it. I
have a RPI ordered and this will probably be the first thing I put on the device.
I'm still struggling with the next history memory address part. My logs show that while it almost always advances by 0x12 every 15 minutes (my history interval), occasionally it won't advance for longer than that, rarely much longer (i.e 2 hours).Glad your history blabbermouth settled down. At one time I was trying to anticipate what the next history address will be, and that worked most of the time to keep it from sending history packets. But it didn't always work, and that might be what you're seeing too. At this point I just repeat the address it last sent out, so when the address changes what I send is behind by one history record length (0x12 bytes). So it then sends a 1-record history packet, I save the address from bytes 4&5, and am back in sync with it again. That works out since I save that history record. That way I have the complete history. I think this may be what weatherdirect does too.
Nonetheless, by getting the next history address closer to the last history address, it has finally gotten the long history recaps to stop.
BTW, any thoughts on the 5-byte packet that triggers this? The first byte is always 0x41 (clearly, the packet type).I think the second byte is RF signal strength, as a binary value in percent, with 5% granularity. This value is also in the same byte in the history (type 0x21) and data (type 0x01) packets. I don't know what the other bytes are. When mine was communicating with weatherdirect, the third byte contained same values as you, and a 35 once. I don't have a clue about the last two bytes.
The third byte has always been one of (10, 11, 20, 21, 30, 31); may it be some kind of forecast value? The other three bytes bounce around quite a bit, with no clear trends. Also, the number of different values is much less than the numbers of samples, so they have some non-random meaning.
I finally got the history packets to dry up, by saving the last memory address from the history packets and sending it back in the 14:01 reply. However, due to some fat fingering, I sent a bad address, and the thing has gone loopy.
Since the bad 14:01 packet, the system is sending the 00:70 packets non-stop. Interestingly, the weatherdirect.com response to those changed from padding the first 14 bytes with 0x00 to 0x2e. Also, the weatherdirect.com response to the 01:00 packet is also filled with 0x2e, except for the memory address bytes and the checksum. Not even the leading 01 packet type byte is there.
I would really like to stop the flood of 00:70 packets. I let the system talk directly to weatherdirect (without my relay) for a couple hours, and it's still doing it. I've rebooted the gateway multiple times, and reset the weather station itself once. No luck. Any thoughts?
Hmm! I've been saving the address from bytes 6 and 7. Maybe that's why mine has stopped sending history packets completely now. Like you, I had been getting the one record response every 15 minutes, but I haven't seen one since I sent the bad address packet.
At this point I just repeat the address it last sent out, so when the address changes what I send is behind by one history record length (0x12 bytes). So it then sends a 1-record history packet, I save the address from bytes 4&5, and am back in sync with it again. That works out since I save that history record. That way I have the complete history. I think this may be what weatherdirect does too.
I think the second byte is RF signal strength, as a binary value in percent, with 5% granularity.
Now, I have one question about these: How do I shut them up? Every time my gateway sends a full current data packet, it retransmits the entire history again.
You need to send a properly formatted 0010 reply to the GW after it requests the current time in a 0100 5-byte packet.Instead of calling it "epoch", I call it "last history memory address". When you get an history packet (an 01:01 packet with a first byte = 0x21, the last history address is in bytes 4-5. I've been putting this in bytes 22-23 of my 14:01 replies to the 01:00 packets, and I've been getting one 30-byte history packet every 15 minutes or so.
The reply must contain your PWS serial number issued by LCX - the 7FFFxxxxxxxxxxxxxx hex number.
It must also contain the correct local time/date (if you want your LCD display to have an accurate clock).
Last, and there is some controversy about this, you probably need to update the "epoch" field in the reply packet to match the value that the GW expects. It is my opinion that if the epoch value is not set correctly, then the GW will interpret this as an internet interruption and start sending historical packets again.
I have this handshake working perfectly in the latest (unreleased) version of SkySpy. The only time I see 210-byte packets is when I stop or pause the SkySpy service long enough for the GW to time out.
I'm still wrestling with what to do with the historical data myself. I can't see how storing the values coming from the unit itself will be helpful, as I can always look up the same data from my database anytime. I might store frequently required values in a history table to relieve my database from looking up the same thing over and over again, but I still don't think I'd populate that table with data from the weather station. Maybe there's something there that I can't get from the db, but I can't see it.
I think historical data might be useful if the server is down for some time. I don't try to achieve good reliability with UPSes, etc., and times when the power is out might be the times I later wish I had the data. I suspect the console/gateway will save history until the server is back up, at which time the server will store whatever was missed.Good point. Saving the history as extra data points in sensorvalues certainly won't hurt. I think the only problem is to be careful with the units, as some of those in the history packets seem to be in different formats than the current data packets. Since my algorithm for saving the last memory address occurs after the history packet is sent, it should catch me up after an outage.
Has anybody else noticed that the max gust per cycle (if that's what it really is) in bytes 160-161 of the sensor data packets are all multiples of 0xd8? The current wind speeds in bytes 145-146 are all multiples of 0x24 (1/6 of the intervals for gusts) as well. I've been interpreting both values as unsigned integers of 0.01 km/hr, meaning I'm getting a granularity of .36 kph and 2.16 kph for wind and gusts respectively.I use the same decoding algorithm for all three wind values, at bytes 145, 157, and 160, and they seem to correlate ok. One check is the max gust value at byte 157. This should always match the console. I divide the 4-nybble binary value by 161.9 (there is a typo in my writeup, BTW). Are you using four nybbles for each value?
The values I'm getting seem rather low to me. I get daily thunderstorms where I live, with gusts often over 40 mph, but the highest wind values (current or gust) that I've seen are 0x534 (13.32 kph or 8.33mph). I'm suspecting the units might be 0.1 km/h, not 0.01.
BTW, I pointed my leaf blower at the anemometer for a while, so a top speed of 83 mph is not ridiculous.My leaf blower must be a bit wimpy. When I did that, it only went up to about 35 mph :-(
function heatindex($t, $rh) { // T in deg F
//Valid for T>80 F and RH>40%
if ($t < 80 || $rh < 40) return $t;
//{HI} = c_1 + c_2 T + c_3 R + c_4 T R
// + c_5 T^2 + c_6 R^2 + c_7 T^2R + c_8 T R^2 + c_9 T^2 R^2\ \,
//Constants from NOAA
$c = [ 0, -42.379, 2.04901523, 10.14333127, -0.22475541,
-6.83783E-3, -5.481717E-2, 1.22874E-3, 8.5282E-4, -1.99E-6 ];
$t2 = pow($t,2);
$rh2 = pow($rh,2);
$hi = $c[1] + $c[2]*$t + $c[3]*$rh + $c[4]*$t*$rh
+ $c[5]*$t2 + $c[6]*$rh2 + $c[7]*$t2*$rh + $c[8]*$t*$rh2 + $c[9]*$t2*$rh2;
return round($hi,1);
}
Can anyone make more sense of the rainfall data than I am?As I understand it, the previous month's rain only changes on the first day of the month. Likewise the previous week's rain only changes when the week changes. The start of the week is defined as midnight of the day prior to the day of the week when batteries were last installed in the console. I think 1-hr and 24-hr rain are moving windows. They may put a timestamp on each bucket tip, and tally how many tips fall within each moving window.
According to keckec, the 7-nyb value at nyb 184 is the previous month rain.
Likewise, the 6-nyb value at 206 is the previous week rain.
My server has only been collecting data reliably since July 8, so I can't say anything about the monthly rainfall value except that in my case, it has been constant at 181.9 mm since I started collecting.
However, I definitely have more than a week of data, but my weekly rainfall value has been almost constant at 63.2 mm, the only variation being a few values of 75.0 on July 4 (before reliable collection began).
The range of the values seems appropriate for monthly and weekly rainfalls, by why aren't they changing?
Likewise the previous week's rain only changes when the week changes. The start of the week is defined as midnight of the day prior to the day of the week when batteries were last installed in the console.Yup! That's what the manual says. But assuming my console's week ended July 4, I would have expected the data to change again on July 12, but it didn't. It would be an amazing coincidence if the rainfall from one week to the next was the same down to the last .01 mm! I'll see what happens July 19, I guess.
how are you guys detecting bucket tips from sensor and/or history data packets?
I just use the difference between the current rain since reset value from the last packet. Sounds simple, but my code must take account of the possibility that a reset occurred between packets. I also use this data to calculate running weekly and 30 day rain totals, since the given definition of weekly and monthly data doesn't work for me.Thanks for the input. The user reset does add complexity. I keep thinking there might be a way to remotely reset things via one of the packets sent to the gateway.
Something I might try is to use the rainfall value from the history records to tally rainfall.I have a problem with the rainfall data in the history packets, in that it doesn't agree with the value from the SDPs. For example, this morning we had a brief light rain. The SDP reported 0.25 mm, but the history reported 0.125 mm. Because I'm currently using data from both in my rainfall graphs, it introduces noise. Look at the rainfall graph today on my weather page,
I have a problem with the rainfall data in the history packets, in that it doesn't agree with the value from the SDPs. For example, this morning we had a brief light rain. The SDP reported 0.25 mm, but the history reported 0.125 mm. Because I'm currently using data from both in my rainfall graphs, it introduces noise.Are you sure about the history scaling? I think the history rainfall field is in bucket tips, with each tip being about 0.01", or 0.25mm.
I came across a way to change the interval for sending SDP packets, from the 14:01 packet sent in response to the 0100 packet.I've been controlling the SDP frequency by specifying the number of seconds between packets (currently using 300) in the last two bytes of the 18-byte 70:00 reply to the 00:70 packets. I've been setting 0x3 in both bytes 0x14 and 0x1f of the 14:01 packets.
Are you sure about the history scaling? I think the history rainfall field is in bucket tips, with each tip being about 0.01", or 0.25mm.It's been raining here for an half-hour or so: These are my data
Time Ptype Stype Value
19:09 2 10 6.19
19:05 2 10 4.9
19:01 2 10 4.38
19:00 9 10 0
18:58 2 10 4.12
18:57 2 10 3.87
18:53 2 10 3.35
18:49 2 10 2.58
18:45 2 10 2.32
18:45 9 10 0
18:42 2 10 2.32
18:41 2 10 2.06
18:30 9 10 0.01
18:21 2 10 0
18:17 2 10 0
18:15 9 10 0.01
18:13 2 10 0
18:09 2 10 0
18:05 2 10 0
18:01 2 10 0
17:49 2 10 0
17:45 2 10 0
Packet type 2 are SDPs, and type 9 are history values. All the sensor types are current rain hour on my system. The values are as reported by the weather station, no scaling except for the decimal points (i.e. whatever units they are, I not converting them to anything).Based on your recent posts, I tried playing with the settings for the interval it sends in Weather data...not much luck. Still runs around 5 minute intervals.If you want to try something, set byte 0x14 of the 14:01 reply packet to 0. On mine, that changes the interval of the sensor data packet to 1 minute. For reference, the history interval setting in byte 0x1f of the same packet is 0x03 (15 minutes), and byte 0x11 of the 70:00 packet is 0xf0 (240 seconds). I believe this value sets the interval of the 00:70 "ping" packet, which I think is used as a keep-alive to maintain the connection.
I am very interested in testing new settings, if you need someone to try them out.
192.168.2.206 - - [22/Jul/2014:09:34:41 -0400] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 18 "-" "-"
192.168.2.206 - - [22/Jul/2014:09:34:42 -0400] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 38 "-" "-"
192.168.2.206 - - [22/Jul/2014:09:34:44 -0400] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 18 "-" "-"
192.168.2.206 - - [22/Jul/2014:09:36:05 -0400] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 18 "-" "-"
192.168.2.206 - - [22/Jul/2014:09:37:26 -0400] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 18 "-" "-"
192.168.2.206 - - [22/Jul/2014:09:38:34 -0400] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 - "-" "-"
192.168.2.206 - - [22/Jul/2014:09:38:43 -0400] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 38 "-" "-"
192.168.2.206 - - [22/Jul/2014:09:38:46 -0400] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 18 "-" "-"
192.168.2.206 - - [22/Jul/2014:09:38:47 -0400] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 38 "-" "-"
192.168.2.206 - - [22/Jul/2014:09:38:49 -0400] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 18 "-" "-"
192.168.2.206 - - [22/Jul/2014:09:49:51 -0400] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 - "-" "-"
192.168.2.206 - - [22/Jul/2014:09:49:59 -0400] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 38 "-" "-"
192.168.2.206 - - [22/Jul/2014:09:50:02 -0400] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 18 "-" "-"
192.168.2.206 - - [22/Jul/2014:09:50:03 -0400] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 38 "-" "-"
192.168.2.206 - - [22/Jul/2014:09:50:05 -0400] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 18 "-" "-"
192.168.2.206 - - [22/Jul/2014:09:53:56 -0400] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 - "-" "-"
192.168.2.206 - - [22/Jul/2014:09:54:04 -0400] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 38 "-" "-"
192.168.2.206 - - [22/Jul/2014:09:54:07 -0400] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 18 "-" "-"
192.168.2.206 - - [22/Jul/2014:09:54:08 -0400] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 38 "-" "-"
192.168.2.206 - - [22/Jul/2014:09:54:10 -0400] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 18 "-" "-"
192.168.2.206 - - [22/Jul/2014:09:55:03 -0400] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 - "-" "-"
192.168.2.206 - - [22/Jul/2014:09:55:12 -0400] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 38 "-" "-"
192.168.2.206 - - [22/Jul/2014:09:55:15 -0400] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 18 "-" "-"
192.168.2.206 - - [22/Jul/2014:09:55:16 -0400] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 38 "-" "-"
192.168.2.206 - - [22/Jul/2014:09:55:18 -0400] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 18 "-" "-"
192.168.2.206 - - [22/Jul/2014:09:58:10 -0400] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 - "-" "-"
192.168.2.206 - - [22/Jul/2014:09:58:18 -0400] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 38 "-" "-"
192.168.2.206 - - [22/Jul/2014:09:58:21 -0400] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 18 "-" "-"
192.168.2.206 - - [22/Jul/2014:09:58:22 -0400] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 38 "-" "-"
192.168.2.206 - - [22/Jul/2014:09:58:24 -0400] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 18 "-" "-"
192.168.2.206 - - [22/Jul/2014:10:02:15 -0400] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 - "-" "-"
192.168.2.206 - - [22/Jul/2014:10:02:23 -0400] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 38 "-" "-"
192.168.2.206 - - [22/Jul/2014:10:02:26 -0400] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 18 "-" "-"
192.168.2.206 - - [22/Jul/2014:10:02:27 -0400] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 38 "-" "-"
192.168.2.206 - - [22/Jul/2014:10:02:29 -0400] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 18 "-" "-"
write weather underground : 2014-07-22 09:49:51 : &tempf=74.12&humidity=83&dewptf=69.77&windspeedmph=5.34&windgustmph=6.89&winddir=154&baromin=28.12&rainin=0.00&dailyrainin=0.03&softwaretype=phpLaxWeatherBro : returned:success
write weather underground : 2014-07-22 09:53:56 : &tempf=74.12&humidity=83&dewptf=69.77&windspeedmph=2.45&windgustmph=6.89&winddir=115&baromin=28.12&rainin=0.00&dailyrainin=0.03&softwaretype=phpLaxWeatherBro : returned:success
write weather underground : 2014-07-22 09:55:03 : &tempf=74.30&humidity=83&dewptf=69.95&windspeedmph=1.56&windgustmph=2.67&winddir=187&baromin=28.12&rainin=0.00&dailyrainin=0.03&softwaretype=phpLaxWeatherBro : returned:success
write weather underground : 2014-07-22 09:58:10 : &tempf=74.48&humidity=82&dewptf=69.84&windspeedmph=3.34&windgustmph=8.23&winddir=127&baromin=28.11&rainin=0.00&dailyrainin=0.03&softwaretype=phpLaxWeatherBro : returned:success
write weather underground : 2014-07-22 10:02:15 : &tempf=74.30&humidity=82&dewptf=69.67&windspeedmph=4.00&windgustmph=6.89&winddir=153&baromin=28.12&rainin=0.00&dailyrainin=0.01&softwaretype=phpLaxWeatherBro : returned:success
192.168.1.16 - - [22/Jul/2014:07:49:17 -0700] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 18 "-" "-"
192.168.1.16 - - [22/Jul/2014:07:49:20 -0700] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 0 "-" "-"
192.168.1.16 - - [22/Jul/2014:07:49:29 -0700] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 38 "-" "-"
192.168.1.16 - - [22/Jul/2014:07:49:30 -0700] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 18 "-" "-"
192.168.1.16 - - [22/Jul/2014:07:50:38 -0700] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 0 "-" "-"
192.168.1.16 - - [22/Jul/2014:07:50:47 -0700] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 38 "-" "-"
192.168.1.16 - - [22/Jul/2014:07:50:48 -0700] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 18 "-" "-"
192.168.1.16 - - [22/Jul/2014:07:51:56 -0700] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 0 "-" "-"
192.168.1.16 - - [22/Jul/2014:07:52:05 -0700] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 38 "-" "-"
192.168.1.16 - - [22/Jul/2014:07:52:06 -0700] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 18 "-" "-"
192.168.1.16 - - [22/Jul/2014:07:53:14 -0700] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 0 "-" "-"
192.168.1.16 - - [22/Jul/2014:07:53:23 -0700] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 38 "-" "-"
192.168.1.16 - - [22/Jul/2014:07:53:24 -0700] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 18 "-" "-"
192.168.1.16 - - [22/Jul/2014:07:54:32 -0700] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 0 "-" "-"
192.168.1.16 - - [22/Jul/2014:07:54:41 -0700] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 38 "-" "-"
192.168.1.16 - - [22/Jul/2014:07:54:42 -0700] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 18 "-" "-"
192.168.2.206 - - [22/Jul/2014:12:30:27 -0400] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 - "-" "-"
192.168.2.206 - - [22/Jul/2014:12:30:35 -0400] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 38 "-" "-"
192.168.2.206 - - [22/Jul/2014:12:30:38 -0400] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 18 "-" "-"
192.168.2.206 - - [22/Jul/2014:12:30:39 -0400] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 38 "-" "-"
192.168.2.206 - - [22/Jul/2014:12:30:41 -0400] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 18 "-" "-"
192.168.2.206 - - [22/Jul/2014:12:34:32 -0400] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 - "-" "-"
192.168.2.206 - - [22/Jul/2014:12:34:40 -0400] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 38 "-" "-"
192.168.2.206 - - [22/Jul/2014:12:34:43 -0400] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 18 "-" "-"
192.168.2.206 - - [22/Jul/2014:12:34:44 -0400] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 38 "-" "-"
192.168.2.206 - - [22/Jul/2014:12:34:46 -0400] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 18 "-" "-"
192.168.2.206 - - [22/Jul/2014:12:38:37 -0400] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 - "-" "-"
192.168.2.206 - - [22/Jul/2014:12:38:45 -0400] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 38 "-" "-"
192.168.2.206 - - [22/Jul/2014:12:38:48 -0400] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 18 "-" "-"
192.168.2.206 - - [22/Jul/2014:12:38:49 -0400] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 38 "-" "-"
192.168.2.206 - - [22/Jul/2014:12:38:51 -0400] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 18 "-" "-"
192.168.2.206 - - [22/Jul/2014:12:42:42 -0400] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 - "-" "-"
192.168.2.206 - - [22/Jul/2014:12:42:50 -0400] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 38 "-" "-"
192.168.2.206 - - [22/Jul/2014:12:42:53 -0400] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 18 "-" "-"
192.168.2.206 - - [22/Jul/2014:12:42:54 -0400] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 38 "-" "-"
192.168.2.206 - - [22/Jul/2014:12:42:56 -0400] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 18 "-" "-"
192.168.2.206 - - [22/Jul/2014:12:45:48 -0400] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 - "-" "-"
192.168.2.206 - - [22/Jul/2014:12:45:56 -0400] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 38 "-" "-"
192.168.2.206 - - [22/Jul/2014:12:45:59 -0400] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 18 "-" "-"
192.168.2.206 - - [22/Jul/2014:12:46:00 -0400] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 38 "-" "-"
192.168.2.206 - - [22/Jul/2014:12:46:02 -0400] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 18 "-" "-"
192.168.2.206 - - [22/Jul/2014:12:46:56 -0400] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 - "-" "-"
192.168.2.206 - - [22/Jul/2014:12:47:04 -0400] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 38 "-" "-"
192.168.2.206 - - [22/Jul/2014:12:47:07 -0400] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 18 "-" "-"
192.168.2.206 - - [22/Jul/2014:12:47:08 -0400] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 38 "-" "-"
192.168.2.206 - - [22/Jul/2014:12:47:10 -0400] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 18 "-" "-"
192.168.2.206 - - [22/Jul/2014:12:50:02 -0400] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 - "-" "-"
192.168.2.206 - - [22/Jul/2014:12:50:10 -0400] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 38 "-" "-"
192.168.2.206 - - [22/Jul/2014:12:50:13 -0400] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 18 "-" "-"
192.168.2.206 - - [22/Jul/2014:12:50:14 -0400] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 38 "-" "-"
192.168.2.206 - - [22/Jul/2014:12:50:16 -0400] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 18 "-" "-"
192.168.2.206 - - [22/Jul/2014:12:54:07 -0400] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 - "-" "-"
192.168.2.206 - - [22/Jul/2014:12:54:15 -0400] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 38 "-" "-"
192.168.2.206 - - [22/Jul/2014:12:54:18 -0400] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 18 "-" "-"
192.168.2.206 - - [22/Jul/2014:12:54:19 -0400] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 38 "-" "-"
192.168.2.206 - - [22/Jul/2014:12:54:21 -0400] "PUT http://box.weatherdirect.com/request.breq HTTP/1.1" 200 18 "-" "-"
write weather underground : 2014-07-22 11:42:26 : &tempf=75.92&humidity=79&dewptf=70.38&windspeedmph=1.78&windgustmph=4.00&winddir=97&baromin=28.11&rainin=0.00&dailyrainin=0.01&softwaretype=phpLaxWeatherBro : returned:success
write weather underground : 2014-07-22 11:45:32 : &tempf=75.92&humidity=81&dewptf=70.96&windspeedmph=1.78&windgustmph=4.00&winddir=217&baromin=28.11&rainin=0.00&dailyrainin=0.01&softwaretype=phpLaxWeatherBro : returned:success
write weather underground : 2014-07-22 11:50:35 : &tempf=76.28&humidity=81&dewptf=71.3&windspeedmph=2.45&windgustmph=4.00&winddir=148&baromin=28.11&rainin=0.00&dailyrainin=0.01&softwaretype=phpLaxWeatherBro : returned:success
write weather underground : 2014-07-22 11:54:41 : &tempf=76.64&humidity=81&dewptf=71.65&windspeedmph=0.89&windgustmph=5.34&winddir=205&baromin=28.11&rainin=0.00&dailyrainin=0.01&softwaretype=phpLaxWeatherBro : returned:success
write weather underground : 2014-07-22 11:57:47 : &tempf=77.36&humidity=77&dewptf=71.17&windspeedmph=4.22&windgustmph=5.34&winddir=232&baromin=28.11&rainin=0.00&dailyrainin=0.01&softwaretype=phpLaxWeatherBro : returned:success
write weather underground : 2014-07-22 12:01:52 : &tempf=77.54&humidity=78&dewptf=71.64&windspeedmph=3.34&windgustmph=5.34&winddir=176&baromin=28.10&rainin=0.00&dailyrainin=0.00&softwaretype=phpLaxWeatherBro : returned:success
write weather underground : 2014-07-22 12:05:57 : &tempf=77.72&humidity=78&dewptf=71.82&windspeedmph=0.67&windgustmph=1.33&winddir=165&baromin=28.11&rainin=0.00&dailyrainin=0.00&softwaretype=phpLaxWeatherBro : returned:success
write weather underground : 2014-07-22 12:10:02 : &tempf=78.26&humidity=79&dewptf=72.63&windspeedmph=1.56&windgustmph=2.67&winddir=183&baromin=28.10&rainin=0.00&dailyrainin=0.00&softwaretype=phpLaxWeatherBro : returned:success
write weather underground : 2014-07-22 12:14:07 : &tempf=78.44&humidity=78&dewptf=72.51&windspeedmph=0.89&windgustmph=1.33&winddir=226&baromin=28.10&rainin=0.00&dailyrainin=0.00&softwaretype=phpLaxWeatherBro : returned:success
write weather underground : 2014-07-22 12:18:12 : &tempf=78.44&humidity=78&dewptf=72.51&windspeedmph=1.33&windgustmph=1.33&winddir=308&baromin=28.10&rainin=0.00&dailyrainin=0.00&softwaretype=phpLaxWeatherBro : returned:success
write weather underground : 2014-07-22 12:22:17 : &tempf=78.62&humidity=79&dewptf=72.98&windspeedmph=3.11&windgustmph=4.00&winddir=222&baromin=28.10&rainin=0.00&dailyrainin=0.00&softwaretype=phpLaxWeatherBro : returned:success
write weather underground : 2014-07-22 12:26:22 : &tempf=78.80&humidity=78&dewptf=72.86&windspeedmph=3.34&windgustmph=5.34&winddir=247&baromin=28.10&rainin=0.00&dailyrainin=0.00&softwaretype=phpLaxWeatherBro : returned:success
write weather underground : 2014-07-22 12:30:27 : &tempf=78.80&humidity=78&dewptf=72.86&windspeedmph=1.33&windgustmph=1.33&winddir=180&baromin=28.10&rainin=0.00&dailyrainin=0.00&softwaretype=phpLaxWeatherBro : returned:success
write weather underground : 2014-07-22 12:34:32 : &tempf=78.98&humidity=77&dewptf=72.73&windspeedmph=3.11&windgustmph=4.00&winddir=105&baromin=28.10&rainin=0.00&dailyrainin=0.00&softwaretype=phpLaxWeatherBro : returned:success
write weather underground : 2014-07-22 12:38:37 : &tempf=79.16&humidity=77&dewptf=72.9&windspeedmph=0.67&windgustmph=1.33&winddir=253&baromin=28.10&rainin=0.00&dailyrainin=0.00&softwaretype=phpLaxWeatherBro : returned:success
write weather underground : 2014-07-22 12:42:42 : &tempf=79.34&humidity=75&dewptf=72.45&windspeedmph=0.67&windgustmph=1.33&winddir=95&baromin=28.10&rainin=0.00&dailyrainin=0.00&softwaretype=phpLaxWeatherBro : returned:success
write weather underground : 2014-07-22 12:45:48 : &tempf=79.16&humidity=76&dewptf=72.59&windspeedmph=0.44&windgustmph=1.33&winddir=211&baromin=28.10&rainin=0.00&dailyrainin=0.00&softwaretype=phpLaxWeatherBro : returned:success
write weather underground : 2014-07-22 12:46:56 : &tempf=79.16&humidity=76&dewptf=72.59&windspeedmph=2.45&windgustmph=4.00&winddir=207&baromin=28.10&rainin=0.00&dailyrainin=0.00&softwaretype=phpLaxWeatherBro : returned:success
write weather underground : 2014-07-22 12:50:02 : &tempf=79.16&humidity=76&dewptf=72.59&windspeedmph=1.33&windgustmph=2.67&winddir=281&baromin=28.10&rainin=0.00&dailyrainin=0.00&softwaretype=phpLaxWeatherBro : returned:success
write weather underground : 2014-07-22 12:54:07 : &tempf=78.62&humidity=75&dewptf=71.77&windspeedmph=2.45&windgustmph=6.89&winddir=97&baromin=28.10&rainin=0.00&dailyrainin=0.00&softwaretype=phpLaxWeatherBro : returned:success
If you want to try something, set byte 0x14 of the 14:01 reply packet to 0. On mine, that changes the interval of the sensor data packet to 1 minute. For reference, the history interval setting in byte 0x1f of the same packet is 0x03 (15 minutes), and byte 0x11 of the 70:00 packet is 0xf0 (240 seconds). I believe this value sets the interval of the 00:70 "ping" packet, which I think is used as a keep-alive to maintain the connection.I can confirm the meaning of byte 0x14 in the 14:01 packet. I set mine to 1, 3 and 4 and got sensor data packets approximately every 2, 4 and 5 minutes.
Maybe my PHP code is old? I downloaded it from the GITHUB lowerpower and the code is about a month old.
https://github.com/lowerpower/LaCrosse (https://github.com/lowerpower/LaCrosse)
Are there updates available?
Dave
From what I know the 70:00 Packet only controls the gateway ping, not the weather station data flow. So you will get more packets, but not any more SDP packets with this setting.First, give credit where credit is due; keckec discovered that the 14:01 packet byte 0x14 controls the SDP flow.
I think kennkong is right about the SDP flow is based on the 14:01 packet.
Hmmm. I hadn't seen the GITHUB page. The code is older than what I'm using. I just posted a newer version of my request.breq at
http://www.keckec.com/weather/request.breq
Would someone care to arrange to send their data my way for a limited time? At first, I'd like to test getting data from an unsolicited station, to make sure that my code rejects it. Then I'd need to get some information (like the MAC address and serial number data that Lacrosse sends) so that I could set it up to accept data.OK, I'll bite. I sent you a PM.
I can forward the packets back to you, so that you don't lose any data. Any such test would only be for an hour or so, anyway. Any volunteers?
I need some brave souls to download, install and test the next version of SkySpy. Feedback is welcome!
Make sure you back up any existing installation and data before installing the new version.
Here is a link to the users manual. I recommend reading it prior to starting the installation. As usual, the installer will put another copy in your installation folder.
https://www.dropbox.com/s/6htjoyuxkgezia9/ReadMe2.pdf (https://www.dropbox.com/s/6htjoyuxkgezia9/ReadMe2.pdf)
Here is a link to the installer:
https://www.dropbox.com/s/4qpv7destypx726/SkySpyInstall.exe (https://www.dropbox.com/s/4qpv7destypx726/SkySpyInstall.exe)
# For advice on how to change settings please see
# http://dev.mysql.com/doc/refman/5.6/en/server-configuration-defaults.html
# *** DO NOT EDIT THIS FILE. It's a template which will be copied to the
# *** default location during install, and will be replaced if you
# *** upgrade to a newer version of MySQL.
[client]
port=3308
[mysqld]
# Remove leading # and set to the amount of RAM for the most important data
# cache in MySQL. Start at 70% of total RAM for dedicated server, else 10%.
innodb_buffer_pool_size = 128M
# Remove leading # to turn on a very important data integrity option: logging
# changes to the binary log between backups.
# log_bin
# These are commonly set, remove the # and set as required.
basedir = "C:\\mysql56\\"
datadir = "C:\\mysql56\\data\\"
port = 3308
#server_id = ....
# Remove leading # to set options mainly useful for reporting servers.
# The server defaults are faster for transactions and fast SELECTs.
# Adjust sizes as needed, experiment to find the optimal values.
join_buffer_size = 128M
sort_buffer_size = 2M
read_rnd_buffer_size = 2M
sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES
I need some brave souls to download, install and test the next version of SkySpy. Feedback is welcome!
Make sure you back up any existing installation and data before installing the new version.
Here is a link to the users manual. I recommend reading it prior to starting the installation. As usual, the installer will put another copy in your installation folder.
https://www.dropbox.com/s/6htjoyuxkgezia9/ReadMe2.pdf (https://www.dropbox.com/s/6htjoyuxkgezia9/ReadMe2.pdf)
Here is a link to the installer:
https://www.dropbox.com/s/4qpv7destypx726/SkySpyInstall.exe (https://www.dropbox.com/s/4qpv7destypx726/SkySpyInstall.exe)
After recovering from my brain fart the installation went smoothly without any issues.
I am happy to send you what it built, but I am not a MYSQL expert.
Can you tell me what to do to back it up?
I was using MYSQL on port 3308 and set your app to do the same.
The DB settings are:
# For advice on how to change settings please see
# http://dev.mysql.com/doc/refman/5.6/en/server-configuration-defaults.html
# *** DO NOT EDIT THIS FILE. It's a template which will be copied to the
# *** default location during install, and will be replaced if you
# Other default tuning values
# MySQL Server Instance Configuration File
# ----------------------------------------------------------------------
# Generated by the MySQL Server Instance Configuration Wizard
#
#
# Installation Instructions
# ----------------------------------------------------------------------
#
# On Linux you can copy this file to /etc/my.cnf to set global options,
# mysql-data-dir/my.cnf to set server-specific options
# (@localstatedir@ for this installation) or to
# ~/.my.cnf to set user-specific options.
#
# On Windows you should keep this file in the installation directory
# of your server (e.g. C:\Program Files\MySQL\MySQL Server X.Y). To
# make sure the server reads the config file use the startup option
# "--defaults-file".
#
# To run run the server from the command line, execute this in a
# command line shell, e.g.
# mysqld --defaults-file="C:\Program Files\MySQL\MySQL Server X.Y\my.ini"
#
# To install the server as a Windows service manually, execute this in a
# command line shell, e.g.
# mysqld --install MySQLXY --defaults-file="C:\Program Files\MySQL\MySQL Server X.Y\my.ini"
#
# And then execute this in a command line shell to start the server, e.g.
# net start MySQLXY
#
#
# Guildlines for editing this file
# ----------------------------------------------------------------------
#
# In this file, you can use all long options that the program supports.
# If you want to know the options a program supports, start the program
# with the "--help" option.
#
# More detailed information about the individual options can also be
# found in the manual.
#
# For advice on how to change settings please see
# http://dev.mysql.com/doc/refman/5.6/en/server-configuration-defaults.html
#
#
# CLIENT SECTION
# ----------------------------------------------------------------------
#
# The following options will be read by MySQL client applications.
# Note that only client applications shipped by MySQL are guaranteed
# to read this section. If you want your own MySQL client program to
# honor these values, you need to specify it as an option during the
# MySQL client library initialization.
#
[client]
no-beep
# pipe
# socket=mysql
port=3306
[mysql]
default-character-set=utf8
# SERVER SECTION
# ----------------------------------------------------------------------
#
# The following options will be read by the MySQL Server. Make sure that
# you have installed the server correctly (see above) so it reads this
# file.
#
# server_type=3
[mysqld]
# The next three options are mutually exclusive to SERVER_PORT below.
# skip-networking
# enable-named-pipe
# The Pipe the MySQL Server will use
# socket=mysql
# The TCP/IP Port the MySQL Server will listen on
port=3306
# Path to installation directory. All paths are usually resolved relative to this.
# basedir="C:/Program Files/MySQL/MySQL Server 5.6/"
# Path to the database root
datadir="C:/ProgramData/MySQL/MySQL Server 5.6/data\"
# The default character set that will be used when a new schema or table is
# created and no character set is defined
# The default storage engine that will be used when create new tables when
default-storage-engine=INNODB
# Set the SQL mode to strict
sql-mode="STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"
# Enable Windows Authentication
# plugin-load=authentication_windows.dll
# General and Slow logging.
log-output=NONE
general-log=0
general_log_file="WOLVERINE.log"
slow-query-log=0
# Binary Logging.
# log-bin
# Error Logging.
log-error="WOLVERINE.err"
# The maximum amount of concurrent sessions the MySQL server will
# allow. One of these connections will be reserved for a user with
# SUPER privileges to allow the administrator to login even if the
# connection limit has been reached.
max_connections=151
# Query cache is used to cache SELECT results and later return them
# without actual executing the same query once again. Having the query
# cache enabled may result in significant speed improvements, if your
# have a lot of identical queries and rarely changing tables. See the
# "Qcache_lowmem_prunes" status variable to check if the current value
# is high enough for your load.
# Note: In case your tables change very often or if your queries are
# textually different every time, the query cache may result in a
# slowdown instead of a performance improvement.
query_cache_size=0
# The number of open tables for all threads. Increasing this value
# increases the number of file descriptors that mysqld requires.
# Therefore you have to make sure to set the amount of open files
# allowed to at least 4096 in the variable "open-files-limit" in
# section [mysqld_safe]
table_open_cache=2000
# Maximum size for internal (in-memory) temporary tables. If a table
# grows larger than this value, it is automatically converted to disk
# based table This limitation is for a single table. There can be many
# of them.
tmp_table_size=118M
# How many threads we should keep in a cache for reuse. When a client
# disconnects, the client's threads are put in the cache if there aren't
# more than thread_cache_size threads from before. This greatly reduces
# the amount of thread creations needed if you have a lot of new
# connections. (Normally this doesn't give a notable performance
# improvement if you have a good thread implementation.)
thread_cache_size=10
#*** MyISAM Specific options
# The maximum size of the temporary file MySQL is allowed to use while
# recreating the index (during REPAIR, ALTER TABLE or LOAD DATA INFILE.
# If the file-size would be bigger than this, the index will be created
# through the key cache (which is slower).
myisam_max_sort_file_size=100G
# If the temporary file used for fast index creation would be bigger
# than using the key cache by the amount specified here, then prefer the
# key cache method. This is mainly used to force long character keys in
# large tables to use the slower key cache method to create the index.
myisam_sort_buffer_size=226M
# Size of the Key Buffer, used to cache index blocks for MyISAM tables.
# Do not set it larger than 30% of your available memory, as some memory
# is also required by the OS to cache rows. Even if you're not using
# MyISAM tables, you should still set it to 8-64M as it will also be
# used for internal temporary disk tables.
key_buffer_size = 25M
# Size of the buffer used for doing full table scans of MyISAM tables.
# Allocated per thread, if a full scan is needed.
read_buffer_size=64K
read_rnd_buffer_size=256K
# This buffer is allocated when MySQL needs to rebuild the index in
# REPAIR, OPTIMZE, ALTER table statements as well as in LOAD DATA INFILE
# into an empty table. It is allocated per thread so be careful with
# large settings.
sort_buffer_size=256K
#*** INNODB Specific options ***
# innodb_data_home_dir=0.0
# Use this option if you have a MySQL server with InnoDB support enabled
# but you do not plan to use it. This will save memory and disk space
# and speed up some things.
# skip-innodb
# Additional memory pool that is used by InnoDB to store metadata
# information. If InnoDB requires more memory for this purpose it will
# start to allocate it from the OS. As this is fast enough on most
# recent operating systems, you normally do not need to change this
# value. SHOW INNODB STATUS will display the current amount used.
innodb_additional_mem_pool_size = 47M
# If set to 1, InnoDB will flush (fsync) the transaction logs to the
# disk at each commit, which offers full ACID behavior. If you are
# willing to compromise this safety, and you are running small
# transactions, you may set this to 0 or 2 to reduce disk I/O to the
# logs. Value 0 means that the log is only written to the log file and
# the log file flushed to disk approximately once per second. Value 2
# means the log is written to the log file at each commit, but the log
# file is only flushed to disk approximately once per second.
innodb_flush_log_at_trx_commit=1
# The size of the buffer InnoDB uses for buffering log data. As soon as
# it is full, InnoDB will have to flush it to disk. As it is flushed
# once per second anyway, it does not make sense to have it very large
# (even with long transactions).
innodb_log_buffer_size=9M
# InnoDB, unlike MyISAM, uses a buffer pool to cache both indexes and
# row data. The bigger you set this the less disk I/O is needed to
# access data in tables. On a dedicated database server you may set this
# parameter up to 80% of the machine physical memory size. Do not set it
# too large, though, because competition of the physical memory may
# cause paging in the operating system. Note that on 32bit systems you
# might be limited to 2-3.5G of user level memory per process, so do not
# set it too high.
innodb_buffer_pool_size=755M
# Size of each log file in a log group. You should set the combined size
# of log files to about 25%-100% of your buffer pool size to avoid
# unneeded buffer pool flush activity on log file overwrite. However,
# note that a larger logfile size will increase the time needed for the
# recovery process.
innodb_log_file_size=48M
# Number of threads allowed inside the InnoDB kernel. The optimal value
# depends highly on the application, hardware as well as the OS
# scheduler properties. A too high value may lead to thread thrashing.
innodb_thread_concurrency = 10
# The increment size (in MB) for extending the size of an auto-extend InnoDB system tablespace file when it becomes full.
innodb_autoextend_increment=64
# The number of regions that the InnoDB buffer pool is divided into.
# For systems with buffer pools in the multi-gigabyte range, dividing the buffer pool into separate instances can improve concurrency,
# by reducing contention as different threads read and write to cached pages.
innodb_buffer_pool_instances=8
# Determines the number of threads that can enter InnoDB concurrently.
# Specifies how long in milliseconds (ms) a block inserted into the old sublist must stay there after its first access before
# it can be moved to the new sublist.
innodb_old_blocks_time=1000
# It specifies the maximum number of .ibd files that MySQL can keep open at one time. The minimum value is 10.
innodb_open_files=300
# When this variable is enabled, InnoDB updates statistics during metadata statements.
innodb_stats_on_metadata
# When innodb_file_per_table is enabled (the default in 5.6.6 and higher), InnoDB stores the data and indexes for each newly created table
# in a separate .ibd file, rather than in the system tablespace.
innodb_file_per_table=1
# Use the following list of values: 0 for crc32, 1 for strict_crc32, 2 for innodb, 3 for strict_innodb, 4 for none, 5 for strict_none.
innodb_checksum_algorithm=0
# The number of outstanding connection requests MySQL can have.
# This option is useful when the main MySQL thread gets many connection requests in a very short time.
# It then takes some time (although very little) for the main thread to check the connection and start a new thread.
# The back_log value indicates how many requests can be stacked during this short time before MySQL momentarily
# stops answering new requests.
# You need to increase this only if you expect a large number of connections in a short period of time.
# If this is set to a nonzero value, all tables are closed every flush_time seconds to free up resources and
# synchronize unflushed data to disk.
# This option is best used only on systems with minimal resources.
# The minimum size of the buffer that is used for plain index scans, range index scans, and joins that do not use
# indexes and thus perform full table scans.
join_buffer_size=256K
# The maximum size of one packet or any generated or intermediate string, or any parameter sent by the
# mysql_stmt_send_long_data() C API function.
max_allowed_packet = 160M
# If more than this many successive connection requests from a host are interrupted without a successful connection,
# the server blocks that host from performing further connections.
# Changes the number of file descriptors available to mysqld.
# You should try increasing the value of this option if mysqld gives you the error "Too many open files".
open_files_limit=4161
# Set the query cache type. 0 for OFF, 1 for ON and 2 for DEMAND.
query_cache_type=0
# If you see many sort_merge_passes per second in SHOW GLOBAL STATUS output, you can consider increasing the
# sort_buffer_size value to speed up ORDER BY or GROUP BY operations that cannot be improved with query optimization
# or improved indexing.
sort_buffer_size=256K
# The number of table definitions (from .frm files) that can be stored in the definition cache.
# If you use a large number of tables, you can create a large table definition cache to speed up opening of tables.
# The table definition cache takes less space and does not use file descriptors, unlike the normal table cache.
# The minimum and default values are both 400.
table_definition_cache=1400
# Specify the maximum size of a row-based binary log event, in bytes.
# Rows are grouped into events smaller than this size if possible. The value should be a multiple of 256.
binlog_row_event_max_size=8K
# If the value of this variable is greater than 0, a replication slave synchronizes its master.info file to disk.
# (using fdatasync()) after every sync_master_info events.
# If the value of this variable is greater than 0, the MySQL server synchronizes its relay log to disk.
# (using fdatasync()) after every sync_relay_log writes to the relay log.
# If the value of this variable is greater than 0, a replication slave synchronizes its relay-log.info file to disk.
# (using fdatasync()) after every sync_relay_log_info transactions.
secure-auth = off
net_buffer_length = 2M
net_write_timeout = 1800
wait_timeout = 1800
basedir = "C:/Program Files/MySQL/MySQL Server 5.6"
interactive_timeout = 28800
innodb_lock_wait_timeout = 10
net_read_timeout = 1800
performance_schema = off
Anyway to get the data from the old database (weather) into the new (weather2) ??
I'm on my own server, I'll send you the backup later today. Everything seems to be working great since I remembered to uninstall first.Anyway to get the data from the old database (weather) into the new (weather2) ??
If you are using a full-up MySQL database engine, then yes. Back it up and send it to me and I will translate it to the new format. Are you still on my server?
Otherwise you can view/download your historical data from Weatherunderground.
I finally got around to trying some of this code, and used what I think was the latest snapshot of keckec's as well as kennkong. I couldn't get either one to work out of the box :( but after some cajoling I got the keckec stuff to mostly work -- I was missing the schema for the rain history table, and it doesn't seem to ever record any of the historical min/maxes (code missing for the most part), but at least there's sensorvalues getting into the DB!Sorry my php/schema isn't fully working. I'm sort-of feeling my way along, as this is the first time I've worked with PHP or SQL. The db schema has changed substantially several times, as I learn more.
I do think it'd be really great if we could all agree to use a versionable repo like github to share stuff through, it seems as though there's at least 3 php forks going now, all with slightly different featuresets :( I like the features that kennkong seems to have (WUG posting, passthrough to Lacrosse, simple charting), but the schema seems to have diverged somewhere, for one thing. :(I don't mind using github, and I currently use git with my own repo. So far my code is rough, and as you found out a lot of it doesn't work very well yet. I don't plan to send to WU, but store data for myself and a few friends, and provide web pages to view graphs, etc. I've been saving captures of all the packets to and from the station, and so far have about 500K packets. Right now I'm working on php code to import it into the db, which I doubt would be of much interest to others.
I was missing the schema for the rain history table, and it doesn't seem to ever record any of the historical min/maxes (code missing for the most part), but at least there's sensorvalues getting into the DB!I gather from context that you're talking about keckec's version of historical values, but it does bring up a point about my version that may not be clear. My `records` table must be prepopulated with the records you want to keep, the request script only updates existing records. It doesn't create missing ones. This is because certain records like minimum wind and rainfall are useless, so why keep them?
I do think it'd be really great if we could all agree to use a versionable repo like github to share stuff through, it seems as though there's at least 3 php forks going now, all with slightly different featuresets :( I like the features that kennkong seems to have (WUG posting, passthrough to Lacrosse, simple charting), but the schema seems to have diverged somewhere, for one thing. :(I've never used github or any other repository before, but I'm not opposed to using any particular one. In the meantime, I've updated my code weather.tgz (http://1drv.ms/1kbzfFU) I've reconfigured everything to reside in one directory, which on my system I've set up as a virtual host. These should work in the root directory of a web server, too. As I've said before, I'm a total newb at web services, so these are hardly shining examples of best practices. Any suggestions for improvement are welcome.
I really appreciate all the work everyone's put into this effort! I wish I had more time to contribute.
Kenn, thanks a lot for this, I'm making some progress getting your stuff to work for me.I updated weather.sql to pre-populate the sensors table. I added a file records.sql which has a script to populate the records table after you have at least one sensor reading
However, PLEASE include the data dump for the 'sensors' table, and any others that have "generic" data! Pretty tricky to figure out what is supposed to populate those...
Edit: fixuprain() still not working properly for me; commented out the call to it, for now.Looking more carefully at the code, fixuprain() might need an existing record for the last rain reset date in the sensordatevalues table to work.
I also didn't have an admin@localhost user on my mysql install, so the views didn't work; I adjusted them to be the right user but maybe setting SQL SECURITY INVOKER would be a better solution.I didn't check the generated schema script closely enough.
Also had to change the HTTP-IDENTIFY to be HTTP_IDENTIFY (underscore vs hyphen). Not sure why on your GW it (apparently!) sends a hyphen...?The problem is not with my gateway, it's with my webserver. It doesn't have apache_request_headers() built-in, so I borrowed some code to create one. That code changes the underscores to hyphens for some reason. If your server has apache_request_headers() that leaves the underscores unchanged, well, how am I supposed to know that? Remember, total webserver newb here.
How large are the data packets sent from the C84612 gateway to the La Crosse Alerts site?
I'm having an issue with SkySpy working on WIN7 Ultimate. The program won't communicate with the gateway if I have the Windows firewall turned on for the local or private network. If I turn it off everything works OK. I have looked the firewall application rules and can see that ssmonitor.exe is listed in the 'incoming' rules, but I don't see an entry in the 'outgoing' rules. Any ideas?
-Skydvrz, I think you have a typo in the user manual when refering to the weather station as model C86412 instead of C84612.
I'm using the latest version of SkySpy configured with the internal DB.
I thought I had added SkySpyService.exe to the firewall program list during troubleshooting, but when I checked again it wasn't there. After adding it, it was listed as 'C86412 Gateway Interface and Web Server' (C84612). Both the sensor data and web server are now working with Windows 'private networks' firewall turned on.
Is adding this entry to Windows Firewall something that should happen during install or does it need to be done manually?
I do have hardware firewall and load balancing hardware between my LAN and the Internet.
Update: When I switched back to the WIN7 PC a 2nd time I did some get 'Special SDP= 210' for awhile. Now I'm get an occasional 'Special SDP-30, but the sensor values & WU are updating.
Should I reset the C84612 by removing the batteries?
The blinking led means it's not connecting to the sky spy service. Are you sure you reset to gateway to the correct in?
When the gateway is pointed at the XP system the LCD "Internet" icon was flashing or blinking. While connected to the WIN7 system it is a steady on.
I switched back to the XP system and the Special SDP=210 continued for over 4 hours and never did correct. I then switched back to WIN7 and had the 210 message about 20 times before the sensors updated and the =210 stopped.
I powered cycled the gateway & LCD while on XP and it had no effect. I keep thinking it's something simple or oblivious. :?
I don't want to load wireshark and dig in to the nuts & bolts to see what's different if I don't need to.
The blinking led means it's not connecting to the sky spy service. Are you sure you reset to gateway to the correct in?
When the gateway is pointed at the XP system the LCD "Internet" icon was flashing or blinking. While connected to the WIN7 system it is a steady on.
Why are you trying to run it on an XP box?The XP box was a low power Acer R1600 thin-client that is used for solar data logging task and had been running HeavyWeather along with WUHU for a years.
This is "banging the rocks together" quality work, so if anyone wants to offer any improvements, it would be welcome.
My firmware version is 1.21.00, compiled on 7/4/08 (from the GW's web page). I'm curious what version others have.Ditto.
I just found a way to solve problem #2 (described in the previous post).
I found the C:\ProgramData\SkySpyData\SkySpy.ini file and manually changed the "DBEmbedded" value from 0 to 1. The monitor no longer tries to connect to database with every menu pick.
1) I can't get the Gateway talking to the SkySpy service. Here are the steps I'm following:
A) I did a factory reset on the Gateway just to be sure I'm starting from scratch
B) I got the gateway working and reporting data to LacrosseAlerts.com (I can see it updating on the website just fine)
C) With the SkySpy service running (but with the SkySpy monitor not opened yet...)
i) Run Gateway Advanced Setup
a) Change the "www.proxyserver.de" to match the PC-IP
b) Change the port to 8000
c) Check the "Use" box
d) Leave the "Use DHCP" box checked
e) Changed the "Gateway" and "DNS IP" to my router's IP (192.168.0.1)
NOTE: I didn't change the IP or Netmask addresses (see attached screen-shot)
f) Click Set
g) Click Reboot
After the reboot, the Green RF light flashes continuously for several seconds then stops. "Internet" on the weather display turns off at this point.
I discovered this thread this morning, and read the entire thing.
So, my million dollar question is whether SkySpy would have any applicability to a simple source such as the TX60-U, which is 2 temps and humidity only.
I won't be near a station setup to test this for another few days, but I am excited that I might be able to use WUnderground instead of the clunky Weather Direct site, and the spotty Lacrosse pay site.
skydvrz: Is the version you posted on July 25 the most current? And is it now recommended over 1.1.0.72? Thanks!
skydvrz: Is the version you posted on July 25 the most current? And is it now recommended over 1.1.0.72? Thanks!
Is that you filling up my bug reporting system with error reports? :grin:
Follow the instruction manual for Embedded mode. That should fix it.
Thanks for the reply! More urgent for me would be figuring out question #1 described in my post (3 posts up).
I've tried everything and can't get SkySpy talking to the C84612 weather station.
Thanks,
--Doug
Looking at the DHCP client list for my router, the gateway always keeps its ip address no matter what the Advanced Gateway Setup uses. I suppose that's normal. What is odd that a random device "LaCrosse_Weather_Gateway" shows up, sometimes with its own ip address. When it does that the mac address is always different from the gateway by 1 character at the end. Other times it simply renames another device on the network. (The other device continues to function fine.)
Looking at the DHCP client list for my router, the gateway always keeps its ip address no matter what the Advanced Gateway Setup uses. I suppose that's normal. What is odd that a random device "LaCrosse_Weather_Gateway" shows up, sometimes with its own ip address. When it does that the mac address is always different from the gateway by 1 character at the end. Other times it simply renames another device on the network. (The other device continues to function fine.)
Your Gateway is simply grabbing new IP addresses from your DHCP server (usually your firewall/router/WiFi Access Point). It is OK for the Gateway address to shift around, as long as it can find your SkySpy PC on your LAN. The Gateway initiates all network conversations and the SkySpy PC simply replies back to the sender's address.
The thing that could be messing you up is if your SkySpy PC has a DHCP-assigned address. Is your current IP address for your SkySpy PC the same as the one you entered into your Gateway?
Your PC's address may shift around when your "DHCP lease" expires, when you reset your router and for other reasons. Normally this is not a problem, but if another device on your LAN expects your PC to be at a certain address - and it is not - then bad things will happen. The Gateway won't be able to find your PC and send it packets.
So, to cut down the crazyness factor, you may need to use a static IP address on your PC.
Most routers allow you to set up a block of static IP addresses that the built in DHCP server will avoid. Conversely, some routers allow you to set up the range of DHCP addresses; The remaining ones are for use with static assignments.
You put things like printers, web servers, PCs and other network appliances in the router's static address range with fixed addresses.
I use static IP addresses for all of my computers here at my house. I only use DHCP for smartphones and my Gateway module.
I am new to this and WAY over my head, but I seem to have the same issue as flamand. When I change the IP address to point to my SkySpy computer, the Internet icon goes away and the reporting stops going to the LacrosseAlert page and is never seen by Sky Spy Monitor.
I used the latest version of SkySpyInstaller posted in this thread. I am running Win7.
Do I need to install mySQL if using the embedded database?
I'm still trying to figure out why no data is going to skyspy. Could anyone who has it working tell me whether you get data pinging a gateway's original ip address while it's going through a proxy? I mean, if GAS has the gateway (192.168.1.111) using the skyspy pc as proxy (192.168.1.222), what happens when you ping 192.168.1.111?
I have my gateway set to use a proxy and can ping it from other machines on my home network. The gateway also has a web server listening on port 80, so you should be able to point a browser to its IP address and see some gateway info. That may not prove much though, since the problem is likely going the other way -- from the GW to the skyspy machine. If you have a firewall on your skyspy machine it's probably only blocking incoming connections. I don't use Windows so I doubt I'll be much help with firewall issues.
If you have another computer on your local network you could try connecting from it to the skyspy machine using telnet. Use whatever the skyspy machine's IP address is and whatever port skyspy is listening on.
If you have another computer on your local network you could try connecting from it to the skyspy machine using telnet. Use whatever the skyspy machine's IP address is and whatever port skyspy is listening on.
Use Proxy Yes
Proxy Server Name 192.168.1.10
Proxy Port 80
Proxy Server IP 192.168.1.10
Last contact 7915959800
My ERF gateway page is different from keckec's in the previous message in that there is no entry in the line for "proxy server ip". Should that be populated when GAS is set to use a proxy? Would that mean that there's a problem with how GAS is working in my network vs a problem in the skyspy service?Read page 4 of the users guide (readme2.pdf) It has to be populated.
I have my gateway set to use a proxy and can ping it from other machines on my home network. The gateway also has a web server listening on port 80, so you should be able to point a browser to its IP address and see some gateway info. That may not prove much though, since the problem is likely going the other way -- from the GW to the skyspy machine. If you have a firewall on your skyspy machine it's probably only blocking incoming connections. I don't use Windows so I doubt I'll be much help with firewall issues.
If you have another computer on your local network you could try connecting from it to the skyspy machine using telnet. Use whatever the skyspy machine's IP address is and whatever port skyspy is listening on.
When I point my browser to the gateway's ip and the gateway is configured to use the spysky pc as the proxy, the proxy name shows the spysky pc's ip address and port but the proxy ip is empty (0.0.0.0) and the last contact line says "no contact". Is that correct?
My ERF gateway page is different from keckec's in the previous message in that there is no entry in the line for "proxy server ip". Should that be populated when GAS is set to use a proxy? Would that mean that there's a problem with how GAS is working in my network vs a problem in the skyspy service?Read page 4 of the users guide (readme2.pdf) It has to be populated.
Sorry ...I was unclear.
I ran Gateway Advanced Server. The proxyserver field was set to be the spysky pc's ip, using port 8000. Then I clicked the set and reboot boxes and then exited GAS.
I opened a web browser at pointed it to the spysky pc's ip. In the third group of information, at the end I see:
Proxy Server Name 192.168.115
Proxy Port 8000
Data Server IP 0.0.0.0
Last contact no contact
Somehow the Data Server IP is not being set and I suspect that's consistent with spysky not receiving any data.
Sorry ...I was unclear.
I ran Gateway Advanced Server. The proxyserver field was set to be the spysky pc's ip, using port 8000. Then I clicked the set and reboot boxes and then exited GAS.
I opened a web browser at pointed it to the spysky pc's ip. In the third group of information, at the end I see:
Proxy Server Name 192.168.115
Proxy Port 8000
Data Server IP 0.0.0.0
Last contact no contact
Somehow the Data Server IP is not being set and I suspect that's consistent with spysky not receiving any data.
You are sure that after you changed the data with GAS you clicked on SET, waited and then clicked on REBOOT.
Proxy Server Name 192.168.115
Proxy Port 8000
Data Server IP 0.0.0.0
Last contact no contact
Somehow the Data Server IP is not being set and I suspect that's consistent with spysky not receiving any data.
Proxy Server Name 192.168.115
Proxy Port 8000
Data Server IP 0.0.0.0
Last contact no contact
Somehow the Data Server IP is not being set and I suspect that's consistent with spysky not receiving any data.
I think the GW might not fill in the Data Server IP field until it makes a connection. In my setup the GW connects to a web server with php scripts to save data and keep the GW happy.
I'll try disabling the web server and cycle power on the GW. Then I'll look at its web page to see if/when the Data Server IP and Last Contact fields get filled in.
Proxy Server Name 192.168.115
Proxy Port 8000
Data Server IP 0.0.0.0
Last contact no contact
Somehow the Data Server IP is not being set and I suspect that's consistent with spysky not receiving any data.
Proxy Server Name 192.168.121Is 192.168.121 the full IP address you entered? This looks incomplete. It should have four numbers separated by three periods.
But I still do not get any data reflected on the SkySpy Monitor. :sad:
And the Internet icon is not displayed.
Sorry missed a .1.OK. I was thinking if you only entered three numbers into GAS, it could have been the problem.
It should have been:
192.168.1.121
Nothing came threw initially, because I had stopped re-directing data with GAS. After going into GAS and using the 192.168.1.121 address, data starting showing up in Wireshark!!! What does tell me?All the traffic is going one way. It appears skyspy is not replying. I think it still could be a firewall issue, where skyspy is not seeing the packets from the GW, or its reply is being blocked. Does skyspy keep a log that might tell if it sees anything?
I've attached a screenshot of what I was seeing. Is png the preferred graphic format?
Nothing came threw initially, because I had stopped re-directing data with GAS. After going into GAS and using the 192.168.1.121 address, data starting showing up in Wireshark!!! What does tell me?All the traffic is going one way. It appears skyspy is not replying. I think it still could be a firewall issue, where skyspy is not seeing the packets from the GW, or its reply is being blocked. Does skyspy keep a log that might tell if it sees anything?
I've attached a screenshot of what I was seeing. Is png the preferred graphic format?
Can you think of another way to look for a firewall problem?
I've thought about another test using an ethernet crossover cable to connect the gateway directly to the skyspy pc and let the pc get internet connectivity via wireless. i'm sure it's more involved than just plugging in a cable though.
Can you think of another way to look for a firewall problem?
I've thought about another test using an ethernet crossover cable to connect the gateway directly to the skyspy pc and let the pc get internet connectivity via wireless. i'm sure it's more involved than just plugging in a cable though.
Could you copy and paste all the info from the GW's web page into a reply to this thread, or post a screen shot. Or if you'd rather, send it in a PM to me. I want to check the rest of the fields. Thanks.
These are for with and without using a proxy.I think the problem is the proxy server name field doesn't have enough numbers in the IP.Can you think of another way to look for a firewall problem?
I've thought about another test using an ethernet crossover cable to connect the gateway directly to the skyspy pc and let the pc get internet connectivity via wireless. i'm sure it's more involved than just plugging in a cable though.
Could you copy and paste all the info from the GW's web page into a reply to this thread, or post a screen shot. Or if you'd rather, send it in a PM to me. I want to check the rest of the fields. Thanks.
I think the problem is the proxy server name field doesn't have enough numbers in the IP.
Glad it's working. I can't tell you how many times I've done that sort of thing.QuoteI think the problem is the proxy server name field doesn't have enough numbers in the IP.
Good old user error. I have "looked" at that screen so many times over the past couple of weeks and cannot believe I missed it. Weather Underground is getting data now and I couldn't be happier.
Thank you so very much!!!
We Central Floridians got our first "cold snap" of the year last night. It got down to 39 F, giving me the first real opportunity to examine the wind chill numbers in the sensor data packets (nybble offset 111, length 3). Although winds were quite light (< 3 mph, gusts to 7), there should have been some difference between the current outside temp (offset 75, length 3) but there wasn't. Can anyone confirm that their station is outputting a wind chill less than the outside temp?
Update: My research into how wind chill is calculated shows that calculations aren't valid for wind speeds less than 3 mph (NOAA Wind Chill Chart (http://www.crh.noaa.gov/ddc/?n=windchill)). However, I checked my data and found a few data points above 3. Of course, I have no idea what calculations LaCrosse is performing.
I originally found this field by doing a check through all my collected station packets, looking at the difference between current outside temp at offset 75 and the (then unknown) value at offset 111. I found the value at 111 was lower only when it was both windy and cold, and never higher than the outside temp. I didn't do any calculations on the values, and it could be something else.Your climate is much more likely to experience wind chill than mine, but I'll keep an eye on it this winter. Last winter was extremely mild even by Central Florida standards. As I recall, it only dropped below 40 F for a few days. I haven't tried to find the long range forecast for this winter, but I certainly don't want one like we had in 1982-3 just to check the functionality of my weather station.
I tried some things based on what I found in this thread. Here's the update...
It does not seem to be updating the LaCrosse website any more. Is this because SkySpy intercepts the data?
The PC-IP I get is 192.168.1.64 This seems to be the IP of the laptop I'm running SkySpy on.
When I point a browser at that IP address I get my "WiRNS" page (a utility for talking to my ReplayTV).
The "Actual IP" shown in GAS is 192.168.1.71 When I point a browser at that IP address I get the data shown in the attachment below.
Thanks very much for the response. When I added the ":8000" that solved that problem. I now see the attached when I point my browser to that address.
And each time I do point my browser to that address I get one record of activity in the SkySpy monitor - as in the 2nd attachment.
So I pretty clearly messed up my ribbon somehow. Last night I did see all the normal icons - today I don't. I uninstalled SkySpy monitor and re-installed just now. Still no luck. Then I tried customizing the ribbon. I found some of the settings that were missing but they now appear under a new tab "RibbonTab1". I do have "embedded" checked. If you can tell me how to do a "factory reset" on SkySpy I'll do that.
I think I've managed to reconfigure my ribbon properly. I do have "embedded" checked - but still not activity except when I open a browser window to http://localhost:8000 (in which case I get one activity record).
You somehow figured out a way to trash your Monitor registry entry.
Are you sure that you have GAS set up to send data to your IP (proxy settings)?
In an earlier post you mentioned that you were playing with GAS again.
Do not reset your Internet Gateway module either by pushing its button.
Now that I'm home I'm able to capture a screen grab from the Gateway Advanced Setup. The first image shows the exact configuration I see when I hit Set and then Reboot.
The second grab shows the alternate PC-IP in the drop-down box. But you can see that everything else is either blank or zero when I select that - so I don't.
I hope this is of some help. I'm kind of tempted to re-register to the LaCrosse site since I may have messed that up - but I think I'll wait to hear from you before making a bigger mess.
Hello dear friends
I am new in this forum just acquire two stations this model c84612 in america and live in the Pantanal of Brazil
Excuse me for my English but ...
Would I like to help using the SkySpy and this ERF-100 gateway accompanying, ie how do the pc configuration and network and gateway, you need to be on the same network this server or not? It should set the router's ip address?
Ie like the step-by-step instructions on using some manual or about
Please if you can send email thank
gpiveta@ig.com.br
grateful
Gustavo
Hello dear friends
I am new in this forum just acquire two stations this model c84612 in america and live in the Pantanal of Brazil
Excuse me for my English but ...
Would I like to help using the SkySpy and this ERF-100 gateway accompanying, ie how do the pc configuration and network and gateway, you need to be on the same network this server or not? It should set the router's ip address?
Ie like the step-by-step instructions on using some manual or about
Please if you can send email thank
gpiveta@ig.com.br
grateful
Gustavo
Everything you need is in the SkySpy forum. Latest version and setup guide.
Here's the link to the forum and post #100 has the latest version.
http://www.wxforum.net/index.php?topic=24882.0
I replaced the flash chip with a Macronix MX25L2006E, did a factory reset and re-registration, and it's all working again.