Weewx, WMR300 and RaspberryPi "altimeter: none, barometer: none" no view ...?

[Yngve Andersson]

Hey!

I need help getting forward with displaying the information from "barometer = pressure" that is missing and showing "none" in log file and at presentation. The values ​​show only at the first registration after starting the program.

When I searched for information online, I realized that it could be tricky to have the barometer work with the WMR300.

I have, after search, tested all proposals that have appeared to be relevant to this problem, but with negative or unchanged results. I have tested all WMR300 drivers from version 0.18, 0.18nolegacy.05.01a, 0.19rc1-cr3.

I am very grateful if any of you can have any idea that will bring me a solution to this problem.

Measurement values ​​can be seen at:

https://www.wunderground.com/personal-weather-station/dashboard?ID=IKUMLING2#history/tdata/s20180117/e20180117/mdaily

As seen on this web site, the barometer appears to work and displays the values ​​for a shorter time after the system is restarted!

My system is WMR300 with wmr300.py version "0.19rc3" and RapberryPi. Programmed and installed with version "weewx_3.8.0-1.deb".

Attaches info about syslog after start and weewx.conf

Sincerely Yngve

[mwall]

yngve,

thank you for a detailed problem description!

wu can be very unreliable about displaying data, so we should first ensure that weewx is getting correct data from the hardware.

as you know, the wmr300 emits a pressure reading only every 900 seconds.  so if you have an archive interval of 300 seconds, only every 3rd archive record will have a value for pressure.

however, your archive interval of 900 seconds should address this.

how often do you have records (REC not LOOP) with no pressure/altimeter/barometer?

you can find out easily by doing a query on the weewx database:

sqlite3 /var/lib/weewx.sdb

select dateTime,pressure,barometer,altimeter from archive

m

[Yngve Andersson]

Thank you, mwall for your quick response and dedication!

The time is set to 900 seconds, also tested 1200 seconds with the same result.

I'm not familiar with the "sqlite3" program, so it needed an installation. Then I come so far.

pi@raspberrypi:~$ sqlite3 /var/lib/weewx.sdb

SQLite version 3.16.2 2017-01-06 16:32:41

Enter ”.help” for usage hints.

Sqlite> select dateTime,pressure,barometer,altimeter from archive

- - >

[Yngve Andersson]

The time between two "REC" 01:45:00 - 02:00:00 is exactly 900 seconds. The reading was done manually from the terminal. Also noted that reading values showed "altimeter: None, appTemp: 19.6444928978, barometer: None"

[Yngve Andersson]

Notes on ...

After the Weewx program has stopped (for some reason?) And been turned off for a few hours, I now restart with the command "sudo weewxd weewx.conf".

There is now a list of "REC" with historically stored values ​​from the time weewx stopped. Measurement values ​​displayed here with a range of 60 seconds and up to the current time look correct (see attached print). (WMR300 is initially set to log 1 time/60seconds... if now this may be important?). These historical "REC" are now scrolling to return to normal running ("LOOP" and "REC, every 900 seconds") and now again with "altimeter: None and barometer: None" display.

It's tricky to describe the procedure, but I hope it's understandable.

A thought and wonder from a novice ... if the 60 seconds measured values in the WMR300 are correct why not read and present the nearest historically stored value?

Sincerely Yngve

[Andrew Milner]

Can you post your weewx.conf - with sensitive passwords removed of course.

Weewx can be set to either generate archive records from hardware or generate them by software.  If the hardware rec always has the right data then ensure that in weewx.conf - stdArchive section - you have got record generation set to hardware

60 second archive interval is very small - usually one uses 5 minutes (300 secs) - and may lead to other issues in generating reports etc which is done at the archive interval - so at 60 seconds the reports may start to backlog a little

On Saturday, 20 January 2018 10:41:05 UTC+2, Yngve Andersson wrote:

Notes on ...

After the Weewx program has stopped (for some reason?) And been turned off for a few hours, I now restart with the command "sudo weewxd weewx.conf".

There is now a list of "REC" with historically stored values ​​from the time weewx stopped. Measurement values ​​displayed here with a range of 60 seconds and up to the current time look correct (see attached print). (WMR300 is initially set to log 1 time/60seconds... if now this may be important?). These historical "REC" are now scrolling to return to normal running ("LOOP" and "REC, every 900 seconds") and now again with "altimeter: None and barometer: None" display.

It's tricky to describe the procedure, but I hope it's understandable.

A thought and wonder from a novice ... if the 60 seconds measured values in the WMR300 are correct why not read and present the nearest historically stored value?

Sincerely Yngve

Den lördag 20 januari 2018 kl. 02:12:02 UTC+2 skrev Yngve Andersson:

The time between two "REC" 01:45:00 - 02:00:00 is exactly 900 seconds. The reading was done manually from the terminal. Also noted that reading values showed "altimeter: None, appTemp: 19.6444928978, barometer: None"

Den fredag 19 januari 2018 kl. 22:01:42 UTC+2 skrev Yngve Andersson:

Thank you, mwall for your quick response and dedication!

The time is set to 900 seconds, also tested 1200 seconds with the same result.

I'm not familiar with the "sqlite3" program, so it needed an installation. Then I come so far.

p...@raspberrypi:~$ sqlite3 /var/lib/weewx.sdb

[Yngve Andersson]

Andrew

Ok! has now changed the WMR300 logging interval to 5 minutes. I have waited a period of 900 seconds for the first REC, giving unchanged results.

Attaches weewx.conf as it is running now!

Best regards / Yngve

[Andrew Milner]

The .conf you posted had the interval set to 900 = 15 minutes, not 5, but the station only outputs the pressure every 15 minutes - so perhaps your archive interval needs to be 20-30 minutes in order to contain at least one pressure reading

Does the weather station have its interval set to the same value??

I see that the station only supplies barometer in loop and rec packets, and pressure in loop data and for rec packets weewx has to calculate altimeter and pressure

If you have a long archive interval (eg 30 minutes rather than the 5 i suggested originally), and the station set to the same value, does it help??

[Yngve Andersson]

Andrew

I have now changed the time in weewx.conf to 1800 sec=30 minutes and WMR300 to 15 minutes (WMR300 can only select storage frequency to 1 minute, 5 minutes, 15 minutes and 60 minutes). We wait for results in an hour and then see.

Thank you so much / Yngve

[gjr80]

Matthew,

Would this situation not be able to be resolved if the WMR300 driver was subjected to the (for want of a better term) 'removal of unnecessary output' treatment that the vantage driver was given under 3.7.0? I see there are archive records and loop packets where all 3 'pressures' are None. If we follow the vantage model this should not happen, if or more of these is known any of the missing 'pressures' should be calculated and if all three are unknown (unreported) then all 3 should be omitted from the loop packet/archive record. The user could then use the $latest tag in reports to get the lastest barometer, altitude or pressure and for WU the cached values added in (I think) 3.6.2 should cater for pressure only being reported every 15 minutes.

To me going to a 15 or 30 minute or longer archive period is not much of a solution.

Gary

[Yngve Andersson]

Andrew and Gary

Longer times does not seem to solve the problem of the presentation of pressure!

I have now tried a totally crazy idea without any knowledge, I hope you have an earning with my ignorance ... I set the time weewx.conf back to 300 seconds and the WMR300 logging to 1 minute ... then I manually do the command restart (stop o start) by weewx ?? I have no idea what restart does and when it breaks and restarts program execution, sometimes there is something wrong message, but by the way, the program will be back. I suppose this command entails some mess in program execution depending on where in the program execution is located?

However, tried to give the command at a certain sequence in syslog and after a certain time. Result results in new values ​​being displayed positively and also pressure shows values.

However, this is not a solution to the problem, so ... I'll get even more say that pressure can be read manually on the WMR300 display!

[mwall]

On Saturday, January 20, 2018 at 8:52:44 AM UTC-5, gjr80 wrote:

Matthew,

Would this situation not be able to be resolved if the WMR300 driver was subjected to the (for want of a better term) 'removal of unnecessary output' treatment that the vantage driver was given under 3.7.0? I see there are archive records and loop packets where all 3 'pressures' are None. If we follow the vantage model this should not happen, if or more of these is known any of the missing 'pressures' should be calculated and if all three are unknown (unreported) then all 3 should be omitted from the loop packet/archive record. The user could then use the $latest tag in reports to get the lastest barometer, altitude or pressure and for WU the cached values added in (I think) 3.6.2 should cater for pressure only being reported every 15 minutes.

gary,

- wmr300 emits partial packets

- wmr300 should never emit None for an observation unless there is something wrong with the sensor (i.e., the decode failed)

part of the solution in this case might be to update to the latest restx.py from the repository - it has the insert-None-only-if-independent-variable-is-None fix.  that *might* be less confusing to wu.  but it if there is a hardware/sensor/decoding issue, then we need to see the raw serial output.

i suspect that the stream of valid pressures in wu is due to reading historical values of pressure from the wmr300 logger.

we need to see REC output for 10 or 20 records, but *after* all records from the logger have been read.

then we need to see the 0xd6 pressure packets (by filtering LOOP packets) every 900 seconds.

if current conditions (LOOP packets) always returns None for pressure, then the next step is to see if the hardware is sending 0x7f packets, or if the decoding algorithm is not handling the station pressure properly.  decoding pressure from a 0xd2 history packet is different from decoding pressure from a 0xd6 packet.  the 0xd6 packet contains pressure, barometer, and altitude.  most other hardware only reports a station pressure or a sea level pressure.

 

To me going to a 15 or 30 minute or longer archive period is not much of a solution.

agreed.  i suggest that only to diagnose the problem, not as a long-term solution.

 

[mwall]

yngve,

what is the 'altitude' entered in your wmr300 console?

please try the following:

1) stop weewx

    sudo /etc/init.d/weewx stop

2) ensure that the archive interval in weewx.conf is 300 seconds.  the archive interval of the wmr300 can be anything, but you might want to set it to 5 minutes, just for consistency.

3) run the driver directly, and capture the output

    sudo PYTHONPATH=/usr/share/weewx python /usr/share/weewx/weewx/drivers/wmr300.py --get-current > /var/tmp/wmr300-driver-output.txt

let that run for 30 or 40 minutes.  then ctrl-c to quit.

4) run weewx directly, and capture the output

    sudo /usr/share/weewx/weewxd /etc/weewx/weewx.conf > /var/tmp/wmr300-weewxd-output.txt

let that run for 15 minutes.  then crtl-c to quit.

5) start weewx as usual

    sudo /etc/init.d/weewx start

6) post the two output files (wmr300-driver-output.txt and wmr300-weewxd-output.txt)

this should tell us if there is a difference between pressure in historical records and pressure in live packets.  the driver output will contain only live packets, the weewxd output should contain the historical records and some live packets.

m

[Yngve Andersson]

Ok ... I'll be back tomorrow

Thanks / Yngve

[Yngve Andersson]

mwall

I have now started up for the day!

The height of the WMR300 is set to 10 meters!

Attaches read files:

Unfortunately, the logging of "wmr300-weewxd-output.txt" was canceled too soon!

wmr300-driver-output.txt

wmr300-weewxd-output.txt

/ yngve

Den lördag 20 januari 2018 kl. 20:03:41 UTC+2 skrev mwall:

[Cameron D]

Hello Yngve,

I don't think the time interval should make a problem - I have been running 3.7.1 for ages at 1 minute log interval.

The Wunderground station is IBRISBAN102 . 

Rapidfire is off.

log_success = False

DIsplayed data is updated once a minute (as seen on the Wunderground web page), but it only saves data every 5 minutes.  I'm not sure if I have any control over that.

I don't think I have ever lost a pressure reading.

Curiously, the Wunderground pressure displayed does not agree precisely with the weewx data, but I think that relates to rounding errors as it is converted to US units and back to metric.

I see this morning you presumably restarted weewx and loaded 1-minute interval history data from 6:40 to 9:54. Then again from 10:20 to 10:40.

Soon I will be upgrading to 3.8.0 so we will see how that goes.

Cameron.

[Cameron D]

If you look at my data from 16-Jan-2018, when the house lost power from approx 7:00 until 10:00, you will see the same effect - history results from the battery-backed console are logged on Wunderground at one-minute intervals.

On Sunday, 28 January 2018 16:21:36 UTC+10, Cameron D wrote:

......

I see this morning you presumably restarted weewx and loaded 1-minute interval history data from 6:40 to 9:54. Then again from 10:20 to 10:40.

...

[Yngve Andersson]

Hello Cameron!

Thank you for your dedication. Missing info at your weather station, for example, where you run the program from.

It's very frustrating that the air pressure is not presented! As I note, however, the print information is retrieved from the sensor and stored during the weewx run, but then lost during the process and not sent further and becomes available for presentation. Other weather information appears to be present and presented without remark, even under "localhost, (barometer = N / A)".

Let me mention that when i do the "sudo /etc/init.d/weewx restart" command, the air pressure is displayed once and then returns to no view.

My system is:

-Water station Oregon WMR300

-cpu controls are "RaspberryPi Model B Revision 2.0 512MB 000e" with Raspbian

-installed program is "weewx_3.8.0-1_all.deb"

-Driver is "wmr300.py version 0.19rc5", the latest updated version that I found. I have tested all versions that I search and found online, but without positive results.

My station is posted and can be seen in following places:

https://www.pwsweather.com/obs/NORDENS.html

https://www.awekas.at/en/instrument.php?id=14340#day

https://www.wunderground.com/personal-weather-station/dashboard?ID=IKUMLING2#history

OK, action!

Switch computer from RaspberryPi to my desktop computer with Linux Mint18.3, run the same version of weewx and the files weeewx.conf, "wmr300.py version 0.19rc5" as for Raspberry.

After some time, all values ​​are displayed correctly, so even the air pressure!

So, the issue of air pressure is related to RaspberryPi that conflicts with the WMR300! Too bad ... it would be useful to have RaspberryPi + WMR300 together as communication to the internet.

/ Yngve

[sina...@gmail.com]

Hi yngve, can you make rapidfire true for me? I wanna see how it will send data to wunderground. Thanks

[Cameron D]

Hello Yvgne,

my system logs to a CentOS 6 server that is always on.

Are you able to check the database that all three pressures are being recorded? 

Mine has pressure, barometer and altimeter.  Maybe the system uses one to display to you, but another to report to Weatherunderground.

With regard to rapidfire, I tried it once and it did not work (cannot remember details). However I can see wind gust speeds being updated every minute, but I don't notice the direction changing.

If I look at the Wunderground data table, there is no gust direction data, and even average wind is only stored to coarse compass bearings, so it is not surprising to see no change.

Cameron.

[Yngve Andersson]

Hey!

I have logged the following information from Raspberry and WMR300 with command:

sudo PYTHONPATH=/usr/share/weewx python /usr/share/weewx/weewx/drivers/wmr300.py --get-current> /var/tmp/wmr300-driver-output.txt

and

sudo /usr/share/weewx/weewxd /etc/weewx/weewx.conf> /var/tmp/wmr300-weewxd output.

Attach these:

It's not just a problem with information going to wunderground, etc. ..., it's also the presentation on the local host (Raspberry)!

/ Yngve

[Cameron D]

They are quite odd readings.. Do you really have cloudbase and solar radiation meters?

If not then maybe the mappings have gone awry? 

Matthew will have  a much  better idea than me.

Cameron.

[Yngve Andersson]

Hi sinantc34!

I have now put true on rapidfire in weewx.conf. I have no idea what rapidfire does?

Thank you for helping Yngve

Den måndag 29 januari 2018 kl. 00:45:40 UTC+2 skrev sina...@gmail.com:

[Yngve Andersson]

Hi Cameron!

The station WMR300 is standard, no extra sensors!

I joined WMR300 yesterday 28 Jan 3:15 pm to my desktop computer Mint 18.3 and seems to have worked OK! Joined RaspberryPi today 29 Jan 4:30 pm and now with no air pressure.

So it is obvious that my RaspberyPi does not fully work out!

Thanks! Yngve

[Andrew Milner]

have you checked that weewx.conf is IDENTICAL on both systems?

[Yngve Andersson]

Hello Andrew!

There is a certain difference of weewx.conf between Raspberry and Mint18.3! I do not know if the difference is important?

I've been trying to make changes and additions that I found to try to fix the problem. There have been many tests over and over again when I signed in and tested. So, therefore, there has been a difference in the files. You'll see if the difference is significant?

I will copy "Raspberry, weewx.conf" and run it in Mint18.3

Attaches both files weewx.conf

Thank you, for your dedication Yngve

[Yngve Andersson]

Andrew!

weewx.conf

Den måndag 29 januari 2018 kl. 17:57:26 UTC+2 skrev Andrew Milner:

[Andrew Milner]

If you are trying to compare why weewx works ok on one system and not the other then I suggest you make sure that weewx.conf and skin.conf files are the same.  If there are differences then I have to ask you why they are different.  You cannot compare two systems if the conf files are different!!!!  The only differences should be related to paths to files - in all other respects they should be identical.  

What are the differences??

[Cameron D]

Yngve,

you have rapidfire enabled on the pi - I would first turn that off.

Also disable cumulusrealtime and see if that is related.  It might be the combination of both factors.

[Yngve Andersson]

Hello Andrew and others!

I have now found the problem of strange views of, among other things, air pressure. After your point of view of the importance of the inequality of non functioning and functioning systems with the weewx.conf and skin.conf files, I have found aberration and a significant error in weewx.conf. I do not know if [CumulusRealTime] is significant and can result in problems?

[Engine]

[[Services]]

^{Raspberry Pi}

process_services = weewx.engine.StdConvert, weewx.engine.StdCalibrate, weewx.engine.StdQC, weewx.wxservices.StdWXCalculate, user.crt.CumulusRealTime

^{mint 18}

process_services = weewx.engine.StdConvert, weewx.engine.StdCalibrate, weewx.engine.StdQC, weewx.wxservices.StdWXCalculate

^{Raspberry Pi}

restful_services = weewx.restx.StdStationRegistry, weewx.restx.StdWunderground, weewx.restx.StdPWSweather, weewx.restx.StdCWOP, weewx.restx.StdWOW, weewx.restx.StdAWEKAS, user.wcloud.WeatherCloud # user.wcloud.WeatherCloud

^{mint 18}

restful_services = weewx.restx.StdStationRegistry, weewx.restx.StdWunderground, weewx.restx.StdPWSweather, weewx.restx.StdCWOP, weewx.restx.StdWOW, weewx.restx.StdAWEKAS, user.wcloud.WeatherCloud

^{Raspberry Pi}

[CumulusRealTime]

filename = /var/tmp/realtime.txt

For the skin.conf file in RaspberryPi, I had changed the display to "meter, C, mm ,, m/s" under

[Units]

[[Groups]]

This may not be necessary if they are enrolled in weewx.conf? So now, skin.conf is also switched to the original version.

The configurations of the files (in original) now work with RaspberryPi as well as for mint18. RaspberryPi has now worked since yesterday 8:00 pm

I do not know exactly how I managed to accomplish this mismatch and this problem, but probably it's a result of my somewhat ignorant way of trying to fix something that went wrong. I think that was when I tried to change the display of the pressure to mbar.

I am very grateful for all your help and regret that I have asked for something that really should not be a problem, if you are careful about what you do.

Thank you so much to all of you! Andrew, Cameron, gjr80, mwall, sinantc34

Yngve

[Andrew Milner]

Good to hear that both systems are now doing the same thing, and working as you expect - in that respect it is progress!!  If you try with the cumulus realtime extension again - just change one thing at a time to avoid confusion!!  If you change many things at once it becomes very very difficult to pinpoint a problem.

[Yngve Andersson]

Cameron!

What is the meaning of rapidfire? I have put it active now!

Yngve

[Andrew Milner]

http://wiki.wunderground.com/index.php/Troubleshooting_-_Rapid_fire

[Andrew Milner]

and also:

http://wiki.wunderground.com/index.php/PWS_-_Upload_Protocol#RapidFire_Updates