This is certainly not what you are looking for, but it is what I use to get
NWS forecasts.
Here is a url for a forecast for a randomly selected location:
https://forecast.weather.gov/MapClick.php?lat=41.177010&lon=-73.141963&unit=0&lg=english&FcstType=text&TextType=2
Note where latitude and lon
It appears that you are using an editor called Nano. The two lines of help
at the bottom of the screen use the caret symbol to represent the CTRL key,
so pressing CTL and O at the same time will "write out" (save) the file,
and CTRL-X will exit the editor.
On Wednesday, February 2, 2022 at 9:4
My suspicion is that this happens because of unusual propagation conditions
such as "tropospheric ducting," which may be associated with unusual
weather or sunspot activity, among other factors. There are occasions when
distant radio or TV signals can be received briefly, sometimes stronger
tha
Tom, you might find it helpful to look at the Hardware Guide at
http://www.weewx.com/docs/hardware.htm
It will tell you the reporting interval for some families of weather
stations.
On Wednesday, June 3, 2020 at 4:16:32 PM UTC-4, Tom K wrote:
>
> Hello all - looking for some specific hardwar
On Wednesday, June 3, 2020 at 11:32:46 PM UTC-4, Xant wrote:
>
>
> Welcome to WeeWX, but also to note, that there are many previous posting
> regarding this issue (which should check prior to new post).
>
>
It is certainly true that there are many previous posts asking questions
about hardware,
https://groups.google.com/d/msg/weewx-user/cDFAN1GBCfA/39399_wjAAAJ
On Friday, January 31, 2020 at 2:53:47 AM UTC-5, Kevin Key wrote:
>
> Is there an option to disable use of SSL for pushing data to Weather
> Underground? I am getting nothing but errors and can no longer push to WU.
>
>
--
You
That seems to have worked for me, too.
On Thursday, January 30, 2020 at 5:36:53 PM UTC-5, Jarom Hatch wrote:
>
> Quick fix for me was to change the URLs in restx.py to http instead of
> https. That got it back updating.
>
> On Thursday, January 30, 2020 at 3:30:32 PM UTC-7, Jarom Hatch wrote:
>
As the one who started and finished that thread, I have to say that the
solution described there is still working very well for me.
On Sunday, January 19, 2020 at 3:10:17 PM UTC-5, SingleSpeed wrote:
>
> Thx for the info - not sure why I didn't find that one. Anyway, this
> should be very helpf
Is archive data adequate for your needs? (Typically updates every five
minutes, although you can set the archive period to something else.) Or do
you need to use loop data, which is nearly real-time?
If archive data will work, the simplest (not necessarily best) way to do
what you ask is to add
nough to
> survive' (most of the time) level.
>
> I have had a look at the wiki and now realise that this is way beyond my
> current skill level.
>
> Thank you, Gary and RobbH for your tips. I have a lot of learning to do
> before I can take this on.
>
>
>
--
You might take a look at the crt service:
https://github.com/weewx/weewx/wiki/crt
This writes a text file, realtime.txt every time new loop data is received.
The current outside temperature is always the third field in the file.
However, many loop packets may not include temperature data, in wh
My apologies. I misread the reference to "Acurite access" as meaning
"access to Acurite" rather than the Access device.
On Sunday, May 19, 2019 at 6:09:19 PM UTC-4, mwall wrote:
>
> On Sunday, May 19, 2019 at 5:44:55 PM UTC-4, Ray Pfaff wrote:
>>
>> Am I missing something? Both of those apply t
See this message and the rest of the thread:
https://groups.google.com/d/msg/weewx-user/0e2E3F7EG7Y/mVv7oUZ1BgAJ
On Sunday, May 19, 2019 at 8:52:51 AM UTC-4, Ray Pfaff wrote:
>
> I've been trying to get the 0.41 version of weewx interceptor working with
> my Acurite access and haven't had any
That shouldn't have any impact if the SmartHub data is being redirected to
a local ip and received by the Interceptor in listen mode, should it?
On Tuesday, February 19, 2019 at 12:40:47 PM UTC-5, Arthur Emerson wrote:
>
> FYI, AcuRite is going to be shutting down the Lake Geneva Mothership
> (
rnoon.
On Monday, February 18, 2019 at 4:55:39 PM UTC-5, RobbH wrote:
>
> Thanks!
>
>
> On Monday, February 18, 2019 at 4:42:10 PM UTC-5, Scott Grayban wrote:
>>
>> You can update over the old one. No need to remove the old one.
>>
>> On Monday, Februa
Thanks!
On Monday, February 18, 2019 at 4:42:10 PM UTC-5, Scott Grayban wrote:
>
> You can update over the old one. No need to remove the old one.
>
> On Monday, February 18, 2019 at 1:16:25 PM UTC-8, RobbH wrote:
>>
>> I am having some problems with the Acurite bridge
I am having some problems with the Acurite bridge, and I suspect hardware
failure. (Syslog shows that the interceptor occasionally receives full
data, but for the past several hours it mostly just reports "weewx[916]:
interceptor: MainThread: empty queue".)
I assume it makes sense to try updati
urite has calculated for me? Sounds like it doesn't need to be
> used/mapped.
>
> On Sat, May 26, 2018 at 10:42 AM RobbH >
> wrote:
>
>> With a very similar setup, here's what's in the sensor map section of my
>> weewx.conf (changing my sensor ID number to
With a very similar setup, here's what's in the sensor map section of my
weewx.conf (changing my sensor ID number to yours):
rain = rainfall.3420.*
weeWX calculates the daily rain total.
On Friday, May 25, 2018 at 11:51:43 AM UTC-4, bdf0506 wrote:
>
> I'm trying to properly map an Acurite
Max, I am no expert, but I do currently have an Acurite 5-in-1 sensor,
along with two additional temperature/humidity sensors, using an Acurite
"smart hub" to receive the signals and the Interceptor driver to import the
data into weeWX. It works well, but there are a few catches.
First of all,
Bruce, unlike others who have responded to your question, I am definitely
not an expert. However, I have recently developed my own real-time display
using the crt service, and it works very well for my purposes. The only
catch is that some of the fields in the realtime.txt file do not contain
r
al already.
>
> On Sat, Apr 14, 2018 at 8:40 PM, RobbH >
> wrote:
>
>> Following up, there are directions for compiling rtl_433 and rtl-sdr,
>> which you will also need. Both are linked from the sdr driver page in the
>> wiki.
>>
>>
>>
>>
Following up, there are directions for compiling rtl_433 and rtl-sdr,
which you will also need. Both are linked from the sdr driver page in the
wiki.
On Saturday, April 14, 2018 at 8:31:08 PM UTC-4, RobbH wrote:
>
> Have you looked into the sdr driver for weewx? It's in the wiki
Have you looked into the sdr driver for weewx? It's in the wiki, which can
be accessed from the weewx Support page.
On Monday, April 9, 2018 at 1:07:14 AM UTC-4, doug1...@gmail.com wrote:
>
>
> Hi,
>
> I have a 5 n 1 and would like to access it by internet. I have an sdr
> receiver and raspberr
ntext, or if the line containing
dailyrainin is ever formatted differently, my script will fail miserably.
On Sunday, April 1, 2018 at 1:42:16 PM UTC-4, RobbH wrote:
>
> Never mind! I've discovered the tcpflow command. tcpflow -i any -C -J port
> 80 | grep "dailyrainin"
to be surprised by
> the weird results ;-)
>
>
>
> Cheers
> Glenn
>
> rorpi - read only raspberry pi & various weewx addons
> https://github.com/glennmckechnie
>
> On 6 April 2018 at 05:36, RobbH > wrote:
>
>> I finally came to the realization that
:13 PM UTC-4, Tom Keffer wrote:
>
> Very clever!
>
> -tk
>
> On Thu, Apr 5, 2018 at 12:36 PM, RobbH >
> wrote:
>
>> I finally came to the realization that everything I wanted to do could be
>> done with the Cheetah engine, and even learned a tiny bit of Python
following the final
comment, with this code:
10
5
On Thursday, April 5, 2018 at 5:25:01 PM UTC-4, RobbH wrote:
>
> It's available (temporarily) here:
>
> http://rh3.operamail.com/windrose_testing.svg
>
> On Thursday, April 5, 2018 at 3:45:58 PM UTC-4, Al
It's available (temporarily) here:
http://rh3.operamail.com/windrose_testing.svg
On Thursday, April 5, 2018 at 3:45:58 PM UTC-4, Alec Bennett wrote:
>
> Possible to see the generated output of that somewhere?
>
> On Thu, Apr 5, 2018 at 12:36 PM, RobbH >
> wrote:
>
f
This is set up to work with speeds measured in miles per hour. Some
modification would be needed to make it work with other units. I hope
someone will find it useful. Improvements welcome.
On Monday, April 2, 2018 at 8:21:51 PM UTC-4, RobbH wrote:
>
> Very nice! That's not ex
de version, without making the wind directional pointer proportional
>> to wind speed, can be done with svg graphics and no outside help. I've
>> posted that to the old thread that I linked in the first post.
>>
>>
>> On Friday, March 30, 2018 at 8:27:41 PM UTC-4
Never mind! I've discovered the tcpflow command. tcpflow -i any -C -J port
80 | grep "dailyrainin" should provide what I need.
On Saturday, March 31, 2018 at 5:07:46 PM UTC-4, RobbH wrote:
>
> Thanks. I understand that, for a change.
>
> So there's no way to wo
t I linked in the first post.
On Friday, March 30, 2018 at 8:27:41 PM UTC-4, RobbH wrote:
>
> Maybe, at long last, I'm going to have to buckle down and learn enough of
> Python to do this!
>
>
> On Friday, March 30, 2018 at 6:51:49 PM UTC-4, vince wrote:
>>
>>
This a very old thread, but it still turns up in searches. Here's a simple
way to do a crude version of what the original poster was doing. That is, a
display of the most recent wind direction on the background of a compass
rose, not a wind rose, showing history. May not work in all browsers, bu
o the crt service, without waiting for weewx to do
its calculations?
On Friday, March 30, 2018 at 9:54:25 PM UTC-4, mwall wrote:
>
> On Friday, March 30, 2018 at 6:00:14 PM UTC-4, RobbH wrote:
>>
>>
>> We can see that field 10 (rain today) and 48 (rainfall last hour) stil
Maybe, at long last, I'm going to have to buckle down and learn enough of
Python to do this!
On Friday, March 30, 2018 at 6:51:49 PM UTC-4, vince wrote:
>
> On Friday, March 30, 2018 at 1:54:30 PM UTC-7, RobbH wrote:
>>
>> Still pursuing this, and I have learned how
I have been playing with displaying realtime data, using the hardware
mentioned in the subject line. That's the CRT service, Interceptor driver,
and an AcuRite multisensor and bridge. Running weewx 3.8.0 on Debian Jessie
32-bit on a netbook.
Everything works, except rain. Other data displays in
Still pursuing this, and I have learned how to generate the sort of image I
want, but not within Weewx. Is it possible call an external program (shell
script) during each report cycle?
On Friday, March 23, 2018 at 2:44:49 PM UTC-4, RobbH wrote:
>
> Is it possible, using the standard
Good luck to you! I hope somebody who actually knows something about this
will join in and help you with issues you encounter.
On Saturday, March 24, 2018 at 11:50:39 AM UTC-4, Joush wrote:
>
>
> Thank for your help, RobbH.
> I will take a look at the link and give a try.
> Will
TC-4, Joush wrote:
>
> Hi RobbH,
>
> Thank you for your help. Your idea is very good.
> But, due to my bad English, there is a little not exactly what I want to
> do.
> I try to explain one more time.
> So, I have a 7-inch monitor (like this one:
> https://www.waveshare
Joush, I am not certain I understand what you want to do, but I think you
want to display current weather data in a simple way that's readable in a
command line environment. Is that right?
If so, the simplest way is to install a command line web browser on the Pi.
I like lynx, but several other
Is it possible, using the standard image generator, to create an image of
the maximum and average wind vector, only for the most recent archive
period?
I assume not, as the docs are very clear that there is no current.windvec
tag. Still, I have some hope that Those Who Know A Lot More Than I Do
x27;t feel you had I
had wasted too much of your time. I'll consult this thread in the future,
when I hope to be better prepared to understand it.
On Saturday, March 10, 2018 at 3:27:41 PM UTC-5, RobbH wrote:
>
> Thanks for all the help and patience with my bumbling. I can now repor
;http://y.y.y.y/weatherstation$1>
I've tried that, but it doesn't seem to do what I need. The driver still
reads data as long as it's listening to port 80, but finds nothing when
listening on .
Any advice will be appreciated!
On Thursday, March 8, 2018 at 11:16:14 AM UT
"Supported" makes sense. Thanks for making that distinction, as well as
explaining the change.
On Thursday, March 8, 2018 at 11:04:32 AM UTC-5, vince wrote:
>
> On Thursday, March 8, 2018 at 6:39:27 AM UTC-8, RobbH wrote:
>>
>> Is dpkg still recommended? I came to my
ation, though.
On Thursday, March 8, 2018 at 4:00:13 AM UTC-5, Liz wrote:
>
> On Wed, 7 Mar 2018 19:58:44 -0800 (PST)
> RobbH > wrote:
>
> > This is on Debian, with Weewx installed using dpkg. (I see now that
> > that's no longer a recommended way to install.)
&g
wall wrote:
>
>
>
> On Wednesday, March 7, 2018 at 9:20:31 PM UTC-5, RobbH wrote:
>>
>>
>> Meanwhile, I've encountered another issue, that I think is independent of
>> the hardware issues. Installation of the Interceptor appeared to be
>> successful,
ide!
On Wednesday, February 28, 2018 at 12:06:42 PM UTC-5, RobbH wrote:
>
> This is more a Linux question than a Weewx question, but it is necessary
> to get Weewx working the way I want it to. This is a networking issue
> unlike any I've dealt with, so I hope someone with greater
1:45:16 AM UTC-8, RobbH wrote:
>>
>> That would work, but I'm trying to avoid sending all DNS requests (not
>> DHCP) from the entire LAN through a separate server
>>
>
> Then send just the bridge box to the pihole for DHCP, if you can
> statically set its DNS sett
Thank you. Not the "lightweight" solution I was hoping for, using just the
hosts file and maybe dnsmasq. But this is certainly do-able, especially
with the helpful examples you've provided. If bind and dhcpd are what's
called for, that's what I'll do.
...after I spend a bit more time studying y
hosts file of the machine it's hosted on?
It still seems to me that it should work, but I've probably got something
configured that prevents it from working.
On Wednesday, February 28, 2018 at 12:18:16 PM UTC-5, vince wrote:
>
> On Wednesday, February 28, 2018 at 9:06:42 AM UT
This is more a Linux question than a Weewx question, but it is necessary to
get Weewx working the way I want it to. This is a networking issue unlike
any I've dealt with, so I hope someone with greater knowledge will be
willing to share it.
My main router, a Netgear R7000, does not provide the
Davis VP2
> off Craigslist for =< $ 300, and using the belfryboy cables.
>
> On Wednesday, February 21, 2018 at 7:55:53 PM UTC-5, RobbH wrote:
>>
>> I probably sound like a noob, but I've been using Weewx nearly four years
>> with various Oregon Scientific equipme
t bit of info!
On Thursday, February 22, 2018 at 2:54:58 PM UTC-5, vince wrote:
>
> On Thursday, February 22, 2018 at 11:10:51 AM UTC-8, RobbH wrote:
>>
>> That clears up most of my confusion. (Whatever remains is inherent and no
>> concern here.) Thanks!
>>
>>
d twice my budget on Davis gear, and even
though Weather Flow is very tempting, it feels a little too much like
vaporware.
On Thursday, February 22, 2018 at 1:17:26 PM UTC-5, mwall wrote:
>
> On Thursday, February 22, 2018 at 1:07:25 PM UTC-5, RobbH wrote:
>>
>> Many thanks f
in
> the same league in terms of durability and accuracy.
>
> -tk
>
> On Wed, Feb 21, 2018 at 6:00 PM, RobbH >
> wrote:
>
>> Thanks, Vince. Weather Flow looks very promising, but I'm not sure I have
>> confidence in their ability to deliver all of the
e. The API makes it
especially intriguing.
On Wednesday, February 21, 2018 at 8:10:26 PM UTC-5, vince wrote:
>
> On Wednesday, February 21, 2018 at 4:55:53 PM UTC-8, RobbH wrote:
>>
>> I need separate sensors, not an all in one, since the rain gauge and
>> thermometer/
I probably sound like a noob, but I've been using Weewx nearly four years
with various Oregon Scientific equipment, currently a WMR200 console and
sensors that were bundled with the WMR100. I'm weary of the flaky sensors
and ready to move to something more reliable. I've read enough to
understa
58 matches
Mail list logo