Re: [weewx-user] Re: Wee-Import UTC Conversion

[gjr80]

WeeWX stores date-times in unix time 
 which is the number of seconds 
since the Unix Epoch which is 00:00:00 UTC on 1 January 1970. That is why 
you might say WeeWX stores date-time in UTC. The python datetime library 
used by WeeWX for manipulating dates/times knows the local computer time 
and timezone from the operating system (try typing date at a linux command 
prompt - you will get a date, time and timezone). The python date time 
library is thus able to convert between UTC and the local system time. You 
change the system timezone by using a utility such as timedatectl on 
systemd based systems. So whilst WeeWX knows the station lat/long, this has 
nothing to do with determining local time; it is all taken from the system. 
It is possible to programmatically determine the system offset from UTC 
through use of some of the methods in the python datetime library. 

WeeWX has no knowledge of any other timezones. Hence my comment that 
wee_import may have been able to handle UTC times. Any other timezones 
would be somewhat difficult to implement given the current WeeWX python 
dependencies.

Gary
On Thursday, 19 January 2023 at 13:34:54 UTC+10 Wayne wrote:

> Help me understand this. The weewx documentation says all data is stored 
> in UTC time. If that is true (and I believe it is) how does my imported 
> data in Local Time get converted to UTC? The only place where I can see 
> that weewx knows my time zone is possibly the Longitude value in 
> weewx.conf. Is there some other place where a GMT offset is stored? Does it 
> look at the system clock offset? I'm really curious about this. Thanks.
>
>
> On Wed, Jan 18, 2023, at 5:40 PM, gjr80 wrote:
> > If that is local time then you are in luck and need do nothing special. 
> > If it's GMT/UTC then wee_import cannot handle it as is; it will be 
> > treated as local, there is no 'this_is_GMT' option in wee_import. 
> > Having looked at the wee_import date-time routines the only possible 
> > way to import a GMT/UTC type date-time is if the date-time data was 
> > formatted as an epoch timestamp. That being said, it should be fairly 
> > easy to implement a 'this_is_GMT' option to interpret the date-time 
> > string as GMT/UTC rather than local time, there is sufficient support 
> > for GMT/UTC in the python date time library without the need to include 
> > timezone data. I'll add it to the list of wee_import ToDos.
> >
> > Gary
> >
> > On Thursday, 19 January 2023 at 10:15:11 UTC+10 Wayne wrote:
> >> Here is a sample of a CSV format of my data: 
> >> 
> >> 
> Time,TempOut,TempIn,HumOut,HumIn,Baro,Rain,Rate,Wind,WindDir,Gust,GustDir 
> >> 2020-03-26 
> 10:20:00,56.3,71.8,36.0,31.0,29.742,0.00,-327.68,10.0,270.0,22.0, 
> >> 2020-03-26 
> 10:30:00,56.8,70.2,35.0,29.0,29.739,0.00,-327.68,12.0,270.0,23.0, 
> >> 2020-03-26 
> 10:40:00,57.1,69.1,34.0,28.0,29.739,0.00,-327.68,12.0,247.5,22.0, 
> >> 2020-03-26 
> 10:50:00,57.4,69.0,33.0,27.0,29.742,0.00,-327.68,11.0,247.5,21.0, 
> >> 2020-03-26 
> 11:00:00,57.5,68.5,33.0,27.0,29.736,0.00,-327.68,13.0,247.5,23.0, 
> >> 
> >> My belief is that this is Local Time. There is no GMT offset nor 
> timezone indicator. These are the first records that I captured at this 
> particular location and I'm pretty sure I started this station around 10 AM 
> and not 3 AM local (if the value shown were UTC). Maybe others could 
> confirm the WeatherLink application behavior. This data came from a Davis 
> Weather Monitor II. I hope this helps. 
> >> 
> >> 
> >> On Wed, Jan 18, 2023, at 4:19 PM, gjr80 wrote: 
> >> > Short answer is it depends. What is the format of the date-time data 
> in 
> >> > your resulting CSV file? Is it straight date and time but in GMT, eg 
> >> > '24-Jan-2023 18:25' or does it have some sort of timezone indicator 
> >> > embedded eg '24-Jan-2023 18:25 GMT' or is an epoch timestamp eg 
> >> > '1674548700'? WeeWX does not recognise timezones but the python 
> >> > datetime calls used may support GMT. I will need to look at your data 
> >> > and the wee_import date-time parsing routines to see what is 
> possible. 
> >> > 
> >> > Gary 
> >> > 
> >> > On Thursday, 19 January 2023 at 08:41:35 UTC+10 Wayne wrote: 
> >> >> I am looking into the process for converting my Davis weather 
> archive files to be imported into weewx. If I'm not mistaken, Davis 
> WeatherLink stores the timestamps in local time in the .wlk files. 
> Accordingly, the application wlkReader creates a csv file also in the same 
> local time format. 
> >> >> 
> >> >> The import config file used by the utility wee-import provides an 
> option raw_datetime_format for defining the text date/time format in the 
> csv input file. Although I don't see it explicitly discussed in the 
> Utilities Guide, is there a format code which can be use in this option 
> which applies a UTC offset conversion to the supplied local time? If so can 
> you give an example of its usage? Otherwise the only other option I 

Re: [weewx-user] line gaps

[Graham Eddy]

fair request, but i don’t GitHub, so some code follows.
my old RPi test box is now my production LoRaWAN box, so i worked using my 
production weewx box, so testing is pretty minimal (seems to work on my two 
graphs)

see weeplot/utilities.py:520 on weewx 5.8.0:

line = []
last_x = None
for xy in zip(x, y):
#GE start new
# If the y coordinate is None, ignore it
if xy[1] is None:
continue
#GE end new 
dx = xy[0] - last_x if last_x is not None else 0
last_x = xy[0]
#GE start original
#GE# If the y coordinate is None or dx > maxdx, that marks a break
#GEif xy[1] is None or (maxdx is not None and dx > maxdx):
#GE end original
#GE start new
# If dx > maxdx, that marks a break
if (maxdx is not None and dx > maxdx):
#GE end new 
# If the length of the line is non-zero, yield it
if len(line):
yield line
line = [] if xy[1] is None else [xy]
else:   
line.append(xy)
if len(line):
yield line

cheers
⊣GE⊢

> On 19 Jan 2023, at 12:50 pm, Tom Keffer  wrote:
> 
> Speaking of dumb, in retrospect, this seems like a dumb choice. It should be 
> at least optional.
> 
> The code was written about 10 years ago. I simply cannot remember why I chose 
> to always honor None values, despite any value of line_gap_fraction.
> 
> A PR would be welcome, should you wish to write one.
> 
> On Wed, Jan 18, 2023 at 4:55 PM Graham Eddy  > wrote:
>> this means line_gap_fraction relates only to interval gaps of whole records, 
>> not of column value gaps within successive records.
>> hmm, inserting interpolated values to cover interval gaps in a column can 
>> only be done to past records - nope, i don’t want to go there...
>> well, now i know - learn to love the ‘mark’ not the ‘line'.
>> thanks
>> ⊣GE⊢
>> 
>>> On 19 Jan 2023, at 2:49 am, Tom Keffer >> > wrote:
>>> 
>>> You're not doing something dumb. None values always mark line breaks. 
>>> 
>>> On Wed, Jan 18, 2023 at 6:30 AM Graham Eddy >> > wrote:
>>> 
>> 
>> 
>> -- 
>> 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/D4BCD919-180F-45F4-AA01-845B49CB9A74%40geddy.au
>>  
>> .
> 
> 
> -- 
> 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/CAPq0zEAoEWv3TdnHZ%2BJeWmbQV7t20-h2N9La3geer7eiLyavMA%40mail.gmail.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/6EF71977-00B3-465E-A252-2CC02F7B1C3E%40geddy.au.

Re: [weewx-user] Re: Wee-Import UTC Conversion

[Wayne]

Help me understand this.  The weewx documentation says all data is stored in 
UTC time.  If that is true (and I believe it is) how does my imported data in 
Local Time get converted to UTC?  The only place where I can see that weewx 
knows my time zone is possibly the Longitude value in weewx.conf.  Is there 
some other place where a GMT offset is stored?  Does it look at the system 
clock offset?  I'm really curious about this.  Thanks.


On Wed, Jan 18, 2023, at 5:40 PM, gjr80 wrote:
> If that is local time then you are in luck and need do nothing special. 
> If it's GMT/UTC then wee_import cannot handle it as is; it will be 
> treated as local, there is no 'this_is_GMT' option in wee_import. 
> Having looked at the wee_import date-time routines the only possible 
> way to import a GMT/UTC type date-time is if the date-time data was 
> formatted as an epoch timestamp. That being said, it should be fairly 
> easy to implement a 'this_is_GMT' option to interpret the date-time 
> string as GMT/UTC rather than local time, there is sufficient support 
> for GMT/UTC in the python date time library without the need to include 
> timezone data. I'll add it to the list of wee_import ToDos.
>
> Gary
>
> On Thursday, 19 January 2023 at 10:15:11 UTC+10 Wayne wrote:
>> Here is a sample of a CSV format of my data: 
>> 
>> Time,TempOut,TempIn,HumOut,HumIn,Baro,Rain,Rate,Wind,WindDir,Gust,GustDir 
>> 2020-03-26 10:20:00,56.3,71.8,36.0,31.0,29.742,0.00,-327.68,10.0,270.0,22.0, 
>> 2020-03-26 10:30:00,56.8,70.2,35.0,29.0,29.739,0.00,-327.68,12.0,270.0,23.0, 
>> 2020-03-26 10:40:00,57.1,69.1,34.0,28.0,29.739,0.00,-327.68,12.0,247.5,22.0, 
>> 2020-03-26 10:50:00,57.4,69.0,33.0,27.0,29.742,0.00,-327.68,11.0,247.5,21.0, 
>> 2020-03-26 11:00:00,57.5,68.5,33.0,27.0,29.736,0.00,-327.68,13.0,247.5,23.0, 
>> 
>> My belief is that this is Local Time. There is no GMT offset nor timezone 
>> indicator. These are the first records that I captured at this particular 
>> location and I'm pretty sure I started this station around 10 AM and not 3 
>> AM local (if the value shown were UTC). Maybe others could confirm the 
>> WeatherLink application behavior. This data came from a Davis Weather 
>> Monitor II. I hope this helps. 
>> 
>> 
>> On Wed, Jan 18, 2023, at 4:19 PM, gjr80 wrote: 
>> > Short answer is it depends. What is the format of the date-time data in 
>> > your resulting CSV file? Is it straight date and time but in GMT, eg 
>> > '24-Jan-2023 18:25' or does it have some sort of timezone indicator 
>> > embedded eg '24-Jan-2023 18:25 GMT' or is an epoch timestamp eg 
>> > '1674548700'? WeeWX does not recognise timezones but the python 
>> > datetime calls used may support GMT. I will need to look at your data 
>> > and the wee_import date-time parsing routines to see what is possible. 
>> > 
>> > Gary 
>> > 
>> > On Thursday, 19 January 2023 at 08:41:35 UTC+10 Wayne wrote: 
>> >> I am looking into the process for converting my Davis weather archive 
>> >> files to be imported into weewx. If I'm not mistaken, Davis WeatherLink 
>> >> stores the timestamps in local time in the .wlk files. Accordingly, the 
>> >> application wlkReader creates a csv file also in the same local time 
>> >> format. 
>> >> 
>> >> The import config file used by the utility wee-import provides an option 
>> >> raw_datetime_format for defining the text date/time format in the csv 
>> >> input file. Although I don't see it explicitly discussed in the Utilities 
>> >> Guide, is there a format code which can be use in this option which 
>> >> applies a UTC offset conversion to the supplied local time? If so can you 
>> >> give an example of its usage? Otherwise the only other option I see is to 
>> >> manually convert the times in the input csv files to UTC prior to 
>> >> importing. I'm sure I am not the first user to encounter this issue! My 
>> >> thanks in advance. 
>> > 
>> > -- 
>> > 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/15226f71-27a9--a715-1d8fdc747e09n%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/6ba7290e-a0a4-4b08-a57a-c58cf1a60376n%40googlegroups.com
>  
> .

-- 
You received this 

Re: [weewx-user] line gaps

[Tom Keffer]

Speaking of dumb, in retrospect, this seems like a dumb choice. It should
be at least optional.

The code was written about 10 years ago. I simply cannot remember why I
chose to always honor None values, despite any value of line_gap_fraction.

A PR would be welcome, should you wish to write one.

On Wed, Jan 18, 2023 at 4:55 PM Graham Eddy  wrote:

> this means line_gap_fraction relates only to interval gaps of whole
> records, not of column value gaps within successive records.
> hmm, inserting interpolated values to cover interval gaps in a column can
> only be done to past records - nope, i don’t want to go there...
> well, now i know - learn to love the ‘mark’ not the ‘line'.
> thanks
> *⊣GE⊢*
>
> On 19 Jan 2023, at 2:49 am, Tom Keffer  wrote:
>
> You're not doing something dumb. None values always mark line breaks.
>
> On Wed, Jan 18, 2023 at 6:30 AM Graham Eddy  wrote:
>
>
> --
> 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/D4BCD919-180F-45F4-AA01-845B49CB9A74%40geddy.au
> 
> .
>

-- 
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/CAPq0zEAoEWv3TdnHZ%2BJeWmbQV7t20-h2N9La3geer7eiLyavMA%40mail.gmail.com.

Re: [weewx-user] line gaps

[Graham Eddy]

this means line_gap_fraction relates only to interval gaps of whole records, 
not of column value gaps within successive records.
hmm, inserting interpolated values to cover interval gaps in a column can only 
be done to past records - nope, i don’t want to go there...
well, now i know - learn to love the ‘mark’ not the ‘line'.
thanks
⊣GE⊢

> On 19 Jan 2023, at 2:49 am, Tom Keffer  wrote:
> 
> You're not doing something dumb. None values always mark line breaks. 
> 
> On Wed, Jan 18, 2023 at 6:30 AM Graham Eddy  > wrote:
> 

-- 
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/D4BCD919-180F-45F4-AA01-845B49CB9A74%40geddy.au.

Re: [weewx-user] Re: Wee-Import UTC Conversion

[gjr80]

If that is local time then you are in luck and need do nothing special. If 
it's GMT/UTC then wee_import cannot handle it as is; it will be treated as 
local, there is no 'this_is_GMT' option in wee_import. Having looked at the 
wee_import date-time routines the only possible way to import a GMT/UTC 
type date-time is if the date-time data was formatted as an epoch 
timestamp. That being said, it should be fairly easy to implement a 
'this_is_GMT' option to interpret the date-time string as GMT/UTC rather 
than local time, there is sufficient support for GMT/UTC in the python date 
time library without the need to include timezone data. I'll add it to the 
list of wee_import ToDos.

Gary

On Thursday, 19 January 2023 at 10:15:11 UTC+10 Wayne wrote:

> Here is a sample of a CSV format of my data:
>
> Time,TempOut,TempIn,HumOut,HumIn,Baro,Rain,Rate,Wind,WindDir,Gust,GustDir
> 2020-03-26 
> 10:20:00,56.3,71.8,36.0,31.0,29.742,0.00,-327.68,10.0,270.0,22.0,
> 2020-03-26 
> 10:30:00,56.8,70.2,35.0,29.0,29.739,0.00,-327.68,12.0,270.0,23.0,
> 2020-03-26 
> 10:40:00,57.1,69.1,34.0,28.0,29.739,0.00,-327.68,12.0,247.5,22.0,
> 2020-03-26 
> 10:50:00,57.4,69.0,33.0,27.0,29.742,0.00,-327.68,11.0,247.5,21.0,
> 2020-03-26 
> 11:00:00,57.5,68.5,33.0,27.0,29.736,0.00,-327.68,13.0,247.5,23.0,
>
> My belief is that this is Local Time. There is no GMT offset nor timezone 
> indicator. These are the first records that I captured at this particular 
> location and I'm pretty sure I started this station around 10 AM and not 3 
> AM local (if the value shown were UTC). Maybe others could confirm the 
> WeatherLink application behavior. This data came from a Davis Weather 
> Monitor II. I hope this helps.
>
>
> On Wed, Jan 18, 2023, at 4:19 PM, gjr80 wrote:
> > Short answer is it depends. What is the format of the date-time data in 
> > your resulting CSV file? Is it straight date and time but in GMT, eg 
> > '24-Jan-2023 18:25' or does it have some sort of timezone indicator 
> > embedded eg '24-Jan-2023 18:25 GMT' or is an epoch timestamp eg 
> > '1674548700'? WeeWX does not recognise timezones but the python 
> > datetime calls used may support GMT. I will need to look at your data 
> > and the wee_import date-time parsing routines to see what is possible. 
> >
> > Gary
> >
> > On Thursday, 19 January 2023 at 08:41:35 UTC+10 Wayne wrote:
> >> I am looking into the process for converting my Davis weather archive 
> files to be imported into weewx. If I'm not mistaken, Davis WeatherLink 
> stores the timestamps in local time in the .wlk files. Accordingly, the 
> application wlkReader creates a csv file also in the same local time 
> format. 
> >> 
> >> The import config file used by the utility wee-import provides an 
> option raw_datetime_format for defining the text date/time format in the 
> csv input file. Although I don't see it explicitly discussed in the 
> Utilities Guide, is there a format code which can be use in this option 
> which applies a UTC offset conversion to the supplied local time? If so can 
> you give an example of its usage? Otherwise the only other option I see is 
> to manually convert the times in the input csv files to UTC prior to 
> importing. I'm sure I am not the first user to encounter this issue! My 
> thanks in advance. 
> >
> > -- 
> > 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/15226f71-27a9--a715-1d8fdc747e09n%40googlegroups.com
>  
> > <
> https://groups.google.com/d/msgid/weewx-user/15226f71-27a9--a715-1d8fdc747e09n%40googlegroups.com?utm_medium=email_source=footer
> >.
>

-- 
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/6ba7290e-a0a4-4b08-a57a-c58cf1a60376n%40googlegroups.com.

Re: [weewx-user] Re: Trouble viewing new data column(s)

[gjr80]

Ian,

When you say measurement group I presume you mean unit - 
part_per_million_per_cubic_meter is a unit whereas what you call a 
'measurement group' sounds to me to be more like a unit group, eg 
group_temperature or group_pressure which are groups that contain details 
of all of the units used for temperature and pressure respectively. Not 
trying to be pedantic, but it's important to know what part of the WeeWX 
unit system we are dealing with - there are lots of moving parts. I'll 
assume your question is about adding a new unit.

Same basic process but instead of manipulating weewx.units.obs_group_dict 
you might need to manipulate weewx.units.USUnits, weewx.units.MetricUnits 
and weewx.units.MetricWXUnits unit systems if your new unit will be the 
default unit used for one or more of the three unit systems. If it is not 
to be a default but rather another unit in an existing unit group then you 
would need to add it to the weewx.units.conversionDict so that WeeWX knows 
how to convert to and from your new unit in it's unit group. If your new 
unit is not a default unit in a unit system or is not a unit to be 
converted to/from then you essentially won't be using your new unit. You 
may also need to define default unit formatting and unit labels for your 
new unit in units.default_unit_format_dict and units.default_unit_label_dict 
respectively.

Ignoring the existing WeeWX group_concentration, let's say you want a new 
unit group, 'group_new_concentration' and it will be the only unit in that 
unit group (ie no unit conversions required). Default unit formatting will 
be 1 decimal place and the default unit label will be 'ppm/m3'. So putting 
that altogether you might end up with something like:

import weewx.units
# set the unit system units
weewx.units.USUnits['group_new_concentration'] = 
'part_per_million_per_cubic_meter'
weewx.units.MetricUnits['group_new_concentration'] = 
'part_per_million_per_cubic_meter'
weewx.units.MetricWXUnits['group_new_concentration'] = 
'part_per_million_per_cubic_meter'
# define default formatting
weewx.units.default_unit_format_dict['part_per_million_per_cubic_meter'] = 
'%.1f'
# define default unit label
weewx.units.default_unit_label_dict['part_per_million_per_cubic_meter'] = ' 
ppm/m3'

Let's say you want to add part_per_million_per_cubic_meter to the existing 
group_concentration unit group. part_per_million_per_cubic_meter will not 
be the default group_concentration unit in any of the unit systems. Same 
default formatting and unit label. For the sake of argument lets say to 
convert from microgram_per_meter_cubed to part_per_million_per_cubic_meter 
you divide by 10, ie 10 microgram_per_meter_cubed = 1 
part_per_million_per_cubic_meter (this is a nonsense of course, it is just 
to illustrate a point). In this case you might use:

 import weewx.units
# define conversion functions for group_concentration
weewx.units.conversionDict['microgram_per_meter_cubed'] = 
{'part_per_million_per_cubic_meter': lambda x: x / 10.0}
weewx.units.conversionDict['part_per_million_per_cubic_meter'] = 
{'microgram_per_meter_cubed': lambda x: x * 10.0}
# define default formatting
weewx.units.default_unit_format_dict['part_per_million_per_cubic_meter'] = 
'%.1f'
# define default unit label
weewx.units.default_unit_label_dict['part_per_million_per_cubic_meter'] = ' 
ppm/m3'

If you wanted to set part_per_million_per_meter_cubed as the the default US 
customary unit then you would add in the following line:

weewx.units.USUnits['group_concentration'] = 
'part_per_million_per_cubic_meter'

Finally, where to put the code. Of course you could put it in extensions.py 
as per my previous post. If you were using this as part of a driver or 
service you have written (and that is the only place it will be used, ie 
someone who does not have your driver will unlikely use these settings) 
then you can put it in your driver or service file with zero indent, that 
way the code will be read and executed when your driver or service is 
loaded. My preference is the latter if it is applicable.

Gary


On Wednesday, 18 January 2023 at 19:31:52 UTC+10 steep...@btinternet.com 
wrote:

> Gary,
> Follow up question from me in a similar vein. What is the correct way to 
> add a completely new measurement group to WeeWX, for example 
> part_per_million_per_cubic_meter?
> Ian
>
> Sent from my iPad.
>
> On 17 Jan 2023, at 05:20, gjr80  wrote:
>
> If you add a new observation to the database you need to tell WeeWX what 
> unit group it belongs to in order to be able to effectively use the 
> formatting and unit conversion capabilities of the WeeWX tag system in 
> reports. For example, if you add a field that is a pressure once WeeWX 
> knows the new field is a pressure WeeWX knows what default formatting to 
> apply, the correct unit label and you can use the formatting and unit 
> conversion aspects of the tag system to change the format/convert units in 
> a WeeWX report template. If WeeWX does not know 

Re: [weewx-user] Re: Wee-Import UTC Conversion

[Wayne]

Here is a sample of a CSV format of my data:

Time,TempOut,TempIn,HumOut,HumIn,Baro,Rain,Rate,Wind,WindDir,Gust,GustDir
2020-03-26 10:20:00,56.3,71.8,36.0,31.0,29.742,0.00,-327.68,10.0,270.0,22.0,
2020-03-26 10:30:00,56.8,70.2,35.0,29.0,29.739,0.00,-327.68,12.0,270.0,23.0,
2020-03-26 10:40:00,57.1,69.1,34.0,28.0,29.739,0.00,-327.68,12.0,247.5,22.0,
2020-03-26 10:50:00,57.4,69.0,33.0,27.0,29.742,0.00,-327.68,11.0,247.5,21.0,
2020-03-26 11:00:00,57.5,68.5,33.0,27.0,29.736,0.00,-327.68,13.0,247.5,23.0,

My belief is that this is Local Time.  There is no GMT offset nor timezone 
indicator.  These are the first records that I captured at this particular 
location and I'm pretty sure I started this station around 10 AM and not 3 AM 
local (if the value shown were UTC).  Maybe others could confirm the 
WeatherLink application behavior.  This data came from a Davis Weather Monitor 
II.  I hope this helps.


On Wed, Jan 18, 2023, at 4:19 PM, gjr80 wrote:
> Short answer is it depends. What is the format of the date-time data in 
> your resulting CSV file? Is it straight date and time but in GMT, eg 
> '24-Jan-2023 18:25' or does it have some sort of timezone indicator 
> embedded eg '24-Jan-2023 18:25 GMT' or is an epoch timestamp eg 
> '1674548700'? WeeWX does not recognise timezones but the python 
> datetime calls used may support GMT. I will need to look at your data 
> and the wee_import date-time parsing routines to see what is possible. 
>
> Gary
>
> On Thursday, 19 January 2023 at 08:41:35 UTC+10 Wayne wrote:
>> I am looking into the process for converting my Davis weather archive files 
>> to be imported into weewx. If I'm not mistaken, Davis WeatherLink stores the 
>> timestamps in local time in the .wlk files. Accordingly, the application 
>> wlkReader creates a csv file also in the same local time format. 
>> 
>> The import config file used by the utility wee-import provides an option 
>> raw_datetime_format for defining the text date/time format in the csv input 
>> file. Although I don't see it explicitly discussed in the Utilities Guide, 
>> is there a format code which can be use in this option which applies a UTC 
>> offset conversion to the supplied local time? If so can you give an example 
>> of its usage? Otherwise the only other option I see is to manually convert 
>> the times in the input csv files to UTC prior to importing. I'm sure I am 
>> not the first user to encounter this issue! My thanks in advance. 
>
> -- 
> 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/15226f71-27a9--a715-1d8fdc747e09n%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/1cdc23ee-6cd4-4852-b9e1-c4f864e33b1c%40app.fastmail.com.

[weewx-user] Re: Dedicated user account for weewx?

['Cameron D' via weewx-user]

There are notes on various aspects to this in the weewk wiki 


On Wednesday, 18 January 2023 at 9:23:29 am UTC+10 Wayne wrote:

> Hello - I am a new weewx user with medium proficiency in linux. Running on 
> a Raspberry Pi 4 installed from DEB package.
>
> Is there any benefit to creating a superuser account specifically for 
> weewx instead of running as "root"? It seems to me it would be a better 
> practice for using rsync to transfer files to an http server on another 
> machine. Or maybe it's not worth the effort. Comments??
>

-- 
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/d6825005-bee3-42b6-8e8a-6a81c62b02cen%40googlegroups.com.

[weewx-user] Re: Wee-Import UTC Conversion

[gjr80]

Short answer is it depends. What is the format of the date-time data in 
your resulting CSV file? Is it straight date and time but in GMT, eg 
'24-Jan-2023 18:25' or does it have some sort of timezone indicator 
embedded eg '24-Jan-2023 18:25 GMT' or is an epoch timestamp eg 
'1674548700'? WeeWX does not recognise timezones but the python datetime 
calls used may support GMT. I will need to look at your data and the 
wee_import date-time parsing routines to see what is possible. 

Gary

On Thursday, 19 January 2023 at 08:41:35 UTC+10 Wayne wrote:

> I am looking into the process for converting my Davis weather archive 
> files to be imported into weewx. If I'm not mistaken, Davis WeatherLink 
> stores the timestamps in local time in the .wlk files. Accordingly, the 
> application wlkReader creates a csv file also in the same local time 
> format. 
>
> The import config file used by the utility wee-import provides an option 
> raw_datetime_format for defining the text date/time format in the csv input 
> file. Although I don't see it explicitly discussed in the Utilities Guide, 
> is there a format code which can be use in this option which applies a UTC 
> offset conversion to the supplied local time? If so can you give an example 
> of its usage? Otherwise the only other option I see is to manually convert 
> the times in the input csv files to UTC prior to importing. I'm sure I am 
> not the first user to encounter this issue! My thanks in advance.
>

-- 
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/15226f71-27a9--a715-1d8fdc747e09n%40googlegroups.com.

[weewx-user] Wee-Import UTC Conversion

[Wayne]

I am looking into the process for converting my Davis weather archive files to 
be imported into weewx.   If I'm not mistaken, Davis WeatherLink stores the 
timestamps in local time in the .wlk files.  Accordingly, the application 
wlkReader creates a csv file also in the same local time format.  

The import config file used by the utility wee-import provides an option 
raw_datetime_format for defining the text date/time format in the csv input 
file.  Although I don't see it explicitly discussed in the Utilities Guide, is 
there a format code which can be use in this option which applies a UTC offset 
conversion to the supplied local time?  If so can you give an example of its 
usage?  Otherwise the only other option I see is to manually convert the times 
in the input csv files to UTC prior to importing.  I'm sure I am not the first 
user to encounter this issue!  My thanks in advance.

-- 
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/b56d61b5-a099-4d5c-8199-8c1f9b29dc75%40app.fastmail.com.

Re: [weewx-user] new install LOOP batch try #3; error: Unable to wake up Vantage console

[Tom Keffer]

On Wed, Jan 18, 2023 at 11:27 AM Brian Waligorski / N6RZR <
bgorsk...@gmail.com> wrote:

> Could it be RF from the Vantage console itself??
> I assume it xmits as well as receives data?
>

I really doubt it. There are thousands of them working uneventfully around
the world.

RF sources can be microwaves, railroads, industrial processes, etc. There
are lots of things in the 900 MHz+ band.

You implied that you're using a serial-to-usb converter. That's the most
likely culprit.

-tk

-- 
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/CAPq0zEAVE27kafZpDyJgjq6qYn5vVXpqVgFBL9%3D-5%2Bdtj0j9ag%40mail.gmail.com.

Re: [weewx-user] new install LOOP batch try #3; error: Unable to wake up Vantage console

[Brian Waligorski / N6RZR]

Could it be RF from the Vantage console itself??
I assume it xmits as well as receives data??

On Wednesday, January 18, 2023 at 6:56:14 AM UTC-8 tke...@gmail.com wrote:

> Then, as you suspected, it's likely a communications problem between the 
> logger and the computer. 
>
> Things to try:
>
> Is it located near a source of RF?
> Are you using a serial-to-usb converter? If so, try another one.
> Install ferrite chokes on the cable. 
>
> See the section *Tips on making a system reliable 
> .*
>
> On Wed, Jan 18, 2023 at 6:37 AM Brian Waligorski / N6RZR <
> bgor...@gmail.com> wrote:
>
>> Ver 4.9.1
>>
>> On Wednesday, January 18, 2023 at 6:27:12 AM UTC-8 tke...@gmail.com 
>> wrote:
>>
>>> Which version of WeeWX?
>>>
>>> -tk
>>>
>>> On Wed, Jan 18, 2023 at 6:13 AM Brian Waligorski / N6RZR <
>>> bgor...@gmail.com> wrote:
>>>
 New install on Inovato Quadra. Latest Weewx version installed using DEB 
 package on Debian-based systems, 
 System will run fine for hours, sometimes days. I'm suspecting comm 
 problem between console and weewx??  Any suggestions much appreciated.


 Jan 17 21:54:32 inovato weewx[1544] ERROR weewx.drivers.vantage: LOOP 
 batch try #1; error: Expected to read 99 chars; got 0 instead
 Jan 17 21:54:32 inovato weewx[1544] DEBUG weewx.drivers.vantage: Gentle 
 wake up of console successful
 Jan 17 21:55:01 inovato CRON[5105]: (root) CMD (command -v debian-sa1 > 
 /dev/null && debian-sa1 1 1)
 Jan 17 21:55:14 inovato weewx[1544] DEBUG weewx.drivers.vantage: 
 Getting archive packets since 2023-01-17 21:50:00 PST (1674021000)
 Jan 17 21:55:14 inovato weewx[1544] DEBUG weewx.drivers.vantage: Gentle 
 wake up of console successful
 Jan 17 21:55:14 inovato weewx[1544] DEBUG weewx.drivers.vantage: 
 Retrieving 1 page(s); starting index= 2
 Jan 17 21:55:15 inovato weewx[1544] INFO weewx.manager: Added record 
 2023-01-17 21:55:00 PST (1674021300) to database 'weewx.sdb'
 Jan 17 21:55:15 inovato weewx[1544] INFO weewx.manager: Added record 
 2023-01-17 21:55:00 PST (1674021300) to daily summary in 'weewx.sdb'
 Jan 17 21:55:15 inovato weewx[1544] DEBUG weewx.drivers.vantage: DMPAFT 
 complete: page timestamp 2023-01-09 00:40:00 PST (1673253600) less than 
 final timestamp 2023-01-17 21:55:00 PST (1674021300)
 Jan 17 21:55:15 inovato weewx[1544] DEBUG weewx.drivers.vantage: Catch 
 up complete.
 Jan 17 21:55:15 inovato weewx[1544] DEBUG weewx.reportengine: Running 
 reports for latest time in the database.
 Jan 17 21:55:15 inovato weewx[1544] DEBUG weewx.drivers.vantage: 
 Requesting 200 LOOP packets.
 Jan 17 21:55:15 inovato weewx[1544] DEBUG weewx.reportengine: Running 
 report 'SeasonsReport'
 Jan 17 21:55:15 inovato weewx[1544] DEBUG weewx.drivers.vantage: Gentle 
 wake up of console successful
 Jan 17 21:55:15 inovato weewx[1544] DEBUG weewx.reportengine: Found 
 configuration file /etc/weewx/skins/Seasons/skin.conf for report 
 'SeasonsReport'
 Jan 17 21:55:15 inovato weewx[1544] DEBUG weewx.cheetahgenerator: Using 
 search list ['weewx.cheetahgenerator.Almanac', 
 'weewx.cheetahgenerator.Current', 
 'weewx.cheetahgenerator.DisplayOptions', 'weewx.cheetahgenerator.Extras', 
 'weewx.cheetahgenerator.Gettext', 'weewx.cheetahgenerator.JSONHelpers', 
 'weewx.cheetahgenerator.PlotInfo', 'weewx.cheetahgenerator.SkinInfo', 
 'weewx.cheetahgenerator.Station', 'weewx.cheetahgenerator.Stats', 
 'weewx.cheetahgenerator.UnitInfo']
 Jan 17 21:55:15 inovato weewx[1544] DEBUG weewx.manager: Daily summary 
 version is 4.0
 Jan 17 21:55:15 inovato weewx[1544] INFO weewx.restx: Wunderground-PWS: 
 Published record 2023-01-17 21:55:00 PST (1674021300)
 Jan 17 21:55:18 inovato weewx[1544] INFO weewx.cheetahgenerator: 
 Generated 8 files for report SeasonsReport in 2.98 seconds
 Jan 17 21:55:18 inovato weewx[1544] DEBUG weewx.manager: Daily summary 
 version is 4.0
 Jan 17 21:55:19 inovato weewx[1544] INFO weewx.imagegenerator: 
 Generated 14 images for report SeasonsReport in 1.10 seconds
 Jan 17 21:55:19 inovato weewx[1544] INFO weewx.reportengine: Copied 0 
 files to /var/www/html/weewx
 Jan 17 21:55:19 inovato weewx[1544] DEBUG weewx.reportengine: Report 
 'SmartphoneReport' not enabled. Skipping.
 Jan 17 21:55:19 inovato weewx[1544] DEBUG weewx.reportengine: Report 
 'MobileReport' not enabled. Skipping.
 Jan 17 21:55:19 inovato weewx[1544] DEBUG weewx.reportengine: Report 
 'StandardReport' not enabled. Skipping.
 Jan 17 21:55:19 inovato weewx[1544] DEBUG weewx.reportengine: Report 
 'FTP' not enabled. Skipping.
 Jan 17 21:55:19 inovato weewx[1544] DEBUG weewx.reportengine: Report 
 'RSYNC' not enabled. Skipping.
 Jan 17 21:55:35 inovato weewx[1544] DEBUG 

Re: [weewx-user] new install LOOP batch try #3; error: Unable to wake up Vantage console

[Brian Waligorski / N6RZR]

Don't feel RF is the issue as the past few events were during a time that 
the radio's were off.
Happened again this morning after restarting... log entries were the same.
Any suggestions on a solid serial -USB converter chip-set to use??. 
I'll add another ferrite choke per the 
*Tips on making a system reliable 
.*


*Thanks,*

*Brian*


On Wednesday, January 18, 2023 at 6:56:14 AM UTC-8 tke...@gmail.com wrote:

> Then, as you suspected, it's likely a communications problem between the 
> logger and the computer. 
>
> Things to try:
>
> Is it located near a source of RF?
> Are you using a serial-to-usb converter? If so, try another one.
> Install ferrite chokes on the cable. 
>
> See the section *Tips on making a system reliable 
> .*
>
> On Wed, Jan 18, 2023 at 6:37 AM Brian Waligorski / N6RZR <
> bgor...@gmail.com> wrote:
>
>> Ver 4.9.1
>>
>> On Wednesday, January 18, 2023 at 6:27:12 AM UTC-8 tke...@gmail.com 
>> wrote:
>>
>>> Which version of WeeWX?
>>>
>>> -tk
>>>
>>> On Wed, Jan 18, 2023 at 6:13 AM Brian Waligorski / N6RZR <
>>> bgor...@gmail.com> wrote:
>>>
 New install on Inovato Quadra. Latest Weewx version installed using DEB 
 package on Debian-based systems, 
 System will run fine for hours, sometimes days. I'm suspecting comm 
 problem between console and weewx??  Any suggestions much appreciated.


 Jan 17 21:54:32 inovato weewx[1544] ERROR weewx.drivers.vantage: LOOP 
 batch try #1; error: Expected to read 99 chars; got 0 instead
 Jan 17 21:54:32 inovato weewx[1544] DEBUG weewx.drivers.vantage: Gentle 
 wake up of console successful
 Jan 17 21:55:01 inovato CRON[5105]: (root) CMD (command -v debian-sa1 > 
 /dev/null && debian-sa1 1 1)
 Jan 17 21:55:14 inovato weewx[1544] DEBUG weewx.drivers.vantage: 
 Getting archive packets since 2023-01-17 21:50:00 PST (1674021000)
 Jan 17 21:55:14 inovato weewx[1544] DEBUG weewx.drivers.vantage: Gentle 
 wake up of console successful
 Jan 17 21:55:14 inovato weewx[1544] DEBUG weewx.drivers.vantage: 
 Retrieving 1 page(s); starting index= 2
 Jan 17 21:55:15 inovato weewx[1544] INFO weewx.manager: Added record 
 2023-01-17 21:55:00 PST (1674021300) to database 'weewx.sdb'
 Jan 17 21:55:15 inovato weewx[1544] INFO weewx.manager: Added record 
 2023-01-17 21:55:00 PST (1674021300) to daily summary in 'weewx.sdb'
 Jan 17 21:55:15 inovato weewx[1544] DEBUG weewx.drivers.vantage: DMPAFT 
 complete: page timestamp 2023-01-09 00:40:00 PST (1673253600) less than 
 final timestamp 2023-01-17 21:55:00 PST (1674021300)
 Jan 17 21:55:15 inovato weewx[1544] DEBUG weewx.drivers.vantage: Catch 
 up complete.
 Jan 17 21:55:15 inovato weewx[1544] DEBUG weewx.reportengine: Running 
 reports for latest time in the database.
 Jan 17 21:55:15 inovato weewx[1544] DEBUG weewx.drivers.vantage: 
 Requesting 200 LOOP packets.
 Jan 17 21:55:15 inovato weewx[1544] DEBUG weewx.reportengine: Running 
 report 'SeasonsReport'
 Jan 17 21:55:15 inovato weewx[1544] DEBUG weewx.drivers.vantage: Gentle 
 wake up of console successful
 Jan 17 21:55:15 inovato weewx[1544] DEBUG weewx.reportengine: Found 
 configuration file /etc/weewx/skins/Seasons/skin.conf for report 
 'SeasonsReport'
 Jan 17 21:55:15 inovato weewx[1544] DEBUG weewx.cheetahgenerator: Using 
 search list ['weewx.cheetahgenerator.Almanac', 
 'weewx.cheetahgenerator.Current', 
 'weewx.cheetahgenerator.DisplayOptions', 'weewx.cheetahgenerator.Extras', 
 'weewx.cheetahgenerator.Gettext', 'weewx.cheetahgenerator.JSONHelpers', 
 'weewx.cheetahgenerator.PlotInfo', 'weewx.cheetahgenerator.SkinInfo', 
 'weewx.cheetahgenerator.Station', 'weewx.cheetahgenerator.Stats', 
 'weewx.cheetahgenerator.UnitInfo']
 Jan 17 21:55:15 inovato weewx[1544] DEBUG weewx.manager: Daily summary 
 version is 4.0
 Jan 17 21:55:15 inovato weewx[1544] INFO weewx.restx: Wunderground-PWS: 
 Published record 2023-01-17 21:55:00 PST (1674021300)
 Jan 17 21:55:18 inovato weewx[1544] INFO weewx.cheetahgenerator: 
 Generated 8 files for report SeasonsReport in 2.98 seconds
 Jan 17 21:55:18 inovato weewx[1544] DEBUG weewx.manager: Daily summary 
 version is 4.0
 Jan 17 21:55:19 inovato weewx[1544] INFO weewx.imagegenerator: 
 Generated 14 images for report SeasonsReport in 1.10 seconds
 Jan 17 21:55:19 inovato weewx[1544] INFO weewx.reportengine: Copied 0 
 files to /var/www/html/weewx
 Jan 17 21:55:19 inovato weewx[1544] DEBUG weewx.reportengine: Report 
 'SmartphoneReport' not enabled. Skipping.
 Jan 17 21:55:19 inovato weewx[1544] DEBUG weewx.reportengine: Report 
 'MobileReport' not enabled. Skipping.
 Jan 17 21:55:19 inovato weewx[1544] DEBUG weewx.reportengine: 

Re: [weewx-user] 4.9.1 issue

[Greg Troxel]

  [issues with 4.9.1 and VP2]

I was scared of this for a while so  helf off, and thought a trip report
might be helpful.

I recently took the plunge and udpated from 4.5ish and python 2.7 to
4.9.2a and python 3.10.  Specifically to

  commit 56337c58cfd5dd07c7510f2618d6de445a190945 (origin/master, origin/HEAD)
  Author: Tom Keffer 
  Date:   Sun Dec 25 10:32:16 2022 -0800

Which has the fix from upthread, I think.

I think I'm seeing only occasional VP2 errors, nothing unusual.  Serial
logger with Prolific USB/serial, RPI3, NetBSD.

-- 
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/rmi7cxjhoem.fsf%40s1.lexort.com.

Re: [weewx-user] new install LOOP batch try #3; error: Unable to wake up Vantage console

[Tom Keffer]

Then, as you suspected, it's likely a communications problem between the
logger and the computer.

Things to try:

Is it located near a source of RF?
Are you using a serial-to-usb converter? If so, try another one.
Install ferrite chokes on the cable.

See the section *Tips on making a system reliable
.*

On Wed, Jan 18, 2023 at 6:37 AM Brian Waligorski / N6RZR <
bgorsk...@gmail.com> wrote:

> Ver 4.9.1
>
> On Wednesday, January 18, 2023 at 6:27:12 AM UTC-8 tke...@gmail.com wrote:
>
>> Which version of WeeWX?
>>
>> -tk
>>
>> On Wed, Jan 18, 2023 at 6:13 AM Brian Waligorski / N6RZR <
>> bgor...@gmail.com> wrote:
>>
>>> New install on Inovato Quadra. Latest Weewx version installed using DEB
>>> package on Debian-based systems,
>>> System will run fine for hours, sometimes days. I'm suspecting comm
>>> problem between console and weewx??  Any suggestions much appreciated.
>>>
>>>
>>> Jan 17 21:54:32 inovato weewx[1544] ERROR weewx.drivers.vantage: LOOP
>>> batch try #1; error: Expected to read 99 chars; got 0 instead
>>> Jan 17 21:54:32 inovato weewx[1544] DEBUG weewx.drivers.vantage: Gentle
>>> wake up of console successful
>>> Jan 17 21:55:01 inovato CRON[5105]: (root) CMD (command -v debian-sa1 >
>>> /dev/null && debian-sa1 1 1)
>>> Jan 17 21:55:14 inovato weewx[1544] DEBUG weewx.drivers.vantage: Getting
>>> archive packets since 2023-01-17 21:50:00 PST (1674021000)
>>> Jan 17 21:55:14 inovato weewx[1544] DEBUG weewx.drivers.vantage: Gentle
>>> wake up of console successful
>>> Jan 17 21:55:14 inovato weewx[1544] DEBUG weewx.drivers.vantage:
>>> Retrieving 1 page(s); starting index= 2
>>> Jan 17 21:55:15 inovato weewx[1544] INFO weewx.manager: Added record
>>> 2023-01-17 21:55:00 PST (1674021300) to database 'weewx.sdb'
>>> Jan 17 21:55:15 inovato weewx[1544] INFO weewx.manager: Added record
>>> 2023-01-17 21:55:00 PST (1674021300) to daily summary in 'weewx.sdb'
>>> Jan 17 21:55:15 inovato weewx[1544] DEBUG weewx.drivers.vantage: DMPAFT
>>> complete: page timestamp 2023-01-09 00:40:00 PST (1673253600) less than
>>> final timestamp 2023-01-17 21:55:00 PST (1674021300)
>>> Jan 17 21:55:15 inovato weewx[1544] DEBUG weewx.drivers.vantage: Catch
>>> up complete.
>>> Jan 17 21:55:15 inovato weewx[1544] DEBUG weewx.reportengine: Running
>>> reports for latest time in the database.
>>> Jan 17 21:55:15 inovato weewx[1544] DEBUG weewx.drivers.vantage:
>>> Requesting 200 LOOP packets.
>>> Jan 17 21:55:15 inovato weewx[1544] DEBUG weewx.reportengine: Running
>>> report 'SeasonsReport'
>>> Jan 17 21:55:15 inovato weewx[1544] DEBUG weewx.drivers.vantage: Gentle
>>> wake up of console successful
>>> Jan 17 21:55:15 inovato weewx[1544] DEBUG weewx.reportengine: Found
>>> configuration file /etc/weewx/skins/Seasons/skin.conf for report
>>> 'SeasonsReport'
>>> Jan 17 21:55:15 inovato weewx[1544] DEBUG weewx.cheetahgenerator: Using
>>> search list ['weewx.cheetahgenerator.Almanac', 
>>> 'weewx.cheetahgenerator.Current',
>>> 'weewx.cheetahgenerator.DisplayOptions', 'weewx.cheetahgenerator.Extras',
>>> 'weewx.cheetahgenerator.Gettext', 'weewx.cheetahgenerator.JSONHelpers',
>>> 'weewx.cheetahgenerator.PlotInfo', 'weewx.cheetahgenerator.SkinInfo',
>>> 'weewx.cheetahgenerator.Station', 'weewx.cheetahgenerator.Stats',
>>> 'weewx.cheetahgenerator.UnitInfo']
>>> Jan 17 21:55:15 inovato weewx[1544] DEBUG weewx.manager: Daily summary
>>> version is 4.0
>>> Jan 17 21:55:15 inovato weewx[1544] INFO weewx.restx: Wunderground-PWS:
>>> Published record 2023-01-17 21:55:00 PST (1674021300)
>>> Jan 17 21:55:18 inovato weewx[1544] INFO weewx.cheetahgenerator:
>>> Generated 8 files for report SeasonsReport in 2.98 seconds
>>> Jan 17 21:55:18 inovato weewx[1544] DEBUG weewx.manager: Daily summary
>>> version is 4.0
>>> Jan 17 21:55:19 inovato weewx[1544] INFO weewx.imagegenerator: Generated
>>> 14 images for report SeasonsReport in 1.10 seconds
>>> Jan 17 21:55:19 inovato weewx[1544] INFO weewx.reportengine: Copied 0
>>> files to /var/www/html/weewx
>>> Jan 17 21:55:19 inovato weewx[1544] DEBUG weewx.reportengine: Report
>>> 'SmartphoneReport' not enabled. Skipping.
>>> Jan 17 21:55:19 inovato weewx[1544] DEBUG weewx.reportengine: Report
>>> 'MobileReport' not enabled. Skipping.
>>> Jan 17 21:55:19 inovato weewx[1544] DEBUG weewx.reportengine: Report
>>> 'StandardReport' not enabled. Skipping.
>>> Jan 17 21:55:19 inovato weewx[1544] DEBUG weewx.reportengine: Report
>>> 'FTP' not enabled. Skipping.
>>> Jan 17 21:55:19 inovato weewx[1544] DEBUG weewx.reportengine: Report
>>> 'RSYNC' not enabled. Skipping.
>>> Jan 17 21:55:35 inovato weewx[1544] DEBUG weewx.restx: CWOP: Attempt 1
>>> to cwop.aprs.net:14580. Connection error: timed out
>>> Jan 17 21:55:35 inovato weewx[1544] DEBUG weewx.restx: CWOP: Connected
>>> to server cwop.aprs.net:14580
>>> Jan 17 21:55:35 inovato weewx[1544] INFO weewx.restx: CWOP: Published
>>> record 2023-01-17 21:55:00 PST (1674021300)
>>> Jan 17 

Re: [weewx-user] new install LOOP batch try #3; error: Unable to wake up Vantage console

[Brian Waligorski / N6RZR]

Ver 4.9.1

On Wednesday, January 18, 2023 at 6:27:12 AM UTC-8 tke...@gmail.com wrote:

> Which version of WeeWX?
>
> -tk
>
> On Wed, Jan 18, 2023 at 6:13 AM Brian Waligorski / N6RZR <
> bgor...@gmail.com> wrote:
>
>> New install on Inovato Quadra. Latest Weewx version installed using DEB 
>> package on Debian-based systems, 
>> System will run fine for hours, sometimes days. I'm suspecting comm 
>> problem between console and weewx??  Any suggestions much appreciated.
>>
>>
>> Jan 17 21:54:32 inovato weewx[1544] ERROR weewx.drivers.vantage: LOOP 
>> batch try #1; error: Expected to read 99 chars; got 0 instead
>> Jan 17 21:54:32 inovato weewx[1544] DEBUG weewx.drivers.vantage: Gentle 
>> wake up of console successful
>> Jan 17 21:55:01 inovato CRON[5105]: (root) CMD (command -v debian-sa1 > 
>> /dev/null && debian-sa1 1 1)
>> Jan 17 21:55:14 inovato weewx[1544] DEBUG weewx.drivers.vantage: Getting 
>> archive packets since 2023-01-17 21:50:00 PST (1674021000)
>> Jan 17 21:55:14 inovato weewx[1544] DEBUG weewx.drivers.vantage: Gentle 
>> wake up of console successful
>> Jan 17 21:55:14 inovato weewx[1544] DEBUG weewx.drivers.vantage: 
>> Retrieving 1 page(s); starting index= 2
>> Jan 17 21:55:15 inovato weewx[1544] INFO weewx.manager: Added record 
>> 2023-01-17 21:55:00 PST (1674021300) to database 'weewx.sdb'
>> Jan 17 21:55:15 inovato weewx[1544] INFO weewx.manager: Added record 
>> 2023-01-17 21:55:00 PST (1674021300) to daily summary in 'weewx.sdb'
>> Jan 17 21:55:15 inovato weewx[1544] DEBUG weewx.drivers.vantage: DMPAFT 
>> complete: page timestamp 2023-01-09 00:40:00 PST (1673253600) less than 
>> final timestamp 2023-01-17 21:55:00 PST (1674021300)
>> Jan 17 21:55:15 inovato weewx[1544] DEBUG weewx.drivers.vantage: Catch up 
>> complete.
>> Jan 17 21:55:15 inovato weewx[1544] DEBUG weewx.reportengine: Running 
>> reports for latest time in the database.
>> Jan 17 21:55:15 inovato weewx[1544] DEBUG weewx.drivers.vantage: 
>> Requesting 200 LOOP packets.
>> Jan 17 21:55:15 inovato weewx[1544] DEBUG weewx.reportengine: Running 
>> report 'SeasonsReport'
>> Jan 17 21:55:15 inovato weewx[1544] DEBUG weewx.drivers.vantage: Gentle 
>> wake up of console successful
>> Jan 17 21:55:15 inovato weewx[1544] DEBUG weewx.reportengine: Found 
>> configuration file /etc/weewx/skins/Seasons/skin.conf for report 
>> 'SeasonsReport'
>> Jan 17 21:55:15 inovato weewx[1544] DEBUG weewx.cheetahgenerator: Using 
>> search list ['weewx.cheetahgenerator.Almanac', 
>> 'weewx.cheetahgenerator.Current', 
>> 'weewx.cheetahgenerator.DisplayOptions', 'weewx.cheetahgenerator.Extras', 
>> 'weewx.cheetahgenerator.Gettext', 'weewx.cheetahgenerator.JSONHelpers', 
>> 'weewx.cheetahgenerator.PlotInfo', 'weewx.cheetahgenerator.SkinInfo', 
>> 'weewx.cheetahgenerator.Station', 'weewx.cheetahgenerator.Stats', 
>> 'weewx.cheetahgenerator.UnitInfo']
>> Jan 17 21:55:15 inovato weewx[1544] DEBUG weewx.manager: Daily summary 
>> version is 4.0
>> Jan 17 21:55:15 inovato weewx[1544] INFO weewx.restx: Wunderground-PWS: 
>> Published record 2023-01-17 21:55:00 PST (1674021300)
>> Jan 17 21:55:18 inovato weewx[1544] INFO weewx.cheetahgenerator: 
>> Generated 8 files for report SeasonsReport in 2.98 seconds
>> Jan 17 21:55:18 inovato weewx[1544] DEBUG weewx.manager: Daily summary 
>> version is 4.0
>> Jan 17 21:55:19 inovato weewx[1544] INFO weewx.imagegenerator: Generated 
>> 14 images for report SeasonsReport in 1.10 seconds
>> Jan 17 21:55:19 inovato weewx[1544] INFO weewx.reportengine: Copied 0 
>> files to /var/www/html/weewx
>> Jan 17 21:55:19 inovato weewx[1544] DEBUG weewx.reportengine: Report 
>> 'SmartphoneReport' not enabled. Skipping.
>> Jan 17 21:55:19 inovato weewx[1544] DEBUG weewx.reportengine: Report 
>> 'MobileReport' not enabled. Skipping.
>> Jan 17 21:55:19 inovato weewx[1544] DEBUG weewx.reportengine: Report 
>> 'StandardReport' not enabled. Skipping.
>> Jan 17 21:55:19 inovato weewx[1544] DEBUG weewx.reportengine: Report 
>> 'FTP' not enabled. Skipping.
>> Jan 17 21:55:19 inovato weewx[1544] DEBUG weewx.reportengine: Report 
>> 'RSYNC' not enabled. Skipping.
>> Jan 17 21:55:35 inovato weewx[1544] DEBUG weewx.restx: CWOP: Attempt 1 to 
>> cwop.aprs.net:14580. Connection error: timed out
>> Jan 17 21:55:35 inovato weewx[1544] DEBUG weewx.restx: CWOP: Connected to 
>> server cwop.aprs.net:14580
>> Jan 17 21:55:35 inovato weewx[1544] INFO weewx.restx: CWOP: Published 
>> record 2023-01-17 21:55:00 PST (1674021300)
>> Jan 17 21:59:32 inovato weewx[1544] ERROR weewx.drivers.vantage: LOOP 
>> batch try #1; error: Expected to read 99 chars; got 0 instead
>> Jan 17 21:59:36 inovato weewx[1544] DEBUG weewx.drivers.vantage: Wakeup 
>> retry #1 failed: Expected to read 2 chars; got 0 instead
>> Jan 17 21:59:42 inovato weewx[1544] DEBUG weewx.drivers.vantage: Wakeup 
>> retry #2 failed: Expected to read 2 chars; got 0 instead
>> Jan 17 21:59:47 inovato weewx[1544] DEBUG weewx.drivers.vantage: Wakeup 
>> retry #3 failed: Expected to read 2 

Re: [weewx-user] new install LOOP batch try #3; error: Unable to wake up Vantage console

[Tom Keffer]

Which version of WeeWX?

-tk

On Wed, Jan 18, 2023 at 6:13 AM Brian Waligorski / N6RZR <
bgorsk...@gmail.com> wrote:

> New install on Inovato Quadra. Latest Weewx version installed using DEB
> package on Debian-based systems,
> System will run fine for hours, sometimes days. I'm suspecting comm
> problem between console and weewx??  Any suggestions much appreciated.
>
>
> Jan 17 21:54:32 inovato weewx[1544] ERROR weewx.drivers.vantage: LOOP
> batch try #1; error: Expected to read 99 chars; got 0 instead
> Jan 17 21:54:32 inovato weewx[1544] DEBUG weewx.drivers.vantage: Gentle
> wake up of console successful
> Jan 17 21:55:01 inovato CRON[5105]: (root) CMD (command -v debian-sa1 >
> /dev/null && debian-sa1 1 1)
> Jan 17 21:55:14 inovato weewx[1544] DEBUG weewx.drivers.vantage: Getting
> archive packets since 2023-01-17 21:50:00 PST (1674021000)
> Jan 17 21:55:14 inovato weewx[1544] DEBUG weewx.drivers.vantage: Gentle
> wake up of console successful
> Jan 17 21:55:14 inovato weewx[1544] DEBUG weewx.drivers.vantage:
> Retrieving 1 page(s); starting index= 2
> Jan 17 21:55:15 inovato weewx[1544] INFO weewx.manager: Added record
> 2023-01-17 21:55:00 PST (1674021300) to database 'weewx.sdb'
> Jan 17 21:55:15 inovato weewx[1544] INFO weewx.manager: Added record
> 2023-01-17 21:55:00 PST (1674021300) to daily summary in 'weewx.sdb'
> Jan 17 21:55:15 inovato weewx[1544] DEBUG weewx.drivers.vantage: DMPAFT
> complete: page timestamp 2023-01-09 00:40:00 PST (1673253600) less than
> final timestamp 2023-01-17 21:55:00 PST (1674021300)
> Jan 17 21:55:15 inovato weewx[1544] DEBUG weewx.drivers.vantage: Catch up
> complete.
> Jan 17 21:55:15 inovato weewx[1544] DEBUG weewx.reportengine: Running
> reports for latest time in the database.
> Jan 17 21:55:15 inovato weewx[1544] DEBUG weewx.drivers.vantage:
> Requesting 200 LOOP packets.
> Jan 17 21:55:15 inovato weewx[1544] DEBUG weewx.reportengine: Running
> report 'SeasonsReport'
> Jan 17 21:55:15 inovato weewx[1544] DEBUG weewx.drivers.vantage: Gentle
> wake up of console successful
> Jan 17 21:55:15 inovato weewx[1544] DEBUG weewx.reportengine: Found
> configuration file /etc/weewx/skins/Seasons/skin.conf for report
> 'SeasonsReport'
> Jan 17 21:55:15 inovato weewx[1544] DEBUG weewx.cheetahgenerator: Using
> search list ['weewx.cheetahgenerator.Almanac', 
> 'weewx.cheetahgenerator.Current',
> 'weewx.cheetahgenerator.DisplayOptions', 'weewx.cheetahgenerator.Extras',
> 'weewx.cheetahgenerator.Gettext', 'weewx.cheetahgenerator.JSONHelpers',
> 'weewx.cheetahgenerator.PlotInfo', 'weewx.cheetahgenerator.SkinInfo',
> 'weewx.cheetahgenerator.Station', 'weewx.cheetahgenerator.Stats',
> 'weewx.cheetahgenerator.UnitInfo']
> Jan 17 21:55:15 inovato weewx[1544] DEBUG weewx.manager: Daily summary
> version is 4.0
> Jan 17 21:55:15 inovato weewx[1544] INFO weewx.restx: Wunderground-PWS:
> Published record 2023-01-17 21:55:00 PST (1674021300)
> Jan 17 21:55:18 inovato weewx[1544] INFO weewx.cheetahgenerator: Generated
> 8 files for report SeasonsReport in 2.98 seconds
> Jan 17 21:55:18 inovato weewx[1544] DEBUG weewx.manager: Daily summary
> version is 4.0
> Jan 17 21:55:19 inovato weewx[1544] INFO weewx.imagegenerator: Generated
> 14 images for report SeasonsReport in 1.10 seconds
> Jan 17 21:55:19 inovato weewx[1544] INFO weewx.reportengine: Copied 0
> files to /var/www/html/weewx
> Jan 17 21:55:19 inovato weewx[1544] DEBUG weewx.reportengine: Report
> 'SmartphoneReport' not enabled. Skipping.
> Jan 17 21:55:19 inovato weewx[1544] DEBUG weewx.reportengine: Report
> 'MobileReport' not enabled. Skipping.
> Jan 17 21:55:19 inovato weewx[1544] DEBUG weewx.reportengine: Report
> 'StandardReport' not enabled. Skipping.
> Jan 17 21:55:19 inovato weewx[1544] DEBUG weewx.reportengine: Report 'FTP'
> not enabled. Skipping.
> Jan 17 21:55:19 inovato weewx[1544] DEBUG weewx.reportengine: Report
> 'RSYNC' not enabled. Skipping.
> Jan 17 21:55:35 inovato weewx[1544] DEBUG weewx.restx: CWOP: Attempt 1 to
> cwop.aprs.net:14580. Connection error: timed out
> Jan 17 21:55:35 inovato weewx[1544] DEBUG weewx.restx: CWOP: Connected to
> server cwop.aprs.net:14580
> Jan 17 21:55:35 inovato weewx[1544] INFO weewx.restx: CWOP: Published
> record 2023-01-17 21:55:00 PST (1674021300)
> Jan 17 21:59:32 inovato weewx[1544] ERROR weewx.drivers.vantage: LOOP
> batch try #1; error: Expected to read 99 chars; got 0 instead
> Jan 17 21:59:36 inovato weewx[1544] DEBUG weewx.drivers.vantage: Wakeup
> retry #1 failed: Expected to read 2 chars; got 0 instead
> Jan 17 21:59:42 inovato weewx[1544] DEBUG weewx.drivers.vantage: Wakeup
> retry #2 failed: Expected to read 2 chars; got 0 instead
> Jan 17 21:59:47 inovato weewx[1544] DEBUG weewx.drivers.vantage: Wakeup
> retry #3 failed: Expected to read 2 chars; got 0 instead
> Jan 17 21:59:52 inovato weewx[1544] DEBUG weewx.drivers.vantage: Wakeup
> retry #4 failed: Expected to read 2 chars; got 0 instead
> Jan 17 21:59:53 inovato weewx[1544] ERROR weewx.drivers.vantage: 

[weewx-user] new install LOOP batch try #3; error: Unable to wake up Vantage console

[Brian Waligorski / N6RZR]

New install on Inovato Quadra. Latest Weewx version installed using DEB 
package on Debian-based systems, 
System will run fine for hours, sometimes days. I'm suspecting comm problem 
between console and weewx??  Any suggestions much appreciated.


Jan 17 21:54:32 inovato weewx[1544] ERROR weewx.drivers.vantage: LOOP batch 
try #1; error: Expected to read 99 chars; got 0 instead
Jan 17 21:54:32 inovato weewx[1544] DEBUG weewx.drivers.vantage: Gentle 
wake up of console successful
Jan 17 21:55:01 inovato CRON[5105]: (root) CMD (command -v debian-sa1 > 
/dev/null && debian-sa1 1 1)
Jan 17 21:55:14 inovato weewx[1544] DEBUG weewx.drivers.vantage: Getting 
archive packets since 2023-01-17 21:50:00 PST (1674021000)
Jan 17 21:55:14 inovato weewx[1544] DEBUG weewx.drivers.vantage: Gentle 
wake up of console successful
Jan 17 21:55:14 inovato weewx[1544] DEBUG weewx.drivers.vantage: Retrieving 
1 page(s); starting index= 2
Jan 17 21:55:15 inovato weewx[1544] INFO weewx.manager: Added record 
2023-01-17 21:55:00 PST (1674021300) to database 'weewx.sdb'
Jan 17 21:55:15 inovato weewx[1544] INFO weewx.manager: Added record 
2023-01-17 21:55:00 PST (1674021300) to daily summary in 'weewx.sdb'
Jan 17 21:55:15 inovato weewx[1544] DEBUG weewx.drivers.vantage: DMPAFT 
complete: page timestamp 2023-01-09 00:40:00 PST (1673253600) less than 
final timestamp 2023-01-17 21:55:00 PST (1674021300)
Jan 17 21:55:15 inovato weewx[1544] DEBUG weewx.drivers.vantage: Catch up 
complete.
Jan 17 21:55:15 inovato weewx[1544] DEBUG weewx.reportengine: Running 
reports for latest time in the database.
Jan 17 21:55:15 inovato weewx[1544] DEBUG weewx.drivers.vantage: Requesting 
200 LOOP packets.
Jan 17 21:55:15 inovato weewx[1544] DEBUG weewx.reportengine: Running 
report 'SeasonsReport'
Jan 17 21:55:15 inovato weewx[1544] DEBUG weewx.drivers.vantage: Gentle 
wake up of console successful
Jan 17 21:55:15 inovato weewx[1544] DEBUG weewx.reportengine: Found 
configuration file /etc/weewx/skins/Seasons/skin.conf for report 
'SeasonsReport'
Jan 17 21:55:15 inovato weewx[1544] DEBUG weewx.cheetahgenerator: Using 
search list ['weewx.cheetahgenerator.Almanac', 
'weewx.cheetahgenerator.Current', 
'weewx.cheetahgenerator.DisplayOptions', 'weewx.cheetahgenerator.Extras', 
'weewx.cheetahgenerator.Gettext', 'weewx.cheetahgenerator.JSONHelpers', 
'weewx.cheetahgenerator.PlotInfo', 'weewx.cheetahgenerator.SkinInfo', 
'weewx.cheetahgenerator.Station', 'weewx.cheetahgenerator.Stats', 
'weewx.cheetahgenerator.UnitInfo']
Jan 17 21:55:15 inovato weewx[1544] DEBUG weewx.manager: Daily summary 
version is 4.0
Jan 17 21:55:15 inovato weewx[1544] INFO weewx.restx: Wunderground-PWS: 
Published record 2023-01-17 21:55:00 PST (1674021300)
Jan 17 21:55:18 inovato weewx[1544] INFO weewx.cheetahgenerator: Generated 
8 files for report SeasonsReport in 2.98 seconds
Jan 17 21:55:18 inovato weewx[1544] DEBUG weewx.manager: Daily summary 
version is 4.0
Jan 17 21:55:19 inovato weewx[1544] INFO weewx.imagegenerator: Generated 14 
images for report SeasonsReport in 1.10 seconds
Jan 17 21:55:19 inovato weewx[1544] INFO weewx.reportengine: Copied 0 files 
to /var/www/html/weewx
Jan 17 21:55:19 inovato weewx[1544] DEBUG weewx.reportengine: Report 
'SmartphoneReport' not enabled. Skipping.
Jan 17 21:55:19 inovato weewx[1544] DEBUG weewx.reportengine: Report 
'MobileReport' not enabled. Skipping.
Jan 17 21:55:19 inovato weewx[1544] DEBUG weewx.reportengine: Report 
'StandardReport' not enabled. Skipping.
Jan 17 21:55:19 inovato weewx[1544] DEBUG weewx.reportengine: Report 'FTP' 
not enabled. Skipping.
Jan 17 21:55:19 inovato weewx[1544] DEBUG weewx.reportengine: Report 
'RSYNC' not enabled. Skipping.
Jan 17 21:55:35 inovato weewx[1544] DEBUG weewx.restx: CWOP: Attempt 1 to 
cwop.aprs.net:14580. Connection error: timed out
Jan 17 21:55:35 inovato weewx[1544] DEBUG weewx.restx: CWOP: Connected to 
server cwop.aprs.net:14580
Jan 17 21:55:35 inovato weewx[1544] INFO weewx.restx: CWOP: Published 
record 2023-01-17 21:55:00 PST (1674021300)
Jan 17 21:59:32 inovato weewx[1544] ERROR weewx.drivers.vantage: LOOP batch 
try #1; error: Expected to read 99 chars; got 0 instead
Jan 17 21:59:36 inovato weewx[1544] DEBUG weewx.drivers.vantage: Wakeup 
retry #1 failed: Expected to read 2 chars; got 0 instead
Jan 17 21:59:42 inovato weewx[1544] DEBUG weewx.drivers.vantage: Wakeup 
retry #2 failed: Expected to read 2 chars; got 0 instead
Jan 17 21:59:47 inovato weewx[1544] DEBUG weewx.drivers.vantage: Wakeup 
retry #3 failed: Expected to read 2 chars; got 0 instead
Jan 17 21:59:52 inovato weewx[1544] DEBUG weewx.drivers.vantage: Wakeup 
retry #4 failed: Expected to read 2 chars; got 0 instead
Jan 17 21:59:53 inovato weewx[1544] ERROR weewx.drivers.vantage: Unable to 
wake up Vantage console
Jan 17 21:59:53 inovato weewx[1544] ERROR weewx.drivers.vantage: LOOP batch 
try #2; error: Unable to wake up Vantage console
Jan 17 21:59:57 inovato weewx[1544] DEBUG weewx.drivers.vantage: Wakeup 
retry #1 

Re: [weewx-user] Dedicated user account for weewx?

[cric...@pobox.com]

Aside from communicating with your weather station, the only other non-root 
hang up was where
the PID file was being written.  That's an easy command line option to 
write it somewhere the user
does have permissions.  I don't let systemd manage the process, so I don't 
need the pid file any
particular place.
Chris
On Tuesday, January 17, 2023 at 4:37:36 PM UTC-7 Greg Troxel wrote:

>
> Wayne  writes:
>
> > Hello - I am a new weewx user with medium proficiency in linux. Running 
> on a Raspberry Pi 4 installed from DEB package.
> >
> > Is there any benefit to creating a superuser account specifically for
> > weewx instead of running as "root"? It seems to me it would be a
> > better practice for using rsync to transfer files to an http server on
> > another machine. Or maybe it's not worth the effort. Comments??
>
> Yes, it's basically always better to have a uid (and to a lesser extend
> gid) for each daemon and to grant them access to as little as possible.
>
> weewx doesn't need to be root, in general. It just needs rw access to
> devices that access weather stations, at least in my case.
>
> https://en.wikipedia.org/wiki/Principle_of_least_privilege
>

-- 
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/ffcf6767-2322-4e75-8109-3c5bd1548204n%40googlegroups.com.

Re: [weewx-user] line gaps

[Tom Keffer]

Things to check:

You didn't show the relevant part of skin.conf, but are you trying to do a
bar plot? Option line_gap_fraction does not work for a bar plot. Try a line
plot. See Issue #818 .

What's in the database for this time period?

As always, the log.




On Tue, Jan 17, 2023 at 9:15 PM Graham Eddy  wrote:

> i am getting a sequence of points plotted rather than a line showing.
>
> line_type = solid
> line_gap_fraction = 0.3
>
> the points are 20 mins apart. 20min/24hrs = 0.013 so i expect the points
> to be joined.
> i have tried line_gap_fraction 0.9 and - just to be thorough - 1.0 and
> (being silly) 10.0 - with no change.
> any ideas how to ‘join the dots’?
> google is my friend but he didn’t help this time.
> cheers
>
> [image: dayriverlevel2.png]
> *⊣GE⊢*
>
> --
> 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/5E209B62-AD8B-4F6E-8219-EC2778D16E35%40geddy.au
> 
> .
>

-- 
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/CAPq0zEDFJij4E8_htbjFrGYZo6%2BZipA14L-9umf7so9GHWQeZQ%40mail.gmail.com.

Re: [weewx-user] Re: Trouble viewing new data column(s)

['Ian Millard' via weewx-user]

Gary,Follow up question from me in a similar vein. What is the correct way to add a completely new measurement group to WeeWX, for example part_per_million_per_cubic_meter?IanSent from my iPad.On 17 Jan 2023, at 05:20, gjr80  wrote:If you add a new observation to the database you need to tell WeeWX what unit group it belongs to in order to be able to effectively use the formatting and unit conversion capabilities of the WeeWX tag system in reports. For example, if you add a field that is a pressure once WeeWX knows the new field is a pressure WeeWX knows what default formatting to apply, the correct unit label and you can use the formatting and unit conversion aspects of the tag system to change the format/convert units in a WeeWX report template. If WeeWX does not know what unit group the observation belongs to you just get the raw value from the database (which is typically a float with many decimal places - ie what you are seeing now).There are a number of ways to assign an observation to a unit group. In your case the easiest approach is to add a few lines of code to /home/weewx/bin/user/extensions.py (or /usr/share/weewx/user/extensions.py if you installed WeeWX as a package). Try adding the following to the bottom of extensions.py:import weewx.unitsweewx.units.obs_group_dict['waterTemp'] = 'group_temperature'weewx.units.obs_group_dict['tideHeight'] = 'group_length'(group_temperature was the obvious choice for waterTemp; tideHeight could be group_length, group_altitude, group_rain or group_distance. The deciding factor here is the available units for each group - if you look at the Units appendix to the Customisation Guide you will see what I mean)You will need to restart WeeWX for the changes to take effect. The extensions.py code is run at WeeWX startup and the above lines will make the appropriate unit group assignments for your new fields. You should now be able to use tags based on waterTemp and tideHeight in your reports. You will find some further info on assigning unit groups in the Customising units and unit groups section of the Customisation Guide. You will also find information on the WeeWX tag system in the Tags section of the Customisation Guide.A couple of notes about units.For the WeeWX tag system to correctly and consistently display observation values and units you need to ensure the data you are adding to the database is in the correct units. How you do this depends on how you are inserting data into the database. If you are using a WeeWX service to augment loop packets (the preferred approach) then your service needs to take cognisance of the unit system (ie WeeWX field usUnits) of the loop packet being augmented and add waterTemp and tideHeight to the loop packet using the appropriate units for the unit group each observation belongs to for the unit system used by the loop packet. For example, if the loop packet uses US customary units (ie usUnits = 0) then waterTemp would need to be in Fahrenheit and tideHeight in inches. Once you do this WeeWX takes care of everything else. You will find information on the unit systems, unit groups and units used by WeeWX in the Units appendix to the Customisation Guide.If you are directly inserting data in the WeeWX database (not the preferred approach) then it is up to you to ensure that the values are inserted using units applicable to the database unit system and the unit group used for each observation.Apologies for the long response but the WeeWX tag/unit/formatting system has a lot of moving parts and you need to have them all correctly configured or you will have problems.GaryOn Tuesday, 17 January 2023 at 07:19:24 UTC+10 ja...@runser.net wrote:Incremental progress. As described above but with the addition of a restart I have data in the statistics section but still N/A for Water Temp in "Current Conditions". Further, the data in statistics is formatted as "00.00" instead of the hoped-for "00.00 

°F". I've walked through the template and inc files but still can't find the right building blocks. I even tried changing the waterTemp column from a double to a double(4,2) but am still getting all the extra zeros.On Monday, January 16, 2023 at 2:16:12 PM UTC-5 James Runser wrote:I'm trying to integrate a home-built tide and temperature monitor into weewx (configured and working without issue with an Acurite Atlas). I'm using a MySQL DB and tried simply inserting my data (waterTemp, tideHeight) into archive. I use current timestamp, usUnits and 10 for the required interval values and let the remaining columns default to null ( except - duh - waterTemp and tideHeight). The data are written without issue but I'm never seeing the results in the Seasons report - I chose waterTemp as the learning value since the skin.conf already had a reference to water temp.My thinking is that my data is not returned by the report engine - based, perhaps - on timestamp? Is there a better way to hook net new data into the flow? I do in fact see the waterTemp