Version 4.4.0

[Tom Keffer]

This version fixes a bug that was introduced by fixing yet another bug. It only affects vector wind plots.

4.4.0 01/30/2021

StdWXCalculate can now do calculations for only LOOP packets, only archive
records, or both. PR #630. Thanks to user g-eddy!

Introduced aggregate types "avg_ge" and "avg_le". PR #631. Thanks again to user
g-eddy!

NOAA reports now use a 'utf8' encoding instead of 'strict_ascii'. This will only
affect new installations. Fixes issue #644.

Introduced new encoding type 'normalized_ascii', which replaces characters that
have accented marks with analogous ascii characters. For example, ö gets
replaced with o.

Patching process is more forgiving about records with interval less than or
equal to zero.

Fixed problem where invalid mintime or maxtime was returned for days with no
data. Fixes issue #635.

Syntax errors in weewx.conf are now logged. PR #637. Thanks to user Rich Bell!

Fixed problem where plots could fail if the data range was outside of a
specified axes range. Fixes issue #638.

Fixed problem that could cause reporting to fail under Python2.7 if the
configuration dictionary contained a comment with a UTF-8 character. Fixes
issue #639.

Fixed problem that could cause program to crash if asking for deltas of a non-
existent key.

The version 4.3.0 patch to fix the incorrect calculation of sums in the daily
summary tables itself contained a bug. This version includes a patch to fix the
problem. It runs once at startup. Fixes issue #642.

[Tom Keffer]

My apologies to user 'edi-x', who was the true author of PR #631.

Thanks to user g-eddy for pointing this out.

[Δημήτρης Βήχος]

thanks!! very good point to NOAA reports now use a 'utf8' encoding instead of 'strict_ascii'. 

[t...@tom.org]

Looks good. JFYI sample output from a former 4.3.0 instance here:

➜  vt-dev git:(master) ✗ k logs -f weewx-deployment-vt-dev-667d7777d7-mrwdp

*** Running /etc/my_init.d/00_regen_ssh_host_keys.sh...

*** Running /etc/my_init.d/10_syslog-ng.init...

*** Booting runit daemon...

*** Runit started as PID 21

Jan 31 08:57:27 weewx-deployment-vt-dev-667d7777d7-mrwdp syslog-ng[13]: syslog-ng starting up; version='3.13.2'

using vt-dev

Jan 31 08:57:27 weewx-deployment-vt-dev-667d7777d7-mrwdp cron[26]: (CRON) INFO (pidfile fd = 3)

Jan 31 08:57:27 weewx-deployment-vt-dev-667d7777d7-mrwdp cron[26]: (CRON) INFO (Running @reboot jobs)

Jan 31 08:57:27 weewx-deployment-vt-dev-667d7777d7-mrwdp weewx[27] INFO __main__: Initializing weewx version 4.4.0

Jan 31 08:57:27 weewx-deployment-vt-dev-667d7777d7-mrwdp weewx[27] INFO __main__: Using Python 3.6.9 (default, Oct  8 2020, 12:12:24)

[GCC 8.4.0]

Jan 31 08:57:27 weewx-deployment-vt-dev-667d7777d7-mrwdp weewx[27] INFO __main__: Platform Linux-5.4.49+-x86_64-with-Ubuntu-18.04-bionic

Jan 31 08:57:27 weewx-deployment-vt-dev-667d7777d7-mrwdp weewx[27] INFO __main__: Locale is 'en_US.UTF-8'

Jan 31 08:57:27 weewx-deployment-vt-dev-667d7777d7-mrwdp weewx[27] INFO __main__: Using configuration file /home/weewx/weewx.conf

Jan 31 08:57:27 weewx-deployment-vt-dev-667d7777d7-mrwdp weewx[27] INFO __main__: Debug is 1

Jan 31 08:57:27 weewx-deployment-vt-dev-667d7777d7-mrwdp weewx[27] INFO weewx.engine: Loading station type Vantage (weewx.drivers.vantage)

Jan 31 08:57:32 weewx-deployment-vt-dev-667d7777d7-mrwdp weewx[27] ERROR weewx.drivers.vantage: ip-read error: timed out

Jan 31 08:57:37 weewx-deployment-vt-dev-667d7777d7-mrwdp weewx[27] INFO weewx.engine: StdConvert target unit is 0x1

Jan 31 08:57:37 weewx-deployment-vt-dev-667d7777d7-mrwdp weewx[27] INFO weewx.manager: Daily summaries at V3.0. Patching to V4.0

Jan 31 08:57:37 weewx-deployment-vt-dev-667d7777d7-mrwdp weewx[27] INFO weewx.manager: recalculate_weights: Using database 'weewx_vt_dev'

Daily summaries at V3.0. Patching to V4.0

Jan 31 08:59:01 weewx-deployment-vt-dev-667d7777d7-mrwdp weewx[27] INFO weewx.manager: Patch finished.

Jan 31 08:59:01 weewx-deployment-vt-dev-667d7777d7-mrwdp weewx[27] INFO weewx.engine: Archive will use data binding wx_binding

[WindnFog]

Thanks, Tom, et. al.  weewx v4.4.0 is working well here.

- Paul VE1DX

https://ve1dx.net <--- Weather Station

[Neville Davis]

I am also now at 4.4.0 and Belchertown 1.2... everything working fine..

Thanks very much

[Chris Alemany]

Updated here as well with standard and Weather34 skins on macOS 11.1. Flawless.

--
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/94dad3f2-f3a8-4626-9a77-980d63e762ben%40googlegroups.com.

[Nate Bargmann]

Updated this morning on Debian 10.7 and after several minutes of
updating the DB, everything came up working smooth as silk.

Good show!

- Nate

--

"The optimist proclaims that we live in the best of all
possible worlds. The pessimist fears this is true."

Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819

[Vetti52]

Just upgraded from 4.4.3 to 4.4.0, but it fails.

got this in systemctl status weewx.service:

Feb 03 16:44:25 RaspBee python3[629]: weewx[629] CRITICAL weewx.engine:     ****      debug_wind=self.debug_wind)
Feb 03 16:44:25 RaspBee python3[629]: weewx[629] CRITICAL weewx.engine:     ****    File "/usr/share/weewx/user/gw1000.py", line 2166, in __init__
Feb 03 16:44:25 RaspBee python3[629]: weewx[629] CRITICAL weewx.engine:     ****      lost_contact_log_period=lost_contact_log_period)
Feb 03 16:44:25 RaspBee python3[629]: weewx[629] CRITICAL weewx.engine:     ****    File "/usr/share/weewx/user/gw1000.py", line 2915, in __init__
Feb 03 16:44:25 RaspBee python3[629]: weewx[629] CRITICAL weewx.engine:     ****      ip_port_list = self.discover()
Feb 03 16:44:25 RaspBee python3[629]: weewx[629] CRITICAL weewx.engine:     ****    File "/usr/share/weewx/user/gw1000.py", line 3005, in discover
Feb 03 16:44:25 RaspBee python3[629]: weewx[629] CRITICAL weewx.engine:     ****      socket_obj.sendto(packet, (self.broadcast_address, self.broadcast_port))
Feb 03 16:44:25 RaspBee python3[629]: weewx[629] CRITICAL weewx.engine:     ****  OSError: [Errno 101] Das Netzwerk ist nicht erreichbar
Feb 03 16:44:25 RaspBee python3[629]: weewx[629] CRITICAL __main__: Unable to load driver: [Errno 101] Das Netzwerk ist nicht erreichbar
Feb 03 16:44:25 RaspBee python3[629]: weewx[629] CRITICAL __main__:     ****  Exiting...

Hopefully someone knows, what to do.

Thanks

-Peter

[Vetti52]

Typo: Upgrade from 4.3.0 to 4.4.0.

Version 4.3.0 had no issues so far.

[Vetti52]

just to narrow down my problem:

When starting manually

 weewxd /etc/weewx/weewx.conf

it works. Starting with

systemctl start weewx,

it fails.

Maybe, I will find out, what makes the difference. But, just in case, someone knows the trick, please tell!

Thanks

-Peter

[gjr80]

Hi,

It appears there is a network/connectivity issue preventing the gw1000 driver connecting to your GW1000 device. Can you connect to the GW1000 via the WS View app on your mobile device? If so is your WeeWX machine properly connecting to the same network? Can you ping the WeeWX machine from another device? If so I would set debug=1 and restart WeeWX. If the WS View app cannot connect to the GW1000 or your WeeWX machine is not connected to the same network then you need to deal with those issues before WeeWX will work.

Could you please start a new thread if you need further help.

Gary

[gjr80]

Ok, can you please set debug=1, restart WeeWX as a daemon and post in a new thread the log through until the failure occurs.

Gary

[Vetti52]

Hi,

maybe a new thread would be helpful, because the issue is/was very special and might not be a problem with version 4.4.0:

After I realized, that weewx could be run manually, I was inspecting, what was the difference. I had updated to version 4.4.0 and also had an update for my Zigbee device driver (deCONZ). Then I had to reboot the Raspberry Pi and after that the error occured. Finally I realized, that, the /etc/init.d/weewx start failed, with code=exited but no success. I misinterpreted this as that weewx was not running, since there were no syslog entries at all. Repeating to start weewx using the previous interceptor driver did not work either. So I decided to let it run with gw1000 driver, but started it manually with sudo weewxd /etc/weewx/weewx.conf >nul &.  This was successful, and went to sleep....

Today I decided to look at this issue again and, instead of killing the manually started weexd properly, I accidently used /etc/init.d/weewx stop, which indeed stopped weewx, but the manually started weewxd continued. After I stopped this too, I realized, that weewx had in fact been started autmatically after reboot, but got stuck, as you say, because of the gw1000 driver. What I did not expect, is, that weewx then did not exit. Any additional starting command therefore failed. I was cind of silly, not to look at that, sorry. After stopping the hanging weewx, I could start weewx as expected, and now it works without any issues. Maybe, it would be better not to start weewx with its init.d script, but with systemctl using a separate weewx.service file which should contain a stanza like

[Unit]

After=network-online.target

that would avoid to start weewx before network is up, which seems to be a crucial step for gw1000. But this should be another thread, I think.

Thanks

Peter

[Karen K]

Meanwhile I would add, that the update was without problems in my case (Ubuntu apt-get upgrade). I use Belchertown skin and some additional uploaders.

[David Trebacz]

My first upgrade of Wewwx (after years on wview). Upgraded from 4.1.1 to 4.4.0 with Belchertown 1.2 on a Ubuntu 20.04 VM using the setup.py method. Wow that was smooth... Great software and wonderful community.

[gert.a...@gmail.com]

Hi Tom

At #1 you wrote:

NOAA reports now use a 'utf8' encoding instead of 'strict_ascii'. This will only
affect new installations. Fixes issue #644. 

When I look at the skin.conf, utf8 has disappeared as a choice:

# Possible encodings include 'html_entities', 'strict_ascii', 'normalized_ascii',

normalized_ascii will not show danish characters correct(æåøÆÅØ)

From the NOAA report:

normalized_ascii:
NAME: Vester Smarken, Bornholm

With utf8:
NAME: Vester Sømarken, Bornholm

Rgds

Gert

[Tom Keffer]

Here's the problem: when a browser renders a document, it needs to know what encoding it is in. For HTML documents, this is specified by a meta tag

    <meta charset="UTF-8">

However, with a plain text document, there is no way to specify the encoding, so, instead, browsers must use a default. From what I can tell, most default to cp1252 (aka, Windows-1252), not UTF-8. Hence, if we encode the NOAA documents in UTF-8, the browser will not know it and, instead, will default to cp1252, giving odd results.

The good news is that the Danish characters can be encoded using cp1252, so use that as the encoding. I.e.,

    [[SummaryByMonth]]
        # Reports that summarize "by month"
        [[[NOAA_month]]]
            encoding = cp1252
            template = NOAA/NOAA-%Y-%m.txt.tmpl

This will only work with V4.4.1 and later (not released yet).

You can understand that we can't make this the default for the NOAA reports because not all characters can be encoded in cp1252. If a character cannot be encoded, then an exception is raised, terminating the report. So, normalized_ascii was chosen for the default.

-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+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/ff73a836-106f-4a62-9c69-4652ad6c40c4n%40googlegroups.com.