date:20211217

[weewx-user] Re: Help with Acurite5n1 & rtl-sdr

2021-12-17 Thread Ryan Weber

*Matthew,*

*I was able to update to the newest version of weewx-sdr. Thank you for the 
help:*

pi@nn7m-pi:~ $ wee_extension --list
Extension NameVersion   Description
sdr   0.83  Capture data from rtl_433


*I have mapped the rain_total as you advised in the /etc/weewx/weewx.conf 
file:*

[SDR]
# This section is for the software-defined radio driver.

# The driver to use
driver = user.sdr

# The time (in seconds) between LOOP packets.
loop_interval = 2.5


path = /usr/share/weewx/user/

cmd = sudo rtl_433 -M utc -F json

[[sensor_map]]
#   barometer   
#   pressure
#   altimeter
#   inTemp  temperature_in  
outTemp = temperature.0050.Acurite5n1PacketV2
#   inHumidity  humidity_in 
outHumidity = humidity.0050.Acurite5n1PacketV2
windSpeed = wind_speed.0050.Acurite5n1PacketV2
windDir = wind_dir.0050.Acurite5n1PacketV2

#   rain_total = rain_in.0050.Acurite5n1PacketV2
   rain_total = rain_total.0050.Acurite5n1PacketV2

#   dewpoint
#   windchill
#   heatindex
#   rxCheckPercent  rssi
#outTempBatteryStatus = battery_ok.0050.Acurite5n1PacketV2


[[deltas]]
#   rain = rain_total

*But still, no rain info is being reported to the web page. I'm not sure 
what to do here? When I stop weewx and watch the rtl_433 output, it reports 
Rainfall Accumilation :*

time  : 2021-12-17 16:50:18
model : Acurite-5n1  message_type: 49  id: 80
channel   : Csequence_num: 0   battery   : 1   
  wind_speed: 1.8 km/h  wind_dir_deg: 90.0Rainfall 
Accumulation: 22.08 in Integrity : CHECKSUM


*When I run sudo rtl_433 -M utc -F json I get rain_in:*

{"time" : "2021-12-18 00:53:54", "model" : "Acurite-5n1", "message_type" : 
49, "id" : 80, "channel" : "C", "sequence_num" : 1, "battery_ok" : 1, 
"wind_avg_km_h" : 6.795, "wind_dir_deg" : 90.000, "rain_in" : 22.080, "mic" 
: "CHECKSUM", "mod" : "ASK", "freq" : 433.959, "rssi" : -2.191, "snr" : 
5.146, "noise" : -7.337}
On Thursday, December 9, 2021 at 3:59:17 AM UTC-8 matthew wall wrote:

> On Thursday, December 9, 2021 at 1:52:46 AM UTC-5 weber...@gmail.com 
> wrote:
>
>> *I'm having problems following your directions for installing the latest 
>> version of weewx-sdr.*
>>
>> *4) run the driver directly to identify the packets you want to capture 
>> cd /home/weewx sudo PYTHONPATH=bin python bin/user/sdr.py --cmd="rtl_433 -M 
>> utc -F json"*
>>
>> *my path is different, as far as I understand. When I change the command 
>> to where I've found my sdr.py, I get this response: *
>>
>> sudo PYTHONPATH=bin python ./weewx-sdr/bin/user/sdr.py --cmd="rtl_433 -M 
>> utc -F json"
>> Traceback (most recent call last):
>>   File "./weewx-sdr/bin/user/sdr.py", line 91, in 
>> import weewx.drivers
>> ImportError: No module named weewx.drivers
>>
>
> the PYTHONPATH should terminate at the weewx BIN_ROOT directory (where the 
> weewx executables are located).  if you installed using rpm or deb package, 
> that would be:
>
> PYTHONPATH=/usr/share/weewx
>
> if you installed using setup.py to the /home/weewx directory, that would 
> be:
>
> PYTHONPATH=/home/weewx/bin
>
> you can use either absolute or relative path
>

-- 
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/69c35184-5121-4c58-ac99-a185309293can%40googlegroups.com.

Re: [weewx-user] HTML Production Stopped After Update

2021-12-17 Thread Tom Keffer

I would guess that your firmware is too old to recognize the more modern
LPS command, used for type LOOP 2 packets. So, it choked.

Can you check on your firmware? Stop weewxd, then run

*wee_device --info*

and post the results.



On Fri, Dec 17, 2021 at 4:38 PM Ken Waters  wrote:

> Well, well, that fixed it.  I'm perplexed but I see now that the files are
> being made and uploaded to http://satwatcher.us/wxstation/.
>
> Any idea why that might have been the problem?
>
> Thanks!
>
> Ken
>
> On Fri, Dec 17, 2021 at 5:33 PM Ken Waters  wrote:
>
>> I'm not sure.  I don't remember setting it.  I'll try 1 and restart.
>>
>> Ken
>>
>> On Fri, Dec 17, 2021 at 4:47 PM Tom Keffer  wrote:
>>
>>> Any particular reason why you are using loop_request = 3? Could you try
>>> setting it to 1?
>>>
>>> [Vantage]
>>>   ...
>>>   loop_request = 1
>>>
>>>
>>>
>>>
>>>
>>> On Fri, Dec 17, 2021 at 2:39 PM satwa...@gmail.com <
>>> satwatch...@gmail.com> wrote:
>>>
 Nope, didn't fix it.  Here's the syslog where Weewx starts up:
 Dec 17 15:35:23 WeewxWeatherServer weewx[825] INFO __main__: retrying...
 Dec 17 15:35:23 WeewxWeatherServer weewx[825] INFO __main__: Using
 configuration file /etc/weewx/weewx.conf
 Dec 17 15:35:23 WeewxWeatherServer weewx[825] INFO __main__: Debug is 1
 Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG __main__:
 Initializing engine
 Dec 17 15:35:23 WeewxWeatherServer weewx[825] INFO weewx.engine:
 Loading station type Vantage (weewx.drivers.vantage)
 Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG
 weewx.drivers.vantage: Driver version is 3.2.2
 Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG
 weewx.drivers.vantage: Option loop_request=3
 Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG
 weewx.drivers.vantage: Opened up serial port /dev/ttyS0; baud 19200;
 timeout 4.00
 Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG
 weewx.drivers.vantage: Gentle wake up of console successful
 Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG
 weewx.drivers.vantage: Hardware type is 16
 Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG
 weewx.drivers.vantage: ISS ID is 1
 Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG
 weewx.drivers.vantage: Hardware name: Vantage Pro2
 Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine:
 Loading service weewx.engine.StdTimeSynch
 Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine:
 Finished loading service weewx.engine.StdTimeSynch
 Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine:
 Loading service weewx.engine.StdConvert
 Dec 17 15:35:23 WeewxWeatherServer weewx[825] INFO weewx.engine:
 StdConvert target unit is 0x1
 Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine:
 Finished loading service weewx.engine.StdConvert
 Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine:
 Loading service weewx.engine.StdCalibrate
 Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine:
 Finished loading service weewx.engine.StdCalibrate
 Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine:
 Loading service weewx.engine.StdQC
 Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine:
 Finished loading service weewx.engine.StdQC
 Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine:
 Loading service weewx.wxservices.StdWXCalculate
 Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.manager:
 Daily summary version is 4.0
 Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine:
 Finished loading service weewx.wxservices.StdWXCalculate
 Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine:
 Loading service weewx.wxxtypes.StdWXXTypes
 Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine:
 Finished loading service weewx.wxxtypes.StdWXXTypes
 Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine:
 Loading service weewx.wxxtypes.StdPressureCooker
 Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine:
 Finished loading service weewx.wxxtypes.StdPressureCooker
 Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine:
 Loading service weewx.wxxtypes.StdRainRater
 Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine:
 Finished loading service weewx.wxxtypes.StdRainRater
 Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine:
 Loading service weewx.wxxtypes.StdDelta
 Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine:
 Finished loading service weewx.wxxtypes.StdDelta
 Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine:
 Loading service weewx.engine.StdArchive
 Dec 17 15:35:23 WeewxWeatherServer weewx[825] INFO weewx.engine:
 Archive will use data binding wx_binding
 Dec 17 15:35:23

Re: [weewx-user] HTML Production Stopped After Update

2021-12-17 Thread Ken Waters

Well, well, that fixed it.  I'm perplexed but I see now that the files are
being made and uploaded to http://satwatcher.us/wxstation/.

Any idea why that might have been the problem?

Thanks!

Ken

On Fri, Dec 17, 2021 at 5:33 PM Ken Waters  wrote:

> I'm not sure.  I don't remember setting it.  I'll try 1 and restart.
>
> Ken
>
> On Fri, Dec 17, 2021 at 4:47 PM Tom Keffer  wrote:
>
>> Any particular reason why you are using loop_request = 3? Could you try
>> setting it to 1?
>>
>> [Vantage]
>>   ...
>>   loop_request = 1
>>
>>
>>
>>
>>
>> On Fri, Dec 17, 2021 at 2:39 PM satwa...@gmail.com 
>> wrote:
>>
>>> Nope, didn't fix it.  Here's the syslog where Weewx starts up:
>>> Dec 17 15:35:23 WeewxWeatherServer weewx[825] INFO __main__: retrying...
>>> Dec 17 15:35:23 WeewxWeatherServer weewx[825] INFO __main__: Using
>>> configuration file /etc/weewx/weewx.conf
>>> Dec 17 15:35:23 WeewxWeatherServer weewx[825] INFO __main__: Debug is 1
>>> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG __main__:
>>> Initializing engine
>>> Dec 17 15:35:23 WeewxWeatherServer weewx[825] INFO weewx.engine: Loading
>>> station type Vantage (weewx.drivers.vantage)
>>> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG
>>> weewx.drivers.vantage: Driver version is 3.2.2
>>> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG
>>> weewx.drivers.vantage: Option loop_request=3
>>> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG
>>> weewx.drivers.vantage: Opened up serial port /dev/ttyS0; baud 19200;
>>> timeout 4.00
>>> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG
>>> weewx.drivers.vantage: Gentle wake up of console successful
>>> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG
>>> weewx.drivers.vantage: Hardware type is 16
>>> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG
>>> weewx.drivers.vantage: ISS ID is 1
>>> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG
>>> weewx.drivers.vantage: Hardware name: Vantage Pro2
>>> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine:
>>> Loading service weewx.engine.StdTimeSynch
>>> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine:
>>> Finished loading service weewx.engine.StdTimeSynch
>>> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine:
>>> Loading service weewx.engine.StdConvert
>>> Dec 17 15:35:23 WeewxWeatherServer weewx[825] INFO weewx.engine:
>>> StdConvert target unit is 0x1
>>> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine:
>>> Finished loading service weewx.engine.StdConvert
>>> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine:
>>> Loading service weewx.engine.StdCalibrate
>>> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine:
>>> Finished loading service weewx.engine.StdCalibrate
>>> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine:
>>> Loading service weewx.engine.StdQC
>>> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine:
>>> Finished loading service weewx.engine.StdQC
>>> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine:
>>> Loading service weewx.wxservices.StdWXCalculate
>>> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.manager: Daily
>>> summary version is 4.0
>>> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine:
>>> Finished loading service weewx.wxservices.StdWXCalculate
>>> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine:
>>> Loading service weewx.wxxtypes.StdWXXTypes
>>> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine:
>>> Finished loading service weewx.wxxtypes.StdWXXTypes
>>> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine:
>>> Loading service weewx.wxxtypes.StdPressureCooker
>>> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine:
>>> Finished loading service weewx.wxxtypes.StdPressureCooker
>>> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine:
>>> Loading service weewx.wxxtypes.StdRainRater
>>> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine:
>>> Finished loading service weewx.wxxtypes.StdRainRater
>>> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine:
>>> Loading service weewx.wxxtypes.StdDelta
>>> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine:
>>> Finished loading service weewx.wxxtypes.StdDelta
>>> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine:
>>> Loading service weewx.engine.StdArchive
>>> Dec 17 15:35:23 WeewxWeatherServer weewx[825] INFO weewx.engine: Archive
>>> will use data binding wx_binding
>>> Dec 17 15:35:23 WeewxWeatherServer weewx[825] INFO weewx.engine: Record
>>> generation will be attempted in 'hardware'
>>> Dec 17 15:35:23 WeewxWeatherServer weewx[825] INFO weewx.engine: Using
>>> archive interval of 60 seconds (specified by hardware)
>>> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine: Use
>>> LOOP data in hi/low calculations: 1
>>> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.en

Re: [weewx-user] HTML Production Stopped After Update

2021-12-17 Thread Ken Waters

I'm not sure.  I don't remember setting it.  I'll try 1 and restart.

Ken

On Fri, Dec 17, 2021 at 4:47 PM Tom Keffer  wrote:

> Any particular reason why you are using loop_request = 3? Could you try
> setting it to 1?
>
> [Vantage]
>   ...
>   loop_request = 1
>
>
>
>
>
> On Fri, Dec 17, 2021 at 2:39 PM satwa...@gmail.com 
> wrote:
>
>> Nope, didn't fix it.  Here's the syslog where Weewx starts up:
>> Dec 17 15:35:23 WeewxWeatherServer weewx[825] INFO __main__: retrying...
>> Dec 17 15:35:23 WeewxWeatherServer weewx[825] INFO __main__: Using
>> configuration file /etc/weewx/weewx.conf
>> Dec 17 15:35:23 WeewxWeatherServer weewx[825] INFO __main__: Debug is 1
>> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG __main__:
>> Initializing engine
>> Dec 17 15:35:23 WeewxWeatherServer weewx[825] INFO weewx.engine: Loading
>> station type Vantage (weewx.drivers.vantage)
>> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG
>> weewx.drivers.vantage: Driver version is 3.2.2
>> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG
>> weewx.drivers.vantage: Option loop_request=3
>> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG
>> weewx.drivers.vantage: Opened up serial port /dev/ttyS0; baud 19200;
>> timeout 4.00
>> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG
>> weewx.drivers.vantage: Gentle wake up of console successful
>> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG
>> weewx.drivers.vantage: Hardware type is 16
>> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG
>> weewx.drivers.vantage: ISS ID is 1
>> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG
>> weewx.drivers.vantage: Hardware name: Vantage Pro2
>> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine: Loading
>> service weewx.engine.StdTimeSynch
>> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine:
>> Finished loading service weewx.engine.StdTimeSynch
>> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine: Loading
>> service weewx.engine.StdConvert
>> Dec 17 15:35:23 WeewxWeatherServer weewx[825] INFO weewx.engine:
>> StdConvert target unit is 0x1
>> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine:
>> Finished loading service weewx.engine.StdConvert
>> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine: Loading
>> service weewx.engine.StdCalibrate
>> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine:
>> Finished loading service weewx.engine.StdCalibrate
>> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine: Loading
>> service weewx.engine.StdQC
>> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine:
>> Finished loading service weewx.engine.StdQC
>> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine: Loading
>> service weewx.wxservices.StdWXCalculate
>> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.manager: Daily
>> summary version is 4.0
>> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine:
>> Finished loading service weewx.wxservices.StdWXCalculate
>> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine: Loading
>> service weewx.wxxtypes.StdWXXTypes
>> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine:
>> Finished loading service weewx.wxxtypes.StdWXXTypes
>> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine: Loading
>> service weewx.wxxtypes.StdPressureCooker
>> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine:
>> Finished loading service weewx.wxxtypes.StdPressureCooker
>> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine: Loading
>> service weewx.wxxtypes.StdRainRater
>> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine:
>> Finished loading service weewx.wxxtypes.StdRainRater
>> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine: Loading
>> service weewx.wxxtypes.StdDelta
>> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine:
>> Finished loading service weewx.wxxtypes.StdDelta
>> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine: Loading
>> service weewx.engine.StdArchive
>> Dec 17 15:35:23 WeewxWeatherServer weewx[825] INFO weewx.engine: Archive
>> will use data binding wx_binding
>> Dec 17 15:35:23 WeewxWeatherServer weewx[825] INFO weewx.engine: Record
>> generation will be attempted in 'hardware'
>> Dec 17 15:35:23 WeewxWeatherServer weewx[825] INFO weewx.engine: Using
>> archive interval of 60 seconds (specified by hardware)
>> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine: Use
>> LOOP data in hi/low calculations: 1
>> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine:
>> Finished loading service weewx.engine.StdArchive
>> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine: Loading
>> service weewx.restx.StdStationRegistry
>> Dec 17 15:35:23 WeewxWeatherServer weewx[825] INFO weewx.restx:
>> StationRegistry: Station will be registered.
>> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG w

Re: [weewx-user] HTML Production Stopped After Update

2021-12-17 Thread Tom Keffer

Any particular reason why you are using loop_request = 3? Could you try
setting it to 1?

[Vantage]
  ...
  loop_request = 1





On Fri, Dec 17, 2021 at 2:39 PM satwa...@gmail.com 
wrote:

> Nope, didn't fix it.  Here's the syslog where Weewx starts up:
> Dec 17 15:35:23 WeewxWeatherServer weewx[825] INFO __main__: retrying...
> Dec 17 15:35:23 WeewxWeatherServer weewx[825] INFO __main__: Using
> configuration file /etc/weewx/weewx.conf
> Dec 17 15:35:23 WeewxWeatherServer weewx[825] INFO __main__: Debug is 1
> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG __main__: Initializing
> engine
> Dec 17 15:35:23 WeewxWeatherServer weewx[825] INFO weewx.engine: Loading
> station type Vantage (weewx.drivers.vantage)
> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.drivers.vantage:
> Driver version is 3.2.2
> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.drivers.vantage:
> Option loop_request=3
> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.drivers.vantage:
> Opened up serial port /dev/ttyS0; baud 19200; timeout 4.00
> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.drivers.vantage:
> Gentle wake up of console successful
> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.drivers.vantage:
> Hardware type is 16
> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.drivers.vantage:
> ISS ID is 1
> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.drivers.vantage:
> Hardware name: Vantage Pro2
> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine: Loading
> service weewx.engine.StdTimeSynch
> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine: Finished
> loading service weewx.engine.StdTimeSynch
> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine: Loading
> service weewx.engine.StdConvert
> Dec 17 15:35:23 WeewxWeatherServer weewx[825] INFO weewx.engine:
> StdConvert target unit is 0x1
> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine: Finished
> loading service weewx.engine.StdConvert
> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine: Loading
> service weewx.engine.StdCalibrate
> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine: Finished
> loading service weewx.engine.StdCalibrate
> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine: Loading
> service weewx.engine.StdQC
> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine: Finished
> loading service weewx.engine.StdQC
> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine: Loading
> service weewx.wxservices.StdWXCalculate
> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.manager: Daily
> summary version is 4.0
> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine: Finished
> loading service weewx.wxservices.StdWXCalculate
> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine: Loading
> service weewx.wxxtypes.StdWXXTypes
> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine: Finished
> loading service weewx.wxxtypes.StdWXXTypes
> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine: Loading
> service weewx.wxxtypes.StdPressureCooker
> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine: Finished
> loading service weewx.wxxtypes.StdPressureCooker
> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine: Loading
> service weewx.wxxtypes.StdRainRater
> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine: Finished
> loading service weewx.wxxtypes.StdRainRater
> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine: Loading
> service weewx.wxxtypes.StdDelta
> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine: Finished
> loading service weewx.wxxtypes.StdDelta
> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine: Loading
> service weewx.engine.StdArchive
> Dec 17 15:35:23 WeewxWeatherServer weewx[825] INFO weewx.engine: Archive
> will use data binding wx_binding
> Dec 17 15:35:23 WeewxWeatherServer weewx[825] INFO weewx.engine: Record
> generation will be attempted in 'hardware'
> Dec 17 15:35:23 WeewxWeatherServer weewx[825] INFO weewx.engine: Using
> archive interval of 60 seconds (specified by hardware)
> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine: Use LOOP
> data in hi/low calculations: 1
> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine: Finished
> loading service weewx.engine.StdArchive
> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine: Loading
> service weewx.restx.StdStationRegistry
> Dec 17 15:35:23 WeewxWeatherServer weewx[825] INFO weewx.restx:
> StationRegistry: Station will be registered.
> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine: Finished
> loading service weewx.restx.StdStationRegistry
> Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine: Loading
> service weewx.restx.StdWunderground
> Dec 17 15:35:23 WeewxWeatherServer weewx[825

Re: [weewx-user] HTML Production Stopped After Update

2021-12-17 Thread satwa...@gmail.com

Nope, didn't fix it.  Here's the syslog where Weewx starts up:
Dec 17 15:35:23 WeewxWeatherServer weewx[825] INFO __main__: retrying...
Dec 17 15:35:23 WeewxWeatherServer weewx[825] INFO __main__: Using 
configuration file /etc/weewx/weewx.conf
Dec 17 15:35:23 WeewxWeatherServer weewx[825] INFO __main__: Debug is 1
Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG __main__: Initializing 
engine
Dec 17 15:35:23 WeewxWeatherServer weewx[825] INFO weewx.engine: Loading 
station type Vantage (weewx.drivers.vantage)
Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.drivers.vantage: 
Driver version is 3.2.2
Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.drivers.vantage: 
Option loop_request=3
Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.drivers.vantage: 
Opened up serial port /dev/ttyS0; baud 19200; timeout 4.00
Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.drivers.vantage: 
Gentle wake up of console successful
Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.drivers.vantage: 
Hardware type is 16
Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.drivers.vantage: 
ISS ID is 1
Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.drivers.vantage: 
Hardware name: Vantage Pro2
Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine: Loading 
service weewx.engine.StdTimeSynch
Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine: Finished 
loading service weewx.engine.StdTimeSynch
Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine: Loading 
service weewx.engine.StdConvert
Dec 17 15:35:23 WeewxWeatherServer weewx[825] INFO weewx.engine: StdConvert 
target unit is 0x1
Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine: Finished 
loading service weewx.engine.StdConvert
Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine: Loading 
service weewx.engine.StdCalibrate
Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine: Finished 
loading service weewx.engine.StdCalibrate
Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine: Loading 
service weewx.engine.StdQC
Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine: Finished 
loading service weewx.engine.StdQC
Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine: Loading 
service weewx.wxservices.StdWXCalculate
Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.manager: Daily 
summary version is 4.0
Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine: Finished 
loading service weewx.wxservices.StdWXCalculate
Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine: Loading 
service weewx.wxxtypes.StdWXXTypes
Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine: Finished 
loading service weewx.wxxtypes.StdWXXTypes
Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine: Loading 
service weewx.wxxtypes.StdPressureCooker
Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine: Finished 
loading service weewx.wxxtypes.StdPressureCooker
Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine: Loading 
service weewx.wxxtypes.StdRainRater
Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine: Finished 
loading service weewx.wxxtypes.StdRainRater
Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine: Loading 
service weewx.wxxtypes.StdDelta
Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine: Finished 
loading service weewx.wxxtypes.StdDelta
Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine: Loading 
service weewx.engine.StdArchive
Dec 17 15:35:23 WeewxWeatherServer weewx[825] INFO weewx.engine: Archive 
will use data binding wx_binding
Dec 17 15:35:23 WeewxWeatherServer weewx[825] INFO weewx.engine: Record 
generation will be attempted in 'hardware'
Dec 17 15:35:23 WeewxWeatherServer weewx[825] INFO weewx.engine: Using 
archive interval of 60 seconds (specified by hardware)
Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine: Use LOOP 
data in hi/low calculations: 1
Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine: Finished 
loading service weewx.engine.StdArchive
Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine: Loading 
service weewx.restx.StdStationRegistry
Dec 17 15:35:23 WeewxWeatherServer weewx[825] INFO weewx.restx: 
StationRegistry: Station will be registered.
Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine: Finished 
loading service weewx.restx.StdStationRegistry
Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine: Loading 
service weewx.restx.StdWunderground
Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.restx: WU 
essentials: {}
Dec 17 15:35:23 WeewxWeatherServer weewx[825] INFO weewx.restx: 
Wunderground-PWS: Data for station KAZMESA460 will be posted
Dec 17 15:35:23 WeewxWeatherServer weewx[825] DEBUG weewx.engine: Finished 
loading service weewx.restx.StdWunderground
Dec 17 15:35:23 WeewxWeatherServ

Re: [weewx-user] logrotate permissions problem

2021-12-17 Thread Tom Keffer

I think this was fixed in V3.9. What version did you upgrade from?

On Fri, Dec 17, 2021 at 9:33 AM mbat...@gmail.com 
wrote:

> After upgrading my devuan distro to v4, logrotate is now v3.18.0-2, and
> complains that
> /home/weewx/util/logrotate.d/weewx has group write permissions.
>
>  ls -l shows:
>   -rw-rw-r-- 1 root root 810 Nov  1 17:26
> /home/weewx/util/logrotate.d/weewx
>
> "chmod 644" fixes the problem.
>
> Thanks!
> P
>
>
>
> --
> 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/5e1fb815-40f9-48aa-9543-2828e387bb44n%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/CAPq0zEDLcH77evSt%3DuVbbGeg33N%3DKiqSyacB%2BPEE-Ric_L9ncg%40mail.gmail.com.

Re: [weewx-user] WeeWX is second in Google's search list

2021-12-17 Thread Tom Keffer

It's 11th here when done from an *in cognito* window, but #1 for the search
term ''open source weather software", which is the one I really care about.

On Fri, Dec 17, 2021 at 11:14 AM Karen K  wrote:

> Recently I recognized: for the word "Wettersoftware" (which is "weather
> software" in English) WeeWX is the second item in Google's result list. I
> am glad about that.
>
> --
> 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/26c47c7c-25dd-4a68-b8b0-f6c8ba502487n%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/CAPq0zEDJ-xGUFmzX9aVZb7B9LK%2B%2B8DoNfDvXLEu6DzKOPavxVA%40mail.gmail.com.

[weewx-user] logrotate permissions problem

2021-12-17 Thread mbat...@gmail.com

After upgrading my devuan distro to v4, logrotate is now v3.18.0-2, and 
complains that 
/home/weewx/util/logrotate.d/weewx has group write permissions.

 ls -l shows:
  -rw-rw-r-- 1 root root 810 Nov  1 17:26 /home/weewx/util/logrotate.d/weewx

"chmod 644" fixes the problem.

Thanks!
P
   


-- 
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/5e1fb815-40f9-48aa-9543-2828e387bb44n%40googlegroups.com.

Re: [weewx-user] Re: Determine source of metric which fails QC

2021-12-17 Thread Joel Baranick

I think I have it sorted out now with the changes in this 
commit: 
https://github.com/kadaan/weewx-purple/commit/db52c50c9ee4ec92b0357c20ebb8f5fc65f34875

Thanks!!!

On Friday, December 17, 2021 at 8:18:10 AM UTC-8 Joel Baranick wrote:

> Hey John.  Nope, it does not.  I included it in a fork and it worked for a 
> long time.  The weewx server died and had to be rebuilt from scratch.  
> After that, it is no longer working.
>
> On Friday, December 17, 2021 at 5:51:28 AM UTC-8 jo...@johnkline.com 
> wrote:
>
>> Hi Joel,
>>
>> The purple extension does NOT insert pressure into the loop packet.  You 
>> can see that for yourself if you look at new_loop_packet in the plugin. 
>>  Are you modifying the extension to add it?
>>
>> On Dec 17, 2021, at 2:49 AM, gjr80  wrote:
>>
>> There are many ways to handle unit conversion, some more sophisticated 
>> than others. Here are a couple of fairly basic approaches 
>> https://github.com/matthewwall/weewx-maxbotix/blob/master/bin/user/maxbotix.py#L142
>>  
>> and 
>> https://gitlab.com/wjcarpenter/bme280wx/-/blob/master/bin/user/bme280wx.py#L82
>>
>>
>> Gary
>>
>> On Friday, 17 December 2021 at 20:30:03 UTC+10 jbar...@gmail.com wrote:
>>
>>> Thanks!  You mind pointing me at a reference implementation of a service 
>>> class that does this all correctly?  I'm likely able to get it working on 
>>> my own if I see how it is to be done.
>>>
>>> On Friday, December 17, 2021 at 2:11:13 AM UTC-8 gjr80 wrote:
>>>
 Any values have to be analysed in context of the unit system of the 
 packet into which they are inserted. The unit system of packets emitted by 
 the sdr driver when reading acurite devices is either US customary or 
 metric depending on the sensors being read. As far as I can tell the 
 purple 
 air extension you are using does not perform any check of the unit system 
 of the loop packet (loop packet field usUnits) to which pressure is added, 
 but I could be wrong. Normally you would find something in the method of 
 the service class that is bound to the NEW_LOOP_PACKET event (in this case 
 Purple.new_loop_packet()) that checks usUnits and converts pressures, 
 temperature, speeds etc to match the packet units. Or if not in that 
 method 
 in the code called by that method. 

 I’m not about to try to debug someone else’s extension, especially one 
 as complex as this. John, the author, frequents the forums so give it a 
 day 
 or so and see if he comments. Otherwise I suggest you raise an issue in 
 his 
 repo.

 Gary

 On Friday, 17 December 2021 at 19:16:38 UTC+10 jbar...@gmail.com wrote:

> Well,  I have basically two sources: acurite sensors via sdr and the 
> purple api via a purple api plugin.  The acurite sensors don't expose 
> pressure and the rtl433 logs never indicate that a pressure is detected 
> in 
> the acurite information.  
>
> The purple api does expose pressure and it comes in as millibars: 
> 200 success { "api_version" : "V1.0.10-0.0.12", "time_stamp" : 
> 1639725648, "data_time_stamp" : 1639725596, "sensor" : { 
> "sensor_index" : 81961, "pressure" : 1018.5 } }
>
> That said there are log lines that indicate the pressure was read from 
> purple and included as inHg in the result.
>
> weewx[1] DEBUG user.purple: Inserted packet[pressure]: 30.096963 into 
> packet.
>
> I've run the purple plugin locally and verified that is is converted 
> to inHg.  The conversion happens here: 
> https://github.com/chaunceygardiner/weewx-purple/blob/e7f214539b63281d74af9e90810045dd8d1b7b80/bin/user/purple.py#L266.
>   
> Is this the proper way of doing it?  If not, can you point me to an 
> example 
> of doing it properly in a plugin?
>
>
>
>
>
> On Friday, December 17, 2021 at 12:39:29 AM UTC-8 gjr80 wrote:
>
>> What driver are you using and what is the source of the pressure 
>> value? This sounds very much like a service is being used to add one or 
>> more of the three pressure fields (altimeter, barometer or pressure) to 
>> packets/records from the driver and the unit system of the packet/record 
>> is 
>> not being checked and followed. This can result in fields being added to 
>> packets/records in the wrong units which eventually results in a double 
>> unit conversion.
>>
>> The answer will almost certainly be related to the source of one of 
>> the three pressure fields.
>>
>> Gary
>> On Friday, 17 December 2021 at 17:56:10 UTC+10 jbar...@gmail.com 
>> wrote:
>>
>>> BTW, running on Develop
>>>
>>> On Thursday, December 16, 2021 at 11:54:46 PM UTC-8 Joel Baranick 
>>> wrote:
>>>
 What is the best way to determine the source of a metric which 
 fails QC?  The failure in this case is the "pressure" metrics which is 
 exp

Re: [weewx-user] Re: Determine source of metric which fails QC

2021-12-17 Thread Joel Baranick

Hey John.  Nope, it does not.  I included it in a fork and it worked for a 
long time.  The weewx server died and had to be rebuilt from scratch.  
After that, it is no longer working.

On Friday, December 17, 2021 at 5:51:28 AM UTC-8 jo...@johnkline.com wrote:

> Hi Joel,
>
> The purple extension does NOT insert pressure into the loop packet.  You 
> can see that for yourself if you look at new_loop_packet in the plugin. 
>  Are you modifying the extension to add it?
>
> On Dec 17, 2021, at 2:49 AM, gjr80  wrote:
>
> There are many ways to handle unit conversion, some more sophisticated 
> than others. Here are a couple of fairly basic approaches 
> https://github.com/matthewwall/weewx-maxbotix/blob/master/bin/user/maxbotix.py#L142
>  
> and 
> https://gitlab.com/wjcarpenter/bme280wx/-/blob/master/bin/user/bme280wx.py#L82
>
>
> Gary
>
> On Friday, 17 December 2021 at 20:30:03 UTC+10 jbar...@gmail.com wrote:
>
>> Thanks!  You mind pointing me at a reference implementation of a service 
>> class that does this all correctly?  I'm likely able to get it working on 
>> my own if I see how it is to be done.
>>
>> On Friday, December 17, 2021 at 2:11:13 AM UTC-8 gjr80 wrote:
>>
>>> Any values have to be analysed in context of the unit system of the 
>>> packet into which they are inserted. The unit system of packets emitted by 
>>> the sdr driver when reading acurite devices is either US customary or 
>>> metric depending on the sensors being read. As far as I can tell the purple 
>>> air extension you are using does not perform any check of the unit system 
>>> of the loop packet (loop packet field usUnits) to which pressure is added, 
>>> but I could be wrong. Normally you would find something in the method of 
>>> the service class that is bound to the NEW_LOOP_PACKET event (in this case 
>>> Purple.new_loop_packet()) that checks usUnits and converts pressures, 
>>> temperature, speeds etc to match the packet units. Or if not in that method 
>>> in the code called by that method. 
>>>
>>> I’m not about to try to debug someone else’s extension, especially one 
>>> as complex as this. John, the author, frequents the forums so give it a day 
>>> or so and see if he comments. Otherwise I suggest you raise an issue in his 
>>> repo.
>>>
>>> Gary
>>>
>>> On Friday, 17 December 2021 at 19:16:38 UTC+10 jbar...@gmail.com wrote:
>>>
 Well,  I have basically two sources: acurite sensors via sdr and the 
 purple api via a purple api plugin.  The acurite sensors don't expose 
 pressure and the rtl433 logs never indicate that a pressure is detected in 
 the acurite information.  

 The purple api does expose pressure and it comes in as millibars: 
 200 success { "api_version" : "V1.0.10-0.0.12", "time_stamp" : 
 1639725648, "data_time_stamp" : 1639725596, "sensor" : { "sensor_index" 
 : 81961, "pressure" : 1018.5 } }

 That said there are log lines that indicate the pressure was read from 
 purple and included as inHg in the result.

 weewx[1] DEBUG user.purple: Inserted packet[pressure]: 30.096963 into 
 packet.

 I've run the purple plugin locally and verified that is is converted to 
 inHg.  The conversion happens here: 
 https://github.com/chaunceygardiner/weewx-purple/blob/e7f214539b63281d74af9e90810045dd8d1b7b80/bin/user/purple.py#L266.
   
 Is this the proper way of doing it?  If not, can you point me to an 
 example 
 of doing it properly in a plugin?





 On Friday, December 17, 2021 at 12:39:29 AM UTC-8 gjr80 wrote:

> What driver are you using and what is the source of the pressure 
> value? This sounds very much like a service is being used to add one or 
> more of the three pressure fields (altimeter, barometer or pressure) to 
> packets/records from the driver and the unit system of the packet/record 
> is 
> not being checked and followed. This can result in fields being added to 
> packets/records in the wrong units which eventually results in a double 
> unit conversion.
>
> The answer will almost certainly be related to the source of one of 
> the three pressure fields.
>
> Gary
> On Friday, 17 December 2021 at 17:56:10 UTC+10 jbar...@gmail.com 
> wrote:
>
>> BTW, running on Develop
>>
>> On Thursday, December 16, 2021 at 11:54:46 PM UTC-8 Joel Baranick 
>> wrote:
>>
>>> What is the best way to determine the source of a metric which fails 
>>> QC?  The failure in this case is the "pressure" metrics which is 
>>> expected 
>>> to be in inHq.  The QC error is: `LOOP value 'pressure' 
>>> 0.8885885448234093 
>>> outside limits (24.0, 34.5)`.  It seems like the pressure is converted 
>>> to 
>>> inHq correctly: `Inserted packet[pressure]: 30.091057 into packet.`. 
>>> But, 
>>> it seems like the  30.091057 is being be fed back into the conversion 
>>> function.
>>

Re: [weewx-user] Re: Determine source of metric which fails QC

2021-12-17 Thread 'John Kline' via weewx-user

Hi Joel,

The purple extension does NOT insert pressure into the loop packet.  You can 
see that for yourself if you look at new_loop_packet in the plugin.  Are you 
modifying the extension to add it?

> On Dec 17, 2021, at 2:49 AM, gjr80  wrote:
> 
> There are many ways to handle unit conversion, some more sophisticated than 
> others. Here are a couple of fairly basic approaches 
> https://github.com/matthewwall/weewx-maxbotix/blob/master/bin/user/maxbotix.py#L142
>  and 
> https://gitlab.com/wjcarpenter/bme280wx/-/blob/master/bin/user/bme280wx.py#L82
> 
> Gary
> 
>> On Friday, 17 December 2021 at 20:30:03 UTC+10 jbar...@gmail.com wrote:
>> Thanks!  You mind pointing me at a reference implementation of a service 
>> class that does this all correctly?  I'm likely able to get it working on my 
>> own if I see how it is to be done.
>> 
>>> On Friday, December 17, 2021 at 2:11:13 AM UTC-8 gjr80 wrote:
>>> Any values have to be analysed in context of the unit system of the packet 
>>> into which they are inserted. The unit system of packets emitted by the sdr 
>>> driver when reading acurite devices is either US customary or metric 
>>> depending on the sensors being read. As far as I can tell the purple air 
>>> extension you are using does not perform any check of the unit system of 
>>> the loop packet (loop packet field usUnits) to which pressure is added, but 
>>> I could be wrong. Normally you would find something in the method of the 
>>> service class that is bound to the NEW_LOOP_PACKET event (in this case 
>>> Purple.new_loop_packet()) that checks usUnits and converts pressures, 
>>> temperature, speeds etc to match the packet units. Or if not in that method 
>>> in the code called by that method. 
>>> 
>>> I’m not about to try to debug someone else’s extension, especially one as 
>>> complex as this. John, the author, frequents the forums so give it a day or 
>>> so and see if he comments. Otherwise I suggest you raise an issue in his 
>>> repo.
>>> 
>>> Gary
>>> 
 On Friday, 17 December 2021 at 19:16:38 UTC+10 jbar...@gmail.com wrote:
 Well,  I have basically two sources: acurite sensors via sdr and the 
 purple api via a purple api plugin.  The acurite sensors don't expose 
 pressure and the rtl433 logs never indicate that a pressure is detected in 
 the acurite information.  
 
 The purple api does expose pressure and it comes in as millibars: 
 200 success
 {
   "api_version" : "V1.0.10-0.0.12",
   "time_stamp" : 1639725648,
   "data_time_stamp" : 1639725596,
   "sensor" : {
 "sensor_index" : 81961,
 "pressure" : 1018.5
   }
 }
 
 That said there are log lines that indicate the pressure was read from 
 purple and included as inHg in the result.
 
 weewx[1] DEBUG user.purple: Inserted packet[pressure]: 30.096963 into 
 packet.
 
 I've run the purple plugin locally and verified that is is converted to 
 inHg.  The conversion happens here: 
 https://github.com/chaunceygardiner/weewx-purple/blob/e7f214539b63281d74af9e90810045dd8d1b7b80/bin/user/purple.py#L266.
   Is this the proper way of doing it?  If not, can you point me to an 
 example of doing it properly in a plugin?
 
 
 
 
 
> On Friday, December 17, 2021 at 12:39:29 AM UTC-8 gjr80 wrote:
> What driver are you using and what is the source of the pressure value? 
> This sounds very much like a service is being used to add one or more of 
> the three pressure fields (altimeter, barometer or pressure) to 
> packets/records from the driver and the unit system of the packet/record 
> is not being checked and followed. This can result in fields being added 
> to packets/records in the wrong units which eventually results in a 
> double unit conversion.
> 
> The answer will almost certainly be related to the source of one of the 
> three pressure fields.
> 
> Gary
>> On Friday, 17 December 2021 at 17:56:10 UTC+10 jbar...@gmail.com wrote:
>> BTW, running on Develop
>> 
>>> On Thursday, December 16, 2021 at 11:54:46 PM UTC-8 Joel Baranick wrote:
>>> What is the best way to determine the source of a metric which fails 
>>> QC?  The failure in this case is the "pressure" metrics which is 
>>> expected to be in inHq.  The QC error is: `LOOP value 'pressure' 
>>> 0.8885885448234093 outside limits (24.0, 34.5)`.  It seems like the 
>>> pressure is converted to inHq correctly: `Inserted packet[pressure]: 
>>> 30.091057 into packet.`. But, it seems like the  30.091057 is being be 
>>> fed back into the conversion function.
> 
> -- 
> 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.goo

Re: [weewx-user] HTML Production Stopped After Update

2021-12-17 Thread Tom Keffer

Yes, I had forgotten about that. Could definitely be the issue. The daemon
modemmanager can compete for the serial port.

First check to see if you're running it. I think this will also tell you
which port it's monitoring.

*ps aux|grep modem*

Then to remove:

*sudo apt purge modemmanager*

On Thu, Dec 16, 2021 at 6:43 PM vince  wrote:

> Please don't blindly reinstall weewx thinking it can fix what looks like
> an os or physical connectivity issue.
>
> Your original post saying "*Yesterday, I saw one of those routine update
> messages on my desktop and elected to accept them*" got me thinking...
>
> Can you describe your setup a bit more ?
>
>- What kind of hardware are you on ?Something with a DB9 has to be
>pretty ancient these days.
>- Did you see a bunch of updates available and just say 'go ahead
>update everything' ?
>- Are you sure you're on 18.04 ?  What does your /etc/os-release say ?
>- Did you add anything else to your ubuntu before it stopped working ?
>- Did you take a reboot after your (big?) update/upgrade ?
>- Did you move the box or Vantage console ?   Might something be loose
>?  DB9 connectors are easy to get part-way connected.
>
> Tom - wasn't there some package a long time ago in ubuntu that you found
> affected whether serial ports worked ?  Some package that blocked the
> /dev(ice) from functioning ?  It's been a long time but I seem to remember
> there was some package that messed things up.
>
> --
> 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/3fd72451-19fc-498e-a07f-fc86310aa2b7n%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/CAPq0zEAM2zbnJ6mPdntLwpwfpwHxF7oOv1-oNxZip7V4%3D1yv%2Bw%40mail.gmail.com.

[weewx-user] Re: Determine source of metric which fails QC

2021-12-17 Thread gjr80

There are many ways to handle unit conversion, some more sophisticated than 
others. Here are a couple of fairly basic 
approaches 
https://github.com/matthewwall/weewx-maxbotix/blob/master/bin/user/maxbotix.py#L142
 
and 
https://gitlab.com/wjcarpenter/bme280wx/-/blob/master/bin/user/bme280wx.py#L82

Gary

On Friday, 17 December 2021 at 20:30:03 UTC+10 jbar...@gmail.com wrote:

> Thanks!  You mind pointing me at a reference implementation of a service 
> class that does this all correctly?  I'm likely able to get it working on 
> my own if I see how it is to be done.
>
> On Friday, December 17, 2021 at 2:11:13 AM UTC-8 gjr80 wrote:
>
>> Any values have to be analysed in context of the unit system of the 
>> packet into which they are inserted. The unit system of packets emitted by 
>> the sdr driver when reading acurite devices is either US customary or 
>> metric depending on the sensors being read. As far as I can tell the purple 
>> air extension you are using does not perform any check of the unit system 
>> of the loop packet (loop packet field usUnits) to which pressure is added, 
>> but I could be wrong. Normally you would find something in the method of 
>> the service class that is bound to the NEW_LOOP_PACKET event (in this case 
>> Purple.new_loop_packet()) that checks usUnits and converts pressures, 
>> temperature, speeds etc to match the packet units. Or if not in that method 
>> in the code called by that method. 
>>
>> I’m not about to try to debug someone else’s extension, especially one as 
>> complex as this. John, the author, frequents the forums so give it a day or 
>> so and see if he comments. Otherwise I suggest you raise an issue in his 
>> repo.
>>
>> Gary
>>
>> On Friday, 17 December 2021 at 19:16:38 UTC+10 jbar...@gmail.com wrote:
>>
>>> Well,  I have basically two sources: acurite sensors via sdr and the 
>>> purple api via a purple api plugin.  The acurite sensors don't expose 
>>> pressure and the rtl433 logs never indicate that a pressure is detected in 
>>> the acurite information.  
>>>
>>> The purple api does expose pressure and it comes in as millibars: 
>>> 200 success { "api_version" : "V1.0.10-0.0.12", "time_stamp" : 
>>> 1639725648, "data_time_stamp" : 1639725596, "sensor" : { "sensor_index" 
>>> : 81961, "pressure" : 1018.5 } }
>>>
>>> That said there are log lines that indicate the pressure was read from 
>>> purple and included as inHg in the result.
>>>
>>> weewx[1] DEBUG user.purple: Inserted packet[pressure]: 30.096963 into 
>>> packet.
>>>
>>> I've run the purple plugin locally and verified that is is converted to 
>>> inHg.  The conversion happens here: 
>>> https://github.com/chaunceygardiner/weewx-purple/blob/e7f214539b63281d74af9e90810045dd8d1b7b80/bin/user/purple.py#L266.
>>>   
>>> Is this the proper way of doing it?  If not, can you point me to an example 
>>> of doing it properly in a plugin?
>>>
>>>
>>>
>>>
>>>
>>> On Friday, December 17, 2021 at 12:39:29 AM UTC-8 gjr80 wrote:
>>>
 What driver are you using and what is the source of the pressure value? 
 This sounds very much like a service is being used to add one or more of 
 the three pressure fields (altimeter, barometer or pressure) to 
 packets/records from the driver and the unit system of the packet/record 
 is 
 not being checked and followed. This can result in fields being added to 
 packets/records in the wrong units which eventually results in a double 
 unit conversion.

 The answer will almost certainly be related to the source of one of the 
 three pressure fields.

 Gary
 On Friday, 17 December 2021 at 17:56:10 UTC+10 jbar...@gmail.com wrote:

> BTW, running on Develop
>
> On Thursday, December 16, 2021 at 11:54:46 PM UTC-8 Joel Baranick 
> wrote:
>
>> What is the best way to determine the source of a metric which fails 
>> QC?  The failure in this case is the "pressure" metrics which is 
>> expected 
>> to be in inHq.  The QC error is: `LOOP value 'pressure' 
>> 0.8885885448234093 
>> outside limits (24.0, 34.5)`.  It seems like the pressure is converted 
>> to 
>> inHq correctly: `Inserted packet[pressure]: 30.091057 into packet.`. 
>> But, 
>> it seems like the  30.091057 is being be fed back into the conversion 
>> function.
>
>

-- 
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/a8eb1f58-0352-46c4-8b66-905710ea5c54n%40googlegroups.com.

[weewx-user] Re: Determine source of metric which fails QC

2021-12-17 Thread Joel Baranick

Thanks!  You mind pointing me at a reference implementation of a service 
class that does this all correctly?  I'm likely able to get it working on 
my own if I see how it is to be done.

On Friday, December 17, 2021 at 2:11:13 AM UTC-8 gjr80 wrote:

> Any values have to be analysed in context of the unit system of the packet 
> into which they are inserted. The unit system of packets emitted by the sdr 
> driver when reading acurite devices is either US customary or metric 
> depending on the sensors being read. As far as I can tell the purple air 
> extension you are using does not perform any check of the unit system of 
> the loop packet (loop packet field usUnits) to which pressure is added, but 
> I could be wrong. Normally you would find something in the method of the 
> service class that is bound to the NEW_LOOP_PACKET event (in this case 
> Purple.new_loop_packet()) that checks usUnits and converts pressures, 
> temperature, speeds etc to match the packet units. Or if not in that method 
> in the code called by that method. 
>
> I’m not about to try to debug someone else’s extension, especially one as 
> complex as this. John, the author, frequents the forums so give it a day or 
> so and see if he comments. Otherwise I suggest you raise an issue in his 
> repo.
>
> Gary
>
> On Friday, 17 December 2021 at 19:16:38 UTC+10 jbar...@gmail.com wrote:
>
>> Well,  I have basically two sources: acurite sensors via sdr and the 
>> purple api via a purple api plugin.  The acurite sensors don't expose 
>> pressure and the rtl433 logs never indicate that a pressure is detected in 
>> the acurite information.  
>>
>> The purple api does expose pressure and it comes in as millibars: 
>> 200 success { "api_version" : "V1.0.10-0.0.12", "time_stamp" : 1639725648
>> , "data_time_stamp" : 1639725596, "sensor" : { "sensor_index" : 81961, 
>> "pressure" : 1018.5 } }
>>
>> That said there are log lines that indicate the pressure was read from 
>> purple and included as inHg in the result.
>>
>> weewx[1] DEBUG user.purple: Inserted packet[pressure]: 30.096963 into 
>> packet.
>>
>> I've run the purple plugin locally and verified that is is converted to 
>> inHg.  The conversion happens here: 
>> https://github.com/chaunceygardiner/weewx-purple/blob/e7f214539b63281d74af9e90810045dd8d1b7b80/bin/user/purple.py#L266.
>>   
>> Is this the proper way of doing it?  If not, can you point me to an example 
>> of doing it properly in a plugin?
>>
>>
>>
>>
>>
>> On Friday, December 17, 2021 at 12:39:29 AM UTC-8 gjr80 wrote:
>>
>>> What driver are you using and what is the source of the pressure value? 
>>> This sounds very much like a service is being used to add one or more of 
>>> the three pressure fields (altimeter, barometer or pressure) to 
>>> packets/records from the driver and the unit system of the packet/record is 
>>> not being checked and followed. This can result in fields being added to 
>>> packets/records in the wrong units which eventually results in a double 
>>> unit conversion.
>>>
>>> The answer will almost certainly be related to the source of one of the 
>>> three pressure fields.
>>>
>>> Gary
>>> On Friday, 17 December 2021 at 17:56:10 UTC+10 jbar...@gmail.com wrote:
>>>
 BTW, running on Develop

 On Thursday, December 16, 2021 at 11:54:46 PM UTC-8 Joel Baranick wrote:

> What is the best way to determine the source of a metric which fails 
> QC?  The failure in this case is the "pressure" metrics which is expected 
> to be in inHq.  The QC error is: `LOOP value 'pressure' 
> 0.8885885448234093 
> outside limits (24.0, 34.5)`.  It seems like the pressure is converted to 
> inHq correctly: `Inserted packet[pressure]: 30.091057 into packet.`. But, 
> it seems like the  30.091057 is being be fed back into the conversion 
> function.



-- 
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/8c8e3753-21fd-4f23-8674-ccbe96bf8506n%40googlegroups.com.

[weewx-user] Re: Determine source of metric which fails QC

2021-12-17 Thread gjr80

Any values have to be analysed in context of the unit system of the packet 
into which they are inserted. The unit system of packets emitted by the sdr 
driver when reading acurite devices is either US customary or metric 
depending on the sensors being read. As far as I can tell the purple air 
extension you are using does not perform any check of the unit system of 
the loop packet (loop packet field usUnits) to which pressure is added, but 
I could be wrong. Normally you would find something in the method of the 
service class that is bound to the NEW_LOOP_PACKET event (in this case 
Purple.new_loop_packet()) that checks usUnits and converts pressures, 
temperature, speeds etc to match the packet units. Or if not in that method 
in the code called by that method. 

I’m not about to try to debug someone else’s extension, especially one as 
complex as this. John, the author, frequents the forums so give it a day or 
so and see if he comments. Otherwise I suggest you raise an issue in his 
repo.

Gary

On Friday, 17 December 2021 at 19:16:38 UTC+10 jbar...@gmail.com wrote:

> Well,  I have basically two sources: acurite sensors via sdr and the 
> purple api via a purple api plugin.  The acurite sensors don't expose 
> pressure and the rtl433 logs never indicate that a pressure is detected in 
> the acurite information.  
>
> The purple api does expose pressure and it comes in as millibars: 
> 200 success { "api_version" : "V1.0.10-0.0.12", "time_stamp" : 1639725648, 
> "data_time_stamp" : 1639725596, "sensor" : { "sensor_index" : 81961, 
> "pressure" : 1018.5 } }
>
> That said there are log lines that indicate the pressure was read from 
> purple and included as inHg in the result.
>
> weewx[1] DEBUG user.purple: Inserted packet[pressure]: 30.096963 into 
> packet.
>
> I've run the purple plugin locally and verified that is is converted to 
> inHg.  The conversion happens here: 
> https://github.com/chaunceygardiner/weewx-purple/blob/e7f214539b63281d74af9e90810045dd8d1b7b80/bin/user/purple.py#L266.
>   
> Is this the proper way of doing it?  If not, can you point me to an example 
> of doing it properly in a plugin?
>
>
>
>
>
> On Friday, December 17, 2021 at 12:39:29 AM UTC-8 gjr80 wrote:
>
>> What driver are you using and what is the source of the pressure value? 
>> This sounds very much like a service is being used to add one or more of 
>> the three pressure fields (altimeter, barometer or pressure) to 
>> packets/records from the driver and the unit system of the packet/record is 
>> not being checked and followed. This can result in fields being added to 
>> packets/records in the wrong units which eventually results in a double 
>> unit conversion.
>>
>> The answer will almost certainly be related to the source of one of the 
>> three pressure fields.
>>
>> Gary
>> On Friday, 17 December 2021 at 17:56:10 UTC+10 jbar...@gmail.com wrote:
>>
>>> BTW, running on Develop
>>>
>>> On Thursday, December 16, 2021 at 11:54:46 PM UTC-8 Joel Baranick wrote:
>>>
 What is the best way to determine the source of a metric which fails 
 QC?  The failure in this case is the "pressure" metrics which is expected 
 to be in inHq.  The QC error is: `LOOP value 'pressure' 0.8885885448234093 
 outside limits (24.0, 34.5)`.  It seems like the pressure is converted to 
 inHq correctly: `Inserted packet[pressure]: 30.091057 into packet.`. But, 
 it seems like the  30.091057 is being be fed back into the conversion 
 function.
>>>
>>>

-- 
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/22c3e4f6-59d8-4d8a-a17c-c1866ec6d67fn%40googlegroups.com.

[weewx-user] Re: Determine source of metric which fails QC

2021-12-17 Thread Joel Baranick

Well,  I have basically two sources: acurite sensors via sdr and the purple 
api via a purple api plugin.  The acurite sensors don't expose pressure and 
the rtl433 logs never indicate that a pressure is detected in the acurite 
information.  

The purple api does expose pressure and it comes in as millibars: 
200 success { "api_version" : "V1.0.10-0.0.12", "time_stamp" : 1639725648, 
"data_time_stamp" : 1639725596, "sensor" : { "sensor_index" : 81961, 
"pressure" : 1018.5 } }

That said there are log lines that indicate the pressure was read from 
purple and included as inHg in the result.

weewx[1] DEBUG user.purple: Inserted packet[pressure]: 30.096963 into 
packet.

I've run the purple plugin locally and verified that is is converted to 
inHg.  The conversion happens 
here: 
https://github.com/chaunceygardiner/weewx-purple/blob/e7f214539b63281d74af9e90810045dd8d1b7b80/bin/user/purple.py#L266.

Is this the proper way of doing it?  If not, can you point me to an example 
of doing it properly in a plugin?

On Friday, December 17, 2021 at 12:39:29 AM UTC-8 gjr80 wrote:

> What driver are you using and what is the source of the pressure value? 
> This sounds very much like a service is being used to add one or more of 
> the three pressure fields (altimeter, barometer or pressure) to 
> packets/records from the driver and the unit system of the packet/record is 
> not being checked and followed. This can result in fields being added to 
> packets/records in the wrong units which eventually results in a double 
> unit conversion.
>
> The answer will almost certainly be related to the source of one of the 
> three pressure fields.
>
> Gary
> On Friday, 17 December 2021 at 17:56:10 UTC+10 jbar...@gmail.com wrote:
>
>> BTW, running on Develop
>>
>> On Thursday, December 16, 2021 at 11:54:46 PM UTC-8 Joel Baranick wrote:
>>
>>> What is the best way to determine the source of a metric which fails 
>>> QC?  The failure in this case is the "pressure" metrics which is expected 
>>> to be in inHq.  The QC error is: `LOOP value 'pressure' 0.8885885448234093 
>>> outside limits (24.0, 34.5)`.  It seems like the pressure is converted to 
>>> inHq correctly: `Inserted packet[pressure]: 30.091057 into packet.`. But, 
>>> it seems like the  30.091057 is being be fed back into the conversion 
>>> function.
>>
>>

-- 
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/10681fb9-2373-463a-8449-fed0e9f98793n%40googlegroups.com.

[weewx-user] Re: Determine source of metric which fails QC

2021-12-17 Thread gjr80

What driver are you using and what is the source of the pressure value? 
This sounds very much like a service is being used to add one or more of 
the three pressure fields (altimeter, barometer or pressure) to 
packets/records from the driver and the unit system of the packet/record is 
not being checked and followed. This can result in fields being added to 
packets/records in the wrong units which eventually results in a double 
unit conversion.

The answer will almost certainly be related to the source of one of the 
three pressure fields.

Gary
On Friday, 17 December 2021 at 17:56:10 UTC+10 jbar...@gmail.com wrote:

> BTW, running on Develop
>
> On Thursday, December 16, 2021 at 11:54:46 PM UTC-8 Joel Baranick wrote:
>
>> What is the best way to determine the source of a metric which fails QC?  
>> The failure in this case is the "pressure" metrics which is expected to be 
>> in inHq.  The QC error is: `LOOP value 'pressure' 0.8885885448234093 
>> outside limits (24.0, 34.5)`.  It seems like the pressure is converted to 
>> inHq correctly: `Inserted packet[pressure]: 30.091057 into packet.`. But, 
>> it seems like the  30.091057 is being be fed back into the conversion 
>> function.
>
>

-- 
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/473a3ef8-4fe4-4ab4-b450-1344ce0d57c9n%40googlegroups.com.

[weewx-user] Re: Help with Acurite5n1 & rtl-sdr

Re: [weewx-user] HTML Production Stopped After Update

Re: [weewx-user] HTML Production Stopped After Update

Re: [weewx-user] HTML Production Stopped After Update

Re: [weewx-user] HTML Production Stopped After Update

Re: [weewx-user] HTML Production Stopped After Update

Re: [weewx-user] logrotate permissions problem

Re: [weewx-user] WeeWX is second in Google's search list

[weewx-user] logrotate permissions problem

Re: [weewx-user] Re: Determine source of metric which fails QC

Re: [weewx-user] Re: Determine source of metric which fails QC

Re: [weewx-user] Re: Determine source of metric which fails QC

Re: [weewx-user] HTML Production Stopped After Update

[weewx-user] Re: Determine source of metric which fails QC

[weewx-user] Re: Determine source of metric which fails QC

[weewx-user] Re: Determine source of metric which fails QC

[weewx-user] Re: Determine source of metric which fails QC

[weewx-user] Re: Determine source of metric which fails QC

18 matches

Site Navigation

Mail list logo

Footer information