[weewx-user] Re: GW2000 driver and additional sensors

[gjr80]

The first requirement for plotting observation data from a driver/station 
is that the data to be plotted must be saved to database, simply put if 
it's not in the database you cannot plot it. Following on from this 
requirement is that WeeWX will only save a field to database if (1) the 
field exists in the current archive table schema (aka 'the database 
schema') and (2) the field exists in the archive record generated by WeeWX 
(software record generation) or the driver (hardware record generation). If 
these two conditions are met the field will be automatically saved to 
database by WeeWX.

As you say, all of the required data is present in loop packets. The WH41 
PM2.5 data appears in WeeWX loop packet field pm2_5 and the WH45 PM2.5 and 
PM10 data appears in WeeWX loop packet fields pm2_55 and pm10 (refer to the 
Field 
Map page 

 
in the Ecowitt Gateway driver wiki). If you are using the default 
wview_extended schema your archive table will contain the pm2_5 and pm10 
fields but not pm2_55. To get the WH45 PM2.5 data saved to database you 
will either need to add field pm2_55 to your database schema or you will 
need to re-purpose an existing unused database field in which to store the 
pm2_55 data. I would suggest the former, just follow the instructions 
under in Adding a new type to an existing database 
 in the 
Customization Guide. Once you have added the new field to the database you 
will need to tell WeeWX what units the new field uses, this is covered 
under Assigning a unit group 
 in the 
Customization Guide, but in your case the code required is:

import weewx.units
weewx.units.obs_group_dict['pm2_55'] = 'group_concentration'

and you should add this code to /usr/share/weewx/user/extensions.py or 
/home/weewx/bin/user/extensions.py (as applicable).

If you want to save the WH45 PM2.5 data in a (new) database field of your 
own choosing, for example say indoor_pm2_5, then you will need to add a 
field map extensions entry under [GW1000] in weewx.conf to map the WH45 
PM2.5 data to WeeWX field indoor_pm2_5, something like:

[GW1000]

[[field_map_extensions]]
indoor_pm2_5 = pm2_55

you would then need to follow the earlier instructions for adding a field 
to the database but use indoor_pm2_5 as the field name instead of pm2_55.

Once you restart WeeWX you should have WH41 PM2.5, WH45 PM2.5 and WH45 PM10 
data being saved to database. You can now make the necessary changes to the 
Season skin to create/display the desired plots.

I'm not quite sure what you mean by "I'd like to map the indoor pm2.5 (and 
pm10) separately from the outdoor pm2.5". These three fields are already 
mapped separately, do you mean plotted instead of mapped?

Assuming you are using the 'new' parameterised Season skin introduced in 
WeeWX v4.6.0 you will need to make a few changes to skin.conf to generate 
and display the plots you desire. There is already a plot that displays 
PM2.5 and PM10, you can add the WH45 PM2.5 data to the plot by adding 
pm2_55 to [[[daypm]]] under [ImageGenerator] [[day_images]], ie:

[ImageGenerator]

[[day_plots]]

[[[daypm]]]
pm1_0
pm2_5
pm10
pm2_55

You will need to make similar changes to [[[weekpm]]], [[[monthpm]]] and 
[[[yearpm]]]. This will result in the plots being likely being labelled 
'pm2_5 pm10 pm2_55', you can change this to something more appealing by 
using the label option for each series, eg:

[[[daypm]]]
pm1_0
pm2_5
label = Outdoor PM2.5
pm10
label = Indoor PM10
pm2_55
label = Indoor PM2.5

Note that this needs to be applied to each plot ie [[[daypm]]], [[[weekpm]]], 
[[[monthpm]]] and [[[yearpm]]]. Or you could add some suitable labels under 
[StdReport] 
[[Defaults]] [[[Labels]]] Generic in weewx.conf, eg:


[StdReport]

[[Defaults]]

[[[Labels]]]

Generic

pm2_5 = Outdoor PM2.5
pm10 = Indoor PM10
pm2_55 = Indoor PM2.5

If you want to have separate indoor and outdoor plots for PM2.5/PM10 then 
you would need to:
1. modify [[[daypm]]] and friends under [ImageGenerator] to plot either 
indoor or outdoor only
2. create a new plot, say [[[dayoutdoorpm]]] (and friends)
3. modify plot_groups under [DisplayOptions] in skin.conf to display the 
new plot

I see you have two rain gauges, if you want to plot the WS90 rain data (the 
p_* fields) then you will need to go through a similar process as you will 
with pm2_55.

Gary

On Monday, 6 June 2022 at 08:53:17 UTC+10 stephen...@gmail.com wrote:

> Hi all,
>
> I have the WH90,
> 

[weewx-user] Need some help changing a chart

[Steve2Q]

Hi all. I have not been on since BC (before Covid). I want to change my 
windspeed chart, but so far (because I forgot what my initial change was), 
I have not been successful. Here is what I would like to do;
Presently my windspeed chart looks like the attached. I thought I was being 
clever at the time by adding what I thought was windgust, but this was 
incorrect as my console (Peet Bros) only sends wind speed. I also added 
average windspeed. As you can see, the actual windspeed (blue) is labeled 
Gust Speed while the incorrect windgust (black) is labeled Wind Speed. What 
I want to do is get rid of the windgust completely and have the true wind 
speed labeled properly. I also want to keep the average windspeed as that 
calculation appears correct. 
The following snip is from my skin.conf file:

 #time_length = 43200
   #  Removed # on following 5/8/18 Switched order of WindSpeed and WindGust
  windGust
color = 'blue'
anti_alias = 2
   #  Changed color and data_type
  wind_avg
color = 'yellow'
data_type = windSpeed
aggregate_type = avg
aggregate_interval = 3600# 1 Hour
line_gap_fraction = 0.05
label =  1 Hour Avg Speed
   #  End of addition
   windSpeed
color = 0x00
anti_alias = 2

Thanks for any help..


-- 
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/42735f03-05c5-4d01-ad19-c8bfa0282121n%40googlegroups.com.

[weewx-user] GW2000 driver and additional sensors

[Stephen Hocking]

Hi all,

I have the WH90,
WH40 (bucket-style rainfall)
WH41 (outdoor PM2.5 sensor)
WH45 (indoor PM2.5/PM10/CO2/Temp/Humidity)
WH57 (lightning).

On the GW2000's webpage
on my ecowitt.net webpages, I can see all of these. Running the weewx
driver in debug mode (0.50b4) I see all of the sensors (output below). I'm
having some difficulty getting a graph on the Seasons skin for CO2, and I'd
like to map the indoor pm2.5 (and pm10) separately from the outdoor pm2.5.
I guess it's a matter of paying attention to the mapping section of
weew.conf and/or creating some additional DB fields?

root@weather:/etc/weewx# PYTHONPATH=/usr/share/weewx python3 -m user.gw1000
--live-data --ip-address=202.12.111.10

Using configuration file /etc/weewx/weewx.conf


Interrogating GW2000 at 202.12.111.10:45000


GW2000 live sensor data (2022-06-06 08:52:21 AEST (1654469541)):
'absbarometer': '931.80', 'annual_reset': '0.00', 'co2':
'518.00', 'co2_24h_avg': '485.00', 'day_reset': '0.00',
'daymaxwind': '67.32', 'gain0': '1.00', 'gain1': '1.00',
'gain2': '1.00', 'gain3': '1.00', 'gain4': '1.00', 'gain5':
'1.00', 'gain6': '1.00', 'gain7': '1.00', 'gain8': '1.00',
'gain9': '1.00', 'gustspeed': '55.08', 'humid17': '45.00',
'inhumid': '43.00', 'intemp': '18.90', 'light': '14150.00',
'lightningcount': '0.00', 'lightningdettime': 'None', 'lightningdist':
'None', 'outhumid': '87.00', 'outtemp': '4.90', 'p_rainday':
'1.73', 'p_rainevent': '1.86', 'p_rainmonth': '2.23',
'p_rainrate': '0.00', 'p_rainweek': '1.95', 'p_rainyear':
'28.08', 'pm10': '2.20', 'pm10_24h_avg': '2.70', 'pm251':
'1.00', 'pm251_24h_avg': '1.90', 'pm255': '1.30',
'pm255_24h_avg': '1.50', 'relbarometer': '932.80', 't_rainday':
'0.93', 't_rainevent': '1.13', 't_rainhour': '1.00',
't_rainmonth': '1.48', 't_rainrate': '0.00', 't_rainweek':
'1.16', 't_rainyear': '13.85', 'temp17': '21.50', 'uv':
'9.90', 'uvi': '1.00', 'week_reset': '0.00', 'wh40_batt':
'1.60', 'wh40_sig': '4.00', 'wh41_ch1_batt': '5.00',
'wh41_ch1_sig': '4.00', 'wh45_batt': '6.00', 'wh45_sig':
'4.00', 'wh57_batt': '5.00', 'wh57_sig': '4.00', 'winddir':
'283.00', 'windspeed': '15.84', 'ws90_batt': '3.14', 'ws90_sig':
'4.00'


And some packet capture

2022-06-06 08:46:30 AEST (1654469190): 'co2': '520', 'co2_24h_avg': '485',
'dateTime': '1654469190', 'daymaxwind': '18.7', 'dayRain': '9.3',
'extraHumid17': '46', 'extraTemp17': '21.4', 'hourRain': '10.0',
'inHumidity': '43', 'inTemp': '18.8', 'lightning_distance': 'None',
'lightning_last_det_time': 'None', 'lightning_strike_count': '0',
'lightningcount': '0', 'luminosity': '14300.0', 'monthRain': '14.8',
'outHumidity': '88', 'outTemp': '4.6', 'p_dayRain': '17.3', 'p_monthRain':
'22.3', 'p_rain': '0.0', 'p_rainRate': '0.0', 'p_stormRain': '18.6',
'p_weekRain': '19.5', 'p_yearRain': '280.8', 'pm2_5': '1.0',
'pm2_51_24h_avg': '1.9', 'pm2_55': '1.2', 'pm2_55_24h_avg': '1.5', 'pm10':
'2.0', 'pm10_24h_avg': '2.7', 'pressure': '931.7', 'rain': '0.0',
'rainRate': '0.0', 'relbarometer': '932.7', 'stormRain': '11.3', 'usUnits':
'17', 'UV': '1', 'uvradiation': '9.9', 'weekRain': '11.6', 'wh40_batt':
'1.6', 'wh40_sig': '4', 'wh41_ch1_batt': '5', 'wh41_ch1_sig': '4',
'wh45_batt': '6', 'wh45_sig': '4', 'wh57_batt': '5', 'wh57_sig': '4',
'windDir': '286', 'windGust': '13.2', 'windSpeed': '6.0', 'ws90_batt':
'3.14', 'ws90_sig': '4', 'yearRain': '138.5'

2022-06-06 08:46:50 AEST (1654469210): 'co2': '519', 'co2_24h_avg': '485',
'dateTime': '1654469210', 'daymaxwind': '18.7', 'dayRain': '9.3',
'extraHumid17': '46', 'extraTemp17': '21.4', 'hourRain': '10.0',
'inHumidity': '43', 'inTemp': '18.8', 'lightning_distance': 'None',
'lightning_last_det_time': 'None', 'lightning_strike_count': '0',
'lightningcount': '0', 'luminosity': '12460.0', 'monthRain': '14.8',
'outHumidity': '88', 'outTemp': '4.6', 'p_dayRain': '17.3', 'p_monthRain':
'22.3', 'p_rain': '0.0', 'p_rainRate': '0.0', 'p_stormRain': '18.6',
'p_weekRain': '19.5', 'p_yearRain': '280.8', 'pm2_5': '1.0',
'pm2_51_24h_avg': '1.9', 'pm2_55': '1.3', 'pm2_55_24h_avg': '1.5', 'pm10':
'2.3', 'pm10_24h_avg': '2.7', 'pressure': '931.7', 'rain': '0.0',
'rainRate': '0.0', 'relbarometer': '932.7', 'stormRain': '11.3', 'usUnits':
'17', 'UV': '0', 'uvradiation': '0.0', 'weekRain': '11.6', 'wh40_batt':
'1.6', 'wh40_sig': '4', 'wh41_ch1_batt': '5', 'wh41_ch1_sig': '4',
'wh45_batt': '6', 'wh45_sig': '4', 'wh57_batt': '5', 'wh57_sig': '4',
'windDir': '310', 'windGust': '8.9', 'windSpeed': '8.9', 'ws90_batt':
'3.14', 'ws90_sig': '4', 'yearRain': '138.5'





-- 

  "I and the public know
  what all schoolchildren learn
  Those to whom evil is done
  Do evil in return"W.H. Auden, "September 1, 1939"

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To 

[weewx-user] Re: Logging noise

[drd...@gmail.com]

I do indeed like it quiet! Your suggestion looks very plausible. I'll know 
by tomorrow morning. 
Thanks much for your very prompt reply

On Sunday, June 5, 2022 at 10:13:09 PM UTC+1 drd...@gmail.com wrote:

> I have been able to silence most log messages with
>
> # Whether to log successful operations
> log_success = False
> # Whether to log unsuccessful operations
> log_failure = False
>
> [Logging]
>   [[loggers]]
> [[[weewx.restx]]]
>   level = WARNING
> [[[weewx.manager]]]
>   level = WARNING
> [[[user.interceptor]]]
>   level = WARNING
>
> But I'm still seeing 
>
> weewx[24537] INFO weewx.engine: Garbage collected 13319 objects in 0.02 
> seconds
>
> every three hours in syslog
>
> Can someone please explain how to silence this INFO message?
>

-- 
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/7407135e-0227-4400-b6a3-a9127c48df72n%40googlegroups.com.

Re: [weewx-user] Logging noise

[Tom Keffer]

Wow, you really like it quiet!

I would think one more entry, this one for the engine, should do it:

[[[weewx.engine]]]
  level = WARNING




On Sun, Jun 5, 2022 at 2:13 PM drd...@gmail.com  wrote:

> I have been able to silence most log messages with
>
> # Whether to log successful operations
> log_success = False
> # Whether to log unsuccessful operations
> log_failure = False
>
> [Logging]
>   [[loggers]]
> [[[weewx.restx]]]
>   level = WARNING
> [[[weewx.manager]]]
>   level = WARNING
> [[[user.interceptor]]]
>   level = WARNING
>
> But I'm still seeing
>
> weewx[24537] INFO weewx.engine: Garbage collected 13319 objects in 0.02
> seconds
>
> every three hours in syslog
>
> Can someone please explain how to silence this INFO message?
>
> --
> 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/c65e6228-05be-4108-bbee-91ae18783408n%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/CAPq0zED0QcALE2c8Sv05n-DWriQTuT-OwndH1abHKOxd1pJXcQ%40mail.gmail.com.

[weewx-user] Logging noise

[drd...@gmail.com]

I have been able to silence most log messages with

# Whether to log successful operations
log_success = False
# Whether to log unsuccessful operations
log_failure = False

[Logging]
  [[loggers]]
[[[weewx.restx]]]
  level = WARNING
[[[weewx.manager]]]
  level = WARNING
[[[user.interceptor]]]
  level = WARNING

But I'm still seeing 

weewx[24537] INFO weewx.engine: Garbage collected 13319 objects in 0.02 
seconds

every three hours in syslog

Can someone please explain how to silence this INFO message?

-- 
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/c65e6228-05be-4108-bbee-91ae18783408n%40googlegroups.com.

Re: [weewx-user] CWOP/APRS upload does not contain pressure data

[Tom Keffer]

Whatever works.

Although I'd sure like to know why the in-the-box uploader doesn't work.

On Sun, Jun 5, 2022 at 11:01 AM 'Ben' via weewx-user <
weewx-user@googlegroups.com> wrote:

> Yep, I installed the WeeWX aprs extenstion and configure aprx -- the
> extension creates packets containing all data that's available and aprx
> pushes it to aprs.fi.
>
> Should've done that from the beginning, was way easier than I had
> expected. :-)
>
> tke...@gmail.com schrieb am Sonntag, 5. Juni 2022 um 20:00:06 UTC+2:
>
>> I'm really not an expert, but I thought packets sent to CWOP were the
>> same, except for their station ID (and passcode). At least, you're showing
>> up in the findu database:
>> https://www.findu.com/cgi-bin/raw.cgi?call=Dl1ben-13
>>
>> Now that I look at it, the last 3 packets contain altimeter. Value is
>> 1003.8 mbar. Did you change something?
>>
>> -tk
>>
>> On Sun, Jun 5, 2022 at 10:17 AM 'Ben' via weewx-user <
>> weewx...@googlegroups.com> wrote:
>>
>>> Ah, I didn't know that CWOP relies on altimeter, not pressure.
>>> Precipitation winds are missing because I don't have any sensors for it.
>>>
>>> All data that is collected (which is temperature, humidity, air
>>> pressure, air pressure @ sea level, dew point) does actually get into
>>> WeeWX. I can see it on my report page.
>>>
>>> Maybe the correct way to push data to aprs.fi is using
>>> https://github.com/cavedon/weewx-aprs and aprx to connect to APRS IS?
>>> I thought using CWOP was an easy workaround, but maybe I'm wrong.
>>> tke...@gmail.com schrieb am Sonntag, 5. Juni 2022 um 18:23:39 UTC+2:
>>>
 NB: CWOP requires *altimeter*. WeeWX needs station pressure
 (observation type "pressure") plus altitude to calculate it.

 It looks like altimeter is not the only thing you're missing.
 Precipitation and wind are also missing, which suggests are more general
 problem.

 I would look at the path data takes to get into WeeWX. Your software
 type suggests you are using MQTT somewhere along the way. Make sure it is
 configured correctly.

 You can also try running weewxd directly from the command line. It will
 print out the LOOP packets and archive records. Make sure they contain what
 you think they should, in particular, type "pressure".

 -tk

 On Sun, Jun 5, 2022 at 8:30 AM 'Ben' via weewx-user <
 weewx...@googlegroups.com> wrote:

> Hello everyone,
>
> I'm new to WeeWX, so please bear with me.
>
> My setup is a BME280 on a ESP32 Nodemcu delivering temperature,
> humidity and pressure data via MQTT to WeeWX running on my Raspberry Pi 
> 3B+
> w/ dietpi.
>
> Everything works fine except that when I try to upload my weather data
> to aprs.fi (yes, I'm a ham), only temperature and humidity show up.
>
> This data and current air pressure *do* show up on my reports, so I'd
> say there's nothing more to configure, isn't it?
>
> When I inspect my raw packets on aprs.fi, they actually do *lack* the
> pressure data:
>
> 2022-06-05 15:33:15 CEST: *DL1BEN-13
> *
> >APRS,TCPIP*,qAC,FIRST:@051330z5137.18N
> /00755.37E_.../...g...t070r...p...P...b.h69.weewx-4.8.0-MQTTSubscribeDriver
>
> Here's the relevant info from my weewx.conf:
>
>  [[CWOP]]
> # This section is for configuring posts to CWOP.
>
> # If you wish to post to CWOP, set the option 'enable' to true,
> # then specify the station ID (e.g., CW1234).
> enable = true
> station = DL1BEN-13
> # If this is an APRS (radio amateur) station, specify the
> # passcode (e.g., 12345). Otherwise, ignore.
> passcode = 
> server_list = rotate.aprs.net:14580, rotate.aprs2.net:14580
>
> What am I doing wrong?
> Any help is greatly appreciated.
>
> Tnx
> Ben
>
> --
> 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+...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-user/215bd0a3-9607-4759-b65f-804aa1a10322n%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+...@googlegroups.com.
>>>
>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/weewx-user/007a8fb3-c845-4391-98f6-e6e2e99c532en%40googlegroups.com
>>> 

Re: [weewx-user] CWOP/APRS upload does not contain pressure data

[Tom Keffer]

I'm really not an expert, but I thought packets sent to CWOP were the same,
except for their station ID (and passcode). At least, you're showing up in
the findu database: https://www.findu.com/cgi-bin/raw.cgi?call=Dl1ben-13

Now that I look at it, the last 3 packets contain altimeter. Value is
1003.8 mbar. Did you change something?

-tk

On Sun, Jun 5, 2022 at 10:17 AM 'Ben' via weewx-user <
weewx-user@googlegroups.com> wrote:

> Ah, I didn't know that CWOP relies on altimeter, not pressure.
> Precipitation winds are missing because I don't have any sensors for it.
>
> All data that is collected (which is temperature, humidity, air pressure,
> air pressure @ sea level, dew point) does actually get into WeeWX. I can
> see it on my report page.
>
> Maybe the correct way to push data to aprs.fi is using
> https://github.com/cavedon/weewx-aprs and aprx to connect to APRS IS?
> I thought using CWOP was an easy workaround, but maybe I'm wrong.
> tke...@gmail.com schrieb am Sonntag, 5. Juni 2022 um 18:23:39 UTC+2:
>
>> NB: CWOP requires *altimeter*. WeeWX needs station pressure (observation
>> type "pressure") plus altitude to calculate it.
>>
>> It looks like altimeter is not the only thing you're missing.
>> Precipitation and wind are also missing, which suggests are more general
>> problem.
>>
>> I would look at the path data takes to get into WeeWX. Your software type
>> suggests you are using MQTT somewhere along the way. Make sure it is
>> configured correctly.
>>
>> You can also try running weewxd directly from the command line. It will
>> print out the LOOP packets and archive records. Make sure they contain what
>> you think they should, in particular, type "pressure".
>>
>> -tk
>>
>> On Sun, Jun 5, 2022 at 8:30 AM 'Ben' via weewx-user <
>> weewx...@googlegroups.com> wrote:
>>
>>> Hello everyone,
>>>
>>> I'm new to WeeWX, so please bear with me.
>>>
>>> My setup is a BME280 on a ESP32 Nodemcu delivering temperature, humidity
>>> and pressure data via MQTT to WeeWX running on my Raspberry Pi 3B+ w/
>>> dietpi.
>>>
>>> Everything works fine except that when I try to upload my weather data
>>> to aprs.fi (yes, I'm a ham), only temperature and humidity show up.
>>>
>>> This data and current air pressure *do* show up on my reports, so I'd
>>> say there's nothing more to configure, isn't it?
>>>
>>> When I inspect my raw packets on aprs.fi, they actually do *lack* the
>>> pressure data:
>>>
>>> 2022-06-05 15:33:15 CEST: *DL1BEN-13
>>> *
>>> >APRS,TCPIP*,qAC,FIRST:@051330z5137.18N
>>> /00755.37E_.../...g...t070r...p...P...b.h69.weewx-4.8.0-MQTTSubscribeDriver
>>>
>>> Here's the relevant info from my weewx.conf:
>>>
>>>  [[CWOP]]
>>> # This section is for configuring posts to CWOP.
>>>
>>> # If you wish to post to CWOP, set the option 'enable' to true,
>>> # then specify the station ID (e.g., CW1234).
>>> enable = true
>>> station = DL1BEN-13
>>> # If this is an APRS (radio amateur) station, specify the
>>> # passcode (e.g., 12345). Otherwise, ignore.
>>> passcode = 
>>> server_list = rotate.aprs.net:14580, rotate.aprs2.net:14580
>>>
>>> What am I doing wrong?
>>> Any help is greatly appreciated.
>>>
>>> Tnx
>>> Ben
>>>
>>> --
>>> 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+...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/weewx-user/215bd0a3-9607-4759-b65f-804aa1a10322n%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/007a8fb3-c845-4391-98f6-e6e2e99c532en%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/CAPq0zECx-u-VKLurw3%3D80A-A9RYJntFFgmWVKvq7_gMx_gcMkw%40mail.gmail.com.

Re: [weewx-user] Sunshine Database

['Peter Fletcher' via weewx-user]

I am using a Vantage Pro 2, and I had forgotten (if I ever knew!) that the 
solar radiation value had a slower update rate than most other weather 
values, but it is certainly another reason not to worry about processing 
every LOOP value separately. You could even argue that (for this hardware) 
the LOOP code should accumulate time until the reported radiation value 
actually changes (or until an appropriately set  maximum time elapses) 
before processing the previous period's values.

On Sunday, June 5, 2022 at 12:33:47 PM UTC-4 jterr...@gmail.com wrote:

> I think it is also OK to do an average for every 30 seconds.  It depends 
> also on the weather station used.
> For  instance, a Davis Vantage Pro 2 ISS transmits an updated  solar 
> radiation value every 50 to 60 seconds. So with this weather station, even 
> a 1 minute average would not be very different  since anyway the solar 
> radiation values of the LOOP packet are the same for at least 50 seconds.!
>
> Le 5 juin 2022 à 18:02, 'Peter Fletcher' via weewx-user <
> weewx...@googlegroups.com> a écrit :
>
> I chose to average the LOOP radiation readings and only to do the 
> threshold calculation and make the sun/no sun determination every 30 
> seconds because I thought doing it on every LOOP might overload LOOP 
> processing (I am running weewx on a Pi 3B, which is also doing a few other 
> things which use the CPU). If this is an unnecessary concern, as it may 
> very well be, your modified code is much cleaner than mine.
>
> On Saturday, June 4, 2022 at 12:41:08 PM UTC-4 jterr...@gmail.com wrote:
>
>> It is a very good idea to calculate the sunshine duration for each LOOP 
>> packet and sum these values to make the final archive sunshine duration.  I 
>> have modified my script accordingly :  
>> https://github.com/Jterrettaz/sunduration.
>> The logic is the following :  for each received LOOP packet, the 
>> radiation is compared to a calculated threshold. If the radiation is above 
>> the threshold value, the sunshine time for the LOOP packet is equal to the 
>> time elapsed between the  previous loop packet and this packet (most of the 
>> time 2 seconds with a Vantage Davis Pro).
>> The final archive sunshine duration is the sum of all the LOOP value 
>> within the archive period.
>> Le vendredi 3 juin 2022 à 21:59:36 UTC+2, Peter Fletcher a écrit :
>>
>>> That makes some sense when you are getting data from an 'external' 
>>> sensor, though there are (IMHO) simpler ways of doing it. weewx already has 
>>> access to the LOOP radiation data from the VP2, so handling the processing 
>>> and data storage within weewx makes more sense to me in this case.
>>>
>>> On Friday, June 3, 2022 at 3:24:23 PM UTC-4 vince wrote:
>>>
 On Friday, June 3, 2022 at 11:17:00 AM UTC-7 Meteo Oberwallis wrote:

>  if the interval of Weewx and the data logger is set to 10 minutes, I 
> would have liked to read the value of the solar sensor every minute and 
> then write it into a separate .sdb database as possible sunshine.


 Personally I'd use an external program called via cron and posting a 
 message to a MQTT topic.  Have weewx subscribe to that topic to get the 
 data into your db.

 This is how I used to get my DS18b20 temperature sensor data into weewx.


> -- 
> You received this message because you are subscribed to a topic in the 
> Google Groups "weewx-user" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/weewx-user/19ylVTRqbh4/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> weewx-user+...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/0e631671-0a74-4963-9f1c-e5f81bc7c366n%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/72776a59-cc07-4bd3-9fa2-382bb45b73c5n%40googlegroups.com.

Re: [weewx-user] CWOP/APRS upload does not contain pressure data

['Ben' via weewx-user]

Ah, I didn't know that CWOP relies on altimeter, not pressure. 
Precipitation winds are missing because I don't have any sensors for it. 

All data that is collected (which is temperature, humidity, air pressure, 
air pressure @ sea level, dew point) does actually get into WeeWX. I can 
see it on my report page.

Maybe the correct way to push data to aprs.fi is using 
https://github.com/cavedon/weewx-aprs and aprx to connect to APRS IS? 
I thought using CWOP was an easy workaround, but maybe I'm wrong. 
tke...@gmail.com schrieb am Sonntag, 5. Juni 2022 um 18:23:39 UTC+2:

> NB: CWOP requires *altimeter*. WeeWX needs station pressure (observation 
> type "pressure") plus altitude to calculate it.
>
> It looks like altimeter is not the only thing you're missing. 
> Precipitation and wind are also missing, which suggests are more general 
> problem.
>
> I would look at the path data takes to get into WeeWX. Your software type 
> suggests you are using MQTT somewhere along the way. Make sure it is 
> configured correctly. 
>
> You can also try running weewxd directly from the command line. It will 
> print out the LOOP packets and archive records. Make sure they contain what 
> you think they should, in particular, type "pressure".
>
> -tk
>
> On Sun, Jun 5, 2022 at 8:30 AM 'Ben' via weewx-user <
> weewx...@googlegroups.com> wrote:
>
>> Hello everyone,
>>
>> I'm new to WeeWX, so please bear with me. 
>>
>> My setup is a BME280 on a ESP32 Nodemcu delivering temperature, humidity 
>> and pressure data via MQTT to WeeWX running on my Raspberry Pi 3B+ w/ 
>> dietpi.
>>
>> Everything works fine except that when I try to upload my weather data to 
>> aprs.fi (yes, I'm a ham), only temperature and humidity show up.
>>
>> This data and current air pressure *do* show up on my reports, so I'd 
>> say there's nothing more to configure, isn't it?
>>
>> When I inspect my raw packets on aprs.fi, they actually do *lack* the 
>> pressure data:
>>
>> 2022-06-05 15:33:15 CEST: *DL1BEN-13 
>> *
>> >APRS,TCPIP*,qAC,FIRST:@051330z5137.18N/00755.37E_.../...g...t070r...p...P...b.h69.weewx-4.8.0-MQTTSubscribeDriver
>>
>> Here's the relevant info from my weewx.conf:
>>
>>  [[CWOP]]
>> # This section is for configuring posts to CWOP.
>>
>> # If you wish to post to CWOP, set the option 'enable' to true,
>> # then specify the station ID (e.g., CW1234).
>> enable = true
>> station = DL1BEN-13
>> # If this is an APRS (radio amateur) station, specify the
>> # passcode (e.g., 12345). Otherwise, ignore.
>> passcode = 
>> server_list = rotate.aprs.net:14580, rotate.aprs2.net:14580
>>
>> What am I doing wrong?
>> Any help is greatly appreciated.
>>
>> Tnx
>> Ben
>>
>> -- 
>> 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+...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/215bd0a3-9607-4759-b65f-804aa1a10322n%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/007a8fb3-c845-4391-98f6-e6e2e99c532en%40googlegroups.com.

Re: [weewx-user] Sunshine Database

[Jacques Terrettaz]

I think it is also OK to do an average for every 30 seconds.  It depends also 
on the weather station used.
For  instance, a Davis Vantage Pro 2 ISS transmits an updated  solar radiation 
value every 50 to 60 seconds. So with this weather station, even a 1 minute 
average would not be very different  since anyway the solar radiation values of 
the LOOP packet are the same for at least 50 seconds.!

> Le 5 juin 2022 à 18:02, 'Peter Fletcher' via weewx-user 
>  a écrit :
> 
> I chose to average the LOOP radiation readings and only to do the threshold 
> calculation and make the sun/no sun determination every 30 seconds because I 
> thought doing it on every LOOP might overload LOOP processing (I am running 
> weewx on a Pi 3B, which is also doing a few other things which use the CPU). 
> If this is an unnecessary concern, as it may very well be, your modified code 
> is much cleaner than mine.
> 
> On Saturday, June 4, 2022 at 12:41:08 PM UTC-4 jterr...@gmail.com wrote:
> It is a very good idea to calculate the sunshine duration for each LOOP 
> packet and sum these values to make the final archive sunshine duration.  I 
> have modified my script accordingly :  
> https://github.com/Jterrettaz/sunduration 
> .
> The logic is the following :  for each received LOOP packet, the radiation is 
> compared to a calculated threshold. If the radiation is above the threshold 
> value, the sunshine time for the LOOP packet is equal to the time elapsed 
> between the  previous loop packet and this packet (most of the time 2 seconds 
> with a Vantage Davis Pro).
> The final archive sunshine duration is the sum of all the LOOP value within 
> the archive period.
> Le vendredi 3 juin 2022 à 21:59:36 UTC+2, Peter Fletcher a écrit :
> That makes some sense when you are getting data from an 'external' sensor, 
> though there are (IMHO) simpler ways of doing it. weewx already has access to 
> the LOOP radiation data from the VP2, so handling the processing and data 
> storage within weewx makes more sense to me in this case.
> 
> On Friday, June 3, 2022 at 3:24:23 PM UTC-4 vince wrote:
> On Friday, June 3, 2022 at 11:17:00 AM UTC-7 Meteo Oberwallis wrote:
>  if the interval of Weewx and the data logger is set to 10 minutes, I would 
> have liked to read the value of the solar sensor every minute and then write 
> it into a separate .sdb database as possible sunshine.
> 
> Personally I'd use an external program called via cron and posting a message 
> to a MQTT topic.  Have weewx subscribe to that topic to get the data into 
> your db.
> 
> This is how I used to get my DS18b20 temperature sensor data into weewx.
> 
> 
> -- 
> You received this message because you are subscribed to a topic in the Google 
> Groups "weewx-user" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/weewx-user/19ylVTRqbh4/unsubscribe 
> .
> To unsubscribe from this group and all its topics, 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/0e631671-0a74-4963-9f1c-e5f81bc7c366n%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/FE21AA15-CB39-418F-8E94-F0C27E7A4BE9%40gmail.com.

Re: [weewx-user] CWOP/APRS upload does not contain pressure data

[Tom Keffer]

NB: CWOP requires *altimeter*. WeeWX needs station pressure (observation
type "pressure") plus altitude to calculate it.

It looks like altimeter is not the only thing you're missing.
Precipitation and wind are also missing, which suggests are more general
problem.

I would look at the path data takes to get into WeeWX. Your software type
suggests you are using MQTT somewhere along the way. Make sure it is
configured correctly.

You can also try running weewxd directly from the command line. It will
print out the LOOP packets and archive records. Make sure they contain what
you think they should, in particular, type "pressure".

-tk

On Sun, Jun 5, 2022 at 8:30 AM 'Ben' via weewx-user <
weewx-user@googlegroups.com> wrote:

> Hello everyone,
>
> I'm new to WeeWX, so please bear with me.
>
> My setup is a BME280 on a ESP32 Nodemcu delivering temperature, humidity
> and pressure data via MQTT to WeeWX running on my Raspberry Pi 3B+ w/
> dietpi.
>
> Everything works fine except that when I try to upload my weather data to
> aprs.fi (yes, I'm a ham), only temperature and humidity show up.
>
> This data and current air pressure *do* show up on my reports, so I'd say
> there's nothing more to configure, isn't it?
>
> When I inspect my raw packets on aprs.fi, they actually do *lack* the
> pressure data:
>
> 2022-06-05 15:33:15 CEST: *DL1BEN-13
> *
> >APRS,TCPIP*,qAC,FIRST:@051330z5137.18N
> /00755.37E_.../...g...t070r...p...P...b.h69.weewx-4.8.0-MQTTSubscribeDriver
>
> Here's the relevant info from my weewx.conf:
>
>  [[CWOP]]
> # This section is for configuring posts to CWOP.
>
> # If you wish to post to CWOP, set the option 'enable' to true,
> # then specify the station ID (e.g., CW1234).
> enable = true
> station = DL1BEN-13
> # If this is an APRS (radio amateur) station, specify the
> # passcode (e.g., 12345). Otherwise, ignore.
> passcode = 
> server_list = rotate.aprs.net:14580, rotate.aprs2.net:14580
>
> What am I doing wrong?
> Any help is greatly appreciated.
>
> Tnx
> Ben
>
> --
> 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/215bd0a3-9607-4759-b65f-804aa1a10322n%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/CAPq0zEDOmiwFbV%2BMe0EvnE2_PAXOr_frdLmOwVwt-Mg97RbNAQ%40mail.gmail.com.

Re: [weewx-user] Scaling Units for different reports

[Tom Keffer]

Exactly.

That's the big advantage of assigning a type to a unit group. All the
formatting and conversion machinery becomes available.

On Sun, Jun 5, 2022 at 8:45 AM 'Peter Fletcher' via weewx-user <
weewx-user@googlegroups.com> wrote:

> Thanks!
> I assume that this works 'out of the box' because I have defined the unit
> for sunshine time as 'minute' (rather than something like 'sun_minute') and
> weewx already 'knows' how to convert between common units of time. For my
> solar production example, you would presumably need to use the unit names
> as they are defined in one of the energy groups..
>
> On Friday, June 3, 2022 at 7:41:33 PM UTC-4 tke...@gmail.com wrote:
>
>> Sure. Just tell the report to use hours instead of minutes.
>>
>> For example, for tags, it becomes $week.sunshine.sum.hour
>>
>> For a plot, use option 'unit' in skin.conf.
>>
>> [ImageGenerator]
>>   ...
>>   [[week_images]]
>> ...
>> [[[week_sunshine]]]
>>   unit = hour
>>   sunshine
>>
>> All documented in the Customizing Guide
>> .
>>
>> On Fri, Jun 3, 2022 at 4:31 PM 'Peter Fletcher' via weewx-user <
>> weewx...@googlegroups.com> wrote:
>>
>>> As noted in a different thread, I am working on a small extension to
>>> calculate and store sunshine time (time when the sun is out, rather than
>>> covered by clouds). I am saving the number of *minutes* of sunshine
>>> during the archive period in each archive record. Sunshine minutes are fine
>>> for display on daily reports and graphs, but I would rather display the
>>> more usual sunshine hours on weekly, monthly, and longer reports. Is there
>>> an easy way to tell the report generator to scale the units it uses for
>>> different report periods? I can see this being useful for other categories
>>> of data, too. You might, for example want to display solar production in Wh
>>> for the daily reports but in kWh for monthly and longer ones.
>>>
>>> I feel that XTypes may provide the answer to this, but couldn't really
>>> get my head around how it would work, in practice.
>>>
>>> --
>>> 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+...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/weewx-user/2df447f0-c12d-4947-9bf4-9a2ab9491411n%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/e033d8fb-4ec7-4d63-ae5a-d8df1da26dcen%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/CAPq0zEALGZY0GzVrFx5SWO-35MprpmEiEtwFY-O4FQ2WVzUXLA%40mail.gmail.com.

Re: [weewx-user] Sunshine Database

['Peter Fletcher' via weewx-user]

I chose to average the LOOP radiation readings and only to do the threshold 
calculation and make the sun/no sun determination every 30 seconds because 
I thought doing it on every LOOP might overload LOOP processing (I am 
running weewx on a Pi 3B, which is also doing a few other things which use 
the CPU). If this is an unnecessary concern, as it may very well be, your 
modified code is much cleaner than mine.

On Saturday, June 4, 2022 at 12:41:08 PM UTC-4 jterr...@gmail.com wrote:

> It is a very good idea to calculate the sunshine duration for each LOOP 
> packet and sum these values to make the final archive sunshine duration.  I 
> have modified my script accordingly :  
> https://github.com/Jterrettaz/sunduration.
> The logic is the following :  for each received LOOP packet, the radiation 
> is compared to a calculated threshold. If the radiation is above the 
> threshold value, the sunshine time for the LOOP packet is equal to the time 
> elapsed between the  previous loop packet and this packet (most of the time 
> 2 seconds with a Vantage Davis Pro).
> The final archive sunshine duration is the sum of all the LOOP value 
> within the archive period.
> Le vendredi 3 juin 2022 à 21:59:36 UTC+2, Peter Fletcher a écrit :
>
>> That makes some sense when you are getting data from an 'external' 
>> sensor, though there are (IMHO) simpler ways of doing it. weewx already has 
>> access to the LOOP radiation data from the VP2, so handling the processing 
>> and data storage within weewx makes more sense to me in this case.
>>
>> On Friday, June 3, 2022 at 3:24:23 PM UTC-4 vince wrote:
>>
>>> On Friday, June 3, 2022 at 11:17:00 AM UTC-7 Meteo Oberwallis wrote:
>>>
  if the interval of Weewx and the data logger is set to 10 minutes, I 
 would have liked to read the value of the solar sensor every minute and 
 then write it into a separate .sdb database as possible sunshine.
>>>
>>>
>>> Personally I'd use an external program called via cron and posting a 
>>> message to a MQTT topic.  Have weewx subscribe to that topic to get the 
>>> data into your db.
>>>
>>> This is how I used to get my DS18b20 temperature sensor data into weewx.
>>>
>>>

-- 
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/0e631671-0a74-4963-9f1c-e5f81bc7c366n%40googlegroups.com.

Re: [weewx-user] Scaling Units for different reports

['Peter Fletcher' via weewx-user]

Thanks!
I assume that this works 'out of the box' because I have defined the unit 
for sunshine time as 'minute' (rather than something like 'sun_minute') and 
weewx already 'knows' how to convert between common units of time. For my 
solar production example, you would presumably need to use the unit names 
as they are defined in one of the energy groups..

On Friday, June 3, 2022 at 7:41:33 PM UTC-4 tke...@gmail.com wrote:

> Sure. Just tell the report to use hours instead of minutes.
>
> For example, for tags, it becomes $week.sunshine.sum.hour
>
> For a plot, use option 'unit' in skin.conf.
>
> [ImageGenerator]
>   ...
>   [[week_images]]
> ...
> [[[week_sunshine]]]
>   unit = hour
>   sunshine
>   
> All documented in the Customizing Guide 
> .
>
> On Fri, Jun 3, 2022 at 4:31 PM 'Peter Fletcher' via weewx-user <
> weewx...@googlegroups.com> wrote:
>
>> As noted in a different thread, I am working on a small extension to 
>> calculate and store sunshine time (time when the sun is out, rather than 
>> covered by clouds). I am saving the number of *minutes* of sunshine 
>> during the archive period in each archive record. Sunshine minutes are fine 
>> for display on daily reports and graphs, but I would rather display the 
>> more usual sunshine hours on weekly, monthly, and longer reports. Is there 
>> an easy way to tell the report generator to scale the units it uses for 
>> different report periods? I can see this being useful for other categories 
>> of data, too. You might, for example want to display solar production in Wh 
>> for the daily reports but in kWh for monthly and longer ones.
>>
>> I feel that XTypes may provide the answer to this, but couldn't really 
>> get my head around how it would work, in practice.
>>
>> -- 
>> 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+...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/2df447f0-c12d-4947-9bf4-9a2ab9491411n%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/e033d8fb-4ec7-4d63-ae5a-d8df1da26dcen%40googlegroups.com.

[weewx-user] CWOP/APRS upload does not contain pressure data

['Ben' via weewx-user]

Hello everyone,

I'm new to WeeWX, so please bear with me. 

My setup is a BME280 on a ESP32 Nodemcu delivering temperature, humidity 
and pressure data via MQTT to WeeWX running on my Raspberry Pi 3B+ w/ 
dietpi.

Everything works fine except that when I try to upload my weather data to 
aprs.fi (yes, I'm a ham), only temperature and humidity show up.

This data and current air pressure *do* show up on my reports, so I'd say 
there's nothing more to configure, isn't it?

When I inspect my raw packets on aprs.fi, they actually do *lack* the 
pressure data:

2022-06-05 15:33:15 CEST: *DL1BEN-13 
*
>APRS,TCPIP*,qAC,FIRST:@051330z5137.18N/00755.37E_.../...g...t070r...p...P...b.h69.weewx-4.8.0-MQTTSubscribeDriver

Here's the relevant info from my weewx.conf:

 [[CWOP]]
# This section is for configuring posts to CWOP.

# If you wish to post to CWOP, set the option 'enable' to true,
# then specify the station ID (e.g., CW1234).
enable = true
station = DL1BEN-13
# If this is an APRS (radio amateur) station, specify the
# passcode (e.g., 12345). Otherwise, ignore.
passcode = 
server_list = rotate.aprs.net:14580, rotate.aprs2.net:14580

What am I doing wrong?
Any help is greatly appreciated.

Tnx
Ben

-- 
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/215bd0a3-9607-4759-b65f-804aa1a10322n%40googlegroups.com.

[weewx-user] Re: GW2000/WS90 Piezo & Ecowitt Gateway Driver

[Captain Steubing]

Had 0.39" of rain measured overnight and it looks like it's registering in 
WeeWX. Yay! Also seeing historical based on this rain event. 

Thanks again.

On Saturday, June 4, 2022 at 6:56:24 PM UTC-5 Captain Steubing wrote:

> Hi Gary, 
>
> Thanks for your message, much appreciated. Based on the data that I'm 
> getting from the GW2000/WS90 with debug enabled,  I've set up the following 
> in weewx.conf. Hoping that on my next rain event I'll get some data. I've 
> not added any other fields to the database; although it would have been 
> nice to have the rain history from the last few days when I set it up. We 
> had some good downpours from the recent Potential Tropical Cyclone #1 as it 
> passed.
>
> [GW1000]
> #p_rain p_stormRain p_rainRate p_dayRain p_weekRain p_monthRain 
> p_yearRain
>
> [[field_map_extensions]]
> rain = p_rain
> stormRain = p_stormRain
> dayRain = p_dayRain
> weekRain = p_weekRain
> monthRain = p_monthRain
> yearRain = p_yearRain
> rainRate = p_rainRate
>
> Hopefully this thread will be useful for someone with a new GW2000/WS90
>
> Thanks, 
> Arthur
>
> On Saturday, June 4, 2022 at 5:32:58 AM UTC-5 gjr80 wrote:
>
>> Arthur,
>>
>> There are a few approaches you could use, what works best will depend on 
>> what hardware you have and what you want to achieve.
>>
>> If your only rain gauge is the WS90 then the easiest approach is to alter 
>> the Ecowitt Gateway Driver field map to map the WS90 (piezo) rain fields to 
>> the standard WeeWX rain fields. This approach requires no change to the 
>> Seasons skin (other than perhaps some sensor settings if you wish to 
>> display WS90 battery and signal data). You could do as you outlined above 
>> and add additional fields to the WeeWX database and alter the Season skin 
>> to display these new fields, though if the WS90 is your only rain gauge 
>> then that is quite a bit of work for no real benefit. If you have another 
>> rain gauge as well as the WS90 then the standard WeeWx rain fields will 
>> likely be used by the other rain gauge. In that case you have no choice but 
>> to add new fields to the database in which to save the WS90 rain data (and 
>> modify the Seasons skin as you indicated). Note that the week, month and 
>> year fields are not used by the Seasons skin, so there is no real benefit 
>> in adding them to the database. The dayRain field is used by some of the 
>> RESTful uploaders, so there may be benefit in providing that field to WeeWX 
>> (it must be named dayRain though), but there is no need to add it to the 
>> database as only the current value is used.
>>
>> Assuming the WS90 is your only rain gauge the following field map 
>> extensions for the driver should be all that is required, something like:
>>
>> [GW1000]
>> 
>> [[field_map_extensions]]
>> rain = p_rain
>> stormRain = p_rainevent
>> dayRain = p_rainday
>> weekRain = p_rainweek
>> monthRain = p_rainmonth
>> yearRain = p_rainyear
>> rainRate = p_rainrate
>>
>> Of the above fields only rain and rainRate will be stored in the 
>> database (WeeWX will automatically store data in fields where (1) the field 
>> exists in the archive record and (2) the archive table in the database has 
>> an identical column name, all other fields are ultimately discarded). This 
>> is fine if the Seasons skin is all you are using as the Seasons skin does 
>> not use any of the other rain related fields. As mentioned above if you are 
>> uploading to WU or PWS then the dayRain field may be of use, though if 
>> it is not available WeeWX will calculate the value from the rain field. 
>> So unless you have some other need stormRain, weekRain, monthRain and 
>> yearRain entries could be omitted without detriment.
>>
>> Gary
>>
>> On Saturday, 4 June 2022 at 14:26:40 UTC+10 Captain Steubing wrote:
>>
>>> Howdy WX Friends, 
>>>
>>> Recently installed WeeWX pulling data from a GW2000/WS90.  System is 
>>> built and receiving data from the GW2000.  Trying to figure out how to get 
>>> the "p_rainX" variables into WeeWX.  I've pieced together what I think 
>>> I need to do, but want to ensure I'm understanding things correctly.
>>>
>>>- Add the p_rainX (p_rain p_stormRain p_rainRate p_dayRain 
>>>p_weekRain p_monthRain p_yearRain) columns to the WeeWX database.
>>>   - Assuming this is the command: wee_database --add-column=p_rain 
>>>   etc.
>>>- Update skin.conf stanzas [DisplayOptions] and [CheetahGenerator] 
>>>adding p_rainX where I see the rainX variables .
>>>
>>> Is there a way to map the p_rainX variables to the standard rainX variables 
>>> to avoid having to do all of this manual config?
>>>
>>> Thanks for your help.
>>>
>>> Thanks, 
>>> Arthur
>>>
>>

-- 
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