It MUST be caching - since the WMR200 does not emit all the data every 10 seconds, so in order to upload to WU every 10 seconds via rapidfire some/all of the data must have been old/stale - it certainly cannot ALL be the latest/current, although it may well be the last received.
On Wednesday, 12 October 2016 12:41:26 UTC+3, shriramvenu wrote: > Would love to hear from a WMR200 user, because Weather Display was > updating WU every 10s with rapidfire, so I guess it wasn't caching anything. > > On Wednesday, 12 October 2016 17:35:34 UTC+8, Andrew Milner wrote: >> >> From reading the user guide and hardware guide it would seem to me (NOT a >> WMR200 user) that since the WMR200 emits partial packets it may well take >> more than 60 seconds to obtain current values for all fields - this means >> that the archive period should be 300 seconds, and you would also be >> correct in thinking that weewx does not handle rapid fire for the wmr200 - >> because the hardware does not emit all data within a loop packet. >> >> Weather display may well handle rapid fire better if it buffers the data >> somehow or retransmits old data as part of rapid fire. >> >> I would personally argue that weather display is 'fooling' WU by doing >> such buffering. >> >> Probably the best bet for you is to stop using rapid fire, upload archive >> records at 300 second intervals instead. >> >> Just my thoughts - am sure a wmr200 user (or matthew or Tom) will give a >> more authorative statement. >> >> >> >> On Wednesday, 12 October 2016 12:05:03 UTC+3, shriramvenu wrote: >> >>> Thanks for this. I saw the first bug but was'nt quite sure what to do. I >>> guess i just replace wmr200.py in /bin/weewx/drivers? (where /bin is from >>> the root directory of my R-pi?) >>> >>> Yes I have RapidFire enabled. Before this I was uploading to Weather >>> Underground using rapidfire via WeatherDisplay for months using my windows >>> PC so I dont think the problem is the WMR200 hardware. Are you saying that >>> weewx doesnt properly handle rapidfire for the WMR200? >>> >>> Also should I keep the archive interval at the default 60s or change to >>> 300s like advised here? >>> https://groups.google.com/forum/#!topic/weewx-user/nUWo2znTP5I >>> >>> Id prefer to have more frequent updates (hopefully that doesnt kill my >>> sd card haha) >>> >>> Thanks again >>> >>> On Wednesday, 12 October 2016 03:40:10 UTC+8, mwall wrote: >>>> >>>> On Tuesday, October 11, 2016 at 3:20:51 PM UTC-4, shriramvenu wrote: >>>>> >>>>> 1) I keep my outdoor Thermo-Hygro sensor on Channel 2 because I get >>>>> interference on channel 1. I've searched through the documentation and >>>>> cant >>>>> find any info on how to set weewx to receive data for channel 2. >>>>> >>>> >>>> this bug was recently reported: >>>> >>>> https://github.com/weewx/weewx/issues/164 >>>> >>>> with a short-term fix applied here: >>>> >>>> >>>> https://github.com/weewx/weewx/commit/fc97406fad0dc0d2fd8ff1110bd1430643f8f3b7 >>>> >>>> please try the fixed driver: >>>> >>>> >>>> https://raw.githubusercontent.com/weewx/weewx/master/bin/weewx/drivers/wmr200.py >>>> >>>> replacing your existing weewx/drivers/wmr200.py file with the new one. >>>> >>>> 2) My localhost site shows N/A for all current conditions, and the info >>>>> going up to weather underground is basically nonexsistent most of the >>>>> time. >>>>> Usually the wind is visible, sometimes the barometer. Never the >>>>> temperature, but that could be due to being on channel 2. >>>>> >>>> >>>> are you using rapidfire? the wmr hardware emit partial packets, and wu >>>> rapidfire does not know how to deal with that. >>>> >>>> see this for details: >>>> >>>> https://github.com/weewx/weewx/issues/31 >>>> >>>> m >>>> >>> -- You received this message because you are subscribed to the Google Groups "weewx-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
