Author Topic: Wunderground Rapid Fire  (Read 10568 times)

0 Members and 1 Guest are viewing this topic.

Offline mwall

  • Contributor
  • ***
  • Posts: 135
Re: Wunderground Rapid Fire
« Reply #25 on: January 16, 2017, 06:57:32 PM »
Ugh!  That didn't last long.  :(  I'm generating pressure and inTemp from a Service that I wrote, since the 5-in-1 doesn't have a barometer.  For some reason, the new JSON code is apparently taking "none" from the LOOP packets rather than the service's data for pressure.  inTemp still seems to be working.  Falling back to non-JSON, since I have an appointment that I have to leave for right now.....

how are you injecting pressure into loop packets?  weewx-sdr reports only what it gets from the hardware, and nothing has changed in that respect.  if you add a pressure to a loop packet emitted by weewx-sdr, then something else must be modifying your pressure (is the pressure outside of the calibration limits? check the log)

weewx-sdr v0.16 should help with identifiers (commit 7907dd0): it will try to make every acurite identifier uppercase hex (instead of decimal).  it also deals with some random sensor output such as 'DSC Contact ESN: FFFFFF' that recently popped up in my neighborhood (the formatting is different from other sensors).

unfortunately i cannot guarantee everything works for every type of sensor until we get actual json output from rtl_433 - and apparently my neighbors don't have that many different kinds of sensors :)

its kind of funny to see the output from tire pressure gauges when a truck drives by - it should be easy to use the identifiers to see which trucks pass regularly.  or the door/window open-and-close sensors for the neighbor's security system.

m

Offline vreihen

  • El Niņo chaser
  • Forecaster
  • *****
  • Posts: 1216
  • K2BIG
Re: Wunderground Rapid Fire
« Reply #26 on: January 16, 2017, 08:23:34 PM »
how are you injecting pressure into loop packets?

Through a custom service that I hacked together, based on the example pond.py:

Code: [Select]
        data_services = user.i2c.i2cService
Quote
if you add a pressure to a loop packet emitted by weewx-sdr, then something else must be modifying your pressure (is the pressure outside of the calibration limits? check the log)

Yup, that's the problem!  My custom code was sending mbar and degrees C numbers, and something was converting them to inHg and degrees F.  For some reason, this conversion stopped with the new rtl_433/sdr.py combo, triggering the range error.  It only seems to happen with JSON mode on the newer rtl_433 binary, and feeding sdr.py from the December rtl_433 binary in non-JSON apparently did the conversions *unsolicited* to fix the wrong units.

Anyway, the behavior of today's sdr.py is correct in not trying to fix my bad data.  I'll do the conversions to imperial units in my custom service code, so that it is outputting data in weewx's default units.....

Signed,
Captain Coredump  :-)
WU Gold Stars for everyone! :lol:

Offline mwall

  • Contributor
  • ***
  • Posts: 135
Re: Wunderground Rapid Fire
« Reply #27 on: January 16, 2017, 08:29:14 PM »
Anyway, the behavior of today's sdr.py is correct in not trying to fix my bad data.  I'll do the conversions to imperial units in my custom service code, so that it is outputting data in weewx's default units.....

your service should check the unit system of the packet/record to which it is adding data (the 'usUnits' field), and use units in that unit system.  usUnits will be either weewx.METRICWX, weewx.METRIC, or weewx.US.

weewx-sdr might emit packets in METRICWX, METRIC, or US - it depends on what it gets from the sensors.

this is another inconsistency in rtl_433 that is slowly getting cleaned up.  some decoders were emitting metric units, others both metric and us.  rtl_433 has a flag now to indicate which units you want.  i'm not sure if it works yet across all decoders.

m

Offline vreihen

  • El Niņo chaser
  • Forecaster
  • *****
  • Posts: 1216
  • K2BIG
Re: Wunderground Rapid Fire
« Reply #28 on: January 17, 2017, 07:10:11 AM »
I now obviously need to clean up my own service code to account for units.

Weewx stopped uploading to WU again overnight.  Both rtl_433 and weewx were still running, and there were no errors logged in either syslog or on the console.  When I went to fall back to MeteoBridge/USB again, MB had a red text warning that it had not seen a rain record in over an hour.  I started up rtl_433 to check the OTA data, and sure enough my 5-in-1 wasn't sending anything but type 38 packets for the 5+ minutes that I let it run.  After power-cycling the 5-in-1, both MB and rtl_433 started receiving type 31 packets again.  Weewx was also happy when I re-started it after the 5-in-1 power cycle.

I am at wit's end with my Acu-Rite hardware reliability at this point, and this failure may be the last straw that forces me to ditch it all for another solution.....
WU Gold Stars for everyone! :lol:

Offline vreihen

  • El Niņo chaser
  • Forecaster
  • *****
  • Posts: 1216
  • K2BIG
Re: Wunderground Rapid Fire
« Reply #29 on: January 17, 2017, 07:39:42 PM »
I just made the tweak to my service code so that it is sending the expected imperial units, downloaded/installed sdr.py v0.17, and changed back to -F json.  The sensor iD's are back to hex, and the pressure/inTemp from my custom service is importing properly.  Keeping my fingers crossed that everything keeps running now.

Regarding the rain_total, I was running the December rtl_433 against sdr.py 0.15 all day.  MeteoBridge, two Acu-Rite consoles, and even the newer rtl_433 I'm running measured 0.36 inches of rain.  When I stopped weewx to do the above updates, it had only measured 0.11 inches (when the others were reading 0.34 inches).  Don't know if this is another units problem or something that was already fixed in one of the supporting packages, but rain_total was under-reported by over 50% yet again.  Of course it just stopped raining, so I can't test it again until mother nature cooperates.....  #-o
WU Gold Stars for everyone! :lol:

Offline vreihen

  • El Niņo chaser
  • Forecaster
  • *****
  • Posts: 1216
  • K2BIG
Re: Wunderground Rapid Fire
« Reply #30 on: January 18, 2017, 06:27:20 AM »
We had another 0.08 inches of rain here after midnight.  Both weewx and MeteoBridge finally agree with that number!  Whatever was wrong with the rain_total was fixed by going JSON with the absolute latest rtl_433 (downloaded/built last night) and sdr.py 0.17.

Wish that I could say there was great joy in Whoville, but the USB link to the SDR took a dump a few hours ago:

Code: [Select]
Jan 18 04:18:07 WXpi3 kernel: [33389.799736] usb 1-1.4: usbfs: usb_submit_urb returned -121
Jan 18 04:18:07 WXpi3 kernel: [33389.799828] usb 1-1.4: usbfs: usb_submit_urb returned -121
Jan 18 04:18:07 WXpi3 kernel: [33389.799922] usb 1-1.4: usbfs: usb_submit_urb returned -121
Jan 18 04:18:07 WXpi3 kernel: [33389.800011] usb 1-1.4: usbfs: usb_submit_urb returned -121
Jan 18 04:18:07 WXpi3 kernel: [33389.800110] usb 1-1.4: usbfs: usb_submit_urb returned -121
Jan 18 04:18:07 WXpi3 kernel: [33389.800210] usb 1-1.4: usbfs: usb_submit_urb returned -121
Jan 18 04:18:07 WXpi3 kernel: [33389.800337] usb 1-1.4: usbfs: usb_submit_urb returned -121
Jan 18 04:18:07 WXpi3 kernel: [33389.800453] usb 1-1.4: usbfs: usb_submit_urb returned -121
Jan 18 04:18:07 WXpi3 kernel: [33389.800569] usb 1-1.4: usbfs: usb_submit_urb returned -121
Jan 18 04:18:07 WXpi3 kernel: [33389.800602] usb 1-1.4: USB disconnect, device number 4
Jan 18 04:18:07 WXpi3 kernel: [33390.036685] usb 1-1.4: new high-speed USB device number 5 using dwc_otg
Jan 18 04:18:08 WXpi3 kernel: [33390.546729] usb 1-1.4: new high-speed USB device number 7 using dwc_otg
Jan 18 04:18:08 WXpi3 kernel: [33390.658119] usb 1-1.4: New USB device found, idVendor=0bda, idProduct=2838
Jan 18 04:18:08 WXpi3 kernel: [33390.658134] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jan 18 04:18:08 WXpi3 kernel: [33390.658141] usb 1-1.4: Product: RTL2838UHIDIR
Jan 18 04:18:08 WXpi3 kernel: [33390.658148] usb 1-1.4: Manufacturer: Realtek
Jan 18 04:18:08 WXpi3 kernel: [33390.658154] usb 1-1.4: SerialNumber: 00000001
Jan 18 04:18:08 WXpi3 systemd-udevd[3203]: failed to execute '/lib/udev/mtp-probe' 'mtp-probe /sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.4 1 7': No such file or directory

I've got a new Pi and SDR arriving tomorrow to rule out the hardware, since this does not appear to be the same issue as mentioned with earlier USB code in the sdr.py readme.....
WU Gold Stars for everyone! :lol:

Offline mwall

  • Contributor
  • ***
  • Posts: 135
Re: Wunderground Rapid Fire
« Reply #31 on: January 18, 2017, 07:47:05 AM »
We had another 0.08 inches of rain here after midnight.  Both weewx and MeteoBridge finally agree with that number!  Whatever was wrong with the rain_total was fixed by going JSON with the absolute latest rtl_433 (downloaded/built last night) and sdr.py 0.17.

excellent news!

Wish that I could say there was great joy in Whoville, but the USB link to the SDR took a dump a few hours ago:

Code: [Select]
Jan 18 04:18:07 WXpi3 kernel: [33389.799736] usb 1-1.4: usbfs: usb_submit_urb returned -121
Jan 18 04:18:07 WXpi3 kernel: [33389.799828] usb 1-1.4: usbfs: usb_submit_urb returned -121
Jan 18 04:18:07 WXpi3 kernel: [33389.799922] usb 1-1.4: usbfs: usb_submit_urb returned -121
Jan 18 04:18:07 WXpi3 kernel: [33389.800011] usb 1-1.4: usbfs: usb_submit_urb returned -121
Jan 18 04:18:07 WXpi3 kernel: [33389.800110] usb 1-1.4: usbfs: usb_submit_urb returned -121
Jan 18 04:18:07 WXpi3 kernel: [33389.800210] usb 1-1.4: usbfs: usb_submit_urb returned -121
Jan 18 04:18:07 WXpi3 kernel: [33389.800337] usb 1-1.4: usbfs: usb_submit_urb returned -121
Jan 18 04:18:07 WXpi3 kernel: [33389.800453] usb 1-1.4: usbfs: usb_submit_urb returned -121
Jan 18 04:18:07 WXpi3 kernel: [33389.800569] usb 1-1.4: usbfs: usb_submit_urb returned -121
Jan 18 04:18:07 WXpi3 kernel: [33389.800602] usb 1-1.4: USB disconnect, device number 4
Jan 18 04:18:07 WXpi3 kernel: [33390.036685] usb 1-1.4: new high-speed USB device number 5 using dwc_otg
Jan 18 04:18:08 WXpi3 kernel: [33390.546729] usb 1-1.4: new high-speed USB device number 7 using dwc_otg
Jan 18 04:18:08 WXpi3 kernel: [33390.658119] usb 1-1.4: New USB device found, idVendor=0bda, idProduct=2838
Jan 18 04:18:08 WXpi3 kernel: [33390.658134] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jan 18 04:18:08 WXpi3 kernel: [33390.658141] usb 1-1.4: Product: RTL2838UHIDIR
Jan 18 04:18:08 WXpi3 kernel: [33390.658148] usb 1-1.4: Manufacturer: Realtek
Jan 18 04:18:08 WXpi3 kernel: [33390.658154] usb 1-1.4: SerialNumber: 00000001
Jan 18 04:18:08 WXpi3 systemd-udevd[3203]: failed to execute '/lib/udev/mtp-probe' 'mtp-probe /sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.4 1 7': No such file or directory

I've got a new Pi and SDR arriving tomorrow to rule out the hardware, since this does not appear to be the same issue as mentioned with earlier USB code in the sdr.py readme.....

that looks like a usb reset, but without a nice recovery.

thanks for the feedback!

m

Offline vreihen

  • El Niņo chaser
  • Forecaster
  • *****
  • Posts: 1216
  • K2BIG
Re: Wunderground Rapid Fire
« Reply #32 on: January 25, 2017, 06:30:21 AM »
For archival purposes, I changed the SDR hardware and weewx has run for 3 days straight (including a rain/sleet Nor'easter) with no issues.  The SDR that I was originally using was online for three years straight as my Dump_1090 ADS-B decoder before that, so it was probably time to toss it anyway given how hot they run at times.

I'm confident enough in weewx's stability at this point to enable it for WU posts again in place of MeteoBridge, and hope that having the barometer back online will get my gold star back.....
WU Gold Stars for everyone! :lol:

Offline tim273

  • Contributor
  • ***
  • Posts: 106
Re: Wunderground Rapid Fire
« Reply #33 on: July 16, 2018, 11:51:56 AM »
Just checking for an update since it's been a while since this post was active.  I too have an Acurite 5-in-1 sensor and am using an SDR with a NooElec RTL_SDR stick.  Everything works great, but was wondering about the Rapid Fire issue, if that has been fixed.  I'm using WeeWx v3.8.