Installed extension and edited config, but still shows simulator

[Timothy Buchanan]

I set up a WeatherFlow station per their instructions, and it is feeding correct data to their app. I installed the weatherflowudp extension (using a Pi3), and wee_extension --list shows Version 1.03 as installed. There is a file weatherflowudp.py in /usr/share/wewx/user. I edited the /etc/weewx/weewx.conf as so:

# Set to type of station hardware. There must be a corresponding stanza

    # in this file with a 'driver' parameter indicating the driver to be used.

    # station_type = Simulator

    station_type = WeatherFlowUDP

[WeatherFlowUDP]

    driver = user.weatherflowudp

    log_raw_packets = False

    udp_address = <broadcast>

    # udp_address = 0.0.0.0

    # udp_address = 255.255.255.255

    udp_port = 50222

    udp_timeout = 90

    share_socket = False

    

    [[sensor_map]]

        outTemp = air_temperature.AR-00004444.obs_air

        outHumidity = relative_humidity.AR-00004444.obs_air

        pressure = station_pressure.AR-00004444.obs_air

        # lightning_strikes =  lightning_strike_count.AR-00004444.obs_air

        # avg_distance =  lightning_strike_avg_distance.AR-00004444.obs_air

        outTempBatteryStatus = battery.AR-00004444.obs_air

        windSpeed = wind_speed.SK-00001234.rapid_wind

        windDir = wind_direction.SK-00001234.rapid_wind

        # lux = illuminance.SK-00001234.obs_sky

        UV = uv.SK-00001234.obs_sky

        rain = rain_accumulated.SK-00001234.obs_sky

        windBatteryStatus = battery.SK-00001234.obs_sky

        radiation = solar_radiation.SK-00001234.obs_sky

# lightningYYY = distance.AR-00004444.evt_strike

# lightningZZZ = energy.AR-00004444.evt_strike

Yet when I start weewx, it still shows the simulator. The page is available at millennialhouse.mynetgear.com/weewx/ for viewing.

The file at /var/log/syslog shows the weewx in listening for UDP at <broadcast> on port 50222, but times out.

What have I neglected to do? Thanks for help.

[mwall]

On Sunday, October 13, 2019 at 1:04:09 PM UTC-4, Timothy Buchanan wrote:

Yet when I start weewx, it still shows the simulator. The page is available at millennialhouse.mynetgear.com/weewx/ for viewing.

The file at /var/log/syslog shows the weewx in listening for UDP at <broadcast> on port 50222, but times out.

What have I neglected to do? Thanks for help.

what does the log say?  please post the log contents, not your summary of it.

https://www.youtube.com/watch?v=jofNR_WkoCE

(sorry, the younger nieces and nephews *still* keep playing that video over and over again, and i cannot help but think that we need a "what does the log say?" soundtrack for weewx :)

m 

[Timothy Buchanan]

Attached syslog file.

[vince]

On Sunday, October 13, 2019 at 10:04:09 AM UTC-7, Timothy Buchanan wrote:

I set up a WeatherFlow station per their instructions, and it is feeding correct data to their app. I installed the weatherflowudp extension (using a Pi3), and wee_extension --list shows Version 1.03 as installed. There is a file weatherflowudp.py in /usr/share/wewx/user. I edited the /etc/weewx/weewx.conf as so:

The file at /var/log/syslog shows the weewx in listening for UDP at <broadcast> on port 50222, but times out.

What have I neglected to do? Thanks for help.

I'm not quite seeing anything obvious.

If you're comfortable running python stuff, you could try running my standalone WeatherFlow UDP listener to verify your gear is hearing the broadcast messages (which would validate the pi, taking weewx out of the question for the moment)

• change share_socket to True so the weewx extension can let other apps listen for the broadcasts simultaneously
• stop weewx (for now)

• grab my listener from https://github.com/vinceskahan/weatherflow-udp-listener and follow the Installation instructions
• you can run it via "python listen.py --raw" to have it just dump what it sees to the screen.  You'll see wind info in 3 secs if you have rapid_wind enabled, but you'll see hub status in 10 secs or so regardless.  If 'anything' is reported then your pi is hearing the broadcasts and we can move back to validating weewx.
• hit control-C to stop it (you might need to hit that twice) 

[Timothy Buchanan]

This is the output from listen --raw. It keeps repeating these lines.

[Timothy Buchanan]

And here is the weewx.conf file.

[mwall]

On Sunday, October 13, 2019 at 1:43:31 PM UTC-4, Timothy Buchanan wrote:

Attached syslog file.

please send the log starting just before weewx starts up 

[Timothy Buchanan]

weewx runs as a daemon on boot here, so I used sudo /etc/init.d/weewx stop, then started it again. I attach an extract of syslog from the stop/start for some minutes after. it looks like weewx starts properly and begins to listen, but never gets data or times out.

I attached wewx.conf to an earlier posting; perhaps someone who has a working WeatherFlow setup can look at that.

I used Vince's listen script and the output from that is attached to an earlier posting. The rpi seems to be getting hub information but no sensor data.

All help is greatly appreciated.

[Timothy Buchanan]

I've now run listen with -d set and got these attached results. It does seem as if the rpi is picking up the UDP packets, but not displaying them. Also, the web page continues to say "Simulator."

On Sunday, October 13, 2019 at 12:47:45 PM UTC-6, vince wrote:

[gjr80]

You can ignore the 'Simulator' web page, it is an old page generated from when you were running the simulator. It is clear from the log WeeWX is using the weatherflow driver. WeeWX is not receiving any data from the driver so hence no archive records are produced and hence no reports being produced/updated. Once you have data it will be fine.

Gary

[Timothy Buchanan]

The station is producing data. I can see it in the WFapp, and on the WF online map. The rpi is apparently picking up UDP packets per the python listen script. So why is WeeWx "not receiving any data?" Any leads to troubleshooting this would be appreciated.

[gjr80]

Never said the station wasn’t producing data. You asked why ‘Simulator’ is still being shown, it is simply a symptom of WeeWX not receiving data from the driver.

Gary

[Timothy Buchanan]

Yes, thanks, I understand that. How can I find out why WeeWx is not receiving data?

[Andrew Milner]

how about attaching a log from when you start weewx until atleast two archive intervals have passed.  The last log you posted did not show weewx starting

[mwall]

On Sunday, October 13, 2019 at 11:01:00 PM UTC-4, Timothy Buchanan wrote:

Yes, thanks, I understand that. How can I find out why WeeWx is not receiving data?

first of all, you need to use your own sensor identifiers, not the ones from the example.  set 'log_raw_packets = True' in the wf configuration stanza in weewx to figure out your sensor identifiers.  you'll want to set it back to False after you get the identifiers.

as for the timeouts, that probably indicates that you specified the wrong port, or your network is blocking the udp broadcasts (is the computer on which you run weewx on the same network segment as the weatherflow hardware?), or a firewall is blocking the udp (are you running a firewall on the computer on which weewx is running?)

if you are seeing data when you run vince's script, and you are running that on the same computer on which you run weewx, then compare the settings in the script with the settings you have for weatherflow in weewx.  the difference should be obvious.

m 

[mwall]

perhaps try 0.0.0.0 as the address.  or maybe '' as the address (that is what the listen script defaults to)

btw, you can see your serial numbers in the listen output.  you should use those in the weatherflowudp sensormap in your weewx.conf

m

[vince]

On Sunday, October 13, 2019 at 12:41:08 PM UTC-7, Timothy Buchanan wrote:

This is the output from listen --raw. It keeps repeating these lines.

Yes - that says your pi is indeed receiving the data that is broadcast from the station.

The problem is your weewx.conf file config settings.   The map is wrong.

Your sky serial number is SK-00017445 and your air serial number is AR-00017660 from the --raw output.

You have to edit 'your' values into the weewx.conf file.  That's the issue.   Edit the file, restart weewx, and you should be good to go.

[Timothy Buchanan]

Thank you Vince and mwall for pointing out that I needed to change the sensor serial numbers in config. I did that but unhappily it's still not working. Before I had to leave I set weewx to log raw packets. When I get back I'll post the syslog for two or more archive periods.

[Timothy Buchanan]

Ok, here is an extract from the syslog, from 14:04:53 when weewx started, to 14:26:20 when it stopped. It was running as daemon with log raw packets true. Also attached is the weewx.conf file. What can you tell from these? Thanks.

[vince]

On Monday, October 14, 2019 at 4:27:11 PM UTC-7, Timothy Buchanan wrote:

Ok, here is an extract from the syslog, from 14:04:53 when weewx started, to 14:26:20 when it stopped. It was running as daemon with log raw packets true. Also attached is the weewx.conf file. What can you tell from these? Thanks.

Looks like it's hearing the station quite fine.   What is the problem at this time ?

My guess (guess) is that you have your weewx.conf set to put the output in one place, and your web server (if there is one installed) to look in a different place for the data.

This is a very unusual place for HTML files

HTML_ROOT = /var/weewx/reports

See if there is anything in there with current timestamps.  Open the index.html there in a browser and see what it looks like.

[Timothy Buchanan]

I was following nginx server instructions I found, which were as follows:

1. At this point WeeWX is technically installed, however many individuals will want to present the WeeWX reports via webpage.  In this case, we’ll install nginx, which is a lightweight webserver
   1. sudo apt-get install nginx
      1. More details on this can be found here: http://www.weewx.com/docs/usersguide.htm#integrating_with_webserver
2. Configure WeeWX to minimize disk IO
   1. Why do we need to do this?  Since Raspberry PI’s leverage SD cards, there is typically a finite number of reads/writes to the SD Card.  In this case, it is recommended to either leverage an external database/fileserver for WeeWX to write its reports.  Alternatively, we can also configure WeeWX to leverage ram to host the reports, which will prevent IO to the SD card (in this case, theoretically increasing the life of the drive)
      1. Three approaches are outlined here–in this guide I’ll reflect the GitHub page in saving reports to a temporary file system using tmpfs
         1. Add an entry to fstab

            1. echo "weewx_reports /var/weewx/reports tmpfs size=20M,noexec,nosuid,nodev 0 0" | sudo tee -a /etc/fstab

         2. Mount the new file system
            1. sudo mkdir -p /var/weewx/reports
            2. sudo mount -a
         3. Update weewx.config file to point to new directory

            1. sudo sed -i -e 's%HTML_ROOT =.*%HTML_ROOT = /var/weewx/reports%' /etc/weewx/weewx.conf

         4. Restart WeeWX service
            1. sudo service weewx restart
         5. Create symbolic link to point webserver to the reports
            1. sudo ln -s /var/weewx/reports /var/www/html/weewx
         6. Give the web server the ability to read from the directory
            1. sudo chmod -R 755 /var/www/html/weewx

At this point, go ahead and browse out to http://youripaddress/weewx/ to see your weather. (end)

Should I try to undo all this, and where should the html files be?

I have looked at the index.html in the following directories:

/home/weewx/public_html/index.html

/var/wewx/reports/index.html

/var/www/html/wewx/index.html

They each show the same simulator page. Where else can I look?

Where could I look to see if there are reports, without going through a web page? If I can see data that weewx is collecting then I'll worry about how to get it into a web page.

thanks again.

[Timothy Buchanan]

I answered my last question by myself. starting weewx not as daemon gives me data. everything seems to be there except pressure, altimeter and barometer. That may have to do with the altitude here (8500 feet), although I put that into the config file. If you can advise me where index.html normally is kept (the main directory is /home/weewx), then I will try to figure out how to get nginx to look there.

On Monday, October 14, 2019 at 6:17:58 PM UTC-6, vince wrote:

[gjr80]

The reason you cannot find any reports is that none are being produced, you need to look back earlier to see why. These lines indicate that WeeWX is saving something to the database:

Oct 14 14:05:17 raspberrypi weewx[8036]: manager: Added record 2019-10-14 14:05:00 MDT (1571083500) to database 'weewx.sdb' 
Oct 14 14:05:18 raspberrypi weewx[8036]: manager: Added record 2019-10-14 14:05:00 MDT (1571083500) to daily summary in 'weewx.sdb'

That is a step forward from yesterday. There should be some lines similar to these appear next as the WeeWX report cycle executes, what you see will depend on your system but there should be something not nothing:

Oct 13 06:25:22 aurora weewx[21977]: cheetahgenerator: Generated 6 files for report SeasonsAuroraReport in 1.28 seconds
Oct 13 06:25:23 aurora weewx[21977]: imagegenerator: Generated 7 images for SeasonsAuroraReport in 0.52 seconds
Oct 13 06:25:23 aurora weewx[21977]: copygenerator: copied 0 files to /home/weewx/public_html
Oct 13 06:25:24 aurora weewx[21977]: rsyncupload: rsync'd 13 files (120,985 bytes) in 0.88 seconds

The following indicates you have an issue with pressure data from the station/driver:

Oct 14 14:05:26 raspberrypi weewx[8036]: engine: 2019-10-14 14:05:24 MDT (1571083524) LOOP value 'pressure' 21.92306272 outside limits (24.0, 34.5)

Could be anyone of a number of issues but I would leave that for the moment and get WeeWX working with the driver and producing output.

I would edit weewx.conf and set debug = 1, save weewx.conf and restart WeeWX. Let WeeWX run for a couple of archive periods and then post the log from startup making sure you include the WeeWX startup sequence and the couple of archive periods of activity. You might want to set log_raw_packets = False under [WeatherFlowUDP] in weewx.conf to cut down a bit of log output, setting debug = 1 will make the log more chatty.

Gary

[vince]

On Monday, October 14, 2019 at 7:03:25 PM UTC-7, gjr80 wrote:

The following indicates you have an issue with pressure data from the station/driver:

Oct 14 14:05:26 raspberrypi weewx[8036]: engine: 2019-10-14 14:05:24 MDT (1571083524) LOOP value 'pressure' 21.92306272 outside limits (24.0, 34.5)

He indicated he's at 8500 feet elevation (wow) so that is likely related.  Personally I'd just up the limits that are acceptable.

Agree with debug=1 as the next step of course.

[Timothy Buchanan]

Thanks to the patient help and advice from many members here, I now have the weewx web page running and displaying data, though it still needs some tuning. My problems were from three sources:

1. I didn't know about setting the sensor parameters in the driver configuration, though it is obvious in retrospect. After that, I got packets, but nothing changed on the web page.

2. The instructions I found for saving weewx reports to a RAM file may have been misleading. I deleted all that and, for good measure, purged and re-installed weewx.

3. The lower pressure limit was far too high for Colorado. I set it to 18.

Now I have a working web page. Most data is the same or very close to what is shown in the WF app, except for barometric pressure which is way off. The app shows 30.274 now, for example, while weewx shows 29.766. I have the weewx altitude and the WF sensor altitude set to the same value, 8475 feet (both sensors are on the ground now). What adjustments need to be made here?