Hello Gary,
Thank you so much for the thorough reply with all the tips on how to
implement rain field functionality!
Just to be clear, the interval the driver receives a loop packet is
controlled by the driver's polling interval, not by the station as the
driver is polling the station's comput
Tom,
This workaround in wxservices.py works for me.
def _setup(self, stop_ts, db_manager):
"""Initialize the rain event list"""
if self.rain_events is None:
self.rain_events = []
start_ts = stop_ts - self.retain_period
try:
# Get all rai
Hello,
I'm implementing a driver for the Columbia Weather Systems MicroServer that
supports a variety of their weather stations including the Pulsar 600. So
far I have the driver polling the station reliably under WeeWX 3.9.2 under
Python 2.7 and 4.0.0b13 under Python 3.6.
However, the issue I
Since you are writing the driver, have you considered performing the necessary
conversions so that the driver returns US or metric (i.e., one or the other,
not a mix)?
> On Mar 8, 2020, at 12:57 PM, Bill Burton wrote:
>
>
> Hello,
>
> I'm implementing a driver for the Columbia Weather Syste
Hi
Hit a problem with the SDR driver. Under WeeWX3.9.2 it work perfectly.
With WeeWX 4.0.0b14 I hit this problem.
ar 09 00:18:24 raspberrypi weewxd[8537]: weewx[8537] CRITICAL weewx.engine:
self.console = loader_function(config_dict, self)
Mar 09 00:18:24 raspberrypi weewxd[8537]:
These are my weewx.conf settings.
[SDR]
# This section is for the software-defined radio driver.
driver = user.sdr
path = /usr/local/bin
cmd = rtl_433 -f 868M -s 1024k -M utc -F json -R 78
[[sensor_map]]
outTemp = temperature.71.FOWH65BPacke
On Sunday, March 8, 2020 at 5:31:58 PM UTC-7, steeple ian wrote:
>
> Mar 09 00:18:24 raspberrypi weewxd[8537]: weewx[8537] CRITICAL __main__:
> Unable to load driver: failed to start process 'rtl_433 -f 868M -s 1024k -M
> utc -F json -R 78': [Errno 13] Permission denied
>
>
I would suspect your
All units within a packet must use one of the three weewx unit systems, US,
METRIC, or METRICWX. You can change from packet to packet, but not within a
packet.
You could emit a different packet for each observation type, but you could
miss out on some calculations. For example, to calculate dewpoi
Hello,
On Sunday, March 8, 2020 at 4:01:53 PM UTC-4, John Kline wrote:
>
> Since you are writing the driver, have you considered performing the
> necessary conversions so that the driver returns US or metric (i.e., one or
> the other, not a mix)?
>
Yes, good question. I suppose it could be done
As you concluded, it's generally best to keep the unit system as close to
the "native" unit system of the hardware as possible.
-tk
On Sun, Mar 8, 2020 at 8:32 PM Bill Burton wrote:
> Hello,
>
> On Sunday, March 8, 2020 at 4:01:53 PM UTC-4, John Kline wrote:
>>
>> Since you are writing the driv
This isn’t the general case. I find it difficult to see the harm in converting
to and fro for some cases. Are you worried about loss of precision?
> On Mar 8, 2020, at 8:45 PM, Thomas Keffer wrote:
>
>
> As you concluded, it's generally best to keep the unit system as close to the
> "nativ
Yes. A good driver makes minimal interpretations about the data it is
seeing. If possible, it should just pass it on.
On Sun, Mar 8, 2020 at 9:03 PM John Kline wrote:
> This isn’t the general case. I find it difficult to see the harm in
> converting to and fro for some cases. Are you worried a
I agree that, all things being equal, a driver should just pass it on; but this
is not that case.
There won’t be any meaningful loss of precision for the double conversions. As
such, the alternative, splitting into separate packets, is an unnecessary
complication even without factoring in that
13 matches
Mail list logo
