[weewx-user] Re: GW1000 and" CMD_READ_STATION_MAC"

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

Hi

Thank to All and your good suggestions.

I have configured a static IP-address for the GW1000 and the RPI. I have 
also rebooted the RPI and the Gateway and now it seems to work again.

Thanks again.

Gert

On Tuesday, December 1, 2020 at 1:48:38 AM UTC+1 gjr80 wrote:

> The error shows that the driver could not contact your GW1000 for some 
> reason, once the driver had everything required to connect to the GW1000 
> the GW1000 did not respond. It could have happened for any number of 
> reasons; the GW1000 driver may have been using an incorrect address when 
> trying to connect to the GW1000,  the GW1000 may have changed address or 
> the network may have experienced a problem. Impossible to say more without 
> knowing exact config details both of the driver and your GW1000/network 
> config. 
>
> Things to try. You could set loop_on_init = True 
>  in weewx.conf so that 
> WeeWX will wait 60 seconds when the driver fails to load and then try 
> again. If the issue is transient in nature this may work but if it is 
> something more permanent then it likely will just cause WeeWX to loop 
> indefinitely. You could try configuring your network such that the GW1000 
> uses a static IP rather than having the GW1000 driver locate the GW1000 via 
> network broadcast.
>
> Gary
> On Tuesday, 1 December 2020 at 01:51:08 UTC+10 gert.a...@gmail.com wrote:
>
>> Hi
>>
>> Running RPI 4, Weewx 4.2 and GW1000 latest version and suddenly this 
>> appears. Any ideas what's going on?
>>
>> The combination has been running stable, so my best quest it might be a 
>> hardware problem or? 
>>
>> Never seen this before and couldn't find anything on the net.
>>
>> Nov 30 16:30:32 raspberrypi weewx[537] ERROR user.gw1000: Failed to 
>> obtain response to command 'CMD_READ_STATION_MAC' after 3 attempts
>> Nov 30 16:30:32 raspberrypi weewx[537] ERROR weewx.engine: Import of 
>> driver failed: Failed to obtain response to command 'CMD_READ_STATION_MAC' 
>> after 3 attempts ()
>> Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL weewx.engine:   
>> Traceback (most recent call last):
>> Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL weewx.engine: 
>> File "/home/weewx/bin/weewx/engine.py", line 109, in setupStation
>> Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL weewx.engine: 
>>   self.console = loader_function(config_dict, self)
>> Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL weewx.engine: 
>> File "/home/weewx/bin/user/gw1000.py", line 1293, in loader
>> Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL weewx.engine: 
>>   return Gw1000Driver(**config_dict[DRIVER_NAME])
>> Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL weewx.engine: 
>> File "/home/weewx/bin/user/gw1000.py", line 1568, in __init__
>> Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL weewx.engine: 
>>   super(Gw1000Driver, self).__init__(**stn_dict)
>> Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL weewx.engine: 
>> File "/home/weewx/bin/user/gw1000.py", line 767, in __init__
>> Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL weewx.engine: 
>>   debug_wind=self.debug_wind)
>> Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL weewx.engine: 
>> File "/home/weewx/bin/user/gw1000.py", line 1870, in __init__
>> Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL weewx.engine: 
>>   lost_contact_log_period=lost_contact_log_period)
>> Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL weewx.engine: 
>> File "/home/weewx/bin/user/gw1000.py", line 2276, in __init__
>> Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL weewx.engine: 
>>   self.mac = self.get_mac_address()
>> Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL weewx.engine: 
>> File "/home/weewx/bin/user/gw1000.py", line 2407, in get_mac_address
>> Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL weewx.engine: 
>>   return self.send_cmd_with_retries('CMD_READ_STATION_MAC')
>> Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL weewx.engine: 
>> File "/home/weewx/bin/user/gw1000.py", line 2532, in send_cmd_with_retries
>> Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL weewx.engine: 
>>   raise GW1000IOError(_msg)
>> Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL weewx.engine:   
>> user.gw1000.GW1000IOError: Failed to obtain response to command 
>> 'CMD_READ_STATION_MAC' after 3 attempts
>> Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL __main__: Unable to load 
>> driver: Failed to obtain response to command 'CMD_READ_STATION_MAC' after 3 
>> attempts
>> Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL __main__:   
>> Exiting...
>>
>> Gert
>>
>

-- 
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] Re: GW1000 and" CMD_READ_STATION_MAC"

[gjr80]

The error shows that the driver could not contact your GW1000 for some 
reason, once the driver had everything required to connect to the GW1000 
the GW1000 did not respond. It could have happened for any number of 
reasons; the GW1000 driver may have been using an incorrect address when 
trying to connect to the GW1000,  the GW1000 may have changed address or 
the network may have experienced a problem. Impossible to say more without 
knowing exact config details both of the driver and your GW1000/network 
config. 

Things to try. You could set loop_on_init = True 
 in weewx.conf so that WeeWX 
will wait 60 seconds when the driver fails to load and then try again. If 
the issue is transient in nature this may work but if it is something more 
permanent then it likely will just cause WeeWX to loop indefinitely. You 
could try configuring your network such that the GW1000 uses a static IP 
rather than having the GW1000 driver locate the GW1000 via network 
broadcast.

Gary
On Tuesday, 1 December 2020 at 01:51:08 UTC+10 gert.a...@gmail.com wrote:

> Hi
>
> Running RPI 4, Weewx 4.2 and GW1000 latest version and suddenly this 
> appears. Any ideas what's going on?
>
> The combination has been running stable, so my best quest it might be a 
> hardware problem or? 
>
> Never seen this before and couldn't find anything on the net.
>
> Nov 30 16:30:32 raspberrypi weewx[537] ERROR user.gw1000: Failed to obtain 
> response to command 'CMD_READ_STATION_MAC' after 3 attempts
> Nov 30 16:30:32 raspberrypi weewx[537] ERROR weewx.engine: Import of 
> driver failed: Failed to obtain response to command 'CMD_READ_STATION_MAC' 
> after 3 attempts ()
> Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL weewx.engine:   
> Traceback (most recent call last):
> Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL weewx.engine: 
> File "/home/weewx/bin/weewx/engine.py", line 109, in setupStation
> Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL weewx.engine: 
>   self.console = loader_function(config_dict, self)
> Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL weewx.engine: 
> File "/home/weewx/bin/user/gw1000.py", line 1293, in loader
> Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL weewx.engine: 
>   return Gw1000Driver(**config_dict[DRIVER_NAME])
> Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL weewx.engine: 
> File "/home/weewx/bin/user/gw1000.py", line 1568, in __init__
> Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL weewx.engine: 
>   super(Gw1000Driver, self).__init__(**stn_dict)
> Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL weewx.engine: 
> File "/home/weewx/bin/user/gw1000.py", line 767, in __init__
> Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL weewx.engine: 
>   debug_wind=self.debug_wind)
> Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL weewx.engine: 
> File "/home/weewx/bin/user/gw1000.py", line 1870, in __init__
> Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL weewx.engine: 
>   lost_contact_log_period=lost_contact_log_period)
> Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL weewx.engine: 
> File "/home/weewx/bin/user/gw1000.py", line 2276, in __init__
> Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL weewx.engine: 
>   self.mac = self.get_mac_address()
> Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL weewx.engine: 
> File "/home/weewx/bin/user/gw1000.py", line 2407, in get_mac_address
> Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL weewx.engine: 
>   return self.send_cmd_with_retries('CMD_READ_STATION_MAC')
> Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL weewx.engine: 
> File "/home/weewx/bin/user/gw1000.py", line 2532, in send_cmd_with_retries
> Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL weewx.engine: 
>   raise GW1000IOError(_msg)
> Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL weewx.engine:   
> user.gw1000.GW1000IOError: Failed to obtain response to command 
> 'CMD_READ_STATION_MAC' after 3 attempts
> Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL __main__: Unable to load 
> driver: Failed to obtain response to command 'CMD_READ_STATION_MAC' after 3 
> attempts
> Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL __main__:   
> Exiting...
>
> Gert
>

-- 
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/f20fc723-aa20-4152-a556-837b0ffe3115n%40googlegroups.com.

[weewx-user] Re: GW1000 and" CMD_READ_STATION_MAC"

[vince]

On Monday, November 30, 2020 at 2:58:31 PM UTC-8 wa4...@gmail.com wrote:

> I saw this today, too.
> For some reason weewx can't contact your GW1000.  Without the GW1000 
> connecting weewx won't start.
> Either the wrong IP in weewx.config, or the GW1000 needs to be set up 
> (again?) on your WiFi.
> If you haven't already assigned the GW1000 a static IP in your router, now 
> is a good time.
>
>
Always a good idea to reserve a static address via your router, even if the 
computer/station works via DHCP.

Note - the gw1000 will reboot if it fails to reach the Ecowitt servers (or 
a NTP server) too often or for too long a period.  They have a couple 
watchdog timers in the firmware that can't be turned off.  While it can be 
faked on your LAN to prevent this, the gateway will still reboot if you 
lose your home wifi for too long, as it thinks lack of connectivity to 
Ecowitt means the hardware needs to reboot itself (which is not true of 
course, but they do what they do I guess...)


-- 
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/e27c0db4-d546-4cb3-95ae-1e92f30e8421n%40googlegroups.com.

Re: [weewx-user] forcast wunderground for weewx 4.2.x using python 3

[John Kline]

Thanks, I was just looking for you to confirm that you were seeing the issue in 
the forecast skin itself.

I looked at forecast_compact.inc.  It is looking for temperatureMin and 
temperatureMax (which are in the beginning section of the WU forecast).  
Furthermore, when I looked at the tempMin and tempMax columns in the database, 
they were wrong.  There was a bug in parsing for these values.  I’ve fixed that 
now.

Please pull forecast.py at head and give it a try.  Copy it to 
/bin/user.

You’ll need to wait for a new WU forecast to download and then for a report to 
generate.  This download may take some time.  If you’re comfortable mucking 
with the database, you could delete the latest WU forecast.  If you’re not 
comfortable doing that, and you don’t want to wait, you could simply delete the 
forecast.db file and then restart weewx (which you have to restart anyway after 
you copy over the new forecast.py file).

> On Nov 30, 2020, at 8:20 AM, 'Michael Waldor' via weewx-user 
>  wrote:
> 
> Regarding missing icon... I already copied it from your zip, and it's 
> working fine. I just thought that the missing icon might be a hint that some 
> important code might be missing, too. But probably not. 
> 
> I did use the original forcast skin creating the subfolder forecast within 
> HTML area. And it, too, contains the "wrong" temperature values. Identical to 
> those values as been shown within my usecase of forecast_compact. 
> 
> Yesterday I've validated that forcast.sdb contains the "correct" forecast 
> temperatures within the SQL database field temperature (there are 12entries 
> per timestamp for 6days). Hopefully my forecast.sdb.txt posted yesterday is 
> still a valid binary SQL database, then you can inspect it e. g. using 
> sqlbrowser. 
> 
> Thus I assume that somewhere within weewx/forecast the wrong data are 
> forwarded into HTML output. 
> 
> jo...@johnkline.com schrieb am Montag, 30. November 2020 um 16:15:24 UTC+1:
>> frzngdrzl.png was added to the repository after the b10 release.  If you 
>> want it, you’ll have to download the repository at head.
>> 
>> I cannot decipher from your reply if the compact forecast is correct in the 
>> forecast skin.  Is it?
>> 
 On Nov 30, 2020, at 12:10 AM, Michael Waldor  wrote:
 
>>> 
>> 
>>> Yes, I did diff both - they are identical. But there is a minor issue: You 
>>> did update install.py to include frzgrain.png. This is still missing within 
>>> your  
>>> https://github.com/chaunceygardiner/weewx-forecast/releases/tag/v3.4.0b10 - 
>>> the png is include but it will not be installed. Is there any other 
>>> important change maybe missing within your last zip release?
>>> 
>>> Of course that does not explain the wrong temperature numbers. I've checked 
>>> also the foreground skin. The data are in sync with my change within 
>>> Seasons skin. But the data do not contain the values from temperature field 
>>> within forecast.sdb.
>>> 
>>> Don't know the internal flow of weewx/forecast. I assume that first you 
>>> fetch json contents from WU. Then that data is uploaded into forecast.sdb. 
>>> Afterwards during creation of HTML output the data from forecast.sdb is 
>>> read and added into the HTML templates by forecast.py. If my assumption is 
>>> correct there might be a problem during the step from forecast.sdg into the 
>>> HTML output.
>>> 
>>> 
>>> jo...@johnkline.com schrieb am Sonntag, 29. November 2020 um 14:36:07 UTC+1:
 > Maybe I'm using the wrong forecast_compact.inc (see my included file)? 
 > And see als my forecast.sdb and 5day.json with the presumably correct 
 > temp values, but not shown within the rendered window.
 
 Did you diff forecast_compact.inc with the like named file in the latest 
 forecast extension?  Are they identical?  If not, please provide the diff.
 
 Does the compact forecast in the forecast skin have the correct values?
 
>> On Nov 29, 2020, at 1:27 AM, Michael Waldor  wrote:
>> 
> Sorry for posting multiple times - but google did abort any post if 
> containing *.json or *.inc files:-(
 
> 
> 
> Michael Waldor schrieb am Sonntag, 29. November 2020 um 10:26:00 UTC+1:
>> Tried to rename forecast.sdb into forecast.sdb.txt 
>> 
>> Michael Waldor schrieb am Sonntag, 29. November 2020 um 10:23:34 UTC+1:
>>> Sorry, but google doesn't allow me to append the data. Thus I try again 
>>> ...
>>> 
> 
 
> -- 
> 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/23bc8b05-639e-4a2b-9860-0e9b92ca6e8cn%40googlegroups.com.
> 
>>> 
>>> -- 
>>> You received this message because you are subscribed to the Google Groups 
>>> 

Re: [weewx-user] suggestions to buy a station

[Tom Keffer]

Recent thread on the topic:
https://groups.google.com/g/weewx-user/c/XSNRWVNa_Fc/m/7t6korfbAwAJ

On Mon, Nov 30, 2020 at 2:21 PM Rich Painter  wrote:

> I'm wanting to buy a weather station with the normal meters and  wind
> speed, dir and rain gauge.
>
> Any suggestions?
>
> thanks
> rich
>
> --
> Richard A. Painter, P.E. Retired
>
>
> --
> 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/CABh4ZQi7YoCOqFwknyroKnU%2BmS2w4LepDr6vnHirGQuGymujhg%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/CAPq0zEDLRp-tMHyNPkib8Vk64Ponj49pwfv9rVbEFMNq-AfprA%40mail.gmail.com.

[weewx-user] Re: GW1000 and" CMD_READ_STATION_MAC"

[Bill Arthur]

I saw this today, too.
For some reason weewx can't contact your GW1000.  Without the GW1000 
connecting weewx won't start.
Either the wrong IP in weewx.config, or the GW1000 needs to be set up 
(again?) on your WiFi.
If you haven't already assigned the GW1000 a static IP in your router, now 
is a good time.

On Monday, November 30, 2020 at 9:51:08 AM UTC-6 gert.a...@gmail.com wrote:

> Hi
>
> Running RPI 4, Weewx 4.2 and GW1000 latest version and suddenly this 
> appears. Any ideas what's going on?
>
> The combination has been running stable, so my best quest it might be a 
> hardware problem or? 
>
> Never seen this before and couldn't find anything on the net.
>
> Nov 30 16:30:32 raspberrypi weewx[537] ERROR user.gw1000: Failed to obtain 
> response to command 'CMD_READ_STATION_MAC' after 3 attempts
> Nov 30 16:30:32 raspberrypi weewx[537] ERROR weewx.engine: Import of 
> driver failed: Failed to obtain response to command 'CMD_READ_STATION_MAC' 
> after 3 attempts ()
> Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL weewx.engine:   
> Traceback (most recent call last):
> Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL weewx.engine: 
> File "/home/weewx/bin/weewx/engine.py", line 109, in setupStation
> Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL weewx.engine: 
>   self.console = loader_function(config_dict, self)
> Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL weewx.engine: 
> File "/home/weewx/bin/user/gw1000.py", line 1293, in loader
> Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL weewx.engine: 
>   return Gw1000Driver(**config_dict[DRIVER_NAME])
> Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL weewx.engine: 
> File "/home/weewx/bin/user/gw1000.py", line 1568, in __init__
> Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL weewx.engine: 
>   super(Gw1000Driver, self).__init__(**stn_dict)
> Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL weewx.engine: 
> File "/home/weewx/bin/user/gw1000.py", line 767, in __init__
> Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL weewx.engine: 
>   debug_wind=self.debug_wind)
> Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL weewx.engine: 
> File "/home/weewx/bin/user/gw1000.py", line 1870, in __init__
> Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL weewx.engine: 
>   lost_contact_log_period=lost_contact_log_period)
> Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL weewx.engine: 
> File "/home/weewx/bin/user/gw1000.py", line 2276, in __init__
> Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL weewx.engine: 
>   self.mac = self.get_mac_address()
> Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL weewx.engine: 
> File "/home/weewx/bin/user/gw1000.py", line 2407, in get_mac_address
> Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL weewx.engine: 
>   return self.send_cmd_with_retries('CMD_READ_STATION_MAC')
> Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL weewx.engine: 
> File "/home/weewx/bin/user/gw1000.py", line 2532, in send_cmd_with_retries
> Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL weewx.engine: 
>   raise GW1000IOError(_msg)
> Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL weewx.engine:   
> user.gw1000.GW1000IOError: Failed to obtain response to command 
> 'CMD_READ_STATION_MAC' after 3 attempts
> Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL __main__: Unable to load 
> driver: Failed to obtain response to command 'CMD_READ_STATION_MAC' after 3 
> attempts
> Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL __main__:   
> Exiting...
>
> Gert
>

-- 
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/e9f14709-42cc-47b7-883a-2436c97e58c7n%40googlegroups.com.

Re: [weewx-user] suggestions to buy a station

[Didier Decoodt]

A Vantage Vue and Weatherlinklive is a good choice

It's depend of your budget...

Le lun. 30 nov. 2020 à 23:21, Rich Painter  a écrit :

> I'm wanting to buy a weather station with the normal meters and  wind
> speed, dir and rain gauge.
>
> Any suggestions?
>
> thanks
> rich
>
> --
> Richard A. Painter, P.E. Retired
>
>
> --
> 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/CABh4ZQi7YoCOqFwknyroKnU%2BmS2w4LepDr6vnHirGQuGymujhg%40mail.gmail.com
> 
> .
>


-- 
Quel temps fait-il à Auffargis  ?

-- 
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/CAAvt3%3DRRiwWLwzmw_DfKFnE2eX-pGKr42i6bdktMbb%3D9_NxNKQ%40mail.gmail.com.

[weewx-user] suggestions to buy a station

[Rich Painter]

I'm wanting to buy a weather station with the normal meters and  wind
speed, dir and rain gauge.

Any suggestions?

thanks
rich

-- 
Richard A. Painter, P.E. Retired

-- 
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/CABh4ZQi7YoCOqFwknyroKnU%2BmS2w4LepDr6vnHirGQuGymujhg%40mail.gmail.com.

Re: [weewx-user] Wrong monthly average temperature

[michael.k...@gmx.at]

Thank you again and again, especially the support you are providing! I'm 
more than happy, when my inputs lead to improvements.

I stopped weewx

I ran the 
update archive_day_XXX set wsum=sum*300, sumtime=count*300;
queries,

I edited manager.py

I started weewx again.

Log looks normal.

Most recent archive_day_outTemp line before:
1606690800 -3.8 1606716001 5.6 1606739368 66.9377561327561 246 
20081.3268398268 73800
Most recent archive_day_outTemp line after two values were added to archive 
:
1606690800 -3.8 1606716001 5.6 1606739368 61.3091847041846 248 
18392.7554112554 74400

I've done the math and everything looks correct to me :)

tke...@gmail.com schrieb am Montag, 30. November 2020 um 20:38:22 UTC+1:

> I think I found the problem. The version number was inadvertently being 
> truncated from '2.0' to '2'. Later, the weighting factor is determined as:
>
> weight = 60.0 * record['interval'] if self.version >= '2.0' else 
> 1.0
>
> Because '2' collates ahead of '2.0', the weight was set to 1.0.
>
> Fixed in commit 9510f38 
> 
> .
>
> Michael, if you want to apply the fix to your copy, go into 
> weewx/manager.py. Around line 827 change this
>
> v = self._read_metadata('Version')
> self.version = v[0] if v is not None else "1.0"
>
> to this
>
> self.version = self._read_metadata('Version')
> if self.version is None:
> self.version = '1.0'
>
> Thanks, Michael, for your diligence in drawing this to my attention.
>
> I don't know why so many of your messages keep going to spam. I keep 
> telling Google Groups to allow all messages from you to pass, but it 
> doesn't always pay attention.
>
> -tk
>
>
>
>
> On Mon, Nov 30, 2020 at 11:06 AM michael.k...@gmx.at  
> wrote:
>
>> Hello again,
>>
>> What happens now is: metadata says "Version 2.0", weewx is currently 
>> producing "Version 1.0" numbers (4.2.0). So I am afraid, when I follow your 
>> advice and and recalculate "Version 2.0" values, tomorrow I'll end up 
>> having mixed values again.
>>
>> I checked a database snapshot BEFORE I updated t0 4.2.0:
>>
>> Version 2.0
>>
>> It didn't change during the update.
>>
>> Here  are some entries from archive_day_outTemp AFTER the update to 
>> 4.2.0, but BEFORE I manually changed to Version 1.0 Nuumbers: (dateTime 
>> DESC)
>>
>
>> 1605481200 1.4 1605493171 8.9 1605535929 1811.52088383838 288 
>> 1811.52088383838 288
>> 1605394800 2.1 1605473931 16.1 1605445486 2346.52735930736 288 
>> 2346.52735930736 288
>> 1605308400 5.5 1605328978 17.3 1605360608 2590.47363636364 288 
>> 650228.309292929 69058
>> 1605222000 4.0 1605238302 14.9 1605272440 2255.38090909091 288 
>> 676614.272727273 86400
>> 1605135600 2.7 1605160230 12.0 1605186834 1942.27053030303 288 
>> 582681.159090909 86400
>>
>> Weewx just "decided" to produce Version 1.0 Number after the update an 
>> mixing both oh the particular day.
>>
>> Now something also very interesting, the following lines are from a 
>> friend's database, two days before and after the update: (dateTime DESC)
>> 1604098800 5.1 1604184954 15.8 1604153156 3087.89794733045 288 
>> 3087.89794733045 288
>> 1604012400 6.9 1604022829 12.6 1604059984 2970.48686868687 288 
>> 2970.48686868687 288
>> 1603926000 5.6 1603926667 9.7 1603970504 2352.86239898999 288 
>> 235090.302070707 30188
>> 1603839600 -1.2 1603859547 11.9 1603896779 1507.83905483406 288 
>> 452351.716450217 86400
>> 1603753200 0.29997 1603839591 9.9 1603808400 1324.44158008658 288 
>> 397332.474025974 86400
>>
>> The same happened, he ales has Version 2.0 in metadata, Version 2.0 
>> numbers before the update, mixed on the day of the update and Version 1.0 
>> after the update. But his average calculation still works.
>>
>> So somehow something happened. @all Readers: can you check your database 
>> before and after the upgrade? Is anybody seeing the same behavior? We, my 
>> friend an me, have very similar installations, maybe the same quirksy 
>> config? Or maybe this is more widespread, but most of the users don't 
>> recognise the effects?
>>
>
>>
>> tke...@gmail.com schrieb am Montag, 30. November 2020 um 15:20:21 UTC+1:
>>
>>> Michael, I have no idea what happened, but if you want to modify your 
>>> daily summaries, it should be done right. If I understand you correctly, 
>>> you patched them with SQL commands like
>>>
>>> update archive_day_ET set wsum=sum, sumtime=count;
>>> update archive_day_UV set wsum=sum, sumtime=count;
>>> update archive_day_altimeter set wsum=sum, sumtime=count;
>>> etc.
>>>
>>> This will leave your summaries in an inconsistent state: the numbers are 
>>> what would be expected for a Version 1 summary, yet your metadata will say 
>>> Version 2. Furthermore, as new days are added, Version 2 numbers will be 
>>> used, and you'll be back where you started: with half Version 1 and half 
>>> Version 2. 
>>>
>>> I would suggest making it totally Version 2. Do an 

Re: [weewx-user] Upgrade problems?

[David Hindley]

OK.  Thanks, anyway.

David.

On Mon, 30 Nov 2020 at 19:41, Tom Keffer  wrote:

> It was no tip: it was right there in the error message.
>
> Nov 30 15:27:12 raspberrypi python2[487]: weewx[487] CRITICAL __main__:
> Unable to load driver: [Errno 101] Network is unreachable
>
> -tk
>
> On Mon, Nov 30, 2020 at 9:45 AM David Hindley 
> wrote:
>
>> Solved!!  I had to disconnect the Davis Console from power, remove the
>> batteries, disconnect the Ethernet cable from the console, reconnect and
>> repower. Then the router found the logger again and restarting weewx got it
>> working again. Many thanks for your tip about the port.
>>
>> David.
>>
>> On Mon, 30 Nov 2020 at 17:30, David Hindley 
>> wrote:
>>
>>> When I go into the WeatherLink software, and select Comms Port, Find it
>>> cannot find the device, so something is obviously wrong wi TV the basic set
>>> up.  Any ideas please?
>>>
>>> Many Thanks
>>>
>>> David.
>>>
>>> On Mon, 30 Nov 2020 at 16:50, David Hindley 
>>> wrote:
>>>
 Tom

 Many Thanks for your prompt reply.

 Yes, it’s a WeatherLinkIP. What port would have been closed and how do
 I reopen it?

 Thanks.

 David.

 On Mon, 30 Nov 2020 at 16:36, Tom Keffer  wrote:

> What kind of logger does your Vantage have? If it's a weatherlinkIP,
> it's a network issue. Perhaps your upgrade closed a port?
>
> On Mon, Nov 30, 2020 at 8:21 AM david_h 
> wrote:
>
>> Weewx has stopped working and I think it might be due to me recently
>> upgrading via DEB.
>>
>> When I look at the service status I get:
>>
>> Nov 30 15:27:12 raspberrypi python2[487]: weewx[487] CRITICAL
>> weewx.engine:   return VantageService(engine, config_dict)
>> Nov 30 15:27:12 raspberrypi python2[487]: weewx[487] CRITICAL
>> weewx.engine: File 
>> "/usr/share/weewx/weewx/drivers/vantage.py",
>> line 1898, in __init__
>> Nov 30 15:27:12 raspberrypi python2[487]: weewx[487] CRITICAL
>> weewx.engine:   Vantage.__init__(self,
>> **config_dict[DRIVER_NAME])
>> Nov 30 15:27:12 raspberrypi python2[487]: weewx[487] CRITICAL
>> weewx.engine: File 
>> "/usr/share/weewx/weewx/drivers/vantage.py",
>> line 512, in __init__
>> Nov 30 15:27:12 raspberrypi python2[487]: weewx[487] CRITICAL
>> weewx.engine:   self.port.openPort()
>> Nov 30 15:27:12 raspberrypi python2[487]: weewx[487] CRITICAL
>> weewx.engine: File 
>> "/usr/share/weewx/weewx/drivers/vantage.py",
>> line 344, in openPort
>> Nov 30 15:27:12 raspberrypi python2[487]: weewx[487] CRITICAL
>> weewx.engine:   raise weewx.WeeWxIOError(ex)
>> Nov 30 15:27:12 raspberrypi python2[487]: weewx[487] CRITICAL
>> weewx.engine:   WeeWxIOError: [Errno 101] Network is unreachable
>> Nov 30 15:27:12 raspberrypi python2[487]: weewx[487] CRITICAL
>> __main__: Unable to load driver: [Errno 101] Network is unreachable
>> Nov 30 15:27:12 raspberrypi python2[487]: weewx[487] CRITICAL
>> __main__:   Exiting...
>>
>> Any ideas what is causing the above please?  I opted to retain the
>> existing weewx.conf file, as I use the belchertown skin (an old version 
>> of
>> that, I think).
>>
>> Many thanks
>>
>> David.
>>
> --
>> 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/a01bf34e-fd56-4e73-9e0b-92862eaa45f4n%40googlegroups.com
>> 
>> .
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "weewx-user" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/weewx-user/nhQtoByAgmQ/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> weewx-user+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-user/CAPq0zECyE4pRxnqxNVc3eB72X_NKUP5AVPLEjrpk_3n_2p9U9Q%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
>> 

Re: [weewx-user] Upgrade problems?

[Tom Keffer]

It was no tip: it was right there in the error message.

Nov 30 15:27:12 raspberrypi python2[487]: weewx[487] CRITICAL __main__:
Unable to load driver: [Errno 101] Network is unreachable

-tk

On Mon, Nov 30, 2020 at 9:45 AM David Hindley 
wrote:

> Solved!!  I had to disconnect the Davis Console from power, remove the
> batteries, disconnect the Ethernet cable from the console, reconnect and
> repower. Then the router found the logger again and restarting weewx got it
> working again. Many thanks for your tip about the port.
>
> David.
>
> On Mon, 30 Nov 2020 at 17:30, David Hindley 
> wrote:
>
>> When I go into the WeatherLink software, and select Comms Port, Find it
>> cannot find the device, so something is obviously wrong wi TV the basic set
>> up.  Any ideas please?
>>
>> Many Thanks
>>
>> David.
>>
>> On Mon, 30 Nov 2020 at 16:50, David Hindley 
>> wrote:
>>
>>> Tom
>>>
>>> Many Thanks for your prompt reply.
>>>
>>> Yes, it’s a WeatherLinkIP. What port would have been closed and how do I
>>> reopen it?
>>>
>>> Thanks.
>>>
>>> David.
>>>
>>> On Mon, 30 Nov 2020 at 16:36, Tom Keffer  wrote:
>>>
 What kind of logger does your Vantage have? If it's a weatherlinkIP,
 it's a network issue. Perhaps your upgrade closed a port?

 On Mon, Nov 30, 2020 at 8:21 AM david_h  wrote:

> Weewx has stopped working and I think it might be due to me recently
> upgrading via DEB.
>
> When I look at the service status I get:
>
> Nov 30 15:27:12 raspberrypi python2[487]: weewx[487] CRITICAL
> weewx.engine:   return VantageService(engine, config_dict)
> Nov 30 15:27:12 raspberrypi python2[487]: weewx[487] CRITICAL
> weewx.engine: File 
> "/usr/share/weewx/weewx/drivers/vantage.py",
> line 1898, in __init__
> Nov 30 15:27:12 raspberrypi python2[487]: weewx[487] CRITICAL
> weewx.engine:   Vantage.__init__(self,
> **config_dict[DRIVER_NAME])
> Nov 30 15:27:12 raspberrypi python2[487]: weewx[487] CRITICAL
> weewx.engine: File 
> "/usr/share/weewx/weewx/drivers/vantage.py",
> line 512, in __init__
> Nov 30 15:27:12 raspberrypi python2[487]: weewx[487] CRITICAL
> weewx.engine:   self.port.openPort()
> Nov 30 15:27:12 raspberrypi python2[487]: weewx[487] CRITICAL
> weewx.engine: File 
> "/usr/share/weewx/weewx/drivers/vantage.py",
> line 344, in openPort
> Nov 30 15:27:12 raspberrypi python2[487]: weewx[487] CRITICAL
> weewx.engine:   raise weewx.WeeWxIOError(ex)
> Nov 30 15:27:12 raspberrypi python2[487]: weewx[487] CRITICAL
> weewx.engine:   WeeWxIOError: [Errno 101] Network is unreachable
> Nov 30 15:27:12 raspberrypi python2[487]: weewx[487] CRITICAL
> __main__: Unable to load driver: [Errno 101] Network is unreachable
> Nov 30 15:27:12 raspberrypi python2[487]: weewx[487] CRITICAL
> __main__:   Exiting...
>
> Any ideas what is causing the above please?  I opted to retain the
> existing weewx.conf file, as I use the belchertown skin (an old version of
> that, I think).
>
> Many thanks
>
> David.
>
 --
> 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/a01bf34e-fd56-4e73-9e0b-92862eaa45f4n%40googlegroups.com
> 
> .
>
 --
 You received this message because you are subscribed to a topic in the
 Google Groups "weewx-user" group.
 To unsubscribe from this topic, visit
 https://groups.google.com/d/topic/weewx-user/nhQtoByAgmQ/unsubscribe.
 To unsubscribe from this group and all its topics, send an email to
 weewx-user+unsubscr...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/weewx-user/CAPq0zECyE4pRxnqxNVc3eB72X_NKUP5AVPLEjrpk_3n_2p9U9Q%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/CAKbmhJQ5bj3LpkXBe1Q9i0GuO6b%2Bg1rvXyuAp1dK7HVyLVA-mA%40mail.gmail.com
> 

Re: [weewx-user] Wrong monthly average temperature

[Tom Keffer]

I think I found the problem. The version number was inadvertently being
truncated from '2.0' to '2'. Later, the weighting factor is determined as:

weight = 60.0 * record['interval'] if self.version >= '2.0' else 1.0

Because '2' collates ahead of '2.0', the weight was set to 1.0.

Fixed in commit 9510f38

.

Michael, if you want to apply the fix to your copy, go into
weewx/manager.py. Around line 827 change this

v = self._read_metadata('Version')
self.version = v[0] if v is not None else "1.0"

to this

self.version = self._read_metadata('Version')
if self.version is None:
self.version = '1.0'

Thanks, Michael, for your diligence in drawing this to my attention.

I don't know why so many of your messages keep going to spam. I keep
telling Google Groups to allow all messages from you to pass, but it
doesn't always pay attention.

-tk




On Mon, Nov 30, 2020 at 11:06 AM michael.k...@gmx.at <
michael.kainzba...@gmx.at> wrote:

> Hello again,
>
> What happens now is: metadata says "Version 2.0", weewx is currently
> producing "Version 1.0" numbers (4.2.0). So I am afraid, when I follow your
> advice and and recalculate "Version 2.0" values, tomorrow I'll end up
> having mixed values again.
>
> I checked a database snapshot BEFORE I updated t0 4.2.0:
>
> Version 2.0
>
> It didn't change during the update.
>
> Here  are some entries from archive_day_outTemp AFTER the update to 4.2.0,
> but BEFORE I manually changed to Version 1.0 Nuumbers: (dateTime DESC)
>
> 1605481200 1.4 1605493171 8.9 1605535929 1811.52088383838 288
> 1811.52088383838 288
> 1605394800 2.1 1605473931 16.1 1605445486 2346.52735930736 288
> 2346.52735930736 288
> 1605308400 5.5 1605328978 17.3 1605360608 2590.47363636364 288
> 650228.309292929 69058
> 1605222000 4.0 1605238302 14.9 1605272440 2255.38090909091 288
> 676614.272727273 86400
> 1605135600 2.7 1605160230 12.0 1605186834 1942.27053030303 288
> 582681.159090909 86400
>
> Weewx just "decided" to produce Version 1.0 Number after the update an
> mixing both oh the particular day.
>
> Now something also very interesting, the following lines are from a
> friend's database, two days before and after the update: (dateTime DESC)
> 1604098800 5.1 1604184954 15.8 1604153156 3087.89794733045 288
> 3087.89794733045 288
> 1604012400 6.9 1604022829 12.6 1604059984 2970.48686868687 288
> 2970.48686868687 288
> 1603926000 5.6 1603926667 9.7 1603970504 2352.86239898999 288
> 235090.302070707 30188
> 1603839600 -1.2 1603859547 11.9 1603896779 1507.83905483406 288
> 452351.716450217 86400
> 1603753200 0.29997 1603839591 9.9 1603808400 1324.44158008658 288
> 397332.474025974 86400
>
> The same happened, he ales has Version 2.0 in metadata, Version 2.0
> numbers before the update, mixed on the day of the update and Version 1.0
> after the update. But his average calculation still works.
>
> So somehow something happened. @all Readers: can you check your database
> before and after the upgrade? Is anybody seeing the same behavior? We, my
> friend an me, have very similar installations, maybe the same quirksy
> config? Or maybe this is more widespread, but most of the users don't
> recognise the effects?
>
>
> tke...@gmail.com schrieb am Montag, 30. November 2020 um 15:20:21 UTC+1:
>
>> Michael, I have no idea what happened, but if you want to modify your
>> daily summaries, it should be done right. If I understand you correctly,
>> you patched them with SQL commands like
>>
>> update archive_day_ET set wsum=sum, sumtime=count;
>> update archive_day_UV set wsum=sum, sumtime=count;
>> update archive_day_altimeter set wsum=sum, sumtime=count;
>> etc.
>>
>> This will leave your summaries in an inconsistent state: the numbers are
>> what would be expected for a Version 1 summary, yet your metadata will say
>> Version 2. Furthermore, as new days are added, Version 2 numbers will be
>> used, and you'll be back where you started: with half Version 1 and half
>> Version 2.
>>
>> I would suggest making it totally Version 2. Do an update, except weight
>> them with the archive interval. This will work if your archive interval is
>> a constant 5 minutes (300 seconds):
>>
>> 1. Stop weewx.
>> 2. Make a backup of weewx.sdb
>> 3. Use updates that look like:
>>
>> update archive_day_ET set wsum=sum*300, sumtime=count*300;
>> update archive_day_UV set wsum=sum*300, sumtime=count*300;
>> update archive_day_altimeter set wsum=sum*300, sumtime=count*300;
>> etc.
>>
>> 4. Restart weewx
>>
>>
>>
>> On Sun, Nov 29, 2020 at 11:36 AM michael.k...@gmx.at 
>> wrote:
>>
>>>
>>> https://imgur.com/a/yZUPoTq
>>>
>> michael.k...@gmx.at schrieb am Samstag, 28. November 2020 um 09:27:44
>>> UTC+1:
>>>
>>
 I am observing the same situation, as well as other WeeWX users near
 me. The average is clearly off since the 4.2.0 update. It also affects
 yearly average since then. So I guess this is 

[weewx-user] Re: Vantage ip-read error with VVP

[John S]

I've used your config for systemd and it solved my problem with the dreaded 
ip-read error. Thanks for the tip and tutorial!
J. Sergneri

On Thursday, March 14, 2019 at 3:24:25 PM UTC-7 Peter Fletcher wrote:

>
>
> On Thursday, March 14, 2019 at 5:06:18 PM UTC-5, jmviper wrote:
>>
>> Ok done and running without problems. 
>>
>> I always connect as root on the orangepipc (with armbian) and manage 
>> weewx with service weewx (start|stop|restart|reload)
>>
>  
> A systemd service is managed using systemctl, so you would now say:
> sudo systemctl start|stop|restart|reload weewx.service
>  
>
>>
>> One silly question  though I suppose not a weewx upgrade will 
>> overwrite these changes ?? 
>>
>>  
> No. You haven't changed the weewx code or configuration, just how and 
> under whose control the program is started, so upgrading weewx will not 
> affect the change to using systemd directly to run it. 
>
> I hope this works well
>>
>> Thanks again
>>
>
>
>
>

-- 
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/269e0981-43e1-4354-8597-8fcf394719b5n%40googlegroups.com.

Re: [weewx-user] Wrong monthly average temperature

[michael.k...@gmx.at]

Hello again,

What happens now is: metadata says "Version 2.0", weewx is currently 
producing "Version 1.0" numbers (4.2.0). So I am afraid, when I follow your 
advice and and recalculate "Version 2.0" values, tomorrow I'll end up 
having mixed values again.

I checked a database snapshot BEFORE I updated t0 4.2.0:

Version 2.0

It didn't change during the update.

Here  are some entries from archive_day_outTemp AFTER the update to 4.2.0, 
but BEFORE I manually changed to Version 1.0 Nuumbers: (dateTime DESC)

1605481200 1.4 1605493171 8.9 1605535929 1811.52088383838 288 
1811.52088383838 288
1605394800 2.1 1605473931 16.1 1605445486 2346.52735930736 288 
2346.52735930736 288
1605308400 5.5 1605328978 17.3 1605360608 2590.47363636364 288 
650228.309292929 69058
1605222000 4.0 1605238302 14.9 1605272440 2255.38090909091 288 
676614.272727273 86400
1605135600 2.7 1605160230 12.0 1605186834 1942.27053030303 288 
582681.159090909 86400

Weewx just "decided" to produce Version 1.0 Number after the update an 
mixing both oh the particular day.

Now something also very interesting, the following lines are from a 
friend's database, two days before and after the update: (dateTime DESC)
1604098800 5.1 1604184954 15.8 1604153156 3087.89794733045 288 
3087.89794733045 288
1604012400 6.9 1604022829 12.6 1604059984 2970.48686868687 288 
2970.48686868687 288
1603926000 5.6 1603926667 9.7 1603970504 2352.86239898999 288 
235090.302070707 30188
1603839600 -1.2 1603859547 11.9 1603896779 1507.83905483406 288 
452351.716450217 86400
1603753200 0.29997 1603839591 9.9 1603808400 1324.44158008658 288 
397332.474025974 86400

The same happened, he ales has Version 2.0 in metadata, Version 2.0 numbers 
before the update, mixed on the day of the update and Version 1.0 after the 
update. But his average calculation still works.

So somehow something happened. @all Readers: can you check your database 
before and after the upgrade? Is anybody seeing the same behavior? We, my 
friend an me, have very similar installations, maybe the same quirksy 
config? Or maybe this is more widespread, but most of the users don't 
recognise the effects?


tke...@gmail.com schrieb am Montag, 30. November 2020 um 15:20:21 UTC+1:

> Michael, I have no idea what happened, but if you want to modify your 
> daily summaries, it should be done right. If I understand you correctly, 
> you patched them with SQL commands like
>
> update archive_day_ET set wsum=sum, sumtime=count;
> update archive_day_UV set wsum=sum, sumtime=count;
> update archive_day_altimeter set wsum=sum, sumtime=count;
> etc.
>
> This will leave your summaries in an inconsistent state: the numbers are 
> what would be expected for a Version 1 summary, yet your metadata will say 
> Version 2. Furthermore, as new days are added, Version 2 numbers will be 
> used, and you'll be back where you started: with half Version 1 and half 
> Version 2. 
>
> I would suggest making it totally Version 2. Do an update, except weight 
> them with the archive interval. This will work if your archive interval is 
> a constant 5 minutes (300 seconds):
>
> 1. Stop weewx.
> 2. Make a backup of weewx.sdb
> 3. Use updates that look like:
>
> update archive_day_ET set wsum=sum*300, sumtime=count*300;
> update archive_day_UV set wsum=sum*300, sumtime=count*300;
> update archive_day_altimeter set wsum=sum*300, sumtime=count*300;
> etc.
>
> 4. Restart weewx
>
>
>
> On Sun, Nov 29, 2020 at 11:36 AM michael.k...@gmx.at  
> wrote:
>
>>
>> https://imgur.com/a/yZUPoTq
>>
> michael.k...@gmx.at schrieb am Samstag, 28. November 2020 um 09:27:44 
>> UTC+1:
>>
>
>>> I am observing the same situation, as well as other WeeWX users near me. 
>>> The average is clearly off since the 4.2.0 update. It also affects yearly 
>>> average since then. So I guess this is something that happened with the 
>>> 4.2.0 Version. I don't want to rebuild my daily values, how to find the bad 
>>> values and correct them? Probably in the archive_daily table of the day I 
>>> made the update?
>>>
>>> I found something: It's a change with "sum":
>>> 1-13 has "new" sumtime, 14 a mix (the day I updated) and old sumtime are 
>>> 15 and and older:
>>>
>>> Isn't there a config that sets how this is calculated?
>>>
>>>
>>> b.cl...@gmail.com schrieb am Donnerstag, 19. November 2020 um 19:43:57 
>>> UTC+1:
>>>
 Yeah, everything looks great again.
 Thank you Tom for that excellent support. 
 Greetings from Suedlohn (Germany).
 Berny

 tke...@gmail.com schrieb am Donnerstag, 19. November 2020 um 17:56:56 
 UTC+1:

> So, for some reason, the weighted sum (field 'wsum') has too high a 
> value, or the sum of observation time (field 'sumtime') has too low a 
> value.
>
> The easiest fix is to just rebuild the daily summaries using the 
> wee_database 
> utility 
> .
>
> Stop weewxd. then,
>
> *wee_database --drop-daily*

Re: [weewx-user] Wrong monthly average temperature

[michael.k...@gmx.at]

Hello again,

What happens now is: metadata says "Version 2.0", weewx is currently 
producing "Version 1.0" numbers (4.2.0). So I am afraid, when I follow your 
advice and and recalculate "Version 2.0" values, tomorrow I'll end up 
having mixed values again.

I checked a database snapshot BEFORE I updated t0 4.2.0:

Version 2.0

It didn't change during the update.

Here  are some entries from archive_day_outTemp AFTER the update to 4.2.0, 
but BEFORE I manually changed to Version 1.0 Nuumbers: (dateTime DESC)

1605481200 1.4 1605493171 8.9 1605535929 1811.52088383838 288 
1811.52088383838 288
1605394800 2.1 1605473931 16.1 1605445486 2346.52735930736 288 
2346.52735930736 288
1605308400 5.5 1605328978 17.3 1605360608 2590.47363636364 288 
650228.309292929 69058
1605222000 4.0 1605238302 14.9 1605272440 2255.38090909091 288 
676614.272727273 86400
1605135600 2.7 1605160230 12.0 1605186834 1942.27053030303 288 
582681.159090909 86400

Weewx just "decided" to produce Version 1.0 Number after the update an 
mixing both oh the particular day.

Now something also very interesting, the following lines are from a 
friend's database, two days before and after the update: (dateTime DESC)
1604098800 5.1 1604184954 15.8 1604153156 3087.89794733045 288 
3087.89794733045 288
1604012400 6.9 1604022829 12.6 1604059984 2970.48686868687 288 
2970.48686868687 288
1603926000 5.6 1603926667 9.7 1603970504 2352.86239898999 288 
235090.302070707 30188
1603839600 -1.2 1603859547 11.9 1603896779 1507.83905483406 288 
452351.716450217 86400
1603753200 0.29997 1603839591 9.9 1603808400 1324.44158008658 288 
397332.474025974 86400

The same happened, he ales has Version 2.0 in metadata, Version 2.0 numbers 
before the update, mixed on the day of the update and Version 1.0 after the 
update. But his average calculation still works.

So somehow something happened. @all Readers: can you check your database 
before and after the upgrade? Is anybody seeing the same behavior? We, my 
friend an me, have very similar installations, maybe the same quirksy 
config? Or maybe this is more widespread, but most of the users don't 
recognise the effects?
tke...@gmail.com schrieb am Montag, 30. November 2020 um 15:20:21 UTC+1:

> Michael, I have no idea what happened, but if you want to modify your 
> daily summaries, it should be done right. If I understand you correctly, 
> you patched them with SQL commands like
>
> update archive_day_ET set wsum=sum, sumtime=count;
> update archive_day_UV set wsum=sum, sumtime=count;
> update archive_day_altimeter set wsum=sum, sumtime=count;
> etc.
>
> This will leave your summaries in an inconsistent state: the numbers are 
> what would be expected for a Version 1 summary, yet your metadata will say 
> Version 2. Furthermore, as new days are added, Version 2 numbers will be 
> used, and you'll be back where you started: with half Version 1 and half 
> Version 2. 
>
> I would suggest making it totally Version 2. Do an update, except weight 
> them with the archive interval. This will work if your archive interval is 
> a constant 5 minutes (300 seconds):
>
> 1. Stop weewx.
> 2. Make a backup of weewx.sdb
> 3. Use updates that look like:
>
> update archive_day_ET set wsum=sum*300, sumtime=count*300;
> update archive_day_UV set wsum=sum*300, sumtime=count*300;
> update archive_day_altimeter set wsum=sum*300, sumtime=count*300;
> etc.
>
> 4. Restart weewx
>
>
>
> On Sun, Nov 29, 2020 at 11:36 AM michael.k...@gmx.at  
> wrote:
>
>>
>> https://imgur.com/a/yZUPoTq
>>
> michael.k...@gmx.at schrieb am Samstag, 28. November 2020 um 09:27:44 
>> UTC+1:
>>
>
>>> I am observing the same situation, as well as other WeeWX users near me. 
>>> The average is clearly off since the 4.2.0 update. It also affects yearly 
>>> average since then. So I guess this is something that happened with the 
>>> 4.2.0 Version. I don't want to rebuild my daily values, how to find the bad 
>>> values and correct them? Probably in the archive_daily table of the day I 
>>> made the update?
>>>
>>> I found something: It's a change with "sum":
>>> 1-13 has "new" sumtime, 14 a mix (the day I updated) and old sumtime are 
>>> 15 and and older:
>>>
>>> Isn't there a config that sets how this is calculated?
>>>
>>>
>>> b.cl...@gmail.com schrieb am Donnerstag, 19. November 2020 um 19:43:57 
>>> UTC+1:
>>>
 Yeah, everything looks great again.
 Thank you Tom for that excellent support. 
 Greetings from Suedlohn (Germany).
 Berny

 tke...@gmail.com schrieb am Donnerstag, 19. November 2020 um 17:56:56 
 UTC+1:

> So, for some reason, the weighted sum (field 'wsum') has too high a 
> value, or the sum of observation time (field 'sumtime') has too low a 
> value.
>
> The easiest fix is to just rebuild the daily summaries using the 
> wee_database 
> utility 
> .
>
> Stop weewxd. then,
>
> *wee_database --drop-daily*

Re: [weewx-user] Wrong monthly average temperature

[michael.k...@gmx.at]

Hello again,

What happens now is: metadata says "Version 2.0", weewx is currently 
producing "Version 1.0" numbers (4.2.0). So I am afraid, when I follow your 
advice and and recalculate "Version 2.0" values, tomorrow I'll end up 
having mixed values again.

I checked a database snapshot BEFORE I updated t0 4.2.0:

Version 2.0

It didn't change during the update.

Here  are some entries from archive_day_outTemp AFTER the update to 4.2.0, 
but BEFORE I manually changed to Version 1.0 Nuumbers: (dateTime DESC)

16054812001.416054931718.916055359291811.52088383838
2881811.52088383838288
16053948002.1160547393116.11605445486
2346.527359307362882346.52735930736288
16053084005.5160532897817.31605360608
2590.47363636364288650228.30929292969058
16052220004.0160523830214.91605272440
2255.38090909091288676614.27272727386400
16051356002.7160516023012.01605186834
1942.27053030303288582681.15909090986400

Weewx just "decided" to produce Version 1.0 Number after the update an 
mixing both oh the particular day.

Now something also very interesting, the following lines are from a 
friend's database, two days before and after the update: (dateTime DESC)
16040988005.1160418495415.81604153156
3087.897947330452883087.89794733045288
16040124006.9160402282912.61604059984
2970.486868686872882970.48686868687288
16039260005.616039266679.716039705042352.86239898999
288235090.30207070730188
1603839600-1.2160385954711.91603896779
1507.83905483406288452351.71645021786400
16037532000.2999716038395919.91603808400
1324.44158008658288397332.47402597486400

The same happened, he ales has Version 2.0 in metadata, Version 2.0 numbers 
before the update, mixed on the day of the update and Version 1.0 after the 
update. But his average calculation still works.

So somehow something happened. @all Readers: can you check your database 
before and after the upgrade? Is anybody seeing the same behavior? We, my 
friend an me, have very similar installations, maybe the same quirksy 
config? Or maybe this is more widespread, but most of the users don't 
recognise the effects?


tke...@gmail.com schrieb am Montag, 30. November 2020 um 15:20:21 UTC+1:

> Michael, I have no idea what happened, but if you want to modify your 
> daily summaries, it should be done right. If I understand you correctly, 
> you patched them with SQL commands like
>
> update archive_day_ET set wsum=sum, sumtime=count;
> update archive_day_UV set wsum=sum, sumtime=count;
> update archive_day_altimeter set wsum=sum, sumtime=count;
> etc.
>
> This will leave your summaries in an inconsistent state: the numbers are 
> what would be expected for a Version 1 summary, yet your metadata will say 
> Version 2. Furthermore, as new days are added, Version 2 numbers will be 
> used, and you'll be back where you started: with half Version 1 and half 
> Version 2. 
>
> I would suggest making it totally Version 2. Do an update, except weight 
> them with the archive interval. This will work if your archive interval is 
> a constant 5 minutes (300 seconds):
>
> 1. Stop weewx.
> 2. Make a backup of weewx.sdb
> 3. Use updates that look like:
>
> update archive_day_ET set wsum=sum*300, sumtime=count*300;
> update archive_day_UV set wsum=sum*300, sumtime=count*300;
> update archive_day_altimeter set wsum=sum*300, sumtime=count*300;
> etc.
>
> 4. Restart weewx
>
>
>
> On Sun, Nov 29, 2020 at 11:36 AM michael.k...@gmx.at  
> wrote:
>
>>
>> https://imgur.com/a/yZUPoTq
>>
> michael.k...@gmx.at schrieb am Samstag, 28. November 2020 um 09:27:44 
>> UTC+1:
>>
>
>>> I am observing the same situation, as well as other WeeWX users near me. 
>>> The average is clearly off since the 4.2.0 update. It also affects yearly 
>>> average since then. So I guess this is something that happened with the 
>>> 4.2.0 Version. I don't want to rebuild my daily values, how to find the bad 
>>> values and correct them? Probably in the archive_daily table of the day I 
>>> made the update?
>>>
>>> I found something: It's a change with "sum":
>>> 1-13 has "new" sumtime, 14 a mix (the day I updated) and old sumtime are 
>>> 15 and and older:
>>>
>>> Isn't there a config that sets how this is calculated?
>>>
>>>
>>> b.cl...@gmail.com schrieb am Donnerstag, 19. November 2020 um 19:43:57 
>>> UTC+1:
>>>
 Yeah, everything looks great again.
 Thank you Tom for that excellent support. 
 Greetings from Suedlohn (Germany).
 Berny

 tke...@gmail.com schrieb am Donnerstag, 19. November 2020 um 17:56:56 
 UTC+1:

> So, for some reason, the weighted sum (field 'wsum') has too high a 
> value, or the sum of observation time (field 'sumtime') has too low a 
> value.
>
> 

Re: [weewx-user] Wrong monthly average temperature

[michael.k...@gmx.at]

Hello again,

What happens now is: metadata says "Version 2.0", weewx is currently 
producing "Version 1.0" numbers (4.2.0). So I am afraid, when I follow your 
advice and and recalculate "Version 2.0" values, tomorrow I'll end up 
having mixed values again.

I checked a database snapshot BEFORE I updated t0 4.2.0:

Version 2.0

It didn't change during the update.

Here  are some entries from archive_day_outTemp AFTER the update to 4.2.0, 
but BEFORE I manually changed to Version 1.0 Nuumbers: (dateTime DESC)

16054812001.416054931718.916055359291811.52088383838
2881811.52088383838288
16053948002.1160547393116.11605445486
2346.527359307362882346.52735930736288
16053084005.5160532897817.31605360608
2590.47363636364288650228.30929292969058
16052220004.0160523830214.91605272440
2255.38090909091288676614.27272727386400
16051356002.7160516023012.01605186834
1942.27053030303288582681.15909090986400

Weewx just "decided" to produce Version 1.0 Number after the update an 
mixing both oh the particular day.

Now something also very interesting, the following lines are from a 
friend's database, two days before and after the update: (dateTime DESC)
16040988005.1160418495415.81604153156
3087.897947330452883087.89794733045288
16040124006.9160402282912.61604059984
2970.486868686872882970.48686868687288
16039260005.616039266679.716039705042352.86239898999
288235090.30207070730188
1603839600-1.2160385954711.91603896779
1507.83905483406288452351.71645021786400
16037532000.2999716038395919.91603808400
1324.44158008658288397332.47402597486400

The same happened, he ales has Version 2.0 in metadata, Version 2.0 numbers 
before the update, mixed on the day of the update and Version 1.0 after the 
update. But his average calculation still works.

So somehow something happened. @all Readers: can you check your database 
before and after the upgrade? Is anybody seeing the same behavior? We, my 
friend an me, have very similar installations, maybe the same quirksy 
config? Or maybe this is more widespread, but most of the users don't 
recognise the effects?



tke...@gmail.com schrieb am Montag, 30. November 2020 um 15:20:21 UTC+1:

> Michael, I have no idea what happened, but if you want to modify your 
> daily summaries, it should be done right. If I understand you correctly, 
> you patched them with SQL commands like
>
> update archive_day_ET set wsum=sum, sumtime=count;
> update archive_day_UV set wsum=sum, sumtime=count;
> update archive_day_altimeter set wsum=sum, sumtime=count;
> etc.
>
> This will leave your summaries in an inconsistent state: the numbers are 
> what would be expected for a Version 1 summary, yet your metadata will say 
> Version 2. Furthermore, as new days are added, Version 2 numbers will be 
> used, and you'll be back where you started: with half Version 1 and half 
> Version 2. 
>
> I would suggest making it totally Version 2. Do an update, except weight 
> them with the archive interval. This will work if your archive interval is 
> a constant 5 minutes (300 seconds):
>
> 1. Stop weewx.
> 2. Make a backup of weewx.sdb
> 3. Use updates that look like:
>
> update archive_day_ET set wsum=sum*300, sumtime=count*300;
> update archive_day_UV set wsum=sum*300, sumtime=count*300;
> update archive_day_altimeter set wsum=sum*300, sumtime=count*300;
> etc.
>
> 4. Restart weewx
>
>
>
> On Sun, Nov 29, 2020 at 11:36 AM michael.k...@gmx.at  
> wrote:
>
>>
>> https://imgur.com/a/yZUPoTq
>>
> michael.k...@gmx.at schrieb am Samstag, 28. November 2020 um 09:27:44 
>> UTC+1:
>>
>
>>> I am observing the same situation, as well as other WeeWX users near me. 
>>> The average is clearly off since the 4.2.0 update. It also affects yearly 
>>> average since then. So I guess this is something that happened with the 
>>> 4.2.0 Version. I don't want to rebuild my daily values, how to find the bad 
>>> values and correct them? Probably in the archive_daily table of the day I 
>>> made the update?
>>>
>>> I found something: It's a change with "sum":
>>> 1-13 has "new" sumtime, 14 a mix (the day I updated) and old sumtime are 
>>> 15 and and older:
>>>
>>> Isn't there a config that sets how this is calculated?
>>>
>>>
>>> b.cl...@gmail.com schrieb am Donnerstag, 19. November 2020 um 19:43:57 
>>> UTC+1:
>>>
 Yeah, everything looks great again.
 Thank you Tom for that excellent support. 
 Greetings from Suedlohn (Germany).
 Berny

 tke...@gmail.com schrieb am Donnerstag, 19. November 2020 um 17:56:56 
 UTC+1:

> So, for some reason, the weighted sum (field 'wsum') has too high a 
> value, or the sum of observation time (field 'sumtime') has too low a 
> value.
>
> 

Re: [weewx-user] Wrong monthly average temperature

[michael.k...@gmx.at]

My Post gets deleted, why?

tke...@gmail.com schrieb am Montag, 30. November 2020 um 15:20:21 UTC+1:

> Michael, I have no idea what happened, but if you want to modify your 
> daily summaries, it should be done right. If I understand you correctly, 
> you patched them with SQL commands like
>
> update archive_day_ET set wsum=sum, sumtime=count;
> update archive_day_UV set wsum=sum, sumtime=count;
> update archive_day_altimeter set wsum=sum, sumtime=count;
> etc.
>
> This will leave your summaries in an inconsistent state: the numbers are 
> what would be expected for a Version 1 summary, yet your metadata will say 
> Version 2. Furthermore, as new days are added, Version 2 numbers will be 
> used, and you'll be back where you started: with half Version 1 and half 
> Version 2. 
>
> I would suggest making it totally Version 2. Do an update, except weight 
> them with the archive interval. This will work if your archive interval is 
> a constant 5 minutes (300 seconds):
>
> 1. Stop weewx.
> 2. Make a backup of weewx.sdb
> 3. Use updates that look like:
>
> update archive_day_ET set wsum=sum*300, sumtime=count*300;
> update archive_day_UV set wsum=sum*300, sumtime=count*300;
> update archive_day_altimeter set wsum=sum*300, sumtime=count*300;
> etc.
>
> 4. Restart weewx
>
>
>
> On Sun, Nov 29, 2020 at 11:36 AM michael.k...@gmx.at  
> wrote:
>
>>
>> https://imgur.com/a/yZUPoTq
>>
> michael.k...@gmx.at schrieb am Samstag, 28. November 2020 um 09:27:44 
>> UTC+1:
>>
>
>>> I am observing the same situation, as well as other WeeWX users near me. 
>>> The average is clearly off since the 4.2.0 update. It also affects yearly 
>>> average since then. So I guess this is something that happened with the 
>>> 4.2.0 Version. I don't want to rebuild my daily values, how to find the bad 
>>> values and correct them? Probably in the archive_daily table of the day I 
>>> made the update?
>>>
>>> I found something: It's a change with "sum":
>>> 1-13 has "new" sumtime, 14 a mix (the day I updated) and old sumtime are 
>>> 15 and and older:
>>>
>>> Isn't there a config that sets how this is calculated?
>>>
>>>
>>> b.cl...@gmail.com schrieb am Donnerstag, 19. November 2020 um 19:43:57 
>>> UTC+1:
>>>
 Yeah, everything looks great again.
 Thank you Tom for that excellent support. 
 Greetings from Suedlohn (Germany).
 Berny

 tke...@gmail.com schrieb am Donnerstag, 19. November 2020 um 17:56:56 
 UTC+1:

> So, for some reason, the weighted sum (field 'wsum') has too high a 
> value, or the sum of observation time (field 'sumtime') has too low a 
> value.
>
> The easiest fix is to just rebuild the daily summaries using the 
> wee_database 
> utility 
> .
>
> Stop weewxd. then,
>
> *wee_database --drop-daily*
> *wee_database --rebuild-daily*
>
> Restart weewxd
>
> For a database of your size, it shouldn't take more than a minute or 
> two.
>
> It could take some time for the NOAA and html files to get corrected. 
> You can speed things up by deleting them and allowing weewx to regenerate 
> them.
>
> -tk
>
>
>
> On Thu, Nov 19, 2020 at 8:48 AM Berny Cl  wrote:
>
>> sqlite> select sum(wsum)/sum(sumtime) from archive_day_outTemp where 
>> strftime("%Y-%m",dateTime,'unixepoch','localtime')=='2020-11';
>> 60.1308595259353
>>
>> Ok, that looks the same like the value in my history table. 
>>
>> tke...@gmail.com schrieb am Donnerstag, 19. November 2020 um 
>> 17:13:38 UTC+1:
>>
>>> 1. That looks reasonable. One other query to try:
>>>
>>> sqlite> *select sum(wsum)/sum(sumtime) from archive_day_outTemp 
>>> where strftime("%Y-%m",dateTime,'unixepoch','localtime')=='2020-11';*
>>>
>>> 2. If that doesn't reveal anything, I will send you an instrumented 
>>> version of xtypes.py that will log the calculation.
>>>
>>>
>>> On Thu, Nov 19, 2020 at 6:44 AM Berny Cl  wrote:
>>>
 sqlite> select avg(outTemp) from archive where strftime("%Y-%m", 
 dateTime,'unixepoch','localtime')=='2020-11';
 51.117818676717 <(781)%20867-6717>
 sqlite> select sum(sum)/sum(count) from archive_day_outTemp where 
 strftime("%Y-%m",dateTime,'unixepoch','localtime')=='2020-11';
 51.114923603352

 Thank you!
 OK, I did that. The two numbers are very close. I think they are 
 correct (in Fahrenheit) but in my history table the temperature ist 
 too 
 high (in degree Celsius).

 tke...@gmail.com schrieb am Donnerstag, 19. November 2020 um 
 15:02:55 UTC+1:

> Most likely it's some bad data. Let's check the database directly. 
>
> First find the database. If you did a package install, it's most 
> likely at /var/lib/weewx/weewx.sdb. 

Re: [weewx-user] Wrong monthly average temperature

[michael.k...@gmx.at]

I save my database hourly, keep these snapshots for a day, keep daily 
snapshots for a month... and so on.

>From a database snapshot before I upgraded, archive_day__metadata says: 
 "Version 2.0" 
It didn't change during the update.

Here is an entry of "archive_day_outTemp": (also from a snapshot before the 
update)
1604876400 -0.101 1604903428 9.3 1604925619 1065.95282828283 288 
319785.848484848 86400

After the update weewx was producing these lines (first and second), the 
third line is the day with the update, fourth and fifth is before the 
update.
(from a snapshot after the update, but before my sql-patch)

1605481200 1.4 1605493171 8.9 1605535929 1811.52088383838 288 
1811.52088383838 288
1605394800 2.1 1605473931 16.1 1605445486 2346.52735930736 288 
2346.52735930736 288
1605308400 5.5 1605328978 17.3 1605360608 2590.47363636364 288 
650228.309292929 69058
1605222000 4.0 1605238302 14.9 1605272440 2255.38090909091 288 
676614.272727273 86400
1605135600 2.7 1605160230 12.0 1605186834 1942.27053030303 288 
582681.159090909 86400

So the behavior changed after the update. If I now alter the database with 
your suggested queries, I'm afraid ending up having the unweigthed entries 
written, like weewx now writes them and then having the problem all over 
again.

Here are some lines of a friend's database. He didn't observe any problems 
with his average values:

1604098800 5.1 1604184954 15.8 1604153156 3087.89794733045 288 
3087.89794733045 288
1604012400 6.9 1604022829 12.6 1604059984 2970.48686868687 288 
2970.48686868687 288
1603926000 5.6 1603926667 9.7 1603970504 2352.8623989899 288 
235090.302070707 30188
1603839600 -1.2 1603859547 11.9 1603896779 1507.83905483406 288 
452351.716450217 86400
1603753200 0.29997 1603839591 9.9 1603808400 1324.44158008658 288 
397332.474025974 86400

I let you guess, which day he updated to 4.2.0 :)
But his average calculation still works. He also has "Version 2.0", but he 
doesn't have a db snapshot from a day before the update.
tke...@gmail.com schrieb am Montag, 30. November 2020 um 15:20:21 UTC+1:

> Michael, I have no idea what happened, but if you want to modify your 
> daily summaries, it should be done right. If I understand you correctly, 
> you patched them with SQL commands like
>
> update archive_day_ET set wsum=sum, sumtime=count;
> update archive_day_UV set wsum=sum, sumtime=count;
> update archive_day_altimeter set wsum=sum, sumtime=count;
> etc.
>
> This will leave your summaries in an inconsistent state: the numbers are 
> what would be expected for a Version 1 summary, yet your metadata will say 
> Version 2. Furthermore, as new days are added, Version 2 numbers will be 
> used, and you'll be back where you started: with half Version 1 and half 
> Version 2. 
>
> I would suggest making it totally Version 2. Do an update, except weight 
> them with the archive interval. This will work if your archive interval is 
> a constant 5 minutes (300 seconds):
>
> 1. Stop weewx.
> 2. Make a backup of weewx.sdb
> 3. Use updates that look like:
>
> update archive_day_ET set wsum=sum*300, sumtime=count*300;
> update archive_day_UV set wsum=sum*300, sumtime=count*300;
> update archive_day_altimeter set wsum=sum*300, sumtime=count*300;
> etc.
>
> 4. Restart weewx
>
>
>
> On Sun, Nov 29, 2020 at 11:36 AM michael.k...@gmx.at  
> wrote:
>
>>
>> https://imgur.com/a/yZUPoTq
>>
> michael.k...@gmx.at schrieb am Samstag, 28. November 2020 um 09:27:44 
>> UTC+1:
>>
>
>>> I am observing the same situation, as well as other WeeWX users near me. 
>>> The average is clearly off since the 4.2.0 update. It also affects yearly 
>>> average since then. So I guess this is something that happened with the 
>>> 4.2.0 Version. I don't want to rebuild my daily values, how to find the bad 
>>> values and correct them? Probably in the archive_daily table of the day I 
>>> made the update?
>>>
>>> I found something: It's a change with "sum":
>>> 1-13 has "new" sumtime, 14 a mix (the day I updated) and old sumtime are 
>>> 15 and and older:
>>>
>>> Isn't there a config that sets how this is calculated?
>>>
>>>
>>> b.cl...@gmail.com schrieb am Donnerstag, 19. November 2020 um 19:43:57 
>>> UTC+1:
>>>
 Yeah, everything looks great again.
 Thank you Tom for that excellent support. 
 Greetings from Suedlohn (Germany).
 Berny

 tke...@gmail.com schrieb am Donnerstag, 19. November 2020 um 17:56:56 
 UTC+1:

> So, for some reason, the weighted sum (field 'wsum') has too high a 
> value, or the sum of observation time (field 'sumtime') has too low a 
> value.
>
> The easiest fix is to just rebuild the daily summaries using the 
> wee_database 
> utility 
> .
>
> Stop weewxd. then,
>
> *wee_database --drop-daily*
> *wee_database --rebuild-daily*
>
> Restart weewxd
>
> For a database of your size, it shouldn't take 

[weewx-user] Wrong monthly average temperature (Follow up)

[michael.k...@gmx.at]

I can't post to the other anymore, my messages get deleted almost 
instantly. So I have to try it again in a new thread:

 Hello again,

What happens now is: metadata says "Version 2.0", weewx is currently 
producing "Version 1.0" numbers (4.2.0). So I am afraid, when I follow your 
advice and and recalculate "Version 2.0" values, tomorrow I'll end up 
having mixed values again.

I checked a database snapshot BEFORE I updated t0 4.2.0:

Version 2.0

It didn't change during the update.

Here  are some entries from archive_day_outTemp AFTER the update to 4.2.0, 
but BEFORE I manually changed to Version 1.0 Nuumbers: (dateTime DESC)

1605481200 1.4 1605493171 8.9 1605535929 1811.52088383838 288 
1811.52088383838 288
1605394800 2.1 1605473931 16.1 1605445486 2346.52735930736 288 
2346.52735930736 288
1605308400 5.5 1605328978 17.3 1605360608 2590.47363636364 288 
650228.309292929 69058
1605222000 4.0 1605238302 14.9 1605272440 2255.38090909091 288 
676614.272727273 86400
1605135600 2.7 1605160230 12.0 1605186834 1942.27053030303 288 
582681.159090909 86400

Weewx just "decided" to produce Version 1.0 Number after the update an 
mixing both oh the particular day.

Now something also very interesting, the following lines are from a 
friend's database, two days before and after the update: (dateTime DESC)
1604098800 5.1 1604184954 15.8 1604153156 3087.89794733045 288 
3087.89794733045 288
1604012400 6.9 1604022829 12.6 1604059984 2970.48686868687 288 
2970.48686868687 288
1603926000 5.6 1603926667 9.7 1603970504 2352.86239898999 288 
235090.302070707 30188
1603839600 -1.2 1603859547 11.9 1603896779 1507.83905483406 288 
452351.716450217 86400
1603753200 0.29997 1603839591 9.9 1603808400 1324.44158008658 288 
397332.474025974 86400

The same happened, he ales has Version 2.0 in metadata, Version 2.0 numbers 
before the update, mixed on the day of the update and Version 1.0 after the 
update. But his average calculation still works.

So somehow something happened. @all Readers: can you check your database 
before and after the upgrade? Is anybody seeing the same behavior? We, my 
friend an me, have very similar installations, maybe the same quirksy 
config? Or maybe this is more widespread, but most of the users don't 
recognise the effects?

-- 
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/08e95010-2df0-4afa-b1a2-7808a4885478n%40googlegroups.com.

Re: [weewx-user] Upgrade problems?

[David Hindley]

Solved!!  I had to disconnect the Davis Console from power, remove the
batteries, disconnect the Ethernet cable from the console, reconnect and
repower. Then the router found the logger again and restarting weewx got it
working again. Many thanks for your tip about the port.

David.

On Mon, 30 Nov 2020 at 17:30, David Hindley  wrote:

> When I go into the WeatherLink software, and select Comms Port, Find it
> cannot find the device, so something is obviously wrong wi TV the basic set
> up.  Any ideas please?
>
> Many Thanks
>
> David.
>
> On Mon, 30 Nov 2020 at 16:50, David Hindley 
> wrote:
>
>> Tom
>>
>> Many Thanks for your prompt reply.
>>
>> Yes, it’s a WeatherLinkIP. What port would have been closed and how do I
>> reopen it?
>>
>> Thanks.
>>
>> David.
>>
>> On Mon, 30 Nov 2020 at 16:36, Tom Keffer  wrote:
>>
>>> What kind of logger does your Vantage have? If it's a weatherlinkIP,
>>> it's a network issue. Perhaps your upgrade closed a port?
>>>
>>> On Mon, Nov 30, 2020 at 8:21 AM david_h  wrote:
>>>
 Weewx has stopped working and I think it might be due to me recently
 upgrading via DEB.

 When I look at the service status I get:

 Nov 30 15:27:12 raspberrypi python2[487]: weewx[487] CRITICAL
 weewx.engine:   return VantageService(engine, config_dict)
 Nov 30 15:27:12 raspberrypi python2[487]: weewx[487] CRITICAL
 weewx.engine: File "/usr/share/weewx/weewx/drivers/vantage.py",
 line 1898, in __init__
 Nov 30 15:27:12 raspberrypi python2[487]: weewx[487] CRITICAL
 weewx.engine:   Vantage.__init__(self,
 **config_dict[DRIVER_NAME])
 Nov 30 15:27:12 raspberrypi python2[487]: weewx[487] CRITICAL
 weewx.engine: File "/usr/share/weewx/weewx/drivers/vantage.py",
 line 512, in __init__
 Nov 30 15:27:12 raspberrypi python2[487]: weewx[487] CRITICAL
 weewx.engine:   self.port.openPort()
 Nov 30 15:27:12 raspberrypi python2[487]: weewx[487] CRITICAL
 weewx.engine: File "/usr/share/weewx/weewx/drivers/vantage.py",
 line 344, in openPort
 Nov 30 15:27:12 raspberrypi python2[487]: weewx[487] CRITICAL
 weewx.engine:   raise weewx.WeeWxIOError(ex)
 Nov 30 15:27:12 raspberrypi python2[487]: weewx[487] CRITICAL
 weewx.engine:   WeeWxIOError: [Errno 101] Network is unreachable
 Nov 30 15:27:12 raspberrypi python2[487]: weewx[487] CRITICAL __main__:
 Unable to load driver: [Errno 101] Network is unreachable
 Nov 30 15:27:12 raspberrypi python2[487]: weewx[487] CRITICAL
 __main__:   Exiting...

 Any ideas what is causing the above please?  I opted to retain the
 existing weewx.conf file, as I use the belchertown skin (an old version of
 that, I think).

 Many thanks

 David.

>>> --
 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/a01bf34e-fd56-4e73-9e0b-92862eaa45f4n%40googlegroups.com
 
 .

>>> --
>>> You received this message because you are subscribed to a topic in the
>>> Google Groups "weewx-user" group.
>>> To unsubscribe from this topic, visit
>>> https://groups.google.com/d/topic/weewx-user/nhQtoByAgmQ/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to
>>> weewx-user+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/weewx-user/CAPq0zECyE4pRxnqxNVc3eB72X_NKUP5AVPLEjrpk_3n_2p9U9Q%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/CAKbmhJQ5bj3LpkXBe1Q9i0GuO6b%2Bg1rvXyuAp1dK7HVyLVA-mA%40mail.gmail.com.

Re: [weewx-user] Upgrade problems?

[David Hindley]

When I go into the WeatherLink software, and select Comms Port, Find it
cannot find the device, so something is obviously wrong wi TV the basic set
up.  Any ideas please?

Many Thanks

David.

On Mon, 30 Nov 2020 at 16:50, David Hindley  wrote:

> Tom
>
> Many Thanks for your prompt reply.
>
> Yes, it’s a WeatherLinkIP. What port would have been closed and how do I
> reopen it?
>
> Thanks.
>
> David.
>
> On Mon, 30 Nov 2020 at 16:36, Tom Keffer  wrote:
>
>> What kind of logger does your Vantage have? If it's a weatherlinkIP, it's
>> a network issue. Perhaps your upgrade closed a port?
>>
>> On Mon, Nov 30, 2020 at 8:21 AM david_h  wrote:
>>
>>> Weewx has stopped working and I think it might be due to me recently
>>> upgrading via DEB.
>>>
>>> When I look at the service status I get:
>>>
>>> Nov 30 15:27:12 raspberrypi python2[487]: weewx[487] CRITICAL
>>> weewx.engine:   return VantageService(engine, config_dict)
>>> Nov 30 15:27:12 raspberrypi python2[487]: weewx[487] CRITICAL
>>> weewx.engine: File "/usr/share/weewx/weewx/drivers/vantage.py",
>>> line 1898, in __init__
>>> Nov 30 15:27:12 raspberrypi python2[487]: weewx[487] CRITICAL
>>> weewx.engine:   Vantage.__init__(self,
>>> **config_dict[DRIVER_NAME])
>>> Nov 30 15:27:12 raspberrypi python2[487]: weewx[487] CRITICAL
>>> weewx.engine: File "/usr/share/weewx/weewx/drivers/vantage.py",
>>> line 512, in __init__
>>> Nov 30 15:27:12 raspberrypi python2[487]: weewx[487] CRITICAL
>>> weewx.engine:   self.port.openPort()
>>> Nov 30 15:27:12 raspberrypi python2[487]: weewx[487] CRITICAL
>>> weewx.engine: File "/usr/share/weewx/weewx/drivers/vantage.py",
>>> line 344, in openPort
>>> Nov 30 15:27:12 raspberrypi python2[487]: weewx[487] CRITICAL
>>> weewx.engine:   raise weewx.WeeWxIOError(ex)
>>> Nov 30 15:27:12 raspberrypi python2[487]: weewx[487] CRITICAL
>>> weewx.engine:   WeeWxIOError: [Errno 101] Network is unreachable
>>> Nov 30 15:27:12 raspberrypi python2[487]: weewx[487] CRITICAL __main__:
>>> Unable to load driver: [Errno 101] Network is unreachable
>>> Nov 30 15:27:12 raspberrypi python2[487]: weewx[487] CRITICAL __main__:
>>>  Exiting...
>>>
>>> Any ideas what is causing the above please?  I opted to retain the
>>> existing weewx.conf file, as I use the belchertown skin (an old version of
>>> that, I think).
>>>
>>> Many thanks
>>>
>>> David.
>>>
>> --
>>> 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/a01bf34e-fd56-4e73-9e0b-92862eaa45f4n%40googlegroups.com
>>> 
>>> .
>>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "weewx-user" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/weewx-user/nhQtoByAgmQ/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> weewx-user+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/weewx-user/CAPq0zECyE4pRxnqxNVc3eB72X_NKUP5AVPLEjrpk_3n_2p9U9Q%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/CAKbmhJSYm4%2BUA7cf_19LWVVQW45H5KG3gS4y4xb%3DXkQ5yZYZ6Q%40mail.gmail.com.

Re: [weewx-user] Upgrade problems?

[David Hindley]

Tom

Many Thanks for your prompt reply.

Yes, it’s a WeatherLinkIP. What port would have been closed and how do I
reopen it?

Thanks.

David.

On Mon, 30 Nov 2020 at 16:36, Tom Keffer  wrote:

> What kind of logger does your Vantage have? If it's a weatherlinkIP, it's
> a network issue. Perhaps your upgrade closed a port?
>
> On Mon, Nov 30, 2020 at 8:21 AM david_h  wrote:
>
>> Weewx has stopped working and I think it might be due to me recently
>> upgrading via DEB.
>>
>> When I look at the service status I get:
>>
>> Nov 30 15:27:12 raspberrypi python2[487]: weewx[487] CRITICAL
>> weewx.engine:   return VantageService(engine, config_dict)
>> Nov 30 15:27:12 raspberrypi python2[487]: weewx[487] CRITICAL
>> weewx.engine: File "/usr/share/weewx/weewx/drivers/vantage.py",
>> line 1898, in __init__
>> Nov 30 15:27:12 raspberrypi python2[487]: weewx[487] CRITICAL
>> weewx.engine:   Vantage.__init__(self,
>> **config_dict[DRIVER_NAME])
>> Nov 30 15:27:12 raspberrypi python2[487]: weewx[487] CRITICAL
>> weewx.engine: File "/usr/share/weewx/weewx/drivers/vantage.py",
>> line 512, in __init__
>> Nov 30 15:27:12 raspberrypi python2[487]: weewx[487] CRITICAL
>> weewx.engine:   self.port.openPort()
>> Nov 30 15:27:12 raspberrypi python2[487]: weewx[487] CRITICAL
>> weewx.engine: File "/usr/share/weewx/weewx/drivers/vantage.py",
>> line 344, in openPort
>> Nov 30 15:27:12 raspberrypi python2[487]: weewx[487] CRITICAL
>> weewx.engine:   raise weewx.WeeWxIOError(ex)
>> Nov 30 15:27:12 raspberrypi python2[487]: weewx[487] CRITICAL
>> weewx.engine:   WeeWxIOError: [Errno 101] Network is unreachable
>> Nov 30 15:27:12 raspberrypi python2[487]: weewx[487] CRITICAL __main__:
>> Unable to load driver: [Errno 101] Network is unreachable
>> Nov 30 15:27:12 raspberrypi python2[487]: weewx[487] CRITICAL __main__:
>>  Exiting...
>>
>> Any ideas what is causing the above please?  I opted to retain the
>> existing weewx.conf file, as I use the belchertown skin (an old version of
>> that, I think).
>>
>> Many thanks
>>
>> David.
>>
> --
>> 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/a01bf34e-fd56-4e73-9e0b-92862eaa45f4n%40googlegroups.com
>> 
>> .
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "weewx-user" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/weewx-user/nhQtoByAgmQ/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> weewx-user+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-user/CAPq0zECyE4pRxnqxNVc3eB72X_NKUP5AVPLEjrpk_3n_2p9U9Q%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/CAKbmhJSWdnu2eSwJKWuUG3WVdSq2_YD-MPj-udeJT1U3H3HvEg%40mail.gmail.com.

Re: [weewx-user] Upgrade problems?

[Tom Keffer]

What kind of logger does your Vantage have? If it's a weatherlinkIP, it's a
network issue. Perhaps your upgrade closed a port?

On Mon, Nov 30, 2020 at 8:21 AM david_h  wrote:

> Weewx has stopped working and I think it might be due to me recently
> upgrading via DEB.
>
> When I look at the service status I get:
>
> Nov 30 15:27:12 raspberrypi python2[487]: weewx[487] CRITICAL
> weewx.engine:   return VantageService(engine, config_dict)
> Nov 30 15:27:12 raspberrypi python2[487]: weewx[487] CRITICAL
> weewx.engine: File "/usr/share/weewx/weewx/drivers/vantage.py",
> line 1898, in __init__
> Nov 30 15:27:12 raspberrypi python2[487]: weewx[487] CRITICAL
> weewx.engine:   Vantage.__init__(self,
> **config_dict[DRIVER_NAME])
> Nov 30 15:27:12 raspberrypi python2[487]: weewx[487] CRITICAL
> weewx.engine: File "/usr/share/weewx/weewx/drivers/vantage.py",
> line 512, in __init__
> Nov 30 15:27:12 raspberrypi python2[487]: weewx[487] CRITICAL
> weewx.engine:   self.port.openPort()
> Nov 30 15:27:12 raspberrypi python2[487]: weewx[487] CRITICAL
> weewx.engine: File "/usr/share/weewx/weewx/drivers/vantage.py",
> line 344, in openPort
> Nov 30 15:27:12 raspberrypi python2[487]: weewx[487] CRITICAL
> weewx.engine:   raise weewx.WeeWxIOError(ex)
> Nov 30 15:27:12 raspberrypi python2[487]: weewx[487] CRITICAL
> weewx.engine:   WeeWxIOError: [Errno 101] Network is unreachable
> Nov 30 15:27:12 raspberrypi python2[487]: weewx[487] CRITICAL __main__:
> Unable to load driver: [Errno 101] Network is unreachable
> Nov 30 15:27:12 raspberrypi python2[487]: weewx[487] CRITICAL __main__:
>    Exiting...
>
> Any ideas what is causing the above please?  I opted to retain the
> existing weewx.conf file, as I use the belchertown skin (an old version of
> that, I think).
>
> Many thanks
>
> David.
>
> --
> 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/a01bf34e-fd56-4e73-9e0b-92862eaa45f4n%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/CAPq0zECyE4pRxnqxNVc3eB72X_NKUP5AVPLEjrpk_3n_2p9U9Q%40mail.gmail.com.

[weewx-user] Upgrade problems?

[david_h]

Weewx has stopped working and I think it might be due to me recently 
upgrading via DEB.

When I look at the service status I get:

Nov 30 15:27:12 raspberrypi python2[487]: weewx[487] CRITICAL 
weewx.engine:   return VantageService(engine, config_dict)
Nov 30 15:27:12 raspberrypi python2[487]: weewx[487] CRITICAL 
weewx.engine: File "/usr/share/weewx/weewx/drivers/vantage.py", 
line 1898, in __init__
Nov 30 15:27:12 raspberrypi python2[487]: weewx[487] CRITICAL 
weewx.engine:   Vantage.__init__(self, 
**config_dict[DRIVER_NAME])
Nov 30 15:27:12 raspberrypi python2[487]: weewx[487] CRITICAL 
weewx.engine: File "/usr/share/weewx/weewx/drivers/vantage.py", 
line 512, in __init__
Nov 30 15:27:12 raspberrypi python2[487]: weewx[487] CRITICAL 
weewx.engine:   self.port.openPort()
Nov 30 15:27:12 raspberrypi python2[487]: weewx[487] CRITICAL 
weewx.engine: File "/usr/share/weewx/weewx/drivers/vantage.py", 
line 344, in openPort
Nov 30 15:27:12 raspberrypi python2[487]: weewx[487] CRITICAL 
weewx.engine:   raise weewx.WeeWxIOError(ex)
Nov 30 15:27:12 raspberrypi python2[487]: weewx[487] CRITICAL 
weewx.engine:   WeeWxIOError: [Errno 101] Network is unreachable
Nov 30 15:27:12 raspberrypi python2[487]: weewx[487] CRITICAL __main__: 
Unable to load driver: [Errno 101] Network is unreachable
Nov 30 15:27:12 raspberrypi python2[487]: weewx[487] CRITICAL __main__:
   Exiting...

Any ideas what is causing the above please?  I opted to retain the existing 
weewx.conf file, as I use the belchertown skin (an old version of that, I 
think).

Many thanks

David.

-- 
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/a01bf34e-fd56-4e73-9e0b-92862eaa45f4n%40googlegroups.com.

Re: [weewx-user] forcast wunderground for weewx 4.2.x using python 3

['Michael Waldor' via weewx-user]

Regarding missing icon... I already copied it from your zip, and it's 
working fine. I just thought that the missing icon might be a hint that 
some important code might be missing, too. But probably not. 

I did use the original forcast skin creating the subfolder forecast within 
HTML area. And it, too, contains the "wrong" temperature values. Identical 
to those values as been shown within my usecase of forecast_compact. 

Yesterday I've validated that forcast.sdb contains the "correct" forecast 
temperatures within the SQL database field temperature (there are 12entries 
per timestamp for 6days). Hopefully my forecast.sdb.txt posted yesterday is 
still a valid binary SQL database, then you can inspect it e. g. using 
sqlbrowser. 

Thus I assume that somewhere within weewx/forecast the wrong data are 
forwarded into HTML output. 

jo...@johnkline.com schrieb am Montag, 30. November 2020 um 16:15:24 UTC+1:

> frzngdrzl.png was added to the repository after the b10 release.  If you 
> want it, you’ll have to download the repository at head.
>
> I cannot decipher from your reply if the compact forecast is correct in 
> the forecast skin.  Is it?
>
> On Nov 30, 2020, at 12:10 AM, Michael Waldor  wrote:
>
> 
>
> Yes, I did diff both - they are identical. But there is a minor issue: You 
> did update install.py to include frzgrain.png. This is still missing within 
> your  
> https://github.com/chaunceygardiner/weewx-forecast/releases/tag/v3.4.0b10 
> - the png is include but it will not be installed. Is there any other 
> important change maybe missing within your last zip release?
>
> Of course that does not explain the wrong temperature numbers. I've 
> checked also the foreground skin. The data are in sync with my change 
> within Seasons skin. But the data do not contain the values from 
> temperature field within forecast.sdb.
>
> Don't know the internal flow of weewx/forecast. I assume that first you 
> fetch json contents from WU. Then that data is uploaded into forecast.sdb. 
> Afterwards during creation of HTML output the data from forecast.sdb is 
> read and added into the HTML templates by forecast.py. If my assumption is 
> correct there might be a problem during the step from forecast.sdg into the 
> HTML output.
>
>
> jo...@johnkline.com schrieb am Sonntag, 29. November 2020 um 14:36:07 
> UTC+1:
>
>> > Maybe I'm using the wrong forecast_compact.inc (see my included file)? 
>> And see als my forecast.sdb and 5day.json with the presumably correct temp 
>> values, but not shown within the rendered window.
>>
>> Did you diff forecast_compact.inc with the like named file in the latest 
>> forecast extension?  Are they identical?  If not, please provide the diff.
>>
>> Does the compact forecast in the *forecast skin* have the correct values?
>>
>> On Nov 29, 2020, at 1:27 AM, Michael Waldor  wrote:
>>
>> Sorry for posting multiple times - but google did abort any post if 
>> containing *.json or *.inc files:-(
>>
>>
>>
>> Michael Waldor schrieb am Sonntag, 29. November 2020 um 10:26:00 UTC+1:
>>
>>> Tried to rename forecast.sdb into forecast.sdb.txt 
>>>
>>> Michael Waldor schrieb am Sonntag, 29. November 2020 um 10:23:34 UTC+1:
>>>
 Sorry, but google doesn't allow me to append the data. Thus I try again 
 ...

 -- 
>> 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/23bc8b05-639e-4a2b-9860-0e9b92ca6e8cn%40googlegroups.com
>>  
>> 
>> .
>> 
>>
>> -- 
> You received this message because you are subscribed to the Google Groups 
> "weewx-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to weewx-user+...@googlegroups.com.
>
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/86d6d50c-6653-41fb-ac02-ece43c399a0bn%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/85ee7fca-1645-4f35-9d65-7665c978a59en%40googlegroups.com.

Re: [weewx-user] Re: raspberry pi3 installation completed, a page displayed and no update

[P C]

and new to linux and raspberry - not easy!

Le lundi 30 novembre 2020 à 17:18:39 UTC+1, P C a écrit :

> Hello,
> Sorry, super newbie here, I will now think of your solution for log files.
> Yes I also thought of console memory corruption and used this solution ... 
> to no avail
>
> Le lundi 30 novembre 2020 à 16:12:10 UTC+1, tke...@gmail.com a écrit :
>
>> How to post, and how to find the log 
>> .
>>
>> From your very limited description, I would say that your Vantage is 
>> suffering from a classic case of memory corruption. Here are the 
>> directions for how to fix it. 
>> 
>>  
>>
>> But, without the log, there is no way to be sure.
>>
>> On Mon, Nov 30, 2020 at 6:32 AM P C  wrote:
>>
>>>
>>> Hello and thank you for the reply
>>> but, sorry, I don't know where the weewx logs are
>>>
>>> In the meantime, I tested with "screen" if the data logger was on the 
>>> right port and it's ok
>>>
>>> good to you
>>> Le lundi 30 novembre 2020 à 13:38:36 UTC+1, graha...@gmail.com a écrit :
>>>
 need to see the weewx log (you showed a snippet of syslog)

 On 30 Nov 2020, at 11:35 pm, P C  wrote:

 Here is the log after a reboot of the pi, then of the restart of weewx 
 (debug = 1)


 -- 
>>> 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/edbe3d46-6e71-4af0-aa66-7eb954125446n%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/a6a35c74-a103-4670-b46d-3759f8f72792n%40googlegroups.com.

Re: [weewx-user] Re: raspberry pi3 installation completed, a page displayed and no update

[P C]

Hello,
Sorry, super newbie here, I will now think of your solution for log files.
Yes I also thought of console memory corruption and used this solution ... 
to no avail

Le lundi 30 novembre 2020 à 16:12:10 UTC+1, tke...@gmail.com a écrit :

> How to post, and how to find the log 
> .
>
> From your very limited description, I would say that your Vantage is 
> suffering from a classic case of memory corruption. Here are the 
> directions for how to fix it. 
> 
>  
>
> But, without the log, there is no way to be sure.
>
> On Mon, Nov 30, 2020 at 6:32 AM P C  wrote:
>
>>
>> Hello and thank you for the reply
>> but, sorry, I don't know where the weewx logs are
>>
>> In the meantime, I tested with "screen" if the data logger was on the 
>> right port and it's ok
>>
>> good to you
>> Le lundi 30 novembre 2020 à 13:38:36 UTC+1, graha...@gmail.com a écrit :
>>
>>> need to see the weewx log (you showed a snippet of syslog)
>>>
>>> On 30 Nov 2020, at 11:35 pm, P C  wrote:
>>>
>>> Here is the log after a reboot of the pi, then of the restart of weewx 
>>> (debug = 1)
>>>
>>>
>>> -- 
>> 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/edbe3d46-6e71-4af0-aa66-7eb954125446n%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/36ae5646-682d-464a-aa04-b06df4416296n%40googlegroups.com.

[weewx-user] GW1000 and" CMD_READ_STATION_MAC"

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

Hi

Running RPI 4, Weewx 4.2 and GW1000 latest version and suddenly this 
appears. Any ideas what's going on?

The combination has been running stable, so my best quest it might be a 
hardware problem or? 

Never seen this before and couldn't find anything on the net.

Nov 30 16:30:32 raspberrypi weewx[537] ERROR user.gw1000: Failed to obtain 
response to command 'CMD_READ_STATION_MAC' after 3 attempts
Nov 30 16:30:32 raspberrypi weewx[537] ERROR weewx.engine: Import of driver 
failed: Failed to obtain response to command 'CMD_READ_STATION_MAC' after 3 
attempts ()
Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL weewx.engine:   
Traceback (most recent call last):
Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL weewx.engine: 
File "/home/weewx/bin/weewx/engine.py", line 109, in setupStation
Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL weewx.engine:   
self.console = loader_function(config_dict, self)
Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL weewx.engine: 
File "/home/weewx/bin/user/gw1000.py", line 1293, in loader
Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL weewx.engine:   
return Gw1000Driver(**config_dict[DRIVER_NAME])
Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL weewx.engine: 
File "/home/weewx/bin/user/gw1000.py", line 1568, in __init__
Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL weewx.engine:   
super(Gw1000Driver, self).__init__(**stn_dict)
Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL weewx.engine: 
File "/home/weewx/bin/user/gw1000.py", line 767, in __init__
Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL weewx.engine:   
debug_wind=self.debug_wind)
Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL weewx.engine: 
File "/home/weewx/bin/user/gw1000.py", line 1870, in __init__
Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL weewx.engine:   
lost_contact_log_period=lost_contact_log_period)
Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL weewx.engine: 
File "/home/weewx/bin/user/gw1000.py", line 2276, in __init__
Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL weewx.engine:   
self.mac = self.get_mac_address()
Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL weewx.engine: 
File "/home/weewx/bin/user/gw1000.py", line 2407, in get_mac_address
Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL weewx.engine:   
return self.send_cmd_with_retries('CMD_READ_STATION_MAC')
Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL weewx.engine: 
File "/home/weewx/bin/user/gw1000.py", line 2532, in send_cmd_with_retries
Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL weewx.engine:   
raise GW1000IOError(_msg)
Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL weewx.engine:   
user.gw1000.GW1000IOError: Failed to obtain response to command 
'CMD_READ_STATION_MAC' after 3 attempts
Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL __main__: Unable to load 
driver: Failed to obtain response to command 'CMD_READ_STATION_MAC' after 3 
attempts
Nov 30 16:30:32 raspberrypi weewx[537] CRITICAL __main__:   
Exiting...

Gert

-- 
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/bd16ef1c-b2a4-4a7e-9533-7ecb9b263c56n%40googlegroups.com.

Re: [weewx-user] forcast wunderground for weewx 4.2.x using python 3

[John Kline]

frzngdrzl.png was added to the repository after the b10 release.  If you want 
it, you’ll have to download the repository at head.

I cannot decipher from your reply if the compact forecast is correct in the 
forecast skin.  Is it?

> On Nov 30, 2020, at 12:10 AM, Michael Waldor  wrote:
> 
> 
> Yes, I did diff both - they are identical. But there is a minor issue: You 
> did update install.py to include frzgrain.png. This is still missing within 
> your  
> https://github.com/chaunceygardiner/weewx-forecast/releases/tag/v3.4.0b10 - 
> the png is include but it will not be installed. Is there any other important 
> change maybe missing within your last zip release?
> 
> Of course that does not explain the wrong temperature numbers. I've checked 
> also the foreground skin. The data are in sync with my change within Seasons 
> skin. But the data do not contain the values from temperature field within 
> forecast.sdb.
> 
> Don't know the internal flow of weewx/forecast. I assume that first you fetch 
> json contents from WU. Then that data is uploaded into forecast.sdb. 
> Afterwards during creation of HTML output the data from forecast.sdb is read 
> and added into the HTML templates by forecast.py. If my assumption is correct 
> there might be a problem during the step from forecast.sdg into the HTML 
> output.
> 
> 
> jo...@johnkline.com schrieb am Sonntag, 29. November 2020 um 14:36:07 UTC+1:
>> > Maybe I'm using the wrong forecast_compact.inc (see my included file)? And 
>> > see als my forecast.sdb and 5day.json with the presumably correct temp 
>> > values, but not shown within the rendered window.
>> 
>> Did you diff forecast_compact.inc with the like named file in the latest 
>> forecast extension?  Are they identical?  If not, please provide the diff.
>> 
>> Does the compact forecast in the forecast skin have the correct values?
>> 
 On Nov 29, 2020, at 1:27 AM, Michael Waldor  wrote:
 
>>> Sorry for posting multiple times - but google did abort any post if 
>>> containing *.json or *.inc files:-(
>> 
>>> 
>>> 
>>> Michael Waldor schrieb am Sonntag, 29. November 2020 um 10:26:00 UTC+1:
 Tried to rename forecast.sdb into forecast.sdb.txt 
 
 Michael Waldor schrieb am Sonntag, 29. November 2020 um 10:23:34 UTC+1:
> Sorry, but google doesn't allow me to append the data. Thus I try again 
> ...
> 
>>> 
>> 
>>> -- 
>>> 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/23bc8b05-639e-4a2b-9860-0e9b92ca6e8cn%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/86d6d50c-6653-41fb-ac02-ece43c399a0bn%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/E6D21124-E190-4026-8982-47773CAFEAD0%40johnkline.com.

Re: [weewx-user] Re: raspberry pi3 installation completed, a page displayed and no update

[Tom Keffer]

How to post, and how to find the log
.

>From your very limited description, I would say that your Vantage is
suffering from a classic case of memory corruption. Here are the directions
for how to fix it.



But, without the log, there is no way to be sure.

On Mon, Nov 30, 2020 at 6:32 AM P C  wrote:

>
> Hello and thank you for the reply
> but, sorry, I don't know where the weewx logs are
>
> In the meantime, I tested with "screen" if the data logger was on the
> right port and it's ok
>
> good to you
> Le lundi 30 novembre 2020 à 13:38:36 UTC+1, graha...@gmail.com a écrit :
>
>> need to see the weewx log (you showed a snippet of syslog)
>>
>> On 30 Nov 2020, at 11:35 pm, P C  wrote:
>>
>> Here is the log after a reboot of the pi, then of the restart of weewx
>> (debug = 1)
>>
>>
>> --
> 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/edbe3d46-6e71-4af0-aa66-7eb954125446n%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/CAPq0zEDPgAGho1LbwOF37wE0jsNFxauX1yg53DqV_MM3OBsUWw%40mail.gmail.com.

Re: [weewx-user] Re: raspberry pi3 installation completed, a page displayed and no update

[P C]

Hello and thank you for the reply
but, sorry, I don't know where the weewx logs are

In the meantime, I tested with "screen" if the data logger was on the right 
port and it's ok

good to you
Le lundi 30 novembre 2020 à 13:38:36 UTC+1, graha...@gmail.com a écrit :

> need to see the weewx log (you showed a snippet of syslog)
>
> On 30 Nov 2020, at 11:35 pm, P C  wrote:
>
> Here is the log after a reboot of the pi, then of the restart of weewx 
> (debug = 1)
>
>
>

-- 
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/edbe3d46-6e71-4af0-aa66-7eb954125446n%40googlegroups.com.

Re: [weewx-user] Wrong monthly average temperature

[Tom Keffer]

Michael, I have no idea what happened, but if you want to modify your daily
summaries, it should be done right. If I understand you correctly, you
patched them with SQL commands like

update archive_day_ET set wsum=sum, sumtime=count;
update archive_day_UV set wsum=sum, sumtime=count;
update archive_day_altimeter set wsum=sum, sumtime=count;
etc.

This will leave your summaries in an inconsistent state: the numbers are
what would be expected for a Version 1 summary, yet your metadata will say
Version 2. Furthermore, as new days are added, Version 2 numbers will be
used, and you'll be back where you started: with half Version 1 and half
Version 2.

I would suggest making it totally Version 2. Do an update, except weight
them with the archive interval. This will work if your archive interval is
a constant 5 minutes (300 seconds):

1. Stop weewx.
2. Make a backup of weewx.sdb
3. Use updates that look like:

update archive_day_ET set wsum=sum*300, sumtime=count*300;
update archive_day_UV set wsum=sum*300, sumtime=count*300;
update archive_day_altimeter set wsum=sum*300, sumtime=count*300;
etc.

4. Restart weewx



On Sun, Nov 29, 2020 at 11:36 AM michael.k...@gmx.at <
michael.kainzba...@gmx.at> wrote:

>
> https://imgur.com/a/yZUPoTq
> michael.k...@gmx.at schrieb am Samstag, 28. November 2020 um 09:27:44
> UTC+1:
>
>>
>> I am observing the same situation, as well as other WeeWX users near me.
>> The average is clearly off since the 4.2.0 update. It also affects yearly
>> average since then. So I guess this is something that happened with the
>> 4.2.0 Version. I don't want to rebuild my daily values, how to find the bad
>> values and correct them? Probably in the archive_daily table of the day I
>> made the update?
>>
>> I found something: It's a change with "sum":
>> 1-13 has "new" sumtime, 14 a mix (the day I updated) and old sumtime are
>> 15 and and older:
>>
>> Isn't there a config that sets how this is calculated?
>>
>>
>> b.cl...@gmail.com schrieb am Donnerstag, 19. November 2020 um 19:43:57
>> UTC+1:
>>
>>> Yeah, everything looks great again.
>>> Thank you Tom for that excellent support.
>>> Greetings from Suedlohn (Germany).
>>> Berny
>>>
>>> tke...@gmail.com schrieb am Donnerstag, 19. November 2020 um 17:56:56
>>> UTC+1:
>>>
 So, for some reason, the weighted sum (field 'wsum') has too high a
 value, or the sum of observation time (field 'sumtime') has too low a 
 value.

 The easiest fix is to just rebuild the daily summaries using the 
 wee_database
 utility .

 Stop weewxd. then,

 *wee_database --drop-daily*
 *wee_database --rebuild-daily*

 Restart weewxd

 For a database of your size, it shouldn't take more than a minute or
 two.

 It could take some time for the NOAA and html files to get corrected.
 You can speed things up by deleting them and allowing weewx to regenerate
 them.

 -tk



 On Thu, Nov 19, 2020 at 8:48 AM Berny Cl  wrote:

> sqlite> select sum(wsum)/sum(sumtime) from archive_day_outTemp where
> strftime("%Y-%m",dateTime,'unixepoch','localtime')=='2020-11';
> 60.1308595259353
>
> Ok, that looks the same like the value in my history table.
>
> tke...@gmail.com schrieb am Donnerstag, 19. November 2020 um 17:13:38
> UTC+1:
>
>> 1. That looks reasonable. One other query to try:
>>
>> sqlite> *select sum(wsum)/sum(sumtime) from archive_day_outTemp
>> where strftime("%Y-%m",dateTime,'unixepoch','localtime')=='2020-11';*
>>
>> 2. If that doesn't reveal anything, I will send you an instrumented
>> version of xtypes.py that will log the calculation.
>>
>>
>> On Thu, Nov 19, 2020 at 6:44 AM Berny Cl  wrote:
>>
>>> sqlite> select avg(outTemp) from archive where strftime("%Y-%m",
>>> dateTime,'unixepoch','localtime')=='2020-11';
>>> 51.117818676717 <(781)%20867-6717>
>>> sqlite> select sum(sum)/sum(count) from archive_day_outTemp where
>>> strftime("%Y-%m",dateTime,'unixepoch','localtime')=='2020-11';
>>> 51.114923603352
>>>
>>> Thank you!
>>> OK, I did that. The two numbers are very close. I think they are
>>> correct (in Fahrenheit) but in my history table the temperature ist too
>>> high (in degree Celsius).
>>>
>>> tke...@gmail.com schrieb am Donnerstag, 19. November 2020 um
>>> 15:02:55 UTC+1:
>>>
 Most likely it's some bad data. Let's check the database directly.

 First find the database. If you did a package install, it's most
 likely at /var/lib/weewx/weewx.sdb. If you did a setup.py install, 
 it's at
 /home/weewx/archive/weewx.sdb. Let's assume the former.

 Then, run two queries:

 *sqlite /var/lib/weewx/weewx.sdb*
 sqlite> *select avg(outTemp) from archive where strftime("%Y-%m",

Re: [weewx-user] How to aggregate by calendar month

[Tom Keffer]

Incidentally, if you order your lines low/avg/high, you can use a bar
chart, which will be easier to read.

 [[[yearhilowmonth]]]
time_length = 31536000 # 365 days
aggregate_interval = 2629800# month?
line_gap_fraction = None
plot_type = bar
low
data_type = outTemp
aggregate_type = min
label = min
avg
data_type = outTemp
aggregate_type = avg
label = average temperature
hi
data_type = outTemp
aggregate_type = max
label = month max

-tk

On Mon, Nov 30, 2020 at 3:24 AM Karen K  wrote:

> Ah, so there is a special hack included for that problem.
>
> Thank you for explaining.
>
> tke...@gmail.com schrieb am Montag, 30. November 2020 um 03:33:06 UTC+1:
>
>> An aggregate_interval of 365.25 / 12 * 24 * 3600 = 2629800 is a "magic
>> number" and recognized by WeeWX as a nominal month.
>>
>> The example you gave should get you what you want: monthly highs, lows,
>> and averages.
>>
>> On Sun, Nov 29, 2020 at 10:10 AM Karen K  wrote:
>>
>>> To create a diagramm I have to set a value for "aggregate_interval" in
>>> seconds. That works fine for days and weeks, as they are always the same
>>> length in seconds. In contrast, months have a variable length of 28, 30, or
>>> 31 days. Even 29 days are possible sometimes. So, is there a possibility to
>>> aggregate by calendar month?
>>>
>>> And then, it is not sure, that the aggregation interval starts at the
>>> beginning of a month.
>>> Is there any possibility to force that?
>>>
>>> Example:
>>> [[[yearhilowmonth]]]
>>> time_length = 31536000 # 365 days
>>> aggregate_interval = 2629800 # month?
>>> line_gap_fraction = None
>>> hi
>>> data_type = outTemp
>>> aggregate_type = max
>>> label = month max
>>> low
>>> data_type = outTemp
>>> aggregate_type = min
>>> label = min
>>> avg
>>> data_type = outTemp
>>> aggregate_type = avg
>>> label = average temperature
>>>
>>> --
>>> 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/fff1ce23-4428-4fea-bf8d-165b95c27624n%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/731fa600-86b4-46a2-856c-6204ba956a80n%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/CAPq0zEA40LEKk1aLXpS0dTD9rW2dRN2OBF_2r6RW8E2jVMqdVw%40mail.gmail.com.

Re: [weewx-user] Re: raspberry pi3 installation completed, a page displayed and no update

[Graham Eddy]

need to see the weewx log (you showed a snippet of syslog)

> On 30 Nov 2020, at 11:35 pm, P C  wrote:
> 
> Here is the log after a reboot of the pi, then of the restart of weewx (debug 
> = 1)

-- 
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/C928810B-C2A4-459D-957E-203E240A611C%40gmail.com.

[weewx-user] Re: raspberry pi3 installation completed, a page displayed and no update

[P C]

Sorry : davis vantage vue and usb data logger

Le lundi 30 novembre 2020 à 11:59:34 UTC+1, P C a écrit :

> Hello,
> After many tests, I managed to install weewx on a Pi3.
> He sent his files once via FTP. But, it was the page of 11/26/20 13:35:00 
> while it was 11/29. Later, 4:55 pm arrived, and since nothing
> The page: https://cambier.eu/meteo/weewx/
> Here is the log after a reboot of the pi, then of the restart of weewx 
> (debug = 1)
>
> The configuration file is located here: 
> https://www.dropbox.com/s/ywoqpzvarxnhwy3/Config_WeeWx_Anonyme.txt?dl=0
> Do you have a lead for me?
> Thank you !
>
> pi@weewx-pi3:~ $ tail -f /var/log/syslog 
> Nov 30 11:31:31 weewx-pi3 dhcpcd[439]: wlan0: expired address 
> 2a02:2788:11f4:344:c909:9ba4:6f20:ce24/64
> Nov 30 11:31:31 weewx-pi3 avahi-daemon[371]: Withdrawing address record 
> for 2a02:2788:11f4:344:c909:9ba4:6f20:ce24 on wlan0.
> Nov 30 11:31:31 weewx-pi3 dhcpcd[439]: wlan0: part of Router Advertisement 
> expired
> Nov 30 11:31:31 weewx-pi3 avahi-daemon[371]: Leaving mDNS multicast group 
> on interface wlan0.IPv6 with address 2a02:2788:11f4:344:c909:9ba4:6f20:ce24.
> Nov 30 11:31:31 weewx-pi3 avahi-daemon[371]: Joining mDNS multicast group 
> on interface wlan0.IPv6 with address fe80::5fee:62fb:9770:fccf.
> Nov 30 11:31:31 weewx-pi3 dhcpcd[439]: wlan0: deleting route to 
> 2a02:2788:11f4:344::/64
> Nov 30 11:31:31 weewx-pi3 avahi-daemon[371]: Registering new address 
> record for fe80::5fee:62fb:9770:fccf on wlan0.*.
> Nov 30 11:31:31 weewx-pi3 dhcpcd[439]: wlan0: deleting default route via 
> fe80::264b:feff:fe2e:56a0
> Nov 30 11:32:16 weewx-pi3 dbus-daemon[733]: [session uid=1000 pid=733] 
> Successfully activated service 'ca.desrt.dconf'
> Nov 30 11:34:30 weewx-pi3 systemd[1]: Stopping LSB: weewx weather system...
> Nov 30 11:34:31 weewx-pi3 weewx[1284]: Stopping weewx weather system: 
> weewx not running
> Nov 30 11:34:31 weewx-pi3 systemd[1]: weewx.service: Succeeded.
> Nov 30 11:34:31 weewx-pi3 systemd[1]: Stopped LSB: weewx weather system.
> Nov 30 11:34:31 weewx-pi3 systemd[1]: Starting LSB: weewx weather system...
> Nov 30 11:34:31 weewx-pi3 weewx[1307] INFO __main__: Initializing weewx 
> version 4.2.0
> Nov 30 11:34:31 weewx-pi3 weewx[1307] INFO __main__: Using Python 3.7.3 
> (default, Jul 25 2020, 13:03:44) #012[GCC 8.3.0]
> Nov 30 11:34:31 weewx-pi3 weewx[1307] INFO __main__: Platform 
> Linux-5.4.72-v7+-armv7l-with-debian-10.6
> Nov 30 11:34:31 weewx-pi3 weewx[1307] INFO __main__: Locale is 
> 'fr_BE.UTF-8'
> Nov 30 11:34:31 weewx-pi3 weewx[1307] INFO __main__: PID file is 
> /var/run/weewx.pid
> Nov 30 11:34:31 weewx-pi3 weewx[1295]: Starting weewx weather system: 
> weewx.
> Nov 30 11:34:31 weewx-pi3 systemd[1]: Started LSB: weewx weather system.
> Nov 30 11:36:39 weewx-pi3 systemd[1]: Starting Cleanup of Temporary 
> Directories...
> Nov 30 11:36:39 weewx-pi3 systemd[1]: systemd-tmpfiles-clean.service: 
> Succeeded.
> Nov 30 11:36:39 weewx-pi3 systemd[1]: Started Cleanup of Temporary 
> Directories.
>

-- 
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/005f8ef5-84de-4343-9315-d93ab8c5d2c5n%40googlegroups.com.

RE: [weewx-user] luftdaten.info - sensor.community air quality data to weewx

[steepleian]

OK those values look more realistic. I assume SDS_P1 = PM10 and SDS_P2 = PM2.5 I will work out the code to parse that structure this evening.Ian Sent from Mail for Windows 10 From: Calo GeyerSent: 30 November 2020 11:15To: weewx-userSubject: Re: [weewx-user] luftdaten.info - sensor.community air quality data to weewx Hi, sorry, I just have the data.json output. I do not have a log file which looks like the one from Michal.On Monday, November 30, 2020 at 11:03:33 AM UTC+1 steep...@gmail.com wrote:The screen dump is from Michal’s json data. Can you post a similar data file so that I can compare with your log? On Mon, 30 Nov 2020 at 08:56, Calo Geyer  wrote:Hi, not sure if you talk about my measurements? I would say it can not be accumulated. Here my latest values from the log. On Mon, 30 Nov 2020 at 09:38, steeple ian  wrote:  On Mon, 30 Nov 2020 at 08:36, steeple ian  wrote:I have looked at the example json data from your process. The PM data values appear to be SDS_P1 and SDS_P2. The actual values are very high. Are these accumulated values or artificially stimulated? On Mon, 30 Nov 2020 at 08:20, Calo Geyer  wrote:Hi Ian, I am trying to use :-)but I am not yet sure how to use in Weewx afterwards. I also tried to import my archive.db in myphpadmin but did not work so I am afraid this is not leading me to where I want to go. If we get your file to work we can use the Weewx extended which for sure will do the job. Andreas On Mon, 30 Nov 2020 at 09:09, steeple ian  wrote:Yes I see. So you are using a separate database if I understand correctly? If you use the WeeWX extended database you only need the PM sensor data. I will share my method in more detail later today.Ian On Mon, 30 Nov 2020 at 07:59, Calo Geyer  wrote:See, Ian, if we managed to use this file, we got PPM10, PPM2.5, Temperature, Humitidy and Wlan.On Monday, November 30, 2020 at 8:58:06 AM UTC+1 Calo Geyer wrote:On Monday, November 30, 2020 at 8:53:16 AM UTC+1 Calo Geyer wrote:Hi, I also worked according this linkhttps://tech.hamm7.de/blogs/feinstaub/feinstaubphpand managed to get the log file recording. I also created the feinstaub.db (using myphpadmin) which I fed by the php script (from the feinstaub.log) however my issue to solve was the connection of script to database (connectdb.php). I think I can solve soon and then we would have all directly in the database.But is good to hear that you explore the other way to get it work as well. Do you mind sharing details how to create the data file?I will share how my log now looks like in a second as I need to pick from home network.On Monday, November 30, 2020 at 8:43:49 AM UTC+1 steep...@gmail.com wrote:I have worked out a method but the json data file that you have is more complicated than the one I have from my process. The only data you need to extract are the pm2.5 and pm10.0 figures. It is difficult to see which is which in your file. My method uses a piece of php code to parse the json data file and insert the data into a txt file in the format that filepile requires. You must also be using the new extended WeeWX database which has additional fields for air quality.Ian On Mon, 30 Nov 2020 at 06:15, miso k  wrote:Hi,I have successfully added inner Humidity fields and graphs to my webpage as a training (values are already measured). So only step is to fill the data from AirQual sensor to database.Did you find a way to do it? MichalDátum: piatok 27. novembra 2020, čas: 21:56:07 UTC+1, odosielateľ: miso kHi again,so I tried to do it your way, it works now.the feinstaub.log looks like this:{"time":1606510522,"datum":"2020-11-27","zeit":"21:55:22","ipAddress":"192.168.1.23","daten":{"esp8266id": "759897", "software_version": "NRZ-2020-131", "sensordatavalues":[{"value_type":"SDS_P1","value":"465.88"},{"value_type":"SDS_P2","value":"66.15"},{"value_type":"BME280_temperature","value":"-0.09"},{"value_type":"BME280_pressure","value":"98677.09"},{"value_type":"BME280_humidity","value":"100.00"},{"value_type":"samples","value":"3565079"},{"value_type":"min_micro","value":"39"},{"value_type":"max_micro","value":"43094"},{"value_type":"interval","value":"145000"},{"value_type":"signal","value":"-62"}]}} now we need to save it to main database weewx.sdb I hope. Let's ask Ian how to do it with filepile. Or let me know, when you will be further with your solutions. Thanks,M Dátum: piatok 27. novembra 2020, čas: 21:29:24 UTC+1, odosielateľ: miso kso i added the file named data_simple.php with content as in the example above. Then I have browsed the address myRPiweewxIPaddress/data_simple.php and i got the answer:Sensor: ok ,but this will be also without any imput data from sensor...No csv is produced. rights on data_simple.php are -rw-r--r-- . is it ok? Dátum: piatok 27. novembra 2020, čas: 13:14:25 UTC+1, odosielateľ: miso kHello,I have this answer from sensor developer: this feature exists in this firmware. Just look for "Send data to custom API". There you can configure a server and a path to a script on 

Re: [weewx-user] How to aggregate by calendar month

[Karen K]

Ah, so there is a special hack included for that problem.

Thank you for explaining.

tke...@gmail.com schrieb am Montag, 30. November 2020 um 03:33:06 UTC+1:

> An aggregate_interval of 365.25 / 12 * 24 * 3600 = 2629800 is a "magic 
> number" and recognized by WeeWX as a nominal month. 
>
> The example you gave should get you what you want: monthly highs, lows, 
> and averages.
>
> On Sun, Nov 29, 2020 at 10:10 AM Karen K  wrote:
>
>> To create a diagramm I have to set a value for "aggregate_interval" in 
>> seconds. That works fine for days and weeks, as they are always the same 
>> length in seconds. In contrast, months have a variable length of 28, 30, or 
>> 31 days. Even 29 days are possible sometimes. So, is there a possibility to 
>> aggregate by calendar month?
>>
>> And then, it is not sure, that the aggregation interval starts at the 
>> beginning of a month.
>> Is there any possibility to force that?
>>
>> Example:
>> [[[yearhilowmonth]]] 
>> time_length = 31536000 # 365 days 
>> aggregate_interval = 2629800 # month?
>> line_gap_fraction = None 
>> hi 
>> data_type = outTemp 
>> aggregate_type = max 
>> label = month max 
>> low 
>> data_type = outTemp 
>> aggregate_type = min 
>> label = min 
>> avg 
>> data_type = outTemp 
>> aggregate_type = avg 
>> label = average temperature
>>
>> -- 
>> 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/fff1ce23-4428-4fea-bf8d-165b95c27624n%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/731fa600-86b4-46a2-856c-6204ba956a80n%40googlegroups.com.

[weewx-user] raspberry pi3 installation completed, a page displayed and no update

[pascal Cambier]

Hello,
After many tests, I managed to install weewx on a Pi3.
He sent his files once via FTP. But, it was the page of 11/26/20 13:35:00 
while it was 11/29. Later, 4:55 pm arrived, and since nothing
The page: https://cambier.eu/meteo/weewx/
Here is the log after a reboot of the pi, then of the restart of weewx 
(debug = 1)

The configuration file is located here: 
https://www.dropbox.com/s/ywoqpzvarxnhwy3/Config_WeeWx_Anonyme.txt?dl=0
Do you have a lead for me?
Thank you !

pi@weewx-pi3:~ $ tail -f /var/log/syslog 
Nov 30 11:31:31 weewx-pi3 dhcpcd[439]: wlan0: expired address 
2a02:2788:11f4:344:c909:9ba4:6f20:ce24/64
Nov 30 11:31:31 weewx-pi3 avahi-daemon[371]: Withdrawing address record for 
2a02:2788:11f4:344:c909:9ba4:6f20:ce24 on wlan0.
Nov 30 11:31:31 weewx-pi3 dhcpcd[439]: wlan0: part of Router Advertisement 
expired
Nov 30 11:31:31 weewx-pi3 avahi-daemon[371]: Leaving mDNS multicast group 
on interface wlan0.IPv6 with address 2a02:2788:11f4:344:c909:9ba4:6f20:ce24.
Nov 30 11:31:31 weewx-pi3 avahi-daemon[371]: Joining mDNS multicast group 
on interface wlan0.IPv6 with address fe80::5fee:62fb:9770:fccf.
Nov 30 11:31:31 weewx-pi3 dhcpcd[439]: wlan0: deleting route to 
2a02:2788:11f4:344::/64
Nov 30 11:31:31 weewx-pi3 avahi-daemon[371]: Registering new address record 
for fe80::5fee:62fb:9770:fccf on wlan0.*.
Nov 30 11:31:31 weewx-pi3 dhcpcd[439]: wlan0: deleting default route via 
fe80::264b:feff:fe2e:56a0
Nov 30 11:32:16 weewx-pi3 dbus-daemon[733]: [session uid=1000 pid=733] 
Successfully activated service 'ca.desrt.dconf'
Nov 30 11:34:30 weewx-pi3 systemd[1]: Stopping LSB: weewx weather system...
Nov 30 11:34:31 weewx-pi3 weewx[1284]: Stopping weewx weather system: weewx 
not running
Nov 30 11:34:31 weewx-pi3 systemd[1]: weewx.service: Succeeded.
Nov 30 11:34:31 weewx-pi3 systemd[1]: Stopped LSB: weewx weather system.
Nov 30 11:34:31 weewx-pi3 systemd[1]: Starting LSB: weewx weather system...
Nov 30 11:34:31 weewx-pi3 weewx[1307] INFO __main__: Initializing weewx 
version 4.2.0
Nov 30 11:34:31 weewx-pi3 weewx[1307] INFO __main__: Using Python 3.7.3 
(default, Jul 25 2020, 13:03:44) #012[GCC 8.3.0]
Nov 30 11:34:31 weewx-pi3 weewx[1307] INFO __main__: Platform 
Linux-5.4.72-v7+-armv7l-with-debian-10.6
Nov 30 11:34:31 weewx-pi3 weewx[1307] INFO __main__: Locale is 'fr_BE.UTF-8'
Nov 30 11:34:31 weewx-pi3 weewx[1307] INFO __main__: PID file is 
/var/run/weewx.pid
Nov 30 11:34:31 weewx-pi3 weewx[1295]: Starting weewx weather system: weewx.
Nov 30 11:34:31 weewx-pi3 systemd[1]: Started LSB: weewx weather system.
Nov 30 11:36:39 weewx-pi3 systemd[1]: Starting Cleanup of Temporary 
Directories...
Nov 30 11:36:39 weewx-pi3 systemd[1]: systemd-tmpfiles-clean.service: 
Succeeded.
Nov 30 11:36:39 weewx-pi3 systemd[1]: Started Cleanup of Temporary 
Directories.

-- 
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/0b7265c1-27f4-4912-a30f-12e08211eb32n%40googlegroups.com.

Re: [weewx-user] luftdaten.info - sensor.community air quality data to weewx

[steeple ian]

[image: image.png]


On Mon, 30 Nov 2020 at 08:36, steeple ian  wrote:

> I have looked at the example json data from your process. The PM data
> values appear to be SDS_P1 and SDS_P2. The actual values are very high. Are
> these accumulated values or artificially stimulated?
>
> On Mon, 30 Nov 2020 at 08:20, Calo Geyer  wrote:
>
>> Hi Ian,
>>
>> I am trying to use :-)
>> but I am not yet sure how to use in Weewx afterwards. I also tried to
>> import my archive.db in myphpadmin but did not work so I am afraid this is
>> not leading me to where I want to go. If we get your file to work we can
>> use the Weewx extended which for sure will do the job.
>>
>> Andreas
>>
>> On Mon, 30 Nov 2020 at 09:09, steeple ian  wrote:
>>
>>> Yes I see. So you are using a separate database if I understand
>>> correctly? If you use the WeeWX extended database you only need the PM
>>> sensor data. I will share my method in more detail later today.
>>> Ian
>>>
>>> On Mon, 30 Nov 2020 at 07:59, Calo Geyer  wrote:
>>>
 See, Ian, if we managed to use this file, we got PPM10, PPM2.5,
 Temperature, Humitidy and Wlan.

 On Monday, November 30, 2020 at 8:58:06 AM UTC+1 Calo Geyer wrote:

> [image: Screenshot_20201130-085211.jpg]
>
> On Monday, November 30, 2020 at 8:53:16 AM UTC+1 Calo Geyer wrote:
>
>> Hi, I also worked according this link
>> https://tech.hamm7.de/blogs/feinstaub/feinstaubphp
>> and managed to get the log file recording. I also created the
>> feinstaub.db (using myphpadmin) which I fed by the php script (from the
>> feinstaub.log) however my issue to solve was the connection of script to
>> database (connectdb.php). I think I can solve soon and then we would have
>> all directly in the database.
>> But is good to hear that you explore the other way to get it work as
>> well. Do you mind sharing details how to create the data file?
>> I will share how my log now looks like in a second as I need to pick
>> from home network.
>> On Monday, November 30, 2020 at 8:43:49 AM UTC+1 steep...@gmail.com
>> wrote:
>>
>>> I have worked out a method but the json data file that you have is
>>> more complicated than the one I have from my process. The only data you
>>> need to extract are the pm2.5 and pm10.0 figures. It is difficult to see
>>> which is which in your file. My method uses a piece of php code to parse
>>> the json data file and insert the data into a txt file in the format 
>>> that
>>> filepile requires. You must also be using the new extended WeeWX 
>>> database
>>> which has additional fields for air quality.
>>> Ian
>>>
>>> On Mon, 30 Nov 2020 at 06:15, miso k  wrote:
>>>
 Hi,
 I have successfully added inner Humidity fields and graphs to my
 webpage as a training (values are already measured). So only step is to
 fill the data from AirQual sensor to database.
 Did you find a way to do it?

 Michal

 Dátum: piatok 27. novembra 2020, čas: 21:56:07 UTC+1, odosielateľ:
 miso k

> Hi again,
> so I tried to do it your way, it works now.
> the feinstaub.log looks like this:
> {"time":1606510522,
> "datum":"2020-11-27",
> "zeit":"21:55:22",
> "ipAddress":"192.168.1.23",
> "daten":{"esp8266id": "759897", "software_version":
> "NRZ-2020-131",
> "sensordatavalues":[{"value_type":"SDS_P1","value":"465.88"},{"value_type":"SDS_P2","value":"66.15"},{"value_type":"BME280_temperature","value":"-0.09"},{"value_type":"BME280_pressure","value":"98677.09"},{"value_type":"BME280_humidity","value":"100.00"},{"value_type":"samples","value":"3565079"},{"value_type":"min_micro","value":"39"},{"value_type":"max_micro","value":"43094"},{"value_type":"interval","value":"145000"},{"value_type":"signal","value":"-62"}]}
> }
>
> now we need to save it to main database weewx.sdb I hope. Let's
> ask Ian how to do it with filepile.
>
> Or let me know, when you will be further with your solutions.
>
> Thanks,
> M
>
> Dátum: piatok 27. novembra 2020, čas: 21:29:24 UTC+1, odosielateľ:
> miso k
>
>> so i added the file named data_simple.php with content as in the
>> example above. Then I have browsed the address
>> myRPiweewxIPaddress/data_simple.php and i got the answer:
>> Sensor: ok
>> ,but this will be also without any imput data from sensor...
>> No csv is produced.
>>
>> rights on data_simple.php are -rw-r--r-- . is it ok?
>>
>>
>> Dátum: piatok 27. novembra 2020, čas: 13:14:25 UTC+1,
>> odosielateľ: miso k
>>
>>> Hello,
>>> I have this answer from sensor developer:
>>>
>>> this feature exists in this 

Re: [weewx-user] luftdaten.info - sensor.community air quality data to weewx

[steeple ian]

I have looked at the example json data from your process. The PM data
values appear to be SDS_P1 and SDS_P2. The actual values are very high. Are
these accumulated values or artificially stimulated?

On Mon, 30 Nov 2020 at 08:20, Calo Geyer  wrote:

> Hi Ian,
>
> I am trying to use :-)
> but I am not yet sure how to use in Weewx afterwards. I also tried to
> import my archive.db in myphpadmin but did not work so I am afraid this is
> not leading me to where I want to go. If we get your file to work we can
> use the Weewx extended which for sure will do the job.
>
> Andreas
>
> On Mon, 30 Nov 2020 at 09:09, steeple ian  wrote:
>
>> Yes I see. So you are using a separate database if I understand
>> correctly? If you use the WeeWX extended database you only need the PM
>> sensor data. I will share my method in more detail later today.
>> Ian
>>
>> On Mon, 30 Nov 2020 at 07:59, Calo Geyer  wrote:
>>
>>> See, Ian, if we managed to use this file, we got PPM10, PPM2.5,
>>> Temperature, Humitidy and Wlan.
>>>
>>> On Monday, November 30, 2020 at 8:58:06 AM UTC+1 Calo Geyer wrote:
>>>
 [image: Screenshot_20201130-085211.jpg]

 On Monday, November 30, 2020 at 8:53:16 AM UTC+1 Calo Geyer wrote:

> Hi, I also worked according this link
> https://tech.hamm7.de/blogs/feinstaub/feinstaubphp
> and managed to get the log file recording. I also created the
> feinstaub.db (using myphpadmin) which I fed by the php script (from the
> feinstaub.log) however my issue to solve was the connection of script to
> database (connectdb.php). I think I can solve soon and then we would have
> all directly in the database.
> But is good to hear that you explore the other way to get it work as
> well. Do you mind sharing details how to create the data file?
> I will share how my log now looks like in a second as I need to pick
> from home network.
> On Monday, November 30, 2020 at 8:43:49 AM UTC+1 steep...@gmail.com
> wrote:
>
>> I have worked out a method but the json data file that you have is
>> more complicated than the one I have from my process. The only data you
>> need to extract are the pm2.5 and pm10.0 figures. It is difficult to see
>> which is which in your file. My method uses a piece of php code to parse
>> the json data file and insert the data into a txt file in the format that
>> filepile requires. You must also be using the new extended WeeWX database
>> which has additional fields for air quality.
>> Ian
>>
>> On Mon, 30 Nov 2020 at 06:15, miso k  wrote:
>>
>>> Hi,
>>> I have successfully added inner Humidity fields and graphs to my
>>> webpage as a training (values are already measured). So only step is to
>>> fill the data from AirQual sensor to database.
>>> Did you find a way to do it?
>>>
>>> Michal
>>>
>>> Dátum: piatok 27. novembra 2020, čas: 21:56:07 UTC+1, odosielateľ:
>>> miso k
>>>
 Hi again,
 so I tried to do it your way, it works now.
 the feinstaub.log looks like this:
 {"time":1606510522,
 "datum":"2020-11-27",
 "zeit":"21:55:22",
 "ipAddress":"192.168.1.23",
 "daten":{"esp8266id": "759897", "software_version": "NRZ-2020-131",
 "sensordatavalues":[{"value_type":"SDS_P1","value":"465.88"},{"value_type":"SDS_P2","value":"66.15"},{"value_type":"BME280_temperature","value":"-0.09"},{"value_type":"BME280_pressure","value":"98677.09"},{"value_type":"BME280_humidity","value":"100.00"},{"value_type":"samples","value":"3565079"},{"value_type":"min_micro","value":"39"},{"value_type":"max_micro","value":"43094"},{"value_type":"interval","value":"145000"},{"value_type":"signal","value":"-62"}]}
 }

 now we need to save it to main database weewx.sdb I hope. Let's ask
 Ian how to do it with filepile.

 Or let me know, when you will be further with your solutions.

 Thanks,
 M

 Dátum: piatok 27. novembra 2020, čas: 21:29:24 UTC+1, odosielateľ:
 miso k

> so i added the file named data_simple.php with content as in the
> example above. Then I have browsed the address
> myRPiweewxIPaddress/data_simple.php and i got the answer:
> Sensor: ok
> ,but this will be also without any imput data from sensor...
> No csv is produced.
>
> rights on data_simple.php are -rw-r--r-- . is it ok?
>
>
> Dátum: piatok 27. novembra 2020, čas: 13:14:25 UTC+1, odosielateľ:
> miso k
>
>> Hello,
>> I have this answer from sensor developer:
>>
>> this feature exists in this firmware. Just look for "Send data to
>> custom API". There you can configure a server and a path to a script 
>> on
>> i.e. a Raspberry PI. If configured the firmware will send a JSON 

Re: [weewx-user] luftdaten.info - sensor.community air quality data to weewx

[Calo Geyer]

Hi Ian,

I am trying to use :-)
but I am not yet sure how to use in Weewx afterwards. I also tried to
import my archive.db in myphpadmin but did not work so I am afraid this is
not leading me to where I want to go. If we get your file to work we can
use the Weewx extended which for sure will do the job.

Andreas

On Mon, 30 Nov 2020 at 09:09, steeple ian  wrote:

> Yes I see. So you are using a separate database if I understand correctly?
> If you use the WeeWX extended database you only need the PM sensor data. I
> will share my method in more detail later today.
> Ian
>
> On Mon, 30 Nov 2020 at 07:59, Calo Geyer  wrote:
>
>> See, Ian, if we managed to use this file, we got PPM10, PPM2.5,
>> Temperature, Humitidy and Wlan.
>>
>> On Monday, November 30, 2020 at 8:58:06 AM UTC+1 Calo Geyer wrote:
>>
>>> [image: Screenshot_20201130-085211.jpg]
>>>
>>> On Monday, November 30, 2020 at 8:53:16 AM UTC+1 Calo Geyer wrote:
>>>
 Hi, I also worked according this link
 https://tech.hamm7.de/blogs/feinstaub/feinstaubphp
 and managed to get the log file recording. I also created the
 feinstaub.db (using myphpadmin) which I fed by the php script (from the
 feinstaub.log) however my issue to solve was the connection of script to
 database (connectdb.php). I think I can solve soon and then we would have
 all directly in the database.
 But is good to hear that you explore the other way to get it work as
 well. Do you mind sharing details how to create the data file?
 I will share how my log now looks like in a second as I need to pick
 from home network.
 On Monday, November 30, 2020 at 8:43:49 AM UTC+1 steep...@gmail.com
 wrote:

> I have worked out a method but the json data file that you have is
> more complicated than the one I have from my process. The only data you
> need to extract are the pm2.5 and pm10.0 figures. It is difficult to see
> which is which in your file. My method uses a piece of php code to parse
> the json data file and insert the data into a txt file in the format that
> filepile requires. You must also be using the new extended WeeWX database
> which has additional fields for air quality.
> Ian
>
> On Mon, 30 Nov 2020 at 06:15, miso k  wrote:
>
>> Hi,
>> I have successfully added inner Humidity fields and graphs to my
>> webpage as a training (values are already measured). So only step is to
>> fill the data from AirQual sensor to database.
>> Did you find a way to do it?
>>
>> Michal
>>
>> Dátum: piatok 27. novembra 2020, čas: 21:56:07 UTC+1, odosielateľ:
>> miso k
>>
>>> Hi again,
>>> so I tried to do it your way, it works now.
>>> the feinstaub.log looks like this:
>>> {"time":1606510522,
>>> "datum":"2020-11-27",
>>> "zeit":"21:55:22",
>>> "ipAddress":"192.168.1.23",
>>> "daten":{"esp8266id": "759897", "software_version": "NRZ-2020-131",
>>> "sensordatavalues":[{"value_type":"SDS_P1","value":"465.88"},{"value_type":"SDS_P2","value":"66.15"},{"value_type":"BME280_temperature","value":"-0.09"},{"value_type":"BME280_pressure","value":"98677.09"},{"value_type":"BME280_humidity","value":"100.00"},{"value_type":"samples","value":"3565079"},{"value_type":"min_micro","value":"39"},{"value_type":"max_micro","value":"43094"},{"value_type":"interval","value":"145000"},{"value_type":"signal","value":"-62"}]}
>>> }
>>>
>>> now we need to save it to main database weewx.sdb I hope. Let's ask
>>> Ian how to do it with filepile.
>>>
>>> Or let me know, when you will be further with your solutions.
>>>
>>> Thanks,
>>> M
>>>
>>> Dátum: piatok 27. novembra 2020, čas: 21:29:24 UTC+1, odosielateľ:
>>> miso k
>>>
 so i added the file named data_simple.php with content as in the
 example above. Then I have browsed the address
 myRPiweewxIPaddress/data_simple.php and i got the answer:
 Sensor: ok
 ,but this will be also without any imput data from sensor...
 No csv is produced.

 rights on data_simple.php are -rw-r--r-- . is it ok?


 Dátum: piatok 27. novembra 2020, čas: 13:14:25 UTC+1, odosielateľ:
 miso k

> Hello,
> I have this answer from sensor developer:
>
> this feature exists in this firmware. Just look for "Send data to
> custom API". There you can configure a server and a path to a script 
> on
> i.e. a Raspberry PI. If configured the firmware will send a JSON 
> object to
> this address. There is a sample script at
> https://github.com/opendata-stuttgart/madavi-api/blob/master/data_simple.php
>  that
> will take this object and save the data to a CSV file.
>
>
>
> Dňa pi 27. 11. 2020, 12:18 Calo Geyer 
> napísal(a):
>
>> And 

Re: [weewx-user] forcast wunderground for weewx 4.2.x using python 3

[Michael Waldor]

Yes, I did diff both - they are identical. But there is a minor issue: You 
did update install.py to include frzgrain.png. This is still missing within 
your  
https://github.com/chaunceygardiner/weewx-forecast/releases/tag/v3.4.0b10 - 
the png is include but it will not be installed. Is there any other 
important change maybe missing within your last zip release?

Of course that does not explain the wrong temperature numbers. I've checked 
also the foreground skin. The data are in sync with my change within 
Seasons skin. But the data do not contain the values from temperature field 
within forecast.sdb.

Don't know the internal flow of weewx/forecast. I assume that first you 
fetch json contents from WU. Then that data is uploaded into forecast.sdb. 
Afterwards during creation of HTML output the data from forecast.sdb is 
read and added into the HTML templates by forecast.py. If my assumption is 
correct there might be a problem during the step from forecast.sdg into the 
HTML output.


jo...@johnkline.com schrieb am Sonntag, 29. November 2020 um 14:36:07 UTC+1:

> > Maybe I'm using the wrong forecast_compact.inc (see my included file)? 
> And see als my forecast.sdb and 5day.json with the presumably correct temp 
> values, but not shown within the rendered window.
>
> Did you diff forecast_compact.inc with the like named file in the latest 
> forecast extension?  Are they identical?  If not, please provide the diff.
>
> Does the compact forecast in the *forecast skin* have the correct values?
>
> On Nov 29, 2020, at 1:27 AM, Michael Waldor  wrote:
>
> Sorry for posting multiple times - but google did abort any post if 
> containing *.json or *.inc files:-(
>
>
>
> Michael Waldor schrieb am Sonntag, 29. November 2020 um 10:26:00 UTC+1:
>
>> Tried to rename forecast.sdb into forecast.sdb.txt 
>>
>> Michael Waldor schrieb am Sonntag, 29. November 2020 um 10:23:34 UTC+1:
>>
>>> Sorry, but google doesn't allow me to append the data. Thus I try again 
>>> ...
>>>
>>> -- 
> 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/23bc8b05-639e-4a2b-9860-0e9b92ca6e8cn%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/86d6d50c-6653-41fb-ac02-ece43c399a0bn%40googlegroups.com.

Re: [weewx-user] luftdaten.info - sensor.community air quality data to weewx

[steeple ian]

Yes I see. So you are using a separate database if I understand correctly?
If you use the WeeWX extended database you only need the PM sensor data. I
will share my method in more detail later today.
Ian

On Mon, 30 Nov 2020 at 07:59, Calo Geyer  wrote:

> See, Ian, if we managed to use this file, we got PPM10, PPM2.5,
> Temperature, Humitidy and Wlan.
>
> On Monday, November 30, 2020 at 8:58:06 AM UTC+1 Calo Geyer wrote:
>
>> [image: Screenshot_20201130-085211.jpg]
>>
>> On Monday, November 30, 2020 at 8:53:16 AM UTC+1 Calo Geyer wrote:
>>
>>> Hi, I also worked according this link
>>> https://tech.hamm7.de/blogs/feinstaub/feinstaubphp
>>> and managed to get the log file recording. I also created the
>>> feinstaub.db (using myphpadmin) which I fed by the php script (from the
>>> feinstaub.log) however my issue to solve was the connection of script to
>>> database (connectdb.php). I think I can solve soon and then we would have
>>> all directly in the database.
>>> But is good to hear that you explore the other way to get it work as
>>> well. Do you mind sharing details how to create the data file?
>>> I will share how my log now looks like in a second as I need to pick
>>> from home network.
>>> On Monday, November 30, 2020 at 8:43:49 AM UTC+1 steep...@gmail.com
>>> wrote:
>>>
 I have worked out a method but the json data file that you have is more
 complicated than the one I have from my process. The only data you need to
 extract are the pm2.5 and pm10.0 figures. It is difficult to see which is
 which in your file. My method uses a piece of php code to parse the json
 data file and insert the data into a txt file in the format that filepile
 requires. You must also be using the new extended WeeWX database which has
 additional fields for air quality.
 Ian

 On Mon, 30 Nov 2020 at 06:15, miso k  wrote:

> Hi,
> I have successfully added inner Humidity fields and graphs to my
> webpage as a training (values are already measured). So only step is to
> fill the data from AirQual sensor to database.
> Did you find a way to do it?
>
> Michal
>
> Dátum: piatok 27. novembra 2020, čas: 21:56:07 UTC+1, odosielateľ:
> miso k
>
>> Hi again,
>> so I tried to do it your way, it works now.
>> the feinstaub.log looks like this:
>> {"time":1606510522,
>> "datum":"2020-11-27",
>> "zeit":"21:55:22",
>> "ipAddress":"192.168.1.23",
>> "daten":{"esp8266id": "759897", "software_version": "NRZ-2020-131",
>> "sensordatavalues":[{"value_type":"SDS_P1","value":"465.88"},{"value_type":"SDS_P2","value":"66.15"},{"value_type":"BME280_temperature","value":"-0.09"},{"value_type":"BME280_pressure","value":"98677.09"},{"value_type":"BME280_humidity","value":"100.00"},{"value_type":"samples","value":"3565079"},{"value_type":"min_micro","value":"39"},{"value_type":"max_micro","value":"43094"},{"value_type":"interval","value":"145000"},{"value_type":"signal","value":"-62"}]}
>> }
>>
>> now we need to save it to main database weewx.sdb I hope. Let's ask
>> Ian how to do it with filepile.
>>
>> Or let me know, when you will be further with your solutions.
>>
>> Thanks,
>> M
>>
>> Dátum: piatok 27. novembra 2020, čas: 21:29:24 UTC+1, odosielateľ:
>> miso k
>>
>>> so i added the file named data_simple.php with content as in the
>>> example above. Then I have browsed the address
>>> myRPiweewxIPaddress/data_simple.php and i got the answer:
>>> Sensor: ok
>>> ,but this will be also without any imput data from sensor...
>>> No csv is produced.
>>>
>>> rights on data_simple.php are -rw-r--r-- . is it ok?
>>>
>>>
>>> Dátum: piatok 27. novembra 2020, čas: 13:14:25 UTC+1, odosielateľ:
>>> miso k
>>>
 Hello,
 I have this answer from sensor developer:

 this feature exists in this firmware. Just look for "Send data to
 custom API". There you can configure a server and a path to a script on
 i.e. a Raspberry PI. If configured the firmware will send a JSON 
 object to
 this address. There is a sample script at
 https://github.com/opendata-stuttgart/madavi-api/blob/master/data_simple.php
  that
 will take this object and save the data to a CSV file.



 Dňa pi 27. 11. 2020, 12:18 Calo Geyer 
 napísal(a):

> And this is what I am going to do this night or later when I got
> time; changing the script to fill the database directly.
>
> https://tech.hamm7.de/blogs/feinstaub/feinstaubphp
>
> On Friday, November 27, 2020 at 12:10:01 PM UTC+1 Calo Geyer wrote:
>
>> Hi, I now made some php call using the setting "send to own API"
>> and do get the data into a log file. It basically looks like the json
>> output when you retrieve