Re: [weewx-user] Re: Pyehpem and International Space Station

[Kevin Davis]

I would love to do some moon-bounce!  Looks like so much fun and lots to
learn.  I have a pi-star here on the bench to build but haven't gotten
around to it yet, but I do stay pretty active on All-Star.  Usually
connected to the East Coast Reflector.

 While I've been a programmer for 25+ years(IBM mainframes), this project
is actually my first Python attempt and basically my first experience with
object oriented taboot.   Below is what I've got so far for building the
next few passes of the ISS.

Perhaps you could explain to me the difference in "passes through the
minimum elevation" vs. at the horizon?

I'm trying to get any pass that goes over 10deg.  The only issue I'm having
is it giving me a rise and set time and degree that are below 10, so
perhaps I'm not calling it correctly.


from skyfield.api import Topos, load
from datetime import timedelta

# Load TLE Information Feed
tle_url = 'http://celestrak.com/NORAD/elements/stations.txt'
satellites = load.tle(tle_url, reload=True)

# Create ISS object
iss = satellites['ISS (ZARYA)']

# Create Corbett object
corbett = Topos('45.27 N', '122.40 W')

# Create Timescale object
ts = load.timescale()

# Calculate/Output TLE Epoch Staleness value
current_time = ts.now()
epoch_stale_days = current_time - iss.epoch
if epoch_stale_days > 0:
  epoch_stale_direction = 'past'
else:
  epoch_stale_direction = 'before'
print('{:.3f} days {} ISS TLE Epoch'.format(epoch_stale_days,
epoch_stale_direction))


# Calculate passes over the next X days
to_time = ts.utc(current_time.utc_datetime() + timedelta(days=2))
t, events = iss.find_events(corbett, current_time, to_time,
altitude_degrees=10.0)
for ti, event in zip(t, events):
name = ('Rise', 'Culminate','Set')[event]
difference = iss - corbett
topocentric = difference.at(ti)
alt, az, distance = topocentric.altaz()
print('{} @ {} -  Bearing: {}  Altitude:
{}'.format(name,ti.utc_iso(),int(az.degrees),int(alt.degrees)))

On Mon, Feb 3, 2020 at 5:33 PM Susan Mackay  wrote:

> Had my 40m WSPR transmitter running last night and made it to just south
>> of you,  into Tasmania to VK7JJ; 13127 km away from me using 200 mw!
>>
> Very impressive! I've not got into WSPR myself - I'm more of a D-Star
> girl. Next you should try a moon bounce.
> I've been playing with the 'find_events' function (it is brand new; as in
> only a few days old) and it gives you the rise and set times of the
> satellite as it passes through the minimum elevation that you set - and NOT
> the actual rise and set times at the horizon. I've communicated with the
> author about this to suggest that there should be an option as to which
> rise/set times it gives you. I'm also looking at the source code to see if
> there is an easy way around this.
> Susan VK3ANZ
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-user/9be14a75-9358-444b-b444-c2e26aa9d95e%40googlegroups.com
> 
> .
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/CAHiQ_B1X3aNRahRZYaxK6kLEFq_obEjgzP_1H3vTrqgKjEejfw%40mail.gmail.com.

Re: [weewx-user] Re: Pyehpem and International Space Station

[Susan Mackay]

>
> Had my 40m WSPR transmitter running last night and made it to just south 
> of you,  into Tasmania to VK7JJ; 13127 km away from me using 200 mw!
>
Very impressive! I've not got into WSPR myself - I'm more of a D-Star girl. 
Next you should try a moon bounce.
I've been playing with the 'find_events' function (it is brand new; as in 
only a few days old) and it gives you the rise and set times of the 
satellite as it passes through the minimum elevation that you set - and NOT 
the actual rise and set times at the horizon. I've communicated with the 
author about this to suggest that there should be an option as to which 
rise/set times it gives you. I'm also looking at the source code to see if 
there is an easy way around this.
Susan VK3ANZ

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/9be14a75-9358-444b-b444-c2e26aa9d95e%40googlegroups.com.

Re: [weewx-user] Re: rtupdate.wunderground.com certificate error

[Leon Shaner]

Tom, All,

On that WU forum, an official rep said the rtupdate and weatherstation URL's go 
the same place.
He said it shouldn't matter which one.  So we can converge on a single URL.

This is down to same old same old "WU is a steaming pile" being the reason for 
the 404's.

Regards,
\Leon
--
Leon Shaner :: Dearborn, Michigan (iPad)

> On Feb 3, 2020, at 3:35 PM, Leon Shaner  wrote:
> 
>  Hey, WeeWx'ers.
> 
> Even my workaround of setting pws_url to the value of the rf_url is still 
> getting 404's, even if I explicitly set a Host header.   :-(
> 
> This is what I have tried...  I guess WU is just a steaming pile as per 
> usual.  :-/
> 
> Here is my attempted fix, which is part hack.
> The "fix" is adding the header.   The "hack" is forcing the code to use the 
> rtupdate URL (because I couldn't spot why the PWS URL was being used for RF).
> 
> $ diff restx.py restx.py_getting404 
> 100d99
> < from urllib.parse import urlparse
> 454,458c453
> < _parseduri = urlparse(url)
> < _parsedhost = '{uri.netloc}'.format(uri=_parseduri)
> < _request.add_header("Host", "%s" % _parsedhost)
> < #log.debug("%s: Added Header: 'Host: %s'"
> < #  % (self.protocol_name, _parsedhost))
> ---
> > _request.add_header("User-Agent", "weewx/%s" % weewx.__version__)
> 610,611c605
> < #pws_url = 
> "https://weatherstation.wunderground.com/weatherstation/updateweatherstation.php;
> < pws_url = 
> "https://rtupdate.wunderground.com/weatherstation/updateweatherstation.php;
> ---
> > pws_url = 
> > "https://weatherstation.wunderground.com/weatherstation/updateweatherstation.php;
> 
> Or in case your line numbers don't match mine (likely), here it is in context:
> ...
> # Python 2/3 compatiblity shims
> import six
> from six.moves import http_client
> from six.moves import queue
> from six.moves import urllib
> from urllib.parse import urlparse
> 
> ...
> 
> def get_request(self, url):
> """Get a request object. This can be overridden to add any special 
> headers."""
> _request = urllib.request.Request(url)
> _parseduri = urlparse(url)
> _parsedhost = '{uri.netloc}'.format(uri=_parseduri)
> _request.add_header("Host", "%s" % _parsedhost)
> #log.debug("%s: Added Header: 'Host: %s'"
> #  % (self.protocol_name, _parsedhost))
> _request.add_header("User-Agent", "weewx/%s" % weewx.__version__)
> return _request
> 
> 
> ...
> 
> # the rapidfire URL:
> rf_url = 
> "https://rtupdate.wunderground.com/weatherstation/updateweatherstation.php;
> # the personal weather station URL:
> #pws_url = 
> "https://weatherstation.wunderground.com/weatherstation/updateweatherstation.php;
> pws_url = 
> "https://rtupdate.wunderground.com/weatherstation/updateweatherstation.php;
> 
> 
> 
> 
> l...@isylum.org - Dearborn, Michigan
>> On 2/3/20 2:43 PM, Leon Shaner wrote:
>> Tom,
>> 
>> Looking at the code, under the do_rapidfire_post, we clearly see it uses 
>> rf_url.  In my debug output I referenced protocol_name and it's showing 
>> Wunderground-RF as the protocol, but the hostname is from pws_url.
>> I have temporarily set pws_url to the rtupdate URL and my 404's have stopped.
>> Looks like the rtupdate URL will take regular posts, but the weatherstation 
>> URL won't take rf posts.  :-/
>> 
>> My debug with pws_url replaced with the rf_url value now shows:
>> Feb  3 14:36:30 nixie weewx[8747] DEBUG weewx.restx: Wunderground-RF: Added 
>> Header: 'Host: rtupdate.wunderground.com'
>> That's what it should have shown if rf_url was getting used for 
>> do_rapidfire_post.
>> I'm stumped.  :-(
>> 
>> Regards,
>> \Leon
>> l...@isylum.org - Dearborn, Michigan
>>> On 2/3/20 2:23 PM, Leon Shaner wrote:
>>> Brice,
>>> 
>>> Thanks!  That's interesting...  I just added an explicit Host header to the 
>>> rtupdate request and put debug output there.
>>> This was unexpected:
>>> Feb  3 14:16:34 nixie weewx[8584] DEBUG weewx.restx: Wunderground-RF: Added 
>>> Header: 'Host: weatherstation.wunderground.com'
>>> That isn't the host that should be used for rapidfire, but it's taken from 
>>> the URL being used.  :-(
>>> We have:
>>> $ grep wunderground.com restx.py
>>> rf_url = 
>>> "https://rtupdate.wunderground.com/weatherstation/updateweatherstation.php;
>>> pws_url = 
>>> "https://weatherstation.wunderground.com/weatherstation/updateweatherstation.php;
>>> It will take me some time to figure out why restx.py is using the wrong URL.
>>> Must have been doing this for a long time, but seems that due to changes on 
>>> the WU side, they no longer accept rapidfire updates to the 
>>> weatherstation.wunderground.com host.
>>> 
>>> Regards,
>>> \Leon
>>> l...@isylum.org - Dearborn, Michigan
>>> On 2/3/20 12:59 PM, Brice Ruth wrote:
 header would be something like `Host: rtupdate.wunderground.com` ... 
 basically, whatever you're using as the hostname in the URL, needs to be 
 sent as 

[weewx-user] Re: New sensor - WT0124 Pool Thermometer

[Iain Grant]

Thank you. 

TBH I'd forgotten it was even there till the SDR picked it up :)

Thanks again,

ig.

On Monday, February 3, 2020 at 5:09:02 PM UTC-5, Gazza wrote:
>
>
> Hi Iain,
>
> I have found the weewx.conf for the system that had the pool sensor.
>
> [SDR]
> 
> driver = user.sdr
> path = /usr/local/bin
> 
> [[sensor_map]]
> 
> # station
> windGust = wind_gust.174.FOWHx080Packet
> outTempBatteryStatus = battery.174.FOWHx080Packet
> rain_total = rain_total.174.FOWHx080Packet
> windSpeed = wind_speed.174.FOWHx080Packet
> windDir = wind_dir.174.FOWHx080Packet
> outHumidity = humidity.174.FOWHx080Packet
> outTemp = temperature.174.FOWHx080Packet
> 
> # prologue - hall
> inHumidity = humidity.133.ProloguePacket
> inTemp = temperature.133.ProloguePacket
> inTempBatteryStatus = battery.133.ProloguePacket
> 
> # acurite - back deck
> extraTemp1 = temperature.32D1.AcuriteTowerPacket
> #extraHumid1 = humidity.32D1.AcuriteTowerPacket
> txBatteryStatus = battery.32D1.AcuriteTowerPacket
> 
> # digoo - downstairs
> extraTemp2 = temperature.1:180.NexusTemperaturePacket
> extraHumid1 = humidity.1:180.NexusTemperaturePacket
> windBatteryStatus = battery.1:180.NexusTemperaturePacket
> 
> # WT0124 - pool
> extraTemp3 = temperature.122.WT0124Packet
>
> The sensor build is not very good, the o-ring seal is crap and water got 
> in and it failed pretty quick !!
>
>
> Gary
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/4acd11e6-52ff-4483-bed3-6851f06e4c7b%40googlegroups.com.

[weewx-user] nogo: driver "ws23xx" and Python V3

[P Simmons]

I've attempted to move from Python2 to Python3, and have encountered a 
problem with ws23xx.py 

Thank you,
Paul

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/2cfe7671-0233-4197-aecc-c0f5d6b0b7d0%40googlegroups.com.
Feb  3 16:22:42 gummo weewx[9021] INFO __main__: Initializing weewx version 
4.0.0b11
Feb  3 16:22:42 gummo weewx[9021] INFO __main__: Using Python 3.5.3 (default, 
Sep 27 2018, 17:25:39) #012[GCC 6.3.0 20170516]
Feb  3 16:22:42 gummo weewx[9021] INFO __main__: Platform 
Linux-4.9.0-11-amd64-x86_64-with-debian-9
Feb  3 16:22:42 gummo weewx[9021] INFO __main__: Locale is 'en_US.UTF-8'
Feb  3 16:22:42 gummo weewx[9021] INFO __main__: PID file is /var/run/weewx.pid
Feb  3 16:22:42 gummo weewx[9025] INFO __main__: Using configuration file 
/home/weewx/weewx.conf
Feb  3 16:22:42 gummo weewx[9025] INFO weewx.engine: Loading station type 
WS23xx (weewx.drivers.ws23xx)
Feb  3 16:22:42 gummo weewx[9025] INFO weewx.drivers.ws23xx: driver version is 
0.40
Feb  3 16:22:42 gummo weewx[9025] INFO weewx.drivers.ws23xx: serial port is 
/dev/ttyS0
Feb  3 16:22:42 gummo weewx[9025] INFO weewx.drivers.ws23xx: polling interval 
is None
Feb  3 16:22:42 gummo weewx[9025] ERROR weewx.engine: Import of driver failed: 
tcsetattr: elements of attributes must be characters or integers ()
Feb  3 16:22:42 gummo weewx[9025] CRITICAL weewx.engine:   Traceback 
(most recent call last):
Feb  3 16:22:42 gummo weewx[9025] CRITICAL weewx.engine: File 
"/home/weewx/bin/weewx/engine.py", line 103, in setupStation
Feb  3 16:22:42 gummo weewx[9025] CRITICAL weewx.engine:   
self.console = loader_function(config_dict, self)
Feb  3 16:22:42 gummo weewx[9025] CRITICAL weewx.engine: File 
"/home/weewx/bin/weewx/drivers/ws23xx.py", line 271, in loader
Feb  3 16:22:42 gummo weewx[9025] CRITICAL weewx.engine:   return 
WS23xxDriver(config_dict=config_dict, **config_dict[DRIVER_NAME])
Feb  3 16:22:42 gummo weewx[9025] CRITICAL weewx.engine: File 
"/home/weewx/bin/weewx/drivers/ws23xx.py", line 438, in __init__
Feb  3 16:22:42 gummo weewx[9025] CRITICAL weewx.engine:   
self.station = WS23xx(self.port)
Feb  3 16:22:42 gummo weewx[9025] CRITICAL weewx.engine: File 
"/home/weewx/bin/weewx/drivers/ws23xx.py", line 640, in __init__
Feb  3 16:22:42 gummo weewx[9025] CRITICAL weewx.engine:   
self.serial_port = LinuxSerialPort(port)
Feb  3 16:22:42 gummo weewx[9025] CRITICAL weewx.engine: File 
"/home/weewx/bin/weewx/drivers/ws23xx.py", line 920, in __init__
Feb  3 16:22:42 gummo weewx[9025] CRITICAL weewx.engine:   
tty.tcsetattr(self.serial_port, tty.TCSAFLUSH, setup)
Feb  3 16:22:42 gummo weewx[9025] CRITICAL weewx.engine:   TypeError: 
tcsetattr: elements of attributes must be characters or integers
Feb  3 16:22:42 gummo weewx[9025] CRITICAL __main__: Unable to load driver: 
tcsetattr: elements of attributes must be characters or integers
Feb  3 16:22:42 gummo weewx[9025] CRITICAL __main__:   Exiting...

Re: [weewx-user] Re: rtupdate.wunderground.com certificate error

[Brice Ruth]

So, I'm a little stumped on why you're getting 404s unless you happen to be
hitting a region that's totally horked - where are you physically located?
I'm currently using 3.9.2-1 on my Pi 4 and I had temporarily disabled
`https`, but now have `https` re-enabled, but with the recent addition of
`/usr/bin/env PYTHONHTTPSVERIFY=0` to stop the weewx thread from failing
out after awhile. I've used rapidfire from the start and I don't see
anywhere that it's using the `weatherstation` URL - do you have
`archive_post` enabled as well, maybe? My errors were always indicating
failures in talking to `rtupdate...` as well, so I'm pretty sure on this
side, it hasn't been talking to anything but the rapidfire URL ... just not
sure why your setup seems to be doing that?

Brice Ruth, FCD
Software Engineer, Madison WI


On Mon, Feb 3, 2020 at 2:35 PM Leon Shaner  wrote:

> Hey, WeeWx'ers.
>
> Even my workaround of setting pws_url to the value of the rf_url is still
> getting 404's, even if I explicitly set a Host header.   :-(
>
> This is what I have tried...  I guess WU is just a steaming pile as per
> usual.  :-/
>
> Here is my attempted fix, which is part hack.
> The "fix" is adding the header.   The "hack" is forcing the code to use
> the rtupdate URL (because I couldn't spot why the PWS URL was being used
> for RF).
>
> $ diff restx.py restx.py_getting404
> 100d99
> < from urllib.parse import urlparse
> 454,458c453
> < _parseduri = urlparse(url)
> < _parsedhost = '{uri.netloc}'.format(uri=_parseduri)
> < _request.add_header("Host", "%s" % _parsedhost)
> < #log.debug("%s: Added Header: 'Host: %s'"
> < #  % (self.protocol_name, _parsedhost))
> ---
> > _request.add_header("User-Agent", "weewx/%s" % weewx.__version__)
> 610,611c605
> < #pws_url =
> "https://weatherstation.wunderground.com/weatherstation/updateweatherstation.php;
> 
> < pws_url =
> "https://rtupdate.wunderground.com/weatherstation/updateweatherstation.php;
> 
> ---
> > pws_url =
> "https://weatherstation.wunderground.com/weatherstation/updateweatherstation.php;
> 
>
> Or in case your line numbers don't match mine (likely), here it is in
> context:
>
> ...
> # Python 2/3 compatiblity shims
> import six
> from six.moves import http_client
> from six.moves import queue
> from six.moves import urllib
> from urllib.parse import urlparse
>
> ...
>
> def get_request(self, url):
> """Get a request object. This can be overridden to add any special
> headers."""
> _request = urllib.request.Request(url)
> _parseduri = urlparse(url)
> _parsedhost = '{uri.netloc}'.format(uri=_parseduri)
> _request.add_header("Host", "%s" % _parsedhost)
> #log.debug("%s: Added Header: 'Host: %s'"
> #  % (self.protocol_name, _parsedhost))
> _request.add_header("User-Agent", "weewx/%s" % weewx.__version__)
> return _request
>
>
> ...
>
> # the rapidfire URL:
> rf_url =
> "https://rtupdate.wunderground.com/weatherstation/updateweatherstation.php;
> 
> # the personal weather station URL:
> #pws_url =
> "https://weatherstation.wunderground.com/weatherstation/updateweatherstation.php;
> 
> pws_url =
> "https://rtupdate.wunderground.com/weatherstation/updateweatherstation.php;
> 
>
>
>
>
> l...@isylum.org - Dearborn, Michigan
>
> On 2/3/20 2:43 PM, Leon Shaner wrote:
>
> Tom,
>
> Looking at the code, under the do_rapidfire_post, we clearly see it uses
> rf_url.  In my debug output I referenced protocol_name and it's showing
> Wunderground-RF as the protocol, but the hostname is from pws_url.
> I have temporarily set pws_url to the rtupdate URL and my 404's have
> stopped.
> Looks like the rtupdate URL will take regular posts, but the
> weatherstation URL won't take rf posts.  :-/
>
> My debug with pws_url replaced with the rf_url value now shows:
>
> Feb  3 14:36:30 nixie weewx[8747] DEBUG weewx.restx: Wunderground-RF:
> Added Header: 'Host: rtupdate.wunderground.com'
>
> That's what it should have shown if rf_url was getting used for
> do_rapidfire_post.
> I'm stumped.  :-(
>
> Regards,
> \Leon
>
> l...@isylum.org - Dearborn, Michigan
>
> On 2/3/20 2:23 PM, Leon Shaner wrote:
>
> Brice,
>
> Thanks!  That's interesting...  I just added an explicit Host header to
> the rtupdate request and put debug output there.
> This was unexpected:
>
> Feb  3 14:16:34 nixie weewx[8584] DEBUG weewx.restx: Wunderground-RF:
> Added Header: 'Host: 

[weewx-user] Re: New sensor - WT0124 Pool Thermometer

[Gazza]

Hi Iain,

I have found the weewx.conf for the system that had the pool sensor.

[SDR]

driver = user.sdr
path = /usr/local/bin

[[sensor_map]]

# station
windGust = wind_gust.174.FOWHx080Packet
outTempBatteryStatus = battery.174.FOWHx080Packet
rain_total = rain_total.174.FOWHx080Packet
windSpeed = wind_speed.174.FOWHx080Packet
windDir = wind_dir.174.FOWHx080Packet
outHumidity = humidity.174.FOWHx080Packet
outTemp = temperature.174.FOWHx080Packet

# prologue - hall
inHumidity = humidity.133.ProloguePacket
inTemp = temperature.133.ProloguePacket
inTempBatteryStatus = battery.133.ProloguePacket

# acurite - back deck
extraTemp1 = temperature.32D1.AcuriteTowerPacket
#extraHumid1 = humidity.32D1.AcuriteTowerPacket
txBatteryStatus = battery.32D1.AcuriteTowerPacket

# digoo - downstairs
extraTemp2 = temperature.1:180.NexusTemperaturePacket
extraHumid1 = humidity.1:180.NexusTemperaturePacket
windBatteryStatus = battery.1:180.NexusTemperaturePacket

# WT0124 - pool
extraTemp3 = temperature.122.WT0124Packet

The sensor build is not very good, the o-ring seal is crap and water got in 
and it failed pretty quick !!


Gary

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/79525dbf-0cbb-48e0-a4b0-644d63d29e50%40googlegroups.com.

Re: [weewx-user] Re: rtupdate.wunderground.com certificate error

[Leon Shaner]

Hey, WeeWx'ers.

Even my workaround of setting pws_url to the value of the rf_url is 
still getting 404's, even if I explicitly set a Host header. :-(


This is what I have tried...  I guess WU is just a steaming pile as per 
usual.  :-/


Here is my attempted fix, which is part hack.
The "fix" is adding the header.   The "hack" is forcing the code to use 
the rtupdate URL (because I couldn't spot why the PWS URL was being used 
for RF).


   $ diff restx.py restx.py_getting404
   100d99
   < from urllib.parse import urlparse
   454,458c453
   < _parseduri = urlparse(url)
   < _parsedhost = '{uri.netloc}'.format(uri=_parseduri)
   < _request.add_header("Host", "%s" % _parsedhost)
   < #    log.debug("%s: Added Header: 'Host: %s'"
   < #  % (self.protocol_name, _parsedhost))
   ---
> _request.add_header("User-Agent", "weewx/%s" %
   weewx.__version__)
   610,611c605
   < #pws_url =
   
"https://weatherstation.wunderground.com/weatherstation/updateweatherstation.php;
   < pws_url =
   "https://rtupdate.wunderground.com/weatherstation/updateweatherstation.php;
   ---
> pws_url =
   
"https://weatherstation.wunderground.com/weatherstation/updateweatherstation.php;

Or in case your line numbers don't match mine (likely), here it is in 
context:


   ...
   # Python 2/3 compatiblity shims
   import six
   from six.moves import http_client
   from six.moves import queue
   from six.moves import urllib
   from urllib.parse import urlparse

   ...

    def get_request(self, url):
    """Get a request object. This can be overridden to add any
   special headers."""
    _request = urllib.request.Request(url)
    _parseduri = urlparse(url)
    _parsedhost = '{uri.netloc}'.format(uri=_parseduri)
    _request.add_header("Host", "%s" % _parsedhost)
   #    log.debug("%s: Added Header: 'Host: %s'"
   #  % (self.protocol_name, _parsedhost))
    _request.add_header("User-Agent", "weewx/%s" %
   weewx.__version__)
    return _request


   ...

    # the rapidfire URL:
    rf_url =
   "https://rtupdate.wunderground.com/weatherstation/updateweatherstation.php;
    # the personal weather station URL:
    #pws_url =
   
"https://weatherstation.wunderground.com/weatherstation/updateweatherstation.php;
    pws_url =
   "https://rtupdate.wunderground.com/weatherstation/updateweatherstation.php;




l...@isylum.org - Dearborn, Michigan

On 2/3/20 2:43 PM, Leon Shaner wrote:

Tom,

Looking at the code, under the do_rapidfire_post, we clearly see it 
uses rf_url.  In my debug output I referenced protocol_name and it's 
showing Wunderground-RF as the protocol, but the hostname is from pws_url.
I have temporarily set pws_url to the rtupdate URL and my 404's have 
stopped.
Looks like the rtupdate URL will take regular posts, but the 
weatherstation URL won't take rf posts.  :-/


My debug with pws_url replaced with the rf_url value now shows:

Feb  3 14:36:30 nixie weewx[8747] DEBUG weewx.restx:
Wunderground-RF: Added Header: 'Host: rtupdate.wunderground.com'

That's what it should have shown if rf_url was getting used for 
do_rapidfire_post.

I'm stumped.  :-(

Regards,
\Leon
l...@isylum.org  - Dearborn, Michigan
On 2/3/20 2:23 PM, Leon Shaner wrote:

Brice,

Thanks!  That's interesting...  I just added an explicit Host header 
to the rtupdate request and put debug output there.

This was unexpected:

Feb  3 14:16:34 nixie weewx[8584] DEBUG weewx.restx:
Wunderground-RF: Added Header: 'Host:
/*weatherstation.wunderground.com*/'

That isn't the host that should be used for rapidfire, but it's taken 
from the URL being used.  :-(

We have:

$ grep wunderground.com restx.py
    rf_url =
"https://rtupdate.wunderground.com/weatherstation/updateweatherstation.php;
    pws_url =

"https://weatherstation.wunderground.com/weatherstation/updateweatherstation.php;

It will take me some time to figure out why restx.py is using the 
wrong URL.
Must have been doing this for a long time, but seems that due to 
changes on the WU side, they no longer accept rapidfire updates to 
the weatherstation.wunderground.com host.


Regards,
\Leon
l...@isylum.org  - Dearborn, Michigan
On 2/3/20 12:59 PM, Brice Ruth wrote:
header would be something like `Host: rtupdate.wunderground.com 
` ... basically, whatever you're 
using as the hostname in the URL, needs to be sent as the `Host` 
header ... that allows load-balancers to route the request to the 
correct backend.


Brice Ruth, FCD
Software Engineer, Madison WI


On Mon, Feb 3, 2020 at 11:44 AM Leon Shaner > wrote:


Hey, WeeWx'ers,

I am still getting 404 errors from the rtupdate URL site.
There is a reply over here about it.
I'm now looking into what the headers need to be.
Does anyone know?

Re: [weewx-user] Re: rtupdate.wunderground.com certificate error

[Leon Shaner]

Tom,

Looking at the code, under the do_rapidfire_post, we clearly see it uses 
rf_url.  In my debug output I referenced protocol_name and it's showing 
Wunderground-RF as the protocol, but the hostname is from pws_url.
I have temporarily set pws_url to the rtupdate URL and my 404's have 
stopped.
Looks like the rtupdate URL will take regular posts, but the 
weatherstation URL won't take rf posts.  :-/


My debug with pws_url replaced with the rf_url value now shows:

   Feb  3 14:36:30 nixie weewx[8747] DEBUG weewx.restx:
   Wunderground-RF: Added Header: 'Host: rtupdate.wunderground.com'

That's what it should have shown if rf_url was getting used for 
do_rapidfire_post.

I'm stumped.  :-(

Regards,
\Leon

l...@isylum.org - Dearborn, Michigan

On 2/3/20 2:23 PM, Leon Shaner wrote:

Brice,

Thanks!  That's interesting...  I just added an explicit Host header 
to the rtupdate request and put debug output there.

This was unexpected:

Feb  3 14:16:34 nixie weewx[8584] DEBUG weewx.restx:
Wunderground-RF: Added Header: 'Host:
/*weatherstation.wunderground.com*/'

That isn't the host that should be used for rapidfire, but it's taken 
from the URL being used.  :-(

We have:

$ grep wunderground.com restx.py
    rf_url =
"https://rtupdate.wunderground.com/weatherstation/updateweatherstation.php;
    pws_url =

"https://weatherstation.wunderground.com/weatherstation/updateweatherstation.php;

It will take me some time to figure out why restx.py is using the 
wrong URL.
Must have been doing this for a long time, but seems that due to 
changes on the WU side, they no longer accept rapidfire updates to the 
weatherstation.wunderground.com host.


Regards,
\Leon
l...@isylum.org  - Dearborn, Michigan
On 2/3/20 12:59 PM, Brice Ruth wrote:
header would be something like `Host: rtupdate.wunderground.com 
` ... basically, whatever you're 
using as the hostname in the URL, needs to be sent as the `Host` 
header ... that allows load-balancers to route the request to the 
correct backend.


Brice Ruth, FCD
Software Engineer, Madison WI


On Mon, Feb 3, 2020 at 11:44 AM Leon Shaner > wrote:


Hey, WeeWx'ers,

I am still getting 404 errors from the rtupdate URL site.
There is a reply over here about it.
I'm now looking into what the headers need to be.
Does anyone know?


https://apicommunity.wunderground.com/weatherapi/topics/is-the-rtupdate-wunderground-com-address-no-longer-valid


For requests to route properly, the
host header must be set correctly
path must be correct


Regards,
\Leon
--
Leon Shaner :: Dearborn, Michigan (iPad)


On Feb 1, 2020, at 12:39 PM, Leon Shaner mailto:l...@isylum.org>> wrote:

Hey, WeeWx'ers.

I took a different approach to working around the WU certificate
issue -- keep SSL but don't verify the CERT.  Scroll for that
"solution."

But meanwhile, using Wunderground-RF (rapid fire) I am getting
an HTTP Error 404:  Not Found.
Any ideas on that?   Did they change the URL, or is it just down?

I noticed that even their own WunderStation App on iOS/iPadOS is
subject to the certificate issue and reports all stations as
"not reporting" -- even ones that are, like mine, which I can
verify via the WU website has the data and has reported within
minutes ago.

From the logs, re: RapidFire HTTP 404:

Feb  1 12:31:51 nixie weewx[13184] DEBUG weewx.restx:
Wunderground-RF: Failed upload attempt 1: HTTP Error 404: Not Found
Feb  1 12:31:51 nixie weewx[13184] ERROR weewx.restx:
Wunderground-RF: Failed to publish record 2020-02-01 12:31:51
EST (1580578311): Failed upload after 1 tries
Feb  1 12:31:56 nixie weewx[13184] DEBUG weewx.restx:
Wunderground-RF: Failed upload attempt 1: HTTP Error 404: Not Found
Feb  1 12:31:56 nixie weewx[13184] ERROR weewx.restx:
Wunderground-RF: Failed to publish record 2020-02-01 12:31:56
EST (1580578316): Failed upload after 1 tries
Feb  1 12:32:04 nixie weewx[13184] DEBUG weewx.restx:
Wunderground-RF: Failed upload attempt 1: HTTP Error 404: Not Found
Feb  1 12:32:04 nixie weewx[13184] ERROR weewx.restx:
Wunderground-RF: Failed to publish record 2020-02-01 12:32:04
EST (1580578324): Failed upload after 1 tries
Feb  1 12:32:05 nixie weewx[13184] DEBUG weewx.restx:
Wunderground-RF: Failed upload attempt 1: HTTP Error 404: Not Found
Feb  1 12:32:05 nixie weewx[13184] ERROR weewx.restx:
Wunderground-RF: Failed to publish record 2020-02-01 12:32:05
EST (1580578325): Failed upload after 1 tries
Feb  1 12:32:06 nixie weewx[13184] DEBUG weewx.restx:
Wunderground-RF: Failed upload attempt 1: HTTP Error 404: Not Found
Feb  1 12:32:06 nixie weewx[13184] ERROR weewx.restx:
Wunderground-RF: Failed to publish record 2020-02-01 12:32:05
EST (1580578325): Failed upload after 1 tries


Here is the 

Re: [weewx-user] Re: rtupdate.wunderground.com certificate error

[Leon Shaner]

Brice,

Thanks!  That's interesting...  I just added an explicit Host header to 
the rtupdate request and put debug output there.

This was unexpected:

   Feb  3 14:16:34 nixie weewx[8584] DEBUG weewx.restx:
   Wunderground-RF: Added Header: 'Host:
   /*weatherstation.wunderground.com*/'

That isn't the host that should be used for rapidfire, but it's taken 
from the URL being used.  :-(

We have:

   $ grep wunderground.com restx.py
    rf_url =
   "https://rtupdate.wunderground.com/weatherstation/updateweatherstation.php;
    pws_url =
   
"https://weatherstation.wunderground.com/weatherstation/updateweatherstation.php;

It will take me some time to figure out why restx.py is using the wrong URL.
Must have been doing this for a long time, but seems that due to changes 
on the WU side, they no longer accept rapidfire updates to the 
weatherstation.wunderground.com host.


Regards,
\Leon

l...@isylum.org - Dearborn, Michigan

On 2/3/20 12:59 PM, Brice Ruth wrote:
header would be something like `Host: rtupdate.wunderground.com 
` ... basically, whatever you're 
using as the hostname in the URL, needs to be sent as the `Host` 
header ... that allows load-balancers to route the request to the 
correct backend.


Brice Ruth, FCD
Software Engineer, Madison WI


On Mon, Feb 3, 2020 at 11:44 AM Leon Shaner > wrote:


Hey, WeeWx'ers,

I am still getting 404 errors from the rtupdate URL site.
There is a reply over here about it.
I'm now looking into what the headers need to be.
Does anyone know?


https://apicommunity.wunderground.com/weatherapi/topics/is-the-rtupdate-wunderground-com-address-no-longer-valid


For requests to route properly, the
host header must be set correctly
path must be correct


Regards,
\Leon
--
Leon Shaner :: Dearborn, Michigan (iPad)


On Feb 1, 2020, at 12:39 PM, Leon Shaner mailto:l...@isylum.org>> wrote:

Hey, WeeWx'ers.

I took a different approach to working around the WU certificate
issue -- keep SSL but don't verify the CERT.  Scroll for that
"solution."

But meanwhile, using Wunderground-RF (rapid fire) I am getting an
HTTP Error 404:  Not Found.
Any ideas on that?   Did they change the URL, or is it just down?

I noticed that even their own WunderStation App on iOS/iPadOS is
subject to the certificate issue and reports all stations as "not
reporting" -- even ones that are, like mine, which I can verify
via the WU website has the data and has reported within minutes ago.

From the logs, re: RapidFire HTTP 404:

Feb  1 12:31:51 nixie weewx[13184] DEBUG weewx.restx:
Wunderground-RF: Failed upload attempt 1: HTTP Error 404: Not Found
Feb  1 12:31:51 nixie weewx[13184] ERROR weewx.restx:
Wunderground-RF: Failed to publish record 2020-02-01 12:31:51 EST
(1580578311): Failed upload after 1 tries
Feb  1 12:31:56 nixie weewx[13184] DEBUG weewx.restx:
Wunderground-RF: Failed upload attempt 1: HTTP Error 404: Not Found
Feb  1 12:31:56 nixie weewx[13184] ERROR weewx.restx:
Wunderground-RF: Failed to publish record 2020-02-01 12:31:56 EST
(1580578316): Failed upload after 1 tries
Feb  1 12:32:04 nixie weewx[13184] DEBUG weewx.restx:
Wunderground-RF: Failed upload attempt 1: HTTP Error 404: Not Found
Feb  1 12:32:04 nixie weewx[13184] ERROR weewx.restx:
Wunderground-RF: Failed to publish record 2020-02-01 12:32:04 EST
(1580578324): Failed upload after 1 tries
Feb  1 12:32:05 nixie weewx[13184] DEBUG weewx.restx:
Wunderground-RF: Failed upload attempt 1: HTTP Error 404: Not Found
Feb  1 12:32:05 nixie weewx[13184] ERROR weewx.restx:
Wunderground-RF: Failed to publish record 2020-02-01 12:32:05 EST
(1580578325): Failed upload after 1 tries
Feb  1 12:32:06 nixie weewx[13184] DEBUG weewx.restx:
Wunderground-RF: Failed upload attempt 1: HTTP Error 404: Not Found
Feb  1 12:32:06 nixie weewx[13184] ERROR weewx.restx:
Wunderground-RF: Failed to publish record 2020-02-01 12:32:05 EST
(1580578325): Failed upload after 1 tries


Here is the diff for my SSL CERT workaround:

$ diff restx.py restx.py.20200201.1
110,115d109
< # SSL certificate hack
< global WUssl
< WUssl = ssl.create_default_context();
< WUssl.check_hostname=False
< WUssl.verify_mode=ssl.CERT_NONE
<
454d447
< _request.add_header("User-Agent", "weewx/%s" % weewx.__version__)
543,544c536
< #        _response = urllib.request.urlopen(request,
data=data_bytes, timeout=self.timeout)
<         _response = urllib.request.urlopen(request,
data=data_bytes, timeout=self.timeout, context=WUssl)
---
>         _response = urllib.request.urlopen(request,
data=data_bytes, timeout=self.timeout)
1051,1052c1043
< #            _response = urllib.request.urlopen(request,
timeout=self.timeout)
<         

[weewx-user] Re: Gravity AS3935 lightning detector

[Giuseppe Saia]

scuse me for my bad english
I attach the compressed file valid for a generic as3935 but it does not 
work for my lightning detector with dfrobot sensor
I would like someone to help me edit the py file so that it works with the 
sensor in my possession
thanks to those who want to help me ...

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/a3ea2f68-d4b9-4dc5-ae4e-e489fdfb9476%40googlegroups.com.


weewx-as3935-0.6.tgz
Description: GNU Unix tar archive

[weewx-user] wanted: Ecowitt WS68 anemometer users that also have an rtlsdr and are familiar with rtl_433. It's almost ready for deployment! :-)

['Tolip Wen' via weewx-user]

Hi, I'm in the middle of helping to add Ecowitt WS68(wind) to rtl_433.
The WH40(rain) is complete.

We have the WS68 Anemometer packets decoding and we lack a few details.
We need to compare rtl_433 packets with GW1000 data to wrap it up.
Specifically we need wind speed and UV data.

Do you use rtl_433 and also have an Ecowitt GW1000?
Do you use rtl_433 with a different anemometer and also have an Ecowitt 
WS68 for comparison?

If you do there are 2 ways to contribute.

If you use pre-built binaries you can capture raw packets with a flex 
decoder.
  -X "n=WS68_flex_decoder,m=FSK_PCM,s=58,l=58,r=5000,g=4000,preamble=aa2dd4"
Capture some packets and report what wind data you see on the GW1000 for 
wind at time of capture.
The needed data will look similar to

"codes : {139}68c54b0f00916f85104"

The 68(hex) after the curly braces tells you it's a WS68 packet.
If you 00 after the five "f" (00) then there is no wind, not useful.

If you compile your own you can pull the latest code and use the 
in-progress WS68 decoder.
Again compare what rtl_433 see's and compare to GW1000 wind data.

What we need is "known wind data" to adjust the decoded WS68 data into 
something useful.
We're almost there.

I'm trying to avoid driving around holding the fragile anemometer out the 
window to calibrate the rtl_433 WS68 decoder, lol.

Please and Thank You! :-)


-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/5e2448de-8ea9-457c-bfc4-cdc5130a2693%40googlegroups.com.

Re: [weewx-user] Re: rtupdate.wunderground.com certificate error

[Brice Ruth]

header would be something like `Host: rtupdate.wunderground.com` ...
basically, whatever you're using as the hostname in the URL, needs to be
sent as the `Host` header ... that allows load-balancers to route the
request to the correct backend.

Brice Ruth, FCD
Software Engineer, Madison WI


On Mon, Feb 3, 2020 at 11:44 AM Leon Shaner  wrote:

> Hey, WeeWx'ers,
>
> I am still getting 404 errors from the rtupdate URL site.
> There is a reply over here about it.
> I'm now looking into what the headers need to be.
> Does anyone know?
>
>
> https://apicommunity.wunderground.com/weatherapi/topics/is-the-rtupdate-wunderground-com-address-no-longer-valid
>
> For requests to route properly, the
> host header must be set correctly
> path must be correct
>
>
> Regards,
> \Leon
> --
> Leon Shaner :: Dearborn, Michigan (iPad)
>
> On Feb 1, 2020, at 12:39 PM, Leon Shaner  wrote:
>
> Hey, WeeWx'ers.
>
> I took a different approach to working around the WU certificate issue --
> keep SSL but don't verify the CERT.  Scroll for that "solution."
>
> But meanwhile, using Wunderground-RF (rapid fire) I am getting an HTTP
> Error 404:  Not Found.
> Any ideas on that?   Did they change the URL, or is it just down?
>
> I noticed that even their own WunderStation App on iOS/iPadOS is subject
> to the certificate issue and reports all stations as "not reporting" --
> even ones that are, like mine, which I can verify via the WU website has
> the data and has reported within minutes ago.
>
> From the logs, re: RapidFire HTTP 404:
>
> Feb  1 12:31:51 nixie weewx[13184] DEBUG weewx.restx: Wunderground-RF:
> Failed upload attempt 1: HTTP Error 404: Not Found
> Feb  1 12:31:51 nixie weewx[13184] ERROR weewx.restx: Wunderground-RF:
> Failed to publish record 2020-02-01 12:31:51 EST (1580578311): Failed
> upload after 1 tries
> Feb  1 12:31:56 nixie weewx[13184] DEBUG weewx.restx: Wunderground-RF:
> Failed upload attempt 1: HTTP Error 404: Not Found
> Feb  1 12:31:56 nixie weewx[13184] ERROR weewx.restx: Wunderground-RF:
> Failed to publish record 2020-02-01 12:31:56 EST (1580578316): Failed
> upload after 1 tries
> Feb  1 12:32:04 nixie weewx[13184] DEBUG weewx.restx: Wunderground-RF:
> Failed upload attempt 1: HTTP Error 404: Not Found
> Feb  1 12:32:04 nixie weewx[13184] ERROR weewx.restx: Wunderground-RF:
> Failed to publish record 2020-02-01 12:32:04 EST (1580578324): Failed
> upload after 1 tries
> Feb  1 12:32:05 nixie weewx[13184] DEBUG weewx.restx: Wunderground-RF:
> Failed upload attempt 1: HTTP Error 404: Not Found
> Feb  1 12:32:05 nixie weewx[13184] ERROR weewx.restx: Wunderground-RF:
> Failed to publish record 2020-02-01 12:32:05 EST (1580578325): Failed
> upload after 1 tries
> Feb  1 12:32:06 nixie weewx[13184] DEBUG weewx.restx: Wunderground-RF:
> Failed upload attempt 1: HTTP Error 404: Not Found
> Feb  1 12:32:06 nixie weewx[13184] ERROR weewx.restx: Wunderground-RF:
> Failed to publish record 2020-02-01 12:32:05 EST (1580578325): Failed
> upload after 1 tries
>
>
> Here is the diff for my SSL CERT workaround:
>
> $ diff restx.py restx.py.20200201.1
> 110,115d109
> < # SSL certificate hack
> < global WUssl
> < WUssl = ssl.create_default_context();
> < WUssl.check_hostname=False
> < WUssl.verify_mode=ssl.CERT_NONE
> <
> 454d447
> < _request.add_header("User-Agent", "weewx/%s" % weewx.__version__)
> 543,544c536
> < #_response = urllib.request.urlopen(request, data=data_bytes,
> timeout=self.timeout)
> < _response = urllib.request.urlopen(request, data=data_bytes,
> timeout=self.timeout, context=WUssl)
> ---
> > _response = urllib.request.urlopen(request, data=data_bytes,
> timeout=self.timeout)
> 1051,1052c1043
> < #_response = urllib.request.urlopen(request,
> timeout=self.timeout)
> < _response = urllib.request.urlopen(request,
> timeout=self.timeout, context=WUssl)
> ---
> > _response = urllib.request.urlopen(request,
> timeout=self.timeout)
>
>
> Regards,
> \Leon
> --
> Leon Shaner :: Dearborn, Michigan (iPad)
>
> On Jan 31, 2020, at 4:16 PM, Thomas Keffer  wrote:
>
> 
> Travis: what is the error? If it's a certificate error, Version 4 will do
> a retry after an hour. Unfortunately, Version 3 does not.
>
> On Fri, Jan 31, 2020 at 1:04 PM Travis Bully  wrote:
>
>> Not here yet.  It'll work for awhile and then will get the random cert
>> error I sent earlier.  A restart of weewx will get it going again.  I wish
>> restx would just try again after xx seconds.
>>
>>
>>
>> On Friday, January 31, 2020 at 2:48:50 PM UTC-5, J B wrote:
>>>
>>> Working here too. I had to restart Weewx.
>>>
>>> On Friday, January 31, 2020 at 11:34:19 AM UTC-8, Brice Ruth wrote:

 Looking like it's working to me, too.

 Brice Ruth, FCD
 Software Engineer, Madison WI


 On Fri, Jan 31, 2020 at 1:31 PM Travis Bully  wrote:

> Agreed.  Seems like I still get one cert error every now and then.
> Likely still propagating changes through 

Re: [weewx-user] Re: rtupdate.wunderground.com certificate error

[Leon Shaner]

Hey, WeeWx'ers,

I am still getting 404 errors from the rtupdate URL site.
There is a reply over here about it.
I'm now looking into what the headers need to be.
Does anyone know?

https://apicommunity.wunderground.com/weatherapi/topics/is-the-rtupdate-wunderground-com-address-no-longer-valid

> For requests to route properly, the
> host header must be set correctly
> path must be correct

Regards,
\Leon
--
Leon Shaner :: Dearborn, Michigan (iPad)

> On Feb 1, 2020, at 12:39 PM, Leon Shaner  wrote:
> 
> Hey, WeeWx'ers.
> 
> I took a different approach to working around the WU certificate issue -- 
> keep SSL but don't verify the CERT.  Scroll for that "solution."
> 
> But meanwhile, using Wunderground-RF (rapid fire) I am getting an HTTP Error 
> 404:  Not Found.
> Any ideas on that?   Did they change the URL, or is it just down?
> 
> I noticed that even their own WunderStation App on iOS/iPadOS is subject to 
> the certificate issue and reports all stations as "not reporting" -- even 
> ones that are, like mine, which I can verify via the WU website has the data 
> and has reported within minutes ago.
> 
> From the logs, re: RapidFire HTTP 404:
> 
> Feb  1 12:31:51 nixie weewx[13184] DEBUG weewx.restx: Wunderground-RF: Failed 
> upload attempt 1: HTTP Error 404: Not Found
> Feb  1 12:31:51 nixie weewx[13184] ERROR weewx.restx: Wunderground-RF: Failed 
> to publish record 2020-02-01 12:31:51 EST (1580578311): Failed upload after 1 
> tries
> Feb  1 12:31:56 nixie weewx[13184] DEBUG weewx.restx: Wunderground-RF: Failed 
> upload attempt 1: HTTP Error 404: Not Found
> Feb  1 12:31:56 nixie weewx[13184] ERROR weewx.restx: Wunderground-RF: Failed 
> to publish record 2020-02-01 12:31:56 EST (1580578316): Failed upload after 1 
> tries
> Feb  1 12:32:04 nixie weewx[13184] DEBUG weewx.restx: Wunderground-RF: Failed 
> upload attempt 1: HTTP Error 404: Not Found
> Feb  1 12:32:04 nixie weewx[13184] ERROR weewx.restx: Wunderground-RF: Failed 
> to publish record 2020-02-01 12:32:04 EST (1580578324): Failed upload after 1 
> tries
> Feb  1 12:32:05 nixie weewx[13184] DEBUG weewx.restx: Wunderground-RF: Failed 
> upload attempt 1: HTTP Error 404: Not Found
> Feb  1 12:32:05 nixie weewx[13184] ERROR weewx.restx: Wunderground-RF: Failed 
> to publish record 2020-02-01 12:32:05 EST (1580578325): Failed upload after 1 
> tries
> Feb  1 12:32:06 nixie weewx[13184] DEBUG weewx.restx: Wunderground-RF: Failed 
> upload attempt 1: HTTP Error 404: Not Found
> Feb  1 12:32:06 nixie weewx[13184] ERROR weewx.restx: Wunderground-RF: Failed 
> to publish record 2020-02-01 12:32:05 EST (1580578325): Failed upload after 1 
> tries
> 
> 
> Here is the diff for my SSL CERT workaround:
> 
> $ diff restx.py restx.py.20200201.1
> 110,115d109
> < # SSL certificate hack
> < global WUssl
> < WUssl = ssl.create_default_context();
> < WUssl.check_hostname=False
> < WUssl.verify_mode=ssl.CERT_NONE
> <
> 454d447
> < _request.add_header("User-Agent", "weewx/%s" % weewx.__version__)
> 543,544c536
> < #_response = urllib.request.urlopen(request, data=data_bytes, 
> timeout=self.timeout)
> < _response = urllib.request.urlopen(request, data=data_bytes, 
> timeout=self.timeout, context=WUssl)
> ---
> > _response = urllib.request.urlopen(request, data=data_bytes, 
> > timeout=self.timeout)
> 1051,1052c1043
> < #_response = urllib.request.urlopen(request, 
> timeout=self.timeout)
> < _response = urllib.request.urlopen(request, 
> timeout=self.timeout, context=WUssl)
> ---
> > _response = urllib.request.urlopen(request, 
> > timeout=self.timeout)
> 
> 
> Regards,
> \Leon
> --
> Leon Shaner :: Dearborn, Michigan (iPad)
> 
>>> On Jan 31, 2020, at 4:16 PM, Thomas Keffer  wrote:
>>> 
>> 
>> Travis: what is the error? If it's a certificate error, Version 4 will do a 
>> retry after an hour. Unfortunately, Version 3 does not.
>> 
>>> On Fri, Jan 31, 2020 at 1:04 PM Travis Bully  wrote:
>>> Not here yet.  It'll work for awhile and then will get the random cert 
>>> error I sent earlier.  A restart of weewx will get it going again.  I wish 
>>> restx would just try again after xx seconds.
>>> 
>>> 
>>> 
 On Friday, January 31, 2020 at 2:48:50 PM UTC-5, J B wrote:
 Working here too. I had to restart Weewx.
 
> On Friday, January 31, 2020 at 11:34:19 AM UTC-8, Brice Ruth wrote:
> Looking like it's working to me, too.
> 
> Brice Ruth, FCD
> Software Engineer, Madison WI
> 
> 
>> On Fri, Jan 31, 2020 at 1:31 PM Travis Bully  wrote:
>> Agreed.  Seems like I still get one cert error every now and then.  
>> Likely still propagating changes through their infrastructure?
>> 
>> Jan 31 14:29:25 homeauto03 weewx[3784]: restx: Wunderground-RF: 
>> Published record 2020-01-31 14:29:24 EST (1580498964)
>> Jan 31 14:29:26 homeauto03 weewx[3784]: restx: Wunderground-RF: Failed 
>> upload attempt 1: > certificate verify failed 

[weewx-user] Re: Gravity AS3935 lightning detector

[Giuseppe Saia]

I attach the compressed file valid for a generic and not working as3935 for 
my dfrobot sensor lightning detector
I'd like someone to help me edit the happy py file in this compressed file 
to make it work with the sensor in my possession
thanks to those who want to help me ...

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/a14ccf23-c7ba-47b9-8cec-58c8ef4acc5b%40googlegroups.com.


weewx-as3935-0.6.tgz
Description: GNU Unix tar archive

Re: [weewx-user] Re: Pyehpem and International Space Station

[Kevin Davis]

And additionally Susan, apropos of nothing, but I noticed you're a ham, as
am I; KE7K here.

Had my 40m WSPR transmitter running last night and made it to just south of
you,  into Tasmania to VK7JJ; 13127 km away from me using 200 mw!

7 3

On Mon, Feb 3, 2020 at 7:14 AM Kevin Davis  wrote:

> Thanks a lot Susan!  That's exactly what I was looking for.
>
> On Sun, Feb 2, 2020 at 6:32 PM Susan Mackay  wrote:
>
>> Also consider using SkyField instead of PyEphem as it is newer and
>> supported.
>> Look at https://rhodesmill.org/skyfield/earth-satellites.html and the
>> example under the title 'Finding when a satellite rises and sets'
>> Susan
>>
>> On Sunday, February 2, 2020 at 11:21:29 AM UTC+11, Kevin Davis wrote:
>>>
>>> Has anybody played with adding upcoming sightings to there page?
>>>
>>> Adding it to pyehpem seems easy enough, just brainstorming a way to loop
>>> through to produce the next X number of sightings.
>>>
>>>
>>> --
>> 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.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/weewx-user/dd7c0dc8-8388-4308-917a-ab8f03420740%40googlegroups.com
>> 
>> .
>>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/CAHiQ_B2_1H0oVHZN-V1MwfAiXDbG5Cc8Uh4EKR3WUD2NocQkrQ%40mail.gmail.com.

Re: [weewx-user] Re: rtupdate.wunderground.com certificate error

[Brice Ruth]

Thanks for this JB - to you or anyone else following the community threads
- has anyone from WU piped in to say they're re-engaged to fix the
remaining issues? I haven't seen any posts from them recently ...

Brice Ruth, FCD
Software Engineer, Madison WI


On Sun, Feb 2, 2020 at 11:14 PM J B  wrote:

> Like some of you I'm still getting intermittent errors that stop weewx
> 3.9.2 from uploading until I restart. Someone over at
> https://apicommunity.wunderground.com/ posted this creative
> workaround that seems to be working so far. It lowers the security of
> python but it's better than sending everything over http.
>
> tmarschner
> 
>
>- 2 Posts
>-  0 Reply Likes
>
> Hi there,
>
> Here's an alternative workaround that doesn't require you to send your
> Wunderground credentials in clear text. It turns off certificate validation
> for python. I've tested this on weewx 3.9.2 on a Raspberry Pi (v. 9
> Stretch) running python 2.7.13.
>
> Modify the weewx startup script /etc/init.d/weewx.
>
> Find the start-stop-daemon line that starts up weewx (the do_start
> routine) and insert "/usr/bin/env PYTHONHTTPSVERIFY=0" into the --exec
> parameter as shown below:
>
> start-stop-daemon --start --chuid $WEEWX_USER --pidfile $PIDFILE --exec 
> /usr/bin/env PYTHONHTTPSVERIFY=0 $DAEMON -- $DAEMON_ARGS || return 2
>
> Cheers,
> Tom
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-user/98106b14-546a-481b-a49c-c8cf3ec19d7c%40googlegroups.com
> 
> .
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/CAFbExW5HWGZfx4j5JnrW6p7iw-ghqJLOMV1cN96_tv-krZSq9Q%40mail.gmail.com.

Re: [weewx-user] Re: Pyehpem and International Space Station

[Kevin Davis]

Thanks a lot Susan!  That's exactly what I was looking for.

On Sun, Feb 2, 2020 at 6:32 PM Susan Mackay  wrote:

> Also consider using SkyField instead of PyEphem as it is newer and
> supported.
> Look at https://rhodesmill.org/skyfield/earth-satellites.html and the
> example under the title 'Finding when a satellite rises and sets'
> Susan
>
> On Sunday, February 2, 2020 at 11:21:29 AM UTC+11, Kevin Davis wrote:
>>
>> Has anybody played with adding upcoming sightings to there page?
>>
>> Adding it to pyehpem seems easy enough, just brainstorming a way to loop
>> through to produce the next X number of sightings.
>>
>>
>> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-user/dd7c0dc8-8388-4308-917a-ab8f03420740%40googlegroups.com
> 
> .
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/CAHiQ_B1N8oowJBt8V8MeekkXC7roh9kwCe_UFWfPwF3SDN13fg%40mail.gmail.com.

[weewx-user] Re: rtupdate.wunderground.com certificate error

[Dave McCreath]

JB

Many thanks for pointing me in the direction of the fix, applied (at line 
61) and it appears to be working fine after a reboot. 

A quick query on Verion 4.xx of weewx for those Linux savvy bodies amongst 
us, how easy is it to install on an RPi and is an undated version of 
Wunderfixer included (that works)?

Regards

Dave


On Monday, 3 February 2020 05:18:22 UTC, J B wrote:
>
> I should mention that I'm assuming that this workaround doesn't turn off 
> certificate validation system-wide but I'm not well-versed enough in how 
> this works to know for sure. Since the daemons are managed by root I guess 
> it's possible.
>
> On Sunday, February 2, 2020 at 9:14:24 PM UTC-8, J B wrote:
>>
>> Like some of you I'm still getting intermittent errors that stop weewx 
>> 3.9.2 from uploading until I restart. Someone over at 
>> https://apicommunity.wunderground.com/ posted this creative 
>> workaround that seems to be working so far. It lowers the security of 
>> python but it's better than sending everything over http.
>>
>> tmarschner 
>> 
>>
>>- 2 Posts 
>>-  0 Reply Likes
>>
>> Hi there,
>>
>> Here's an alternative workaround that doesn't require you to send your 
>> Wunderground credentials in clear text. It turns off certificate validation 
>> for python. I've tested this on weewx 3.9.2 on a Raspberry Pi (v. 9 
>> Stretch) running python 2.7.13.
>>
>> Modify the weewx startup script /etc/init.d/weewx.
>>
>> Find the start-stop-daemon line that starts up weewx (the do_start 
>> routine) and insert "/usr/bin/env PYTHONHTTPSVERIFY=0" into the --exec 
>> parameter as shown below:
>>
>> start-stop-daemon --start --chuid $WEEWX_USER --pidfile $PIDFILE --exec 
>> /usr/bin/env PYTHONHTTPSVERIFY=0 $DAEMON -- $DAEMON_ARGS || return 2
>>
>> Cheers,
>> Tom
>>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/6c5defed-ad97-44ed-aac7-9ad27bea8058%40googlegroups.com.