Re: [weewx-user] Min/Max

[gjr80]

Appreciated.

One thing I don't think is mentioned in the linked thread (but you must 
have worked it out since you previously got alltime tags working) is you 
will need to tell the Standard skin to load the xstats search list. You do 
this by adding a line to the Standard skin.conf:

[CheetahGenerator]
search_list_extensions = user.xstats.ExtendedStatistics
[[ToDate]]

If there happens to already be a search_list_extensions setting in skin.conf 
(there 
shouldn't be) then instead append a comma followed by the 
user.xstats.ExtendedStatistics:

search_list_extensions = some.other.extension, 
user.xstats.ExtendedStatistics

Gary
On Thursday 12 September 2024 at 17:34:26 UTC+10 dunb...@gmail.com wrote:

> Well ThankYou*10^100
>
> On Thursday 12 September 2024 at 13:52:19 UTC+12 gjr80 wrote:
>
>> The problem is the extension installer is not finding the xstats 
>> extension files in /usr/share/doc/weewx/examples/xstats. Creating the 
>> directory just creates an empty directory but none of the xstats files will 
>> be present. I know the readme says /usr/share/doc/weewx/examples/xstats, 
>> but have a look in /etc/weewx, is there a directory named examples? If 
>> so does it contain a directory named xstats and if so does it contain 
>> the xstats extension files? If it does try this command instead:
>>
>> $ sudo weectl extension install /etc/weewx/examples/xstats
>>
>> Note that if you install the xstats extension using weectl extension the 
>> example xtstats web page will be generated each report cycle. You don't 
>> need this file so you might as well disable its generation in weewx.conf. 
>> To do this locate the [StdReport] [[xstats]] stanza and add a line enable 
>> = false as follows:
>>
>> [StdReport]
>> 
>> [[xstats]]
>> skin = xstats
>> HTML_ROOT = xstats
>> enable = false
>>
>> or you can just delete the entire [[xstats]] stanza. Either or.
>>
>> On Wednesday 11 September 2024 at 19:21:49 UTC+10 dunb...@gmail.com 
>> wrote:
>>
>> Thank you Gary, do you have a favorite charity? I would like to make a 
>> donation to it for your
>>
>>  
>> Not really. I am more than happy with just a 'thank you'
>>
>> Gary
>>
>

-- 
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/7cf00b9d-3afa-449b-b331-005896d45176n%40googlegroups.com.

Re: [weewx-user] Min/Max

[gjr80]

The problem is the extension installer is not finding the xstats extension 
files in /usr/share/doc/weewx/examples/xstats. Creating the directory just 
creates an empty directory but none of the xstats files will be present. I 
know the readme says /usr/share/doc/weewx/examples/xstats, but have a look 
in /etc/weewx, is there a directory named examples? If so does it contain a 
directory named xstats and if so does it contain the xstats extension 
files? If it does try this command instead:

$ sudo weectl extension install /etc/weewx/examples/xstats

Note that if you install the xstats extension using weectl extension the 
example xtstats web page will be generated each report cycle. You don't 
need this file so you might as well disable its generation in weewx.conf. 
To do this locate the [StdReport] [[xstats]] stanza and add a line enable = 
false as follows:

[StdReport]

[[xstats]]
skin = xstats
HTML_ROOT = xstats
enable = false

or you can just delete the entire [[xstats]] stanza. Either or.

On Wednesday 11 September 2024 at 19:21:49 UTC+10 dunb...@gmail.com wrote:

Thank you Gary, do you have a favorite charity? I would like to make a 
donation to it for your

 
Not really. I am more than happy with just a 'thank you'

Gary

-- 
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/4960c0a1-29d6-4702-8eb8-97aa21100078n%40googlegroups.com.

Re: [weewx-user] Min/Max

[gjr80]

Some comments below.

Gary

On Wednesday 11 September 2024 at 17:25:25 UTC+10 dunb...@gmail.com wrote:

Thanks Gary, 

sorry to bother you yet again with the same problem..having read back 
through our correspondence in 2019...(i can't believe I was clever enough 
to do this back thenI certainly didn't  lean not much from it...coz I 
don't feel so clever now!) I think that the steps I need to follow to get 
back to there are to 
1. install xstats.py in the correct place and 
2. put the two files above (index.html.tmpl and alltime.html.tmpl) into the 
skins folder and all should work fine.have I missed anything?


That's about it, but you will also need to tell WeeWX to generate 
alltime.html, I alluded to this further down my 2019 post but did not give 
any specifics. All you need do is edit the skin config file for your 
Standard skin and add a couple of lines to the [CheetahGenerator] [[ToDate]] 
stanza. Where that file is will depend on how you installed WeeWX. You've 
found weewx.conf, have a look in the directory containing weewx.conf and 
you should find a skins/Standard directory, that is where skin.conf should 
be. Edit skin.conf and insert the highlighted lines as follows:

[CheetahGenerator]

[[ToDate]]

[[[year]]]
template = year.html.tmpl

[[[alltime]]]
template = alltime.html.tmpl

Once you have installed xstats, created alltime.tmpl.html and modified 
skin.conf WeeWX will automatically start generating alltime.tmpl - no need 
for a restart. 
 


I should be able to find xstats.py in 
/user/share/doc/weewx/examples.but as you will see from the attached 
screenshot.that folder does not exist.what am I missing?


Another v5 change I'm afraid. Again the location of the examples (and 
xstats) depends on how you installed WeeWX. Have a look in the directory 
containing weewx.conf, you should see a directory named examples; that is 
where you should find the xstats directory. Read the readme.txt, it has 
been updated for v5, and (again) I expect you will want to follow the 
manual install instructions.
 

-- 
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/96af7092-723c-45a3-9d70-8af19cc9b547n%40googlegroups.com.

Re: [weewx-user] Min/Max

[gjr80]

Had a quick look at those files and they should be fine, or if not pretty 
close to the mark. index.html.tmpl has the code for a 'Max/Min' button and 
alltime.html.tmpl appears to have all the correct $alltime tags. See how 
you go. Then once its working make a backup copy of you skins directory and 
weewx.conf to keep with your regular database backups. :)

Gary
On Tuesday 10 September 2024 at 17:21:26 UTC+10 dunb...@gmail.com wrote:

> Thanks for that! I have found these two files from 2019...hopefully they 
> are the correct onesas they are from 2019 (according to the time stamp!)
>
>
> On Tuesday 10 September 2024 at 17:40:35 UTC+12 gjr80 wrote:
>
>> On Tuesday 10 September 2024 at 14:32:20 UTC+10 dunb...@gmail.com wrote:
>>
>> see what I mean about being (well) over 60! 
>>
>>
>> Tell me about it, almost but not quite there yet!
>>
>> alltime.html.tmpl is what you want, hopefully it's a recent copy. While 
>> you're looking see if you have an old copy of index.html.tmpl, it will 
>> likely have the code that added an 'alltime' button to the bottom of your 
>> main page, but if not that one is an easy fix.
>>
>> Gary
>>  
>>
>

-- 
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/a3a20864-194e-4c18-89bc-945ea595b534n%40googlegroups.com.

Re: [weewx-user] Min/Max

[gjr80]

On Tuesday 10 September 2024 at 14:32:20 UTC+10 dunb...@gmail.com wrote:

see what I mean about being (well) over 60! 


Tell me about it, almost but not quite there yet!

alltime.html.tmpl is what you want, hopefully it's a recent copy. While 
you're looking see if you have an old copy of index.html.tmpl, it will 
likely have the code that added an 'alltime' button to the bottom of your 
main page, but if not that one is an easy fix.

Gary
 

-- 
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/91ac68e5-e2f0-49bb-b84a-3dafbc8428f9n%40googlegroups.com.

Re: [weewx-user] Min/Max

[gjr80]

I seem to remember helping you with this a few years ago, if you are still 
using the Standard skin this thread 
 may 
help. You would have to work through manually to reconstruct your page, but 
I guess that is the price you have to pay. If you are using/intending to 
use the Seasons skin then that link will be of limited use as the Seasons 
skin works quite differently.

Gary

On Tuesday 10 September 2024 at 07:20:39 UTC+10 dunb...@gmail.com wrote:

> Ahm! Over 60 covers a lot of ground! :)...but you win the 
> burrito!...anyway...back to the matter at handremind me, please, 
> how to call the  alltime template from the standard template?
>
> On Tuesday 10 September 2024 at 01:36:10 UTC+12 Tom Keffer wrote:
>
>> I'm 72.
>>
>> On Sun, Sep 8, 2024 at 6:50 PM Monica Mulholland  
>> wrote:
>>
>>> Yes, I just found the alltime templatebeing over 60, my memory is 
>>> not as good as it was! See attached.how do I call that sheet from the 
>>> main HTML sheet? 
>>>
>>> On Monday 9 September 2024 at 13:46:32 UTC+12 Tom Keffer wrote:
>>>
 Of course. For example, the tag

 *$alltime.outTemp.max*


 will give the maximum temperature ever seen.

 It's all in the *Customization Guide 
 *, in this case, 
 section *Aggregation periods 
 *.
  
 Be sure to read it.

 -tk



 On Sun, Sep 8, 2024 at 6:40 PM Monica Mulholland  
 wrote:

> Hmm! Is there  a way of interrogating the data to find min/max temp, 
> rainfall etc.of the history?
>
> On Monday 9 September 2024 at 13:34:34 UTC+12 Tom Keffer wrote:
>
>> That does not sound familiar. You must have been using a 3rd party 
>> skin.
>>
>> Maybe it triggers somebody else's memory...?
>>
>> On Sun, Sep 8, 2024 at 6:29 PM Monica Mulholland  
>> wrote:
>>
>>> Apologies for that confusion. I should have been more clear. In a 
>>> previous version of my HTML sheet, (an example of which I do not have 
>>> any 
>>> more)...at the bottom of the sheet, along with the week, month, year 
>>> was a 
>>> button which would allow one to look at the global min or max for all 
>>> of 
>>> the history. Does that make any more sense. I had to redo the HTML when 
>>> I 
>>> had a crash and decided to change from a Pi3 to a Pi4and somewhere 
>>> along the way (while setting up the new HTML sheet) I seem to have 
>>> missed 
>>> out putting in the min/max buttons. Thank you for your help!
>>>
>>> On Monday 9 September 2024 at 11:58:27 UTC+12 Tom Keffer wrote:
>>>
 Monica, you are being very vague. Which previous version of the 
 html output? You're making us look through your emails trying to 
 figure out 
 what you're referring to. Attach it!

 Don't know what you mean by min/max at the bottom. None of the 
 WeeWX skins include a min/max of anything along the bottom. Maybe 
 along the 
 side? And, min/max of what?

 On Sun, Sep 8, 2024 at 4:25 PM Monica Mulholland  
 wrote:

> In my previous version of the html output, I had a min/max at the 
> bottom along with month, year, day etc. - see attached. Can somebody 
> please 
> remind me how  how to find how/where to turn this on.
>
> -- 
> 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/95efbe46-d035-4514-9d2e-c2cec3056bffn%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/76f2f44c-97ed-4d72-9e70-d4de431d40e3n%40googlegroups.com
>>>  
>>> 
>>> .
>>>
>> -- 
> You received this message because you are subscribed to the Google 
> Groups "weewx-user" group.
> To unsubscribe from this group and stop receivi

[weewx-user] Re: Mqtt values formated to 2 digits won't work

[gjr80]

Alex, you have the correct uploader installed. Compare your current 
installed extension list:

pi@RPi-Weewx:/etc/weewx $ sudo weectl extension list
Using configuration file /etc/weewx/weewx.conf
Extension NameVersion   Description
mqtt  0.24  Upload weather data to MQTT server.

to your old list:

weectl extension list
Using configuration file /etc/weewx/weewx.conf
Extension NameVersion   Description
MQTT  0.2.0 Extension for uploading LOOP data to an MQTT 
broker

Matthew's uploader is at v0.24.

As Vince said the uploader formatting works. The next thing to do is look 
at your config. Unfortunately the uploader does not log the upload format 
settings so you will need to provide that manually. I suggest you use weectl 
debug <http://weewx.com/docs/5.1/utilities/weectl-debug/> to generate a 
debug report and post that report. Check the report output carefully, weectl 
debug should obfuscate sensitive information but it is not perfect.

Gary
On Friday 30 August 2024 at 07:17:14 UTC+10 al@web.de wrote:

> Hi Gary,
> I repeated the mqtt precedure and
> ##
> pi@RPi-Weewx:/etc/weewx $ sudo weectl extension list
>
> Using configuration file /etc/weewx/weewx.conf
> Extension NameVersion   Description
> mqtt  0.24  Upload weather data to MQTT server.
> ##
> That seems to be also not Matthew's version.
> The log (see attachment) and a trace in the broker reveals, that my 
> desired behavior is not fullfilled.
> So I'm still unhappy.
>
> br.
>
> Alex
>
>
>
> gjr80 schrieb am Dienstag, 27. August 2024 um 06:23:03 UTC+2:
>
>> A bit of googling suggests that this:
>>
>> Extension NameVersion   Description
>> MQTT  0.2.0 Extension for uploading LOOP data to an MQTT 
>> broker
>>
>> refers to the extension in this repo: 
>> https://github.com/michael-slx/weewx-mqtt. Looking through the code for 
>> this extension it does not support formatting the MQTT output as you wish 
>> to. I'm not sure what if any advantages the Michael-six uploader offers 
>> over the matthewwall uploader.
>>
>> As for your re-installlation problem. You appear to be using a package 
>> install of WeeWX v5. I know the instructions say to use pip to install 
>> paho-mqtt, but I find when you are not using a virtual python 
>> environment it is all to easy to end up with a non-functional install when 
>> using pip to install some packages. Try using apt to install paho-mqtt:
>> $ sudo apt update
>> $ sudo apt-cache policy python3-paho-mqtt
>>
>> this should show what version of paho-mqtt will be installed, something 
>> like:
>> python3-paho-mqtt:
>>   Installed: (none)
>>   Candidate: 1.6.1-1
>>   Version table:
>>  1.6.1-1 500
>> 500 http://deb.debian.org/debian bookworm/main arm64 Packages
>> 500 http://deb.debian.org/debian bookworm/main armhf Packages
>>
>> Provided the candidate version is 1.6.1 or lower (ie it is not v2.x.y) 
>> install paho-mqtt using:
>> $ sudo apt install python3-paho-mqtt
>>
>> You should be able to complete the rest of the uploader install/setup. If 
>> it does not work as expected edit weewx.conf, set debug = 2 and restart 
>> WeeWX. Post a log extract showing the complete WeeWX startup and the first 
>> few MQTT uploads. Also post the output from weectl debug as per 
>> instructions in my earlier post.
>>
>> Whether you previously installed paho-mqtt using pip or apt makes no 
>> difference to what WeeWX MQTT uploader was installed/used; somehow you 
>> separately installed the Michael-six uploader rather than the matthewwall 
>> uploader.
>>
>> Gary
>> On Monday 26 August 2024 at 22:09:38 UTC+10 al@web.de wrote:
>>
>>> Hi Gary,
>>>
>>> I checked your hint regarding MQTT version:
>>>
>>> First time, I installed step by step the instruction of the mentioned 
>>> link
>>> a list in weewx control tells me:
>>> weectl extension list
>>> Using configuration file /etc/weewx/weewx.conf
>>> Extension NameVersion   Description
>>> MQTT  0.2.0 Extension for uploading LOOP data to an MQTT 
>>> broker
>>> So I checked the installed packages regarding mqtt:
>>>  apt list | grep mqtt
>>>
>>> WARNING: apt does not have a stable CLI interface. Use with caution in 
>>> scripts.
>>>
>>> golang-github-eclipse-paho.mqtt.golang-dev/stable 1.1.1-1.1 all
>>> kamailio-mqtt-modules/stable 5.6.3-2+rpi1+b1 arm

Re: [weewx-user] Re: Weatther Station stops same time every week

[gjr80]

I have no idea what might be causing your nightly stoppage, but from the 
most recent log posted you almost certainly have corrupt station memory. 
The clues are in hardware record generation being used, WeeWX talking to 
the console/logger but no archive records being dowloaded and reports are 
generated normally but with no new data. The net effect is that WeeWX can 
obtain loop packet data from the console but it cannot obtain archive 
records. You might want to work through the Corrupt station memory 

 
section of the Troubleshooting the Davis Vantage station wiki page 

.

As for the nightly stoppage, once you get your station working again you 
might want to leave debug = 1 and post a log extract covering say 30 
minutes either side of the stoppage time.

Gary

On Thursday 29 August 2024 at 06:53:02 UTC+10 dunb...@gmail.com wrote:

> But, it is not running at all at the moment.it is not showing on the 
> website. On Wunderground it says offline. Despite repeated reboots, it has 
> not run in nearly a week. 
>
> On Thursday 29 August 2024 at 05:57:50 UTC+12 vince wrote:
>
>> Let it run through the weekend and if it fails again this Saturday post 
>> whatever is logged please.
>>
>> On Wednesday, August 28, 2024 at 12:55:24 AM UTC-7 dunbrokin wrote:
>>
>>> OK, lets see if I can get it right this time!
>>>  mylog 
>>> 
>>>
>>> On Tue, Aug 27, 2024 at 2:15 PM vince  wrote:
>>>
 Set debug=1 and maybe we can figure it out

 On Monday, August 26, 2024 at 1:02:43 PM UTC-7 dunbrokin wrote:

> Oops Sorry, I thought I had hardwired in debug=1.bottom of the 
> class for me on this one I thinkmade all the rookie mistakes. 
> Apologies 
> for wasting your time!
>
>
> On Tue, Aug 27, 2024 at 4:20 AM vince  wrote:
>
>> Sigh - as always, set debug=1 and let it run for more like 35 
>> minutes.  You have an archive period of 10 minutes if it's running off 
>> the 
>> hardware interval of 600 seconds so we need to see a few cycles.
>>
>> On Monday, August 26, 2024 at 1:38:03 AM UTC-7 dunbrokin wrote:
>>
>>> Apologies, yes it's always a good idea.
>>>
>>>  For the last 3 weeks on Sat night at 11.50 it stopped 
>>> recording.but rebooting started it again the next day. However this 
>>> week after rebooting it stopped at 11.10 am and despite rebooting, it 
>>> never 
>>> started recording again.
>>>
>>> So I ran the log as per the instructionsbut it only ran for 
>>> about 6 minutes. Attached is all that was recorded in almost 15 minutes.
>>>
>>>
>>> On Sun, Aug 25, 2024 at 1:33 PM vince  wrote:
>>>
 Your system logs.

 On Saturday, August 24, 2024 at 4:16:58 PM UTC-7 Monica Mulholland 
 wrote:

> Every week, on Saturday night at 11.50 pm my station stops 
> reporting and needs to be rebooted. I am on a RPi4 (recently 
> upgraded). 
> Other than this little glitch, which is annoying, it is running very 
> well 
> since I upgraded to the RPi4.
>
> Any suggestions of where I might look to try and sort this issue?
>
> Any help greatly appreciated.
>
 -- 
 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/68cf6bec-901e-449d-b75a-45b3fc7c75b5n%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/79829310-aa83-4281-9244-7cc9adbc0037n%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 o

[weewx-user] Re: Mqtt values formated to 2 digits won't work

[gjr80]

A bit of googling suggests that this:

Extension NameVersion   Description
MQTT  0.2.0 Extension for uploading LOOP data to an MQTT 
broker

refers to the extension in this repo: 
https://github.com/michael-slx/weewx-mqtt. Looking through the code for 
this extension it does not support formatting the MQTT output as you wish 
to. I'm not sure what if any advantages the Michael-six uploader offers 
over the matthewwall uploader.

As for your re-installlation problem. You appear to be using a package 
install of WeeWX v5. I know the instructions say to use pip to install 
paho-mqtt, but I find when you are not using a virtual python environment 
it is all to easy to end up with a non-functional install when using pip to 
install some packages. Try using apt to install paho-mqtt:
$ sudo apt update
$ sudo apt-cache policy python3-paho-mqtt

this should show what version of paho-mqtt will be installed, something 
like:
python3-paho-mqtt:
  Installed: (none)
  Candidate: 1.6.1-1
  Version table:
 1.6.1-1 500
500 http://deb.debian.org/debian bookworm/main arm64 Packages
500 http://deb.debian.org/debian bookworm/main armhf Packages

Provided the candidate version is 1.6.1 or lower (ie it is not v2.x.y) 
install paho-mqtt using:
$ sudo apt install python3-paho-mqtt

You should be able to complete the rest of the uploader install/setup. If 
it does not work as expected edit weewx.conf, set debug = 2 and restart 
WeeWX. Post a log extract showing the complete WeeWX startup and the first 
few MQTT uploads. Also post the output from weectl debug as per 
instructions in my earlier post.

Whether you previously installed paho-mqtt using pip or apt makes no 
difference to what WeeWX MQTT uploader was installed/used; somehow you 
separately installed the Michael-six uploader rather than the matthewwall 
uploader.

Gary
On Monday 26 August 2024 at 22:09:38 UTC+10 al@web.de wrote:

> Hi Gary,
>
> I checked your hint regarding MQTT version:
>
> First time, I installed step by step the instruction of the mentioned link
> a list in weewx control tells me:
> weectl extension list
> Using configuration file /etc/weewx/weewx.conf
> Extension NameVersion   Description
> MQTT  0.2.0 Extension for uploading LOOP data to an MQTT 
> broker
> So I checked the installed packages regarding mqtt:
>  apt list | grep mqtt
>
> WARNING: apt does not have a stable CLI interface. Use with caution in 
> scripts.
>
> golang-github-eclipse-paho.mqtt.golang-dev/stable 1.1.1-1.1 all
> kamailio-mqtt-modules/stable 5.6.3-2+rpi1+b1 armhf
> libmqtt-client-java/stable 1.16-1 all
> libpaho-mqtt-dev/stable 1.3.12-1 armhf
> libpaho-mqtt1.3/stable 1.3.12-1 armhf
> libpaho-mqttpp-dev/stable 1.2.0-2 armhf
> libpaho-mqttpp3-1/stable 1.2.0-2 armhf
> node-mqtt-connection/stable 4.1.0-4 all
> node-mqtt-packet/stable 8.1.2-2 all
> node-mqtt/stable 4.3.7-2 all
> paho.mqtt.c-examples/stable 1.3.12-1 armhf
> prometheus-mqtt-exporter/stable 0.1.7-1 armhf
> python3-asyncio-mqtt/stable 0.16.1-3 all
> python3-hbmqtt/stable 0.9.6-1.2 all
> python3-paho-mqtt/stable,now 1.6.1-1 all  [installiert]
>
> To repeat the install process, I removed MQTT in weewx and removed 
> paho-mqtt in apt
> Reinstall according the instruction:
> wget -O weewx-mqtt.zip 
> https://github.com/matthewwall/weewx-mqtt/archive/master.zip
> sudo pip install paho-mqtt==1.6.1
> error: externally-managed-environment
>
> × This environment is externally managed
> ╰─> To install Python packages system-wide, try apt install
> python3-xyz, where xyz is the package you are trying to
> install.
>
> If you wish to install a non-Debian-packaged Python package,
> create a virtual environment using python3 -m venv path/to/venv.
> Then use path/to/venv/bin/python and path/to/venv/bin/pip. Make
> sure you have python3-full installed.
>
> For more information visit http://rptl.io/venv
>
> note: If you believe this is a mistake, please contact your Python 
> installation or OS distribution provider. You can override this, at the 
> risk of breaking your Python installation or OS, by passing 
> --break-system-packages.
> hint: See PEP 668 for the detailed specification.
>
> => This error occured also at primary installation, so I installed the 
> paho-mqtt with apt.
> Maybe thats the key, why weewx mapped to a complete other version of mqtt?
> Finally the list in apt reveals also other mqtt 
>
> So, what to do?
>
> br
>
> Alex
>
> gjr80 schrieb am Montag, 26. August 2024 um 04:05:25 UTC+2:
>
>> So exactly what MQTT service are you using? Your initial post includes 
>> the link https://github.com/weewx/weewx/wiki/mqtt (which in turn links 
>> to Matthew's RESTful MQTT uploader) an

[weewx-user] Re: Mqtt values formated to 2 digits won't work

[gjr80]

So exactly what MQTT service are you using? Your initial post includes the 
link https://github.com/weewx/weewx/wiki/mqtt (which in turn links to 
Matthew's RESTful MQTT uploader) and the instructions on that page are 
specific to Matthew's uploader. The log extract just provided shows 
user.mqtt.MqttService being loaded:

2024-08-25T19:43:39.786798+02:00 RPi-Weewx weewxd[3614]: DEBUG 
weewx.engine: Loading service user.mqtt.MqttService
2024-08-25T19:43:39.862785+02:00 RPi-Weewx weewxd[3614]: DEBUG user.mqtt: 
Initializing MQTT service
2024-08-25T19:43:39.863826+02:00 RPi-Weewx weewxd[3614]: DEBUG user.mqtt: 
Creating MQTT client with id "weewx_21680fb1"
2024-08-25T19:43:39.881839+02:00 RPi-Weewx weewxd[3614]: DEBUG user.mqtt: 
Starting MQTT client
2024-08-25T19:43:39.882861+02:00 RPi-Weewx weewxd[3614]: DEBUG 
weewx.engine: Finished loading service user.mqtt.MqttService

 but Matthew's uploader has no class named MqttService (it has class MQTT). 
So it is clear you are not using Matthew's MQTT uploader.

You might want to look up the instructions for use for whatever MQTT 
service you are using, or post details of the MQTT service you are using 
and we will see what we can work out.

Gary

On Monday 26 August 2024 at 04:05:46 UTC+10 al@web.de wrote:

> Hi Gary,
>
> I took an exploit from syslog with debug-level 2, see attachment.
> As I mentioned, the observation data for wind, gust and outtemp are still 
> transmitted unformated, I also realiezed that rain values ( 
> "weather/rain_mm": 0.0 (mm)" ) have always zero values although the website 
> tells me the correct rain of today  = 2.6 mm, also the rain_hour value 
> isn't okay with mqtt.
>
> br.
>
> Alex
>
> gjr80 schrieb am Dienstag, 20. August 2024 um 22:29:48 UTC+2:
>
>> I suggest you edit weewx.conf, set debug = 2, save weewx.conf and 
>> restart WeeWX. Let WeeWX run for at least two archive periods then take a 
>> log extract showing the full WeeWX startup through until the two archive 
>> periods have elapsed. Post the unaltered log extract here. Also worthwhile 
>> posting the output of weectl debug 
>> <http://weewx.com/docs/5.1/utilities/weectl-debug/> (or wee_debug 
>> <http://weewx.com/docs/4.10/utilities.htm#wee_debug_utility> if using 
>> WeeWX v4 or earlier). Check the output for sensitive data (eg passwords, 
>> user names, keys etc) before posting, weectl debug should obfuscate 
>> these but it is not perfect. 
>>
>> Gary
>>
>> On Tuesday 20 August 2024 at 22:19:55 UTC+10 al@web.de wrote:
>>
>>> Hi Gary,
>>> thanks for your advice. After the modification of weewx.conf mqtt data 
>>> is still delivered (so tha's positive), but no change in the number of 
>>> decimal places.
>>> My config:
>>> #
>>>  [[MQTT]]
>>>
>>>enable = true
>>> unit_system = METRICWX
>>> # Hostname/IP of MQTT broker
>>> host = 192.168.2.22
>>> topic = weather
>>> #append_units_label = false
>>>
>>> [[[inputs]]]
>>> outTemp
>>> format = %.2f# use two decimal places of 
>>> precision
>>> name = outside_temperature# use label other than 
>>> inTemp
>>> windSpeed
>>> units = meter_per_second
>>> format = %.1f
>>> name = windSpeed_m_s
>>> windGust
>>> units = meter_per_second
>>> format = %.1f
>>> name = gust_m_s
>>> ###
>>>
>>> and the result in the broker:
>>> ###
>>> weather/inTemp_degree_C 27.29
>>> weather/inHumidity_percent 67
>>> weather/outTemp_degree_C 24.703
>>> weather/outHumidity_percent 64
>>> weather/pressure_mbar 1012.8
>>> weather/windSpeed_meter_per_second 0.4099419637863
>>> weather/windGust_meter_per_second 0.614912945679
>>> weather/windDir_degree_compass 112.5
>>> weather/windGustDir_degree_compass 112.5
>>> weather/rainRate_mm_per_hour 0.0
>>> weather/rain_mm (null)
>>> weather/rxCheckPercent_percent 100
>>> weather/windBatteryStatus 0
>>> weather/rainBatteryStatus 0
>>> weather/outTempBatteryStatus 0
>>> weather/inTempBatteryStatus 0
>>> weather/altimeter_mbar 1056.8811153752754
>>> weather/appTemp_degree_C 26.97221024

[weewx-user] Re: Plots by Year?

[gjr80]

Unfortunately the WeeWX image generator cannot do this.

Gary

On Thursday 22 August 2024 at 22:35:48 UTC+10 wfs...@gmail.com wrote:

> Can Imagegenerator create plots with a separate line for each calendar 
> year?
> Examples:
> X axis 1/1 thru 12/31, Y axis daily max outtemp, separate line for each 
> year
>
> X axis Jan, Feb, Mar,...Dec, Y axis month total rain, separate line for 
> each year
>
> Not sure this is possible, but I thought I'd ask.
>
> Thanks,
> Walt
>

-- 
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/3f87e4f9-007c-4bfc-9500-effd7a4c8e5dn%40googlegroups.com.

[weewx-user] Re: Mqtt values formated to 2 digits won't work

[gjr80]

I suggest you edit weewx.conf, set debug = 2, save weewx.conf and restart 
WeeWX. Let WeeWX run for at least two archive periods then take a log 
extract showing the full WeeWX startup through until the two archive 
periods have elapsed. Post the unaltered log extract here. Also worthwhile 
posting the output of weectl debug 
<http://weewx.com/docs/5.1/utilities/weectl-debug/> (or wee_debug 
<http://weewx.com/docs/4.10/utilities.htm#wee_debug_utility> if using WeeWX 
v4 or earlier). Check the output for sensitive data (eg passwords, user 
names, keys etc) before posting, weectl debug should obfuscate these but it 
is not perfect. 

Gary

On Tuesday 20 August 2024 at 22:19:55 UTC+10 al@web.de wrote:

> Hi Gary,
> thanks for your advice. After the modification of weewx.conf mqtt data is 
> still delivered (so tha's positive), but no change in the number of decimal 
> places.
> My config:
> #
>  [[MQTT]]
>
>enable = true
> unit_system = METRICWX
> # Hostname/IP of MQTT broker
> host = 192.168.2.22
> topic = weather
> #append_units_label = false
>
> [[[inputs]]]
> outTemp
> format = %.2f# use two decimal places of 
> precision
> name = outside_temperature# use label other than inTemp
> windSpeed
> units = meter_per_second
> format = %.1f
> name = windSpeed_m_s
> windGust
> units = meter_per_second
> format = %.1f
> name = gust_m_s
> ###
>
> and the result in the broker:
> ###
> weather/inTemp_degree_C 27.29
> weather/inHumidity_percent 67
> weather/outTemp_degree_C 24.703
> weather/outHumidity_percent 64
> weather/pressure_mbar 1012.8
> weather/windSpeed_meter_per_second 0.4099419637863
> weather/windGust_meter_per_second 0.614912945679
> weather/windDir_degree_compass 112.5
> weather/windGustDir_degree_compass 112.5
> weather/rainRate_mm_per_hour 0.0
> weather/rain_mm (null)
> weather/rxCheckPercent_percent 100
> weather/windBatteryStatus 0
> weather/rainBatteryStatus 0
> weather/outTempBatteryStatus 0
> weather/inTempBatteryStatus 0
> weather/altimeter_mbar 1056.8811153752754
> weather/appTemp_degree_C 26.97221024879724
> weather/barometer_mbar 1055.5080297221955
> weather/cloudbase_meter 1267.4829583543142
> weather/dewpoint_degree_C 17.422122081623723
> weather/ET_mm (null)
> weather/heatindex_degree_C 24.896667
> weather/humidex_degree_C 30.293088441750406
> weather/inDewpoint_degree_C 20.621737268345424
> weather/maxSolarRad_watt_per_meter_squared 813.5477625196611
> weather/windchill_degree_C 24.703
> weather/windrun_km (null)
> weather/usUnits 17
> ###
>
> Something goes wrong, but I've no idea
>
> br
>
> Alex
>
> gjr80 schrieb am Dienstag, 20. August 2024 um 11:02:39 UTC+2:
>
>> Your config stanza format is incorrect; you cannot just insert 
>> sub-stanzas in the middle of an existing stanza, the sub-stanzas need to be 
>> added to the end. In the case of a WeeWX config file indents don't matter 
>> but order does. Try something like:
>>
>>  [[MQTT]]# Enable/disable this service
>> enable = true
>> unit_system = METRICWX
>> # Hostname/IP of MQTT broker
>> host = 192.168.2.22
>> topic = weather
>> [[[inputs]]]
>> outTemp
>> format = %.2f# use two decimal places of 
>> precision
>> name = outside_temperature# use label other than 
>> inTemp
>> windSpeed
>> units = meter_per_second
>> format = %.2f
>> name = wind_m_s
>>
>> The order you had meant the MQTT uploader was never seeing the host and 
>> topic config entries.
>>
>> If that doesn't work post a log extract showing the error.
>>
>> Gary
>> On Tuesday 20 August 2024 at 06:40:46 UTC+10 al@web.de wrote:
>>
>>> With this config, the weather values are puplished, but (i guess) due to 
>>> convert from US (within db) to Metricwx with up to 16 decimal places. 
>>> ###
>>>  [[MQTT]]# Enable/disable this service
>>> enable = true
>>> unit_system = METRICWX
>>> # Hostname/IP of MQTT broker
>>> host = 1

[weewx-user] Re: Mqtt values formated to 2 digits won't work

[gjr80]

Your config stanza format is incorrect; you cannot just insert sub-stanzas 
in the middle of an existing stanza, the sub-stanzas need to be added to 
the end. In the case of a WeeWX config file indents don't matter but order 
does. Try something like:

 [[MQTT]]# Enable/disable this service
enable = true
unit_system = METRICWX
# Hostname/IP of MQTT broker
host = 192.168.2.22
topic = weather
[[[inputs]]]
outTemp
format = %.2f# use two decimal places of 
precision
name = outside_temperature# use label other than inTemp
windSpeed
units = meter_per_second
format = %.2f
name = wind_m_s

The order you had meant the MQTT uploader was never seeing the host and 
topic config entries.

If that doesn't work post a log extract showing the error.

Gary
On Tuesday 20 August 2024 at 06:40:46 UTC+10 al@web.de wrote:

> With this config, the weather values are puplished, but (i guess) due to 
> convert from US (within db) to Metricwx with up to 16 decimal places. 
> ###
>  [[MQTT]]# Enable/disable this service
> enable = true
> unit_system = METRICWX
> # Hostname/IP of MQTT broker
> host = 192.168.2.22
> # Prefix for topics
> topic = weather
> #
> I took one exemple from https://github.com/weewx/weewx/wiki/mqtt to 
> reduce the
> decimal places of the published values, but with this config, mqtt stops 
> working.
> #
>  [[MQTT]]# Enable/disable this service
> enable = true
> unit_system = METRICWX
> [[[inputs]]]
> outTemp
> format = %.2f# use two decimal places of 
> precision
> name = outside_temperature# use label other than inTemp
> windSpeed
> units = meter_per_second
> format = %.2f
> name = wind_m_s
>
> # Hostname/IP of MQTT broker
> host = 192.168.2.22
> topic = weather 
> #
>
> What could be wrong in the configuration?
> My aim ist to limit all published values to a max. of 2 digits behind the 
> dot
> e. g. instead 
> weather/windSpeed_meter_per_second 0.4099419637863
> is should be:
> weather/windSpeed_meter_per_second 0.4
>
> br
> Alex
>

-- 
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/5627b007-b463-432b-9616-db5ad90608cfn%40googlegroups.com.

Re: [weewx-user] Re: GW1000 driver doesn't show values from WH46

[gjr80]

Thank you for the feedback.

I have now released v0.6.3 
<https://github.com/gjr80/weewx-gw1000/releases/tag/v0.6.3>.

Gary

On Thursday 1 August 2024 at 21:23:59 UTC+10 j.fri...@gmail.com wrote:

> Hi Gary,
>
> It works very well now.
>
> Thank you for your help.
>
> Jarda
>
> čt 1. 8. 2024 v 13:12 odesílatel gjr80  napsal:
>
>> As Rainer mentioned the issue is likely that the unit group has not been 
>> defined for the PM4 obs type in your database (though this will depend on 
>> your driver setup, database schema and skin you are using). Unit groups for 
>> additional obs types are often defined by the user in extensions.py, but 
>> can also be done in the driver. The gateway driver does define unit groups 
>> for all WeeWX fields in the default field map that do not appear in the 
>> default WeeWX schema (ie the wview_extended schema). I neglected to 
>> update this portion of the driver for the new/updated 'PM' fields in 
>> v0.6.3.b1, I have since made the necessary changes. If you delete the 
>> v0.6.3b1 driver using:
>>
>> $ rm /etc/weewx/bin/user/gw1000.py
>>
>> and then download v0.6.3b2 in it's place using:
>>
>> $ wget -P /etc/weewx/bin/user 
>> https://raw.githubusercontent.com/gjr80/weewx-gw1000/v0.6.3/bin/user/gw1000.py
>>
>> and finally restart WeeWX your PM4 data should display with correct 
>> formatting/labelling.
>>
>> Gary
>>
>> On Thursday 1 August 2024 at 16:08:48 UTC+10 j.fri...@gmail.com wrote:
>>
>>> Hi Gary,
>>>
>>> the  v0.6.3b1 works wery well. There is only one possible issue with PMI 
>>> 4. index.html page shows it in other way then others values .
>>>
>>> Thank you very much for your help.
>>>
>>> Jarda
>>>
>>> *Outout from the driver :*
>>> 'pm1_0': '9.5', 'pm1_0_24h_avg': '1.5', 'pm2_55': '10.6', 
>>> 'pm2_55_24h_avg': '2.5', 'pm4_0': '11.0', 'pm4_0_24h_avg': '3.2', 'pm10_0': 
>>> '11.2', 'pm10_0_24h_avg': '3.6'
>>>
>>> *Database values :*
>>> PM1.0  = 10.6
>>> PM2.5  = 11.7
>>> PM4.0  =  12.06667
>>> PM10 =  12.26667
>>>
>>> *Index.html page :*
>>> [image: Výstřižek.PNG]
>>>
>>>
>>>
>>> Dne úterý 30. července 2024 v 13:51:16 UTC+2 uživatel gjr80 napsal:
>>>
>>> You can try v0.6.3b1 which includes support for the WH46 air quality 
>>> sensor. If a WH46 is connected the v0.6.3 driver should emit the same 
>>> temperature, PM2.5, PM10 and CO2 fields as with a WH45. Additional fields 
>>> pm1_0, pm1_0_24h_avg, pm4_0, pm4_0_24h_avg should also be emitted with 
>>> the WH46 PM1 and PM4 data and 24hour averages respectively. v0.6.3 should 
>>> also automatically determine whether a WH45 or WH46 is present and 
>>> correctly name WH45/WH46 battery and signal state fields.
>>>
>>> Note that I have had to change the names of a the PM10 fields emitted by 
>>> the driver when used with a WH45 sensor. This will only affect you if you 
>>> previously used a WH45 sensor. The driver now emits pm10_0 and 
>>> pm10_0_24h_avg fields (previously the fields were pm10 and pm10_24h_avg). 
>>> Users who have previously used a WH45 sensor will need to either change 
>>> their field map if mapping these fields to some other WeeWX field, or if 
>>> the pm10 and pm10_24h_avg fields are used in the database schema the 
>>> database fields will need to be renamed to the new field names.
>>>
>>> v0.6.3 also includes support for the WS85 sensor array as well as 
>>> including a revised approach to device discovery that is much more reliable 
>>> than the previous approach. Note the recommended approach remains to 
>>> specify the device IP address in the WeeWX config file rather than have the 
>>> driver rely on discovery
>>>
>>> I have not released v0.6.3 yet, rather I have kept it at b1 until 
>>> someone verifies it's use it with a WH45/46. If you wish to try v0.6.3b1 
>>> the following instructions should be used:
>>>
>>> 1. Rename your existing gateway driver to gw1000_0_6_1.py so you can 
>>> easily revert if necessary:
>>> $ cp /etc/weewx/bin/user/gw1000.py /etc/weewx/bin/user/gw1000_0_6_1.py
>>>
>>> 2. Download the v0.6.3b1 driver file and save it to /etc/weewx/bin/user:
>>> 

[weewx-user] Re: GW1000 driver doesn't show values from WH46

[gjr80]

As Rainer mentioned the issue is likely that the unit group has not been 
defined for the PM4 obs type in your database (though this will depend on 
your driver setup, database schema and skin you are using). Unit groups for 
additional obs types are often defined by the user in extensions.py, but 
can also be done in the driver. The gateway driver does define unit groups 
for all WeeWX fields in the default field map that do not appear in the 
default WeeWX schema (ie the wview_extended schema). I neglected to update 
this portion of the driver for the new/updated 'PM' fields in v0.6.3.b1, I 
have since made the necessary changes. If you delete the v0.6.3b1 driver 
using:

$ rm /etc/weewx/bin/user/gw1000.py

and then download v0.6.3b2 in it's place using:

$ wget -P /etc/weewx/bin/user 
https://raw.githubusercontent.com/gjr80/weewx-gw1000/v0.6.3/bin/user/gw1000.py

and finally restart WeeWX your PM4 data should display with correct 
formatting/labelling.

Gary

On Thursday 1 August 2024 at 16:08:48 UTC+10 j.fri...@gmail.com wrote:

> Hi Gary,
>
> the  v0.6.3b1 works wery well. There is only one possible issue with PMI 
> 4. index.html page shows it in other way then others values .
>
> Thank you very much for your help.
>
> Jarda
>
> *Outout from the driver :*
> 'pm1_0': '9.5', 'pm1_0_24h_avg': '1.5', 'pm2_55': '10.6', 
> 'pm2_55_24h_avg': '2.5', 'pm4_0': '11.0', 'pm4_0_24h_avg': '3.2', 'pm10_0': 
> '11.2', 'pm10_0_24h_avg': '3.6'
>
> *Database values :*
> PM1.0  = 10.6
> PM2.5  = 11.7
> PM4.0  =  12.06667
> PM10 =  12.26667
>
> *Index.html page :*
> [image: Výstřižek.PNG]
>
>
>
> Dne úterý 30. července 2024 v 13:51:16 UTC+2 uživatel gjr80 napsal:
>
> You can try v0.6.3b1 which includes support for the WH46 air quality 
> sensor. If a WH46 is connected the v0.6.3 driver should emit the same 
> temperature, PM2.5, PM10 and CO2 fields as with a WH45. Additional fields 
> pm1_0, pm1_0_24h_avg, pm4_0, pm4_0_24h_avg should also be emitted with 
> the WH46 PM1 and PM4 data and 24hour averages respectively. v0.6.3 should 
> also automatically determine whether a WH45 or WH46 is present and 
> correctly name WH45/WH46 battery and signal state fields.
>
> Note that I have had to change the names of a the PM10 fields emitted by 
> the driver when used with a WH45 sensor. This will only affect you if you 
> previously used a WH45 sensor. The driver now emits pm10_0 and 
> pm10_0_24h_avg fields (previously the fields were pm10 and pm10_24h_avg). 
> Users who have previously used a WH45 sensor will need to either change 
> their field map if mapping these fields to some other WeeWX field, or if 
> the pm10 and pm10_24h_avg fields are used in the database schema the 
> database fields will need to be renamed to the new field names.
>
> v0.6.3 also includes support for the WS85 sensor array as well as 
> including a revised approach to device discovery that is much more reliable 
> than the previous approach. Note the recommended approach remains to 
> specify the device IP address in the WeeWX config file rather than have the 
> driver rely on discovery
>
> I have not released v0.6.3 yet, rather I have kept it at b1 until someone 
> verifies it's use it with a WH45/46. If you wish to try v0.6.3b1 the 
> following instructions should be used:
>
> 1. Rename your existing gateway driver to gw1000_0_6_1.py so you can 
> easily revert if necessary:
> $ cp /etc/weewx/bin/user/gw1000.py /etc/weewx/bin/user/gw1000_0_6_1.py
>
> 2. Download the v0.6.3b1 driver file and save it to /etc/weewx/bin/user:
> $ wget -P /etc/weewx/bin/user 
> https://raw.githubusercontent.com/gjr80/weewx-gw1000/v0.6.3/bin/user/gw1000.py
>
> 3. You can run the driver directly as you did in you OP, you should see 
> the WH46 obs fields as well as WH46 battery and signal state data. You 
> might also find using the --live-data option useful when running the 
> driver directly.
>
> 4. If you are happy running the driver directly you can restart WeeWX and 
> it will pick up the v0.6.3 driver.
>
> Note the above commands may require prefixing with sudo. If you need to 
> revert to your original driver just delete /etc/weewx/bin/user/gw1000.py and 
> rename /etc/weewx/bin/user/gw1000_0_6_1.py to 
> /etc/weewx/bin/user/gw1000.py. 
>
> If any problems please let me know.
>
> Gary
>
> On Monday 29 July 2024 at 22:55:21 UTC+10 j.fri...@gmail.com wrote:
>
> Hello,
>
> I added new WH46 to my Ecowitt system. I can view data in ecowitt.net and 
> in mobile application too.
>
> My main system is weewx https

[weewx-user] Re: GW1000 driver doesn't show values from WH46

[gjr80]

You can try v0.6.3b1 which includes support for the WH46 air quality 
sensor. If a WH46 is connected the v0.6.3 driver should emit the same 
temperature, PM2.5, PM10 and CO2 fields as with a WH45. Additional fields 
pm1_0, pm1_0_24h_avg, pm4_0, pm4_0_24h_avg should also be emitted with the 
WH46 PM1 and PM4 data and 24hour averages respectively. v0.6.3 should also 
automatically determine whether a WH45 or WH46 is present and correctly 
name WH45/WH46 battery and signal state fields.

Note that I have had to change the names of a the PM10 fields emitted by 
the driver when used with a WH45 sensor. This will only affect you if you 
previously used a WH45 sensor. The driver now emits pm10_0 and 
pm10_0_24h_avg fields (previously the fields were pm10 and pm10_24h_avg). 
Users who have previously used a WH45 sensor will need to either change 
their field map if mapping these fields to some other WeeWX field, or if 
the pm10 and pm10_24h_avg fields are used in the database schema the 
database fields will need to be renamed to the new field names.

v0.6.3 also includes support for the WS85 sensor array as well as including 
a revised approach to device discovery that is much more reliable than the 
previous approach. Note the recommended approach remains to specify the 
device IP address in the WeeWX config file rather than have the driver rely 
on discovery

I have not released v0.6.3 yet, rather I have kept it at b1 until someone 
verifies it's use it with a WH45/46. If you wish to try v0.6.3b1 the 
following instructions should be used:

1. Rename your existing gateway driver to gw1000_0_6_1.py so you can easily 
revert if necessary:
$ cp /etc/weewx/bin/user/gw1000.py /etc/weewx/bin/user/gw1000_0_6_1.py

2. Download the v0.6.3b1 driver file and save it to /etc/weewx/bin/user:
$ wget -P 
/etc/weewx/bin/user 
https://raw.githubusercontent.com/gjr80/weewx-gw1000/v0.6.3/bin/user/gw1000.py

3. You can run the driver directly as you did in you OP, you should see the 
WH46 obs fields as well as WH46 battery and signal state data. You might 
also find using the --live-data option useful when running the driver 
directly.

4. If you are happy running the driver directly you can restart WeeWX and 
it will pick up the v0.6.3 driver.

Note the above commands may require prefixing with sudo. If you need to 
revert to your original driver just delete /etc/weewx/bin/user/gw1000.py and 
rename /etc/weewx/bin/user/gw1000_0_6_1.py to /etc/weewx/bin/user/gw1000.py
. 

If any problems please let me know.

Gary

On Monday 29 July 2024 at 22:55:21 UTC+10 j.fri...@gmail.com wrote:

> Hello,
>
> I added new WH46 to my Ecowitt system. I can view data in ecowitt.net and 
> in mobile application too.
>
> My main system is weewx https://pocasi.frimlovi.com but the new WH46 data 
> didn't appear automatically in dashboard.
>
> If I run PYTHONPATH=/usr/share/weewx:/etc/weewx/bin python3 
> /etc/weewx/bin/user/gw1000.py --test-service --ip-address=my_IP it shows 
> data from all measures correctly but from WH46 it shows only data about 
> battery and signal -  'wh45_batt': '5', 'wh45_sig': '4'
>
> I use the latest version of GW1000 driver - 0.6.1
>
> I tryed to add data in weewx.conf - [[field_map_extensions]] and in 
> skin.conf in appearance but nothing changed.
>
> Can you help me please ?
>
> Thank you in advance.
>
> Jarda
>

-- 
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/a6b01283-b785-43c5-bd7c-e5688ec250e1n%40googlegroups.com.

[weewx-user] Re: wee_database --calc-missing / weectl database calc-missing seem to not call shutDown() at the end

[gjr80]

Yes, class CalcMissing should call DummyEngine.shutDown() on closing so 
that any invoked services have the chance to properly shut down. Fixed at 
commit bf80fb8 

 
to appear in the next release.

The OP of the referenced thread can apply the fix to an his existing v5 
install by downloading the fixed database.py using 
https://raw.githubusercontent.com/weewx/weewx/development/src/weecfg/database.py
 
and replacing /usr/share/weewx/weecfg/database.py with the downloaded 
database.py (alternatively he can run WeeWX with calc_missing = False in 
his import config file to see if this is the source of his problem - as 
long as he changes back to calc_missing = True before the end of the day 
there will be no effect on his imported data)

Gary

On Sunday 28 July 2024 at 01:00:03 UTC+10 kk44...@gmail.com wrote:

> This refers to https://groups.google.com/g/weewx-user/c/ZLn1scFWuMk
>
> If you call wee_database --calc-missing or weectl database calc-missing 
> all the services defined in weewx.conf are loaded. If some of those 
> services create threads, the command does not finish. Instead it waits 
> indefinitely for the threads finishing.
>
> It seems to me, that wee-database --calc-missing and weectl database 
> calc-missing do not call the shutDown() method of the services after 
> finishing the calculation. So the services do not know it's time to shut 
> down the threads they created. 
>
> Could that be?
>
>
> Excerpt from the log:
>
> Jul 27 16:16:09 LokalWiki wee_database[*1320746*] INFO __main__: 
> Preparing to calculate missing derived observations...
>
> Jul 27 16:16:09 LokalWiki wee_database[*1320746*] INFO __main__: Missing 
> derived observations will be calculated from 2021-02-02 00:00:01 CET 
> (1612220401) through to 2021-02-03 00:00:00 CET (1612306800) inclusive.
>
> Jul 27 16:16:34 LokalWiki wee_database[*1320746*] DEBUG weewx.manager: 
> Daily summary version is 4.0
>
> Jul 27 16:16:34 LokalWiki wee_database[*1320746*] INFO __main__: 
> Calculating missing derived observations...
>
> Jul 27 16:16:34 LokalWiki wee_database[*1320746*] DEBUG weewx.engine: 
> Loading service weewx.engine.StdTimeSynch
>
> Jul 27 16:16:34 LokalWiki wee_database[*1320746*] DEBUG weewx.engine: 
> Finished loading service weewx.engine.StdTimeSynch
>
> Jul 27 16:16:34 LokalWiki wee_database[*1320746*] DEBUG weewx.engine: 
> Loading service ...
>
> Jul 27 16:16:39 LokalWiki wee_database[*1320746*] INFO weewx.wxservices: 
> StdWXCalculate will use data binding wx_binding
>
> Jul 27 16:16:39 LokalWiki wee_database[*1320746*] DEBUG weewx.manager: 
> Daily summary version is 4.0
>
> Jul 27 16:16:39 LokalWiki wee_database[*1320746*] message repeated 3 
> times: [ DEBUG weewx.manager: Daily summary version is 4.0]
>
> Jul 27 16:16:39 LokalWiki wee_database[*1320746*] INFO weewx.wxxtypes: 
> Type beaufort has been deprecated. Use unit beaufort instead.
>
> Jul 27 16:16:39 LokalWiki wee_database[*1320746*] INFO weewx.manager: 
> Starting backfill of daily summaries
>
> Jul 27 16:16:40 LokalWiki wee_database[*1320746*] INFO weewx.manager: 
> Processed 288 records to backfill 1 day summaries in 0.71 seconds
>
> Jul 27 16:16:40 LokalWiki wee_database[*1320746*] INFO weecfg.database: 
> Processed 1 day consisting of 288 records. 1 day consisting of 288 records 
> were updated in 6.63 seconds.
>
> Jul 27 16:16:40 LokalWiki wee_database[*1320746*] INFO __main__: Missing 
> derived observations calculated in 6.64 seconds
>
> ...
>
> Jul 27 16:18:53 LokalWiki wee_database[*1320746*] DEBUG 
> urllib3.connectionpool: Starting new HTTPS connection (1): 
> opendata.dwd.de:443
>
> Jul 27 16:18:54 LokalWiki wee_database[*1320746*] DEBUG 
> urllib3.connectionpool: https://opendata.dwd.de:443 "GET 
> /weather/radar/composite/wn/WN_LATEST.tar.bz2 HTTP/1.1" 200 5501583
>
> Jul 27 16:18:55 LokalWiki wee_database[*1320746*] INFO user.DWD.base: 
> successfully downloaded 
> https://opendata.dwd.de/weather/radar/composite/wn/WN_LATEST.tar.bz2 in 
> 1.66 seconds
>
> Jul 27 16:18:59 LokalWiki wee_database[*1320746*] DEBUG 
> urllib3.connectionpool: Starting new HTTPS connection (1): 
> opendata.dwd.de:443
>
> Jul 27 16:18:59 LokalWiki wee_database[*1320746*] DEBUG 
> urllib3.connectionpool: https://opendata.dwd.de:443 "GET 
> /weather/text_forecasts/html/VHDL50_DWLG_LATEST_html HTTP/1.1" 200 609
>
> Jul 27 16:18:59 LokalWiki wee_database[*1320746*] INFO user.DWD.base: 
> successfully downloaded 
> https://opendata.dwd.de/weather/text_forecasts/html/VHDL50_DWLG_LATEST_html 
> in 0.11 seconds
>
> Jul 27 16:18:59 LokalWiki wee_database[*1320746*] DEBUG 
> urllib3.connectionpool: https://opendata.dwd.de:443 "GET 
> /weather/text_forecasts/html/VHDL51_DWLG_LATEST_html HTTP/1.1" 200 478
>
> Jul 27 16:18:59 LokalWiki wee_database[*1320746*] INFO user.DWD.base: 
> successfully downloaded 
> https://opendata.dwd.de/weather/text_forecasts/html/VHDL51_DWLG_LATEST_html 
> in 0.03 se

[weewx-user] Re: Importing data for custom observations

[gjr80]

Zach,

Did you by chance copy and paste those two lines from my earlier post into 
extensions.py? If so if you look closely I had a typo, lakeSurfaceLevel was 
incorrectly capitalised. I've just run weectl import with your data and 
import config file with the correct two lines in extensions.py and the 
import worked just fine.

Gary

On Wednesday 24 July 2024 at 08:53:39 UTC+10 Zach wrote:

> Unfortunately, adding it to extensions.py did not work. I'll sit tight 
> until a fix is completed. But no hurry!
>
> Thanks Gary!
>
> On Tuesday, July 23, 2024 at 5:48:01 PM UTC-5 gjr80 wrote:
>
>> The problem is weectl import is a standalone utility run independent of 
>> WeeWX and as such does not load the WeeWX services specified in the WeeWX 
>> config file (well it actually does cause some of the services to be loaded, 
>> but later on after the import has occurred when missing obs are/may be 
>> calculated). I've had some second thoughts since my previous post and I am 
>> not even sure that adding those lines to extensions.py will work. If it 
>> is easy enough to try please try it, it will either work or not, nothing 
>> will be broken/corrupted.
>>
>> Failing that there will be a small change required to weectl import that 
>> I should be able to implement later today.
>>
>> Let me know how you get on.
>>
>> Gary
>> On Wednesday 24 July 2024 at 07:33:27 UTC+10 Zach wrote:
>>
>>> I have that line in my custom service for pulling the data from an API. 
>>> Should I also put it in the extension.py?
>>>
>>> On Tuesday, July 23, 2024 at 4:17:36 PM UTC-5 gjr80 wrote:
>>>
>>>> OK, I suspect the problem is when you added field lakeSurfaceLevel to 
>>>> WeeWX you didn't tell WeeWX what unit group the field belongs to. 
>>>> Consequently, when you attempt to import data into lakeSurfaceLevel weectl 
>>>> import conducts some checks to see if any source field unit conversion 
>>>> is required. That is what is causing the KeyError error.
>>>>
>>>> The simple fix is to tell WeeWX what unit group is used by the WeeWX 
>>>> field lakeSurfaceLevel. There are a number of ways to do this, the 
>>>> most common is to add a few lines to 
>>>> ~/weewx-data/bin/user/extensions.py. You could try adding the 
>>>> following to ~/weewx-data/bin/user/extensions.py:
>>>>
>>>> import weewx.units
>>>> weewx.units.obs_group_dict['lakeSurfacelevel'] = 'group_altitude'
>>>>
>>>> save extensions.py and try the import agin.
>>>>
>>>> Gary
>>>>
>>>> On Wednesday 24 July 2024 at 06:50:28 UTC+10 Zach wrote:
>>>>
>>>>> Sorry, I should have clicked reply all. ;)
>>>>>
>>>>> Here is the output
>>>>>
>>>>> Using configuration file */Users/zach/weewx-data/weewx.conf*
>>>>>
>>>>> This is a dry run. Nothing will actually be done.
>>>>>
>>>>> Starting weectl import...
>>>>>
>>>>> A CSV import from source file '/Users/zach/Downloads/Untitled.csv' has 
>>>>> been requested.
>>>>>
>>>>> The following options will be used:
>>>>>
>>>>>  config=/Users/zach/weewx-data/weewx.conf, 
>>>>> import-config=/Users/zach/weewx-data/csv.conf
>>>>>
>>>>>  source=/Users/zach/Downloads/Untitled.csv, from=None, to=None
>>>>>
>>>>>  dry-run=True, calc_missing=False, ignore_invalid_data=True
>>>>>
>>>>>  tranche=250, interval=derive, date/time_string_format=%Y-%m-%d 
>>>>> %H:%M:%S
>>>>>
>>>>>  delimiter=',', wind_direction=[-360.0, 360.0]
>>>>>
>>>>>  UV=False, radiation=False
>>>>>
>>>>> Using database binding 'wx_binding', which is bound to database 
>>>>> 'weewx.sdb'
>>>>>
>>>>> Destination table 'archive' unit system is '0x01' (US).
>>>>>
>>>>> The following imported field-to-WeeWX field map will be used:
>>>>>
>>>>>  source field 'datetime' in units 'unix_epoch' --> WeeWX field 
>>>>> 'dateTime'
>>>>>
>>>>>  source field 'lakeSurfaceLevel' in units 'foot' --> WeeWX field 
>>&

[weewx-user] Re: Importing data for custom observations

[gjr80]

OK. Thanks.

Gary

On Wednesday 24 July 2024 at 08:53:39 UTC+10 Zach wrote:

> Unfortunately, adding it to extensions.py did not work. I'll sit tight 
> until a fix is completed. But no hurry!
>
> Thanks Gary!
>
> On Tuesday, July 23, 2024 at 5:48:01 PM UTC-5 gjr80 wrote:
>
>> The problem is weectl import is a standalone utility run independent of 
>> WeeWX and as such does not load the WeeWX services specified in the WeeWX 
>> config file (well it actually does cause some of the services to be loaded, 
>> but later on after the import has occurred when missing obs are/may be 
>> calculated). I've had some second thoughts since my previous post and I am 
>> not even sure that adding those lines to extensions.py will work. If it 
>> is easy enough to try please try it, it will either work or not, nothing 
>> will be broken/corrupted.
>>
>> Failing that there will be a small change required to weectl import that 
>> I should be able to implement later today.
>>
>> Let me know how you get on.
>>
>> Gary
>> On Wednesday 24 July 2024 at 07:33:27 UTC+10 Zach wrote:
>>
>>> I have that line in my custom service for pulling the data from an API. 
>>> Should I also put it in the extension.py?
>>>
>>> On Tuesday, July 23, 2024 at 4:17:36 PM UTC-5 gjr80 wrote:
>>>
>>>> OK, I suspect the problem is when you added field lakeSurfaceLevel to 
>>>> WeeWX you didn't tell WeeWX what unit group the field belongs to. 
>>>> Consequently, when you attempt to import data into lakeSurfaceLevel weectl 
>>>> import conducts some checks to see if any source field unit conversion 
>>>> is required. That is what is causing the KeyError error.
>>>>
>>>> The simple fix is to tell WeeWX what unit group is used by the WeeWX 
>>>> field lakeSurfaceLevel. There are a number of ways to do this, the 
>>>> most common is to add a few lines to 
>>>> ~/weewx-data/bin/user/extensions.py. You could try adding the 
>>>> following to ~/weewx-data/bin/user/extensions.py:
>>>>
>>>> import weewx.units
>>>> weewx.units.obs_group_dict['lakeSurfacelevel'] = 'group_altitude'
>>>>
>>>> save extensions.py and try the import agin.
>>>>
>>>> Gary
>>>>
>>>> On Wednesday 24 July 2024 at 06:50:28 UTC+10 Zach wrote:
>>>>
>>>>> Sorry, I should have clicked reply all. ;)
>>>>>
>>>>> Here is the output
>>>>>
>>>>> Using configuration file */Users/zach/weewx-data/weewx.conf*
>>>>>
>>>>> This is a dry run. Nothing will actually be done.
>>>>>
>>>>> Starting weectl import...
>>>>>
>>>>> A CSV import from source file '/Users/zach/Downloads/Untitled.csv' has 
>>>>> been requested.
>>>>>
>>>>> The following options will be used:
>>>>>
>>>>>  config=/Users/zach/weewx-data/weewx.conf, 
>>>>> import-config=/Users/zach/weewx-data/csv.conf
>>>>>
>>>>>  source=/Users/zach/Downloads/Untitled.csv, from=None, to=None
>>>>>
>>>>>  dry-run=True, calc_missing=False, ignore_invalid_data=True
>>>>>
>>>>>  tranche=250, interval=derive, date/time_string_format=%Y-%m-%d 
>>>>> %H:%M:%S
>>>>>
>>>>>  delimiter=',', wind_direction=[-360.0, 360.0]
>>>>>
>>>>>  UV=False, radiation=False
>>>>>
>>>>> Using database binding 'wx_binding', which is bound to database 
>>>>> 'weewx.sdb'
>>>>>
>>>>> Destination table 'archive' unit system is '0x01' (US).
>>>>>
>>>>> The following imported field-to-WeeWX field map will be used:
>>>>>
>>>>>  source field 'datetime' in units 'unix_epoch' --> WeeWX field 
>>>>> 'dateTime'
>>>>>
>>>>>  source field 'lakeSurfaceLevel' in units 'foot' --> WeeWX field 
>>>>> 'lakeSurfaceLevel'
>>>>>
>>>>> Imported records will not overwrite existing database records.
>>>>>
>>>>> All WeeWX UV fields will be set to None.
>>>>>
>>>>> All WeeWX radiation fields will be set to None.
>

[weewx-user] Re: RAM is running full. Apparently it's due to the weectl import

[gjr80]

True, but I suspect Belchertown is not playing a significant role here, the 
log extract shows Belchertown completes in less than 10 seconds. My 
understanding tis that the v5 Belchertown issue is characterised by 
excessively long Belchertown report generation times.

Gary

On Wednesday 24 July 2024 at 07:01:47 UTC+10 vince wrote:

> One thing to check is that while weewx.conf might say it's using the 
> wview_extended schema, that is only positively true if the db was created 
> at weewx v4 or later.  Suggest the original poster check their actual db 
> files to see what the database is actually using.   You should probably 
> check all the databases you have.
>
> On Tuesday, July 23, 2024 at 1:38:08 PM UTC-7 gjr80 wrote:
>
>> It's possible the so called 'Belchertown v5 issue' is involved but a few 
>> things suggest it is not, or if it is it's effect is insignificant:
>>
>> - weewx.conf indicates the user is using the wview_extended schema
>> - the Belchertown issue raises it's head when a report is run and missing 
>> derived obs are calculated on the fly, in this case weectl import is 
>> calculating those missing derived obs before reports are run
>> - the Belchertown report generation is completed within 10 seconds
>> - the 'Ctl-C response' shows weectl import was caught executing code 
>> that was not Belchertown code (Belchertown does not use locks or threading)
>>
>> Gary
>> On Tuesday 23 July 2024 at 22:15:06 UTC+10 kk44...@gmail.com wrote:
>>
>>> Sebastian E schrieb am Dienstag, 23. Juli 2024 um 13:41:03 UTC+2:
>>>
>>> Here is a longer excerpt from journalctl
>>>
>>>
>>> What I get from that log is, that weectl starts report generation after 
>>> importing data. And I see, the Belchertown skin is involved. So there is a 
>>> possibility that this problem is involved: v5 performance 
>>> troubleshooting 
>>> <https://github.com/weewx/weewx/wiki/v5-performance-troubleshooting>.
>>>  
>>>
>>

-- 
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/d191882f-d12b-4c48-a742-e692abd2e8b9n%40googlegroups.com.

[weewx-user] Re: Importing data for custom observations

[gjr80]

The problem is weectl import is a standalone utility run independent of 
WeeWX and as such does not load the WeeWX services specified in the WeeWX 
config file (well it actually does cause some of the services to be loaded, 
but later on after the import has occurred when missing obs are/may be 
calculated). I've had some second thoughts since my previous post and I am 
not even sure that adding those lines to extensions.py will work. If it is 
easy enough to try please try it, it will either work or not, nothing will 
be broken/corrupted.

Failing that there will be a small change required to weectl import that I 
should be able to implement later today.

Let me know how you get on.

Gary
On Wednesday 24 July 2024 at 07:33:27 UTC+10 Zach wrote:

> I have that line in my custom service for pulling the data from an API. 
> Should I also put it in the extension.py?
>
> On Tuesday, July 23, 2024 at 4:17:36 PM UTC-5 gjr80 wrote:
>
>> OK, I suspect the problem is when you added field lakeSurfaceLevel to 
>> WeeWX you didn't tell WeeWX what unit group the field belongs to. 
>> Consequently, when you attempt to import data into lakeSurfaceLevel weectl 
>> import conducts some checks to see if any source field unit conversion 
>> is required. That is what is causing the KeyError error.
>>
>> The simple fix is to tell WeeWX what unit group is used by the WeeWX 
>> field lakeSurfaceLevel. There are a number of ways to do this, the most 
>> common is to add a few lines to ~/weewx-data/bin/user/extensions.py. You 
>> could try adding the following to ~/weewx-data/bin/user/extensions.py:
>>
>> import weewx.units
>> weewx.units.obs_group_dict['lakeSurfacelevel'] = 'group_altitude'
>>
>> save extensions.py and try the import agin.
>>
>> Gary
>>
>> On Wednesday 24 July 2024 at 06:50:28 UTC+10 Zach wrote:
>>
>>> Sorry, I should have clicked reply all. ;)
>>>
>>> Here is the output
>>>
>>> Using configuration file */Users/zach/weewx-data/weewx.conf*
>>>
>>> This is a dry run. Nothing will actually be done.
>>>
>>> Starting weectl import...
>>>
>>> A CSV import from source file '/Users/zach/Downloads/Untitled.csv' has 
>>> been requested.
>>>
>>> The following options will be used:
>>>
>>>  config=/Users/zach/weewx-data/weewx.conf, 
>>> import-config=/Users/zach/weewx-data/csv.conf
>>>
>>>  source=/Users/zach/Downloads/Untitled.csv, from=None, to=None
>>>
>>>  dry-run=True, calc_missing=False, ignore_invalid_data=True
>>>
>>>  tranche=250, interval=derive, date/time_string_format=%Y-%m-%d 
>>> %H:%M:%S
>>>
>>>  delimiter=',', wind_direction=[-360.0, 360.0]
>>>
>>>  UV=False, radiation=False
>>>
>>> Using database binding 'wx_binding', which is bound to database 
>>> 'weewx.sdb'
>>>
>>> Destination table 'archive' unit system is '0x01' (US).
>>>
>>> The following imported field-to-WeeWX field map will be used:
>>>
>>>  source field 'datetime' in units 'unix_epoch' --> WeeWX field 
>>> 'dateTime'
>>>
>>>  source field 'lakeSurfaceLevel' in units 'foot' --> WeeWX field 
>>> 'lakeSurfaceLevel'
>>>
>>> Imported records will not overwrite existing database records.
>>>
>>> All WeeWX UV fields will be set to None.
>>>
>>> All WeeWX radiation fields will be set to None.
>>>
>>> This is a dry run, imported data will not be saved to archive.
>>>
>>> Starting dry run import ...
>>>
>>> Obtaining raw import data for period 1 ...
>>>
>>> Raw import data read successfully for period 1.
>>>
>>> Mapping raw import data for period 1 ...
>>>
>>> Traceback (most recent call last):
>>>
>>>   File "/Users/zach/weewx-venv/bin/weectl", line 8, in 
>>>
>>> sys.exit(main())
>>>
>>>   File "/Users/zach/weewx-venv/lib/python3.9/site-packages/weectl.py", 
>>> line 67, in main
>>>
>>> namespace.func(namespace)
>>>
>>>   File 
>>> "/Users/zach/weewx-venv/lib/python3.9/site-packages/weectllib/__init__.py", 
>>> line 90, in dispatch
>>>
>>> namespace.action_func(config_dict, namespace)
>>>
>>>   File 
>>> "/Users

[weewx-user] Re: Importing data for custom observations

[gjr80]

OK, I suspect the problem is when you added field lakeSurfaceLevel to WeeWX 
you didn't tell WeeWX what unit group the field belongs to. Consequently, 
when you attempt to import data into lakeSurfaceLevel weectl import 
conducts some checks to see if any source field unit conversion is 
required. That is what is causing the KeyError error.

The simple fix is to tell WeeWX what unit group is used by the WeeWX field 
lakeSurfaceLevel. There are a number of ways to do this, the most common is 
to add a few lines to ~/weewx-data/bin/user/extensions.py. You could try 
adding the following to ~/weewx-data/bin/user/extensions.py:

import weewx.units
weewx.units.obs_group_dict['lakeSurfacelevel'] = 'group_altitude'

save extensions.py and try the import agin.

Gary

On Wednesday 24 July 2024 at 06:50:28 UTC+10 Zach wrote:

> Sorry, I should have clicked reply all. ;)
>
> Here is the output
>
> Using configuration file */Users/zach/weewx-data/weewx.conf*
>
> This is a dry run. Nothing will actually be done.
>
> Starting weectl import...
>
> A CSV import from source file '/Users/zach/Downloads/Untitled.csv' has 
> been requested.
>
> The following options will be used:
>
>  config=/Users/zach/weewx-data/weewx.conf, 
> import-config=/Users/zach/weewx-data/csv.conf
>
>  source=/Users/zach/Downloads/Untitled.csv, from=None, to=None
>
>  dry-run=True, calc_missing=False, ignore_invalid_data=True
>
>  tranche=250, interval=derive, date/time_string_format=%Y-%m-%d 
> %H:%M:%S
>
>  delimiter=',', wind_direction=[-360.0, 360.0]
>
>  UV=False, radiation=False
>
> Using database binding 'wx_binding', which is bound to database 'weewx.sdb'
>
> Destination table 'archive' unit system is '0x01' (US).
>
> The following imported field-to-WeeWX field map will be used:
>
>  source field 'datetime' in units 'unix_epoch' --> WeeWX field 
> 'dateTime'
>
>  source field 'lakeSurfaceLevel' in units 'foot' --> WeeWX field 
> 'lakeSurfaceLevel'
>
> Imported records will not overwrite existing database records.
>
> All WeeWX UV fields will be set to None.
>
> All WeeWX radiation fields will be set to None.
>
> This is a dry run, imported data will not be saved to archive.
>
> Starting dry run import ...
>
> Obtaining raw import data for period 1 ...
>
> Raw import data read successfully for period 1.
>
> Mapping raw import data for period 1 ...
>
> Traceback (most recent call last):
>
>   File "/Users/zach/weewx-venv/bin/weectl", line 8, in 
>
> sys.exit(main())
>
>   File "/Users/zach/weewx-venv/lib/python3.9/site-packages/weectl.py", 
> line 67, in main
>
> namespace.func(namespace)
>
>   File 
> "/Users/zach/weewx-venv/lib/python3.9/site-packages/weectllib/__init__.py", 
> line 90, in dispatch
>
> namespace.action_func(config_dict, namespace)
>
>   File 
> "/Users/zach/weewx-venv/lib/python3.9/site-packages/weectllib/import_cmd.py", 
> line 85, in import_func
>
> weectllib.import_actions.obs_import(config_dict,
>
>   File 
> "/Users/zach/weewx-venv/lib/python3.9/site-packages/weectllib/import_actions.py",
>  
> line 58, in obs_import
>
> source_obj.run()
>
>   File 
> "/Users/zach/weewx-venv/lib/python3.9/site-packages/weeimport/weeimport.py", 
> line 406, in run
>
> _mapped_data = self.map_raw_data(_raw_data, self.archive_unit_sys)
>
>   File 
> "/Users/zach/weewx-venv/lib/python3.9/site-packages/weeimport/weeimport.py", 
> line 976, in map_raw_data
>
> weewx.units.obs_group_dict[_field])
>
>   File 
> "/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.9/lib/python3.9/collections/__init__.py",
>  
> line 941, in __getitem__
>
> return self.__missing__(key)# support subclasses that 
> define __missing__
>
>   File 
> "/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.9/lib/python3.9/collections/__init__.py",
>  
> line 933, in __missing__
>
> raise KeyError(key)
>
> KeyError: 'lakeSurfaceLevel'
>
>
> On Tuesday, July 23, 2024 at 3:45:46 PM UTC-5 gjr80 wrote:
>
>> Thanks, can you post the complete and exact output to the console when 
>> weectl 
>> import is run. Also, what does the weectl log show?
>>
>> Gary
>> On Wednesday 24 July 2024 at 06:40:53 UTC+10 Zach wrote:
>>
>>> I'm trying to track the water level of a lake so 

[weewx-user] Re: Importing data for custom observations

[gjr80]

Thanks, can you post the complete and exact output to the console when weectl 
import is run. Also, what does the weectl log show?

Gary
On Wednesday 24 July 2024 at 06:40:53 UTC+10 Zach wrote:

> I'm trying to track the water level of a lake so I added a new column to 
> the database (lakeSurfaceLevel), created a service to populate the data, 
> and modified my skin to display it. All of that works great, however when I 
> try to import data for that new observation using weectl, I get a error 
> "KeyError: 'lakeSurfaceLevel'
>
> Any help would be greatly appreciated!
>
> Attached are the csv.conf and a data file
>

-- 
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/5945d3d7-c2c5-420b-85cf-a7e1507aa37fn%40googlegroups.com.

[weewx-user] Re: RAM is running full. Apparently it's due to the weectl import

[gjr80]

It's possible the so called 'Belchertown v5 issue' is involved but a few 
things suggest it is not, or if it is it's effect is insignificant:

- weewx.conf indicates the user is using the wview_extended schema
- the Belchertown issue raises it's head when a report is run and missing 
derived obs are calculated on the fly, in this case weectl import is 
calculating those missing derived obs before reports are run
- the Belchertown report generation is completed within 10 seconds
- the 'Ctl-C response' shows weectl import was caught executing code that 
was not Belchertown code (Belchertown does not use locks or threading)

Gary
On Tuesday 23 July 2024 at 22:15:06 UTC+10 kk44...@gmail.com wrote:

> Sebastian E schrieb am Dienstag, 23. Juli 2024 um 13:41:03 UTC+2:
>
> Here is a longer excerpt from journalctl
>
>
> What I get from that log is, that weectl starts report generation after 
> importing data. And I see, the Belchertown skin is involved. So there is a 
> possibility that this problem is involved: v5 performance troubleshooting 
> .
>  
>

-- 
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/7d1a603f-b7ed-48a3-aca0-0c6836ae270en%40googlegroups.com.

[weewx-user] Re: RAM is running full. Apparently it's due to the weectl import

[gjr80]

Was there anything after the last two lines? The 'calculate missing' part 
of the log is where there may be a clue. The 'UNIQUE constraint failed' 
error messages are expected and can be ignored; once WeeWX has written a 
given record to archive any attempt to write the same record again will 
result in such an error.

Gary
On Tuesday 23 July 2024 at 19:16:04 UTC+10 sebastian...@googlemail.com 
wrote:

> Hey, attached is an excerpt from journalctl. 
>
> Greetings Sebastian
>
> gjr80 schrieb am Dienstag, 23. Juli 2024 um 10:41:51 UTC+2:
>
>> OK. At the moment my best guess is that when weectl import calculates 
>> missing derived obs one of the GTS derived obs is not being calculated 
>> cleanly/causing a process to remain in memory. Over time the overall memory 
>> use increases until the system hangs/crashes due to lack of free memory. A 
>> restart relieves the symptoms by clearing the old weectl import 
>> processes and the cycle repeats. weectl import is completing execution 
>> (the printing of the two lines starting 'Those records with a timestamp 
>> already in the archive will not have been' are the last thing weectl 
>> import does), but I suspect the thread launched by the GTS type is 
>> continues once weectl import has otherwise finished.
>>
>> You still haven't provided any log extracts, my suggestion is to edit 
>> weewx.conf, set debug = 1 then save weewx.conf. The next time your cron 
>> job runs weectl import it should use debug = 1 and there may be some 
>> clue in the log as to what is happening. If your system is using 
>> systemd-journald for logging you may need to poke around using journalctl 
>> to find the weectl import log output, this section 
>> <https://github.com/weewx/weewx/wiki/view-logs#journalctl> of the view 
>> logs wiki page <https://github.com/weewx/weewx/wiki/view-logs> may help. 
>> You might want to start with sudo journalctl -t weectl.
>>
>> Gary
>>
>> On Tuesday 23 July 2024 at 17:02:33 UTC+10 sebastian...@googlemail.com 
>> wrote:
>>
>>> Hello, first of all thank you very much for your help. 
>>>
>>> Here is the content of htop. There I see that the import has started 
>>> several times. According to crontab it starts every 15 minutes. Because it 
>>> doesn't seem to finish, there are so many views. Just my guess.
>>>
>>> gjr80 schrieb am Dienstag, 23. Juli 2024 um 07:47:50 UTC+2:
>>>
>>>> So if ctl-C is being used to interrupt a script, the script must be 
>>>> being run from the command line; ctl-C will have no effect on scripts 
>>>> executed by cron. weectl import does not directly use threading, 
>>>> however, weectl import uses a number of WeeWX 'API' calls to do things 
>>>> (save data to database and calculate missing/derived obs are the two main 
>>>> ones). I would suggest this use of threading is possibly due to an xtype 
>>>> call when calculating missing/derived obs. weectl import does not 
>>>> 'load' any extensions per se; however, that is not to say that some other 
>>>> parts of WeeWX called by weectl import do not. Again an xtype being 
>>>> used to calculate missing/derived obs is an obvious candidate. I don't see 
>>>> the 'area 30 31' output being direct weectl import output, quite 
>>>> possibly it is output from some other extension.
>>>>
>>>> To start tracking this down we need to go back to basics with log and 
>>>> config. What does the WeeWX log shown when weectl import is run? And what 
>>>> is in weewx.conf (and to a lesser extent) the import config file 
>>>> /etc/weewx/import/wu-example.conf.
>>>>
>>>> Gary
>>>>
>>>> On Tuesday 23 July 2024 at 15:08:09 UTC+10 kk44...@gmail.com wrote:
>>>>
>>>>> Gary,
>>>>>
>>>>> may be, it is a little bit of a language problem. I heard of this case 
>>>>> before, so I may add some explanation, but I cannot explain all.
>>>>>
>>>>> The user seems to call weectl import from the command line or from 
>>>>> crontab to retrieve data from Wunderground. The command first runs as 
>>>>> expected. Data is imported and saved to the database. But then, the 
>>>>> command 
>>>>> does not end. It hangs. So I suggested to the user to press CTRL-C 
>>>>> several 
>>>>> times. This resulted in an error message saying that the command hang in 
>>&

[weewx-user] Re: RAM is running full. Apparently it's due to the weectl import

[gjr80]

OK. At the moment my best guess is that when weectl import calculates 
missing derived obs one of the GTS derived obs is not being calculated 
cleanly/causing a process to remain in memory. Over time the overall memory 
use increases until the system hangs/crashes due to lack of free memory. A 
restart relieves the symptoms by clearing the old weectl import processes 
and the cycle repeats. weectl import is completing execution (the printing 
of the two lines starting 'Those records with a timestamp already in the 
archive will not have been' are the last thing weectl import does), but I 
suspect the thread launched by the GTS type is continues once weectl import 
has otherwise finished.

You still haven't provided any log extracts, my suggestion is to edit 
weewx.conf, set debug = 1 then save weewx.conf. The next time your cron job 
runs weectl import it should use debug = 1 and there may be some clue in 
the log as to what is happening. If your system is using systemd-journald 
for logging you may need to poke around using journalctl to find the weectl 
import log output, this section 
<https://github.com/weewx/weewx/wiki/view-logs#journalctl> of the view logs 
wiki page <https://github.com/weewx/weewx/wiki/view-logs> may help. You 
might want to start with sudo journalctl -t weectl.

Gary

On Tuesday 23 July 2024 at 17:02:33 UTC+10 sebastian...@googlemail.com 
wrote:

> Hello, first of all thank you very much for your help. 
>
> Here is the content of htop. There I see that the import has started 
> several times. According to crontab it starts every 15 minutes. Because it 
> doesn't seem to finish, there are so many views. Just my guess.
>
> gjr80 schrieb am Dienstag, 23. Juli 2024 um 07:47:50 UTC+2:
>
>> So if ctl-C is being used to interrupt a script, the script must be being 
>> run from the command line; ctl-C will have no effect on scripts executed by 
>> cron. weectl import does not directly use threading, however, weectl 
>> import uses a number of WeeWX 'API' calls to do things (save data to 
>> database and calculate missing/derived obs are the two main ones). I would 
>> suggest this use of threading is possibly due to an xtype call when 
>> calculating missing/derived obs. weectl import does not 'load' any 
>> extensions per se; however, that is not to say that some other parts of 
>> WeeWX called by weectl import do not. Again an xtype being used to 
>> calculate missing/derived obs is an obvious candidate. I don't see the 
>> 'area 30 31' output being direct weectl import output, quite possibly it 
>> is output from some other extension.
>>
>> To start tracking this down we need to go back to basics with log and 
>> config. What does the WeeWX log shown when weectl import is run? And what 
>> is in weewx.conf (and to a lesser extent) the import config file 
>> /etc/weewx/import/wu-example.conf.
>>
>> Gary
>>
>> On Tuesday 23 July 2024 at 15:08:09 UTC+10 kk44...@gmail.com wrote:
>>
>>> Gary,
>>>
>>> may be, it is a little bit of a language problem. I heard of this case 
>>> before, so I may add some explanation, but I cannot explain all.
>>>
>>> The user seems to call weectl import from the command line or from 
>>> crontab to retrieve data from Wunderground. The command first runs as 
>>> expected. Data is imported and saved to the database. But then, the command 
>>> does not end. It hangs. So I suggested to the user to press CTRL-C several 
>>> times. This resulted in an error message saying that the command hang in 
>>> the threading module while waiting for a lock.
>>>
>>> First question: Where does weectl import use threading? Or does this 
>>> point to the problem that threading is involved at all?
>>>
>>> I had a short glance at the sources, but I did not see it.
>>>
>>> Then, there are some hints that third party extensions are involved in 
>>> the problem. Does weectl import load WeeWX extensions? I do not see a 
>>> reason to do so. But the output "area 30 31" at the end of the first 
>>> post is from an extension, not from the command itself.
>>>
>>> Karen
>>>
>>>

-- 
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/6dbac4fa-e0a4-441d-97f8-43aa625a4904n%40googlegroups.com.

[weewx-user] Re: RAM is running full. Apparently it's due to the weectl import

[gjr80]

So if ctl-C is being used to interrupt a script, the script must be being 
run from the command line; ctl-C will have no effect on scripts executed by 
cron. weectl import does not directly use threading, however, weectl import 
uses a number of WeeWX 'API' calls to do things (save data to database and 
calculate missing/derived obs are the two main ones). I would suggest this 
use of threading is possibly due to an xtype call when calculating 
missing/derived obs. weectl import does not 'load' any extensions per se; 
however, that is not to say that some other parts of WeeWX called by weectl 
import do not. Again an xtype being used to calculate missing/derived obs 
is an obvious candidate. I don't see the 'area 30 31' output being direct 
weectl 
import output, quite possibly it is output from some other extension.

To start tracking this down we need to go back to basics with log and 
config. What does the WeeWX log shown when weectl import is run? And what 
is in weewx.conf (and to a lesser extent) the import config file 
/etc/weewx/import/wu-example.conf.

Gary

On Tuesday 23 July 2024 at 15:08:09 UTC+10 kk44...@gmail.com wrote:

> Gary,
>
> may be, it is a little bit of a language problem. I heard of this case 
> before, so I may add some explanation, but I cannot explain all.
>
> The user seems to call weectl import from the command line or from 
> crontab to retrieve data from Wunderground. The command first runs as 
> expected. Data is imported and saved to the database. But then, the command 
> does not end. It hangs. So I suggested to the user to press CTRL-C several 
> times. This resulted in an error message saying that the command hang in 
> the threading module while waiting for a lock.
>
> First question: Where does weectl import use threading? Or does this 
> point to the problem that threading is involved at all?
>
> I had a short glance at the sources, but I did not see it.
>
> Then, there are some hints that third party extensions are involved in the 
> problem. Does weectl import load WeeWX extensions? I do not see a reason 
> to do so. But the output "area 30 31" at the end of the first post is 
> from an extension, not from the command itself.
>
> Karen
>
>

-- 
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/055517ed-93d0-4cc6-9b70-a26d949445b0n%40googlegroups.com.

[weewx-user] Re: RAM is running full. Apparently it's due to the weectl import

[gjr80]

A few questions for you:
- why do you believe weectl import is the cause of your memory leak 
problem? 
- what does the WeeWX log say? 
- what do you mean by "I have now seen that the weectl import service is 
not stopped". weectl import is a plain ordinary python utility that is run 
from the command line, it is not a WeeWX (or system) service.
- regards your second post, I'm not seeing anything unusual there: weectl 
import was run and appears to have completed execution normal, then ctl-C 
seems to have been pressed. Exactly what did you do (ie commands entered, 
keys pressed)?

Gary
On Tuesday 23 July 2024 at 05:15:49 UTC+10 sebastian...@googlemail.com 
wrote:

>
> One more note
> The message appears after cancellation
>
>
> Finished calculating missing derived observations
> Finished import
> 248 records were processed and 248 unique records imported in 0.42 seconds.
>
> Those records with a timestamp already in the archive will not have been
> imported. Confirm successful import in the weectl log file.
> ^CException ignored in:  '/usr/lib/python3.11/threading.py'>
> Traceback (most recent call last):
>   File "/usr/lib/python3.11/threading.py", line 1590, in _shutdown
> lock.acquire()
> KeyboardInterrupt:
> root@weewx5:~#
>
> Sebastian E schrieb am Montag, 22. Juli 2024 um 13:56:45 UTC+2:
>
>> Hello everyone, I currently have the problem that my RAM is regularly 
>> full and I have to restart the server. 
>>
>> I have now seen that the weectl import service is not stopped. I'm 
>> attaching the output. Does anyone have an idea what this Area 31 30 means? 
>> That's where it seems to hang. Thank you
>>
>>
>> root@weewx5:~# weectl import 
>> --import-config=/etc/weewx/import/wu-example.conf --no-prompt --verbose
>> Using configuration file /etc/weewx/weewx.conf
>> Starting weectl import...
>> Observation history for Weather Underground station 'I*' will be 
>> imported.
>> The following options will be used:
>> config=/etc/weewx/weewx.conf, 
>> import-config=/etc/weewx/import/wu-example.conf
>> station=I**, from=None, to=None
>> apiKey=**
>> dry-run=False, calc_missing=True, ignore_invalid_data=True
>> tranche=250, interval=5, wind_direction=[0.0, 360.0]
>> Using database binding 'wx_binding', which is bound to database 
>> 'weewx.sdb'
>> Destination table 'archive' unit system is '0x10' (METRIC).
>> The following imported field-to-WeeWX field map will be used:
>> source field 'epoch' in units 'unix_epoch' --> WeeWX field 'dateTime'
>> source field 'tempAvg' in units 'degree_F' --> WeeWX field 'outTemp'
>> source field 'humidityAvg' in units 'percent' --> WeeWX field 
>> 'outHumidity'
>> source field 'dewptAvg' in units 'degree_F' --> WeeWX field 'dewpoint'
>> source field 'heatindexAvg' in units 'degree_F' --> WeeWX field 
>> 'heatindex'
>> source field 'windchillAvg' in units 'degree_F' --> WeeWX field 
>> 'windchill'
>> source field 'pressureAvg' in units 'inHg' --> WeeWX field 'barometer'
>> source field 'precipTotal' in units 'inch' --> WeeWX field 'rain'
>> (source field 'precipTotal' will be treated as a cumulative value)
>> source field 'precipRate' in units 'inch_per_hour' --> WeeWX field 
>> 'rainRate'
>> source field 'windspeedAvg' in units 'mile_per_hour' --> WeeWX field 
>> 'windSpeed'
>> source field 'winddirAvg' in units 'degree_compass' --> WeeWX field 
>> 'windDir'
>> source field 'windgustHigh' in units 'mile_per_hour' --> WeeWX field 
>> 'windGust'
>> source field 'solarRadiationHigh' in units 'watt_per_meter_squared' --> 
>> WeeWX field 'radiation'
>> source field 'uvHigh' in units 'uv_index' --> WeeWX field 'UV'
>> Missing derived observations will be calculated.
>> Starting import ...
>> Records covering multiple periods have been identified for import.
>> Obtaining raw import data for period 1 ...
>> Raw import data read successfully for period 1.
>> Mapping raw import data for period 1 ...
>> Mapped 139 records.
>> Raw import data mapped successfully for period 1.
>> Saving mapped data to archive for period 1 ...
>> 139 records identified for import.
>> Unique records processed: 139; Last timestamp: 2024-07-22 11:34:52 CEST 
>> (1721640892)
>> Mapped data saved to archive successfully for period 1.
>> Calculating missing derived observations ...
>> Processing record: 140; Last record: 2024-07-23 00:00:00 CEST (1721685600)
>> Recalculating daily summaries...
>> Finished recalculating daily summaries
>> Finished calculating missing derived observations
>> Finished import
>> 139 records were processed and 139 unique records imported in 0.28 
>> seconds.
>> Those records with a timestamp already in the archive will not have been
>> imported. Confirm successful import in the weectl log file.
>> area 30 31
>>
>>

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

[weewx-user] Re: Remove Inide Temp graph

[gjr80]

Did you look in the Standard skin skin.conf under [ImageGenerator] 
[[day_images]]:

[[day_images]]


[[[dayinside]]]
inTemp

Comment out the [[[dayinside]]] and inTemp lines. Likewise in 
[[week_images]], [[month_images]] and [[year_images]].

Gary
On Monday 22 July 2024 at 09:35:50 UTC+10 dunb...@gmail.com wrote:

> I would appreciate some help to eliminate this graph in my Standard 
> Skin[image: 
> Screenshot from 2024-07-22 11-29-16.png]
>
> I have searched index.html.tmpl and skin.conf and weewx.conf and cannot 
> seem to find where the Inside Temperature graph sits. I have eliminated all 
> references to inside temperature so that it is not recorded...but cannot 
> seem to find the graph reference so that I can eliminate that also.
>
>
>

-- 
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/f16147a9-2ffe-4e44-b53f-f288952eb70fn%40googlegroups.com.

[weewx-user] Re: Need solid line in graph plot

[gjr80]

On Saturday 20 July 2024 at 07:42:39 UTC+10 bell...@gmail.com wrote:

I don’t fully understand the `line_gap_fraction` option. But I seem to 
remember that `None` values will always cause a break in the plot…


line_gap_fraction does seem a little mystical in operation but once you 
understand how it works it is fairly easy to use. Think of line_gap_fraction 
as the proportion of the overall x-axis timeframe that the plot engine 
considers to be a gap in data. So for a typical day plot (27 hours or 97200 
seconds) a line_gap_fraction of 0.05 means that any gap in time between 
successive plot points of 4860 seconds (81 minutes) or longer will be 
considered a gap and result in a gap in the plotted line. If line_gap_fraction 
= 0.01 the gap drops to 16.2 minutes. So for data with a 15 minute archive 
period a line_gap_fraction = 0.01 will plot a continuous line provided 
there are no missing points. Any missing points result in a gap of at least 
30 minutes so line_gap_fraction = 0.01 will result in gaps. In this case a 
line_gap_fraction 
= 0.02 or greater is required. The default line_gap_fraction = 0.05 should 
work fine. If it is not then something else is amiss (first thing that 
springs to mind is the possibility that line_gap_fraction is being 
overridden somewhere in the respective skin.conf or weewx.conf).

The same applies for week, month and year plots, but you now apply 
line_gap_fraction to a much longer overall x-axis timeframe meaning the gap 
in seconds for a given line_gap_fraction value is greater . Also, week, 
month and year plots by default plot an aggregate so the data points are 
now spaced every 'aggregate interval' seconds and not necessarily every 
'archive period' seconds.

Also, when line_gap_fraction is omitted (or set to a value <0 or >1) any 
missing data points will be considered a gap and plotted as such. In this 
case you definitely do not want to omit line_gap_fraction or you will 
always have gaps.

Gary

-- 
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/13ad33a5-8a38-4026-9181-54cf9194c808n%40googlegroups.com.

[weewx-user] Re: List of variables available to Weewx and adding some

[gjr80]

Not sure what you mean by 'a list of variables'. 

Do you mean a list of observation types, eg outside temperature, inside 
temperature, rainfall, wind speed etc? If so that is very much dependent on 
the driver/station you are using. If you are using one of the drivers 
distributed with WeeWX then you may find some useful information for each 
driver/station in the WeeWX Hardware Guide 
, in particular the Station 
Data section at the end of each driver section. For example, here is the 
vantage driver Station Data 
 section for the 
Davis Vantage stations. If you are using a third party driver you need to 
refer to the driver documentation or the driver author.

Or are you referring to the tags used in WeeWX reports? (this would not 
seem to be something you would normally document on a PWS web page but each 
to his own). If you are, then again there is no definitive list, you will 
find some information on the type of tags supported in WeeWX reports in the 
Tags  section of The 
Cheetah generator  
section of the Customization guide 
, but this really only 
covers the type of tags available; ie current data, aggregates of 
historical data etc. Again the driver/station determines what observational 
data (outside temperature, wind speed, rainfall etc) is available.

Gary
On Thursday 18 July 2024 at 01:26:09 UTC+10 Wiggytoo wrote:

> Hi all,
>
> Apologies if this is right ion front of me nut I wanted to see a list of 
> the variables available to Weewx - to add to an about page for example.
>
> Also to create a new one and point it at an observation if it is not 
> already in teh list - RF strength for example.
>
> This is to add to this page
>
> https://www.wiggytoo.co.uk/about/
>
> Have looked at wiki and docs but failed.
>
> Thanks,
> Gav
>

-- 
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/856a42c1-0017-4ab1-883a-73e30bec29ean%40googlegroups.com.

Re: [weewx-user] WeeWX v5.1 is available

[gjr80]

Did you try any of the steps in the link that I gave you? In particular 
clearing the logger memory with *weectl device --clear-memory*. This is a 
common issue encountered with Davis loggers; the logger will provide loop 
packets (which is what software record generation is based upon) but not 
archive records (which is what hardware record generation is based upon). 
Frequently, unless you clear the logger memory the logger will stay in this 
corrupted state. Sure, it will work with software record generation as you 
have discovered, but you will loose the ability to backfill with records 
saved to the logger should your WeeWX machine stop working or have some 
sort of outage.

In the years I have been here I have not yet heard of a logger failing in 
the way you described; clearing the logger memory has always restored 
normal (hard archive record) operation.

Gary

On Monday 8 July 2024 at 07:42:46 UTC+10 igor.d...@gmail.com wrote:

> Thank you. Data logger is not working anymore, so i switched in weewx.conf 
> parameter record_generation to software.
> Maybe is time for a new meteo station. :)
>
> Dana nedjelja, 7. srpnja 2024. u 01:25:58 UTC+2 korisnik gjr80 napisao je:
>
>> From the very short log extract provided this sounds very much like 
>> corrupted station memory rather than anything to do with uploading to web 
>> server etc (if you look at the log at 12:30:15 no archive records were 
>> downloaded so no archive records added to database so the report cycle 
>> generates the same pages with the same (old) data). I would suggest working 
>> through the Corrupt station memory 
>> <https://github.com/weewx/weewx/wiki/Troubleshooting-the-Davis-Vantage-station#corrupt-station-memory>
>>  
>> section of the Troubleshooting the Davis Vantage station 
>> <https://github.com/weewx/weewx/wiki/Troubleshooting-the-Davis-Vantage-station>
>>  
>> wiki page.
>>
>> Gary
>>
>> On Saturday 6 July 2024 at 23:25:41 UTC+10 igor.d...@gmail.com wrote:
>>
>>> No.
>>> All the data is from this morning.
>>>
>>>
>>> Dana subota, 6. srpnja 2024. u 15:07:21 UTC+2 korisnik Graham Eddy 
>>> napisao je:
>>>
>>>> my last attempt at the question: are the reports generated on the weewx 
>>>> server under public_html (not those viewed on the external web server) 
>>>> showing correct/latest data? it is a yes/no question
>>>> *⊣GE⊢*
>>>>
>>>> On 6 Jul 2024, at 11:03 PM, Igor Dobrača  wrote:
>>>>
>>>> For me Weewx isn't collecting anything since the last data is for this 
>>>> morning.
>>>>
>>>> Dana subota, 6. srpnja 2024. u 13:50:27 UTC+2 korisnik Graham Eddy 
>>>> napisao je:
>>>>
>>>>> if the weewx server data is correct, and your web server data is not, 
>>>>> then your uploading is the problem
>>>>> *⊣GE⊢*
>>>>>
>>>>> On 6 Jul 2024, at 9:46 PM, Igor Dobrača  wrote:
>>>>>
>>>>> does the report on the weewx server (not the web server) include the 
>>>>> data?
>>>>>
>>>>>
>>>>>
>>>> -- 
>>>> 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/7f15d917-ef1d-4311-99d7-0711cd3432een%40googlegroups.com
>>>>  
>>>> <https://groups.google.com/d/msgid/weewx-user/7f15d917-ef1d-4311-99d7-0711cd3432een%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>> .
>>>>
>>>>
>>>>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/43a61511-da84-40c3-9f5f-59f25f0367c9n%40googlegroups.com.

Re: [weewx-user] WeeWX v5.1 is available

[gjr80]

>From the very short log extract provided this sounds very much like 
corrupted station memory rather than anything to do with uploading to web 
server etc (if you look at the log at 12:30:15 no archive records were 
downloaded so no archive records added to database so the report cycle 
generates the same pages with the same (old) data). I would suggest working 
through the Corrupt station memory 

 
section of the Troubleshooting the Davis Vantage station 
 
wiki page.

Gary

On Saturday 6 July 2024 at 23:25:41 UTC+10 igor.d...@gmail.com wrote:

> No.
> All the data is from this morning.
>
>
> Dana subota, 6. srpnja 2024. u 15:07:21 UTC+2 korisnik Graham Eddy napisao 
> je:
>
>> my last attempt at the question: are the reports generated on the weewx 
>> server under public_html (not those viewed on the external web server) 
>> showing correct/latest data? it is a yes/no question
>> *⊣GE⊢*
>>
>> On 6 Jul 2024, at 11:03 PM, Igor Dobrača  wrote:
>>
>> For me Weewx isn't collecting anything since the last data is for this 
>> morning.
>>
>> Dana subota, 6. srpnja 2024. u 13:50:27 UTC+2 korisnik Graham Eddy 
>> napisao je:
>>
>>> if the weewx server data is correct, and your web server data is not, 
>>> then your uploading is the problem
>>> *⊣GE⊢*
>>>
>>> On 6 Jul 2024, at 9:46 PM, Igor Dobrača  wrote:
>>>
>>> does the report on the weewx server (not the web server) include the 
>>> data?
>>>
>>>
>>>
>> -- 
>> 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/7f15d917-ef1d-4311-99d7-0711cd3432een%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/aefb8d86-367b-46e8-b8b3-1d15ac192740n%40googlegroups.com.

[weewx-user] Re: Weewx 5.0 FTP and Rsync not even attempting to upload what's going on?

[gjr80]

The clue will be in the log, sometimes it is what is not in the log rather 
than an error message that provides the clue. I suggest you leave debug = 1, 
restart WeeWX and post a log extract showing the full WeeWX startup and at 
least a couple of report cycles.

Gary
On Sunday 16 June 2024 at 13:07:29 UTC+10 kevi...@gmail.com wrote:

> I have FTP and Rsync enabled and the servers and credentials specified, 
> but no uploads and no errors in the log. Any suggestions? The local files 
> are created, but there is nothing on the log to indicate any upload 
> attempts. I have 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/6ad47c32-1293-4d53-b9f5-f2e7e496d079n%40googlegroups.com.

[weewx-user] Re: Do I need a plugin to use rsync and ftp in weewx 5.0?

[gjr80]

Yes. No plugin required.

Gary

On Sunday 16 June 2024 at 14:08:24 UTC+10 kevi...@gmail.com wrote:

> Does weewx do ftp and rsync out of the box? Or is a plugin required?

-- 
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/1d2bb39e-0356-42cb-8b5e-5c4a191ac38dn%40googlegroups.com.

Re: [weewx-user] Setting Vantage Vue archive interval

[gjr80]

Correct, your database won't be touched, it is just the logger memory that 
will be cleared of archive records. If WeeWX has been operating with your 
station and is up to date you will lose nothing.

Gary

On Tuesday 4 June 2024 at 10:21:53 UTC+10 robcr...@gmail.com wrote:

Can you tell me the implications of

rob@pi4:~ $ weectl device --set-interval=5
Using configuration file /etc/weewx/weewx.conf
Using driver weewx.drivers.vantage.
Using Vantage driver version 3.6.2 (weewx.drivers.vantage)
Old archive interval is 1 minutes, new one will be 5 minutes.

*Proceeding will change the archive interval as well as erase all old 
archive records.Are you sure you want to proceed (y/n)?*


Are these just archived on the console? So if WeeWX was up to date, no 
impact on my database?

-- 
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/2404afdc-7673-4fd3-9aae-1d4c11746fbbn%40googlegroups.com.

[weewx-user] Re: rsync: host key verification failed - problem

[gjr80]

Nothing to do with your rsync issue, but I notice in your log extract that 
you are running the Ecowitt gateway driver as both a driver and service in 
the same WeeWX instance against the same Ecowitt gateway device:

Jun 01 19:18:18 rpi weewxd[200894]: INFO __main__: Debug: 0
Jun 01 19:18:18 rpi weewxd[200894]: INFO weewx.engine: Loading station type 
GW1000 (user.gw1000)
Jun 01 19:18:18 rpi weewxd[200894]: INFO user.gw1000: GatewayDriver: 
version is 0.6.1
Jun 01 19:18:18 rpi weewxd[200894]: INFO user.gw1000:  device address 
is 192.168.7.206:45000
Jun 01 19:18:18 rpi weewxd[200894]: INFO user.gw1000:  poll interval is 
20 seconds
Jun 01 19:18:18 rpi weewxd[200894]: INFO user.gw1000: GatewayService: 
version is 0.6.1
Jun 01 19:18:18 rpi weewxd[200894]: INFO user.gw1000:  device address 
is 192.168.7.206:45000
Jun 01 19:18:18 rpi weewxd[200894]: INFO user.gw1000:  poll interval is 
20 seconds
Jun 01 19:18:18 rpi weewxd[200894]: INFO weewx.engine: StdConvert target 
unit is 0x1

I am hard pressed to think of a use case needing this configuration, it was 
certainly not something I ever planned for when writing the driver. The 
recommended use of the Ecowitt gateway driver in a given WeeWX instance is 
to run it as a driver unless you have multiple gateway devices or another 
device type that must be run with its own driver. Running as both a driver 
and service against the same device on the same WeeWX instance will impact 
performance (the gateway device is polled twice as often and the entire 
sensor data and metadata is decoded twice irrespective of and field 
filtering that may be applied).

At best you are just increasing the system (and WeeWX) load, at worst you 
are increasing the system load and may experience unknown 2nd order effects 
on the data emitted by WeeWX.

I would suggest dropping back to running the Ecowitt gateway driver as a 
driver only.

Gary
On Sunday 2 June 2024 at 10:34:36 UTC+10 Ben W. wrote:

> Greetings!
> Thank you for logging these steps last year:
>
> 1. I logged as root ('sudo -i' from 'pi' account)
> 2. generated SSH keys ('ssh-keygen')
> 3. copied them to external server ('ssh-copy-id ace...@external.domain.com 
>  -p 222')
> 4. copied /home/pi/.ssh/config to /root/.ssh/config
> 5. changed owner of 'config' ('chown root:root /root/.ssh/config')
> 6. waited for next synchronization
> 7. smiled because everything worked as expected :)
>
> I'm stuck between 6 and 7 and unsure what I'm doing wrong. My logs are 
> below. I've copied the public key from the 'root' user and verified on my 
> paid web hosting site that they have the same key even with 'root'. I can 
> SSH in, but the host is still asking for a password - only if I enter the 
> password am I able to authenticate. It's as-if either side isn't seeing the 
> key. I'm assuming that's my problem with rsync. The logs:
>
> ___
>
> Jun 01 19:18:18 rpi systemd[1]: Started weewx.service - WeeWX.
> Jun 01 19:18:18 rpi weewxd[200894]: INFO __main__: Initializing weewxd 
> version 5.0.2
> Jun 01 19:18:18 rpi weewxd[200894]: INFO __main__: Command line: 
> /usr/share/weewx/weewxd.py /etc/weewx/weewx.conf
> Jun 01 19:18:18 rpi weewxd[200894]: INFO __main__: Using Python 3.11.2 
> (main, Mar 13 2023, 12:18:29) [GCC 12.2.0]
> Jun 01 19:18:18 rpi weewxd[200894]: INFO __main__: Located at 
> /usr/bin/python3
> Jun 01 19:18:18 rpi weewxd[200894]: INFO __main__: Platform 
> Linux-6.6.20+rpt-rpi-2712-aarch64-with-glibc2.36
> Jun 01 19:18:18 rpi weewxd[200894]: INFO __main__: Locale: 'en_GB.UTF-8'
> Jun 01 19:18:18 rpi weewxd[200894]: INFO __main__: Entry path: 
> /usr/share/weewx/weewxd.py
> Jun 01 19:18:18 rpi weewxd[200894]: INFO __main__: WEEWX_ROOT: /etc/weewx
> Jun 01 19:18:18 rpi weewxd[200894]: INFO __main__: Configuration file: 
> /etc/weewx/weewx.conf
> Jun 01 19:18:18 rpi weewxd[200894]: INFO __main__: User module: 
> /etc/weewx/bin/user
> Jun 01 19:18:18 rpi weewxd[200894]: INFO __main__: Debug: 0
> Jun 01 19:18:18 rpi weewxd[200894]: INFO weewx.engine: Loading station 
> type GW1000 (user.gw1000)
> Jun 01 19:18:18 rpi weewxd[200894]: INFO user.gw1000: GatewayDriver: 
> version is 0.6.1
> Jun 01 19:18:18 rpi weewxd[200894]: INFO user.gw1000:  device address 
> is 192.168.7.206:45000
> Jun 01 19:18:18 rpi weewxd[200894]: INFO user.gw1000:  poll interval 
> is 20 seconds
> Jun 01 19:18:18 rpi weewxd[200894]: INFO user.gw1000: GatewayService: 
> version is 0.6.1
> Jun 01 19:18:18 rpi weewxd[200894]: INFO user.gw1000:  device address 
> is 192.168.7.206:45000
> Jun 01 19:18:18 rpi weewxd[200894]: INFO user.gw1000:  poll interval 
> is 20 seconds
> Jun 01 19:18:18 rpi weewxd[200894]: INFO weewx.engine: StdConvert target 
> unit is 0x1
> Jun 01 19:18:18 rpi weewxd[200894]: INFO weewx.wxservices: StdWXCalculate 
> will use data binding wx_binding
> Jun 01 19:18:18 rpi weewxd[200894]: INFO weewx.engine: Archive will use 
> data binding wx_binding
> Jun 01 19:18:18 rpi w

Re: [weewx-user] Re: removed bad rainrate data but this did not reflect in totals

[gjr80]

That's quite possible, when Xtypes came along in v4.0.0 the StdWXCalculate 
service was re-written to utilise Xtypes resulting in rainRate only being 
calculated for loop packets. Versions before v4.0.0 calculated rainRate for 
both loop packets and archive records.

But I digress.

Gary

On Wednesday 15 May 2024 at 14:16:29 UTC+10 michael.k...@gmx.at wrote:

> Good to know. I can't remember how I recalculated the rainRate some years 
> ago, when I switched from an 1h-interval to a 15-min interval. Obviously 
> not with --calc-missing, because it worked :)
>
> gjr80 schrieb am Dienstag, 14. Mai 2024 um 23:55:01 UTC+2:
>
>> Whilst rainRate may be a value calculated by WeeWX, the current 
>> StdWXCalculate service is limited in that it can only calculate rainRate 
>> from loop packet data. In the case of a backfill/recalculate (as with an 
>> import) the only rain data available is from archive records and hence 
>> rainRate is not calculated. In these cases rainRate must be manually 
>> calculated.
>>
>> Issue #787 <https://github.com/weewx/weewx/issues/787> was raised to 
>> address this behaviour for imports. Any resolution to issue #787 would 
>> likely fix the rainRate re-calculate behaviour as well, but I have no 
>>  timeframe for when issue #787 might be addressed.
>>
>> Gary
>>
>> On Tuesday 14 May 2024 at 23:39:19 UTC+10 michael.k...@gmx.at wrote:
>>
>>> rainRate is a calculated value: 
>>> https://weewx.com/docs/5.0/reference/weewx-options/stdwxcalculate/
>>>
>>> So first you correct all the rain values and may want to delete rainRate 
>>> values from your database
>>> Second recalculate them: 
>>> https://weewx.com/docs/5.0/utilities/weectl-database/#calculate-missing-derived-variables
>>> Third drop the daily summaries 
>>> https://weewx.com/docs/5.0/utilities/weectl-database/#drop-the-daily-summaries
>>> Fourth rebuild the daily summaries 
>>> https://weewx.com/docs/5.0/utilities/weectl-database/#rebuild-the-daily-summaries
>>>
>>> If your archive values are sane, your totals will be sane then.
>>> Consider only dropping/rebuilding the daily summaries for days with bad 
>>> data, this will be faster and you won't lose the exact timestamps/value for 
>>> min/max records on all the other days. See these switches in the docs:  
>>> [[--date=-mm-dd] 
>>> | [--from=-mm-dd] [--to=-mm-dd]]
>>>
>>> Kevin Crivelli schrieb am Dienstag, 14. Mai 2024 um 14:48:16 UTC+2:
>>>
>>>> I did everything here. It is how I was able to remove the bad rainrate 
>>>> data. The problem now is that while the bad rainrate data is gone, the 
>>>> resulting rain total data is not. I need to get the rain totals to reflect 
>>>> the rainrate data now. The totals are still considering the bad rainrate 
>>>> data that has been removed. 
>>>>
>>>> On Tue, May 7, 2024, 2:22 PM vince  wrote:
>>>>
>>>>> You might want to consult the wiki.  That's why hundreds of hours have 
>>>>> been spent creating it.
>>>>>
>>>>> https://github.com/weewx/weewx/wiki/Cleaning-up-old-'bad'-data
>>>>>
>>>>> On Tuesday, May 7, 2024 at 9:19:04 AM UTC-7 Kevin Crivelli wrote:
>>>>>
>>>>>> or perhaps there is a way to rebuild the raintotals fields from the 
>>>>>> current rainrate data
>>>>>>
>>>>>> On Tuesday, May 7, 2024 at 12:17:20 PM UTC-4 Kevin Crivelli wrote:
>>>>>>
>>>>>>> I removed bad rainrate data but it did not effect the raintotals 
>>>>>>> field. I was able to determine the epoch date-time for the bad rainrate 
>>>>>>> data. Having those I was going to delete the rain_total values for 
>>>>>>> those 
>>>>>>> entries but how would I have that then reflect in the following 
>>>>>>> rain_total 
>>>>>>> fields?
>>>>>>>
>>>>>>> chatgpt gave me this which I feel is a start but I'm not quite there 
>>>>>>> yet. anyone able to help me with this?
>>>>>>>
>>>>>>> -- Store the rain total of the specific datetime in a variable
>>>>>>> SET @deleted_rain_total = (SELECT rain_total FROM your_table WHERE 
>>>>>>> datetime = specific_datetime);
>>>>>>>
>>>>>>> -- Delete the rain total at the sp

Re: [weewx-user] Re: removed bad rainrate data but this did not reflect in totals

[gjr80]

Whilst rainRate may be a value calculated by WeeWX, the current 
StdWXCalculate service is limited in that it can only calculate rainRate 
from loop packet data. In the case of a backfill/recalculate (as with an 
import) the only rain data available is from archive records and hence 
rainRate is not calculated. In these cases rainRate must be manually 
calculated.

Issue #787  was raised to 
address this behaviour for imports. Any resolution to issue #787 would 
likely fix the rainRate re-calculate behaviour as well, but I have no 
 timeframe for when issue #787 might be addressed.

Gary

On Tuesday 14 May 2024 at 23:39:19 UTC+10 michael.k...@gmx.at wrote:

> rainRate is a calculated value: 
> https://weewx.com/docs/5.0/reference/weewx-options/stdwxcalculate/
>
> So first you correct all the rain values and may want to delete rainRate 
> values from your database
> Second recalculate them: 
> https://weewx.com/docs/5.0/utilities/weectl-database/#calculate-missing-derived-variables
> Third drop the daily summaries 
> https://weewx.com/docs/5.0/utilities/weectl-database/#drop-the-daily-summaries
> Fourth rebuild the daily summaries 
> https://weewx.com/docs/5.0/utilities/weectl-database/#rebuild-the-daily-summaries
>
> If your archive values are sane, your totals will be sane then.
> Consider only dropping/rebuilding the daily summaries for days with bad 
> data, this will be faster and you won't lose the exact timestamps/value for 
> min/max records on all the other days. See these switches in the docs:  
> [[--date=-mm-dd] 
> | [--from=-mm-dd] [--to=-mm-dd]]
>
> Kevin Crivelli schrieb am Dienstag, 14. Mai 2024 um 14:48:16 UTC+2:
>
>> I did everything here. It is how I was able to remove the bad rainrate 
>> data. The problem now is that while the bad rainrate data is gone, the 
>> resulting rain total data is not. I need to get the rain totals to reflect 
>> the rainrate data now. The totals are still considering the bad rainrate 
>> data that has been removed. 
>>
>> On Tue, May 7, 2024, 2:22 PM vince  wrote:
>>
>>> You might want to consult the wiki.  That's why hundreds of hours have 
>>> been spent creating it.
>>>
>>> https://github.com/weewx/weewx/wiki/Cleaning-up-old-'bad'-data
>>>
>>> On Tuesday, May 7, 2024 at 9:19:04 AM UTC-7 Kevin Crivelli wrote:
>>>
 or perhaps there is a way to rebuild the raintotals fields from the 
 current rainrate data

 On Tuesday, May 7, 2024 at 12:17:20 PM UTC-4 Kevin Crivelli wrote:

> I removed bad rainrate data but it did not effect the raintotals 
> field. I was able to determine the epoch date-time for the bad rainrate 
> data. Having those I was going to delete the rain_total values for those 
> entries but how would I have that then reflect in the following 
> rain_total 
> fields?
>
> chatgpt gave me this which I feel is a start but I'm not quite there 
> yet. anyone able to help me with this?
>
> -- Store the rain total of the specific datetime in a variable
> SET @deleted_rain_total = (SELECT rain_total FROM your_table WHERE 
> datetime = specific_datetime);
>
> -- Delete the rain total at the specific datetime
> DELETE FROM your_table WHERE datetime = specific_datetime;
>
> -- Decrease the rain totals for the following datetimes
> UPDATE your_table
> SET rain_total = rain_total - @deleted_rain_total
> WHERE datetime > specific_datetime;
>
> These are the date and times of the entries that need their raintotal 
> nulled and then the proceeding raintotals to reflect the change
>
> 1699559700: 2024-05-10 01:55:00
> 169956: 2024-05-10 01:56:40
> 1709221800: 2024-05-26 06:50:00
> 1709222100: 2024-05-26 06:55:00
> 1713436800: 2024-06-16 10:00:00
> 1713437100: 2024-06-16 10:05:00
> 1713780900: 2024-06-20 03:35:00
> 1713781200: 2024-06-20 03:40:00
> 1714771200: 2024-06-25 18:40:00
> 1714771500: 2024-06-25 18:45:00
> 1699559400: 2024-05-10 01:50:00
> 1699560300: 2024-05-10 01:51:40
> 1709221500: 2024-05-26 06:45:00
> 1713437400: 2024-06-16 10:10:00
> 1713781500: 2024-06-20 03:05:00
> 1714771800: 2024-06-25 18:10:00
>
> -- 
>>> 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/b687da34-99af-42a8-a84b-490f6c902d91n%40googlegroups.com
>>>  
>>> 
>>> .
>>>
>>

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

[weewx-user] Re: No DB or reports update

[gjr80]

Reinstalling is a bit drastic without first seeing what the problem is. 
Despite a lengthy log extract we did not see the full WeeWX startup (didn't 
see anything covering the driver being loaded) nor did we see anything 
after WeeWX startup. How about posting another log extract showing the full 
WeeWX startup and a good 10-15 minutes after WeeWX has started (ie after 
the 'Starting main packet loop' log entry).

Gary

On Monday 22 April 2024 at 01:54:50 UTC+10 jw1...@gmail.com wrote:

> Hi,
> Amid some updates and other problem solving I now have no updates 
> happening to the database nor the /var/www/html/weewx reports.
> I could have butchered the config it a bit - is there a safe (retaining 
> database) way to reinstall? Weewx.conf and syslog excerpt below.
> Thanks,
> JW
>
>
> *WEEWX.CONF (first couple sections)*
>
> # WEEWX CONFIGURATION FILE
> #
> # Copyright (c) 2009-2021 Tom Keffer 
> # See the file LICENSE.txt for your rights.
>
>
> ##
>
> # This section is for general configuration information.
>
> # Set to 1 for extra debug info, otherwise comment it out or set to zero
> debug = 1
>
> # Root directory of the weewx data file hierarchy for this station
> WEEWX_ROOT = /
>
> # Whether to log successful operations
> log_success = True
>
> # Whether to log unsuccessful operations
> log_failure = True
>
> # How long to wait before timing out a socket (FTP, HTTP) connection
> socket_timeout = 20
>
> # Do not modify this. It is used when installing and updating weewx.
> version = 5.0.2
>
>
> ##
>
>
> *SYSLOG EXCERPT*
>
> Apr 21 11:46:10 sparta weewxd[429125]: DEBUG weewx.engine: Loading service 
> weewx.engine.StdTimeSynch
> Apr 21 11:46:10 sparta weewxd[429125]: DEBUG weewx.engine: Finished 
> loading service weewx.engine.StdTimeSynch
> Apr 21 11:46:10 sparta weewxd[429125]: DEBUG weewx.engine: Loading service 
> weewx.engine.StdConvert
> Apr 21 11:46:10 sparta weewxd[429125]: INFO weewx.engine: StdConvert 
> target unit is 0x1
> Apr 21 11:46:10 sparta weewxd[429125]: DEBUG weewx.engine: Finished 
> loading service weewx.engine.StdConvert
> Apr 21 11:46:10 sparta weewxd[429125]: DEBUG weewx.engine: Loading service 
> weewx.engine.StdCalibrate
> Apr 21 11:46:10 sparta weewxd[429125]: DEBUG weewx.engine: Finished 
> loading service weewx.engine.StdCalibrate
> Apr 21 11:46:10 sparta weewxd[429125]: DEBUG weewx.engine: Loading service 
> weewx.engine.StdQC
> Apr 21 11:46:10 sparta weewxd[429125]: DEBUG weewx.engine: Finished 
> loading service weewx.engine.StdQC
> Apr 21 11:46:10 sparta weewxd[429125]: DEBUG weewx.engine: Loading service 
> weewx.wxservices.StdWXCalculate
> Apr 21 11:46:10 sparta weewxd[429125]: INFO weewx.wxservices: 
> StdWXCalculate will use data binding wx_binding
> Apr 21 11:46:10 sparta weewxd[429125]: DEBUG weewx.manager: Daily summary 
> version is 4.0
> Apr 21 11:46:10 sparta weewxd[429125]: DEBUG weewx.engine: Finished 
> loading service weewx.wxservices.StdWXCalculate
> Apr 21 11:46:10 sparta weewxd[429125]: DEBUG weewx.engine: Loading service 
> user.csv.CSV
> Apr 21 11:46:10 sparta weewxd[429125]: INFO user.csv: service version is 
> 0.11
> Apr 21 11:46:10 sparta weewxd[429125]: DEBUG weewx.engine: Finished 
> loading service user.csv.CSV
> Apr 21 11:46:10 sparta weewxd[429125]: DEBUG weewx.engine: Loading service 
> user.ws.WsWXCalculate
> Apr 21 11:46:10 sparta weewxd[429125]: INFO user.ws: WsWXCalculate 
> version 0.1.4
> Apr 21 11:46:10 sparta weewxd[429125]: INFO user.ws: WsWXCalculate 
> sunshine threshold: 120
> Apr 21 11:46:10 sparta weewxd[429125]: INFO user.ws: pyephem was detected
> Apr 21 11:46:10 sparta weewxd[429125]: DEBUG weewx.engine: Finished 
> loading service user.ws.WsWXCalculate
> Apr 21 11:46:10 sparta weewxd[429125]: DEBUG weewx.engine: Loading service 
> user.mem.MemoryMonitor
> Apr 21 11:46:10 sparta weewxd[429125]: DEBUG weewx.manager: Daily summary 
> version is 4.0
> Apr 21 11:46:10 sparta weewxd[429125]: DEBUG weewx.engine: Finished 
> loading service user.mem.MemoryMonitor
> Apr 21 11:46:10 sparta weewxd[429125]: DEBUG weewx.engine: Loading service 
> weewx.wxxtypes.StdWXXTypes
> Apr 21 11:46:10 sparta weewxd[429125]: DEBUG weewx.engine: Finished 
> loading service weewx.wxxtypes.StdWXXTypes
> Apr 21 11:46:10 sparta weewxd[429125]: DEBUG weewx.engine: Loading service 
> weewx.wxxtypes.StdPressureCooker
> Apr 21 11:46:10 sparta weewxd[429125]: DEBUG weewx.engine: Finished 
> loading service weewx.wxxtypes.StdPressureCooker
> Apr 21 11:46:10 sparta weewxd[429125]: DEBUG weewx.engine: Loading service 
> weewx.wxxtypes.StdRainRater
> Apr 21 11:46:10 sparta weewxd[429125]: DEBUG weewx.engine: Finished 
> loading service weewx.wxxtypes.StdRainRater
> Apr 21 11:46:10 sparta weewxd[429125]: DEBUG weewx.engine: Loading service 
> weewx.wxxtypes.StdDelta
> Apr 21 11:46:10 sparta weewxd[429125]: DEBUG weew

[weewx-user] Re: weectl import csv KeyError: 'source_field'

[gjr80]

I think you will find this is the source of the error in your first post:

[[[inHumidity]]] source_field = inHumid unit = percent [[[windSpeed]]] 
source = windAvg unit = mile_per_hour [[[windDir]]] source_field = windDir 
unit = degree_compass

Gary

-- 
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/376d3d39-bb8b-47fe-9245-fe66804a365bn%40googlegroups.com.

[weewx-user] Re: rtgd dont auto update after lost contact from sensor to console

[gjr80]

Did you work through the How to view the log 
<https://github.com/weewx/weewx/wiki/view-logs> link in my first post? 
Depending on your system your logs may or may not appear in /var/log; if 
your system uses systemd (eg Debian bookworm) you will need to use 
journalctl to view the log.

Gary

On Thursday 11 April 2024 at 20:20:55 UTC+10 hobbyl...@gmail.com wrote:

> i use both latest versions of weewx and rtgd. with debian distro. i was 
> allrady debug=1  but i cant see the log in var/log 
>
> Στις Πέμπτη 11 Απριλίου 2024 στις 1:55:25 π.μ. UTC+3, ο χρήστης gjr80 
> έγραψε:
>
>> Impossible to say anything without more detail. What station do you have? 
>> What WeeWX version? What rtgd version? What does the log show? Please post 
>> a log extract showing the full WeeWX startup, this will give us a clear 
>> picture of your setup. Refer to the Help! Posting to weewx user wiki page 
>> <https://github.com/weewx/weewx/wiki/Help!-Posting-to-weewx-user>. Note 
>> the How to view the log <https://github.com/weewx/weewx/wiki/view-logs> 
>> link if you are having difficulties viewing the log. Note also the need to 
>> set debug = 1 in weewx.conf. 
>>
>> How often does this occur? What was in the log when it last occurred? 
>> Please post a log extract from shortly (say 1-2 archive intervals in time) 
>> before the event through to shortly after the event (say 2-3 archive 
>> intervals in time). If relatively frequently it's worth leaving debug = 1 
>> and when it next occurs post a log extract from shortly (say 1-2 archive 
>> intervals in time) before the event through to shortly after the event (say 
>> 2-3 archive intervals in time). 
>>
>> Gary
>> On Wednesday 10 April 2024 at 16:29:14 UTC+10 hobbyl...@gmail.com wrote:
>>
>>> i notice that, every time who i have lost contact the sensor with the 
>>> console, after the connection back again, weewx  (the seasons skin )  
>>> updates data again , but rtgd (the gauge-data.txt )  no. 
>>> only with weewx restarting rtgd works 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/8b71b83b-a044-4dc3-9f60-0ca8a4ee66d5n%40googlegroups.com.

[weewx-user] Re: Export Meteobridge db as csv, import into WeeWX as csv

[gjr80]

Looks fine to me. A couple of comments:

- Importing data in mixed unit systems (ie mixed US customary, Metric and 
Metric WX) should be fine provided your field map units are correctly 
specified.

- Deriving the interval value from the imported data involves taking the 
difference between the timestamp of successive records. This works fine 
when the import data is complete with no missing records, but can be 
problematic when there are missing records. If you have a fixed interval 
you might find it safer to set interval to a fixed number, in your case 
interval 
= 1. 

- Rather than importing all of your data in one go you might want to just 
try importing one or a few few days to start with, you can do this by using 
the --date or --from and --to command line arguments.

Gary
On Wednesday 10 April 2024 at 14:25:29 UTC+10 lightmas...@gmail.com wrote:

> I have a couple years worth of data that is stored on my Meteobridge 
> NanoSD's database. I want to export that data and import it into WeeWX's 
> database.
>
> I have created a custom export for Meteobridge (
> https://pastebin.com/dg7weFe7) that exports everything I could find that 
> has matching columns in the WeeWX DB. Sample of the CSV that was created (
> https://pastebin.com/gkvWRBwP). I have also created a custom WeeWX CSV 
> import config (https://pastebin.com/UL7iFex0) to import all of that.
>
> Just want someone to double check that that looks good before I import 
> years of data in 1 minute intervals.
>

-- 
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/e7188f8b-622a-4037-81df-f596eaad7b04n%40googlegroups.com.

[weewx-user] Re: rtgd dont auto update after lost contact from sensor to console

[gjr80]

Impossible to say anything without more detail. What station do you have? 
What WeeWX version? What rtgd version? What does the log show? Please post 
a log extract showing the full WeeWX startup, this will give us a clear 
picture of your setup. Refer to the Help! Posting to weewx user wiki page 
. Note the How 
to view the log  link if you 
are having difficulties viewing the log. Note also the need to set debug = 1 
in weewx.conf. 

How often does this occur? What was in the log when it last occurred? 
Please post a log extract from shortly (say 1-2 archive intervals in time) 
before the event through to shortly after the event (say 2-3 archive 
intervals in time). If relatively frequently it's worth leaving debug = 1 
and when it next occurs post a log extract from shortly (say 1-2 archive 
intervals in time) before the event through to shortly after the event (say 
2-3 archive intervals in time). 

Gary
On Wednesday 10 April 2024 at 16:29:14 UTC+10 hobbyl...@gmail.com wrote:

> i notice that, every time who i have lost contact the sensor with the 
> console, after the connection back again, weewx  (the seasons skin )  
> updates data again , but rtgd (the gauge-data.txt )  no. 
> only with weewx restarting rtgd works 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/6aecc3e1-3e4e-49b5-a08d-8c0a4c6938e2n%40googlegroups.com.

[weewx-user] Re: Unexpected weewx stop: ERROR weewx.engine: Import of driver failed

[gjr80]

The more I think of it the more I don't see the benefit of this approach 
over using loop_on_init in weewx.conf in dealing with this type of problem. 
Setting loop_on_init = True will cause WeeWX to reload the driver after 
(the default) three consecutive attempts to contact the gateway device 
fail; WeeWX continues running the entire time. Perhaps if some sort of 
network or device initialisation sat in the WeeWX core there might be a 
benefit, but all of that sits solely in the driver (as far as I am aware 
this is the case with all drivers). If the network or the device is in such 
a state that communication with the device via the API is not possible then 
no amount of WeeWX restarts or driver reloads will correct the situation.

It seems to me that forcing a WeeWX restart via systemd is a somewhat heavy 
handed approach.

My opinion only and I expect others will have a different view.

Gary 

On Wednesday 10 April 2024 at 06:00:37 UTC+10 vince wrote:

> update - my ecowitt instance crashed out on me during a several minute 
> network outage while I was updating firmware on the router/switch/ap so I'm 
> trying this solution to see how well that works.  Thanks.
>
> (not a bug in the gw1000 driver - it did exactly what it's configured to 
> do.  It tried 3x with 2 sec in between.  An alternate workaround would be 
> to try 1000x with a minute in between to basically get through any 
> reasonable network outages for the LAN, but I want to try the systemd 
> method as a more generic fix)
>
> On Tuesday, March 26, 2024 at 7:56:12 AM UTC-7 gary@gmail.com wrote:
>
>> I have added these lines to my weewx service file for just such an 
>> instance.
>> Add under StandardError=journal+console entry in the [Service] stanza
>>
>> Restart=on-failure
>> RestartSec=30
>>
>> Restarts weewx after waiting for 30 seconds to allow whatever interfered 
>> to (hopefully) clear.
>>
>> On Monday, March 25, 2024 at 6:26:44 PM UTC-4 vince wrote:
>>
>>> Perhaps this setting (link) 
>>> 
>>>  is 
>>> something to try if you want to experiment and let us know if it works…
>>>
>>> On Monday, March 25, 2024 at 3:11:41 PM UTC-7 Thomas Hackler wrote:
>>>
 thank you for the answer, then it was maybe soemthing wrong with the 
 wifi

 does it make sense to increase the attempts before exit ?

 I try to find something to check if the process is running
 I have some experience with monit, so maybe I find an example or 
 anything else


 vince schrieb am Montag, 25. März 2024 um 22:09:58 UTC+1:

> I have also seen my gw1000 weewx setup abort on the pi4 occasionally 
> when the wifi network bounces for some reason.  Mine's been up for 6 
> weeks 
> now so it is definitely a transient kind of thing.
>
> Writing yourself a little cron job to look for the weewxd process and 
> if it's not there restart it wouldn't be too tough to do.   Perhaps there 
> is some systemd configuration magic that is possible, but I'm not sure 
> there what a safe+effective way to leverage systemd would look like.  I 
> know how cron works :-)
>
> On Monday, March 25, 2024 at 1:56:10 PM UTC-7 Thomas Hackler wrote:
>
>> Hello,
>> my weewx stopped yesterday unexpected. The last logs are attached. It 
>> ran stable for over 1 week. I have restarts of my raspberry pi with cron 
>> every 1 or 2 days. What is the reason that the gw1000 driver has 
>> suddenly a 
>> problem? How can I avoid it in future? Should I increase the attemps if 
>> there is a short problem with the wifi connection?
>> It is a problem of my gw1000 device? I see no problems with the 
>> ecowitt app.
>> Thank you!
>> Regards
>> Thomas
>>
>

-- 
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/78dcf514-66b7-4bfe-b2e7-62208d382425n%40googlegroups.com.

[weewx-user] Re: AWEKAS Upload & Healthchecks.io both stop working this morning

[gjr80]

Don't know if I'm getting special treatment or not, but your link doesn't 
work for me. Just paste the log here, I'm sure Google has sufficient spare 
storage.

Gary

On Tuesday 9 April 2024 at 11:07:57 UTC+10 david...@gmail.com wrote:

> I moved to Weewx 5 on my Raspberry Pi several weeks ago and all has seemed 
> fine. Suddenly this morning after a restart due to a problem with my 
> Vantage Console relay, both have stopped working.
>
> Here's a debug log for about 10 minutes this evening: 
> https://pastebin.com/passmailer
>
> On start up both a still showing as starting but nothing after that.
>
> I did notice "sudo weectl extension list" returns a strange response for 
> Healthchecks even after uninstalling and reinstalling the extension:
>
> Using configuration file /etc/weewx/weewx.conf
> Extension NameVersion   Description
> Belchertown   1.3.1 A clean modern skin with real time streaming 
> updates and interactive charts. Modeled after BelchertownWeather.com
>
> *Healthchecks  ???   Cannot find 'install' module in 
> /etc/weewx/bin/user/installer/Healthchecks*mqtt  0.24 
>  Upload weather data to MQTT server.
> owm   0.9   Upload weather data to OpenWeatherMap.
> windy 0.7   Upload weather data to Windy.
>
> I'd appreciate any help or direction to getting to the source of these 
> issues. Thanks!
>

-- 
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/e9656732-a475-40b7-9bba-2fd9f5c3246bn%40googlegroups.com.

[weewx-user] Re: Weewx won't run after fileparse install

[gjr80]

Where did you get the fileparse.py that you manually installed? If the 
'readme in the direcory' you referred to is the readme in the fileparse 
directory then it has a mistake. For a manual install under a WeeWX v5.x 
package install you should copy fileparse.py as follows:

cd /etc/weewx/examples/flippers
sudo cp bin/user/fileparse.py /etc/weewx/bin/user

The fileparse.py that you are using is different to the version distributed 
with v5.0.2; the line that is throwing the error uses a python2 syntax for 
the print statement. Under python3 print is a function that requires the 
uses of brackets (hence the error). Have a look in 
/etc/weewx/examples/fileparse/bin/user, that directory contains the 
fileparse.py you should be using. The version number should be 0.9. If 
/etc/weewx/examples/fileparse/bin/user/fileparse.py contains a python2 
print statement (rather than the python3 print function) then that is a 
bug. Interestingly, the last version of fileparse.py to include python2 
print statements was included with WeeWX v4.0.0a3 (and it only had 120 
lines); I have no idea how you have ended up with the fileparse.py that you 
have.

Gary 

On Thursday 21 March 2024 at 12:18:30 UTC+10 Ron Walker wrote:

> Fresh install of weewx 5.02 on Raspberry Pi running buster.  I attempted 
> to instll the fileparse driver manually according to readme in the 
> direcory.  When I attempt to start weewx, this the result:
>
> ron@WeatherPi5:~ $ sudo systemctl status weewx
> * weewx.service - WeeWX
>  Loaded: loaded (/lib/systemd/system/weewx.service; enabled; vendor 
> preset: enabled)
>  Active: failed (Result: exit-code) since Wed 2024-03-20 22:11:04 EDT; 
> 4s ago
>Docs: https://weewx.com/docs
> Process: 1638 ExecStart=weewxd /etc/weewx/weewx.conf (code=exited, 
> status=1/FAILURE)
>Main PID: 1638 (code=exited, status=1/FAILURE)
> CPU: 567ms
>
> Mar 20 22:11:04 WeatherPi5 weewxd[1638]:   ^
> Mar 20 22:11:04 WeatherPi5 weewxd[1638]: SyntaxError: invalid syntax
> Mar 20 22:11:04 WeatherPi5 weewxd[1638]: CRITICAL __main__:  
>  __import__(driver)
> Mar 20 22:11:04 WeatherPi5 weewxd[1638]: CRITICAL __main__:    
>  File "/etc/weewx/bin/user/fileparse.py", line 131
> Mar 20 22:11:04 WeatherPi5 weewxd[1638]: CRITICAL __main__:  
>  print weeutil.weeutil.timestamp_to_string(packet['dateTime']), packet
> Mar 20 22:11:04 WeatherPi5 weewxd[1638]: CRITICAL __main__:    
>  ^
> Mar 20 22:11:04 WeatherPi5 weewxd[1638]: CRITICAL __main__:  
>  SyntaxError: invalid syntax
> Mar 20 22:11:04 WeatherPi5 weewxd[1638]: CRITICAL __main__:  
>  Exiting.
> Mar 20 22:11:04 WeatherPi5 systemd[1]: weewx.service: Main process exited, 
> code=exited, status=1/FAILURE
> Mar 20 22:11:04 WeatherPi5 systemd[1]: weewx.service: Failed with result 
> 'exit-code'.
>
> Any help would be greatly appreciated!
>

-- 
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/23296f47-f46a-4539-9393-7a7ad083d479n%40googlegroups.com.

[weewx-user] Re: After new installation problems with season skin / no site

[gjr80]

Yes, that will be fine. [[Bootstrap]] is only created when you install the 
bootstrap skin.

Gary

On Monday 18 March 2024 at 06:37:52 UTC+10 Thomas Hackler wrote:

> I have a copy of my old /etc/weewx/bin/user. there is a 
> historygenerator.py file
> but there is no [[Bootstrap]] in my new or in my old weewx.conf file
>
> so maybe it is enough to copy the file historygenerator.py from my old 
> system to /etc/weewx/bin/user or should I install the bootstrap skin?
>
> So I guess I should install the neowx skin again too ?
>
> gjr80 schrieb am Sonntag, 17. März 2024 um 21:26:05 UTC+1:
>
>> Agree the problem is a missing user.historygenerator search list 
>> extension which (from memory) is provided by the bootstrap skin, but 
>> user.historygenerator is being called by the Seasons skin. So I suspect 
>> you have modified your Season skin in the past and added 
>> user.historygenerator to the Seasons skin config file, 
>> skins/Seasons/skin.conf. This would explain why you missed it when 
>> checking your backup weewx.conf.
>>
>> The solution is to obtain the historygenerator.py from the bootstrap skin 
>> and add it to your system. You could simply extract this file from the 
>> bootstrap skin and save it to you system, but the easiest way will be as 
>> Vince said - just install the bootstrap skin. I would go one step further 
>> and disable the bootstrap skin (set enable = False  under [StdReport] 
>> [[Bootstrap]] in weewx.conf). This will have no impact on the 
>> availability of user.historygenerator, but will prevent the Bootstrap 
>> skin from generating its content/output.
>>
>> Gary
>> On Monday 18 March 2024 at 05:43:50 UTC+10 vince wrote:
>>
>>> Not quite.
>>>
>>> You need to install all added user extensions and skins. In your case it 
>>> looks like you had the bootstrap skin on your old system which has a file 
>>> bin/user/historygenerator.py that you are missing on the new system. Either 
>>> remove the reference to historygenerator in your weewx.conf or install the 
>>> bootstrap skin to add the missing file.
>>>
>>>
>>> On Sunday, March 17, 2024 at 12:23:43 PM UTC-7 Thomas Hackler wrote:
>>>
>>>> sorry I don't understand, I followed this guide
>>>>
>>>> https://weewx.com/docs/5.0/usersguide/backup/
>>>>
>>>> I compared the weewx.conf file from the fresh installation with my old 
>>>> one and added all the missing things
>>>> so I guess everything should work after that? 
>>>> The neowx skin works normal at the moment, so I will check the warnings 
>>>> later
>>>>
>>>>
>>>> vince schrieb am Sonntag, 17. März 2024 um 18:33:09 UTC+1:
>>>>
>>>>> ModuleNotFoundError: No module named 'user.historygenerator'
>>>>> You need to install all skins and extensions referenced in your .conf 
>>>>> files
>>>>>
>>>>> You also have a variety of warnings from neowx:
>>>>> _etc_weewx_skins_neowx_material_month__Y__m_html_tmpl.py:406: 
>>>>> SyntaxWarning: "is not" with a literal. Did you mean "!="?
>>>>>
>>>>> I 'think' this is related to newer versions of python being more 
>>>>> strict.  I recall trying neowx once and simply editing all the places 
>>>>> that 
>>>>> weewx logged those warnings and they went away.
>>>>>
>>>>> On Sunday, March 17, 2024 at 8:12:09 AM UTC-7 Thomas Hackler wrote:
>>>>>
>>>>>> Hello,
>>>>>> my raspberry pi crashed and I started with a new system. Fortunately 
>>>>>> I have copies from my database and the skins.
>>>>>> I started installing weewx and the gw1000 driver, then I copied the 
>>>>>> skin folder and the database.
>>>>>> I had some issues with permissions with the database but this works 
>>>>>> now. 
>>>>>> I use two skins. The neowx skin works fine but I get errors for the 
>>>>>> season skin and no site is made and I don't understand why.
>>>>>>
>>>>>> Mar 17 15:45:28 raspberrypi weewxd[114945]: ERROR weewx.reportengine: 
>>>>>> Caught unrecoverable exception in generator 
>>>>>> 'weewx.cheetahgenerator.CheetahGenerator'
>>>>>>
>>>>>> Full log file attached.
>>>>>> Thank you for helping!
>>>>>> Thomas Hackler
>>>>>>
>>>>>>
>>>>>>

-- 
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/319cad41-5ebb-427b-9d8d-b6d8aca7a130n%40googlegroups.com.

[weewx-user] Re: After new installation problems with season skin / no site

[gjr80]

Agree the problem is a missing user.historygenerator search list extension 
which (from memory) is provided by the bootstrap skin, but 
user.historygenerator is being called by the Seasons skin. So I suspect you 
have modified your Season skin in the past and added user.historygenerator 
to the Seasons skin config file, skins/Seasons/skin.conf. This would 
explain why you missed it when checking your backup weewx.conf.

The solution is to obtain the historygenerator.py from the bootstrap skin 
and add it to your system. You could simply extract this file from the 
bootstrap skin and save it to you system, but the easiest way will be as 
Vince said - just install the bootstrap skin. I would go one step further 
and disable the bootstrap skin (set enable = False  under [StdReport] 
[[Bootstrap]] in weewx.conf). This will have no impact on the availability 
of user.historygenerator, but will prevent the Bootstrap skin from 
generating its content/output.

Gary
On Monday 18 March 2024 at 05:43:50 UTC+10 vince wrote:

> Not quite.
>
> You need to install all added user extensions and skins. In your case it 
> looks like you had the bootstrap skin on your old system which has a file 
> bin/user/historygenerator.py that you are missing on the new system. Either 
> remove the reference to historygenerator in your weewx.conf or install the 
> bootstrap skin to add the missing file.
>
>
> On Sunday, March 17, 2024 at 12:23:43 PM UTC-7 Thomas Hackler wrote:
>
>> sorry I don't understand, I followed this guide
>>
>> https://weewx.com/docs/5.0/usersguide/backup/
>>
>> I compared the weewx.conf file from the fresh installation with my old 
>> one and added all the missing things
>> so I guess everything should work after that? 
>> The neowx skin works normal at the moment, so I will check the warnings 
>> later
>>
>>
>> vince schrieb am Sonntag, 17. März 2024 um 18:33:09 UTC+1:
>>
>>> ModuleNotFoundError: No module named 'user.historygenerator'
>>> You need to install all skins and extensions referenced in your .conf 
>>> files
>>>
>>> You also have a variety of warnings from neowx:
>>> _etc_weewx_skins_neowx_material_month__Y__m_html_tmpl.py:406: 
>>> SyntaxWarning: "is not" with a literal. Did you mean "!="?
>>>
>>> I 'think' this is related to newer versions of python being more strict. 
>>>  I recall trying neowx once and simply editing all the places that weewx 
>>> logged those warnings and they went away.
>>>
>>> On Sunday, March 17, 2024 at 8:12:09 AM UTC-7 Thomas Hackler wrote:
>>>
 Hello,
 my raspberry pi crashed and I started with a new system. Fortunately I 
 have copies from my database and the skins.
 I started installing weewx and the gw1000 driver, then I copied the 
 skin folder and the database.
 I had some issues with permissions with the database but this works 
 now. 
 I use two skins. The neowx skin works fine but I get errors for the 
 season skin and no site is made and I don't understand why.

 Mar 17 15:45:28 raspberrypi weewxd[114945]: ERROR weewx.reportengine: 
 Caught unrecoverable exception in generator 
 'weewx.cheetahgenerator.CheetahGenerator'

 Full log file attached.
 Thank you for helping!
 Thomas Hackler




-- 
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/a6f8b283-5b80-4bc2-ac80-62e2658efbf4n%40googlegroups.com.

[weewx-user] Re: Daily rain total and daylight saving time error.

[gjr80]

If I understand correctly, clocks in Boston went forward one hour at 2am on 
10 March. WeeWX should have handled this correctly; the net result being 
your database will have no data from 2am to 3am 10 March. This is expected 
behaviour and should not be the cause of any lost data. This is all 
predicated on the Vantage console clock and daylight saving settings being 
correctly set and the console changing time as/when it should. If the 
console behaved correctly I have no idea what the problem could be; you may 
find some clues by looking at the log from say 1am to 4am on 10 March (ie 
what records were added to archive) or you may find some clues by looking 
through the archive table in the database, but these are long shots. Tom or 
others may have more ideas.

WeeWX does have a known issue when daylight saving ceases in that one hour 
of data is lost when the clock is wound back by one hour. But I do not 
recall any issues such as this when daylight saving starts.

I'm guessing you are using the weewx-realtime-gauge_data extension 
<https://github.com/gjr80/weewx-realtime_gauge-data> to drive your 
SteelSeries weather gauges? If so, the reason you did not notice any error 
is that the weewx-realtime-gauge_data extension keeps its own running daily 
(midnight reset) rain total based on incoming loop packets. So it is 
impervious to (well non-midnight/non-1am) daylight saving changes. If you 
are using a template based gauge-data.txt it will suffer from the same 
issues as any other WeeWX generated web page as it uses the same 
$day.rain.sum tag.

Gary

On Monday 11 March 2024 at 03:00:32 UTC+10 russe...@comcast.net wrote:

> Hi, daylight saving time happened last night and my rain total 
> ($day.rain.sum) for the day does not equal that on the Davis Vantage Pro2. 
> The console reads 0.73" and weewx puts out 0.52". Interestingly, my Steel 
> Gauges indicate the correct 0.73". I think an hour of rain was dropped. 
>
> weewx version 5.02
>

-- 
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/80965cc0-cafa-4103-80e8-39c151079adcn%40googlegroups.com.

[weewx-user] Re: Weectl import

[gjr80]

I am not sure why you are exporting data from your old WeeWX database and 
then importing the data into a new installation. The WeeWX database is 
compatible across all WeeWX versions so you can just use it without change 
in your new WeeWX installation. Your existing WeeWX database may use the 
old 'wview' database schema rather than the new 'view_extended' database 
schema, but there is no particular need to upgrade to the 'view_extended' 
database schema unless you need the additional fields. In any case, you can 
upgrade an existing WeeWX installation that uses the old 'wview' database 
schema to the new 'view_extended' database schema by following the 
instructions at the Switching to the new wview_extended schema 

 
wiki page.

I would suggest you just copy your old WeeWX database to your new install 
and if required later update to the 'wview_extended' database schema.

Gary
On Saturday 9 March 2024 at 07:09:23 UTC+10 ott...@googlemail.com wrote:

> Dear community,
> I try to import the database of my old weewx installation to the new 
> system (newly installed + new hardware) by exporting CSV file from the old 
> weewx.sdb and import with weectl import onto the new.
> The process interrupts and I receive error messages as long as I have NULL 
> values in the CSV (NULL represented by comma separators without any value 
> ",,"). When I remove the NULLs e.g. by "0" the process completes 
> successfully.
> Does anybody have an idea, because I do not want to fill up the NULLs with 
> "0" because this is not accurate.
> Thank you for support
> JO
> Here ist the errorlog from weectl import:
>
> Using database binding 'wx_binding', which is bound to database 'weewx.sdb'
> Destination table 'archive' unit system is '0x01' (US).
> Missing derived observations will be calculated.
> All WeeWX UV fields will be set to None.
> All WeeWX radiation fields will be set to None.
> This is a dry run, imported data will not be saved to archive.
> Starting dry run import ...
> Traceback (most recent call last):
>   File "/usr/share/weewx/weeimport/weeimport.py", line 849, in map_raw_data
> _value = float(_row[self.map[_field]['source_field']].strip())
> ValueError: could not convert string to float: ''
>
> During handling of the above exception, another exception occurred:
>
> Traceback (most recent call last):
>   File "/usr/share/weewx/weectl.py", line 74, in 
> main()
>   File "/usr/share/weewx/weectl.py", line 66, in main
> namespace.func(namespace)
>   File "/usr/share/weewx/weectllib/__init__.py", line 121, in dispatch
> namespace.action_func(config_dict, namespace)
>   File "/usr/share/weewx/weectllib/import_cmd.py", line 82, in import_func
> weectllib.import_actions.obs_import(config_dict,
>   File "/usr/share/weewx/weectllib/import_actions.py", line 58, in 
> obs_import
> source_obj.run()
>   File "/usr/share/weewx/weeimport/weeimport.py", line 405, in run
> _mapped_data = self.map_raw_data(_raw_data, self.archive_unit_sys)
>   File "/usr/share/weewx/weeimport/weeimport.py", line 897, in map_raw_data
> self.map[_field]['unit'] == 'degree_compass':
>   File "/usr/lib/python3/dist-packages/configobj.py", line 554, in 
> __getitem__
> val = dict.__getitem__(self, key)
> KeyError: 'unit'
>

-- 
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/bef71334-cd5b-4ba0-a7a4-9ff5a758ece5n%40googlegroups.com.

[weewx-user] Re: heating_base

[gjr80]

I'm familiar with heating degree days in the NOAA reports but what are the 
'history reports' you refer to?

Gary

On Wednesday 6 March 2024 at 19:27:27 UTC+10 MaKi68 wrote:

> Hello,
> Where do I need to change the heating_base so that the value is used for 
> NOAA and history reports?
> I have changed the heating_base in
> [StdReport]
>  [[Defaults]]
>  [[[Units]]]
>  DegreeDays
>  heating_base = 20, degree_C
> but this value is only used in the NOAA report and not in the history 
> report (heatdeg).
>
> I'm using weewx 5.0.2 pip on a Raspi5 with a Vantage Pro2.
>
> Thanks in advance
> LG Manfred
>

-- 
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/641fca62-7eb0-435c-b6ae-a0ced1532f6an%40googlegroups.com.

[weewx-user] Re: Upgraded to 5.0.1, DB is updating but not reflecting

[gjr80]

The first thing to do is to post a log extract so we can see exactly what 
is/is not going on. This wiki page 

 
will help you to get a good log extract to post here.

Gary

On Wednesday 6 March 2024 at 14:08:51 UTC+10 illini...@gmail.com wrote:

> I've been at this hours. I updated my WeeWx from 4.10.2 to 5.0.1. I am 
> running Belchertown and have MQTT setup. That is all working. 
>
> The issue is I don't see the archive data updating the charts or 
> reflecting when you refresh the page. The database file itself does appear 
> to be updated every 5 minutes as the modified date is updating every 5 
> minutes.
>
> Any ideas to troubleshoot?
>

-- 
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/be0d2828-e726-4b5c-b114-530ee26bfc6bn%40googlegroups.com.

[weewx-user] Re: weectl extension install ~/Downloads/weewx-steelseries-master.zip

[gjr80]

Tldr, but you cannot install the weewx-steelseries extension direct from 
Github. You need to download the latest release package from the releases 
tab <https://github.com/gjr80/weewx-steelseries/releases> and install from 
the package file.

Gary

On Sunday 3 March 2024 at 23:16:34 UTC+10 philip@gmail.com wrote:

> Hi
> Using a Pi5 with a clean install of all software (Debian 12 bookworn).
> Loaded weewx v5.0.2 using Installation on Debian based systems all OK
> Then tried loading extensions using weectl which all worked OK until I 
> tried
> weectl extension install ~/Downloads/weewx-steelseries-master.zip.
> It failed with
>  weectl extension install ~/Downloads/weewx-steelseries-master.zip
> Using configuration file /etc/weewx/weewx.conf
> Install extension '/home/phil/Downloads/weewx-steelseries-master.zip' 
> (y/n)? y
> Extracting from zip archive 
> /home/phil/Downloads/weewx-steelseries-master.zip
> Traceback (most recent call last):
>   File "/usr/share/weewx/weectl.py", line 74, in 
> main()
>   File "/usr/share/weewx/weectl.py", line 66, in main
> namespace.func(namespace)
>   File "/usr/share/weewx/weectllib/__init__.py", line 121, in dispatch
> namespace.action_func(config_dict, namespace)
>   File "/usr/share/weewx/weectllib/extension_cmd.py", line 116, in 
> install_extension
> ext.install_extension(namespace.source, no_confirm=namespace.yes)
>   File "/usr/share/weewx/weecfg/extension.py", line 138, in 
> install_extension
> extension_name = self._install_from_file(extension_path, filetype)
>  ^
>   File "/usr/share/weewx/weecfg/extension.py", line 168, in 
> _install_from_file
> extension_name = self.install_from_dir(extension_dir)
>  
>   File "/usr/share/weewx/weecfg/extension.py", line 185, in 
> install_from_dir
> self._install_files(installer['files'], extension_dir)
>   File "/usr/share/weewx/weecfg/extension.py", line 269, in _install_files
> shutil.copy(source_path, destination_path)
>   File "/usr/lib/python3.11/shutil.py", line 419, in copy
> copyfile(src, dst, follow_symlinks=follow_symlinks)
>   File "/usr/lib/python3.11/shutil.py", line 256, in copyfile
> with open(src, 'rb') as fsrc:
>  ^^^
> FileNotFoundError: [Errno 2] No such file or directory: 
> '/tmp/tmpyald28op/weewx-steelseries-master/skins/ss/gauge-data.txt.tmpl'
>
> Just wondered what I may have done wrong
> Thanks
>

-- 
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/7a64ede0-bdbc-410d-ba8b-67a95422b1c7n%40googlegroups.com.

[weewx-user] Re: SteelSeries Gauges rain rate problem

[gjr80]

I'm sorry but it is still not clear to me what the exact issue is. I've 
opened the image from your original post on a better screen and as far as I 
can see the gauge shows rain rate in mm/hr, the labels across the top of 
the plot show rain rat win mm/hr but the y-axis label of the plot seems to 
show in/hr. Is the problem *only* the y-axis label being in in/hr? Do the 
rain rate values show on the gauge and in the plot correctly as mm values 
or as inch values? (ie does the gauge indicate 5mm/hr when in fact the 
actual rain rate is 5mm/hr or does the gauge show 5mm/hr when in fact the 
actual rain rate is 5in/hr)

Finally, what are you using to generate the gauge-data.txt? Have you 
installed the skin direct from the SteelSeries-Weather-Gauges repo 
<https://github.com/mcrossley/SteelSeries-Weather-Gauges/tree/master/weather_server>
 
or did you install the weewx-steelseries extension 
<https://github.com/gjr80/weewx-steelseries> ? In either case could you 
please post a copy of the [StdReport] [[SteelSeries]] stanza from weewx.conf 
along with a copy of the skin config file, skin.conf, from the skins/ss 
directory. (note the location of the skins directory will depend on your 
WeeWX version and how you installed WeeWX - refer to *Where to find things* 
in the User's Guide for your particular WeeWX version 
<http://weewx.com/docs.html>).

Gary
On Saturday 2 March 2024 at 22:59:16 UTC+10 davideverd...@gmail.com wrote:

> The rain rate indicator and graph is in inch/hr but in reality it should 
> be mm/h!
>
> Il giorno sabato 2 marzo 2024 alle 12:37:50 UTC+1 gjr80 ha scritto:
>
>> So which one is correct? If the plots are correct what are you using to 
>> generate gauge-data.txt?
>>
>> Gary
>>
>> On Saturday 2 March 2024 at 20:51:34 UTC+10 davideverd...@gmail.com 
>> wrote:
>>
>>> I have a problem with the SteelSeries Gauges 2.7.6 application. On the 
>>> rain rate graph it says mm but the measurement is in inches. How can I 
>>> solve the problem?
>>>
>>>
>>>

-- 
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/10e222ec-dfc9-40e5-95b7-41cdc69a53c1n%40googlegroups.com.

[weewx-user] Re: SteelSeries Gauges rain rate problem

[gjr80]

So which one is correct? If the plots are correct what are you using to 
generate gauge-data.txt?

Gary

On Saturday 2 March 2024 at 20:51:34 UTC+10 davideverd...@gmail.com wrote:

> I have a problem with the SteelSeries Gauges 2.7.6 application. On the 
> rain rate graph it says mm but the measurement is in inches. How can I 
> solve the problem?
>
>
>

-- 
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/a92468da-17c9-4dd3-9a02-4490b8ad06ebn%40googlegroups.com.

[weewx-user] Re: Saratoga extension unhappy with Feb 29th

[gjr80]

Was fixed in release 0.1.9 
<https://github.com/gjr80/weewx-saratoga/releases/tag/v0.1.9>.

Gary

On Friday 1 March 2024 at 10:48:13 UTC+10 vanilla...@gmail.com wrote:

> I just noticed that today my logs are filled with messages every cycle 
> complaining about the date:
>
> ValueError: day is out of range for month
>
> Full log attached
>
> Al

-- 
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/60887087-3954-4072-bbfa-ef78a75eb4cfn%40googlegroups.com.

Re: [weewx-user] Problem with WeeWX5 "driver" directory

[gjr80]

Where is awekas.zip? is it in ~/weewx-data ? Previously you named your 
extension package AWEKAS.zip not awekas.zip, did you change names or are 
you still using AWEKAS.zip? If so you need weectl extension install 
AWEKAS.zip not weectl extension install awekas.zip.

Gary
On Thursday 29 February 2024 at 19:00:48 UTC+10 remy.l...@gmail.com wrote:

> Yesss ! Thank's Gary!!! We progress... :-)))
>
> BUT... :-(((
> Now with *from weecfg.extension import ExtensionInstaller or from setup 
> import ExtensionInstaller the error* in install.py, the error is :
>
>  (weewx-venv) remy@remy-virtual-machine:~/weewx-data$ weectl extension 
> install awekas.zip
> Using configuration file /home/remy/weewx-data/weewx.conf
> Install extension 'awekas.zip' (y/n)? y
>
> Traceback (most recent call last):
>   File "/home/remy/weewx-venv/bin/weectl", line 8, in 
> sys.exit(main())
>   File "/home/remy/weewx-venv/lib/python3.8/site-packages/weectl.py", line 
> 66, in main
> namespace.func(namespace)
>   File 
> "/home/remy/weewx-venv/lib/python3.8/site-packages/weectllib/__init__.py", 
> line 121, in dispatch
> namespace.action_func(config_dict, namespace)
>   File 
> "/home/remy/weewx-venv/lib/python3.8/site-packages/weectllib/extension_cmd.py",
>  
> line 116, in install_extension
> ext.install_extension(namespace.source, no_confirm=namespace.yes)
>   File 
> "/home/remy/weewx-venv/lib/python3.8/site-packages/weecfg/extension.py", 
> line 143, in install_extension
> raise InstallError(f"Unrecognized type for {extension_path}")
> weecfg.extension.InstallError: Unrecognized type for awekas.zip
>
> Le jeudi 29 février 2024 à 09:35:50 UTC+1, gjr80 a écrit :
>
>> On Thursday 29 February 2024 at 17:50:33 UTC+10 remy.l...@gmail.com 
>> wrote:
>>
>> *with* :  unzip -l AWEKAS.zip 
>> *we have* :
>> (weewx-venv) remy@remy-virtual-machine:~/weewx-data$ unzip -l AWEKAS.zip
>> Archive:  AWEKAS.zip
>>   Length  DateTimeName
>> -  -- -   
>> 0  2024-02-29 08:42   AWEKAS/
>>   565  2024-02-29 08:42   AWEKAS/install.py
>> 35149  2024-02-26 10:33   AWEKAS/LICENSE.txt
>> 56528  2024-02-26 10:33   AWEKAS*/awekaswx.py*
>> - ---
>> 92242 4 files
>>
>>
>> And there is your problem, the structure of your extension 
>> package/archive does not agree with the instructions you have given to the 
>> installer. The line:
>>
>> files=[('bin/user', ['bin/user/awekaswx.py'])],
>>
>> in your installer is telling the extension installer to copy the file 
>> awekaswx.py from the bin/user directory in your extension 
>> package/archive to the WeeWX bin/user directory. The problem is 
>> bin/user/awekaswx.py does not exist in your archive, you have awekaswx.py 
>> in the main directory (AWEKAS) of your archive.
>>
>> Take for example the Ecowitt gateway driver extension package, its 
>> structure is:
>>
>> gary@cockatoo1:~ $ unzip -l ./gw1000.zip
>> Archive:  ./gw1000.zip
>>
>>   Length  DateTimeName
>> -  -- -   
>> 0  2024-02-21 19:39   gw1000/bin/
>> 0  2024-02-21 19:39   gw1000/bin/user/
>>  6148  2024-02-11 20:14   gw1000/bin/user/.DS_Store
>>390698  2024-02-21 19:39   gw1000/bin/user/gw1000.py
>>  8355  2024-02-21 19:39   gw1000/changelog
>> 4  2024-02-21 19:39   gw1000/install.py
>> 11346  2024-02-21 19:39   gw1000/readme.txt
>> - ---
>>
>> The extension installer has the same line:
>>
>> files=[('bin/user', ['bin/user/gw1000.py'])],
>>  
>> (well the same but of course a different file name). Note 
>> bin/user/gw1000.py exists in the extension package/extension. 
>>
>>  To fix you have two choices, change the files = line in your extension 
>> installer or change the structure of your extension package/archive. I 
>> favour the latter, it keeps the structure of the extension package more 
>> akin to the WeeWX file structure and avoids the 'put everything in one 
>> directory' approach. Your choice.
>>
>> Gary
>>
>>
>>

-- 
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/f3996539-b321-4993-a02e-2c1b0c47b161n%40googlegroups.com.

Re: [weewx-user] Problem with WeeWX5 "driver" directory

[gjr80]

On Thursday 29 February 2024 at 17:50:33 UTC+10 remy.l...@gmail.com wrote:

*with* :  unzip -l AWEKAS.zip 
*we have* :
(weewx-venv) remy@remy-virtual-machine:~/weewx-data$ unzip -l AWEKAS.zip
Archive:  AWEKAS.zip
  Length  DateTimeName
-  -- -   
0  2024-02-29 08:42   AWEKAS/
  565  2024-02-29 08:42   AWEKAS/install.py
35149  2024-02-26 10:33   AWEKAS/LICENSE.txt
56528  2024-02-26 10:33   AWEKAS*/awekaswx.py*
- ---
92242 4 files


And there is your problem, the structure of your extension package/archive 
does not agree with the instructions you have given to the installer. The 
line:

files=[('bin/user', ['bin/user/awekaswx.py'])],

in your installer is telling the extension installer to copy the file 
awekaswx.py from the bin/user directory in your extension package/archive 
to the WeeWX bin/user directory. The problem is bin/user/awekaswx.py does 
not exist in your archive, you have awekaswx.py in the main directory (
AWEKAS) of your archive.

Take for example the Ecowitt gateway driver extension package, its 
structure is:

gary@cockatoo1:~ $ unzip -l ./gw1000.zip
Archive:  ./gw1000.zip
  Length  DateTimeName
-  -- -   
0  2024-02-21 19:39   gw1000/bin/
0  2024-02-21 19:39   gw1000/bin/user/
 6148  2024-02-11 20:14   gw1000/bin/user/.DS_Store
   390698  2024-02-21 19:39   gw1000/bin/user/gw1000.py
 8355  2024-02-21 19:39   gw1000/changelog
4  2024-02-21 19:39   gw1000/install.py
11346  2024-02-21 19:39   gw1000/readme.txt
- ---

The extension installer has the same line:

files=[('bin/user', ['bin/user/gw1000.py'])],
 
(well the same but of course a different file name). Note bin/user/gw1000.py 
exists in the extension package/extension. 

 To fix you have two choices, change the files = line in your extension 
installer or change the structure of your extension package/archive. I 
favour the latter, it keeps the structure of the extension package more 
akin to the WeeWX file structure and avoids the 'put everything in one 
directory' approach. Your choice.

Gary


-- 
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/8530a29f-f788-462c-81cc-566982a9540fn%40googlegroups.com.

Re: [weewx-user] Problem with WeeWX5 "driver" directory

[gjr80]

I thought we were trying to solve the OPs problem? The OPs problem has 
nothing to do with setuptools (or perhaps more correctly the python 
distutils package); setuptools/distutils is not used in the OPs installer 
and there is no error re distutils in the provided console output. If the 
absence of setuptools/distutils was the issue the error trace would clearly 
identify this.

Sure, I have used distutils in my installers and when run on a system where 
the in-use python version no longer includes distutils (python 3.12 and 
later) the installer will fail - as you found with StackedWindRose.

Gary
On Thursday 29 February 2024 at 13:13:45 UTC+10 vince wrote:

> Dunno Gary but I had to install that for StackedWindRose to get v5 pip to 
> install it successfully here.  Details on the issue I opened on your github 
> repo.
>
> On Wednesday, February 28, 2024 at 5:56:14 PM UTC-8 gjr80 wrote:
>
>> Not quite sure of the relevance of setuptools; if that was the problem 
>> here it would be VERY evident.
>>
>> Gary
>>
>>
>> On Thursday 29 February 2024 at 11:26:15 UTC+10 vince wrote:
>>
>> I found an old extension of Gary’s the other day that needed setuptools 
>> to be able to install it…it has the same old syntax…
>>
>> On Wednesday, February 28, 2024 at 4:52:49 PM UTC-8 Tom Keffer wrote:
>>
>> I haven't tried it, but I'm thinking the problem is that the awekas 
>> extension uses
>>
>> *from setup import ExtensionInstaller*
>>
>>
>> which has been deprecated for a long time and will no longer work with 
>> V5. It should be
>>
>> *from weecfg.extension import ExtensionInstaller*
>>
>>
>> Try modifying the extension and see if that helps.
>>
>> On Wed, Feb 28, 2024 at 12:32 AM gjr80  wrote:
>>
>> What does unzip -l AWEKAS.zip show? Does bin/user/awekaswx.py actually 
>> exist in the zip file?
>>
>> Gary
>> On Wednesday 28 February 2024 at 17:54:49 UTC+10 remy.l...@gmail.com 
>> wrote:
>>
>> Hello Tom,
>> First problem : when trying to install a driver in virtual environnement :
>>
>> (weewx-venv) remy@remy-virtual-machine:~/weewx-data$ weectl extension 
>> install AWEKAS.zip
>> Using configuration file /home/remy/weewx-data/weewx.conf
>> Install extension 'AWEKAS.zip' (y/n)? y
>> Extracting from zip archive AWEKAS.zip
>> Traceback (most recent call last):
>>   File "/home/remy/weewx-venv/bin/weectl", line 8, in 
>> sys.exit(main())
>>   File "/home/remy/weewx-venv/lib/python3.8/site-packages/weectl.py", 
>> line 66, in main
>> namespace.func(namespace)
>>   File 
>> "/home/remy/weewx-venv/lib/python3.8/site-packages/weectllib/__init__.py", 
>> line 121, in dispatch
>> namespace.action_func(config_dict, namespace)
>>   File 
>> "/home/remy/weewx-venv/lib/python3.8/site-packages/weectllib/extension_cmd.py",
>>  
>> line 116, in install_extension
>> ext.install_extension(namespace.source, no_confirm=namespace.yes)
>>   File 
>> "/home/remy/weewx-venv/lib/python3.8/site-packages/weecfg/extension.py", 
>> line 138, in install_extension
>> extension_name = self._install_from_file(extension_path, filetype)
>>   File 
>> "/home/remy/weewx-venv/lib/python3.8/site-packages/weecfg/extension.py", 
>> line 168, in _install_from_file
>> extension_name = self.install_from_dir(extension_dir)
>>   File 
>> "/home/remy/weewx-venv/lib/python3.8/site-packages/weecfg/extension.py", 
>> line 185, in install_from_dir
>> self._install_files(installer['files'], extension_dir)
>>   File 
>> "/home/remy/weewx-venv/lib/python3.8/site-packages/weecfg/extension.py", 
>> line 269, in _install_files
>> shutil.copy(source_path, destination_path)
>>   File "/usr/lib/python3.8/shutil.py", line 418, in copy
>> copyfile(src, dst, follow_symlinks=follow_symlinks)
>>   File "/usr/lib/python3.8/shutil.py", line 264, in copyfile
>> with open(src, 'rb') as fsrc, open(dst, 'wb') as fdst:
>> FileNotFoundError: [Errno 2] No such file or directory: 
>> '/tmp/tmprpxo6tw5/AWEKAS/bin/user/awekaswx.py'
>>
>> *and the install.py :*
>>
>> # installer for Awekas Bresser awekaswx driver
>> # Copyright 2024 Remy LAVABRE
>>
>> from setup import ExtensionInstaller
>>
>> def loader():
>> return awekaswxInstaller()
>>
>> class awekaswxInstaller(ExtensionInstaller):

Re: [weewx-user] Problem with WeeWX5 "driver" directory

[gjr80]

Not quite sure of the relevance of setuptools; if that was the problem here 
it would be VERY evident.

Gary

On Thursday 29 February 2024 at 11:26:15 UTC+10 vince wrote:

I found an old extension of Gary’s the other day that needed setuptools to 
be able to install it…it has the same old syntax…

On Wednesday, February 28, 2024 at 4:52:49 PM UTC-8 Tom Keffer wrote:

I haven't tried it, but I'm thinking the problem is that the awekas 
extension uses

*from setup import ExtensionInstaller*


which has been deprecated for a long time and will no longer work with V5. 
It should be

*from weecfg.extension import ExtensionInstaller*


Try modifying the extension and see if that helps.

On Wed, Feb 28, 2024 at 12:32 AM gjr80  wrote:

What does unzip -l AWEKAS.zip show? Does bin/user/awekaswx.py actually 
exist in the zip file?

Gary
On Wednesday 28 February 2024 at 17:54:49 UTC+10 remy.l...@gmail.com wrote:

Hello Tom,
First problem : when trying to install a driver in virtual environnement :

(weewx-venv) remy@remy-virtual-machine:~/weewx-data$ weectl extension 
install AWEKAS.zip
Using configuration file /home/remy/weewx-data/weewx.conf
Install extension 'AWEKAS.zip' (y/n)? y
Extracting from zip archive AWEKAS.zip
Traceback (most recent call last):
  File "/home/remy/weewx-venv/bin/weectl", line 8, in 
sys.exit(main())
  File "/home/remy/weewx-venv/lib/python3.8/site-packages/weectl.py", line 
66, in main
namespace.func(namespace)
  File 
"/home/remy/weewx-venv/lib/python3.8/site-packages/weectllib/__init__.py", 
line 121, in dispatch
namespace.action_func(config_dict, namespace)
  File 
"/home/remy/weewx-venv/lib/python3.8/site-packages/weectllib/extension_cmd.py", 
line 116, in install_extension
ext.install_extension(namespace.source, no_confirm=namespace.yes)
  File 
"/home/remy/weewx-venv/lib/python3.8/site-packages/weecfg/extension.py", 
line 138, in install_extension
extension_name = self._install_from_file(extension_path, filetype)
  File 
"/home/remy/weewx-venv/lib/python3.8/site-packages/weecfg/extension.py", 
line 168, in _install_from_file
extension_name = self.install_from_dir(extension_dir)
  File 
"/home/remy/weewx-venv/lib/python3.8/site-packages/weecfg/extension.py", 
line 185, in install_from_dir
self._install_files(installer['files'], extension_dir)
  File 
"/home/remy/weewx-venv/lib/python3.8/site-packages/weecfg/extension.py", 
line 269, in _install_files
shutil.copy(source_path, destination_path)
  File "/usr/lib/python3.8/shutil.py", line 418, in copy
copyfile(src, dst, follow_symlinks=follow_symlinks)
  File "/usr/lib/python3.8/shutil.py", line 264, in copyfile
with open(src, 'rb') as fsrc, open(dst, 'wb') as fdst:
FileNotFoundError: [Errno 2] No such file or directory: 
'/tmp/tmprpxo6tw5/AWEKAS/bin/user/awekaswx.py'

*and the install.py :*

# installer for Awekas Bresser awekaswx driver
# Copyright 2024 Remy LAVABRE

from setup import ExtensionInstaller

def loader():
return awekaswxInstaller()

class awekaswxInstaller(ExtensionInstaller):
def __init__(self):
super(awekaswxInstaller, self).__init__(
version="1.3",
name='awekaswx',
description='Get Bresser 7in1 data on Awekas',
author="Remy LAVABRE",
author_email="remy.l...@gmail.com",
files=[('bin/user', ['bin/user/awekaswx.py'])],
config={
'awekaswx': {
'driver' : 'bin.user.awekaswx',
'poll_interval': '60',
'awekasapikey' :'My_API_Awekas_Key','
'openweatherapikey': 'My_API_OpenWeather_Key',
'send_syslog': 'True',
'model': 'Bresser 7in1'
}
}
)

*Rémy LAVABRE*


Le dim. 25 févr. 2024 à 22:45, Tom Keffer  a écrit :

>From your description, you're installing it in the correct spot, however 
you're not giving us much information. Instead of just showing the single 
error line, it would be helpful to see the log from startup. The reason is 
that it will log the location of the user directory.

Set debug=1, then restart weewxd. Post the log *from startup* through the 
error.

On Sun, Feb 25, 2024 at 10:55 AM Remy Lavabre  wrote:

Hello,

weewx is installed in virtual PIP mode -> ~/weewx-data/... and 
~/weewx-venv/...
I manually added the xxx.py driver for my weather station in the 
~/weewx-data/bin/user directory.
It is declared in weewx.conf as "driver = usr.xxx", as was done in version 
4.x

When launching weewxd, I get the message:
   File "/h

Re: [weewx-user] Problem with WeeWX5 "driver" directory

[gjr80]

Not quite sure this is the problem, as far as I know the following gives 
backward compatibility with setup.ExtensionInstaller:

# Very old extensions did:
#   from setup import ExtensionInstaller
# Redirect references to 'setup' to me instead.
sys.modules['setup'] = sys.modules[__name__]

Plus I am still using the old style in the Ecowitt driver installer which 
works just fine under v5 and python 3.6+.

Gary
On Thursday 29 February 2024 at 10:52:49 UTC+10 tke...@gmail.com wrote:

> I haven't tried it, but I'm thinking the problem is that the awekas 
> extension uses
>
> *from setup import ExtensionInstaller*
>
>
> which has been deprecated for a long time and will no longer work with V5. 
> It should be
>
> *from weecfg.extension import ExtensionInstaller*
>
>
> Try modifying the extension and see if that helps.
>
> On Wed, Feb 28, 2024 at 12:32 AM gjr80  wrote:
>
>> What does unzip -l AWEKAS.zip show? Does bin/user/awekaswx.py actually 
>> exist in the zip file?
>>
>> Gary
>> On Wednesday 28 February 2024 at 17:54:49 UTC+10 remy.l...@gmail.com 
>> wrote:
>>
>>> Hello Tom,
>>> First problem : when trying to install a driver in virtual 
>>> environnement :
>>>
>>> (weewx-venv) remy@remy-virtual-machine:~/weewx-data$ weectl extension 
>>> install AWEKAS.zip
>>> Using configuration file /home/remy/weewx-data/weewx.conf
>>> Install extension 'AWEKAS.zip' (y/n)? y
>>> Extracting from zip archive AWEKAS.zip
>>> Traceback (most recent call last):
>>>   File "/home/remy/weewx-venv/bin/weectl", line 8, in 
>>> sys.exit(main())
>>>   File "/home/remy/weewx-venv/lib/python3.8/site-packages/weectl.py", 
>>> line 66, in main
>>> namespace.func(namespace)
>>>   File 
>>> "/home/remy/weewx-venv/lib/python3.8/site-packages/weectllib/__init__.py", 
>>> line 121, in dispatch
>>> namespace.action_func(config_dict, namespace)
>>>   File 
>>> "/home/remy/weewx-venv/lib/python3.8/site-packages/weectllib/extension_cmd.py",
>>>  
>>> line 116, in install_extension
>>> ext.install_extension(namespace.source, no_confirm=namespace.yes)
>>>   File 
>>> "/home/remy/weewx-venv/lib/python3.8/site-packages/weecfg/extension.py", 
>>> line 138, in install_extension
>>> extension_name = self._install_from_file(extension_path, filetype)
>>>   File 
>>> "/home/remy/weewx-venv/lib/python3.8/site-packages/weecfg/extension.py", 
>>> line 168, in _install_from_file
>>> extension_name = self.install_from_dir(extension_dir)
>>>   File 
>>> "/home/remy/weewx-venv/lib/python3.8/site-packages/weecfg/extension.py", 
>>> line 185, in install_from_dir
>>> self._install_files(installer['files'], extension_dir)
>>>   File 
>>> "/home/remy/weewx-venv/lib/python3.8/site-packages/weecfg/extension.py", 
>>> line 269, in _install_files
>>> shutil.copy(source_path, destination_path)
>>>   File "/usr/lib/python3.8/shutil.py", line 418, in copy
>>> copyfile(src, dst, follow_symlinks=follow_symlinks)
>>>   File "/usr/lib/python3.8/shutil.py", line 264, in copyfile
>>> with open(src, 'rb') as fsrc, open(dst, 'wb') as fdst:
>>> FileNotFoundError: [Errno 2] No such file or directory: 
>>> '/tmp/tmprpxo6tw5/AWEKAS/bin/user/awekaswx.py'
>>>
>>> *and the install.py :*
>>>
>>> # installer for Awekas Bresser awekaswx driver
>>> # Copyright 2024 Remy LAVABRE
>>>
>>> from setup import ExtensionInstaller
>>>
>>> def loader():
>>> return awekaswxInstaller()
>>>
>>> class awekaswxInstaller(ExtensionInstaller):
>>> def __init__(self):
>>> super(awekaswxInstaller, self).__init__(
>>> version="1.3",
>>> name='awekaswx',
>>> description='Get Bresser 7in1 data on Awekas',
>>> author="Remy LAVABRE",
>>> author_email="remy.l...@gmail.com",
>>> files=[('bin/user', ['bin/user/awekaswx.py'])],
>>> config={
>>> 'awekaswx': {
>>> 'driver' : 'bin.user.awekaswx',
>>> 'poll_interval': '60',
>&g

[weewx-user] Re: WeeWx Upgrade from v4 to v5

[gjr80]

The post with the log that shows the error was deleted ?

This look suspiciously like this problem 
. Did 
you some time in the past remove seemingly unused settings from 
[DisplayOptions] in the Seasons skin.conf? It seems that v5 is more 
sensitive to these settings.

GHary

-- 
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/8a0f51f1-d932-4e99-bd0b-6fc53da2a084n%40googlegroups.com.

[weewx-user] Re: WeeWx Upgrade from v4 to v5

[gjr80]

Impossible to say without a log extract 

.

Gary

On Thursday 29 February 2024 at 07:00:21 UTC+10 debbiep...@gmail.com wrote:

> Have a strange problem after upgrading working WeeWx from v4 to v5
>
> See attached .JPG screen shot...
> If you look closely, you can see the standard Graphs still being updated 
> HOWEVER the Left Column of weather information has not been updated since 
> 9:10AM today - it's now 3PM as I write this.  Am using the Tempest driver 
> (works great on v4) can't figure out what I need to (also update?) to make 
> WeeWx v5 update about every 5 minutes.
>
> Any hints?  Anybody else having upgrade issues from v4 to v5?
>
> -pete[image: Weewx-Upgrade.JPG]
>

-- 
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/9e54ad39-7b8a-4248-963c-4b06ff858dd0n%40googlegroups.com.

Re: [weewx-user] Problem with WeeWX5 "driver" directory

[gjr80]

What does unzip -l AWEKAS.zip show? Does bin/user/awekaswx.py actually 
exist in the zip file?

Gary
On Wednesday 28 February 2024 at 17:54:49 UTC+10 remy.l...@gmail.com wrote:

> Hello Tom,
> First problem : when trying to install a driver in virtual environnement :
>
> (weewx-venv) remy@remy-virtual-machine:~/weewx-data$ weectl extension 
> install AWEKAS.zip
> Using configuration file /home/remy/weewx-data/weewx.conf
> Install extension 'AWEKAS.zip' (y/n)? y
> Extracting from zip archive AWEKAS.zip
> Traceback (most recent call last):
>   File "/home/remy/weewx-venv/bin/weectl", line 8, in 
> sys.exit(main())
>   File "/home/remy/weewx-venv/lib/python3.8/site-packages/weectl.py", line 
> 66, in main
> namespace.func(namespace)
>   File 
> "/home/remy/weewx-venv/lib/python3.8/site-packages/weectllib/__init__.py", 
> line 121, in dispatch
> namespace.action_func(config_dict, namespace)
>   File 
> "/home/remy/weewx-venv/lib/python3.8/site-packages/weectllib/extension_cmd.py",
>  
> line 116, in install_extension
> ext.install_extension(namespace.source, no_confirm=namespace.yes)
>   File 
> "/home/remy/weewx-venv/lib/python3.8/site-packages/weecfg/extension.py", 
> line 138, in install_extension
> extension_name = self._install_from_file(extension_path, filetype)
>   File 
> "/home/remy/weewx-venv/lib/python3.8/site-packages/weecfg/extension.py", 
> line 168, in _install_from_file
> extension_name = self.install_from_dir(extension_dir)
>   File 
> "/home/remy/weewx-venv/lib/python3.8/site-packages/weecfg/extension.py", 
> line 185, in install_from_dir
> self._install_files(installer['files'], extension_dir)
>   File 
> "/home/remy/weewx-venv/lib/python3.8/site-packages/weecfg/extension.py", 
> line 269, in _install_files
> shutil.copy(source_path, destination_path)
>   File "/usr/lib/python3.8/shutil.py", line 418, in copy
> copyfile(src, dst, follow_symlinks=follow_symlinks)
>   File "/usr/lib/python3.8/shutil.py", line 264, in copyfile
> with open(src, 'rb') as fsrc, open(dst, 'wb') as fdst:
> FileNotFoundError: [Errno 2] No such file or directory: 
> '/tmp/tmprpxo6tw5/AWEKAS/bin/user/awekaswx.py'
>
> *and the install.py :*
>
> # installer for Awekas Bresser awekaswx driver
> # Copyright 2024 Remy LAVABRE
>
> from setup import ExtensionInstaller
>
> def loader():
> return awekaswxInstaller()
>
> class awekaswxInstaller(ExtensionInstaller):
> def __init__(self):
> super(awekaswxInstaller, self).__init__(
> version="1.3",
> name='awekaswx',
> description='Get Bresser 7in1 data on Awekas',
> author="Remy LAVABRE",
> author_email="remy.l...@gmail.com",
> files=[('bin/user', ['bin/user/awekaswx.py'])],
> config={
> 'awekaswx': {
> 'driver' : 'bin.user.awekaswx',
> 'poll_interval': '60',
> 'awekasapikey' :'My_API_Awekas_Key','
> 'openweatherapikey': 'My_API_OpenWeather_Key',
> 'send_syslog': 'True',
> 'model': 'Bresser 7in1'
> }
> }
> )
>
> *Rémy LAVABRE*
>
>
> Le dim. 25 févr. 2024 à 22:45, Tom Keffer  a écrit :
>
>> From your description, you're installing it in the correct spot, however 
>> you're not giving us much information. Instead of just showing the single 
>> error line, it would be helpful to see the log from startup. The reason is 
>> that it will log the location of the user directory.
>>
>> Set debug=1, then restart weewxd. Post the log *from startup* through 
>> the error.
>>
>> On Sun, Feb 25, 2024 at 10:55 AM Remy Lavabre  
>> wrote:
>>
>>> Hello,
>>>
>>> weewx is installed in virtual PIP mode -> ~/weewx-data/... and 
>>> ~/weewx-venv/...
>>> I manually added the xxx.py driver for my weather station in the 
>>> ~/weewx-data/bin/user directory.
>>> It is declared in weewx.conf as "driver = usr.xxx", as was done in 
>>> version 4.x
>>>
>>> When launching weewxd, I get the message:
>>>File 
>>> "/home/pi/weewx-venv/lib/python3.8/site-packages/weewx/engine.py", line 
>>> 104, in setupStation
>>>  __import__(driver)
>>> ModuleNotFoundError: *No module named 'usr'*
>>>
>>> I tried "driver = xxx.py" without success
>>>
>>> if I put my driver in 
>>> ~/weewx-venv/lib/python3.8/site-packages/weewx/drivers/xxx.py and I put 
>>> driver = xxx.py in weewx.conf there is no longer the error.
>>>
>>> Moral: Would it be possible to tell me the exact location where to put 
>>> my driver in the user directory and how to declare it in weewx.conf ?
>>>
>>> Thank you...
>>>
>>> -- 
>>> 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/

[weewx-user] Re: WeeWX 5.0.2 voltages with 6 digits after the decimal point

[gjr80]

The problem is WeeWX does not know whether your sensor battery fields are 
temperatures, pressures or voltages etc so WeeWX presents the data as it 
comes out of the database and with no units labels. To have WeeWX take care 
of formatting and unit labels each field needs to be assigned to a WeeWX 
unit group, the Ecowitt gateway driver does this automatically for all 
WeeWX fields in the default file map, but if you decide to change the field 
mapping you are responsible for making the unit group assignments yourself. 
There are a number of ways you can do this, but the easiest is to add a few 
lines of code to bin/user/extensions.py (the location of 
bin/user/extensions.py is dependent on how you installed WeeWX, refer to 
Location 
of WeeWX components 
<http://weewx.com/docs/5.0/usersguide/where/#location-of-weewx-components> 
in the User's Guide). Try adding the following to extensions.py:

import weewx.units
weewx.units.obs_group_dict['soilMoistBattx'] = 'group_volt'

add a weewx.units.obs_group_dict entry for each field you have added. Once 
you have made the changes save extensions.py and restart WeeWX. WeeWX will 
then apply the default group_voltage formatting and unit labelling for your 
sensor battery fields.

Gary
On Wednesday 28 February 2024 at 03:20:55 UTC+10 mike.g...@gmail.com wrote:

> Hello.
>
> I have a clean Debian 12 and WeeWX 5.0.2 installation and am currently 
> configuring the ecowitt devices (GW1100, WH65, WH51, WH31, WN34, WH55 and 
> WH57). 
>
> I am using the Ecowitt Gateway v0.6.1 from gjr80 as the driver.
>
> The voltages of soilTemp and soilMoist should be displayed under " 
> Sensors". 
> The missing columns "soilMoistBattx" and "soilTempBattx" have been added 
> to the SQL database. 
>
> Now the voltages on the left are displayed with 6 digits after the decimal 
> point. 
> The driver and the graphics on the right correctly show 2 digits after the 
> decimal point. 
>
> Whats wrong? How can I fix this?
>
> Greetings, Mike
>
> [image: Screenshot 2024-02-22 at 12-36-32 Test City.png]
>

-- 
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/eeb3049b-c4ca-4438-a212-b99aee2c2420n%40googlegroups.com.

[weewx-user] Re: Weewx don't work anymore after SD card restore, I don't know why?

[gjr80]

On Thursday 22 February 2024 at 00:57:58 UTC+10 Thomas Hackler wrote:

Do you mean that I should change this part in my weewx.conf:

[[StandardReport]]
skin = neowx-material

in

[Neowx-Material-Report]]
skin = neowx-material


Yes, the actual name is unimportant, but something descriptive will be 
useful when reading logs etc in the future.(I note a missing '[', I am 
guessing this is a copy/paste issue)
 

Weewx will have no problem that there is no entrance [[StandardReport]] 
anymore ?


No problem at all. WeeWX has no particular requirements of report stanza 
names other than within a given [StdReport] stanza the report names must be 
unique. Convention is to give the report a meaningful name, usually 
something that relates to the skin being used or purpose of the report.
 

the reason of the different driver version could be that I got this driver 
from a german weather station forum and it is not a one from you.

https://www.pc-wetterstation.de/forum/viewtopic.php?f=26&t=10333

not all sensors where supported in the past and so this modified version 
were made


No problem, I was merely pointing out that the version of the driver being 
used appears to be based on the v0.4.2 driver, but the current driver 
version is v0.6.0 (actually v0.6.1 as of yesterday). There have been a 
number of bug fixes and new features introduced since v0.4.2, but knowing 
nothing about v0.4.2KW I suggested that you might want to find a more 
recent version from whatever source you wish.


I plan to install a complete new and clean system for my raspberry pi, then 
I would go further with driver version 0.6.0
I hope that this cause no problems with the database and all the things


Unlikely to be any problems, though if extra sensors were added to v0.4.2KW 
and they use a different naming convention/default mapping compared to the 
same sensors in say v0.6.1 then there could be issues. It really depends on 
what 'extras'  were added to v0.4.2KW.

Gary

-- 
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/6a23a0a0-6333-47fd-9584-2eb23e326ec6n%40googlegroups.com.

[weewx-user] Re: Weewx don't work anymore after SD card restore, I don't know why?

[gjr80]

That is a very good log extract. From that extract WeeWX seems to be 
running just fine with no errors. The lines similar to:
Feb 18 21:05:40 raspberrypi weewxd[35139]: DEBUG weewx.reportengine: Cannot 
read localization file /etc/weewx/skins/neowx-material/lang/en.conf for 
report 'StandardReport': Config file not found: 
"/etc/weewx/skins/neowx-material/lang/en.conf".
Feb 18 21:05:40 raspberrypi weewxd[35139]: DEBUG weewx.reportengine:  
Using defaults instead.
mean than an English language config file could not be found and the 
defaults are being used instead. If your skin files are being generated in 
the correct language you can ignore this.

The neowx-material SyntaxWarnings are exactly that, a warning and do not 
appear to be causing a problem. If they are causing a problem then you 
should take this up with the neowx-material author.

If your system is running error free and you are having problems viewing 
current pages/plots in a browser the first thing to do is to clear the 
browser cache. How you do this varies from browser to browser.

A few additional comments. First you seem to have the neowx-material skin 
being run under the StandardReport report. This is not a problem as the 
report name merely needs to be a unique (compared to other report names) 
string. However, considering that WeeWX ships with a skin called Standard 
that is run under a report named StandardReport you might find it less 
confusing (especially if you need outside help in the future) to give the 
report that runs the neowx-material skin a more descriptive name, eg 
Neowx-MaterialReport.

The order of your enabled reports under [StdReport] in weewx.conf appears 
to be SeasonsReport, FTP, StandardReport (which runs the neowx-material 
skin). Again this runs without error, but it means you Seasons skin files 
are generated, your files are uploaded by FTP then the neowx-material skin 
files are generated. The result is that when the FTP report uploads your 
files it uploads the just generated Seasons skin file, but it then uploads 
the previously generated neowx-material skin files. In other words, on you 
web server you will see the current Seasons skin files but your 
neowx-material files will always be at least five minutes old. Under 
[StdReport] the order of the report stanzas matters. I suspect you would be 
better off changing the order of your enabled reports to SeasonsReport, 
StandardReport,FTP.

Finally, your driver version is 0.4.2KW, I have no idea where you sourced 
this driver from as I have never released such a version and have no idea 
what modifications may have been made to the driver. The current Ecowitt 
gateway (nee GW1000) driver is v0.6.0, so depending on your requirements 
you might want source a more up to date version.

Gary
On Monday 19 February 2024 at 06:26:07 UTC+10 Thomas Hackler wrote:

> Thomas Hackler schrieb am Sonntag, 18. Februar 2024 um 21:25:40 UTC+1:
>
>> ok thanks, I was not ready for version 5 and start reading the docs
>> attached there is a 15 minutes log, I guess now is everything working
>> My edge browser didn't show me the actual pictures from the season skin, 
>> neo wx is working
>> but firefox show me both
>> thanks for the support and documentation (helps to learn a lot)
>>
>> gjr80 schrieb am Sonntag, 18. Februar 2024 um 11:01:53 UTC+1:
>>
>>> A couple of things. First, you appear to be using systemd and if you 
>>> are running a WeeWX v5 Debian install you should be using systemctl 
>>> <http://weewx.com/docs/5.0/usersguide/running/#running-as-a-daemon> and 
>>> to start/stop and otherwise control the WeeWX service.
>>>
>>> Second, your log extract covers just over one minute with WeeWX already 
>>> running. That really is not enough log for us to be of any help. You need 
>>> to capture the full WeeWX startup, this contains important config 
>>> information. You also need a longer log extract, if your archive interval 
>>> is five minutes then we need to see at least 10 minutes of log.
>>>
>>> Gary
>>>
>>> PS. For what it is worth I see no problems in the log extract that was 
>>> posted.
>>> On Sunday 18 February 2024 at 19:13:28 UTC+10 Thomas Hackler wrote:
>>>
>>>> Hello,
>>>> thank you for your help!
>>>> I don't know why but now weewx seems to work again but something is 
>>>> still wrong.
>>>> Attached you can find a complete log file. I had another issue on my Pi 
>>>> which I solved now, I run out of space on the SD card, maybe this effected 
>>>> the access to the gw1000 driver.
>>>> My neo WX skin works, the standard season skin don't show me pictures 
>>>> for today.
>>>> I

[weewx-user] Re: Weewx don't work anymore after SD card restore, I don't know why?

[gjr80]

A couple of things. First, you appear to be using systemd and if you are 
running a WeeWX v5 Debian install you should be using systemctl 
<http://weewx.com/docs/5.0/usersguide/running/#running-as-a-daemon> and to 
start/stop and otherwise control the WeeWX service.

Second, your log extract covers just over one minute with WeeWX already 
running. That really is not enough log for us to be of any help. You need 
to capture the full WeeWX startup, this contains important config 
information. You also need a longer log extract, if your archive interval 
is five minutes then we need to see at least 10 minutes of log.

Gary

PS. For what it is worth I see no problems in the log extract that was 
posted.
On Sunday 18 February 2024 at 19:13:28 UTC+10 Thomas Hackler wrote:

> Hello,
> thank you for your help!
> I don't know why but now weewx seems to work again but something is still 
> wrong.
> Attached you can find a complete log file. I had another issue on my Pi 
> which I solved now, I run out of space on the SD card, maybe this effected 
> the access to the gw1000 driver.
> My neo WX skin works, the standard season skin don't show me pictures for 
> today.
> If I use these commandos there is no reaction in syslog:
>
> sudo /etc/init.d/weewx start 
> sudo /etc/init.d/weewx stop 
> sudo /etc/init.d/weewx restart
>
> i cannot start or stop weewx.
>
> I think with the permissions everything is ok?
>
> pi@raspberrypi:~ $ groups
> pi adm dialout cdrom sudo audio video plugdev games users input render 
> netdev lpadmin weewx gpio i2c spi iobroker
>
> pi@raspberrypi:~ $ grep User /usr/lib/systemd/system/weewx.service
> User=weewx
>
> After I restored the SD card with my old image from January I replaced the 
> weewx.sdb with the newer one, but this should have no effect or not ?
>
> Do you need more information ?
>
>
> gjr80 schrieb am Sonntag, 18. Februar 2024 um 02:04:29 UTC+1:
>
>> Your Ecowitt gateway driver issue is that the driver is unable to contact 
>> your gateway device, this is causing WeeWX to exit. This could be due to 
>> any number of reasons, it's impossible to say much more without seeing the 
>> full log from startup to failure. Refer to the How to get a good, useful 
>> log section 
>> <https://github.com/weewx/weewx/wiki/Help!-Posting-to-weewx-user#how-to-get-a-good-useful-log>
>>  
>> of the Help! Posting to weewx-user Wiki page 
>> <https://github.com/weewx/weewx/wiki/Help!-Posting-to-weewx-user> for 
>> how to get a good log extract. Note that you will likely need to use the 
>> instructions for journalctl rather than syslog.
>>
>> Gary
>> On Saturday 17 February 2024 at 19:58:48 UTC+10 Thomas Hackler wrote:
>>
>>> I am sorry:
>>>
>>> pi@raspberrypi:~ $ systemctl status weewx
>>> ● weewx.service - WeeWX
>>>  Loaded: loaded (/lib/systemd/system/weewx.service; enabled; vendor 
>>> preset: enabled)
>>>  Active: failed (Result: exit-code) since Sat 2024-02-17 10:18:36 
>>> CET; 38min ago
>>>
>>>Docs: https://weewx.com/docs
>>> Process: 606 ExecStart=weewxd /etc/weewx/weewx.conf (code=exited, 
>>> status=4)
>>>Main PID: 606 (code=exited, status=4)
>>> CPU: 621ms
>>>
>>> Feb 17 10:18:36 raspberrypi weewxd[606]: CRITICAL weewx.engine:  
>>>  self.mac = self.get_mac_address()
>>> Feb 17 10:18:36 raspberrypi weewxd[606]: CRITICAL weewx.engine:  
>>>File "/etc/weewx/bin/user/gw1000.py", line 3625, in get_mac_address
>>> Feb 17 10:18:36 raspberrypi weewxd[606]: CRITICAL weewx.engine:  
>>>  return self.send_cmd_with_retries('CMD_READ_STATION_MAC')
>>> Feb 17 10:18:36 raspberrypi weewxd[606]: CRITICAL weewx.engine:  
>>>File "/etc/weewx/bin/user/gw1000.py", line 3808, in send_cmd_with_retries
>>> Feb 17 10:18:36 raspberrypi weewxd[606]: CRITICAL weewx.engine:  
>>>  raise GW1000IOError(_msg)
>>> Feb 17 10:18:36 raspberrypi weewxd[606]: CRITICAL weewx.engine:  
>>>  user.gw1000.GW1000IOError: Failed to obtain response to command 
>>> 'CMD_READ_STATION_MAC' after 3 attempts
>>> Feb 17 10:18:36 raspberrypi weewxd[606]: CRITICAL __main__: Unable to 
>>> load driver: Failed to obtain response to command 'CMD_READ_STATION_MAC' 
>>> after 3 attempts
>>>
>>> Feb 17 10:18:36 raspberrypi weewxd[606]: CRITICAL __main__:  
>>>  Exiting...
>>> Feb 17 10:18:36 raspberrypi systemd[1]: weewx.service: Main process 
>>

[weewx-user] Re: Weewx don't work anymore after SD card restore, I don't know why?

[gjr80]

Your Ecowitt gateway driver issue is that the driver is unable to contact 
your gateway device, this is causing WeeWX to exit. This could be due to 
any number of reasons, it's impossible to say much more without seeing the 
full log from startup to failure. Refer to the How to get a good, useful 
log section 

 
of the Help! Posting to weewx-user Wiki page 
 for how 
to get a good log extract. Note that you will likely need to use the 
instructions for journalctl rather than syslog.

Gary
On Saturday 17 February 2024 at 19:58:48 UTC+10 Thomas Hackler wrote:

> I am sorry:
>
> pi@raspberrypi:~ $ systemctl status weewx
> ● weewx.service - WeeWX
>  Loaded: loaded (/lib/systemd/system/weewx.service; enabled; vendor 
> preset: enabled)
>  Active: failed (Result: exit-code) since Sat 2024-02-17 10:18:36 CET; 
> 38min ago
>
>Docs: https://weewx.com/docs
> Process: 606 ExecStart=weewxd /etc/weewx/weewx.conf (code=exited, 
> status=4)
>Main PID: 606 (code=exited, status=4)
> CPU: 621ms
>
> Feb 17 10:18:36 raspberrypi weewxd[606]: CRITICAL weewx.engine:    
>self.mac = self.get_mac_address()
> Feb 17 10:18:36 raspberrypi weewxd[606]: CRITICAL weewx.engine:    
>  File "/etc/weewx/bin/user/gw1000.py", line 3625, in get_mac_address
> Feb 17 10:18:36 raspberrypi weewxd[606]: CRITICAL weewx.engine:    
>return self.send_cmd_with_retries('CMD_READ_STATION_MAC')
> Feb 17 10:18:36 raspberrypi weewxd[606]: CRITICAL weewx.engine:    
>  File "/etc/weewx/bin/user/gw1000.py", line 3808, in send_cmd_with_retries
> Feb 17 10:18:36 raspberrypi weewxd[606]: CRITICAL weewx.engine:    
>raise GW1000IOError(_msg)
> Feb 17 10:18:36 raspberrypi weewxd[606]: CRITICAL weewx.engine:  
>  user.gw1000.GW1000IOError: Failed to obtain response to command 
> 'CMD_READ_STATION_MAC' after 3 attempts
> Feb 17 10:18:36 raspberrypi weewxd[606]: CRITICAL __main__: Unable to load 
> driver: Failed to obtain response to command 'CMD_READ_STATION_MAC' after 3 
> attempts
>
> Feb 17 10:18:36 raspberrypi weewxd[606]: CRITICAL __main__:  
>  Exiting...
> Feb 17 10:18:36 raspberrypi systemd[1]: weewx.service: Main process 
> exited, code=exited, status=4/NOPERMISSION
> Feb 17 10:18:36 raspberrypi systemd[1]: weewx.service: Failed with result 
> 'exit-code'.
>
> michael.k...@gmx.at schrieb am Samstag, 17. Februar 2024 um 10:53:49 
> UTC+1:
>
>> It will definitely help if you'd attach the log files as a whole, it
>> see>
>> ms >
>> the>
>>  lo>
>> g ab>
>> ove is not showing all the relevant data.
>> Thomas Hackler schrieb am Samstag, 17. Februar 2024 um 10:41:33 UTC+1:
>>
>>> pi@raspberrypi:~ $ apt policy weewx
>>> weewx:
>>>   Installed: 5.0.2-1
>>>   Candidate: 5.0.2-1
>>>
>>>
>>> Thomas Hackler schrieb am Samstag, 17. Februar 2024 um 10:39:13 UTC+1:
>>>
 here are some more information, something seems to be wrong with the 
 gw1000 driver, but I changed nothing:

 pi@raspberrypi:~ $ systemctl status weewx*
 ● weewx.service - WeeWX
  Loaded: loaded (/lib/systemd/system/weewx.service; enabled; vendor 
 preset:>
  Active: failed (Result: exit-code) since Sat 2024-02-17 10:18:36 
 CET; 17mi>
Docs: https://weewx.com/docs
 Process: 606 ExecStart=weewxd /etc/weewx/weewx.conf (code=exited, 
 status=4)
Main PID: 606 (code=exited, status=4)
 CPU: 621ms

 Feb 17 10:18:36 raspberrypi weewxd[606]: CRITICAL weewx.engine: 
   s>
 Feb 17 10:18:36 raspberrypi weewxd[606]: CRITICAL weewx.engine: 
 Fil>
 Feb 17 10:18:36 raspberrypi weewxd[606]: CRITICAL weewx.engine: 
   r>
 Feb 17 10:18:36 raspberrypi weewxd[606]: CRITICAL weewx.engine: 
 Fil>
 Feb 17 10:18:36 raspberrypi weewxd[606]: CRITICAL weewx.engine: 
   r>
 Feb 17 10:18:36 raspberrypi weewxd[606]: CRITICAL weewx.engine: 
   user.>
 Feb 17 10:18:36 raspberrypi weewxd[606]: CRITICAL __main__: Unable to 
 load driv>
 Feb 17 10:18:36 raspberrypi weewxd[606]: CRITICAL __main__:  
  Exiting...
 Feb 17 10:18:36 raspberrypi systemd[1]: weewx.service: Main process 
 exited, cod>
 Feb 17 10:18:36 raspberrypi systemd[1]: weewx.service: Failed with 
 result 'exit>
 lines 1-18/18 (END)...skipping...
 ● weewx.service - WeeWX
  Loaded: loaded (/lib/systemd/system/weewx.service; enabled; vendor 
 preset: enabled)
  Active: failed (Result: exit-code) since Sat 2024-02-17 10:18:36 
 CET; 17min ago
Docs: https://weewx.com/docs
 Process: 606 ExecStart=weewxd /etc/weewx/weewx.conf (code=exited, 
 status=4)
Main PID: 606 (code=exited, status=4)
 CPU: 621ms

>>

[weewx-user] Re: weewx 5.02 crashes (and restarts) on trying to access a docker file?

[gjr80]

Appreciate you have removed cmon and solved the problem; however, in having 
a more leisurely look at the cmon source I see there already s the ability 
for the user to add mounts to the ignore list via the ignored_mounts config 
option. If the ignore list is not specified by the user the default ignore 
list (hard coded in cmon.py) is used, ignored_mounts is specified then that 
list is used in lieu of the default. Furthermore, when checking a given 
mount point against the ignore list, the check used is whether the mount 
point in question starts with any of the entries in the ignore list. So 
using '/var/lib/docker' in the ignore list *should* work and cause all 
docker overlays to be ignored (the source used by cmon as the mount points 
universe on a system is the contents of /proc/mounts with the mount points 
being the second entry on each line). For info, the entries in the default 
ignore list are '/lib/init/rw', 
'/proc', '/sys', '/dev', '/afs', '/mit', '/run', '/var/lib/nfs'. So 
something like:

[ComputerMonitor]

ignored_mounts = 
'/lib/init/rw', '/proc', '/sys', '/dev', '/afs', '/mit', '/run', 
'/var/lib/nfs', 
'/var/lib/docker'

should work. Note, the apostrophes should not be required but leaving them 
in won't hurt.

My apologies for the earlier mis-information.

Gary

On Thursday 15 February 2024 at 22:47:17 UTC+10 valken...@gmail.com wrote:

> Thanx Gary!
> It didn't cross my mind that cmon scans for mounted file systems. I added 
> /var/lib/docker/overlay2 to the ignore list, but the error persisted. To 
> save me from further troubles I just removed the cmon extension for the 
> time being. I will inform Matthew.
>
> Op donderdag 15 februari 2024 om 02:03:10 UTC+1 schreef gjr80:
>
>> Correct. Cmon will try to scan all mounted file systems except for those 
>> in an ignore list. Problem is the ignore list is not user configurable via 
>> a config file, rather it is hard coded in cmon.py. You have a few 
>> options; (1) raise an issue against the weewx-cmon repo and ask for Matthew 
>> to make the ignore list user configurable, (2) drop cmon from your system 
>> or (3) manually change the ignore list in cmon.py to exclude your docker 
>> overlays. I'd suggest a combination of (3) and (1).
>>
>> Have a look at line 266 in cmon.py 
>> <https://github.com/matthewwall/weewx-cmon/blob/master/bin/user/cmon.py#L266>,
>>  
>> just add your docker overlay to the list. Not sure you can add one wildcard 
>> entry for all docker overlays but a bit of experimentation will get you 
>> there. 
>>
>> Gary
>>
>> And do raise an issue for when Matthew does get some time for cmon.  
>>
>> On Thursday 15 February 2024 at 02:14:31 UTC+10 valken...@gmail.com 
>> wrote:
>>
>>> Since upgrading to weewx 5.02 on ubuntue 22.04, deb instaal. I had some 
>>> issues becuase weewx does not run as root user anymore. Most of the were 
>>> easy to solve. However on this ubuntu also a docker instance is running for 
>>> another application. 
>>> My syslog now tells me this:
>>>
>>> INFO weewx.engine: Main loop exiting. Shutting engine down.
>>> Feb 14 16:55:15 kwsweerstation weewxd[9005]: INFO weewx.engine: Shutting 
>>> down StdReport thread
>>> Feb 14 16:55:15 kwsweerstation weewxd[9005]: CRITICAL __main__: Caught 
>>> OSError: [Errno 13] Toegang geweigerd: 
>>> '/var/lib/docker/overlay2/f40006ded3b1ca4e49c40cb408c89374b8b4a067f4de13711cf4be188137d355/merged'
>>> Feb 14 16:55:15 kwsweerstation weewxd[9005]: CRITICAL __main__:  
>>>  Traceback (most recent call last):
>>> Feb 14 16:55:15 kwsweerstation weewxd[9005]: CRITICAL __main__:  
>>>File "/usr/share/weewx/weewx/engine.py", line 210, in run
>>> Feb 14 16:55:15 kwsweerstation weewxd[9005]: CRITICAL __main__:  
>>>  self.dispatchEvent(weewx.Event(weewx.CHECK_LOOP, packet=packet))
>>> Feb 14 16:55:15 kwsweerstation weewxd[9005]: CRITICAL __main__:  
>>>File "/usr/share/weewx/weewx/engine.py", line 241, in dispatchEvent
>>> Feb 14 16:55:15 kwsweerstation weewxd[9005]: CRITICAL __main__:  
>>>  callback(event)
>>> Feb 14 16:55:15 kwsweerstation weewxd[9005]: CRITICAL __main__:  
>>>File "/usr/share/weewx/weewx/engine.py", line 660, in check_loop
>>> Feb 14 16:55:15 kwsweerstation weewxd[9005]: CRITICAL __main__:  
>>>  raise BreakLoop
>>> Feb 14 16:55

[weewx-user] Re: weewx 5.02 crashes (and restarts) on trying to access a docker file?

[gjr80]

Correct. Cmon will try to scan all mounted file systems except for those in 
an ignore list. Problem is the ignore list is not user configurable via a 
config file, rather it is hard coded in cmon.py. You have a few options; 
(1) raise an issue against the weewx-cmon repo and ask for Matthew to make 
the ignore list user configurable, (2) drop cmon from your system or (3) 
manually change the ignore list in cmon.py to exclude your docker overlays. 
I'd suggest a combination of (3) and (1).

Have a look at line 266 in cmon.py 
, 
just add your docker overlay to the list. Not sure you can add one wildcard 
entry for all docker overlays but a bit of experimentation will get you 
there. 

Gary

And do raise an issue for when Matthew does get some time for cmon.  

On Thursday 15 February 2024 at 02:14:31 UTC+10 valken...@gmail.com wrote:

> Since upgrading to weewx 5.02 on ubuntue 22.04, deb instaal. I had some 
> issues becuase weewx does not run as root user anymore. Most of the were 
> easy to solve. However on this ubuntu also a docker instance is running for 
> another application. 
> My syslog now tells me this:
>
> INFO weewx.engine: Main loop exiting. Shutting engine down.
> Feb 14 16:55:15 kwsweerstation weewxd[9005]: INFO weewx.engine: Shutting 
> down StdReport thread
> Feb 14 16:55:15 kwsweerstation weewxd[9005]: CRITICAL __main__: Caught 
> OSError: [Errno 13] Toegang geweigerd: 
> '/var/lib/docker/overlay2/f40006ded3b1ca4e49c40cb408c89374b8b4a067f4de13711cf4be188137d355/merged'
> Feb 14 16:55:15 kwsweerstation weewxd[9005]: CRITICAL __main__:  
>  Traceback (most recent call last):
> Feb 14 16:55:15 kwsweerstation weewxd[9005]: CRITICAL __main__:    
>  File "/usr/share/weewx/weewx/engine.py", line 210, in run
> Feb 14 16:55:15 kwsweerstation weewxd[9005]: CRITICAL __main__:    
>self.dispatchEvent(weewx.Event(weewx.CHECK_LOOP, packet=packet))
> Feb 14 16:55:15 kwsweerstation weewxd[9005]: CRITICAL __main__:    
>  File "/usr/share/weewx/weewx/engine.py", line 241, in dispatchEvent
> Feb 14 16:55:15 kwsweerstation weewxd[9005]: CRITICAL __main__:    
>callback(event)
> Feb 14 16:55:15 kwsweerstation weewxd[9005]: CRITICAL __main__:    
>  File "/usr/share/weewx/weewx/engine.py", line 660, in check_loop
> Feb 14 16:55:15 kwsweerstation weewxd[9005]: CRITICAL __main__:    
>raise BreakLoop
> Feb 14 16:55:15 kwsweerstation weewxd[9005]: CRITICAL __main__:  
>  weewx.engine.BreakLoop
> Feb 14 16:55:15 kwsweerstation weewxd[9005]: CRITICAL __main__:   
> Feb 14 16:55:15 kwsweerstation weewxd[9005]: CRITICAL __main__:  
>  During handling of the above exception, another exception occurred:
> Feb 14 16:55:15 kwsweerstation weewxd[9005]: CRITICAL __main__:   
> Feb 14 16:55:15 kwsweerstation weewxd[9005]: CRITICAL __main__:  
>  Traceback (most recent call last):
> Feb 14 16:55:15 kwsweerstation weewxd[9005]: CRITICAL __main__:    
>  File "/usr/share/weewx/weewx/engine.py", line 676, in post_loop
> Feb 14 16:55:15 kwsweerstation weewxd[9005]: CRITICAL __main__:    
>self._catchup(self.engine.console.genArchiveRecords)
> Feb 14 16:55:15 kwsweerstation weewxd[9005]: CRITICAL __main__:    
>  File "/usr/share/weewx/weewx/engine.py", line 723, in _catchup
> Feb 14 16:55:15 kwsweerstation weewxd[9005]: CRITICAL __main__:    
>for record in generator(lastgood_ts):
> Feb 14 16:55:15 kwsweerstation weewxd[9005]: CRITICAL __main__:    
>  File "/usr/share/weewx/weewx/drivers/__init__.py", line 31, in 
> genArchiveRecords
> Feb 14 16:55:15 kwsweerstation weewxd[9005]: CRITICAL __main__:    
>raise NotImplementedError("Method 'genArchiveRecords' not implemented")
> Feb 14 16:55:15 kwsweerstation weewxd[9005]: CRITICAL __main__:  
>  NotImplementedError: Method 'genArchiveRecords' not implemented
> Feb 14 16:55:15 kwsweerstation weewxd[9005]: CRITICAL __main__:   
> Feb 14 16:55:15 kwsweerstation weewxd[9005]: CRITICAL __main__:  
>  During handling of the above exception, another exception occurred:
> Feb 14 16:55:15 kwsweerstation weewxd[9005]: CRITICAL __main__:   
> Feb 14 16:55:15 kwsweerstation weewxd[9005]: CRITICAL __main__:  
>  Traceback (most recent call last):
> Feb 14 16:55:15 kwsweerstation weewxd[9005]: CRITICAL __main__:    
>  File "/usr/share/weewx/weewxd.py", line 166, in main
> Feb 14 16:55:15 kwsweerstation weewxd[9005]: CRITICAL __main__:    
>engine.run()
> Feb 14 16:55:15 kwsweerstation weewxd[9005]: CRITICAL __main__:    
>  File "/usr/share/weewx/weewx/engine.py", line 217, in run
> Feb 14 16:55:15 kwsweerstation weewxd[9005]: CRITICAL __main__:    
>self.dispatchEvent(weewx.Event(weewx.POST_LOOP))
> Feb 14 16:55:15 kwsweerstation weewxd[9005]: CRITICAL __main__: ***

Re: [weewx-user] unable to save to file '/var/www/html/weewx/...

[gjr80]

WeeWX is being run just fine, the error is in the [SDR] stanza in weewx.conf. 
As is often the case the clue is in the log:

Feb 14 08:49:54 raspberrypi weewxd[5905]: INFO user.sdr: shutdown process sudo 
/usr/local/bin/rtl_433 -f 868.3M -f 433.92M -H 90 -Y autolevel -s 1024k -R 
173 - R 172 -R 42 -M utc -F json

Almost certainly the command to run rtl_433 at the cmd setting includes 
sudo. Remove the sudo and it should be fine.

Gary

-- 
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/a74a0a3a-30f3-4cea-9b00-262ae4956121n%40googlegroups.com.

[weewx-user] Re: No updates to /var/www/html/weewx

[gjr80]

I can't see anything obviously wrong. WeeWX is looking in the right place 
and the .conf files exist. read only permission is fine. Let me see if I 
can replicate this, what Ubuntu version?

Gary

On Wednesday 7 February 2024 at 09:05:49 UTC+10 philip...@gmail.com wrote:

> The Ubuntu package for weewx 5.0.1-3 installs a ton of stuff, including 
> the skins data, in /usr/share/weewx.
>
> /etc/weewx/skins contains three empty folders: font, lang, and NOAA.
>
> I copied /usr/shared/weewx/weewx_data/skins to /etc/weewx/skins and 
> veriified that Seasons/skin.conf is there. I restarted weewxk and it still 
> claims that it can't read Seasons/skin.conf.
>
> philbert@inspiron:~$ ll /etc/weewx/skins/Seasons/skin.conf
> -rw-r--r-- 1 weewx weewx 27403 Feb  4 18:48 
> /etc/weewx/skins/Seasons/skin.conf
> philbert@inspiron:~$ ll /etc/weewx/skins/Seasons/lang/en.conf
> -rw-r--r-- 1 weewx weewx 9459 Feb  4 18:48 
> /etc/weewx/skins/Seasons/lang/en.conf
> philbert@inspiron:~$
>
> Feb 06 14:15:15 inspiron weewxd[700]: INFO weewx.manager: Added record 
> 2024-02-06 14:15:00 PST (1707257700) to database 'weewx.sdb'
> Feb 06 14:15:15 inspiron weewxd[700]: INFO weewx.manager: Added record 
> 2024-02-06 14:15:00 PST (1707257700) to daily summary in 'weewx.sdb'
> Feb 06 14:15:15 inspiron weewxd[700]: DEBUG weewx.reportengine: Running 
> reports for latest time in the database.
> Feb 06 14:15:15 inspiron weewxd[700]: DEBUG weewx.reportengine: Running 
> report 'SeasonsReport'
> Feb 06 14:15:15 inspiron weewxd[700]: DEBUG weewx.reportengine: Cannot 
> read skin configuration file /etc/weewx/skins/Seasons/skin.conf for report 
> 'SeasonsReport': Config file not found: 
> "/etc/weewx/skins/Seasons/skin.conf".
> Feb 06 14:15:15 inspiron weewxd[700]: DEBUG weewx.reportengine: Cannot 
> read localization file /etc/weewx/skins/Seasons/lang/en.conf for report 
> 'SeasonsReport': Config file not found: 
> "/etc/weewx/skins/Seasons/lang/en.conf".
> Feb 06 14:15:15 inspiron weewxd[700]: DEBUG weewx.reportengine:  Using 
> defaults instead.
> Feb 06 14:15:15 inspiron weewxd[700]: DEBUG weewx.reportengine: Running 
> generators for report 'SeasonsReport' in directory 
> '/etc/weewx/skins/Seasons'
> Feb 06 14:15:15 inspiron weewxd[700]: DEBUG weewx.reportengine: No 
> generators specified for report 'SeasonsReport'
>
> On Tuesday, February 6, 2024 at 2:10:19 PM UTC-8 gjr80 wrote:
>
>> So WeeWX cannot find the Seasons skin.conf, what is the contends of 
>> /etc/weewx/skins/Seasons? 
>>
>> Also, you seem to be truncating some of the log lines, it would help if 
>> we could see the rest of the line:
>>
>> Feb 06 13:25:15 inspiron weewxd[692]: DEBUG weewx.reportengine: Cannot 
>> read skin configuration file /etc/weewx/skins/Seasons/skin.conf for report 
>> 'SeasonsReport':>
>> Feb 06 13:25:15 inspiron weewxd[692]: DEBUG weewx.reportengine: Cannot 
>> read localization file /etc/weewx/skins/Seasons/lang/en.conf for report 
>> 'SeasonsReport': Co>
>>
>> For info, a package install has the skins directory in /etc/weewx, it 
>> has never been in /usr/share/weewx, refer to Where to find things 
>> <http://weewx.com/docs/5.0/usersguide/where/> in the User's Guide.
>>
>> Gary
>>
>> On Wednesday 7 February 2024 at 07:57:20 UTC+10 philip...@gmail.com 
>> wrote:
>>
>>> It thinks that the skins are still in /etc/weewx instead of 
>>> /usr/share/weewx.
>>>
>>> -- Boot bc88a89987b645f18a3473d5771ebb26 --
>>> Feb 06 13:22:59 inspiron systemd[1]: Started WeeWX.
>>> Feb 06 13:23:00 inspiron weewxd[692]: INFO __main__: Initializing weewxd 
>>> version 5.0.1
>>> Feb 06 13:23:00 inspiron weewxd[692]: INFO __main__: Command line: 
>>> /usr/share/weewx/weewxd.py /etc/weewx/weewx.conf
>>> Feb 06 13:23:00 inspiron weewxd[692]: INFO __main__: Using Python 
>>> 3.10.12 (main, Nov 20 2023, 15:14:05) [GCC 11.4.0]
>>> Feb 06 13:23:00 inspiron weewxd[692]: INFO __main__: Located at 
>>> /usr/bin/python3
>>> Feb 06 13:23:00 inspiron weewxd[692]: INFO __main__: Platform 
>>> Linux-6.5.0-15-generic-x86_64-with-glibc2.35
>>> Feb 06 13:23:00 inspiron weewxd[692]: INFO __main__: Locale: 
>>> 'en_US.UTF-8'
>>> Feb 06 13:23:00 inspiron weewxd[692]: INFO __main__: Entry path: 
>>> /usr/share/weewx/weewxd.py
>>> Feb 06 13:23:00 inspiron weewxd[692]: INFO __main__: WEEWX_ROOT: 
>>> /etc/weewx
>>> Feb 06 13:23:00 inspiron weewxd[692]: INFO __main__: Configuration file: 
&

[weewx-user] Re: No updates to /var/www/html/weewx

[gjr80]

ince 2024-02-06 13:20:00 PST (1707254400)
> Feb 06 13:23:01 inspiron weewxd[692]: DEBUG weewx.drivers.vantage: 
> Successfully woke up Vantage console
> Feb 06 13:23:01 inspiron weewxd[692]: DEBUG weewx.drivers.vantage: 
> Retrieving 0 page(s); starting index= 0
> Feb 06 13:23:01 inspiron weewxd[692]: INFO weewx.engine: Starting main 
> packet loop.
> Feb 06 13:23:02 inspiron weewxd[692]: DEBUG weewx.drivers.vantage: 
> Successfully woke up Vantage console
> Feb 06 13:23:02 inspiron weewxd[692]: DEBUG weewx.drivers.vantage: 
> Requesting 200 LOOP packets.
> Feb 06 13:23:02 inspiron weewxd[692]: DEBUG weewx.drivers.vantage: 
> Successfully woke up Vantage console
> Feb 06 13:25:14 inspiron weewxd[692]: DEBUG weewx.drivers.vantage: Getting 
> archive packets since 2024-02-06 13:20:00 PST (1707254400)
> Feb 06 13:25:15 inspiron weewxd[692]: DEBUG weewx.drivers.vantage: 
> Successfully woke up Vantage console
> Feb 06 13:25:15 inspiron weewxd[692]: DEBUG weewx.drivers.vantage: 
> Retrieving 1 page(s); starting index= 4
> Feb 06 13:25:15 inspiron weewxd[692]: INFO weewx.manager: Added record 
> 2024-02-06 13:25:00 PST (1707254700) to database 'weewx.sdb'
> Feb 06 13:25:15 inspiron weewxd[692]: INFO weewx.manager: Added record 
> 2024-02-06 13:25:00 PST (1707254700) to daily summary in 'weewx.sdb'
> Feb 06 13:25:15 inspiron weewxd[692]: DEBUG weewx.reportengine: Running 
> reports for latest time in the database.
> Feb 06 13:25:15 inspiron weewxd[692]: DEBUG weewx.drivers.vantage: 
> Requesting 200 LOOP packets.
> Feb 06 13:25:15 inspiron weewxd[692]: DEBUG weewx.reportengine: Running 
> report 'SeasonsReport'
> Feb 06 13:25:15 inspiron weewxd[692]: DEBUG weewx.reportengine: Cannot 
> read skin configuration file /etc/weewx/skins/Seasons/skin.conf for report 
> 'SeasonsReport':>
> Feb 06 13:25:15 inspiron weewxd[692]: DEBUG weewx.reportengine: Cannot 
> read localization file /etc/weewx/skins/Seasons/lang/en.conf for report 
> 'SeasonsReport': Co>
> Feb 06 13:25:15 inspiron weewxd[692]: DEBUG weewx.reportengine:  Using 
> defaults instead.
> Feb 06 13:25:15 inspiron weewxd[692]: DEBUG weewx.reportengine: Running 
> generators for report 'SeasonsReport' in directory 
> '/etc/weewx/skins/Seasons'
> Feb 06 13:25:15 inspiron weewxd[692]: DEBUG weewx.reportengine: No 
> generators specified for report 'SeasonsReport'
>
> On Tuesday, February 6, 2024 at 12:58:36 PM UTC-8 gjr80 wrote:
>
>> Impossible to say what the issue is with such a short log extract. Please 
>> edit weewx.conf, set debug =1, save weewx.conf and restart WeeWX. Let 
>> WeeWX run for at least two archive intervals and then take a log extract 
>> showing the full WeeWX startup through until the two archive intervals have 
>> elapsed. Post the log extract here.
>>
>> Gary 
>>
>> On Wednesday 7 February 2024 at 06:33:54 UTC+10 philip...@gmail.com 
>> wrote:
>>
>>> I'm configured for reports using the Seasons skin and data publishing to 
>>> CWOP and Wunderground.
>>>
>>> After updating from  4.10.2 to 5.0.1, I'm seeing the following in the 
>>> systemd journal every 5 minutes:
>>> Feb 06 12:10:17 inspiron weewxd[680]: INFO weewx.manager: Added record 
>>> 2024-02-06 12:10:00 PST (1707250200) to database 'weewx.sdb'
>>> Feb 06 12:10:17 inspiron weewxd[680]: INFO weewx.manager: Added record 
>>> 2024-02-06 12:10:00 PST (1707250200) to daily summary in 'weewx.sdb'
>>> Feb 06 12:10:17 inspiron weewxd[680]: INFO weewx.restx: CWOP: Published 
>>> record 2024-02-06 12:10:00 PST (1707250200)
>>> Feb 06 12:10:17 inspiron weewxd[680]: INFO weewx.restx: 
>>> Wunderground-PWS: Published record 2024-02-06 12:10:00 PST (1707250200)
>>>
>>> No mention of report generation, and the Seasons data displayed in 
>>> Firefox hasn't changed since I installed the update.
>>>
>>> What could I have done to cause this?
>>>
>>>

-- 
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/7ebc3a02-06d6-4eb7-86b2-59f2cfc291adn%40googlegroups.com.

[weewx-user] Re: New User: First Problem

[gjr80]

This is unlikely to be a units problem, rather it is likely to be one of 
incorrect (or a lack of) data from the station. FineOffset stations provide 
the WeeWX field pressure and WeeWX will then calculate fields barometer and 
altimeter if possible. The log entry provided indicates that WeeWX has 
ended up with a pressure value of zero which is outside the (default) QC 
limits set in [StdQC] [[MinMax]] in weewx.conf. You need to be looking at 
what data is being emitted by the station/driver; with the fousb driver you 
should be able to use weectl device 
 to interrogate the 
station and, among other things, display live data from the station 
. The result 
may well give you an indication of where the problem is.

As an aside the units used within the [StdQC] [[MinMax]] stanza and the 
display units in reports (or on a station hardware display) bear no direct 
relationship. [[MinMax]] settings default to the units used in the WeeWX 
database; however, units can be specified. As it happens the default 
[[MinMax]] settings have US customary units specified. You may find it 
beneficial to read through the [StdQC] reference 
.

Gary
On Wednesday 7 February 2024 at 07:03:37 UTC+10 gszla...@gmail.com wrote:

> I'll take a wild guess..maybe it's a unit mismatch of some sort. Try 
> switching your console to inHg instead of hPa (temporarily) and see if that 
> works.
>
> On Tuesday, February 6, 2024 at 7:05:58 AM UTC-5 michael.k...@gmx.at 
> wrote:
>
>> The warning tells you: WeeWX is receiving 0.0 for "pressure". You say, 
>> "The hardware console is operating correctly as expected", so the problem 
>> is somewhere in between the hardware and the LOOP. It may be, that your 
>> hardware/driver combination doesn't supply a valid value for "pressure" (it 
>> should return "None" instead of "0.0" in this case), did you try 
>> "barometer" or "altimeter" instead? You can also check in your database, if 
>> there are values for these types. If so, take a look into this article 
>> , 
>> to make sure, you really use the correct type for your needs. Having only 
>> one out of the three "pressure", "altimeter" and "barometer", it should be 
>> possible to calculate the others, when you have the altitude, the 
>> temperature and humidity (or even something in addition to that).
>>
>> Alan Salmon schrieb am Dienstag, 6. Februar 2024 um 12:48:48 UTC+1:
>>
>>> Hello everyone.
>>>
>>> I installed weewx for the first time today on a Raspberry Pi Zero 2W, 
>>> using a Fine Offset 3081 station that I used for about 10 years until the 
>>> local cockatoos decided it would be fun to dismantle it!
>>>
>>> It came up on the second attempt after a few minor adjustments to the 
>>> config file, paths, etc. (I used the pip install method on Debian 11).
>>>
>>> The hardware console is operating correctly as expected, but weewx is 
>>> giving me the following error:
>>>
>>> Feb  6 22:26:01 bigfish-08 weewxd[1909]: WARNING weewx.qc: 2024-02-06 
>>> 22:26:02 AEDT (1707218762) LOOP value 'pressure' 0.0 outside limits (24.0, 
>>> 34.5)
>>>
>>> As the value displayed on the console (roughly) agrees with a BME680 I 
>>> have running, can anyone suggest where I should start trying to solve this?
>>>
>>> Note that I am configured for metric with barometric pressure in 
>>> hectopascals (hPa) which is currently just over 1010hPa, so I am at a bit 
>>> of a loss as to why it is showing '0.0' and where the range "24.0 to 34.5' 
>>> comes from.
>>>
>>> The error has been consistent for the 9 hours it has been running.
>>>
>>> Thanks for any advice you can offer.
>>>
>>>
>>>

-- 
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/1d99220d-4d18-42e6-802b-126bbf1ebc53n%40googlegroups.com.

Re: [weewx-user] weewx v5.0.1 upgrade problem

[gjr80]

Impossible to say what the issue is with such a short log extract. Please 
edit weewx.conf, set debug =1, save weewx.conf and restart WeeWX. Let WeeWX 
run for at least two archive intervals and then take a log extract showing 
the full WeeWX startup through until the two archive intervals have 
elapsed. Post the log extract here.

Gary 

On Wednesday 7 February 2024 at 05:23:35 UTC+10 philip...@gmail.com wrote:

> Thanks for that tip - it got me off the ground. All is now well except 
> that /var/www/html/weewx hasn't been updated since just before I did the 
> upgrade to 5.0.1. Anyone else seeing this?
>
> On Tuesday, February 6, 2024 at 8:09:36 AM UTC-8 Tom Hogland wrote:
>
>> In case anyone else runs into this - my Ubuntu server/Davis VP2 and 
>> serial datalogger had ownership set to root:dialout, so I had to add the 
>> weewx user to the dialout group for things to work. 
>>
>> On Tuesday, February 6, 2024 at 6:23:15 AM UTC-9 matthew wall wrote:
>>
>>> when you install rtl-sdr, it typically, but not always, installs udev 
>>> rules for *many* sdr devices.  the udev rules that it installs make it 
>>> possible for anyone in the 'plugdev' group to read/write to the sdr 
>>> device.  (this is true when you install rtl-sdr from source - if you 
>>> install rtl-sdr from a deb/rpm package, it might be different - anyone with 
>>> this configuration please let us know)
>>>
>>> weewx v4 runs as root:root, so it has access to the sdr device no matter 
>>> what the udev rules might be
>>>
>>> weewx v5 runs as weewx:weewx (for a deb/rpm install) or as a regular 
>>> non-root user (for pip installs).  so udev rules are required.
>>>
>>> btw, weewx 5.0.1 *always* converts to weewx:weewx, whereas 5.0.0 did not 
>>> (it would continue to run as root - we changed in 5.0.1 because overall 
>>> security and best practice)
>>>
>>> the udev rules installed by rtl-sdr will not help for a deb/rpm install, 
>>> since the user 'weewx' is not in the plugdev group.  you can either added 
>>> the user weewx to the plugdev group, or modify the udev rules to use 
>>> 'weewx' instead of 'plugdev' as the group.  this is how to do the former:
>>>
>>> sudo usermod -aG plugdev weewx
>>>
>>> for a pip install, be sure that the user running weewx is in the 
>>> 'plugdev' group.
>>>
>>> restart of the weewxd daemon is almost certainly required so that the 
>>> daemon process has the right group.  reboot is not necessary.
>>>
>>> m
>>>
>>

-- 
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/f74ff6b5-238f-4823-b82f-c01864f4f00dn%40googlegroups.com.

[weewx-user] Re: No updates to /var/www/html/weewx

[gjr80]

Impossible to say what the issue is with such a short log extract. Please 
edit weewx.conf, set debug =1, save weewx.conf and restart WeeWX. Let WeeWX 
run for at least two archive intervals and then take a log extract showing 
the full WeeWX startup through until the two archive intervals have 
elapsed. Post the log extract here.

Gary 

On Wednesday 7 February 2024 at 06:33:54 UTC+10 philip...@gmail.com wrote:

> I'm configured for reports using the Seasons skin and data publishing to 
> CWOP and Wunderground.
>
> After updating from  4.10.2 to 5.0.1, I'm seeing the following in the 
> systemd journal every 5 minutes:
> Feb 06 12:10:17 inspiron weewxd[680]: INFO weewx.manager: Added record 
> 2024-02-06 12:10:00 PST (1707250200) to database 'weewx.sdb'
> Feb 06 12:10:17 inspiron weewxd[680]: INFO weewx.manager: Added record 
> 2024-02-06 12:10:00 PST (1707250200) to daily summary in 'weewx.sdb'
> Feb 06 12:10:17 inspiron weewxd[680]: INFO weewx.restx: CWOP: Published 
> record 2024-02-06 12:10:00 PST (1707250200)
> Feb 06 12:10:17 inspiron weewxd[680]: INFO weewx.restx: Wunderground-PWS: 
> Published record 2024-02-06 12:10:00 PST (1707250200)
>
> No mention of report generation, and the Seasons data displayed in Firefox 
> hasn't changed since I installed the update.
>
> What could I have done to cause this?
>
>

-- 
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/3c3e2314-6116-403b-a9c9-6b2ead05cf46n%40googlegroups.com.

[weewx-user] Re: Zambretti forecast in StellSeries

[gjr80]

If you want to use the Zambretti forecast text in the gauge-data.txt 
template you will need to install the WeeWX forecast extension 
. This extension has some 
issues, mostly with weather services such as WU (changed API) and 
DarkSky(now defunct) etc, but as far as I know the Zambretti forecast still 
works. If it doesn't work under WeeWX v4 or v5 you should try one of the 
forks. This one  should 
work. 

Once installed you need to set the Zambretti forecast to work, there is 
little on Zambretti in the extension documentation, but if you read the 
comments 
in forecast.py 

 
it tells you what needs to go into the [Forecast] [[Zambretti]] stanza 
(from memory you can get by with just telling it you hemisphere). You then 
need to make the forecast variable available in your gauge-data.txt 
template by adding search_list_extensions = user.forecast.ForecastVariables 
to your SteelSeries skin config file, again this is covered in the comments 
in forecast.py 

.

You will need to restart WeeWX after installing and configuring the 
forecast extension.

I do not use the gauge-data.txt template or the forecast extension, but if 
they above do not work they should get you close. If you need to 
troubleshoot first confirm the Zambretti forecast is working and the 
forecast database is being populated, then look at whether the 
gauge-data.txt template is obtaining the Zambretti forecast text.

Gary

-- 
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/8a64f4c5-373f-4ead-bf92-1ec8de8a77f7n%40googlegroups.com.

[weewx-user] Re: Rescaling of SteelSeries Gauges

[gjr80]

Correct, not a RTGD or WeeWX issue. Something perhaps to take up with the 
SteelSeries Weather Gauges 
author https://github.com/mcrossley/SteelSeries-Weather-Gauges

Gary

On Thursday 1 February 2024 at 19:02:03 UTC+10 rory.g...@googlemail.com 
wrote:

I am using the SteelSeries gauges with RTGD on a 3 second update as a 
stand-alone weather display on an old iPad. It looks great, however the 
constant rescaling of the gauges for no apparent reason is a real problem. 
Glancing at the display it should be possible to determine the temperature 
and other readings by looking at the needle position without looking at the 
numbers. Unfortunately this is not the case due to rescaling.

The lowest temperature my station has recorded is -4.6ºC and the highest 
(which was a very rare one-off) was 25.7ºC, so the scale of -10ºC to +30ºC 
is perfect, and I have that set in the script, however it keeps rescaling 
to -20ºC to +20ºC for no apparent reason.

I can cope with the wind speed gauge rescaling, but even there I would like 
it to remain 0 - 60mph and only rescale when it goes over 60mph. Pressure, 
UV and solar radiation seem to stay at the values I have set.

Is there any way to prevent the rescaling? I understand this really isn't a 
Weewx or RTGD issue but there's maybe a hack out there that I haven't found.

Thanks,

Rory

You can see the page I use for the iPad here: ttps://
www.360shetland.co.uk/weather/ss

-- 
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/bfd4960d-68eb-45a0-a5f2-7182b9bbd327n%40googlegroups.com.

[weewx-user] Re: Driver permission error when starting Weewx

[gjr80]

You have almost certainly encountered the bug mentioned in this post 
. The 
bug does not bite (ie potentially delete system files) unless you uninstall 
the extension using weectl extension - so my strong advice to you is do not 
attempt to uninstall the extension. A manual uninstall (or install) will be 
fine. But I would further suggest waiting a few days for v5.0.1 which fixes 
this bug, its release should not be too far off.

Gary

On Thursday 1 February 2024 at 17:35:01 UTC+10 csm...@gmail.com wrote:

> @Tomasz, you stated above that ' I installed both interceptor and HP1000 
> drivers by weectl. " Can you provide some insight into how you did this? I 
> have a fresh install of 5.0.1 and when I run 'weectl extension install 
> weewx-interceptor.zip (fresh download) I get an error stack below. I am 
> posting here just in case I am missing something obvious, if not I will 
> start a new thread. 
>
> Thanks, 
> Chris 
>
> :~$ weectl extension install weewx-interceptor.zip
> Using configuration file /etc/weewx/weewx.conf
> Install extension 'weewx-interceptor.zip' (y/n)? y
> Extracting from zip archive weewx-interceptor.zip
>
> Traceback (most recent call last):
>   File "/usr/share/weewx/weectl.py", line 74, in 
> main()
>   File "/usr/share/weewx/weectl.py", line 66, in main
> namespace.func(namespace)
>   File "/usr/share/weewx/weectllib/__init__.py", line 121, in dispatch
> namespace.action_func(config_dict, namespace)
>   File "/usr/share/weewx/weectllib/extension_cmd.py", line 116, in 
> install_extension
> ext.install_extension(namespace.source, no_confirm=namespace.yes)
>   File "/usr/share/weewx/weecfg/extension.py", line 138, in 
> install_extension
> extension_name = self._install_from_file(extension_path, filetype)
>   File "/usr/share/weewx/weecfg/extension.py", line 168, in 
> _install_from_file
> extension_name = self.install_from_dir(extension_dir)
>   File "/usr/share/weewx/weecfg/extension.py", line 185, in 
> install_from_dir
> self._install_files(installer['files'], extension_dir)
>   File "/usr/share/weewx/weecfg/extension.py", line 269, in _install_files
> shutil.copy(source_path, destination_path)
>   File "/usr/lib/python3.8/shutil.py", line 418, in copy
> copyfile(src, dst, follow_symlinks=follow_symlinks)
>   File "/usr/lib/python3.8/shutil.py", line 264, in copyfile
> with open(src, 'rb') as fsrc, open(dst, 'wb') as fdst:
> FileNotFoundError: [Errno 2] No such file or directory: 
> '/bin/user/interceptor.py'
>
> On Thursday, January 25, 2024 at 1:27:34 AM UTC-7 Tomasz Lewicki wrote:
>
>> Mystery solved. 
>>
>> But answering to vince question, my system is rather typical - Raspbian 
>> on Raspberry Pi, only WLAN interface is active. Weewx was unwillingly 
>> updated from 4.10.2 to 5.0.0. I checked all point of failure: Python 
>> version, permissions (thank you Gary!), network traffic. As I wrote before, 
>> rtupdate.wunderground.com was hijacked - local DNS redirected it to 
>> Weewx. So I deleted this bypass, allowing console to send data to real WU 
>> server. But still I couldn't see any traffic on my router. Total silence. 
>> It was abnormal (and it explains why PCAP file captured by Tshark was empty 
>> on port 80). But I didn't check WU settings in WiFi console. Station ID was 
>> empty, password was obfuscated by asterisks. I don't use WU website at all, 
>> I just needed credentials for conversation between console and Weewx. I 
>> entered ID and password - and then console started send data to real WU. So 
>> I redirected  network traffic on my DNS again, and Weewx started to receive 
>> data from WiFi console via interceptor driver :)
>>
>> Thank you to everyone who patiently read my writings and tried to help.
>>
>> środa, 24 stycznia 2024 o 22:54:46 UTC+1 vince napisał(a):
>>
>>> Difficult to answer with no info from you on exactly 'what' command you 
>>> ran for wireshark and whether your listening computer is wifi, ethernet, or 
>>> both.  What kind of computer are you running on ?  What os ?  What version 
>>> ?  Which interfaces ?  What was your 'exact' wireshark command ?
>>>
>>> But I see nothing basically in that 6-second pcap.  If running a sniffer 
>>> on your computer sees no traffic being redirected from the station, then 
>>> there is nothing for interceptor to intercept on the weewx computer.
>>>
>>> Again, when you say "*But I hijacked DNS on my router*" that (to me) 
>>> does not cause any traffic from your station to wunderground to be 
>>> redirected to your weewx system unless I'm not understanding what you're 
>>> saying.  Perhaps you should tell everybody what your system config is so 
>>> those who do interceptor can try to help more. 
>>>
>>> On Wednesday, January 24, 2024 at 1:38:25 PM UTC-8 Tomasz Lewicki wrote:
>>>
 I attach PCAP file with packets captured for 120 seconds. TCP/80 only. 
 Weewx was shut down. No traffic on th

[weewx-user] Re: Running Ecowitt Gateway Driver bith as a driver and a service at the same time?

[gjr80]

Thank you, yes, self.latest_sensor_data['dateTime'] should be 
self.latest_sensor_data['datetime']. Fixed in 0.6.0b6.

Gary
On Sunday 28 January 2024 at 04:59:19 UTC+10 michael.k...@gmx.at wrote:

> Seems like, changed it to
> if self.latest_sensor_data is None or sensor_data['datetime'] > 
> self.latest_sensor_data['datetime']:
> and it didn't crash again so far.
>
> michael.k...@gmx.at schrieb am Samstag, 27. Januar 2024 um 14:31:43 UTC+1:
>
>> Case typo?
>>
>> if self.latest_sensor_data is None or sensor_data['datetime'] > 
>> self.latest_sensor_data['dateTime']:
>> michael.k...@gmx.at schrieb am Samstag, 27. Januar 2024 um 14:24:58 
>> UTC+1:
>>
>>> That part worked. You can tell by the weewx.restx: MQTT: Published 
>>> record entries in the log, there is only one Loop packet every 10s (the 
>>> poll interval).
>>> But after a few archive_intervals it crashed:
>>>
>>> 2024-01-27 14:17:25 weewxd[657388] INFO weewx.engine: Main loop exiting. 
>>> Shutting engine down.
>>> 2024-01-27 14:17:25 weewxd[657388] INFO weewx.engine: Shutting down 
>>> StdReport thread
>>> 2024-01-27 14:17:26 weewxd[657388] INFO user.gw1000: GatewayCollector 
>>> thread has been terminated
>>> 2024-01-27 14:17:27 weewxd[657388] INFO user.gw1000: GatewayCollector 
>>> thread has been terminated
>>> 2024-01-27 14:17:27 weewxd[657388] CRITICAL __main__: Caught 
>>> unrecoverable exception:
>>> 2024-01-27 14:17:27 weewxd[657388] CRITICAL __main__:  
>>>  'dateTime'
>>> 2024-01-27 14:17:27 weewxd[657388] CRITICAL __main__:  
>>>  Traceback (most recent call last):
>>>
>>> 2024-01-27 14:17:27 weewxd[657388] CRITICAL __main__: File 
>>> "/home/pi/weewx-venv/lib/python3.9/site-packages/weewxd.py", line 166, in 
>>> main
>>>
>>> 2024-01-27 14:17:27 weewxd[657388] CRITICAL __main__:  
>>>  engine.run()
>>>
>>> 2024-01-27 14:17:27 weewxd[657388] CRITICAL __main__: File 
>>> "/home/pi/weewx-venv/lib/python3.9/site-packages/weewx/engine.py", line 
>>> 206, in run
>>>
>>> 2024-01-27 14:17:27 weewxd[657388] CRITICAL __main__:  
>>>  self.dispatchEvent(weewx.Event(weewx.NEW_LOOP_PACKET, packet=packet))
>>>
>>> 2024-01-27 14:17:27 weewxd[657388] CRITICAL __main__: File 
>>> "/home/pi/weewx-venv/lib/python3.9/site-packages/weewx/engine.py", line 
>>> 241, in dispatchEvent
>>>
>>> 2024-01-27 14:17:27 weewxd[657388] CRITICAL __main__:  
>>>  callback(event)
>>>
>>> 2024-01-27 14:17:27 weewxd[657388] CRITICAL __main__: File 
>>> "/home/pi/weewx-data/bin/user/gw1000.py", line 1504, in new_loop_packet
>>>
>>> 2024-01-27 14:17:27 weewxd[657388] CRITICAL __main__:  
>>>  self.process_queued_sensor_data(queue_data, event.packet['dateTime'])
>>>
>>> 2024-01-27 14:17:27 weewxd[657388] CRITICAL __main__: File 
>>> "/home/pi/weewx-data/bin/user/gw1000.py", line 1611, in 
>>> process_queued_sensor_data
>>>
>>> 2024-01-27 14:17:27 weewxd[657388] CRITICAL __main__:   if 
>>> self.latest_sensor_data is None or sensor_data['datetime'] > 
>>> self.latest_sensor_data['dateTime']:
>>>
>>> 2024-01-27 14:17:27 weewxd[657388] CRITICAL __main__:  
>>>  KeyError: 'dateTime'
>>>
>>> 2024-01-27 14:17:27 weewxd[657388] CRITICAL __main__:   Exiting.
>>>
>>>
>>> michael.k...@gmx.at schrieb am Donnerstag, 25. Januar 2024 um 10:48:00 
>>> UTC+1:
>>>
>>>> OK, I need to sort this out a little. I think I messed up with 0.6.0bx 
>>>> and 0.5.0bx. Currently I've got too many things on my plate, and wasn't as 
>>>> focused on this topic, as I should have been, sorry for that. I'll do my 
>>>> homework and check everything again.
>>>>
>>>> gjr80 schrieb am Mittwoch, 24. Januar 2024 um 22:24:13 UTC+1:
>>>>
>>>>> On Thursday 25 January 2024 at 06:56:42 UTC+10 michael.k...@gmx.at 
>>>>> wrote:
>>>>>
>>>>> The log is from latest logs I posted are from b5. Sorry, I forgot to 
>>>>> mention that I didn't use the file in your link above, I downloaded from 
>>>

[weewx-user] Re: READ THIS!

[gjr80]

The problem is encountered when using the extension installer/uninstaller 
weectl 
extension. If you install WeeWX v5 via a package install and then use weectl 
extension install to install an extension, some or all of the extension 
files may be installed in an incorrect location. At this stage nothing 
destructive has occurred to your system other than the extension files 
perhaps being in the wrong location (and almost certainly the extension 
itself will not work with WeeWX - though WeeWX functions normally). If you 
then happen to uninstall the extension (perhaps because it seemingly does 
not work) with weectl extension uninstall that is when the uninstaller 
might delete system files.

So in these circumstances we recommend against installing or uninstalling 
extensions with weectl extension. Manual installs/uninstalls of extensions 
will be fine, it is just weectl extension that experiences problems. Also, 
if you have upgraded from an earlier WeeWX package install and the 
extension concerned was already installed (ie it was not installed using weectl 
extension) then you will be fine.

This issue will be fixed in v5.0.1 which should be released real soon.

Gary 

On Saturday 27 January 2024 at 16:09:06 UTC+10 abcor...@gmail.com wrote:

> I'm using weewx 5.0.0-1 (which I upgraded through Debian apt) and the 
> GW1000 driver. Does that mean I should not install the driver via 
> wee_extension until a new version comes out?
>
> Thanks...
>
> Andrew 
> On Wednesday, January 17, 2024 at 11:30:24 AM UTC-7 Tom Keffer wrote:
>
>> We have discovered a potentially serious bug. The specific situation is 
>> as follows:
>>
>>- A V4.x configuration file;
>>- Package installer;
>>- Install an extension;
>>- Uninstall the extension.
>>
>> Under these circumstances, the extension uninstaller could remove system 
>> files!
>>
>> If you are using a V4.x configuration file, please do not install any 
>> extensions until we get a fix out.
>>
>> Apologies.
>>
>> -tk
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/9c161ed3-7b0c-4495-9e67-cfe4b673ab1en%40googlegroups.com.

[weewx-user] Re: Running Ecowitt Gateway Driver bith as a driver and a service at the same time?

[gjr80]

On Thursday 25 January 2024 at 06:56:42 UTC+10 michael.k...@gmx.at wrote:

The log is from latest logs I posted are from b5. Sorry, I forgot to 
mention that I didn't use the file in your link above, I downloaded from 
the releases, and for b4 it says: removed, go for b5. b5 is producing two 
independent LOOP packets after a few on my RPi4.


Sorry, but I don't understand this. The latest log you posted yesterday is 
very clearly from b4:

2024-01-23 19:46:51 weewxd[232660] INFO weewx.engine: Loading station type 
GW1000 (user.gw1000) 
2024-01-23 19:46:51 weewxd[232660] INFO user.gw1000: GatewayDriver: version 
is 0.6.0b4 
2024-01-23 19:46:51 weewxd[232660] INFO user.gw1000: device address is 
10.0.1.85:45000

b4 and b5 have not been published to releases, they have been produced to 
deal with this issue and I have kept them back until I know the issue is 
fixed. You need to re-download the driver from the link I provided earlier 
in order to get b5, b3 (releases) and b4 will never work. Here is the link 
again:

https://raw.githubusercontent.com/gjr80/weewx-gw1000/master/bin/user/gw1000.py

Gary

-- 
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/6c2192cf-0406-4e08-9e75-d354b0c68c54n%40googlegroups.com.

Re: [weewx-user] Re: Error with weewx-SteelSeries skin

[gjr80]

, 'wetbulbTemp': 
>> '42.116', 'windchill': '45.5', 'windDir': 'None', 'windGust': '0.0', 
>> 'windGustDir': 'None', 'windrun': 'None', 'windSpeed': '0.0'
>>
>> LOOP:   2024-01-22 15:14:07 CET (1705932847) 'altimeter': 'None', 
>> 'appTemp': '41.972', 'barometer': '30.359780148749998', 'charge1': '11.0', 
>> 'charge5': '24.5', 'charge15': '16.5', 'cloudbase': '3264.768730531364', 
>> 'cpu_io': '1', 'cpu_irq': '0', 'cpu_softirq': '0', 'cpu_system': '1', 
>> 'cpu_user': '3', 'dateTime': '1705932847', 'dewpoint': 
>> '38.484', 'disk_total': '20425850880', 'disk_used': 
>> '10592813056', 'electricityLinky': '11', 'ET': 'None', 'extraHumid1': '66', 
>> 'extraHumid2': '92', 'extraHumid3': 'None', 'extraHumid4': '61', 
>> 'extraTemp1': '50.1080004', 'extraTemp2': '52.808', 'extraTemp3': 
>> 'None', 'extraTemp4': '66.506', 'extraTemp6': 'None', 'heatindex': 
>> '43.322', 'humidex': '45.5', 'inDewpoint': '51.55950246316422', 
>> 'inHumidity': '54', 'inTemp': '68.9', 'inTempDaikin': '68.0', 'kWhPAC': 
>> '0.827', 'maxSolarRad': '245.70270562970006', 'mem_total': '8286392320', 
>> 'mem_used': '1750069248', 'outHumidity': '76', 'outTemp': '45.5', 
>> 'outTempDaikin': '44.6', 'pressure': 'None', 'radiation': '73', 'rain': 
>> '0.0', 'rainRate': '0.0', 'thermostatDaikin': '68.0', 'usUnits': '1', 'UV': 
>> '0', 'waterSensus': '0.0', 'waterTempDaikin': '80.6', 'wetbulbTemp': 
>> '41.972', 'windchill': '45.5', 'windDir': 'None', 'windGust': '0.0', 
>> 'windGustDir': 'None', 'windrun': 'None', 'windSpeed': '0.0'
>>
>> LOOP:   2024-01-22 15:15:06 CET (1705932906) 'altimeter': 'None', 
>> 'appTemp': '42.116', 'barometer': '30.359780148749998', 'charge1': '3.5', 
>> 'charge5': '19.5', 'charge15': '15.0', 'cloudbase': '3188.894382989006', 
>> 'cpu_io': '0', 'cpu_irq': '0', 'cpu_softirq': '0', 'cpu_system': '0', 
>> 'cpu_user': '0', 'dateTime': '1705932906', 'dewpoint': '38.84', 
>> 'disk_total': '20425850880', 'disk_used': '10592813056', 
>> 'electricityLinky': '11', 'ET': 'None', 'extraHumid1': '66', 'extraHumid2': 
>> '92', 'extraHumid3': 'None', 'extraHumid4': '61', 'extraTemp1': '50.0', 
>> 'extraTemp2': '52.7', 'extraTemp3': 'None', 'extraTemp4': '66.506', 
>> 'extraTemp6': 'None', 'heatindex': '43.369', 'humidex': '45.5', 
>> 'inDewpoint': '52.05716422626888', 'inHumidity': '55', 'inTemp': '68.9', 
>> 'inTempDaikin': '68.0', 'kWhPAC': '0.827', 'maxSolarRad': 
>> '243.75104341154673', 'mem_total': '8286392320', 'mem_used': '1750052864', 
>> 'outHumidity': '77', 'outTemp': '45.5', 'outTempDaikin': '44.6', 
>> 'pressure': 'None', 'radiation': '76', 'rain': '0.0', 'rainRate': '0.0', 
&g

[weewx-user] Re: Running Ecowitt Gateway Driver bith as a driver and a service at the same time?

[gjr80]

It should just work. It works with a dual driver/service implementation on 
my test VM. 

Gary

On Wednesday 24 January 2024 at 07:50:29 UTC+10 michael.k...@gmx.at wrote:

> I will. Just curious: what to expect from b5? Will it behave differently 
> or produce other logs?
>
> gjr80 schrieb am Dienstag, 23. Januar 2024 um 22:19:27 UTC+1:
>
>> Try b5, same link as my previous post to download.
>>
>> Gary
>>
>> On Wednesday 24 January 2024 at 04:55:16 UTC+10 michael.k...@gmx.at 
>> wrote:
>>
>>> I ran weewxd manually, weewxd_console.log is the console output, 
>>> weewxd.log is from the log file. 
>>>
>>> gjr80 schrieb am Montag, 22. Januar 2024 um 20:40:14 UTC+1:
>>>
>>>> An old log entry remained after some earlier restructuring, try b4:
>>>>
>>>> wget 
>>>> https://raw.githubusercontent.com/gjr80/weewx-gw1000/master/bin/user/gw1000.py
>>>>
>>>> Gary
>>>>
>>>> On Tuesday 23 January 2024 at 04:55:32 UTC+10 michael.k...@gmx.at 
>>>> wrote:
>>>>
>>>>> When I configure like so
>>>>> [GW1000]
>>>>> debug_loop = True
>>>>>
>>>>> # This section is for the Ecowitt Gateway driver.
>>>>> 
>>>>> # How often to poll the API, default is every 20 seconds:
>>>>> poll_interval = 10
>>>>> ip_address = 10.0.1.85
>>>>> max_tries = 360
>>>>> 
>>>>> # The driver to use:
>>>>> driver = user.gw1000
>>>>>
>>>>> [GW1000Service]
>>>>> *debug_loop = True*
>>>>>
>>>>> # This section is for the Ecowitt Gateway driver.
>>>>> 
>>>>> # How often to poll the API, default is every 20 seconds:
>>>>> poll_interval = 10
>>>>> ip_address = 10.0.1.86
>>>>> max_tries = 360
>>>>> 
>>>>> # The driver to use:
>>>>> driver = user.gw1000
>>>>>
>>>>> [[field_map]]
>>>>> ws90_windDir = winddir
>>>>> ws90_windSpeed = windspeed
>>>>> ws90_windGust = gustspeed
>>>>> ws90_daymaxwind = daymaxwind
>>>>> ws90_uvradiation = uv
>>>>> ws90_UV = uvi
>>>>> ws90_luminosity = light
>>>>> p_rain = p_rain
>>>>> p_stormRain = p_rainevent
>>>>> p_rainRate = p_rainrate
>>>>> p_dayRain = p_rainday
>>>>> p_weekRain = p_rainweek
>>>>> p_monthRain = p_rainmonth
>>>>> p_yearRain = p_rainyear
>>>>>
>>>>> WeeWX exits with
>>>>>
>>>>> 2024-01-22 19:49:48 weewxd[119797] INFO weewxd: Initializing weewxd 
>>>>> version 5.0.0
>>>>> 2024-01-22 19:49:48 weewxd[119797] INFO weewxd: Command line: 
>>>>> /home/pi/weewx-venv/bin/weewxd
>>>>> 2024-01-22 19:49:48 weewxd[119797] INFO weewxd: Using Python 3.9.2 
>>>>> (default, Feb 28 2021, 17:03:44)
>>>>> [GCC 10.2.1 20210110]
>>>>> 2024-01-22 19:49:48 weewxd[119797] INFO weewxd: Located at 
>>>>> /home/pi/weewx-venv/bin/python3
>>>>> 2024-01-22 19:49:48 weewxd[119797] INFO weewxd: Platform 
>>>>> Linux-6.1.42-v8+-aarch64-with-glibc2.31
>>>>> 2024-01-22 19:49:48 weewxd[119797] INFO weewxd: Locale: 'de_AT.UTF-8'
>>>>> 2024-01-22 19:49:48 weewxd[119797] INFO weewxd: Entry path: 
>>>>> /home/pi/weewx-venv/lib/python3.9/site-packages/weewxd.py
>>>>> 2024-01-22 19:49:48 weewxd[119797] INFO weewxd: WEEWX_ROOT: 
>>>>> /home/pi/weewx-data
>>>>> 2024-01-22 19:49:48 weewxd[119797] INFO weewxd: Configuration file: 
>>>>> /home/pi/weewx-data/weewx.conf
>>>>> 2024-01-22 19:49:48 weewxd[119797] INFO weewxd: User module: 
>>>>> /home/pi/weewx-data/bin/user
>>>>> 2024-01-22 19:49:48 weewxd[119797] INFO weewxd: Debug: 0
>>>>> 2024-01-22 19:49:48 weewxd[119797] INFO weewx.engine: Loading station 
>>>>> type GW1000 (user.gw1000)
>>>>> 2024-01-22 19:49:48 weewxd[119797] INFO user.gw1000: GatewayDriver: 
>>>>> version is 0.6.0b2
>>>>> 2024-01-22 19:49:48 weewxd[119797] INFO user.gw1000:

[weewx-user] Re: Running Ecowitt Gateway Driver bith as a driver and a service at the same time?

[gjr80]

Try b5, same link as my previous post to download.

Gary

On Wednesday 24 January 2024 at 04:55:16 UTC+10 michael.k...@gmx.at wrote:

> I ran weewxd manually, weewxd_console.log is the console output, 
> weewxd.log is from the log file. 
>
> gjr80 schrieb am Montag, 22. Januar 2024 um 20:40:14 UTC+1:
>
>> An old log entry remained after some earlier restructuring, try b4:
>>
>> wget 
>> https://raw.githubusercontent.com/gjr80/weewx-gw1000/master/bin/user/gw1000.py
>>
>> Gary
>>
>> On Tuesday 23 January 2024 at 04:55:32 UTC+10 michael.k...@gmx.at wrote:
>>
>>> When I configure like so
>>> [GW1000]
>>> debug_loop = True
>>>
>>> # This section is for the Ecowitt Gateway driver.
>>> 
>>> # How often to poll the API, default is every 20 seconds:
>>> poll_interval = 10
>>> ip_address = 10.0.1.85
>>> max_tries = 360
>>> 
>>> # The driver to use:
>>> driver = user.gw1000
>>>
>>> [GW1000Service]
>>> *debug_loop = True*
>>>
>>> # This section is for the Ecowitt Gateway driver.
>>> 
>>> # How often to poll the API, default is every 20 seconds:
>>> poll_interval = 10
>>> ip_address = 10.0.1.86
>>> max_tries = 360
>>> 
>>> # The driver to use:
>>> driver = user.gw1000
>>>
>>> [[field_map]]
>>> ws90_windDir = winddir
>>> ws90_windSpeed = windspeed
>>> ws90_windGust = gustspeed
>>> ws90_daymaxwind = daymaxwind
>>> ws90_uvradiation = uv
>>> ws90_UV = uvi
>>> ws90_luminosity = light
>>> p_rain = p_rain
>>> p_stormRain = p_rainevent
>>> p_rainRate = p_rainrate
>>> p_dayRain = p_rainday
>>> p_weekRain = p_rainweek
>>> p_monthRain = p_rainmonth
>>> p_yearRain = p_rainyear
>>>
>>> WeeWX exits with
>>>
>>> 2024-01-22 19:49:48 weewxd[119797] INFO weewxd: Initializing weewxd 
>>> version 5.0.0
>>> 2024-01-22 19:49:48 weewxd[119797] INFO weewxd: Command line: 
>>> /home/pi/weewx-venv/bin/weewxd
>>> 2024-01-22 19:49:48 weewxd[119797] INFO weewxd: Using Python 3.9.2 
>>> (default, Feb 28 2021, 17:03:44)
>>> [GCC 10.2.1 20210110]
>>> 2024-01-22 19:49:48 weewxd[119797] INFO weewxd: Located at 
>>> /home/pi/weewx-venv/bin/python3
>>> 2024-01-22 19:49:48 weewxd[119797] INFO weewxd: Platform 
>>> Linux-6.1.42-v8+-aarch64-with-glibc2.31
>>> 2024-01-22 19:49:48 weewxd[119797] INFO weewxd: Locale: 'de_AT.UTF-8'
>>> 2024-01-22 19:49:48 weewxd[119797] INFO weewxd: Entry path: 
>>> /home/pi/weewx-venv/lib/python3.9/site-packages/weewxd.py
>>> 2024-01-22 19:49:48 weewxd[119797] INFO weewxd: WEEWX_ROOT: 
>>> /home/pi/weewx-data
>>> 2024-01-22 19:49:48 weewxd[119797] INFO weewxd: Configuration file: 
>>> /home/pi/weewx-data/weewx.conf
>>> 2024-01-22 19:49:48 weewxd[119797] INFO weewxd: User module: 
>>> /home/pi/weewx-data/bin/user
>>> 2024-01-22 19:49:48 weewxd[119797] INFO weewxd: Debug: 0
>>> 2024-01-22 19:49:48 weewxd[119797] INFO weewx.engine: Loading station 
>>> type GW1000 (user.gw1000)
>>> 2024-01-22 19:49:48 weewxd[119797] INFO user.gw1000: GatewayDriver: 
>>> version is 0.6.0b2
>>> 2024-01-22 19:49:48 weewxd[119797] INFO user.gw1000:  device address 
>>> is 10.0.1.85:45000
>>> 2024-01-22 19:49:48 weewxd[119797] INFO user.gw1000:  poll interval 
>>> is 10 seconds
>>> 2024-01-22 19:49:48 weewxd[119797] INFO user.gw1000: GatewayService: 
>>> version is 0.6.0b2
>>> 2024-01-22 19:49:48 weewxd[119797] INFO user.gw1000:  max age of API 
>>> data to be used is 60 seconds
>>> 2024-01-22 19:49:50 weewxd[119797] INFO user.gw1000: GatewayCollector 
>>> thread has been terminated
>>> 2024-01-22 19:49:50 weewxd[119797] CRITICAL weewxd: Caught unrecoverable 
>>> exception:
>>> 2024-01-22 19:49:50 weewxd[119797] CRITICAL weewxd:  
>>>  'GatewayService' object has no attribute 'field_map'
>>> 2024-01-22 19:49:50 weewxd[119797] CRITICAL weewxd:   Traceback 
>>> (most recent call last):
>>>
>>> 2024-01-22 19:49:50 weewxd[119797] CRITICAL weewxd: File 
>>> "/home/pi/weewx-venv/lib/python3.9/site-packages/weewxd.py", line 160, in

[weewx-user] Re: Running Ecowitt Gateway Driver bith as a driver and a service at the same time?

[gjr80]

An old log entry remained after some earlier restructuring, try b4:

wget 
https://raw.githubusercontent.com/gjr80/weewx-gw1000/master/bin/user/gw1000.py

Gary

On Tuesday 23 January 2024 at 04:55:32 UTC+10 michael.k...@gmx.at wrote:

> When I configure like so
> [GW1000]
> debug_loop = True
>
> # This section is for the Ecowitt Gateway driver.
> 
> # How often to poll the API, default is every 20 seconds:
> poll_interval = 10
> ip_address = 10.0.1.85
> max_tries = 360
> 
> # The driver to use:
> driver = user.gw1000
>
> [GW1000Service]
> *debug_loop = True*
>
> # This section is for the Ecowitt Gateway driver.
> 
> # How often to poll the API, default is every 20 seconds:
> poll_interval = 10
> ip_address = 10.0.1.86
> max_tries = 360
> 
> # The driver to use:
> driver = user.gw1000
>
> [[field_map]]
> ws90_windDir = winddir
> ws90_windSpeed = windspeed
> ws90_windGust = gustspeed
> ws90_daymaxwind = daymaxwind
> ws90_uvradiation = uv
> ws90_UV = uvi
> ws90_luminosity = light
> p_rain = p_rain
> p_stormRain = p_rainevent
> p_rainRate = p_rainrate
> p_dayRain = p_rainday
> p_weekRain = p_rainweek
> p_monthRain = p_rainmonth
> p_yearRain = p_rainyear
>
> WeeWX exits with
>
> 2024-01-22 19:49:48 weewxd[119797] INFO weewxd: Initializing weewxd 
> version 5.0.0
> 2024-01-22 19:49:48 weewxd[119797] INFO weewxd: Command line: 
> /home/pi/weewx-venv/bin/weewxd
> 2024-01-22 19:49:48 weewxd[119797] INFO weewxd: Using Python 3.9.2 
> (default, Feb 28 2021, 17:03:44)
> [GCC 10.2.1 20210110]
> 2024-01-22 19:49:48 weewxd[119797] INFO weewxd: Located at 
> /home/pi/weewx-venv/bin/python3
> 2024-01-22 19:49:48 weewxd[119797] INFO weewxd: Platform 
> Linux-6.1.42-v8+-aarch64-with-glibc2.31
> 2024-01-22 19:49:48 weewxd[119797] INFO weewxd: Locale: 'de_AT.UTF-8'
> 2024-01-22 19:49:48 weewxd[119797] INFO weewxd: Entry path: 
> /home/pi/weewx-venv/lib/python3.9/site-packages/weewxd.py
> 2024-01-22 19:49:48 weewxd[119797] INFO weewxd: WEEWX_ROOT: 
> /home/pi/weewx-data
> 2024-01-22 19:49:48 weewxd[119797] INFO weewxd: Configuration file: 
> /home/pi/weewx-data/weewx.conf
> 2024-01-22 19:49:48 weewxd[119797] INFO weewxd: User module: 
> /home/pi/weewx-data/bin/user
> 2024-01-22 19:49:48 weewxd[119797] INFO weewxd: Debug: 0
> 2024-01-22 19:49:48 weewxd[119797] INFO weewx.engine: Loading station type 
> GW1000 (user.gw1000)
> 2024-01-22 19:49:48 weewxd[119797] INFO user.gw1000: GatewayDriver: 
> version is 0.6.0b2
> 2024-01-22 19:49:48 weewxd[119797] INFO user.gw1000:  device address 
> is 10.0.1.85:45000
> 2024-01-22 19:49:48 weewxd[119797] INFO user.gw1000:  poll interval is 
> 10 seconds
> 2024-01-22 19:49:48 weewxd[119797] INFO user.gw1000: GatewayService: 
> version is 0.6.0b2
> 2024-01-22 19:49:48 weewxd[119797] INFO user.gw1000:  max age of API 
> data to be used is 60 seconds
> 2024-01-22 19:49:50 weewxd[119797] INFO user.gw1000: GatewayCollector 
> thread has been terminated
> 2024-01-22 19:49:50 weewxd[119797] CRITICAL weewxd: Caught unrecoverable 
> exception:
> 2024-01-22 19:49:50 weewxd[119797] CRITICAL weewxd:  
>  'GatewayService' object has no attribute 'field_map'
> 2024-01-22 19:49:50 weewxd[119797] CRITICAL weewxd:   Traceback 
> (most recent call last):
>
> 2024-01-22 19:49:50 weewxd[119797] CRITICAL weewxd: File 
> "/home/pi/weewx-venv/lib/python3.9/site-packages/weewxd.py", line 160, in 
> main
>
> 2024-01-22 19:49:50 weewxd[119797] CRITICAL weewxd:   engine = 
> weewx.engine.StdEngine(config_dict)
>
> 2024-01-22 19:49:50 weewxd[119797] CRITICAL weewxd: File 
> "/home/pi/weewx-venv/lib/python3.9/site-packages/weewx/engine.py", line 89, 
> in __init__
>
> 2024-01-22 19:49:50 weewxd[119797] CRITICAL weewxd:  
>  self.loadServices(config_dict)
>
> 2024-01-22 19:49:50 weewxd[119797] CRITICAL weewxd: File 
> "/home/pi/weewx-venv/lib/python3.9/site-packages/weewx/engine.py", line 
> 157, in loadServices
>
> 2024-01-22 19:49:50 weewxd[119797] CRITICAL weewxd:   obj = 
> weeutil.weeutil.get_object(svc)(self, config_dict)
>
> 2024-01-22 19:49:50 weewxd[119797] CRITICAL weewxd: File 
> "/home/pi/weewx-data/bin/user/gw1000.py", line 1389, in __init__
>
> 2024-01-22 19:49:50 weewxd[119797] CRITICAL weewxd:   loginf(' 
> field map is %s' % natural_sort_dict(self.field_map))
>
> 2024-

Re: [weewx-user] Re: Error with weewx-SteelSeries skin

[gjr80]

You have a heavily customised install. Do you get the error with the 
gauge-data template every report cycle? It would be useful to see the 
archive record used by WeeWX when the gauge-data template error occurs. If 
it is every report cycle then just run WeeWX directl 
<http://weewx.com/docs/4.10/usersguide.htm#Running_directly>y and post a 
copy of an archive record (line starting with REC:) as it appears on the 
console. If the error occurs occasionally you still need to run WeeWX 
directly, but you need to capture an archive record that results in the 
gauge-data template error.

Gary

On Sunday 21 January 2024 at 18:55:42 UTC+10 remy.l...@gmail.com wrote:

> Hello Gary and thank you for your response.
>
> I have put all the fields in my database below :
>
> [image: WX1.png]
>
> [image: WX2.png]
>
> [image: WX3.png]
>
> [image: WX4.png]
>
> Indeed the error perhaps comes from this side because I deleted fields 
> which were useless to me and added others...*However I do not think I 
> deleted "basic" fields such as those which are used in the skin...?*
>
> As for the WeeWX driver, this is also a driver that I created myself since 
> it directly retrieves the data from AWEKAS after my Bresser 7in1 weather 
> station sent it to their site (no USB output unfortunately) .
> But I don't think this driver is to blame since all the data entered into 
> the database is consistent!
> For information: -> https://meteomillau.go.yo.fr/index.html
>
> Concerning the configuration of Weewx, nothing more classic it seems to 
> me...:
>
>  [[SteelSeries]]
>  skin = ss
>  enable = False
>  HTML_ROOT = /var/www/html/weewx/ss
>  [[[Units]]]
>  Groups
>  group_altitude = meter
>  group_pressure = hPa
>  group_rain = mm
>  group_rainRate = mm_per_hour
>  group_speed = km_per_hour
>  group_temperature = degree_C
>  StringFormats
>  degree_C = %.1f
>  degree_F = %.1f
>  degree_compass = %.0f
>  foot = %.0f
>  hPa = %.1f
>  inHg = %.3f
>  inch = %.2f
>  inch_per_hour = %.2f
>  km = %.1f
>  km_per_hour = %.0f
>  knot = %.0f
>  mbar = %.1f
>  meter = %.0f
>  meter_per_second = %.1f
>  mile = %.1f
>  mile_per_hour = %.0f
>  mm = %.1f
>  mmHg = %.1f
>      mm_per_hour = %.1f
>  percent = %.0f
>  uv_index = %.1f
>  watt_per_meter_squared = %.0f
>
> Le dimanche 21 janvier 2024 à 05:52:36 UTC+1, gjr80 a écrit :
>
>> The error message is very non-specific (as Cheetah errors often are), 
>> though the error is likely caused by a required field being None or 
>> non-existent. When asking for log extract I was not looking for errors in 
>> the log, but rather looking for details of your setup including station 
>> type, driver and WeeWX configuration that would hopefully give a clue as to 
>> the field causing the problem. Without any further information there is 
>> little else I can add.
>>
>> Gary
>> On Saturday 20 January 2024 at 20:30:04 UTC+10 remy.l...@gmail.com wrote:
>>
>>> Thank-you...
>>> Sorry but in the syslog, there is only that...
>>> And systematically same error at each packetsloop !
>>> if the option is disabled in weewx.conf obviously no problem. :-(
>>>
>>> Jan 16 13:56:19 localhost wee_reports[62658] INFO user.alarm_multi: 
>>> Alarm set for expression 18: "extraTemp3 is not None and extraTemp3 >= 80.6"
>>> Jan 16 13:56:19 localhost wee_reports[62658] INFO user.healthchecks: 
>>> healthchecks: Using url 
>>> https://hc-ping.com/---Spw/weewx-record
>>> Jan 16 13:56:20 localhost wee_reports[62658] INFO user.historygenerator: 
>>> historygenerator.py: Generated 6 tables in 0.42 seconds
>>> Jan 16 13:56:32 localhost wee_reports[62658] INFO 
>>> weewx.cheetahgenerator: Generated 13 files for report SeasonsReport2 in 
>>> 12.56 seconds
>>> Jan 16 13:56:35 localhost wee_reports[62658] INFO weewx.imagegenerator: 
>>> Generated 28 images for report SeasonsReport2 in 2.95 seconds
>>> Jan 16 13:56:35 localhost wee_reports[62658] INFO weewx.reportengine: 
>>> Copied 5 files to /var/www/html/weewx
>>> Jan 16 13:56:35 localhost 

[weewx-user] Re: Running Ecowitt Gateway Driver bith as a driver and a service at the same time?

[gjr80]

g': '4', 'wh31_ch8_batt': '0', 
> 'wh31_ch8_sig': '4', 'wh32_batt': '0', 'wh32_sig': '4', 'wh40_batt': 
> '1.44', 'wh40_sig': '4', 'wh57_batt': '5', 'wh57_sig': '4', 'windchill': 
> '-5.128915747986651', 'windDir': '206', 'windGust': '4.2', 'windrun': 
> 'None', 'windSpeed': '2.7', '*ws90_batt*': '3.28', 'ws90_daymaxwind': 
> '7.7', 'ws90_luminosity': '0.0', 'ws90_sig': '4', 'ws90_UV': '0', 
> 'ws90_uvradiation': '0.0', '*ws90_windDir*': '206', 'ws90_windGust': 
> '2.6', 'ws90_windSpeed': '2.1', 'yearRain': '50.4'
>
> But On RPi4, polling the devices seems to drift apart quite quickly, 
> producing individual LOOP packets, containing the individual values (I 
> haven't observed that happening on my Desktop, so this might be connected 
> to CPU power, maybe it happens after a longer period of time) 
> These LOOP packets contain values from the device configured in 
> [GW1000Service] and from the device configured in [ GW1000 ] in that 
> order, but *without values from the configured*  [[field_map]] in 
> [GW1000Service] - I didn't expect that.  
> *(Maybe also worth noting is that the batt/sig values from my WS68 are 
> tagged as wh68, which I consider an undesired typo in the driver's map)*
>
> LOOP:   2024-01-22 06:16:14 CET (1705900574) 'altimeter': 
> '1025.4477187548832', 'appTemp': '-6.463423533619011', 'barometer': 
> '1028.5013923390995', 'cloudbase': '1041.4809012741189', 'dateTime': 
> '1705900574', 'daymaxwind': '6.6', 'dayRain': '0.0', 'dewpoint': 
> '-6.533418604408247', 'ET': 'None', 'extraHumid6': '59', 'extraHumid7': 
> '61', 'extraHumid8': '57', 'extraTemp6': '14.7', 'extraTemp7': '20.5', 
> 'extraTemp8': '21.3', 'heatindex': '-1.5994', 'humidex': 
> '-1.6', 'inDewpoint': '9.08853654596964', 'inHumidity': '51', 'inTemp': 
> '19.5', 'lightning_distance': 'None', 'lightning_last_det_time': 
> '1705345360', 'lightning_strike_count': '0', 'lightningcount': '0', 
> 'luminosity': '0.0', 'maxSolarRad': '0.0', 'monthRain': '50.4', 
> 'outHumidity': '69', 'outTemp': '-1.6', 'p_dayRain': '0.0', 'p_monthRain': 
> '26.5', 'p_rain': '0.0', 'p_rainRate': '0.0', 'p_stormRain': '0.0', 
> 'p_weekRain': '0.0', 'p_yearRain': '26.5', 'pressure': '973.1', 
> 'radiation': '0.0', 'rain': '0.0', 'rainRate': '0.0', 'relbarometer': 
> '1025.9', 'stormRain': '0.0', 'usUnits': '17', 'UV': '0', 'uvradiation': 
> '0.0', 'weekRain': '0.0', 'wh31_ch6_batt': '0', 'wh31_ch6_sig': '4', 
> 'wh31_ch7_batt': '0', 'wh31_ch7_sig': '4', 'wh31_ch8_batt': '0', 
> 'wh31_ch8_sig': '4', 'wh32_batt': '0', 'wh32_sig': '4', 'wh40_batt': 
> '1.44', 'wh40_sig': '4', 'wh57_batt': '5', 'wh57_sig': '4', 'windchill': 
> '-5.422365775103767', 'windDir': '181', 'windGust': '4.2', 'windrun': 
> 'None', 'windSpeed': '3.0', '*ws90_batt*': '3.28', 'ws90_sig': '4', 
> 'yearRain': '50.4'
> LOOP:   2024-01-22 06:16:14 CET (1705900574) 'altimeter': 
> '1025.5520572032206', 'appTemp': '-5.833423533619011', 'barometer': 
> '1028.6070856277995', 'cloudbase': &#x

Re: [weewx-user] Re: Error with weewx-SteelSeries skin

[gjr80]

The error message is very non-specific (as Cheetah errors often are), 
though the error is likely caused by a required field being None or 
non-existent. When asking for log extract I was not looking for errors in 
the log, but rather looking for details of your setup including station 
type, driver and WeeWX configuration that would hopefully give a clue as to 
the field causing the problem. Without any further information there is 
little else I can add.

Gary
On Saturday 20 January 2024 at 20:30:04 UTC+10 remy.l...@gmail.com wrote:

> Thank-you...
> Sorry but in the syslog, there is only that...
> And systematically same error at each packetsloop !
> if the option is disabled in weewx.conf obviously no problem. :-(
>
> Jan 16 13:56:19 localhost wee_reports[62658] INFO user.alarm_multi: Alarm 
> set for expression 18: "extraTemp3 is not None and extraTemp3 >= 80.6"
> Jan 16 13:56:19 localhost wee_reports[62658] INFO user.healthchecks: 
> healthchecks: Using url 
> https://hc-ping.com/---Spw/weewx-record
> Jan 16 13:56:20 localhost wee_reports[62658] INFO user.historygenerator: 
> historygenerator.py: Generated 6 tables in 0.42 seconds
> Jan 16 13:56:32 localhost wee_reports[62658] INFO weewx.cheetahgenerator: 
> Generated 13 files for report SeasonsReport2 in 12.56 seconds
> Jan 16 13:56:35 localhost wee_reports[62658] INFO weewx.imagegenerator: 
> Generated 28 images for report SeasonsReport2 in 2.95 seconds
> Jan 16 13:56:35 localhost wee_reports[62658] INFO weewx.reportengine: 
> Copied 5 files to /var/www/html/weewx
> Jan 16 13:56:35 localhost wee_reports[62658] INFO weewx.reportengine: 
> Copied 6 files to /var/www/html/weewx/ss
> Jan 16 13:56:36 localhost wee_reports[62658] ERROR weewx.cheetahgenerator: 
> Evaluation of template /etc/weewx/skins/ss/gauge-data.txt.tmpl failed with 
> exception ''
> Jan 16 13:56:36 localhost wee_reports[62658] ERROR weewx.cheetahgenerator: 
>  Ignoring template /etc/weewx/skins/ss/gauge-data.txt.tmpl
> Jan 16 13:56:36 localhost wee_reports[62658] ERROR weewx.cheetahgenerator: 
>  Reason: 'UnknownType' object is not subscriptable
> Jan 16 13:56:36 localhost wee_reports[62658] ERROR weewx.cheetahgenerator: 
>   Traceback (most recent call last):
> Jan 16 13:56:36 localhost wee_reports[62658] ERROR weewx.cheetahgenerator: 
> File "/usr/share/weewx/weewx/cheetahgenerator.py", line 348, in 
> generate
> Jan 16 13:56:36 localhost wee_reports[62658] ERROR weewx.cheetahgenerator: 
>   unicode_string = compiled_template.respond()
> Jan 16 13:56:36 localhost wee_reports[62658] ERROR weewx.cheetahgenerator: 
> File "_etc_weewx_skins_ss_gauge_data_txt_tmpl.py", line 142, in 
> respond
> Jan 16 13:56:36 localhost wee_reports[62658] ERROR weewx.cheetahgenerator: 
> File "/usr/lib/python3/dist-packages/Cheetah/Template.py", line 
> 1446, in getVar
> Jan 16 13:56:36 localhost wee_reports[62658] ERROR weewx.cheetahgenerator: 
>   return valueFromSearchList(
> Jan 16 13:56:36 localhost wee_reports[62658] ERROR weewx.cheetahgenerator: 
> File "/usr/share/weewx/weewx/units.py", line 1094, in raw
> Jan 16 13:56:36 localhost wee_reports[62658] ERROR weewx.cheetahgenerator: 
>   return self.value_t[0]
> Jan 16 13:56:36 localhost wee_reports[62658] ERROR weewx.cheetahgenerator: 
>   TypeError: 'UnknownType' object is not subscriptable
> Jan 16 13:56:36 localhost wee_reports[62658] INFO weewx.cheetahgenerator: 
> Generated 1 files for report SteelSeries in 0.76 seconds
> Jan 16 13:56:37 localhost wee_reports[62658] INFO weewx.imagegenerator: 
> Generated 11 images for report SteelSeries in 0.91 seconds
> Jan 16 13:56:40 localhost wee_reports[62658] INFO weewx.cheetahgenerator: 
> Generated 2 files for report wxobs in 3.66 seconds
> Jan 16 13:56:40 localhost wee_reports[62658] INFO weewx.reportengine: 
> Copied 6 files to /var/www/html/weewx/wxobs
> Jan 16 13:56:54 localhost wee_reports[62658] INFO weewx.reportengine: 
> ftpgenerator: Ftp'd 54 files in 13.22 seconds
>
> *Rémy LAVABRE*
>
>
> Le sam. 20 janv. 2024 à 10:51, gjr80  a écrit :
>
>> Impossible to say with such a small log extract. Please refer to the 
>> section How to get a good, useful log 
>> <https://github.com/weewx/weewx/wiki/Help!-Posting-to-weewx-user#how-to-get-a-good-useful-log>
>>  
>> on the Help! Posting to weewx user wiki page 
>> <https://github.com/weewx/weewx/wiki/Help!-Posting-to-weewx-user#how-to-get-a-good-useful-log>
>> .
>>
>> Gary
>> On Saturday 20 January 2024 at 19:40:47 UTC+10 remy.l...@gmail.com wrote:
>>
>>> -> https://github.com/gjr80/weewx-s

[weewx-user] Re: Error with weewx-SteelSeries skin

[gjr80]

Impossible to say with such a small log extract. Please refer to the 
section How to get a good, useful log 
<https://github.com/weewx/weewx/wiki/Help!-Posting-to-weewx-user#how-to-get-a-good-useful-log>
 
on the Help! Posting to weewx user wiki page 
<https://github.com/weewx/weewx/wiki/Help!-Posting-to-weewx-user#how-to-get-a-good-useful-log>
.

Gary
On Saturday 20 January 2024 at 19:40:47 UTC+10 remy.l...@gmail.com wrote:

> -> https://github.com/gjr80/weewx-steelseries
> Good morning,
>
> I don't understand the reason and why of the error that occurs with my 
> version 4.10.2 of weewx and the 'SteelSeries' Skin.
>
> Can anyone help me and tell me what's going on?
> THANKS
>
>
>
> Jan 20 10:31:21 localhost weewx[16495] ERROR weewx.cheetahgenerator:  
> Ignoring template /etc/weewx/skins/ss/gauge-data.txt.tmpl
> Jan 20 10:31:21 localhost weewx[16495] ERROR weewx.cheetahgenerator:  
> Reason: 'UnknownType' object is not subscriptable
> Jan 20 10:31:21 localhost weewx[16495] ERROR weewx.cheetahgenerator:  
>  Traceback (most recent call last):
> Jan 20 10:31:21 localhost weewx[16495] ERROR weewx.cheetahgenerator:  
>File "/usr/share/weewx/weewx/cheetahgenerator.py", line 348, in generate
> Jan 20 10:31:21 localhost weewx[16495] ERROR weewx.cheetahgenerator:  
>  unicode_string = compiled_template.respond()
> Jan 20 10:31:21 localhost weewx[16495] ERROR weewx.cheetahgenerator:  
>File "_etc_weewx_skins_ss_gauge_data_txt_tmpl.py", line 142, in respond
> Jan 20 10:31:21 localhost weewx[16495] ERROR weewx.cheetahgenerator:  
>File "/usr/lib/python3/dist-packages/Cheetah/Template.py", line 1446, in 
> getVar
> Jan 20 10:31:21 localhost weewx[16495] ERROR weewx.cheetahgenerator:  
>  return valueFromSearchList(
> Jan 20 10:31:21 localhost weewx[16495] ERROR weewx.cheetahgenerator:  
>File "/usr/share/weewx/weewx/units.py", line 1094, in raw
> Jan 20 10:31:21 localhost weewx[16495] ERROR weewx.cheetahgenerator:  
>  return self.value_t[0]
> Jan 20 10:31:21 localhost weewx[16495] ERROR weewx.cheetahgenerator:  
>  TypeError: 'UnknownType' object is not subscriptable
>

-- 
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/18ebb63d-7160-4411-8e3d-3ecab1cf3e86n%40googlegroups.com.

[weewx-user] Re: Running Ecowitt Gateway Driver bith as a driver and a service at the same time?

[gjr80]

The Gateway driver has supported simultaneous driver/service operation 
since v0.5.0b5. It is not a configuration I recommend due to the fragility 
of the configuration (if the driver crashes or the device using the driver 
fails/locks up data from the service device is also lost) and the ease of 
running dual WeeWX instances on the same device (particularly under WeeWX 
v5).

Notwithstanding, if you wish to use simultaneous driver/service operation 
the driver configuration is placed under the [GW1000] stanza as normal and 
the service configuration is placed under the [GW1000Service] stanza. 
Otherwise the driver and service are configured as per independent 
operation.

Finally, be aware this is not a configuration I routinely, in fact I 
suspect it has not bee touched since it was added to v0.5.0b5 so there may 
be issues.

Gary

On Saturday 20 January 2024 at 17:52:04 UTC+10 michael.k...@gmx.at wrote:

> The empty queue is probably because of running it in WSL and being in a 
> different IP range than the Console:
> 2024-01-19 18:47:39 weewxd[13771] DEBUG user.interceptor: empty queue
>
> $ ip addr
> 2: eth0:  mtu 1500 qdisc mq state UP 
> group default qlen 1000
> link/ether 00:15:5d:a1:b2:53 brd ff:ff:ff:ff:ff:ff
> inet 172.19.239.191/20 brd 172.19.239.255 scope global eth0
>valid_lft forever preferred_lft forever
> inet6 fe80::215:5dff:fea1:b253/64 scope link 
>valid_lft forever preferred_lft forever
>
> And the console has 10.0.1.106
>
> I need to set up WSL to be in the same network or try this on another 
> machine.
>
> Anyway, @grj80: have you ever considered collecting data from more than 
> one ecowitt console device with the driver? For me this would make perfect 
> sense, but I can very well understand, if it doesn't to you :D
> michael.k...@gmx.at schrieb am Freitag, 19. Januar 2024 um 18:48:05 UTC+1:
>
>> Yes, it's possible. 
>> 2024-01-19 18:27:35 weewxd[5855] DEBUG user.gw1000: Next update in 9 
>> seconds
>> 2024-01-19 18:27:35 weewxd[5855] DEBUG user.gw1000: Next update in 9 
>> seconds
>> LOOP:   2024-01-19 18:27:35 CET (1705685255) 'altimeter': 
>> '1023.2565915245989', 'appTemp': '-4.6378894597484965', 'barometer': 
>> '1026.3446847507096', 'cloudbase': '972.4294835518078', 'dateTime': 
>> '1705685255', 'daymaxwind': '2.1', 'dayRain': '4.7', 'dewpoint': 
>> '-6.267050581532717', 'ET': 'None', 'extraHumid6': '62', 'extraHumid7': 
>> '61', 'extraHumid8': '58', 'extraTemp6': '14.8', 'extraTemp7': '19.9', 
>> 'extraTemp8': '20.6', 'heatindex': '-1.9008', 'humidex': 
>> '-1.9', 'inDewpoint': '12.462345522375951', 'inHumidity': '60', 'inTemp': 
>> '20.5', 'lightning_distance': 'None', 'lightning_last_det_time': 
>> '1705345360', 'lightning_strike_count': '0', 'lightningcount': '0', 
>> 'luminosity': '0.0', 'maxSolarRad': '0.0', 'monthRain': '50.4', 
>> 'outHumidity': '72', 'outTemp': '-1.9', 'p_dayRain': '0.0', 'p_monthRain': 
>> '26.5', 'p_rain': '0.0', 'p_rainRate': '0.0', 'p_stormRain': '0.0', 
>> 'p_weekRain': '11.8', 'p_yearRain': '26.5', 'pressure': '971.0', 
>> 'radiation': '0.0', 'rain': '0.0', 'rainRate': '0.0', 'relbarometer': 
>> '1023.8', 'stormRain': '0.0', 'usUnits': '17', 'UV': '0', 'uvradiation': 
>> '0.0', 'weekRain': '15.2', 'wh31_ch6_batt': '0', 'wh31_ch6_sig': '4', 
>> 'wh31_ch7_batt': '0', 'wh31_ch7_sig': '4', 'wh31_ch8_batt': '0', 
>> 'wh31_ch8_sig': '4', 'wh32_batt': '0', 'wh32_sig': '4', 'wh40_batt': 
>> '1.45', 'wh40_sig': '4', 'wh57_batt': '5', 'wh57_sig': '4', 'windchill': 
>> '-1.9008', 'windDir': 'None', 'windGust': '1.3', 'windrun': 
>> 'None', 'windSpeed': '0.0', 'ws90_batt': '3.28', 'ws90_sig': '4', 
>> 'yearRain': '50.4'
>>
>> But why would anybody want to do this? I have two GW2000 devices and want 
>> to store and show data of as many of my sensor possible in a single weewx 
>> instance. Yet configuring the driver both, as driver and a service at the 
>> same time, seems to work as I hoped at least foor LOOP: two device queries, 
>> on LOOP data.
>>
>> The question now: is it possible to configure the driver/service in a 
>> way, they uses their own ip_address and is it possible to map the 
>> Wind/Dir/Gust of the WS90 bound to the one GW2000, to e.g. 
>> us_windSpeed/us_windDir/us_windGust (us for ultrasonic) just like p_rain 
>> for the haptic array?
>>
>> Or isn't this possible and do I have to combine the Interceptor driver 
>> with the Ecowitt Gateway Driver, one as a service, the other as a Driver to 
>> achieve this? If yes, how could this be possible, I tried it with 
>> Interceptor as a driver and Ecowitt Gateway Driver as a Service and get not 
>> device data:
>> 2024-01-19 18:46:59 weewxd[13771] DEBUG user.interceptor: empty queue
>> 2024-01-19 18:47:07 weewxd[13771] DEBUG user.gw1000: Next update in 9 
>> seconds
>> 2024-01-19 18:47:09 weewxd[13771] DEBUG user.interceptor: empty queue
>> 2024-01-19 18:47:16 weewxd[13771] DEBUG user.gw1000: Next update in 9 
>> seconds
>> 2024-01-19 18:47:19

[weewx-user] Re: import data into Weewx 5.0 error

[gjr80]

This problem is due to small bug in our version comparison. This will be 
fixed in the next release. If you wish to use weectl import before the next 
release you have a couple of options:

1. you can download a file containing the fix for this problem and replace 
your v5.0.0 version of this file. To do this:

- download the patched file using:

  wget -P 
/var/tmp 
https://raw.githubusercontent.com/weewx/weewx/master/src/weectllib/import_actions.py

- locate your installed v5.0.0 version of import_actions.py, it will be in 
the weectllib directory, but where that is depends on your WeeWX install 
type. Where to find things  in 
the User's Guide will help. For a package install it should be in 
/usr/share/weewx/. For a pip install it could be in any one of a number of 
locations, refer to Location of executables in a pip install 

 
for help. For a pip/git install it will be in the src directory of the 
directory in which you cloned the WeeWX repo.

- once located replace your existing import_actions.py with the downloaded 
version:

  cp /var/tmp/import_actions.py /usr/share/weewx/weectllib/

 adjusting the destination directory to suit.

- try the import again

2. you can apply the fix yourself to your installed import_actions.py. To 
do this:

- locate your installed import_actions.py using the second step above.

- once found, open import_actions.py for editing, locate the following line 
(circa line 26):

  REQUIRED_WEEWX = "5.0.0b15"

 and change it to read:

  REQUIRED_WEEWX = "5.0.0"

- save import_actions.py

- try the import again

Alternatively, you can wait and update to the next release (likely a bug 
fix in the not too distant future) and perform your import then.

Gary
On Friday 19 January 2024 at 08:40:14 UTC+10 bhouseski wrote:

> Hey all, I am trying to get old weatherlink data into my Weewx 5.0 setup. 
>  the I run the appropriate command:
>
> 'weectl import --import-config=/var/tmp/csv.conf --dry-run'
>
>  I get the following:
>
> 'WeeWX 5.0.0b15 or greater is required, found 5.0.0. Nothing done, 
> exiting.'
>
>
> Not sure what this means.  isn't 5.0.0b15 a beta version?  I updated to 
> the latest version when I did a general update on my RPi 4.
>
>
> Mike
>

-- 
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/0482a500-4a96-4c14-8b8f-0ac5a3d87ca8n%40googlegroups.com.

[weewx-user] Re: Web page will not refresh after update to 5.0

[gjr80]

Unfortunately the log extracts you have provided lack detail and are 
truncated and consequently of not much help. Please try again noting the 
advice in the *How to get a good, useful log* section 

 
of the *Help! Posting to weewx user* wiki page 
. Make 
sure your log extract covers the full WeeWX startup and at least two 
archive intervals of activity. 

Gary
On Thursday 18 January 2024 at 11:20:05 UTC+10 wil...@gmail.com wrote:

> After an update of Weewx 4.10.2  to 5.0, the data on the web page 
>
> http:///weewx/index.html
>
> no longer refreshes.
>
> Summary data:
>
> uname -a
> Linux linux-3wjh 5.14.21-150500.55.39-default #1 SMP PREEMPT_DYNAMIC Tue 
> Dec 5 10:06:35 UTC 2023 (2e4092e) x86_64 x86_64 x86_64 GNU/Linux
>
> openSUSE Leap  15.5
>
> ~> weewxd --version
> 5.0.0
>
> ~> python3 --version
> Python 3.6.15
>
> systemctl status weewx
> ● weewx.service - WeeWX
>  Loaded: loaded (/usr/lib/systemd/system/weewx.service; enabled; 
> vendor preset: disabled)
>  Active: active (running) since Wed 2024-01-17 19:21:18 EST; 16min ago
>Docs: https://weewx.com/docs
>Main PID: 9772 (python3)
>   Tasks: 1 (limit: 4915)
>  CGroup: /system.slice/weewx.service
>  └─ 9772 python3 /usr/share/weewx/weewxd.py 
> /etc/weewx/weewx.conf
>
> Weewx shows to be running OK as seen in the attached logs file.
>
> If I roll back to 4.10.2, the web page refreshes as normal.
>
>
>

-- 
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/04137fca-b071-4cc8-a12c-42952a23033cn%40googlegroups.com.

Re: [weewx-user] Re: Rain data not displaying

[gjr80]

weectl report run will run the reports against the current database, most 
likely as yet you have no archive data using the new mapping in your 
database. You need to wait until the end of an archive period before you 
will see rain data in your archive. And then remember that some plots are 
only generated every hour, three hours or once a day so some plots may not 
change for a while. You can delete the plots to force regeneration.

Gary


On Wednesday 17 January 2024 at 12:30:09 UTC+10 dale.c...@gmail.com wrote:

> Which gives me this in weewx.cfg:
>
> [GW1000]
> # This section is for the Ecowitt Gateway driver.
>
> # How often to poll the API, default is every 20 seconds:
> poll_interval = 10
>
> # The driver to use:
> driver = user.gw1000
> ip_address = 192.168.50.143
> port = 45000
>
>
> [[field_map_extensions]]
> rain = p_rain
> stormRain = p_rainevent
> rainRate = p_rainrate
> dayRain = p_rainday
> weekRain = p_rainweek
> monthRain = p_rainmonth
> yearRain = p_rainyear
>
>
> Executed weectl report run, reloaded web page.  No new rain graphs.
>
> chatham.org/weewx
>
>
> On 1/16/2024 8:05 PM, gjr80 wrote:
>
> You need to locate weewx.conf, open it for editing, locate the [GW1000] 
> stanza and then add a [[field_map_extension]] stanza with the necessary 
> entries. 
>
> Gary 
>
> On Wednesday 17 January 2024 at 11:47:29 UTC+10 dale.c...@gmail.com wrote:
>
> OK, found this:
> Users with a piezo rainfall gauge only 
>
> Users whose only connected rainfall gauge is a WS90 sensor suite and are 
> using the default field map will see the piezo rainfall data appear in 
> WeeWX loop packets in fields starting with 'p_' as per the above table. 
> Such users that want the piezo rainfall data to appear in the 'standard' 
> WeeWX rainfall fields will need to use a custom field map. The easiest 
> way to create a custom field map for the piezo rain is to add suitable 
> entries under the [GW1000] [[field_map_extensions]] stanza. A suitable 
> custom field map to map piezo rain to the 'standard' WeeWX rainfall fields 
> may look something like:
> [GW1000]  [[field_map_extensions]] rain = p_rain stormRain = 
> p_rainevent rainRate = p_rainrate dayRain = p_rainday weekRain = p_rainweek 
> monthRain = p_rainmonth yearRain = p_rainyear 
>
> Which seems to address the problem. Only question is where does it go? I 
> grepped for field_map_extensions and found nothing within brackets. 
>
> -- 
>
> 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/6c5abbf2-1d12-4340-9f53-556b910858fbn%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/weewx-user/6c5abbf2-1d12-4340-9f53-556b910858fbn%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/03995c0b-6d21-4605-9339-2cca216040e9n%40googlegroups.com.

Re: [weewx-user] Re: Rain data not displaying

[gjr80]

You need to locate weewx.conf, open it for editing, locate the [GW1000] 
stanza and then add a [[field_map_extension]] stanza with the necessary 
entries.

Gary 

On Wednesday 17 January 2024 at 11:47:29 UTC+10 dale.c...@gmail.com wrote:

OK, found this:
Users with a piezo rainfall gauge only 

Users whose only connected rainfall gauge is a WS90 sensor suite and are 
using the default field map will see the piezo rainfall data appear in 
WeeWX loop packets in fields starting with 'p_' as per the above table. 
Such users that want the piezo rainfall data to appear in the 'standard' 
WeeWX rainfall fields will need to use a custom field map. The easiest way 
to create a custom field map for the piezo rain is to add suitable entries 
under the [GW1000] [[field_map_extensions]] stanza. A suitable custom field 
map to map piezo rain to the 'standard' WeeWX rainfall fields may look 
something like:
[GW1000]  [[field_map_extensions]] rain = p_rain stormRain = 
p_rainevent rainRate = p_rainrate dayRain = p_rainday weekRain = p_rainweek 
monthRain = p_rainmonth yearRain = p_rainyear 

Which seems to address the problem. Only question is where does it go? I 
grepped for field_map_extensions and found nothing within brackets. 

-- 
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/6c5abbf2-1d12-4340-9f53-556b910858fbn%40googlegroups.com.

[weewx-user] Re: Rain data not displaying

[gjr80]

Did you look at the driver wiki <https://github.com/gjr80/weewx-gw1000/wiki>? 
The driver wiki has a FAQ 
<https://github.com/gjr80/weewx-gw1000/wiki/Frequently-asked-questions#sensors> 
that addresses this very question.

It would be nice if the driver could auto-configure the rainfall source. 
Whilst the driver has available the information needed to do this there are 
far too many corner cases to be able to implement this in a robust manner. 
For this reason piezo rain gauge users will (likely) need to manually 
configure their rainfall mapping.

Gary

On Wednesday 17 January 2024 at 02:43:46 UTC+10 dale.c...@gmail.com wrote:

> Data from log:
> Jan 16 09:28:28 fedora-workstation weewxd[3577]: INFO user.gw1000: 
> GatewayDriver: Packet 2024-01-16 09:28:27 CST (1705418907): {'dateTime': 
> '1705418907', 'daymaxwind': '7.2', 'extraHumid1': '26', 'extraHumid2': 
> '11', 'extraHumid3': '12', 'extraHumid4': '12', 'extraHumid5': '13', 
> 'extraTemp1': '0.9', 'extraTemp2': '23.9', 'extraTemp3': '22.7', 
> 'extraTemp4': '23.7', 'extraTemp5': '22.7', 'inHumidity': '17', 'inTemp': 
> '16.1', 'lightning_distance': '31', 'lightning_last_det_time': 
> '1705040128', 'lightning_strike_count': '0', 'lightningcount': '0', 
> 'luminosity': '8410.0', 'outHumidity': '52', 'outTemp': '-9.9', 
> 'p_dayRain': '0.0', 'p_monthRain': '26.5', 'p_rain': '0.0', 'p_rainRate': 
> '0.0', 'p_stormRain': '0.0', 'p_weekRain': '0.0', 'p_yearRain': '26.5', 
> 'pressure': '1011.7', 'relbarometer': '1011.7', 'usUnits': '17', 'UV': '0', 
> 'uvradiation': '0.0', 'wh31_ch1_batt': '0', 'wh31_ch1_sig': '4', 
> 'wh31_ch2_batt': '0', 'wh31_ch2_sig': '4', 'wh31_ch3_batt': '0', 
> 'wh31_ch3_sig': '4', 'wh31_ch4_batt': '0', 'wh31_ch4_sig': '4', 
> 'wh31_ch5_batt': '0', 'wh31_ch5_sig': '4', 'wh57_batt': '4', 'wh57_sig': 
> '4', 'windDir': '302', 'windGust': '1.9', 'windSpeed': '0.6', 'ws90_batt': 
> '3.06', 'ws90_sig': '4'}
>
>
> Jan 16 09:28:28 fedora-workstation weewxd[3577]:
> INFO user.gw1000: GatewayDriver: Packet 2024-01-16 09:28:27 CST 
> (1705418907):
> {
>  'dateTime': '1705418907',
>  'daymaxwind': '7.2',
>  'extraHumid1': '26',
>  'extraHumid2': '11',
>  'extraHumid3': '12',
>  'extraHumid4': '12',
>  'extraHumid5': '13',
>  'extraTemp1': '0.9',
>  'extraTemp2': '23.9',
>  'extraTemp3': '22.7',
>  'extraTemp4': '23.7',
>  'extraTemp5': '22.7',
>  'inHumidity': '17',
>  'inTemp': '16.1',
>  'lightning_distance': '31',
>  'lightning_last_det_time': '1705040128',
>  'lightning_strike_count': '0',
>  'lightningcount': '0',
>  'luminosity': '8410.0',
>  'outHumidity': '52',
>  'outTemp': '-9.9',
>  'p_dayRain': '0.0',
>  'p_monthRain': '26.5',
>  'p_rain': '0.0',
>  'p_rainRate': '0.0',
>  'p_stormRain': '0.0',
>  'p_weekRain': '0.0',
>  'p_yearRain': '26.5',
>  'pressure': '1011.7',
>  'relbarometer': '1011.7',
>  'usUnits': '17',
>  'UV': '0',
>  'uvradiation': '0.0',
>  'wh31_ch1_batt': '0',
>  'wh31_ch1_sig': '4',
>  'wh31_ch2_batt': '0',
>  'wh31_ch2_sig': '4',
>  'wh31_ch3_batt': '0',
>  'wh31_ch3_sig': '4',
>  'wh31_ch4_batt': '0',
>  'wh31_ch4_sig': '4',
>  'wh31_ch5_batt': '0',
>  'wh31_ch5_sig': '4',
>  'wh57_batt': '4',
>  'wh57_sig': '4',
>  'windDir': '302',
>  'windGust': '1.9',
>  'windSpeed': '0.6',
>  'ws90_batt': '3.06',
>  'ws90_sig': '4'
> }
>
> Note, rain reporting piezo data
>
>  driver = user.gw1000
>
> Modified Seasons skin
>
> Installed via RPM, update
>
> I suspect this has to do with using piezo rain data and weewx is expecting 
> tipping bucket data.  However, I can't seem to find where t_rain* or 
> p_rain* is configured.
>

-- 
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/5491cffa-7f7e-405b-8d45-0285df809a62n%40googlegroups.com.

Re: [weewx-user] Re: Saratoga Extension Error After Upgrade to 5.0

[gjr80]

Just to wrap this up I have released weewx-saratoga v0.1.8 
<https://github.com/gjr80/weewx-saratoga/releases> that fixes this bug and 
a couple of other unrelated ones. 

Gary

On Tuesday 16 January 2024 at 08:09:33 UTC+10 Tom -KQ5S wrote:

> Thanks, Gary.  I will wait.
>
> Tom
>
> On Monday, January 15, 2024 at 4:05:25 PM UTC-6 gjr80 wrote:
>
>> Or better still wait until I get home this morning and patch 
>> weewx-saratoga.
>>
>> Gary
>> On Tuesday 16 January 2024 at 07:24:01 UTC+10 tke...@gmail.com wrote:
>>
>>> Yes, it will. So much for my assumption that users are unlikely to be 
>>> affected!
>>>
>>> In the meantime, you can change weewx.units.UnknownType to 
>>> weewx.units.UnknownObsType in the code.
>>>
>>> On Mon, Jan 15, 2024 at 11:07 AM bell...@gmail.com  
>>> wrote:
>>>
>>>> As I was researching upgrading to V5 I ran across this, 
>>>> http://www.weewx.com/docs/5.0/upgrade/#class-weewxunitsunknowntype-has-been-renamed
>>>> .
>>>> Looks like Wssearchlist.py will need an update.
>>>> rich
>>>>
>>>> On Monday 15 January 2024 at 11:23:50 UTC-5 Tom -KQ5S wrote:
>>>>
>>>>> I was using one of the beta versions of weewx and all was fine.   I 
>>>>> just updated using the poip update command and am now getting this 
>>>>> error..  
>>>>> Wssearchlist.py is the Search List Extension support for WeeWX-Saratoga.  
>>>>> Maybe Gary can answer.
>>>>> an 15 10:20:18 raspberrypi weewxd[328037]: ERROR weewx.reportengine: 
>>>>> Caught unrecoverable exception in generator 
>>>>> 'weewx.cheetahgenerator.CheetahGenerator'
>>>>> Jan 15 10:20:18 raspberrypi weewxd[328037]: ERROR weewx.reportengine: 
>>>>>   module 'weewx.units' has no attribute 'UnknownType'
>>>>> Jan 15 10:20:18 raspberrypi weewxd[328037]: ERROR weewx.reportengine: 
>>>>>   Traceback (most recent call last):
>>>>> Jan 15 10:20:18 raspberrypi weewxd[328037]: ERROR weewx.reportengine: 
>>>>> File 
>>>>> "/home/pi/weewx-venv/lib/python3.11/site-packages/weewx/reportengine.py", 
>>>>> line 207, in run
>>>>> Jan 15 10:20:18 raspberrypi weewxd[328037]: ERROR weewx.reportengine: 
>>>>>   obj.start()
>>>>> Jan 15 10:20:18 raspberrypi weewxd[328037]: ERROR weewx.reportengine: 
>>>>> File 
>>>>> "/home/pi/weewx-venv/lib/python3.11/site-packages/weewx/reportengine.py", 
>>>>> line 399, in start
>>>>> Jan 15 10:20:18 raspberrypi weewxd[328037]: ERROR weewx.reportengine: 
>>>>>   self.run()
>>>>> Jan 15 10:20:18 raspberrypi weewxd[328037]: ERROR weewx.reportengine: 
>>>>> File 
>>>>> "/home/pi/weewx-venv/lib/python3.11/site-packages/weewx/cheetahgenerator.py",
>>>>>  
>>>>> line 166, in run
>>>>> Jan 15 10:20:18 raspberrypi weewxd[328037]: ERROR weewx.reportengine: 
>>>>>   ngen = self.generate(gen_dict[section_name], 
>>>>> section_name, self.gen_ts)
>>>>> Jan 15 10:20:18 raspberrypi weewxd[328037]: ERROR weewx.reportengine: 
>>>>>  
>>>>> 
>>>>> Jan 15 10:20:18 raspberrypi weewxd[328037]: ERROR weewx.reportengine: 
>>>>> File 
>>>>> "/home/pi/weewx-venv/lib/python3.11/site-packages/weewx/cheetahgenerator.py",
>>>>>  
>>>>> line 226, in generate
>>>>> Jan 15 10:20:18 raspberrypi weewxd[328037]: ERROR weewx.reportengine: 
>>>>>   ngen += self.generate(section[subsection], subsection, 
>>>>> gen_ts)
>>>>> Jan 15 10:20:18 raspberrypi weewxd[328037]: ERROR weewx.reportengine: 
>>>>>  
>>>>>  ^^
>>>>> Jan 15 10:20:18 raspberrypi weewxd[328037]: ERROR weewx.reportengine: 
>>>>> File 
>>>>> "/home/pi/weewx-venv/lib/python3.11/site-packages/weewx/cheetahgenerator.py",
>>>>>  
>>>>> line 226, in generate
>>>>> Jan 15 10:20:18 raspberrypi weewxd[328037]: ERROR 

[weewx-user] Re: Weewx version 5 installation

[gjr80]

You are not providing very much information. You say you "tried to follow 
the steps in the guide but it didn't work". What steps in what guide? What 
happened other than it did not work?

Did you read the Upgrading to V5.0 section 
 of the Upgrade Guide 
? This is mandatory reading when 
(before) upgrading to version 5. The sub-section pip installs to a new 
location  
actually provides a link to a wiki article titled Migrating setup.py 
installs to Version 5.0 , 
did you work through those steps? If not perhaps you should try them, if 
you did what happened?

Gary

On Tuesday 16 January 2024 at 20:07:40 UTC+10 fvirg...@gmail.com wrote:

> Good morning,
> Congrats on the update to weewx 5,
> if I may I would like to ask if anyone managed to update weewx version 5 
> from 4.10.2 having installed with the old setup.py method.
> I tried to follow the steps in the guide but it didn't work.
> Has anyone done this update? What are the precise steps to take?
> Thank you
>

-- 
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/f2f435c5-da33-489d-acdb-c930123e7ce6n%40googlegroups.com.