[weewx-user] Re: Generating same images over and over

[gjr80]

Thanks but that log extract is not much use at all. We need to see a log 
extract showing the WeeWX startup and processing at least a couple of 
report cycles. I suggest you go to the link in my first post next work 
through the steps under ‘To get a good, useful log’ and post the resulting 
log.

Gary
On Thursday, 11 November 2021 at 16:04:44 UTC+10 jens...@gmail.com wrote:

> Nov 11 07:00:17 jjk-F5RL weewx[10103]: cheetahgenerator: Generated 3 files 
> for report StandardReport in 0.07 seconds
> Nov 11 07:00:18 jjk-F5RL weewx[10103]: imagegenerator: Generated 24 images 
> for StandardReport in 1.69 seconds
> Nov 11 07:00:18 jjk-F5RL weewx[10103]: copygenerator: copied 14 files to 
> /home/weewx/public_html
> Nov 11 07:00:20 jjk-F5RL weewx[10103]: ftpgenerator: ftp'd 41 files in 
> 2.05 seconds
>
> Tried to stop and start weewx, delete all files from public_html - no 
> change.
>
> torsdag den 11. november 2021 kl. 06.33.16 UTC+1 skrev gjr80:
>
>> I suggest we start with the log 
>> , you 
>> don’t need an error in the log to diagnose a problem
>>
>> Gary
>>
>> On Thursday, 11 November 2021 at 15:19:03 UTC+10 jens...@gmail.com wrote:
>>
>>> Suddenly, 11 days ago, weewx keeps generating same images over and over. 
>>> No error in syslog, wee_device says: weewx.WakeupError: Unable to wake up 
>>> Vantage console.
>>> I tried to unplug the console, no change, even switched to another 
>>> console, no change.
>>> ?
>>>
>>

-- 
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/3dcde019-48ca-4695-a3b1-0d97e7338327n%40googlegroups.com.

[weewx-user] Re: Generating same images over and over

[Jens-Jørgen Kjærgaard]

Nov 11 07:00:17 jjk-F5RL weewx[10103]: cheetahgenerator: Generated 3 files 
for report StandardReport in 0.07 seconds
Nov 11 07:00:18 jjk-F5RL weewx[10103]: imagegenerator: Generated 24 images 
for StandardReport in 1.69 seconds
Nov 11 07:00:18 jjk-F5RL weewx[10103]: copygenerator: copied 14 files to 
/home/weewx/public_html
Nov 11 07:00:20 jjk-F5RL weewx[10103]: ftpgenerator: ftp'd 41 files in 2.05 
seconds

Tried to stop and start weewx, delete all files from public_html - no 
change.

torsdag den 11. november 2021 kl. 06.33.16 UTC+1 skrev gjr80:

> I suggest we start with the log 
> , you 
> don’t need an error in the log to diagnose a problem
>
> Gary
>
> On Thursday, 11 November 2021 at 15:19:03 UTC+10 jens...@gmail.com wrote:
>
>> Suddenly, 11 days ago, weewx keeps generating same images over and over. 
>> No error in syslog, wee_device says: weewx.WakeupError: Unable to wake up 
>> Vantage console.
>> I tried to unplug the console, no change, even switched to another 
>> console, no change.
>> ?
>>
>

-- 
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/864d7f74-2bde-48b8-9b8a-9932cea7734en%40googlegroups.com.

[weewx-user] Re: Generating same images over and over

[gjr80]

I suggest we start with the log 
, you 
don’t need an error in the log to diagnose a problem

Gary

On Thursday, 11 November 2021 at 15:19:03 UTC+10 jens...@gmail.com wrote:

> Suddenly, 11 days ago, weewx keeps generating same images over and over. 
> No error in syslog, wee_device says: weewx.WakeupError: Unable to wake up 
> Vantage console.
> I tried to unplug the console, no change, even switched to another 
> console, no change.
> ?
>

-- 
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/2cfb089d-cf88-4127-8a7e-7ddbd312ff3cn%40googlegroups.com.

[weewx-user] Generating same images over and over

[Jens-Jørgen Kjærgaard]

Suddenly, 11 days ago, weewx keeps generating same images over and over. No 
error in syslog, wee_device says: weewx.WakeupError: Unable to wake up 
Vantage console.
I tried to unplug the console, no change, even switched to another console, 
no change.
?

-- 
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/31200b03-9960-469a-88dc-63c242c2763cn%40googlegroups.com.

[weewx-user] Re: Error Uploading to WOW

[gjr80]

Hi,

Edit weewx.conf and set debug = 2. Save weewx.conf and restart WeeWX. You 
should now see the full URL used to upload to any of the restful services 
in the log. If you want any further help post a log extract from when you 
restarted WeeWX through until a couple of report cycles have completed. 
It’s import to capture the full WeeWX startup as well as the report cycles.

Gary
On Thursday, 11 November 2021 at 11:13:45 UTC+10 tim.u...@gmail.com wrote:

> Hello everyone, I'm having trouble uploading to WOW.  I created an account 
> got my username and created a password, but this keeps happening: 
>
> Nov 10 19:10:18 weewx weewx[3837] DEBUG weewx.restx: WOW: Failed upload 
> attempt 1: HTTP Error 400: Bad Request
> Nov 10 19:10:24 weewx weewx[3837] DEBUG weewx.restx: WOW: Failed upload 
> attempt 2: HTTP Error 400: Bad Request
> Nov 10 19:10:30 weewx weewx[3837] DEBUG weewx.restx: WOW: Failed upload 
> attempt 3: HTTP Error 400: Bad Request
> Nov 10 19:10:30 weewx weewx[3837] ERROR weewx.restx: WOW: Failed to 
> publish record 2021-11-10 19:10:00 CST (1636593000): Failed upload after 3 
> tries
>
> Not sure what would be causing a bad request, is there anyway to log the 
> full response?
>
> Thanks!
> Tim
>

-- 
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/e317e679-2d40-4d3c-8d5d-0dfc7b9fbc03n%40googlegroups.com.

[weewx-user] Error Uploading to WOW

[Tim Urberg]

Hello everyone, I'm having trouble uploading to WOW.  I created an account 
got my username and created a password, but this keeps happening: 

Nov 10 19:10:18 weewx weewx[3837] DEBUG weewx.restx: WOW: Failed upload 
attempt 1: HTTP Error 400: Bad Request
Nov 10 19:10:24 weewx weewx[3837] DEBUG weewx.restx: WOW: Failed upload 
attempt 2: HTTP Error 400: Bad Request
Nov 10 19:10:30 weewx weewx[3837] DEBUG weewx.restx: WOW: Failed upload 
attempt 3: HTTP Error 400: Bad Request
Nov 10 19:10:30 weewx weewx[3837] ERROR weewx.restx: WOW: Failed to publish 
record 2021-11-10 19:10:00 CST (1636593000): Failed upload after 3 tries

Not sure what would be causing a bad request, is there anyway to log the 
full response?

Thanks!
Tim

-- 
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/55a500e3-b72c-42f6-adee-6e386564a04dn%40googlegroups.com.

Re: [weewx-user] Bug in skin localization / units

[Tom Keffer]

Thought about it, but got bogged down in the implementation and never
finished it. The problem is that not all skins offer all languages, yet
wee_config needs to work when skins other than the Seasons skin are
activated.

Not impossible, just messy and I may get back to it. In the meantime, that
feature didn't make the cut.

On Wed, Nov 10, 2021 at 4:12 PM itec  wrote:

> Thanks to you for fixing it immediately!
> It would be nice to modify the configuration wizard (wee_config
> --reconfigure) also.
> Do you think it makes sense to prompt user for language instead of (in
> addition to) prompting for units?
>
> itec
>
> Il giorno giovedì 11 novembre 2021 alle 00:31:58 UTC+1 tke...@gmail.com
> ha scritto:
>
>> Yes, that is a bug! Thanks for finding it.
>>
>> Fixed in commit f1afbab
>> 
>> .
>>
>> On Wed, Nov 10, 2021 at 3:10 PM itec  wrote:
>>
>>> I used the default settings during installation, changing units to
>>> metric only.
>>> This is my entire section [StdReport]
>>>
>>>
>>> ##
>>>
>>> #   This section specifies what reports, using which skins, to generate.
>>>
>>> [StdReport]
>>>
>>> # Which language to use. Not all skins support all languages.
>>> # You can override this for individual skins.
>>> lang = en
>>>
>>> # Which unit system to use. Choices are 'us', 'metric', or
>>> 'metricwx'.
>>> # You can override this for individual skins.
>>> unit_system = metric
>>>
>>> # Where the skins reside, relative to WEEWX_ROOT
>>> SKIN_ROOT = skins
>>>
>>> # Where the generated reports should go, relative to WEEWX_ROOT
>>> HTML_ROOT = public_html
>>>
>>> # The database binding indicates which data should be used in
>>> reports.
>>> data_binding = wx_binding
>>>
>>> # Whether to log a successful operation
>>> log_success = True
>>>
>>> # Whether to log an unsuccessful operation
>>> log_failure = True
>>>
>>> # Each of the following subsections defines a report that will be
>>> run.
>>> # See the customizing guide to change the units, plot types and line
>>> # colors, modify the fonts, display additional sensor data, and other
>>> # customizations. Many of those changes can be made here by
>>> overriding
>>> # parameters, or by modifying templates within the skin itself.
>>>
>>> [[SeasonsReport]]
>>> # The SeasonsReport uses the 'Seasons' skin, which contains the
>>> # images, templates and plots for the report.
>>> skin = Seasons
>>> enable = true
>>>
>>> [[SmartphoneReport]]
>>> # The SmartphoneReport uses the 'Smartphone' skin, and the
>>> images and
>>> # files are placed in a dedicated subdirectory.
>>> skin = Smartphone
>>> enable = false
>>> HTML_ROOT = public_html/smartphone
>>>
>>> [[MobileReport]]
>>> # The MobileReport uses the 'Mobile' skin, and the images and
>>> files
>>> # are placed in a dedicated subdirectory.
>>> skin = Mobile
>>> enable = false
>>> HTML_ROOT = public_html/mobile
>>>
>>> [[StandardReport]]
>>> # This is the old "Standard" skin. By default, it is not enabled.
>>> skin = Standard
>>> enable = false
>>>
>>> [[FTP]]
>>> # FTP'ing the results to a webserver is treated as just another
>>> report,
>>> # albeit one with an unusual report generator!
>>> skin = Ftp
>>>
>>> # If you wish to use FTP, set "enable" to "true", then
>>> # fill out the next four lines.
>>> # Use quotes around passwords to guard against parsing errors.
>>> enable = false
>>> user = replace_me
>>> password = replace_me
>>> server = replace_me# The ftp server name, e.g,
>>> www.myserver.org
>>> path = replace_me# The destination directory, e.g., /weather
>>>
>>> # Set to True for an FTP over TLS (FTPS) connection. Not all
>>> servers
>>> # support this.
>>> secure_ftp = False
>>>
>>> # To upload files from something other than what HTML_ROOT is set
>>> # to above, specify a different HTML_ROOT here.
>>> #HTML_ROOT = public_html
>>>
>>> # Most FTP servers use port 21
>>> port = 21
>>>
>>> # Set to 1 to use passive mode, zero for active mode
>>> passive = 1
>>>
>>> [[RSYNC]]
>>> # rsync'ing to a webserver is treated as just another report
>>> skin = Rsync
>>>
>>> # If you wish to use rsync, you must configure passwordless ssh
>>> using
>>> # public/private key authentication from the user account that
>>> weewx
>>> # runs to the user account on the remote machine where the files
>>> # will be copied.
>>> #
>>> # If you wish to use rsync, set "enable" to "true", then
>>> # fill o

Re: [weewx-user] Bug in skin localization / units

[itec]

Thanks to you for fixing it immediately!
It would be nice to modify the configuration wizard (wee_config 
--reconfigure) also.
Do you think it makes sense to prompt user for language instead of (in 
addition to) prompting for units?

itec 

Il giorno giovedì 11 novembre 2021 alle 00:31:58 UTC+1 tke...@gmail.com ha 
scritto:

> Yes, that is a bug! Thanks for finding it.
>
> Fixed in commit f1afbab 
> 
> .
>
> On Wed, Nov 10, 2021 at 3:10 PM itec  wrote:
>
>> I used the default settings during installation, changing units to metric 
>> only.
>> This is my entire section [StdReport]
>>
>>
>> ##
>>
>> #   This section specifies what reports, using which skins, to generate.
>>
>> [StdReport]
>> 
>> # Which language to use. Not all skins support all languages.
>> # You can override this for individual skins.
>> lang = en
>> 
>> # Which unit system to use. Choices are 'us', 'metric', or 'metricwx'.
>> # You can override this for individual skins.
>> unit_system = metric
>> 
>> # Where the skins reside, relative to WEEWX_ROOT
>> SKIN_ROOT = skins
>> 
>> # Where the generated reports should go, relative to WEEWX_ROOT
>> HTML_ROOT = public_html
>> 
>> # The database binding indicates which data should be used in reports.
>> data_binding = wx_binding
>> 
>> # Whether to log a successful operation
>> log_success = True
>> 
>> # Whether to log an unsuccessful operation
>> log_failure = True
>> 
>> # Each of the following subsections defines a report that will be run.
>> # See the customizing guide to change the units, plot types and line
>> # colors, modify the fonts, display additional sensor data, and other
>> # customizations. Many of those changes can be made here by overriding
>> # parameters, or by modifying templates within the skin itself.
>> 
>> [[SeasonsReport]]
>> # The SeasonsReport uses the 'Seasons' skin, which contains the
>> # images, templates and plots for the report.
>> skin = Seasons
>> enable = true
>> 
>> [[SmartphoneReport]]
>> # The SmartphoneReport uses the 'Smartphone' skin, and the images 
>> and
>> # files are placed in a dedicated subdirectory.
>> skin = Smartphone
>> enable = false
>> HTML_ROOT = public_html/smartphone
>> 
>> [[MobileReport]]
>> # The MobileReport uses the 'Mobile' skin, and the images and 
>> files
>> # are placed in a dedicated subdirectory.
>> skin = Mobile
>> enable = false
>> HTML_ROOT = public_html/mobile
>> 
>> [[StandardReport]]
>> # This is the old "Standard" skin. By default, it is not enabled.
>> skin = Standard
>> enable = false
>> 
>> [[FTP]]
>> # FTP'ing the results to a webserver is treated as just another 
>> report,
>> # albeit one with an unusual report generator!
>> skin = Ftp
>> 
>> # If you wish to use FTP, set "enable" to "true", then
>> # fill out the next four lines.
>> # Use quotes around passwords to guard against parsing errors.
>> enable = false
>> user = replace_me
>> password = replace_me
>> server = replace_me# The ftp server name, e.g, 
>> www.myserver.org
>> path = replace_me# The destination directory, e.g., /weather
>> 
>> # Set to True for an FTP over TLS (FTPS) connection. Not all 
>> servers
>> # support this.
>> secure_ftp = False
>> 
>> # To upload files from something other than what HTML_ROOT is set
>> # to above, specify a different HTML_ROOT here.
>> #HTML_ROOT = public_html
>> 
>> # Most FTP servers use port 21
>> port = 21
>> 
>> # Set to 1 to use passive mode, zero for active mode
>> passive = 1
>> 
>> [[RSYNC]]
>> # rsync'ing to a webserver is treated as just another report
>> skin = Rsync
>> 
>> # If you wish to use rsync, you must configure passwordless ssh 
>> using
>> # public/private key authentication from the user account that 
>> weewx
>> # runs to the user account on the remote machine where the files
>> # will be copied.
>> #
>> # If you wish to use rsync, set "enable" to "true", then
>> # fill out server, user, and path.
>> # The server should appear in your .ssh/config file.
>> # The user is the username used in the identity file.
>> # The path is the destination directory, such as 
>> /var/www/html/weather.
>> # Be sure that the user has write permissions on the destination!
>> enable = false
>> server = replace_me
>> us

Re: [weewx-user] Wind Missing from Database

[Tom Keffer]

How a database schema is specified changed in V4.0. The newer
wview_extended schema uses the new way, the older wview schema uses the old
way. My hunch is that you're mixing the new way and the old way.

Take a look in the [[wx_binding]] section of weewx.conf. You want either:

# Old way, using wview schema
[DataBindings]

[[wx_binding]]
# The database must match one of the sections in [Databases].
# This is likely to be the only option you would want to change.
database = archive_sqlite
# The name of the table within the database
table_name = archive
# The manager handles aggregation of data for historical summaries
manager = weewx.wxmanager.WXDaySummaryManager
# The schema defines the structure of the database.
# It is *only* used when the database is created.
schema = schemas.wview.schema


# New way, using wview_extended schema
[DataBindings]

[[wx_binding]]
# The database must match one of the sections in [Databases].
# This is likely to be the only option you would want to change.
database = archive_sqlite
# The name of the table within the database
table_name = archive
# The manager handles aggregation of data for historical summaries
manager = weewx.manager.DaySummaryManager
# The schema defines the structure of the database.
# It is *only* used when the database is created.
schema = schemas.wview_extended.schema

If you're using the older wview schema, make sure the manager is set to
weewx.wxmanager.WXDaySummaryManager. Then, use wee_database to drop, then
rebuild the daily summaries.

-tk




On Wed, Nov 10, 2021 at 3:45 PM William Reinhardt 
wrote:

> Hello all,
>
> Back in July, I successfully added a couple new observation types
> ("appTemp" and "cloudbase") to my SQLite database by following these
> instructions:
>
> https://github.com/poblabs/weewx-belchertown/wiki/Adding-a-new-observation-type-to-the-WeeWX-database
>
> Inexplicably, the "archive_day_wind" table was missing afterwards! The
> other wind-related tables ("archive_day_windDir", "archive_day_windGust,"
> etc.) are still in the database, just the "wind" table is missing. I'll
> post the Debug errors from the syslog at the end of this post. Let me know
> if you need more. It also shows up on my weather station website at
> www.woodvilleweather.com. In the "Weather Records Snapshot" section, the
> Average and Highest Wind data show as $day.wind.avg, $month.wind.avg,
> etc., with similar errors since July 2021 in the Reports page. I verified
> the absence of the table using a SQLite database viewer to open old
> database backups from before and after I added the observations in July.
>
> My question is: how can I regain the wind table? Is there a wee_database
> command to add this table? Add a new observation type and call it "wind"?
> Copy-paste from a backup database and rebuild the daily data? My weather
> station stores no data so I can't get it from there. It's been a busy
> summer and I'm now just getting time to play with this and get my WEEWX box
> working 100% again. Thanks for any ideas.
>
> -Bill
>
> *Debug info:*
> Nov 10 18:30:30 WX_WS1 weewx[29868] DEBUG weewx.cheetahgenerator:
> Unrecognized: $day.wind.max
> Nov 10 18:30:30 WX_WS1 weewx[29868] DEBUG weewx.cheetahgenerator:
> Unrecognized: $day.wind.maxtime
> Nov 10 18:30:30 WX_WS1 weewx[29868] DEBUG weewx.cheetahgenerator:
> Unrecognized: $day.wind.gustdir
> Nov 10 18:30:30 WX_WS1 weewx[29868] DEBUG weewx.cheetahgenerator:
> Unrecognized: $day.wind.avg
> Nov 10 18:30:30 WX_WS1 weewx[29868] DEBUG weewx.cheetahgenerator:
> Unrecognized: $day.wind.vecdir
> Nov 10 18:30:30 WX_WS1 weewx[29868] DEBUG weewx.cheetahgenerator:
> Unrecognized: $day.wind.vecavg
> Nov 10 18:30:30 WX_WS1 weewx[29868] DEBUG weewx.cheetahgenerator:
> Unrecognized: $day.wind.rms
> Nov 10 18:30:30 WX_WS1 weewx[29868] DEBUG weewx.cheetahgenerator:
> Unrecognized: $week.wind.max
> Nov 10 18:30:30 WX_WS1 weewx[29868] DEBUG weewx.cheetahgenerator:
> Unrecognized: $week.wind.maxtime
> Nov 10 18:30:30 WX_WS1 weewx[29868] DEBUG weewx.cheetahgenerator:
> Unrecognized: $week.wind.gustdir
> Nov 10 18:30:30 WX_WS1 weewx[29868] DEBUG weewx.cheetahgenerator:
> Unrecognized: $week.wind.avg
> Nov 10 18:30:30 WX_WS1 weewx[29868] DEBUG weewx.cheetahgenerator:
> Unrecognized: $week.wind.vecdir
> Nov 10 18:30:30 WX_WS1 weewx[29868] DEBUG weewx.cheetahgenerator:
> Unrecognized: $week.wind.vecavg
> Nov 10 18:30:30 WX_WS1 weewx[29868] DEBUG weewx.cheetahgenerator:
> Unrecognized: $week.wind.rms
> Nov 10 18:30:31 WX_WS1 weewx[29868] DEBUG weewx.cheetahgenerator:
> Unrecognized: $month.wind.max
> Nov 10 18:30:31 WX_WS1 weewx[29868] DEBUG weewx.cheetahgenerator:
> Unrecognized: $month.wind.maxtime
> Nov 10 18:30:31 WX_WS1 weewx[29868] DEBUG weewx.cheetahgenerator:
> Unrecognized: $month.wind.gustdir
> Nov 10 18:30:31 WX_WS1 weewx[29868] DEBUG weewx.cheetahgenera

[weewx-user] Re: Wind Missing from Database

[vince]

You might try to run wee_database and --drop-daily to drop all the summary 
tables and then run it again --rebuild-daily option to rebuild tham (after 
backing up your existing database someplace safe !!!)

If you run the wview_extended schema that is the new default for new 
installations in v4 you will get the two elements you added without any 
manual intervention required.   After you get your summary tables rebuilt 
ok you might want to just switch to the new extended schema.

-- 
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/31248e8d-cb96-4121-b719-02fd5366967bn%40googlegroups.com.

[weewx-user] Wind Missing from Database

[William Reinhardt]

Hello all,

Back in July, I successfully added a couple new observation types 
("appTemp" and "cloudbase") to my SQLite database by following these 
instructions:
https://github.com/poblabs/weewx-belchertown/wiki/Adding-a-new-observation-type-to-the-WeeWX-database

Inexplicably, the "archive_day_wind" table was missing afterwards! The 
other wind-related tables ("archive_day_windDir", "archive_day_windGust," 
etc.) are still in the database, just the "wind" table is missing. I'll 
post the Debug errors from the syslog at the end of this post. Let me know 
if you need more. It also shows up on my weather station website at 
www.woodvilleweather.com. In the "Weather Records Snapshot" section, the 
Average and Highest Wind data show as $day.wind.avg, $month.wind.avg, etc., 
with similar errors since July 2021 in the Reports page. I verified the 
absence of the table using a SQLite database viewer to open old database 
backups from before and after I added the observations in July.

My question is: how can I regain the wind table? Is there a wee_database 
command to add this table? Add a new observation type and call it "wind"? 
Copy-paste from a backup database and rebuild the daily data? My weather 
station stores no data so I can't get it from there. It's been a busy 
summer and I'm now just getting time to play with this and get my WEEWX box 
working 100% again. Thanks for any ideas.

-Bill

*Debug info:*
Nov 10 18:30:30 WX_WS1 weewx[29868] DEBUG weewx.cheetahgenerator: 
Unrecognized: $day.wind.max
Nov 10 18:30:30 WX_WS1 weewx[29868] DEBUG weewx.cheetahgenerator: 
Unrecognized: $day.wind.maxtime
Nov 10 18:30:30 WX_WS1 weewx[29868] DEBUG weewx.cheetahgenerator: 
Unrecognized: $day.wind.gustdir
Nov 10 18:30:30 WX_WS1 weewx[29868] DEBUG weewx.cheetahgenerator: 
Unrecognized: $day.wind.avg
Nov 10 18:30:30 WX_WS1 weewx[29868] DEBUG weewx.cheetahgenerator: 
Unrecognized: $day.wind.vecdir
Nov 10 18:30:30 WX_WS1 weewx[29868] DEBUG weewx.cheetahgenerator: 
Unrecognized: $day.wind.vecavg
Nov 10 18:30:30 WX_WS1 weewx[29868] DEBUG weewx.cheetahgenerator: 
Unrecognized: $day.wind.rms
Nov 10 18:30:30 WX_WS1 weewx[29868] DEBUG weewx.cheetahgenerator: 
Unrecognized: $week.wind.max
Nov 10 18:30:30 WX_WS1 weewx[29868] DEBUG weewx.cheetahgenerator: 
Unrecognized: $week.wind.maxtime
Nov 10 18:30:30 WX_WS1 weewx[29868] DEBUG weewx.cheetahgenerator: 
Unrecognized: $week.wind.gustdir
Nov 10 18:30:30 WX_WS1 weewx[29868] DEBUG weewx.cheetahgenerator: 
Unrecognized: $week.wind.avg
Nov 10 18:30:30 WX_WS1 weewx[29868] DEBUG weewx.cheetahgenerator: 
Unrecognized: $week.wind.vecdir
Nov 10 18:30:30 WX_WS1 weewx[29868] DEBUG weewx.cheetahgenerator: 
Unrecognized: $week.wind.vecavg
Nov 10 18:30:30 WX_WS1 weewx[29868] DEBUG weewx.cheetahgenerator: 
Unrecognized: $week.wind.rms
Nov 10 18:30:31 WX_WS1 weewx[29868] DEBUG weewx.cheetahgenerator: 
Unrecognized: $month.wind.max
Nov 10 18:30:31 WX_WS1 weewx[29868] DEBUG weewx.cheetahgenerator: 
Unrecognized: $month.wind.maxtime
Nov 10 18:30:31 WX_WS1 weewx[29868] DEBUG weewx.cheetahgenerator: 
Unrecognized: $month.wind.gustdir
Nov 10 18:30:31 WX_WS1 weewx[29868] DEBUG weewx.cheetahgenerator: 
Unrecognized: $month.wind.avg
Nov 10 18:30:31 WX_WS1 weewx[29868] DEBUG weewx.cheetahgenerator: 
Unrecognized: $month.wind.vecdir
Nov 10 18:30:31 WX_WS1 weewx[29868] DEBUG weewx.cheetahgenerator: 
Unrecognized: $month.wind.vecavg
Nov 10 18:30:31 WX_WS1 weewx[29868] DEBUG weewx.cheetahgenerator: 
Unrecognized: $month.wind.rms
Nov 10 18:30:31 WX_WS1 weewx[29868] DEBUG weewx.cheetahgenerator: 
Unrecognized: $year.wind.max
Nov 10 18:30:31 WX_WS1 weewx[29868] DEBUG weewx.cheetahgenerator: 
Unrecognized: $year.wind.maxtime
Nov 10 18:30:31 WX_WS1 weewx[29868] DEBUG weewx.cheetahgenerator: 
Unrecognized: $year.wind.gustdir
Nov 10 18:30:31 WX_WS1 weewx[29868] DEBUG weewx.cheetahgenerator: 
Unrecognized: $year.wind.avg
Nov 10 18:30:31 WX_WS1 weewx[29868] DEBUG weewx.cheetahgenerator: 
Unrecognized: $year.wind.vecdir
Nov 10 18:30:31 WX_WS1 weewx[29868] DEBUG weewx.cheetahgenerator: 
Unrecognized: $year.wind.vecavg
Nov 10 18:30:31 WX_WS1 weewx[29868] DEBUG weewx.cheetahgenerator: 
Unrecognized: $year.wind.rms

-- 
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/766f2e09-9b9f-4604-a939-a406e31b1639n%40googlegroups.com.

Re: [weewx-user] Bug in skin localization / units

[Tom Keffer]

Yes, that is a bug! Thanks for finding it.

Fixed in commit f1afbab

.

On Wed, Nov 10, 2021 at 3:10 PM itec  wrote:

> I used the default settings during installation, changing units to metric
> only.
> This is my entire section [StdReport]
>
>
> ##
>
> #   This section specifies what reports, using which skins, to generate.
>
> [StdReport]
>
> # Which language to use. Not all skins support all languages.
> # You can override this for individual skins.
> lang = en
>
> # Which unit system to use. Choices are 'us', 'metric', or 'metricwx'.
> # You can override this for individual skins.
> unit_system = metric
>
> # Where the skins reside, relative to WEEWX_ROOT
> SKIN_ROOT = skins
>
> # Where the generated reports should go, relative to WEEWX_ROOT
> HTML_ROOT = public_html
>
> # The database binding indicates which data should be used in reports.
> data_binding = wx_binding
>
> # Whether to log a successful operation
> log_success = True
>
> # Whether to log an unsuccessful operation
> log_failure = True
>
> # Each of the following subsections defines a report that will be run.
> # See the customizing guide to change the units, plot types and line
> # colors, modify the fonts, display additional sensor data, and other
> # customizations. Many of those changes can be made here by overriding
> # parameters, or by modifying templates within the skin itself.
>
> [[SeasonsReport]]
> # The SeasonsReport uses the 'Seasons' skin, which contains the
> # images, templates and plots for the report.
> skin = Seasons
> enable = true
>
> [[SmartphoneReport]]
> # The SmartphoneReport uses the 'Smartphone' skin, and the images
> and
> # files are placed in a dedicated subdirectory.
> skin = Smartphone
> enable = false
> HTML_ROOT = public_html/smartphone
>
> [[MobileReport]]
> # The MobileReport uses the 'Mobile' skin, and the images and files
> # are placed in a dedicated subdirectory.
> skin = Mobile
> enable = false
> HTML_ROOT = public_html/mobile
>
> [[StandardReport]]
> # This is the old "Standard" skin. By default, it is not enabled.
> skin = Standard
> enable = false
>
> [[FTP]]
> # FTP'ing the results to a webserver is treated as just another
> report,
> # albeit one with an unusual report generator!
> skin = Ftp
>
> # If you wish to use FTP, set "enable" to "true", then
> # fill out the next four lines.
> # Use quotes around passwords to guard against parsing errors.
> enable = false
> user = replace_me
> password = replace_me
> server = replace_me# The ftp server name, e.g,
> www.myserver.org
> path = replace_me# The destination directory, e.g., /weather
>
> # Set to True for an FTP over TLS (FTPS) connection. Not all
> servers
> # support this.
> secure_ftp = False
>
> # To upload files from something other than what HTML_ROOT is set
> # to above, specify a different HTML_ROOT here.
> #HTML_ROOT = public_html
>
> # Most FTP servers use port 21
> port = 21
>
> # Set to 1 to use passive mode, zero for active mode
> passive = 1
>
> [[RSYNC]]
> # rsync'ing to a webserver is treated as just another report
> skin = Rsync
>
> # If you wish to use rsync, you must configure passwordless ssh
> using
> # public/private key authentication from the user account that
> weewx
> # runs to the user account on the remote machine where the files
> # will be copied.
> #
> # If you wish to use rsync, set "enable" to "true", then
> # fill out server, user, and path.
> # The server should appear in your .ssh/config file.
> # The user is the username used in the identity file.
> # The path is the destination directory, such as
> /var/www/html/weather.
> # Be sure that the user has write permissions on the destination!
> enable = false
> server = replace_me
> user = replace_me
> path = replace_me
>
> # To upload files from something other than what HTML_ROOT is set
> # to above, specify a different HTML_ROOT here.
> #HTML_ROOT = public_html
>
> # Rsync can be configured to remove files from the remote server if
> # they don't exist under HTML_ROOT locally. USE WITH CAUTION: if
> you
> # make a mistake in the remote path, you could could
> unintentionally
> # cause unrelated files to be deleted. Set to 1 to enable remote
> file
> # deletion, zero to allow files to accumulate 

Re: [weewx-user] Bug in skin localization / units

[itec]

I used the default settings during installation, changing units to metric 
only.
This is my entire section [StdReport]

##

#   This section specifies what reports, using which skins, to generate.

[StdReport]

# Which language to use. Not all skins support all languages.
# You can override this for individual skins.
lang = en

# Which unit system to use. Choices are 'us', 'metric', or 'metricwx'.
# You can override this for individual skins.
unit_system = metric

# Where the skins reside, relative to WEEWX_ROOT
SKIN_ROOT = skins

# Where the generated reports should go, relative to WEEWX_ROOT
HTML_ROOT = public_html

# The database binding indicates which data should be used in reports.
data_binding = wx_binding

# Whether to log a successful operation
log_success = True

# Whether to log an unsuccessful operation
log_failure = True

# Each of the following subsections defines a report that will be run.
# See the customizing guide to change the units, plot types and line
# colors, modify the fonts, display additional sensor data, and other
# customizations. Many of those changes can be made here by overriding
# parameters, or by modifying templates within the skin itself.

[[SeasonsReport]]
# The SeasonsReport uses the 'Seasons' skin, which contains the
# images, templates and plots for the report.
skin = Seasons
enable = true

[[SmartphoneReport]]
# The SmartphoneReport uses the 'Smartphone' skin, and the images 
and
# files are placed in a dedicated subdirectory.
skin = Smartphone
enable = false
HTML_ROOT = public_html/smartphone

[[MobileReport]]
# The MobileReport uses the 'Mobile' skin, and the images and files
# are placed in a dedicated subdirectory.
skin = Mobile
enable = false
HTML_ROOT = public_html/mobile

[[StandardReport]]
# This is the old "Standard" skin. By default, it is not enabled.
skin = Standard
enable = false

[[FTP]]
# FTP'ing the results to a webserver is treated as just another 
report,
# albeit one with an unusual report generator!
skin = Ftp

# If you wish to use FTP, set "enable" to "true", then
# fill out the next four lines.
# Use quotes around passwords to guard against parsing errors.
enable = false
user = replace_me
password = replace_me
server = replace_me# The ftp server name, e.g, www.myserver.org
path = replace_me# The destination directory, e.g., /weather

# Set to True for an FTP over TLS (FTPS) connection. Not all servers
# support this.
secure_ftp = False

# To upload files from something other than what HTML_ROOT is set
# to above, specify a different HTML_ROOT here.
#HTML_ROOT = public_html

# Most FTP servers use port 21
port = 21

# Set to 1 to use passive mode, zero for active mode
passive = 1

[[RSYNC]]
# rsync'ing to a webserver is treated as just another report
skin = Rsync

# If you wish to use rsync, you must configure passwordless ssh 
using
# public/private key authentication from the user account that weewx
# runs to the user account on the remote machine where the files
# will be copied.
#
# If you wish to use rsync, set "enable" to "true", then
# fill out server, user, and path.
# The server should appear in your .ssh/config file.
# The user is the username used in the identity file.
# The path is the destination directory, such as 
/var/www/html/weather.
# Be sure that the user has write permissions on the destination!
enable = false
server = replace_me
user = replace_me
path = replace_me

# To upload files from something other than what HTML_ROOT is set
# to above, specify a different HTML_ROOT here.
#HTML_ROOT = public_html

# Rsync can be configured to remove files from the remote server if
# they don't exist under HTML_ROOT locally. USE WITH CAUTION: if you
# make a mistake in the remote path, you could could unintentionally
# cause unrelated files to be deleted. Set to 1 to enable remote 
file
# deletion, zero to allow files to accumulate remotely.
delete = 0

# Options in the [[Defaults]] section below will apply to all reports.
# What follows are a few of the more popular options you may want to
# uncomment, then change.
[[Defaults]]

[[[Units]]]
# Uncommenting the following section freq

Re: [weewx-user] Re: WeeWx database differs from system log

[Tom Keffer]

If you follow Gary's advice, make sure you set debug=1 in weewx.conf before
restarting weewx.

On Wed, Nov 10, 2021 at 12:25 PM gjr80  wrote:

> Hi,
>
> Rather than a filtered log extract, how about restarting WeeWX, letting it
> run for at least half an hour and then post an (entire) log extract
> covering all of the WeeWX startup through until the half hour elapsed. Much
> better to see a full log extract that shows everything that is going on.
> The WeeWX startup part of the log will show us key WeeWX config info.
>
> Gary
>
> On Thursday, 11 November 2021 at 06:07:14 UTC+10 jonatha...@gmail.com
> wrote:
>
>> I'm trying to set up weewx on a new system.  (weewx is also new to me.)
>>  The system log shows records being added to the database every half hour,
>> but the database (weewx.sdb) seems to show records being added every 5
>> minutes.  Is one of these wrong?  Or does weewx add a number or records (6
>> exactly) to the database every half hours?  I'm perplexed.
>>
>> Here's an extract from the system log (*emphasis* added):
>>
>> $ journalctl --since today | grep 'weewx.*Added record.*database'
>> Nov 10 *00:00:16*  OaklandWeather.localdomain python3[1902]: weewx[1902]
>> INFO weewx.manager: Added record 2021-11-10 00:00:00 PST (1636531200) to
>> database 'weewx.sdb'
>> Nov 10 *00:30:16*  OaklandWeather.localdomain python3[1902]: weewx[1902]
>> INFO weewx.manager: Added record 2021-11-10 00:30:00 PST (1636533000) to
>> database 'weewx.sdb'
>> Nov 10 *01:00:16*  OaklandWeather.localdomain python3[1902]: weewx[1902]
>> INFO weewx.manager: Added record 2021-11-10 01:00:00 PST (1636534800) to
>> database 'weewx.sdb'
>> Nov 10 *01:30:16*  OaklandWeather.localdomain python3[1902]: weewx[1902]
>> INFO weewx.manager: Added record 2021-11-10 01:30:00 PST (1636536600) to
>> database 'weewx.sdb'
>> Nov 10 *02:00:16*  OaklandWeather.localdomain python3[1902]: weewx[1902]
>> INFO weewx.manager: Added record 2021-11-10 02:00:00 PST (1636538400) to
>> database 'weewx.sdb'
>>
>> But here is an extract from the database (weewx.sdb) converted to a
>> spreadsheet, covering the same period:
>>
>> --
>>
>> Sincerely Jonathan Ryshpan 
>>
>>  They know that it is human nature to take up
>>  causes whereby a man may oppress his neighbor,
>>  no matter how unjustly. ... Hence they have had
>>  no trouble in finding men who would preach the
>>  damnability and heresy of the new doctrine from
>>  the very pulpit...  -- Galileo Galilei, 1615
>>
>> --
> 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/3a30ac1e-af41-4894-b124-2d66da17dd61n%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/CAPq0zEBOgveNbgKsuxAjvDHMQNw2Qw80AA91s0xdFOzjywFWzA%40mail.gmail.com.

[weewx-user] Re: WeeWx database differs from system log

[gjr80]

Hi,

Rather than a filtered log extract, how about restarting WeeWX, letting it 
run for at least half an hour and then post an (entire) log extract 
covering all of the WeeWX startup through until the half hour elapsed. Much 
better to see a full log extract that shows everything that is going on. 
The WeeWX startup part of the log will show us key WeeWX config info.

Gary

On Thursday, 11 November 2021 at 06:07:14 UTC+10 jonatha...@gmail.com wrote:

> I'm trying to set up weewx on a new system.  (weewx is also new to me.) 
>  The system log shows records being added to the database every half hour, 
> but the database (weewx.sdb) seems to show records being added every 5 
> minutes.  Is one of these wrong?  Or does weewx add a number or records (6 
> exactly) to the database every half hours?  I'm perplexed.
>
> Here's an extract from the system log (*emphasis* added):
>
> $ journalctl --since today | grep 'weewx.*Added record.*database'
> Nov 10 *00:00:16*  OaklandWeather.localdomain python3[1902]: weewx[1902] 
> INFO weewx.manager: Added record 2021-11-10 00:00:00 PST (1636531200) to 
> database 'weewx.sdb'
> Nov 10 *00:30:16*  OaklandWeather.localdomain python3[1902]: weewx[1902] 
> INFO weewx.manager: Added record 2021-11-10 00:30:00 PST (1636533000) to 
> database 'weewx.sdb'
> Nov 10 *01:00:16*  OaklandWeather.localdomain python3[1902]: weewx[1902] 
> INFO weewx.manager: Added record 2021-11-10 01:00:00 PST (1636534800) to 
> database 'weewx.sdb'
> Nov 10 *01:30:16*  OaklandWeather.localdomain python3[1902]: weewx[1902] 
> INFO weewx.manager: Added record 2021-11-10 01:30:00 PST (1636536600) to 
> database 'weewx.sdb'
> Nov 10 *02:00:16*  OaklandWeather.localdomain python3[1902]: weewx[1902] 
> INFO weewx.manager: Added record 2021-11-10 02:00:00 PST (1636538400) to 
> database 'weewx.sdb'
>
> But here is an extract from the database (weewx.sdb) converted to a 
> spreadsheet, covering the same period:
>
> -- 
>
> Sincerely Jonathan Ryshpan 
>
>   They know that it is human nature to take up
>   causes whereby a man may oppress his neighbor,
>   no matter how unjustly. ... Hence they have had
>   no trouble in finding men who would preach the
>   damnability and heresy of the new doctrine from
>   the very pulpit...  -- Galileo Galilei, 1615
>
>

-- 
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/3a30ac1e-af41-4894-b124-2d66da17dd61n%40googlegroups.com.

Re: [weewx-user] WeeWx database differs from system log

[Tom Keffer]

The times in the log are a month later than the times you are showing from
the database. I'll bet if you looked later in the database, you would see
that the records are arriving every 30 minutes.

Which did you intend? 5 or 30 minutes.

On Wed, Nov 10, 2021 at 12:07 PM Jonathan Ryshpan 
wrote:

> I'm trying to set up weewx on a new system.  (weewx is also new to me.)
>  The system log shows records being added to the database every half hour,
> but the database (weewx.sdb) seems to show records being added every 5
> minutes.  Is one of these wrong?  Or does weewx add a number or records (6
> exactly) to the database every half hours?  I'm perplexed.
>
> Here's an extract from the system log (*emphasis* added):
>
> $ journalctl --since today | grep 'weewx.*Added record.*database'
> Nov 10 *00:00:16*  OaklandWeather.localdomain python3[1902]: weewx[1902]
> INFO weewx.manager: Added record 2021-11-10 00:00:00 PST (1636531200) to
> database 'weewx.sdb'
> Nov 10 *00:30:16*  OaklandWeather.localdomain python3[1902]: weewx[1902]
> INFO weewx.manager: Added record 2021-11-10 00:30:00 PST (1636533000) to
> database 'weewx.sdb'
> Nov 10 *01:00:16*  OaklandWeather.localdomain python3[1902]: weewx[1902]
> INFO weewx.manager: Added record 2021-11-10 01:00:00 PST (1636534800) to
> database 'weewx.sdb'
> Nov 10 *01:30:16*  OaklandWeather.localdomain python3[1902]: weewx[1902]
> INFO weewx.manager: Added record 2021-11-10 01:30:00 PST (1636536600) to
> database 'weewx.sdb'
> Nov 10 *02:00:16*  OaklandWeather.localdomain python3[1902]: weewx[1902]
> INFO weewx.manager: Added record 2021-11-10 02:00:00 PST (1636538400) to
> database 'weewx.sdb'
>
> But here is an extract from the database (weewx.sdb) converted to a
> spreadsheet, covering the same period:
>
> --
>
> Sincerely Jonathan Ryshpan 
>
>   They know that it is human nature to take up
>   causes whereby a man may oppress his neighbor,
>   no matter how unjustly. ... Hence they have had
>   no trouble in finding men who would preach the
>   damnability and heresy of the new doctrine from
>   the very pulpit...  -- Galileo Galilei, 1615
>
> --
> 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/0289f0eea330723c6ca0b963cc2a65bf141aebde.camel%40pacbell.net
> 
> .
>

-- 
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/CAPq0zEAwjf6UCJPXLf2NWoMBOqDM2o2uHfR6XHYo_jsrMDLhVg%40mail.gmail.com.

[weewx-user] WeeWx database differs from system log

[Jonathan Ryshpan]

I'm trying to set up weewx on a new system.  (weewx is also new to me.)
 The system log shows records being added to the database every half
hour, but the database (weewx.sdb) seems to show records being added
every 5 minutes.  Is one of these wrong?  Or does weewx add a number or
records (6 exactly) to the database every half hours?  I'm perplexed.

Here's an extract from the system log (emphasis added):

$ journalctl --since today | grep 'weewx.*Added record.*database'
Nov 10 00:00:16  OaklandWeather.localdomain python3[1902]: weewx[1902]
INFO weewx.manager: Added record 2021-11-10 00:00:00 PST (1636531200)
to database 'weewx.sdb'
Nov 10 00:30:16  OaklandWeather.localdomain python3[1902]: weewx[1902]
INFO weewx.manager: Added record 2021-11-10 00:30:00 PST (1636533000)
to database 'weewx.sdb'
Nov 10 01:00:16  OaklandWeather.localdomain python3[1902]: weewx[1902]
INFO weewx.manager: Added record 2021-11-10 01:00:00 PST (1636534800)
to database 'weewx.sdb'
Nov 10 01:30:16  OaklandWeather.localdomain python3[1902]: weewx[1902]
INFO weewx.manager: Added record 2021-11-10 01:30:00 PST (1636536600)
to database 'weewx.sdb'
Nov 10 02:00:16  OaklandWeather.localdomain python3[1902]: weewx[1902]
INFO weewx.manager: Added record 2021-11-10 02:00:00 PST (1636538400)
to database 'weewx.sdb'

But here is an extract from the database (weewx.sdb) converted to a
spreadsheet, covering the same period:

-- 
Sincerely Jonathan Ryshpan 

 They know that it is human nature to take up
 causes whereby a man may oppress his neighbor,
 no matter how unjustly. ... Hence they have had
 no trouble in finding men who would preach the
 damnability and heresy of the new doctrine from
 the very pulpit... -- Galileo Galilei, 1615

-- 
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/0289f0eea330723c6ca0b963cc2a65bf141aebde.camel%40pacbell.net.

Re: [weewx-user] Bug in skin localization / units

[Tom Keffer]

Please post the *entire* section [StdReport].



On Wed, Nov 10, 2021 at 8:28 AM itec  wrote:

> Hi.
> I cloned and installed the developement repository from git.
> version = 4.6.0b7
>
> [StdReport]
>
> # Which language to use. Not all skins support all languages.
> # You can override this for individual skins.
> lang = en
>
> # Which unit system to use. Choices are 'us', 'metric', or 'metricwx'.
> # You can override this for individual skins.
> unit_system = metric
>
>
> Thanks
> itec
> Il giorno mercoledì 10 novembre 2021 alle 17:21:26 UTC+1 tke...@gmail.com
> ha scritto:
>
>> 1. What version of the code are you using? Straight out of the git
>> repository? Or, one of the beta versions?
>>
>> 2. Please post your [StdReport] section from weewx.conf.
>>
>>
>>
>> On Wed, Nov 10, 2021 at 4:41 AM itec  wrote:
>>
>>> Hi.
>>> I'm testing weewx developement.
>>> In weewx.conf file, when I set unit_system = metric, units doesn't
>>> change.
>>> I have to set lang = it.
>>> It seems that unit_system is overridden by lang setting.
>>> Could you please check?
>>>
>>> itec
>>>
>>> --
>>> 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/10c587ca-1e30-47a6-a5ba-c6d620606c57n%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/02bb631b-796e-41ae-866c-77d61b3546b3n%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/CAPq0zEBxkB-UsRcOa2G%2Bp15B6vpcSAbjkvSEJ0pS-d0Gk8jd0Q%40mail.gmail.com.

Re: [weewx-user] Bug in skin localization / units

[itec]

Hi.
I cloned and installed the developement repository from git.
version = 4.6.0b7

[StdReport]

# Which language to use. Not all skins support all languages.
# You can override this for individual skins.
lang = en

# Which unit system to use. Choices are 'us', 'metric', or 'metricwx'.
# You can override this for individual skins.
unit_system = metric


Thanks
itec
Il giorno mercoledì 10 novembre 2021 alle 17:21:26 UTC+1 tke...@gmail.com 
ha scritto:

> 1. What version of the code are you using? Straight out of the git 
> repository? Or, one of the beta versions?
>
> 2. Please post your [StdReport] section from weewx.conf.
>
>
>
> On Wed, Nov 10, 2021 at 4:41 AM itec  wrote:
>
>> Hi.
>> I'm testing weewx developement.
>> In weewx.conf file, when I set unit_system = metric, units doesn't change.
>> I have to set lang = it.
>> It seems that unit_system is overridden by lang setting.
>> Could you please check?
>>
>> itec
>>
>> -- 
>> 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/10c587ca-1e30-47a6-a5ba-c6d620606c57n%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/02bb631b-796e-41ae-866c-77d61b3546b3n%40googlegroups.com.

Re: [weewx-user] Bug in skin localization / units

[Tom Keffer]

1. What version of the code are you using? Straight out of the git
repository? Or, one of the beta versions?

2. Please post your [StdReport] section from weewx.conf.



On Wed, Nov 10, 2021 at 4:41 AM itec  wrote:

> Hi.
> I'm testing weewx developement.
> In weewx.conf file, when I set unit_system = metric, units doesn't change.
> I have to set lang = it.
> It seems that unit_system is overridden by lang setting.
> Could you please check?
>
> itec
>
> --
> 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/10c587ca-1e30-47a6-a5ba-c6d620606c57n%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/CAPq0zEAumPy1eEVO%3DfFnO4-LsOF_yD10VowVADCiLcnPQg3RBA%40mail.gmail.com.

[weewx-user] Bug in skin localization / units

[itec]

Hi.
I'm testing weewx developement.
In weewx.conf file, when I set unit_system = metric, units doesn't change.
I have to set lang = it.
It seems that unit_system is overridden by lang setting.
Could you please check?

itec

-- 
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/10c587ca-1e30-47a6-a5ba-c6d620606c57n%40googlegroups.com.

Re: [weewx-user] All-Time Data different than max observed

[Mauro De Lauretis]

Hi Gary!

Thank you for your brilliant description.
Yes, you're right. I'm running two instances of WeeWX with two different 
databases, skin folders and configuration files.
 
The alltime string I've posted before was quite right, but for whatever 
reason, the main skin folder (Davis Station) continued to take the wrong 
value from the database of WeatherFlow. Since the Weather34 skin has a .php 
file that collects all settings and processed data, including an external 
file as well for the sensors (called archivedata.php), I could solve it by 
including the archivedata.php file of the WeatherFlow as well, obviously 
disabling the data of the other sensors I don't need (temperature, rain, 
etc.). Otherwise they would "crash" together and show me fake data. 

Mauro

Il giorno mercoledì 10 novembre 2021 alle 11:23:45 UTC+1 gjr80 ha scritto:

> Something to ponder and maybe worth some input from Tom.
>
> I think the problem here is a timing issue between the time a report is 
> being generated on one WeeWX instance and the time that records are added 
> to (at least) two different databases. A key point to remember is that for 
> $alltime to use the daily summaries the timespan concerned must start and 
> end on either the first timestamp in the archive, a midnight boundary or 
> the last timestamp in the archive. If this condition is not met the archive 
> is used instead of the daily summaries.
>
> The use of two different bindings implies two different databases. Whilst 
> I don’t think we have been given a detailed description of the setup, I 
> assume there are at least two WeeWX instances running; one with a vantage 
> station and the other a Weatherflow each using their own database. The 
> vantage station will be saving an archive record to database almost 
> immediately after the end of the archive period plus archive delay. I am 
> not familiar with the Weatherflow station, but it is quite possible the 
> archive records are not generated until sometime after the end of the 
> archive period plus delay, typically on receipt of the next loop packet. In 
> such cases, if the vantage instance produces a report using the Weatherflow 
> binding (database) the timespan used by the alltime tag will likely not 
> match the first and last timestamps of the Weatherflow database meaning the 
> archive will be used rather than the daily summaries. However, when the 
> same tag (with the Weatherflow binding of course) is used on the 
> Weatherflow system the timespan in use covers the first and last timestamps 
> in the Weatherflow database (because the reports are run until after the 
> archive record has been saved) so the daily summaries are used. Hence the 
> different results for the seemingly same tag on the two different systems.
>
> Should be easy enough to confirm by comparing the logs from the two 
> instances.
>
> How to fix? I’m not sure, typically the way timing differences between 
> reports and multiple databases are handled is to use $latest in place of 
> $current, but that won’t work here. I guess you could design some elaborate 
> system of reports where the Weatherflow system generates/updates a file 
> that the vantage system then uses - sounds like a lot of work. Or you could 
> live with it. Worth noting though that you do pay a performance penalty by 
> doing a query over the entire archive, so if you do live with it as is I 
> would keep any eye on your report times and not go adding numerous more 
> similar tags. 
>
> One out of the box solution could be to increase the vantage system 
> archive delay so that reports are not run before the Weatherflow system has 
> saved its archive record. But this approach may have other undesirable 
> effects, eg delaying the production of vantage reports/pages.
>
> Then of course Tom may have a magic solution.
>
> Gary
>
> On Wednesday, 10 November 2021 at 19:37:06 UTC+10 Mauro De Lauretis wrote:
>
>> Tom,
>>
>> sorry to annoying you again, but I still have a little issue.
>> Since I am using the Weather34 skin with multiple bindings due two 
>> different stations running (Davis and WeatherFlow, each with his own skin 
>> folder and configuration) I have this for my UV Almanac on my Davis folder:
>>
>> $alltime($data_binding='weatherflow_binding').UV.max
>>
>> This because my Davis it's not provided by UV Sensor, so I take it from 
>> my WeatherFlow.
>>
>> Curious is the fact that by running it on the WeatherFlow itself, the 
>> showed value is the correct one (UVI 1.05).
>> As soon as I run it on the skin folder of my Davis and tell him to take 
>> the values from the WeatherFlow's database (weatherflow_binding), I get the 
>> wrong value (UVI 0.856).
>>
>>
>>
>>
>> Il giorno martedì 9 novembre 2021 alle 22:58:43 UTC+1 tke...@gmail.com 
>> ha scritto:
>>
>>> Not sure. Are you sure they cover the same time period?
>>>
>>> What do you get if you put this in a template?
>>>
>>>   
>>> 
>>>   Start
>>>   End
>>>   Value
>>> 
>>>   

Re: [weewx-user] All-Time Data different than max observed

[gjr80]

Something to ponder and maybe worth some input from Tom.

I think the problem here is a timing issue between the time a report is 
being generated on one WeeWX instance and the time that records are added 
to (at least) two different databases. A key point to remember is that for 
$alltime to use the daily summaries the timespan concerned must start and 
end on either the first timestamp in the archive, a midnight boundary or 
the last timestamp in the archive. If this condition is not met the archive 
is used instead of the daily summaries.

The use of two different bindings implies two different databases. Whilst I 
don’t think we have been given a detailed description of the setup, I 
assume there are at least two WeeWX instances running; one with a vantage 
station and the other a Weatherflow each using their own database. The 
vantage station will be saving an archive record to database almost 
immediately after the end of the archive period plus archive delay. I am 
not familiar with the Weatherflow station, but it is quite possible the 
archive records are not generated until sometime after the end of the 
archive period plus delay, typically on receipt of the next loop packet. In 
such cases, if the vantage instance produces a report using the Weatherflow 
binding (database) the timespan used by the alltime tag will likely not 
match the first and last timestamps of the Weatherflow database meaning the 
archive will be used rather than the daily summaries. However, when the 
same tag (with the Weatherflow binding of course) is used on the 
Weatherflow system the timespan in use covers the first and last timestamps 
in the Weatherflow database (because the reports are run until after the 
archive record has been saved) so the daily summaries are used. Hence the 
different results for the seemingly same tag on the two different systems.

Should be easy enough to confirm by comparing the logs from the two 
instances.

How to fix? I’m not sure, typically the way timing differences between 
reports and multiple databases are handled is to use $latest in place of 
$current, but that won’t work here. I guess you could design some elaborate 
system of reports where the Weatherflow system generates/updates a file 
that the vantage system then uses - sounds like a lot of work. Or you could 
live with it. Worth noting though that you do pay a performance penalty by 
doing a query over the entire archive, so if you do live with it as is I 
would keep any eye on your report times and not go adding numerous more 
similar tags. 

One out of the box solution could be to increase the vantage system archive 
delay so that reports are not run before the Weatherflow system has saved 
its archive record. But this approach may have other undesirable effects, 
eg delaying the production of vantage reports/pages.

Then of course Tom may have a magic solution.

Gary

On Wednesday, 10 November 2021 at 19:37:06 UTC+10 Mauro De Lauretis wrote:

> Tom,
>
> sorry to annoying you again, but I still have a little issue.
> Since I am using the Weather34 skin with multiple bindings due two 
> different stations running (Davis and WeatherFlow, each with his own skin 
> folder and configuration) I have this for my UV Almanac on my Davis folder:
>
> $alltime($data_binding='weatherflow_binding').UV.max
>
> This because my Davis it's not provided by UV Sensor, so I take it from my 
> WeatherFlow.
>
> Curious is the fact that by running it on the WeatherFlow itself, the 
> showed value is the correct one (UVI 1.05).
> As soon as I run it on the skin folder of my Davis and tell him to take 
> the values from the WeatherFlow's database (weatherflow_binding), I get the 
> wrong value (UVI 0.856).
>
>
>
>
> Il giorno martedì 9 novembre 2021 alle 22:58:43 UTC+1 tke...@gmail.com ha 
> scritto:
>
>> Not sure. Are you sure they cover the same time period?
>>
>> What do you get if you put this in a template?
>>
>>   
>> 
>>   Start
>>   End
>>   Value
>> 
>> 
>>   $alltime.start ($alltime.start.raw)
>>   $alltime.end ($alltime.end.raw)
>>   $alltime.UV.max
>> 
>> 
>>   $year.start ($year.start.raw)
>>   $year.end ($year.end.raw)
>>   $year.UV.max
>> 
>>   
>>
>>
>>
>> On Tue, Nov 9, 2021 at 11:56 AM Mauro De Lauretis  
>> wrote:
>>
>>> Sorry Tom, I got a little confused because first I thought that the 
>>> value UVI 0.856 was in the archive_day_UV  and not archive and UVI 1.05 in 
>>> archive instead of archive_day_UV. Therefore it's right like you told me, 
>>> because I know that the LOOP packets values can be higher for daily summary.
>>>
>>> What I don't understand is why I'm getting the UVI 0.856 for All Time 
>>> and not the higher of UVI 1.05.
>>> Is there something wrong in my formulas?
>>>
>>> $alltime.UV.max = I get 0.856
>>>
>>> $year.UV.max =I I get 1.05
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Il giorno martedì 9 novembre 2021 alle 20:19:16 UTC+1 tke...@gmail.com 
>>> ha scritto

Re: [weewx-user] All-Time Data different than max observed

[Mauro De Lauretis]

Tom,

sorry to annoying you again, but I still have a little issue.
Since I am using the Weather34 skin with multiple bindings due two 
different stations running (Davis and WeatherFlow, each with his own skin 
folder and configuration) I have this for my UV Almanac on my Davis folder:

$alltime($data_binding='weatherflow_binding').UV.max

This because my Davis it's not provided by UV Sensor, so I take it from my 
WeatherFlow.

Curious is the fact that by running it on the WeatherFlow itself, the 
showed value is the correct one (UVI 1.05).
As soon as I run it on the skin folder of my Davis and tell him to take the 
values from the WeatherFlow's database (weatherflow_binding), I get the 
wrong value (UVI 0.856).




Il giorno martedì 9 novembre 2021 alle 22:58:43 UTC+1 tke...@gmail.com ha 
scritto:

> Not sure. Are you sure they cover the same time period?
>
> What do you get if you put this in a template?
>
>   
> 
>   Start
>   End
>   Value
> 
> 
>   $alltime.start ($alltime.start.raw)
>   $alltime.end ($alltime.end.raw)
>   $alltime.UV.max
> 
> 
>   $year.start ($year.start.raw)
>   $year.end ($year.end.raw)
>   $year.UV.max
> 
>   
>
>
>
> On Tue, Nov 9, 2021 at 11:56 AM Mauro De Lauretis  
> wrote:
>
>> Sorry Tom, I got a little confused because first I thought that the value 
>> UVI 0.856 was in the archive_day_UV  and not archive and UVI 1.05 in 
>> archive instead of archive_day_UV. Therefore it's right like you told me, 
>> because I know that the LOOP packets values can be higher for daily summary.
>>
>> What I don't understand is why I'm getting the UVI 0.856 for All Time and 
>> not the higher of UVI 1.05.
>> Is there something wrong in my formulas?
>>
>> $alltime.UV.max = I get 0.856
>>
>> $year.UV.max =I I get 1.05
>>
>>
>>
>>
>>
>>
>>
>>
>> Il giorno martedì 9 novembre 2021 alle 20:19:16 UTC+1 tke...@gmail.com 
>> ha scritto:
>>
>>> As I mentioned in my first note, I'm not surprised the value from the 
>>> daily summary is higher --- that's because it includes transient  values 
>>> from the LOOP packets.
>>>
>>> Don't know what you mean by "on my website it's totally the opposition." 
>>> How can you tell the difference?
>>>
>>> On Tue, Nov 9, 2021 at 10:39 AM Mauro De Lauretis  
>>> wrote:
>>>
 EDIT: I’ve chosen the wrong database before. They don’t mach!

 UV 0.856 on archive and 1.05 on archive_day, but on my website it’s 
 totally the opposite


 Il giorno martedì 9 novembre 2021 alle 19:31:28 UTC+1 Mauro De Lauretis 
 ha scritto:

> Hi Tom!
>
> Thank you for your answer.
> Yes, I have a match for both at
>
> 2020-12-09 07:00:00
>
> But there I had no sensor and the values are on UVI 0 of course.
>
>
> Il giorno martedì 9 novembre 2021 alle 19:17:47 UTC+1 tke...@gmail.com 
> ha scritto:
>
>> No explanation. Usually the values from the daily summaries are 
>> higher than those from the archive table because they also include 
>> transient values from the LOOP packets.
>>
>> But, let's double check. run these queries:
>>
>> *select from_unixtime(dateTime), UV from weewx.archive order by UV 
>> desc limit 1;*
>> *select from_unixtime(maxtime), max from weewx.archive_day_UV order 
>> by max desc limit 1;*
>>
>> Do they match?
>>
>> On Tue, Nov 9, 2021 at 9:58 AM Mauro De Lauretis <
>> mauro.de...@gmail.com> wrote:
>>
>>> Hi all
>>>
>>> Today I was looking better to my MySQL database and I was wondering 
>>> why my showed all-time data is always lower than my max observed data.
>>>
>>> Let me explain it better taking an example from UV Sensor:
>>>
>>> In the archive table, the max observed value is 1.1 UVI and it's 
>>> currently the highest value I got since I've installed the sensor. But 
>>> if I 
>>> take a look on archive_day_UV, the highest value from today and taken 
>>> for 
>>> the "All-Time" record is 0.9 UVI.
>>>
>>> Could someone explain me why archive_day takes this value and not 
>>> 1.1?
>>>
>>> Greetings
>>>
>>> -- 
>>> 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/85e91c5b-10ff-41bc-84b0-c1c93e5e9bf1n%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 t