matthewwall / weewx-sdr

weewx driver for software-defined radio
GNU General Public License v3.0
114 stars 74 forks source link

need help - weewx not receiving data from weewx-sdr #126

Closed mrneutron42 closed 3 years ago

mrneutron42 commented 3 years ago

I'm trying to get weather data from an Accurite Atlas into weewx via rtl_433 and weewx-sdr.

The people on the weewx-user Google Group are telling me that weewx is not creating an html report page because it's not getting data into its database from weewx-sdr. see: https://groups.google.com/g/weewx-user/c/yejkXG-_uZo

I installed weewx into a Ubuntu 20 virtual machine via the "setup.py" method: https://weewx.com/docs/setup.htm rtl_433 was compiled from the current source code in github. It is working and parses the Atlas data correctly. I followed the setup instructions for weewx-sdr and believe it's working right. When I run the following command, I see bursts of weather sensor data from the Acurite Atlas every 10-20 seconds.
sudo PYTHONPATH=/home/weewx/bin python3 /home/weewx/bin/user/sdr.py --cmd="rtl_433 -R 40 -M utc -F json" Does this prove that weewx-sdr is configured correctly?

out:['{"time" : "2021-04-27 16:20:22", "model" : "Acurite-Atlas", "id" : 17, "channel" : "A", "sequence_num" : 1, "battery_ok" : 1, "message_type" : 39, "wind_avg_mi_h" : 0.000, "uv" : 0, "lux" : 0, "strike_count" : 2, "strike_distance" : 8, "exception" : 0, "raw_msg" : "c411e700000000004804"}\n', '{"time" : "2021-04-27 16:20:22", "model" : "Acurite-Atlas", "id" : 17, "channel" : "A", "sequence_num" : 2, "battery_ok" : 1, "message_type" : 39, "wind_avg_mi_h" : 0.000, "uv" : 0, "lux" : 0, "strike_count" : 2, "strike_distance" : 8, "exception" : 0, "raw_msg" : "c811e700000000004808"}\n']
parsed: {'dateTime': 1619540422, 'usUnits': 1, 'model.0011.AcuriteAtlasPacket': 'Acurite-Atlas', 'channel.0011.AcuriteAtlasPacket': 'A', 'sequence_num.0011.AcuriteAtlasPacket': 1, 'message_type.0011.AcuriteAtlasPacket': 39, 'wind_speed.0011.AcuriteAtlasPacket': 0.0, 'uv.0011.AcuriteAtlasPacket': 0, 'lux.0011.AcuriteAtlasPacket': 0, 'battery.0011.AcuriteAtlasPacket': 0}
parsed: {'dateTime': 1619540422, 'usUnits': 1, 'model.0011.AcuriteAtlasPacket': 'Acurite-Atlas', 'channel.0011.AcuriteAtlasPacket': 'A', 'sequence_num.0011.AcuriteAtlasPacket': 2, 'message_type.0011.AcuriteAtlasPacket': 39, 'wind_speed.0011.AcuriteAtlasPacket': 0.0, 'uv.0011.AcuriteAtlasPacket': 0, 'lux.0011.AcuriteAtlasPacket': 0, 'battery.0011.AcuriteAtlasPacket': 0}
out:['{"time" : "2021-04-27 16:20:32", "model" : "Acurite-Atlas", "id" : 17, "channel" : "A", "sequence_num" : 0, "battery_ok" : 1, "message_type" : 37, "wind_avg_mi_h" : 0.000, "temperature_F" : 68.300, "humidity" : 42, "strike_count" : 2, "strike_distance" : 8, "exception" : 0, "raw_msg" : "c011650088bbaa00486b"}\n', '{"time" : "2021-04-27 16:20:32", "model" : "Acurite-Atlas", "id" : 17, "channel" : "A", "sequence_num" : 1, "battery_ok" : 1, "message_type" : 37, "wind_avg_mi_h" : 0.000, "temperature_F" : 68.300, "humidity" : 42, "strike_count" : 2, "strike_distance" : 8, "exception" : 0, "raw_msg" : "c411650088bbaa00486f"}\n', '{"time" : "2021-04-27 16:20:32", "model" : "Acurite-Atlas", "id" : 17, "channel" : "A", "sequence_num" : 2, "battery_ok" : 1, "message_type" : 37, "wind_avg_mi_h" : 0.000, "temperature_F" : 68.300, "humidity" : 42, "strike_count" : 2, "strike_distance" : 8, "exception" : 0, "raw_msg" : "c811650088bbaa004873"}\n']

I pieced together my weewx.conf by from reading posts in the rtl_433 Google Group. I guessed that ID number 17 would be 0017 in the [sensor_map] section of the weewx.conf file ? Could someone can look it over for corrections? weewx.conf.zip

Topslakr commented 3 years ago

Your issue is the way you created the sensor_maps. You should not have to 'guess' the values. The ones you need are in the 'parsed' lines:

parsed: {'dateTime': 1619540422, 'usUnits': 1, 'model.0011.AcuriteAtlasPacket': 'Acurite-Atlas', 'channel.0011.AcuriteAtlasPacket': 'A', 'sequence_num.0011.AcuriteAtlasPacket': 1, 'message_type.0011.AcuriteAtlasPacket': 39, 'wind_speed.0011.AcuriteAtlasPacket': 0.0, 'uv.0011.AcuriteAtlasPacket': 0, 'lux.0011.AcuriteAtlasPacket': 0, 'battery.0011.AcuriteAtlasPacket': 0}

Your weewx.conf says: uv.0017.AcuriteAtlasPacket, but it should say uv.0011.AcuriteAtlasPacket, for instance.

WeeWx will ONLY see the 'parsed' info, so you'll need to run

sudo PYTHONPATH=/home/weewx/bin python3 /home/weewx/bin/user/sdr.py --cmd="rtl_433 -M utc -F json"

long enough for you to get the right values for the sensor_map.

Does that make sense? You can also likely drop the '-R 40' part as well, to make sure you're seeing everything.

mrneutron42 commented 3 years ago

Yep. I understand. Thanks for the pointers. I was looking at unparsed data. That's where the 17 came from. I'm editing the sensor_map now.

Is there a how-to document that details how to create the sensor map? I didn't see one.

Eric

Topslakr commented 3 years ago

To be honest, I stumbled my way through all this as well... I used the below guide, and about 20 years in IT, to get across the line.

https://github.com/ChrisM510/AtlasWeeWX/wiki/Acurite-Atlas-on-WeeWX-RTL-SDR-RTL_433-RPi-(Page-1)

I'm not aware of any official guide...

mrneutron42 commented 3 years ago

I'm seeing info types in the data that start with "out:" that do not appear in the parsed data, such as strike_count, strike_distance, wind_ave_m_h. This is the unparsed data? Are those variables not being processed by the parser? Is the parser in rtl_433?

out:['{"time" : "2021-04-27 18:05:05", "model" : "Acurite-Atlas", "id" : 17, "channel" : "A", "sequence_num" : 0, "battery_ok" : 1, "message_type" : 37, "wind_avg_mi_h" : 0.000, "temperature_F" : 68.000, "humidity" : 42, "strike_count" : 2, "strike_distance" : 8, "exception" : 0, "raw_msg" : "c011650088b8aa004868"}\n', '{"time" : "2021-04-27 18:05:05", "model" : "Acurite-Atlas", "id" : 17, "channel" : "A", "sequence_num" : 1, "battery_ok" : 1, "message_type" : 37, "wind_avg_mi_h" : 0.000, "temperature_F" : 68.000, "humidity" : 42, "strike_count" : 2, "strike_distance" : 8, "exception" : 0, "raw_msg" : "c411650088b8aa00486c"}\n', '{"time" : "2021-04-27 18:05:05", "model" : "Acurite-Atlas", "id" : 17, "channel" : "A", "sequence_num" : 2, "battery_ok" : 1, "message_type" : 37, "wind_avg_mi_h" : 0.000, "temperature_F" : 68.000, "humidity" : 42, "strike_count" : 2, "strike_distance" : 8, "exception" : 0, "raw_msg" : "c811650088b8aa004870"}\n']

From some of the example [sensor_map] sections I've seen, it looks like those unparsed variable names can get tacked onto the ".0011.AcuriteAtlasPacket" suffix? Example: wind_ave_mi_h.0011.AcuriteAtlasPacket

Topslakr commented 3 years ago

Looking at my output now too.

I usually let it run for two minutes or more, and dump into a file. The system outputs data at different intervals so you have to be a bit patient.

I'd run something like:

sudo PYTHONPATH=/home/weewx/bin python3 /home/weewx/bin/user/sdr.py --cmd="rtl_433 -M utc -F json" > output which will dump the data into a file called 'output' in the current directory. You can then parse through it easier.

Doing that nets me several different 'parsed' style lines:

parsed: {'dateTime': 1619548292, 'usUnits': 1, 'model.0362.AcuriteAtlasPacket': 'Acurite-Atlas', 'channel.0362.AcuriteAtlasPacket': 'A', 'sequence_num.0362.AcuriteAtlasPacket': 2, 'message_type.0362.AcuriteAtlasPacket': 37, 'temperature.0362.AcuriteAtlasPacket': 65.2, 'humidity.0362.AcuriteAtlasPacket': 13.0, 'wind_speed.0362.AcuriteAtlasPacket': 9.0, 'battery.0362.AcuriteAtlasPacket': 1}

parsed: {'dateTime': 1619548312, 'usUnits': 1, 'model.0362.AcuriteAtlasPacket': 'Acurite-Atlas', 'channel.0362.AcuriteAtlasPacket': 'A', 'sequence_num.0362.AcuriteAtlasPacket': 0, 'message_type.0362.AcuriteAtlasPacket': 39, 'wind_speed.0362.AcuriteAtlasPacket': 13.0, 'uv.0362.AcuriteAtlasPacket': 4, 'lux.0362.AcuriteAtlasPacket': 64840, 'battery.0362.AcuriteAtlasPacket': 1}

Allowing a couple of minutes of run time allows each data point to be gathered, which should get you what you need.

matthewwall commented 3 years ago

Is there a how-to document that details how to create the sensor map?

this might help:

https://github.com/weewx/weewx/wiki/sdr-rpi-recipe

i will install an acurite atlas within the next three weeks. i will document that in a separate wiki page similar to the sdr-rpi-recipe.

apologies for such a prolonged radio silence on this - my 'real job' has been rather demanding.

mrneutron42 commented 3 years ago

I just did a capture of the Acurite Atlas signals with: sudo PYTHONPATH=bin python3 bin/user/sdr.py --cmd="rtl_433 -M utc -F json" > Atlas-data.txt

I do not see the barometer data in the attached captured file, but I know the Atlas is sending it, because it shows up on the external display panel. Is it hidden in some other value? Atlas-data.txt

Topslakr commented 3 years ago

Aaah.. Now here's a fun 'feature'. The Atlas does NOT have a barometer. The External display, in fact, has the barometer built in. I run my system without the Atlas display, and have a different barometer for my system. I'm not sure if the display broadcasts that data...

mrneutron42 commented 3 years ago

I have the simplest (no-wifi, no-usb) color display - Acurite model 06061.
It just receives and displays - no external connectors. My intention was to receive all the Acurite Atlas data with the SDR and send it to weewx.

Topslakr commented 3 years ago

Incredible as it may seem, the Acurite Atlas outdoor unit does NOT have a barometer or method for measuring pressure. The pressure reading you see on your display is generated from the display itself. You can look at page 11 in the manual for information about it.. however minimal. There should be some basic calibration settings in the display for it.

To your point, the display doesn't broadcast that information out so there is no way to 'capture' the pressure info via the rtl_433 process.

I used a WH32B to broadcast that information. Sadly, it does so on 915Mhz, but the SDR.py app can be set to channel hop at an interval so I'm able to capture all the data I need.

This was a big disappointment for me as well...

mrneutron42 commented 3 years ago

Did you notice that there are duplicate readings coming from the Atlas?

I see 2 rain reports (both the rain total for the day?): "rain_in" : 0.170, 'rain_total.0011.AcuriteAtlasPacket': 0.17, Which one should be used?

I also see 2 wind direction readings: "wind_dir_deg" : 183.000, 'wind_dir.0011.AcuriteAtlasPacket': 183.0, Which one should be used?

Thus far, the wind direction data in the weewx webpage is all 0. But, I can see the data getting sent.

That wview.py file shows us the data fields that weewx is sending to the SQLite database? It looks like we can add new data fields to the database, such as lightning strikes?

Topslakr commented 3 years ago

Use ONLY the one in the 'parsed' line. It should be named for the data type, and then have '.0011.AcuriteAtlasPacket' after it.

rain_total.0011.AcuriteAtlasPacket is correct. 'rain_in' is the raw broadcast.

matthewwall commented 3 years ago

you can extend wview.py schema, but better to use the wview_extended.py schema (which is the default for any new weewx installations). it already has lightning counts. all you have to do is map from the 'parsed' names to the schema names in the sdr [sensor_map]

matthewwall commented 3 years ago

be sure to read to note about deltas in the sdr documentation (either the README or the docsys string at the beginning of sdr.py)

mrneutron42 commented 3 years ago

Out-of-the-box, the weewx webpage does not have any lightning graphs. How do we change the contents of the weewx webpage? Change the skin name in the weewx.conf file?

matthewwall commented 3 years ago

How do we change the contents of the weewx webpage? Change the skin name in the weewx.conf file?

copy the Seasons skin, then extend it to include whatever current values, historical reports, and graphs that you want.

see the contents of the Seasons skin.conf and template files - its pretty obvious

see the weewx customization guide for the syntax and formatting options for getting data from database tables by name

see the weewx customization guide for options/syntax/tips about how to define graphs.

mrneutron42 commented 3 years ago

THANKS ALL for all the hints that led to the breaktrough in functionality! The problem is solved so, I will close the issue.