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 weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to