WXforum.net
Weather Software => RaspberryPI Weather Software => Topic started by: mikez104 on April 25, 2015, 11:16:53 AM
-
Hi all. This is my first post on this forum. I had a Davis weather monitor II for about 4 or 5 years and it died. That was about 5 years ago. I have always wanted to set up another station but didn't have the $$ to get another Davis so I now have an acurite 02032C and 5in1 and the acurite bridge.
This is my current setup
02032C - Just sits on the desk. Not attached to anything
Bridge - attached to Raspberry Pi 2 model B via usb ethernet adapter
Raspi - running wheezy 2015-02-16.
Packet grabbing software (if thats what you call it) - ipwx from nincehelser.com/ipwx
weather software - weewx 2.5.0-1 I should upgrade to the latest version.
Sorry for the long winded intro but wanted to provide as much info as I could. Here are my questions.
- I'd like to give the Raspi a static IP so I can open up a port on my router to access the weewx web page but am not familiar with what we did with the port bridging in /etc/network/interfaces. Here is how it looks.
auto lo br0
iface lo inet loopback
iface eth0 inet manual
iface eth1 inet manual
iface br0 inet dhcp
bridge_ports eth0 eth1
allow-hotplug wlan0
iface wlan0 inet manual
wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf
iface default inet dhcp
When I do an ifconfig I see my ip address is assigned to br0. I'm not sure if I just change br0 to static or what?
- Second question is can I send my updates to Weather Underground more often? I see there is a new ipwxLite version out that sends frequent updates to WU directly from that program but in the weewx config file it does not seem to have any adjustment. It looks like it sends the data every 5 minutes.
Besides that, the system seems to be solid for the couple of days I have had it going. Any help would be great.
Thanks
Mike
-
I haven't tried setting br0 to static, but I can't see why that wouldn't work.
An alternative is to make a reservation in your DHCP server so that the same IP is assigned to that MAC.
As for the latest weewx version, there were some changes made that require a new driver. I've got one that works on the latest version of weewx, but it's still got a bug I need to fix... basically it's just a file-contention issue... ipwx is writing the file at the same time weewx is trying to read it, so weewx doesn't get a valid reading and aborts. It's an annoyance that pops up once in a while, but not enough to drive me to sit down and fix it. :? Basically a cleaner driver should be written, but my Python needs work.
As to the 5-minute setting, that's a function of weewx. It can be changed in the weewx.conf file if I remember correctly. I set mine to 1-minute. The latest version of weewx has a "rapid-fire" option, but I'm not sure it's compatible with my driver.
-
Yup, that driver definitely didn't work :-). I had upgraded to the newest version of weewx right after I made that post and now it's broke. #-o Rather than uninstall and try and reinstall an older version, would you be willing to let me use the driver that has the bug? I can handle an occasional crash. As for Python, I know nothing. I can do some scripting but I'm sure it is very ugly by the standards of someone who knows what they are doing but I can usually find a way to make things work by doing workarounds.
I changed br0 to a static ip and it works fine.
-
I put the beta driver up on my site and you can grab it with:
wget http://nincehelser.com/ipwxcode/simulator.pie
You'll need to rename it "simulator.py". My web host wants to interpret the ".py" so I had to rename it.
Note that this driver assumes wxdata is at: /home/pi/ipwx/wxdata If you put yours somewhere else, you'll need to alter it in the driver.
-
Cool, I'll download it in a bit. And yeah, I ran into the path thing last time because I put everything in the home directory of user ipwx but that was easy to figure out. Thanks! I'll let you know how it goes.
-
Got it going and it is working fine. Thanks again.
I looked in weewx.conf for the upload to WU frequency but only found the rapid fire setting. I turned that on. Not sure how that will work out since the 5 in 1 only updates like every 18 seconds. We'll see.
I have some bad data from today. Do you know how I can purge that? I cant tell if it is using mysql or sqlite.
I'd also like to get a url. I have to do some looking around I guess.
-
Got it going and it is working fine. Thanks again.
I looked in weewx.conf for the upload to WU frequency but only found the rapid fire setting. I turned that on. Not sure how that will work out since the 5 in 1 only updates like every 18 seconds. We'll see.
I have some bad data from today. Do you know how I can purge that? I cant tell if it is using mysql or sqlite.
I'd also like to get a url. I have to do some looking around I guess.
What I was thinking of in weewx.conf was archive_interval. That sets how often data is saved to the database and reported. Like I said, I don't know if the "rapid fire" option will work with the driver. Let me know what you find out.
"Rapid Fire" doesn't have any set frequency. Wunderground will accept anything down to 2.5 seconds.
I believe it is using sqlite. Anyway, you can purge the entire database by removing /var/lib/weewx/weewx.sdb. When you restart weewx, it will start a new database. This is a quick way to start a fresh database once you've got everything squared away.
I'm not sure what you mean by a URL, but in weewx.conf you can set HTML_ROOT where you want it. Mine is set to /var/www.
I have avahi and bonjour set up so I can type http://weather.local to be automatically directed to the weewx pages. It works nicely, but you have to install iTunes on Windows to easily get bonjour functionality. Apple doesn't have bonjour split out as a stand-alone package. Oh, you also have to enable ipV6 on the pi for that to work. I plan to cover that as options on the new write-up.
-
With rapid fire on, I did not see anything saying that it was posting to WU. IDK, I turned it off anch changes the archive_interval to 60 seconds. After I did that I can see that it is posting to WU every minute but the weird thing is that WU is only showing that I am updating it at 5 minute intervals. Do they just throw out the extra data? That's pretty beat.
I blew out the database and it created the clean new one like you said. Sounds like you've been doing this for a while and know your stuff. Thanks for your help.
When I said URL I meant like a domain name. I just signed up on no-ip.com for the free dynamic DNS. I still have to set up my router to allow access to the raspi. I get kinda nervous about that... Maybe just allow port 80? I did it a while back for some other projects I was working on and didn't have any problems though.
-
"Rapid Fire" is Weather Underground terminology. I'm not sure if they've trademarked it. They're the only hardware-independent service I know of that accepts data that quickly.
The purpose is to drive animated web widgets with near real-time data, especially for the wind readings. For archival purposes, it seems they aggregate data to 5-minute intervals as you've already noticed. I assume the high-resolution data is tossed after it is processed, but I can't say for sure.
You'd want port 80 open for sure. Perhaps 443 if you plan to do anything with https. Port 22 is also a good one to open if you need SSH access from the outside.
If you're worried about people having direct access to your interior network, you could have your domain and website hosted by someone else. Weewx can be configured to send the generated web pages to your external hosting service via ftp or rsync. That will eliminate the need to open ports into your home network. It may also be the best option if you have a lot of people accessing your data so as not to swamp your home internet link.
-
I opened up port 80. I may do ssh but I'll move it to a more obscure port. I used no-ip.com and you can see (I hope) my weewx at mikez104.zapto.org/weewx
-
george,
when you rewrite the ipwx extension to weewx, you might want to consider starting with the fileparse extension. it is much simpler than the simulator. in fact, you could almost use it as-is.
it does *not* solve your race condition, but you could solve that by putting the read into a retry loop (see the genLoopPackets in the acurite.py driver for an example of how to do that).
https://raw.githubusercontent.com/weewx/weewx/master/extensions/fileparse/bin/user/fileparse.py
the fileparse extension is a sample driver included in the weewx 3 distribution. all it does is read name-value pairs from a file.
m
-
george,
when you rewrite the ipwx extension to weewx, you might want to consider starting with the fileparse extension. it is much simpler than the simulator. in fact, you could almost use it as-is.
it does *not* solve your race condition, but you could solve that by putting the read into a retry loop (see the genLoopPackets in the acurite.py driver for an example of how to do that).
https://raw.githubusercontent.com/weewx/weewx/master/extensions/fileparse/bin/user/fileparse.py
the fileparse extension is a sample driver included in the weewx 3 distribution. all it does is read name-value pairs from a file.
m
That sounds like it would greatly simplify things. Is there a list of variable names I need to use?
-
you can use any names you want, then map them using the label_map in the configuration.
but to make it easier (and skip the need for configuration), use the names in the default schema:
weewx.com/docs/customizing.htm#archive_types
these names come from the wview schema (the default schema used by weewx), which in turn are derived from the davis names.
m
-
you can use any names you want, then map them using the label_map in the configuration.
but to make it easier (and skip the need for configuration), use the names in the default schema:
weewx.com/docs/customizing.htm#archive_types
these names come from the wview schema (the default schema used by weewx), which in turn are derived from the davis names.
m
I think I'll go with those schema names to keep things easy.
I'm fuzzy on the "rain", though. What time interval is that supposed to cover? The polling interval set in fileparse?
If I remember correctly, the way I hacked simulator was take the 36 seconds (the reporting rate of the hardware) and divided it by 2.5 seconds (the simulator loop interval) to get 14.4. I then divided the amount of rain in 36 seconds by 14.4.
So should I set "rain" to the 36-second rain amount divided by 14.4, or is there a better way to do it?
Oh, another issue I have is the initial accumulation of data for weewx. I'm getting around this now by delaying the start of weewx until 70 seconds after I start collecting data from the bridge to ensure I have a full set of valid data in the file. With the fileparse extension, is there a particular value I could start with that weewx would understand as not being valid data and pass over it? Perhaps "Null" or something similar?
Thanks!
-
Feel free to use me to test. My system is new so if I loose data or experience a crash, no big deal.
I do have a question about mounting the 5 in 1 unit. They say use the bubble level to ensure the thing is level. If I mount this on a 12 foot pole or something, how are you supposed to see the level?
-
And no, I don't have a 12 foot ladder...
-
Feel free to use me to test. My system is new so if I loose data or experience a crash, no big deal.
I do have a question about mounting the 5 in 1 unit. They say use the bubble level to ensure the thing is level. If I mount this on a 12 foot pole or something, how are you supposed to see the level?
Get a 13-foot ladder. ;)
The unit needs to be level mainly so the rain tipping buckets work properly.
Also you need to be sure the unit can't sway in the wind, which might also cause the tipping buckets to move and register "phantom rain".
-
Well, I think I have it like 15 or 16 feet up. I got a piece of 3/4" metal conduit and mounted that towards the top of the play thing (wooden structure with swings and slide that my kids grew out of years ago). I guess 7 feet of the pole are in the air and the rest is secured to the structure. Time will tell if it wobbles in the wind. I strapped it to the side while one end of the tube was on the ground so I could see the bubble level and when I had it right, I raised it up and tightened it in place. It should be close enough. I tried the thin wall conduit but that stuff was flimsy and did not fit snuggly in the bottom of the 5 in 1. I took that back and got the thick wall galvanized stuff. That fit perfect and seemed a lot more rigid.
-
I think I'll go with those schema names to keep things easy.
I'm fuzzy on the "rain", though. What time interval is that supposed to cover? The polling interval set in fileparse?
If I remember correctly, the way I hacked simulator was take the 36 seconds (the reporting rate of the hardware) and divided it by 2.5 seconds (the simulator loop interval) to get 14.4. I then divided the amount of rain in 36 seconds by 14.4.
So should I set "rain" to the 36-second rain amount divided by 14.4, or is there a better way to do it?
Oh, another issue I have is the initial accumulation of data for weewx. I'm getting around this now by delaying the start of weewx until 70 seconds after I start collecting data from the bridge to ensure I have a full set of valid data in the file. With the fileparse extension, is there a particular value I could start with that weewx would understand as not being valid data and pass over it? Perhaps "Null" or something similar?
a weewx driver only needs to report raw data from the sensors, in one of METRIC, METRICWX, or US systems (see the weewx customization guide for details about unit systems and conversions).
quality control, filtering, calculation of derived quantities, unit conversions, data storage, reporting, and uploading are all done in other weewx services. the driver should be simple; its job is simply to collect raw data from the hardware. this lets us share code, features, and extensibility across many different types of hardware and hardware architectures.
the fileparse driver has a polling_interval parameter - that determines how often it will read the file. assuming that data from the sensors are written to the file on every sensor read, set the polling_interval to the shortest sensor update interval, which would be 18 seconds for the acurite hardware.
the observation 'rain' is a 'delta' reading - it is the amount of rain since the last observation. rainRate is automatically calculated by the StdWXCalculate service, as are other derived quantities such as dewpoint, windchill, cloudbase, etc. so if your hardware reports a cumulative value for rain, call it rain_total, then the driver should remember the last rain_total and report 'rain' as the difference between last rain_total and current rain_total.
temperature, pressure, and most other observations are 'gauge' readings.
any rainfall totals happen in the reporting layer, typically by querying the database. for example, if you want to answer "how much rain fell last week" you simply do an sql query. the sql query has been simplified for many common meterological reports in the weewx report template system. in this case, the expression:
$week.rain
would do that sql query and return the amount of rainfall in the past week. the template syntax enables you to optionally display/convert units, format the numeric value, etc. its pretty powerful for creating web pages, json data, xml, raw text reports. once again, see the weewx customization guide for many, many, more options and heaps of examples.
finally, if you start using weewx in april, but you know that you have had 100 inches of rain since january 1 and you want that included in your reports, just do something like this:
#set $totalrain = 100 + $year.rain.inch.raw
rain this year: $totalrain
m
-
I think I'll go with those schema names to keep things easy.
I'm fuzzy on the "rain", though. What time interval is that supposed to cover? The polling interval set in fileparse?
If I remember correctly, the way I hacked simulator was take the 36 seconds (the reporting rate of the hardware) and divided it by 2.5 seconds (the simulator loop interval) to get 14.4. I then divided the amount of rain in 36 seconds by 14.4.
So should I set "rain" to the 36-second rain amount divided by 14.4, or is there a better way to do it?
Oh, another issue I have is the initial accumulation of data for weewx. I'm getting around this now by delaying the start of weewx until 70 seconds after I start collecting data from the bridge to ensure I have a full set of valid data in the file. With the fileparse extension, is there a particular value I could start with that weewx would understand as not being valid data and pass over it? Perhaps "Null" or something similar?
a weewx driver only needs to report raw data from the sensors, in one of METRIC, METRICWX, or US systems (see the weewx customization guide for details about unit systems and conversions).
quality control, filtering, calculation of derived quantities, unit conversions, data storage, reporting, and uploading are all done in other weewx services. the driver should be simple; its job is simply to collect raw data from the hardware. this lets us share code, features, and extensibility across many different types of hardware and hardware architectures.
the fileparse driver has a polling_interval parameter - that determines how often it will read the file. assuming that data from the sensors are written to the file on every sensor read, set the polling_interval to the shortest sensor update interval, which would be 18 seconds for the acurite hardware.
the observation 'rain' is a 'delta' reading - it is the amount of rain since the last observation. rainRate is automatically calculated by the StdWXCalculate service, as are other derived quantities such as dewpoint, windchill, cloudbase, etc. so if your hardware reports a cumulative value for rain, call it rain_total, then the driver should remember the last rain_total and report 'rain' as the difference between last rain_total and current rain_total.
temperature, pressure, and most other observations are 'gauge' readings.
any rainfall totals happen in the reporting layer, typically by querying the database. for example, if you want to answer "how much rain fell last week" you simply do an sql query. the sql query has been simplified for many common meterological reports in the weewx report template system. in this case, the expression:
$week.rain
would do that sql query and return the amount of rainfall in the past week. the template syntax enables you to optionally display/convert units, format the numeric value, etc. its pretty powerful for creating web pages, json data, xml, raw text reports. once again, see the weewx customization guide for many, many, more options and heaps of examples.
finally, if you start using weewx in april, but you know that you have had 100 inches of rain since january 1 and you want that included in your reports, just do something like this:
#set $totalrain = 100 + $year.rain.inch.raw
rain this year: $totalrain
m
OK. So if I set the polling interval to 18 seconds, how does weewx know that the "rain" data represents 36 seconds? Is that programmed into a hardware profile somewhere?
-
OK. So if I set the polling interval to 18 seconds, how does weewx know that the "rain" data represents 36 seconds? Is that programmed into a hardware profile somewhere?
lets say that ipwx reads the acurite bridge every 30 seconds. the first time it runs it spits out a text file like this:
outTemp = 72.5
inTemp = 68.0
rain_total = 22
pressure = 30.18
the driver reads this file and creates this dictionary:
packet = {"dateTime":xxxxxx, "usUnits":weewx.US, "outTemp": 72.5, "inTemp": 68.0, "rain": None, "pressure": 30.18}
the value xxxxxx is a unix epoch - number of seconds since 1 january 1970 GMT. the value "rain" is undefined because we have only the current cumulative count, 22. we need another cumulative rain reading to get a delta. but the driver retains the value 22:
self.last_rain = 22
30 seconds later, ipwx spits out this:
outTemp = 72.4
inTemp = 68.0
rain_total = 22
pressure = 30.19
from which the driver creates this packet:
packet = {"dateTime":xxxxxx, "usUnits":weewx.US, "outTemp": 72.4, "inTemp": 68.0, "rain": 0, "pressure": 30.19}
and does this assignment:
self.last_rain = 22
30 seconds later, ipwx spits out this:
outTemp = 72.8
inTemp = 68.0
rain_total = 24
pressure = 30.15
from which the driver creates this packet:
packet = {"dateTime":xxxxxx, "usUnits":weewx.US, "outTemp": 72.8, "inTemp": 68.0, "rain": 0.02, "pressure": 30.15}
the value for rain was calculated like this:
rain = (total_rain - self.last_rain) * inches_per_count
self.last_rain = total_rain
so that after this read we have:
self.last_rain = 24
note that it does not matter how often you poll the file. however, since the file only changes every 30 seconds, there is no need to poll it more often than that.
since the 5-in-1 sensors report every 18 and 36 seconds, you could just have ipwx spit out the file every 18 seconds and have the driver read the file every 18 seconds. use a retry during the read just in case the read is attempted while ipwx is writing to the file.
m
-
Ok... I'm confused.
The bridge hardware puts out a time-delta value for rain.
Are you suggesting instead of passing the hardware-reported value to weewx through "rain", I change it to an accumulated value (i.e "rain_total") instead?
I don't see "rain_total" in that list you linked, but I assume it's a variable that would be understood by the fileparse extension?
-
Ok... I'm confused.
The bridge hardware puts out a time-delta value for rain.
Are you suggesting instead of passing the hardware-reported value to weewx through "rain", I change it to an accumulated value (i.e "rain_total") instead?
I don't see "rain_total" in that list you linked, but I assume it's a variable that would be understood by the fileparse extension?
oh. i assumed that the bridge reports a rain total, not a rain delta. (the acurite console reports a cumulative counter - number of bucket tips)
you could simply report the rain delta that you get from the bridge, but that might be prone to error (e.g., if you miss a packet from the bridge, or if the driver polls the file much less often than ipwx writes to it).
can ipwx keep a total count (based on what it hears from the bridge), or is it stateless?
does the bridge spit out a complete set of observations each time it sends data? or is it more like the console, which sends out "partial packets" - for example, R1a messages contain wind speed, wind direction, cumulative rain, R1b messages contain wind speed, out temp, out humidity, and R2 messages contain pressure and inside temperature.
m
-
Ok... I'm confused.
The bridge hardware puts out a time-delta value for rain.
Are you suggesting instead of passing the hardware-reported value to weewx through "rain", I change it to an accumulated value (i.e "rain_total") instead?
I don't see "rain_total" in that list you linked, but I assume it's a variable that would be understood by the fileparse extension?
oh. i assumed that the bridge reports a rain total, not a rain delta. (the acurite console reports a cumulative counter - number of bucket tips)
you could simply report the rain delta that you get from the bridge, but that might be prone to error (e.g., if you miss a packet from the bridge, or if the driver polls the file much less often than ipwx writes to it).
can ipwx keep a total count (based on what it hears from the bridge), or is it stateless?
does the bridge spit out a complete set of observations each time it sends data? or is it more like the console, which sends out "partial packets" - for example, R1a messages contain wind speed, wind direction, cumulative rain, R1b messages contain wind speed, out temp, out humidity, and R2 messages contain pressure and inside temperature.
m
The 5n1 sensor sends data every 18 seconds, alternating between (wind speed, temp, humidity) and (wind speed, wind direction, rain in the last 36 seconds). These are received by the bridge then forwarded to acu-link.com as corresponding http statements. In other words, the 5n1 sensor generates 2 different http messages, very similar in content to R1a and R1b.
The rain data is not cumulative, though. If a packet is missed, that data is gone forever. The rain data is also sent (at least on the http side) in mm/1000 rather than tips, which I found surprising. I convert that to inches in ipwx.
As far as ipwx goes, I can keep a cumulative count. In my current beta version I'm keeping "dailyrainin" already for use with wunderground, so it would easy enough to write that to the file.
Sending cumulative rain seems easier to think about. It's hard to explain why I'm chopping up the 36-second rain data into 14.4 pieces to fit a 2.5-second polling rate. Sending cumulative rain is, like you say, probably less prone to error as it is immune to variances in the polling rate.
-
Hi, I ordered an additional temp sensor. I guess I should have asked you before I ordered but will ipwx push that data through to weewx? And does it move that to weather underground also? I'd like to have it be my interior temp and humidity or maybe put it in the shade when it starts getting hot and compare that with the temp on the 5 in 1.
-
Hi, I ordered an additional temp sensor. I guess I should have asked you before I ordered but will ipwx push that data through to weewx? And does it move that to weather underground also? I'd like to have it be my interior temp and humidity or maybe put it in the shade when it starts getting hot and compare that with the temp on the 5 in 1.
It can. With the fileparser extension we're discussing should make it even easier to get it into weewx.
As for wunderground taking additional data (like a second temp and humidity), it doesn't seem to graph additional sensors, even though they've allowed for that data to be sent through their published protocol. The best I've been able to do is send a second temperature as "soil temp", and it will show on the station page, but unfortunately it won't graph.
-
Ok, good to know. Thanks
-
So the tower sensor showed up. It is working but I'm really not sure what I have to do to pass the data to weewx. Can you point me in to correct direction?
-
So the tower sensor showed up. It is working but I'm really not sure what I have to do to pass the data to weewx. Can you point me in to correct direction?
I'm on the road the next week or so and don't have access to my system and code, but I'll try to point you in the right direction.
I assume you're using the beta parser at http://nincehelser.com/ipwxcode/parser
That has code in it to read the temperature and relative humidity from a tower. The variables are named something like $tower_tempF and $tower_RH.
What you'll need to do is uncomment the lines that write the wxdata file, and then add a couple lines to write the tower data. I'd suggest using value names that work with the existing database schema. ('cause that's the way I'll eventually be going)
The file parser extension would make this much easier. I you want to go that route you're welcome to try it yourself as I won't get to it for a bit. See Matt's documentation linked above, and the weewx docs about installing the extension. It should be pretty straight-forward write the wxdata file in the format needed. It basically pretty close now, but you'd need to change the value names to something that matches the existing schema.
Or you can try to modify the hacked simulator driver for now. That shouldn't be too hard either, but you'll still need to figure out what variable names to use. I believe there are suitable pre-existing variables in the schema, like the ones for indoor temp and indoor humidity. I'm not sure what the process is for adding new names to the schema, but I'm sure it's covered somewhere in the weewx docs. (Personally, I'd try to use something already existing just to keep it simple)
Hope this helps. I'll still be checking in here while on the road if you have questions.
-
Thank you sir. I'll take a look tomorrow. Too tired and it's too late to do any more thinking today. Safe travels.
-
Ok, I wasn't going to touch it until tomorrow but, yeah, I got sucked into it...
So looking at the parser file I saw that I am using the original one from the instructions at http://nincehelser.com/ipwx/ . I assumed I should be using the one you referenced above so I switched to that. It looks like you have changed up some stuff in the newer file.
I could not get it to work. It would not update the temp on weewx page. The other settings didn't seem to move either but I cant say whether they were broke or not because it is a very calm night with like no wind. The baro didn't seem to move and I tried comparing the readings with my aculink page. Aculink temp moved but weewx stayed the same. I looked at the syslog and it was doing tasks and not complaining but the data seemed to be staying the same. I though maybe it was because the lines for the wxdata file were commented out so I undid the comments but that did not make a difference.
I put back the original parser file and weewx and WU seem to updating normally now.
From the way I see it, the listener basically sniffs the packets coming from the bridge that are on their way to the aculink site and takes that data and passes it off to the parser through the pipe. The parser then takes the data and arranges it with the correct names and corrects the units and reformats it then makes some kind of handoff to the weewx driver. Then weewx takes that data and makes the web page, archives the data in the db and, for me, uploads to WU. How does parser make that handoff? Via that wxdata textfile? I think that's where I'm confused.
Keep in mind that I don't know python. I can follow a lot of whats going to a point but I don't know the syntax. And I'm no programmer. Everything I know, I just taught myself.
Now, I'm throwing in the towel. g'night.
-
Ok, I wasn't going to touch it until tomorrow but, yeah, I got sucked into it...
So looking at the parser file I saw that I am using the original one from the instructions at http://nincehelser.com/ipwx/ . I assumed I should be using the one you referenced above so I switched to that. It looks like you have changed up some stuff in the newer file.
I could not get it to work. It would not update the temp on weewx page. The other settings didn't seem to move either but I cant say whether they were broke or not because it is a very calm night with like no wind. The baro didn't seem to move and I tried comparing the readings with my aculink page. Aculink temp moved but weewx stayed the same. I looked at the syslog and it was doing tasks and not complaining but the data seemed to be staying the same. I though maybe it was because the lines for the wxdata file were commented out so I undid the comments but that did not make a difference.
I put back the original parser file and weewx and WU seem to updating normally now.
From the way I see it, the listener basically sniffs the packets coming from the bridge that are on their way to the aculink site and takes that data and passes it off to the parser through the pipe. The parser then takes the data and arranges it with the correct names and corrects the units and reformats it then makes some kind of handoff to the weewx driver. Then weewx takes that data and makes the web page, archives the data in the db and, for me, uploads to WU. How does parser make that handoff? Via that wxdata textfile? I think that's where I'm confused.
Keep in mind that I don't know python. I can follow a lot of whats going to a point but I don't know the syntax. And I'm no programmer. Everything I know, I just taught myself.
Now, I'm throwing in the towel. g'night.
You've got a pretty good handle on it. Yes, the parser writes the text file, wxdata, and that is then read by weewx.
I suspect the problem might be the path where wxdata is written. Originally I started with /home/ipwx/wxdata, but with the new beta I started using /home/pi/ipwx/wxdata. Where wxdata is written isn't particularly important, but the paths used by "parser" and the hacked "simulator.py" must be in agreement.
-
Dang it. That bit me before but I figured it out then. I think that I figured it out before because there was an error in the syslog about the file not existing. This time the wxdata already existed because it was written by the earlier version of the parser so no errors in syslog. Guess the beers I enjoyed this evening clouded my memory. #-o
I'll check it out tomorrow.
-
Ok, fixed the path and that made it not crash. So, I added two lines to the parser that reverenced $tower_tempF and $tower_RH. Looks like this
print MYFILE "item = $tower_tempF\n";
print MYFILE "ihum = $tower_RH\n";
That created the lines in the wxdata file but they were empty. So I ran the listener by itself and saw that it was not greping for the tower sensor so I fixed that. So it's piping the data to the parser but the parser was set to look for "tower" and the data from the listener program was tagged as "tower&humidity" so I changed those and now it saves the data to the wxdata file.
It looks like near the top of the parser file, you might be setting the variables initial values? Like RH = '999'; I don't see a line in there for the tower sensor but there seems to be a line for everything else. Not sure if tower should be added there.
So on the the simulator.py. I found the part where it looks like you are reading the data from the wxdata file and I think it would need some info added there for the tower sensor. I did that but the program would not run and complained about using a float or something. I think it may be because I can't just add that to area where you are reading the file. Maybe it needs set up before that section? Here is the section I speak of. I took my lines out because I wanted to get it back up and running.
print(wxdata)
_packet['outTemp'] = wxdata['temp']
_packet['outHumidity'] = wxdata['humi']
_packet['barometer'] = wxdata['baro']
_packet['windSpeed'] = wxdata['wspd']
And I also found out how to get into the databases for weewx and see the data although I have not tried to edit anything yet. So any ideas on the driver? It seems to be good until there.
-
Ok, fixed the path and that made it not crash. So, I added two lines to the parser that reverenced $tower_tempF and $tower_RH. Looks like this
print MYFILE "item = $tower_tempF\n";
print MYFILE "ihum = $tower_RH\n";
That created the lines in the wxdata file but they were empty. So I ran the listener by itself and saw that it was not greping for the tower sensor so I fixed that. So it's piping the data to the parser but the parser was set to look for "tower" and the data from the listener program was tagged as "tower&humidity" so I changed those and now it saves the data to the wxdata file.
It looks like near the top of the parser file, you might be setting the variables initial values? Like RH = '999'; I don't see a line in there for the tower sensor but there seems to be a line for everything else. Not sure if tower should be added there.
So on the the simulator.py. I found the part where it looks like you are reading the data from the wxdata file and I think it would need some info added there for the tower sensor. I did that but the program would not run and complained about using a float or something. I think it may be because I can't just add that to area where you are reading the file. Maybe it needs set up before that section? Here is the section I speak of. I took my lines out because I wanted to get it back up and running.
print(wxdata)
_packet['outTemp'] = wxdata['temp']
_packet['outHumidity'] = wxdata['humi']
_packet['barometer'] = wxdata['baro']
_packet['windSpeed'] = wxdata['wspd']
And I also found out how to get into the databases for weewx and see the data although I have not tried to edit anything yet. So any ideas on the driver? It seems to be good until there.
It sounds like you're using the original version of the listener. The new one at http://nincehelser.com/ipwxcode/listener just greps for "mt=". That apparently stands for model type, and any valid AcuLink message will contain one. So what's happening is the listener is forwarding any message that contains a model type, be it tower, 5n1, pressure (the bridge), or even 3n1.
I just set some initial values for some variables that cause trouble if you don't. For example, I set RH to 999 to flag it doesn't have a legitimate value yet (a legal value would be something like 0 to 99). I think the reason I did that is the dewpoint calculation goes nuts if RH isn't reasonable because of the natural log function. I didn't calculate dewpoint for the tower so it wasn't an issue.
The "float" problem may have occurred if weewx didn't understand a value. That might occur if weewx starts too soon after the listener. Give the listener a good minute or so to fully populate wxdata, then start weewx.
Before doing that, though, you should look at the values in wxdata and make sure they are properly updating. (use cat wxdata to list the data) Once your're satisfied they are updating, you can start weewx.
Basically the "float" error occurs because weewx is trying to read the file and is expecting a floating point number value, but is getting nothing or something different.
-
Yeah, everything is good up until the driver reads wxdata. I took out my additions to the driver before I fixed the other stuff so it make senses that weewx didn't like the value it read from wxdata because the value was empty. Before I fixed listener, parser was not populating the the lines I had added for the extra sensors. I will set them up again and give it another try. I haven't touched it today, I took another old raspberry pi and am going to set it up as an outdoor weather webcam. I was having issues with the wireless adapter I was using but got that all working. So, tomorrow maybe I'll try the driver again.
-
Well, I just put my variables back in the driver and it is now adding the inHumidty and inTemp to the database. It also added the inside temp to the web page but not the humidity. I have to dig around a little to find where to add that one.
-
Ok, I found a new skin that I like and it includes the inside temp and humidity BUT, the values are going all weird. The humidity was saying 76% when the sensor is reading 43%. I checked the wxdata file and it matches the 43% so the difference is coming from the driver I think.
I went in and started moving values for " 'inHumidity' : Observation(magnitude=30.0, average=50.0" and they seem to make the humidity value change but nothing consistent. I ended up putting them back to where they were and the reading was normal. No clue why. But now, the reading is climbing again. In the last two hours, it went up 5% over the correct reading.
# The following doesn't make much meteorological sense, but it is easy to program!
self.observations = {'inTemp' : Observation(magnitude=20.0, average= 50.0, period=24.0, phase_lag=14.0, start=start_ts),
'inHumidity' : Observation(magnitude=30.0, average=50.0, period=48.0, phase_lag=14.0, start=start_ts),
'outTemp' : Observation(magnitude=20.0, average= 50.0, period=24.0, phase_lag=14.0, start=start_ts),
'barometer' : Observation(magnitude=1.0, average= 30.1, period=48.0, phase_lag= 0.0, start=start_ts),
'windSpeed' : Observation(magnitude=10.0, average= 5.0, period=48.0, phase_lag=24.0, start=start_ts),
'windDir' : Observation(magnitude=360.0, average=180.0, period=48.0, phase_lag= 0.0, start=start_ts),
'humidity' : Observation(magnitude=30.0, average= 50.0, period=48.0, phase_lag= 0.0, start=start_ts),
'rain' : Rain(rain_start=0, rain_length=3, total_rain=0.2, loop_interval=self.loop_interval)}
Do you know what could be happening? And could you explain what the values are for and how they work?
-
Ok, I found a new skin that I like and it includes the inside temp and humidity BUT, the values are going all weird. The humidity was saying 76% when the sensor is reading 43%. I checked the wxdata file and it matches the 43% so the difference is coming from the driver I think.
I went in and started moving values for " 'inHumidity' : Observation(magnitude=30.0, average=50.0" and they seem to make the humidity value change but nothing consistent. I ended up putting them back to where they were and the reading was normal. No clue why. But now, the reading is climbing again. In the last two hours, it went up 5% over the correct reading.
# The following doesn't make much meteorological sense, but it is easy to program!
self.observations = {'inTemp' : Observation(magnitude=20.0, average= 50.0, period=24.0, phase_lag=14.0, start=start_ts),
'inHumidity' : Observation(magnitude=30.0, average=50.0, period=48.0, phase_lag=14.0, start=start_ts),
'outTemp' : Observation(magnitude=20.0, average= 50.0, period=24.0, phase_lag=14.0, start=start_ts),
'barometer' : Observation(magnitude=1.0, average= 30.1, period=48.0, phase_lag= 0.0, start=start_ts),
'windSpeed' : Observation(magnitude=10.0, average= 5.0, period=48.0, phase_lag=24.0, start=start_ts),
'windDir' : Observation(magnitude=360.0, average=180.0, period=48.0, phase_lag= 0.0, start=start_ts),
'humidity' : Observation(magnitude=30.0, average= 50.0, period=48.0, phase_lag= 0.0, start=start_ts),
'rain' : Rain(rain_start=0, rain_length=3, total_rain=0.2, loop_interval=self.loop_interval)}
Do you know what could be happening? And could you explain what the values are for and how they work?
Ah. What you're looking at there is the original simulator code. The original purpose of the simulator was to simulate data when you had no device.
So what's going on in that code snippet is the generation of data based some mathematical function, like a sine wave, based on those parameters.
What I did later on in the code was over-rode those synthesized values with actual values... you'll need to do the same in inTemp and inHumidity.
I think those additions should occur in this area of the driver:
print(wxdata)
_packet['outTemp'] = wxdata['temp']
_packet['outHumidity'] = wxdata['humi']
_packet['barometer'] = wxdata['baro']
_packet['windSpeed'] = wxdata['wspd']
-
Ok, I didn't know what the heck that was. I also added my stuff below like you said. They are the lines with inHumidity and inTemp. The temp works fine but the humitity is increasing for some reason.
print(wxdata)
_packet['outTemp'] = wxdata['temp']
_packet['outHumidity'] = wxdata['humi']
_packet['barometer'] = wxdata['baro']
_packet['windSpeed'] = wxdata['wspd']
if wxdata['wspd'] >=1:
_packet['windDir'] = wxdata['wdir']
else:
_packet['windDir'] = None
_packet['rain'] = wxdata['rain'] / 14.4
_packet['inTemp'] = wxdata['item']
_packet['inHumitity'] = wxdata['ihum']
_packet['windGust'] = None
-
_packet['inHumitity'] = wxdata['ihum']
Check your spelling of "humidity" in the above line. ;)
-
:shock: :oops:
Derp
Hey, lookie there, works like a charm now... Thanks man, that was driving me nuts!
-
I caught it throwing that error again about the converting a string to a float. Any clue?
May 5 12:17:16 weatherPi weewx[2288]: engine: Shutting down StdReport thread
May 5 12:17:16 weatherPi weewx[2288]: engine: StdReport thread has been terminated
May 5 12:17:16 weatherPi weewx[2288]: engine: Caught unrecoverable exception in engine:
May 5 12:17:16 weatherPi weewx[2288]: **** could not convert string to float:
May 5 12:17:16 weatherPi weewx[2288]: **** Traceback (most recent call last):
May 5 12:17:16 weatherPi weewx[2288]: **** File "/usr/share/weewx/weewx/engine.py", line 836, in main
May 5 12:17:16 weatherPi weewx[2288]: **** engine.run()
May 5 12:17:16 weatherPi weewx[2288]: **** File "/usr/share/weewx/weewx/engine.py", line 187, in run
May 5 12:17:16 weatherPi weewx[2288]: **** for packet in self.console.genLoopPackets():
May 5 12:17:16 weatherPi weewx[2288]: **** File "/usr/share/weewx/weewx/drivers/simulator.py", line 149, in genLoopPackets
May 5 12:17:16 weatherPi weewx[2288]: **** number = float(line[eq_index + 1:].strip())
May 5 12:17:16 weatherPi weewx[2288]: **** ValueError: could not convert string to float:
May 5 12:17:16 weatherPi weewx[2288]: **** Exiting.
-
I caught it throwing that error again about the converting a string to a float. Any clue?
May 5 12:17:16 weatherPi weewx[2288]: engine: Shutting down StdReport thread
May 5 12:17:16 weatherPi weewx[2288]: engine: StdReport thread has been terminated
May 5 12:17:16 weatherPi weewx[2288]: engine: Caught unrecoverable exception in engine:
May 5 12:17:16 weatherPi weewx[2288]: **** could not convert string to float:
May 5 12:17:16 weatherPi weewx[2288]: **** Traceback (most recent call last):
May 5 12:17:16 weatherPi weewx[2288]: **** File "/usr/share/weewx/weewx/engine.py", line 836, in main
May 5 12:17:16 weatherPi weewx[2288]: **** engine.run()
May 5 12:17:16 weatherPi weewx[2288]: **** File "/usr/share/weewx/weewx/engine.py", line 187, in run
May 5 12:17:16 weatherPi weewx[2288]: **** for packet in self.console.genLoopPackets():
May 5 12:17:16 weatherPi weewx[2288]: **** File "/usr/share/weewx/weewx/drivers/simulator.py", line 149, in genLoopPackets
May 5 12:17:16 weatherPi weewx[2288]: **** number = float(line[eq_index + 1:].strip())
May 5 12:17:16 weatherPi weewx[2288]: **** ValueError: could not convert string to float:
May 5 12:17:16 weatherPi weewx[2288]: **** Exiting.
That's likely the bug I mentioned early-on. wxdata is in the process of being re-written, but weewx tries to read it before it is ready, getting garbled results.
-
Got ya. I totally blew it up today. Tried messing with the skin, couldn't get forecasts to work, changed a bunch of stuff and it blew up. I'm starting over. :roll: at least I will take care of some stuff that I wanted to change. After messing with all this, I went back and read the posts between you and the other guy again. I may try that file parser. I looked at it and it is very small and simple but I have the same questions about the rain. I may experiment with that combined with the listener/parser programs.
-
Got ya. I totally blew it up today. Tried messing with the skin, couldn't get forecasts to work, changed a bunch of stuff and it blew up. I'm starting over. :roll: at least I will take care of some stuff that I wanted to change. After messing with all this, I went back and read the posts between you and the other guy again. I may try that file parser. I looked at it and it is very small and simple but I have the same questions about the rain. I may experiment with that combined with the listener/parser programs.
Yeah. Fileparser does look like the easiest way to go. The only catch with rain is how you want to report it. If you use the 36-second delta as it comes from the bridge, then you'll need to divide it as appropriate for the polling rate. For example, if you poll every 18 seconds, then you'll have to cut that 36-second value in half.
Or you could calculate an accumulation. The "dailiyrainin" I use in the beta parser may be good for that. Using an accumulation makes things simpler and less prone to error, too.
Interestingly, Acurite stated on their forum that the rain value should be a rolling counter. That makes a lot of sense as it seems to explain the operation of the consoles, however, that's not how it's being reported by the bridge. A rolling counter would make much more sense and be more robust to data loss with respect to rain, so I wonder why they made that change?
-
Idk. Maybe the console has the ability to store data (a few weeks worth I think) and make calculations. The bridge seems like it is just a dumb relay of sorts that just receives the data from the 5&1 and 2 others and just spits it to the aculink site and lets the site do all the calculations. For them, it would be easier to make any changes in code that would do calculations and what not on their site instead of trying to push firmware out. Ha, or I could be totally off base! Just a thought.
Well, I have to thank you for those instructions on your site. I was able to install a new image of Raspbian, install weewx and get apache installed in record time. If I had to rethink all the steps, it would of taken quite some time.
This time, I am going to image the SD card at this point so if I blow it up again, I wont wate a bunch of time rebuilding the base system. I kept telling myself that I have to image this SD card just in case and bam. Well, I guess thats how it goes.
-
Idk. Maybe the console has the ability to store data (a few weeks worth I think) and make calculations. The bridge seems like it is just a dumb relay of sorts that just receives the data from the 5&1 and 2 others and just spits it to the aculink site and lets the site do all the calculations. For them, it would be easier to make any changes in code that would do calculations and what not on their site instead of trying to push firmware out. Ha, or I could be totally off base! Just a thought.
Well, I have to thank you for those instructions on your site. I was able to install a new image of Raspbian, install weewx and get apache installed in record time. If I had to rethink all the steps, it would of taken quite some time.
This time, I am going to image the SD card at this point so if I blow it up again, I wont wate a bunch of time rebuilding the base system. I kept telling myself that I have to image this SD card just in case and bam. Well, I guess thats how it goes.
The big question is what data the 5n1 is actually sending out the radio link. I don't know of anyone who has decoded it that far. Basically the 5n1 has a counter to count the bucket tips. It doesn't necessarily have to reset that counter after each transmission (as it seems to do from the bridge point-of-view). It could just keep incrementing the counter and let software figure out the change in rainfall as necessary. The beauty of that scheme is that it becomes fairly immune to data packet loss. If connectivity was lost during a huge rainstorm, then you could still tell how much rain did fall once you re-acquired the signal by comparing the change in the counter.
The consoles do seem to behave as if they might be reading a counter. I've tried to block them from receiving rain data when messing with the gauge, but it still seems they pick up readings once communications are restored. That seems to make sense if the 5n1 really has a rolling counter. Someone might do a controlled experiment to see if that behavior holds true.
-
Oh, don't get me going. I'll be up the yard tearing down my 5&1 to find out... That would make sense though. All i'd have to do is loosen 4 screws and....
-
I was getting weird dewpoint readings of like 2000+ degrees. I think it was because listener/parser was not running long enough to put valid data in the wxdata file before the driver read it. I think I solved that. I put a single line script that starts the listener/parser in /etc/rc.local then added sleep 65 to the beginning of /etc/init.d/weewx. Weewx seemed to wait a decent amount of time to start after I rebooted. And no crazy readings.
-
I was looking through the parser program and trying to figure out how that works. It looks pretty straight forward. I also was looking at the data that comes in from the listener. I can understand most of it. Seems like the values of the readings are prefixed with an A ans some of them have a lot af extra 00s at the end. Delimited with a &. And you spell out the compass rose weirdness with the hex and the wind in cm/sec but what the heck is going on with the pressure? Looking at the raw data, I just don't get how you can get anything from that. How did you figure that one out? Or am i missing something.
-
I was looking through the parser program and trying to figure out how that works. It looks pretty straight forward. I also was looking at the data that comes in from the listener. I can understand most of it. Seems like the values of the readings are prefixed with an A ans some of them have a lot af extra 00s at the end. Delimited with a &. And you spell out the compass rose weirdness with the hex and the wind in cm/sec but what the heck is going on with the pressure? Looking at the raw data, I just don't get how you can get anything from that. How did you figure that one out? Or am i missing something.
Figuring out the the pressure data took a little bit of detective work and educated guessing. I started searching data sheets for baro sensors that had similar characteristics. It didn't take too long to find one where the number and names of the variables matched up. I ran the numbers through the equations on the data sheet and found the results matched up perfectly. A bit later another hacker disassembled their bridge and visually verified that the sensor and data sheet lined up.
http://www.hoperf.com/upload/sensor/HP03S.pdf
-
Others have done the RF signal decode. Try an internet search for "acurite 5n1 rf decode" to find some of them.
The rain is indeed just a counter that increments by one for every bucket tip. It is probably 13-bits wide so would count from zero to 8192 (or 81.92 inches of rain) before rolling over.
-
Others have done the RF signal decode. Try an internet search for "acurite 5n1 rf decode" to find some of them.
The rain is indeed just a counter that increments by one for every bucket tip. It is probably 13-bits wide so would count from zero to 8192 (or 81.92 inches of rain) before rolling over.
Unfortunately that is not how the data comes out of the Acurite Bridge.
-
Sorry, just trying to help. Earlier in this thread you said:
The big question is what data the 5n1 is actually sending out the radio link. I don't know of anyone who has decoded it that far. Basically the 5n1 has a counter to count the bucket tips.
And I knew the radio link has been figured out so was trying to provide that info.
-
I tried to pull my 5n1 off the pole today to experiment with the rain buckets. When I tried to unscrew the screw I put in to to fix the 5n1 to the pole, I snapped the head off. :?
Yup, stainless stud sticking out of the pole securely fixing the plastic base in place. I didn't feel like drilling it out as we were thunderstorms were on the way. We ended up getting almost an inch and a half of rain. Anyway, here is the question.
Do you think there is a way to read an additional sensor in the parser program? The windspeed from my 5n1 is too low. It is not that high up and there are trees all around. I still have a Davis anemometer on my roof from my old system. It still spins and is unobstructed and is 40ish feet above ground. I got hold of the wire from the thing and spliced it to an arduino. It reads the closures of the switch and counts them and calculates a wind speed. The guy who came up with the program had it sending the windspeed and temp to an LCD. I got rid of the temp code he had in there and changed it to write to the serial port instead of the LCD. I hooked that up and can see the data on the Raspi by doing a cat /dev/ttyACM0. Right now I have it outputting "Windspeed is XX" but could change that to anything. The Arduino script counts the pulses for 3 seconds then averages and gives the speed.
The readings I was getting with the Davis unit were almost twice as the 5n1 and they also were very close to the guy up on the hill behind my house. He has a weewx site also and uses a Davis Vantage Pro2.
So, not sure how much would be involved in adding that. Let me know what ya think.
Thanks
Mike
-
I tried to pull my 5n1 off the pole today to experiment with the rain buckets. When I tried to unscrew the screw I put in to to fix the 5n1 to the pole, I snapped the head off. :?
Yup, stainless stud sticking out of the pole securely fixing the plastic base in place. I didn't feel like drilling it out as we were thunderstorms were on the way. We ended up getting almost an inch and a half of rain. Anyway, here is the question.
Do you think there is a way to read an additional sensor in the parser program? The windspeed from my 5n1 is too low. It is not that high up and there are trees all around. I still have a Davis anemometer on my roof from my old system. It still spins and is unobstructed and is 40ish feet above ground. I got hold of the wire from the thing and spliced it to an arduino. It reads the closures of the switch and counts them and calculates a wind speed. The guy who came up with the program had it sending the windspeed and temp to an LCD. I got rid of the temp code he had in there and changed it to write to the serial port instead of the LCD. I hooked that up and can see the data on the Raspi by doing a cat /dev/ttyACM0. Right now I have it outputting "Windspeed is XX" but could change that to anything. The Arduino script counts the pulses for 3 seconds then averages and gives the speed.
The readings I was getting with the Davis unit were almost twice as the 5n1 and they also were very close to the guy up on the hill behind my house. He has a weewx site also and uses a Davis Vantage Pro2.
So, not sure how much would be involved in adding that. Let me know what ya think.
Thanks
Mike
That shouldn't be too hard.
Quick and dirty, just before the wxdata file is written, I'd read the windspeed using /dev/ttyACM0 as the input and write that value to wxdata instead of the value from the 5n1.
-
One would think that would be easy... and it may be if you know how to program. Unfortunatly I do not. I looked around for some code and found some that works but it reads the usb port forever and never moves on to write the file. Here is what I have. I added this to the top and it seems to work fine.
use Device::SerialPort;
my $port = Device::SerialPort->new("/dev/ttyACM0");
$port->databits(8);
$port->baudrate(9600);
$port->parity("none");
$port->stopbits(1);
But here is where I am stuck. The original code reads like this, and it loops forever.
while(1) {
my $byte=$port->read(1);
print "$byte";
}
If I try this, it just errors out and I'm not sure where to go from here.
my $byte=$port->read(1);
$windspeed = $byte
-
Hey George, Have you ever run into this one? My raspberry pi was unresponsive this morning so I power cycled it and when it came back up it looked at the syslog and this is what it is doing when it tries to start weewx.
Jun 6 13:47:01 weatherpi /USR/SBIN/CRON[2775]: (root) CMD (/home/ipwx/./watchdog)
Jun 6 13:47:02 weatherpi weewx[2793]: engine: Initializing weewx version 3.1.0
Jun 6 13:47:02 weatherpi weewx[2793]: engine: Using Python 2.7.3 (default, Mar 18 2014, 05:13:23) #012[GCC 4.6.3]
Jun 6 13:47:02 weatherpi weewx[2793]: engine: pid file is /var/run/weewx.pid
Jun 6 13:47:02 weatherpi weewx[2795]: engine: Using configuration file /etc/weewx/weewx.conf
Jun 6 13:47:02 weatherpi weewx[2795]: engine: Loading station type Simulator (weewx.drivers.simulator)
Jun 6 13:47:02 weatherpi weewx[2795]: engine: StdConvert target unit is 0x1
Jun 6 13:47:02 weatherpi /USR/SBIN/CRON[2774]: (CRON) info (No MTA installed, discarding output)
Jun 6 13:47:02 weatherpi weewx[2795]: engine: Archive will use data binding wx_binding
Jun 6 13:47:02 weatherpi weewx[2795]: engine: Record generation will be attempted in 'hardware'
Jun 6 13:47:02 weatherpi weewx[2795]: engine: Using archive interval of 60 seconds
Jun 6 13:47:02 weatherpi weewx[2795]: engine: Caught unrecoverable exception in engine:
Jun 6 13:47:02 weatherpi weewx[2795]: **** database disk image is malformed
Jun 6 13:47:02 weatherpi weewx[2795]: **** Traceback (most recent call last):
Jun 6 13:47:02 weatherpi weewx[2795]: **** File "/usr/share/weewx/weewx/engine.py", line 831, in main
Jun 6 13:47:02 weatherpi weewx[2795]: **** engine = EngineClass(config_dict)
Jun 6 13:47:02 weatherpi weewx[2795]: **** File "/usr/share/weewx/weewx/engine.py", line 77, in __init__
Jun 6 13:47:02 weatherpi weewx[2795]: **** self.loadServices(config_dict)
Jun 6 13:47:02 weatherpi weewx[2795]: **** File "/usr/share/weewx/weewx/engine.py", line 141, in loadServices
Jun 6 13:47:02 weatherpi weewx[2795]: **** self.service_obj.append(weeutil.weeutil._get_object(svc)(self, config_dict))
Jun 6 13:47:02 weatherpi weewx[2795]: **** File "/usr/share/weewx/weewx/engine.py", line 504, in __init__
Jun 6 13:47:02 weatherpi weewx[2795]: **** self.setup_database(config_dict)
Jun 6 13:47:02 weatherpi weewx[2795]: **** File "/usr/share/weewx/weewx/engine.py", line 602, in setup_database
Jun 6 13:47:02 weatherpi weewx[2795]: **** dbmanager = self.engine.db_binder.get_manager(self.data_binding, initialize=True)
Jun 6 13:47:02 weatherpi weewx[2795]: **** File "/usr/share/weewx/weewx/manager.py", line 833, in get_manager
Jun 6 13:47:02 weatherpi weewx[2795]: **** self.manager_cache[data_binding] = open_manager(manager_dict, initialize)
Jun 6 13:47:02 weatherpi weewx[2795]: **** File "/usr/share/weewx/weewx/manager.py", line 915, in open_manager
Jun 6 13:47:02 weatherpi weewx[2795]: **** manager_dict['schema'])
Jun 6 13:47:02 weatherpi weewx[2795]: **** File "/usr/share/weewx/weewx/manager.py", line 139, in open_with_create
Jun 6 13:47:02 weatherpi weewx[2795]: **** dbmanager = cls(connection, table_name=table_name, schema=schema)
Jun 6 13:47:02 weatherpi weewx[2795]: **** File "/usr/share/weewx/weewx/manager.py", line 1052, in __init__
Jun 6 13:47:02 weatherpi weewx[2795]: **** super(DaySummaryManager, self).__init__(connection, table_name, schema)
Jun 6 13:47:02 weatherpi weewx[2795]: **** File "/usr/share/weewx/weewx/manager.py", line 71, in __init__
Jun 6 13:47:02 weatherpi weewx[2795]: **** self.sqlkeys = self.connection.columnsOf(self.table_name)
Jun 6 13:47:02 weatherpi weewx[2795]: **** File "/usr/share/weewx/weedb/sqlite.py", line 151, in columnsOf
Jun 6 13:47:02 weatherpi weewx[2795]: **** column_list = [row[1] for row in self.genSchemaOf(table)]
Jun 6 13:47:02 weatherpi weewx[2795]: **** File "/usr/share/weewx/weedb/sqlite.py", line 140, in genSchemaOf
Jun 6 13:47:02 weatherpi weewx[2795]: **** for row in self.connection.execute("""PRAGMA table_info(%s);""" % table):
Jun 6 13:47:02 weatherpi weewx[2795]: **** DatabaseError: database disk image is malformed
Jun 6 13:47:02 weatherpi weewx[2795]: **** Exiting.
I saw someone said you may be able to fix this by using sqlite to dump to a text file then reimporting. I tryed that but it would bnot dump. Here's what I got. Any clue how to repair this db? Or what may have caused the corruption in the first place? It happened this morning at about 6:30. No power hits or anything, the box just locked up at that time.
PRAGMA foreign_keys=OFF;
BEGIN TRANSACTION;
/****** CORRUPTION ERROR *******/
/****** database disk image is malformed ******/
/****** ERROR: database disk image is malformed ******/
/**** ERROR: (11) database disk image is malformed *****/
ROLLBACK; -- due to errors
-
I haven't had that happen before. If the Pi was completely locked up, I suspect something went wrong when writing to the SD card.
Be sure your Pi's power adapter can supply plenty of power. The only crashes I have had were due to a wimpy adapter I was trying to use (only .5 Amp).
You might try the weewx users group for ideas on repairing the database file.
-
maybe it it the card, idk. It went weird on me again tonight. It has done this before. Apache stops responding, I can't ssh in and things get weird. I was able to blindly hook up a keyboard and gracefully shut it down and reboot. I swapped the power supply for a 3 amp unit. We'll see what happens...
-
BTW, that turtle in your signature thing looks like it would take your hand off!
-
BTW, that turtle in your signature thing looks like it would take your hand off!
It almost did!
It lunged out at my iPhone right after I took that shot. Knocked it clean out of my hands and put a good gouge in the case!
But now no one should mess with my phone again!
(http://i905.photobucket.com/albums/ac259/nincehelser/Acurite%205n1%20Sensor%20Photos/BAE11C43-87E0-4071-8A81-F03EE0370B1B_zpsqupi4ov4.png)
-
Turtle Soup?