Gary, thanks for your reply,i will add it right now.
Op maandag 27 mei 2019 04:41:44 UTC+2 schreef gjr80:
>
> Hi,
>
> Your 'fix' has merely forced the csv service to always generate data.csv
> based on archive records rather than the default loop packets. Using
> archive records rather than loop
The number one rule when augmenting archive records or loop packets with
data is that you must check the unit system used in the record or packet
(ie check the usUnits field) you are adding data to and make sure that any
data you do add is in the same units as used by that unit system. If you
Gary,
It's late, so I'll respond to the rest later, but...
The problem here is that if we compare our local every 1-minute records to WU's
query that only shows every 5-minute records, then we'll keep re-uploading the
the "missing" 1-minute records every time wunderfixer is called. This amount
Hi Ian,
Also notice some left-over debug code in shared.php that prevents
Fahrenheit temps from displaying correctly.
*$weather["temp_units"]='C'; *
if ($weather["temp_units"] == 'C'){
$heatIndex = fToCDirect($heatIndex);
Thanks Jerry
On Sunday, May 26, 2019 at 7:28:06 PM UTC-7, Jd D wrote:
>
On Monday, 27 May 2019 13:16:53 UTC+10, Leon Shaner wrote:
>
> Gary,
>
> In practice, WU seems to discard data that is not close to their
> APPARENTly preferred 5-minute "normalization buckets."
>
> I upload via rapidfire *and* regular loop on 1-minute intervals, and
> irregardless of same, the q
Gary,
In practice, WU seems to discard data that is not close to their APPARENTly
preferred 5-minute "normalization buckets."
I upload via rapidfire *and* regular loop on 1-minute intervals, and
irregardless of same, the queries only ever show the records most closely
aligned to their "preferr
On Saturday, 25 May 2019 22:54:25 UTC+10, Leon Shaner wrote:
>
>
> There is no point re-uploading 00:00:00, then 00:01:00, then 00:02:00,
> because WU is only going to keep 00:00:00, and then later it will keep
> whatever is closest to 00:05:00. That's been the behavior of wunderfixer
> vs. WU
Hi,
Your 'fix' has merely forced the csv service to always generate data.csv
based on archive records rather than the default loop packets. Using
archive records rather than loop packets would make sense for a station
that emits partial loop packets (ie a station that does not include
radiatio
Hi Ian,
Noticed this in weewxcron.php
if ($position6=="forecast3ds.php" || $position6=='forecast3wu.php' ||
$position6=='forecast3wularge.php' || *$position4 = "advisory.php")*{
I think you want ==
Also I cleaned up most of my apache errors by making small changes to
livedata.php
Thanks Je
Hello Andrew,
indeed it actually is only augmenting.
But in case the archive data is gained from a DMPAFT packet it seems to be
converted complete after augmenting. If the archive data is gained from a
LOOP packet it converted before.
So the following things would probably solve the issue:
- On
Tested on 4.x (python 2 and 3) and 3.9.x. (python 2).
Ultimately went with apikey instead of apiKey in weewx.conf, which was to be
more consistent with other parameter names.
If you are willing to pass "--apikey=0123456789012345678901" on wunderfixer
command-line, then you only need wunderfixer
Hi Ian,
Right now just using the template for my local weather station and my
nearby metar.
Here is my settings1.php.
I XXed out personal stuff.
Also I tried to use the least number of sections so to reduce the number of
apache errors I am logging.
Since I cut and pasted the file into the repl
Can you expand on that please. Do you mean that you are deliberately not using
WU or DS for forecasting, just your local metar?
Sent from my iPhone
> On 26 May 2019, at 18:25, Jd D wrote:
>
> Hi,
> No WU
> No DS
> Just local metar.
>
> Thanks Jerry
>
>> On Sunday, May 26, 2019 at 9:35:48 AM
Also, are there any other USB devices connected?
No
How long is your USB cable that connects to the WMR300?
Is a standard cable. 1m or so. It worked before with a weather
display setup.
Are you using an official Raspberry Pi power supply or another brand?
Im using a Samsun
That's an interesting idea. You might be able to use the console connector
present on every SIM board to capture the same packets that are sent out on
radio - *if* it's only the original radio that's dead. The only issue is
the power consumption of the ESP32. Whatever ULP mode it has, WiFi will
Hi,
No WU
No DS
Just local metar.
Thanks Jerry
On Sunday, May 26, 2019 at 9:35:48 AM UTC-7, steeple ian wrote:
>
> Hi Jerry,
>
> Are you using the Weather Underground forecasts? If so have you got one of
> the new API keys? If so have you entered correctly in the settings?
>
> Ian
>
> On Sun, Ma
>
> Thanks for the pointer to the RFM69 discussions.
>>
>
Now I am thinking of a change in strategy and just putting one of the
ESP32+RFM95W dev boards into the ISS and send the data out directly,
alternating between moderate range LoRa <-> LoRa peers and occasionally to
a distant LoRaWAN gatew
Hi Jerry,
Are you using the Weather Underground forecasts? If so have you got one of
the new API keys? If so have you entered correctly in the settings?
Ian
On Sun, May 26, 2019 at 6:09 AM Jd D wrote:
> Hi Ian,
>
> So I decided to do a new install of both weewx and the very latest
> Weather34
The radio should be capable on paper, but the RFM9x series is only used for
LoRa in the wild. The main problem is that there's no suitable driver for
these modules for FSK mode. The RFM69 is cheaper for FSK and there are
several FSK/OOK libs to choose from, plus it already has several working
i
I spent a fair bit of time on what I believe is the same issue. I even
installed an Adafruit RTC and that didn't seem to solve the issue. At the
moment, I have the system on a UPS (which is huge and probably uses more
power than my Console, Adapter/Logger module and the RPi Zero W). My UPS
batt
The script you posted SHOULD only be augmenting REC packets, and not be
affected by any LOOP packets.
Maybe you should set record generation to either use hardware or use
software and not prefer hardware or prefer software. Your augmented data
should be use software I would have thought
Hallo,
think I tracked the issue down.
First it starts with record generation software.
So each time a archive dataset is retreivedn form the hardware logger my
data is augmented and then it runs apparently through the unit converter,
converting it to metric units (in case of my augmented data c
Just chiming in because I am stuck with the same result running the interceptor
driver directly: identifiers {}. My question is here:
https://groups.google.com/forum/m/#!topic/weewx-user/DHDNdfX6ZVw
If you learn anything I'd love to hear about it :)
--
You received this message because you are
23 matches
Mail list logo
