Re: [weewx-user] Updates from Davis Envoy have stopped

[Peter Tuft]

Fixed!!  Thanks so much.  I'm delighted.

This exercise has prompted one other query:  despite my "ain't broke, don't 
fix it" approach perhaps it's time I updated to a more recent version of 
WeeWX.  The upgrade page cautions strongly that I should use the same 
method as the original installation, but that was over 3 years ago and I 
don't remember.  Is there a way of identifying the original install method?

Thanks again,
Peter T.


On Friday, April 12, 2024 at 11:05:18 AM UTC+10 Tom Keffer wrote:

> You can accomplish the same thing by using the old v4 utilities 
> <https://www.weewx.com/docs/4.10/hardware.htm#vantage_notes>. 
>
> wee_device --dump
> wee_device --clear-memory
>
> On Thu, Apr 11, 2024 at 6:01 PM Peter Tuft  wrote:
>
>> Tom,
>>
>> Many thanks - I've done as you suggested, log attached.  It does show 
>> discrepancies in the times.  I tried the  weectl device commands to dump 
>> and clear the memory but my Pi says "command not found".  Where do I find 
>> that?
>>
>> Because I believe in "ain't broke, don't fix it" I'm running old software 
>> - Weewx 4.5.1 under Raspbian 10.  But maybe it's "broke" - do I need to 
>> update to access weectl device?
>>
>> Thanks,
>> Peter T.
>>
>> On Friday, April 12, 2024 at 1:35:19 AM UTC+10 Tom Keffer wrote:
>>
>>> Odds are it's a problem with corrupted memory 
>>> <https://github.com/weewx/weewx/wiki/Troubleshooting-the-Davis-Vantage-station#corrupt-station-memory>,
>>>  
>>> but this time, just to be sure, could you set debug=1, restart, then post 
>>> the log through the first reporting cycle.
>>>
>>>
>>>
>>> On Thu, Apr 11, 2024 at 6:41 AM Peter Tuft  wrote:
>>>
>>>> A couple of days ago I disconnected/reconnected the USB power and 
>>>> serial data cables between my Raspberry Pi and Davis Envoy.  Since then 
>>>> weewx seems to have stopped receiving updates from the Envoy - it just 
>>>> reports old data.  I've tested the connection using minicom as described 
>>>> here: 
>>>> https://github.com/weewx/weewx/wiki/Troubleshooting-the-Davis-Vantage-station.
>>>>   
>>>> That seemed to work OK.  That page also suggested powering down the Envoy 
>>>> for a few minutes then restarting which didn't help either.  
>>>>
>>>> So I'm at a loss.  Attached is a log of events since my most recent 
>>>> restart of weewx.  The system updates every 10 minutes and you can see two 
>>>> cycles of that at the end of the log.  That same pattern continues 
>>>> indefinitely, but the FTP upload is always of the same old data from a 
>>>> couple of days ago.
>>>>
>>>> I'll be most grateful for any advice.
>>>>
>>>> Thanks,
>>>> Peter T.
>>>>
>>>> -- 
>>>> 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/091560c7-e85f-46d0-b8eb-6e9201d7ab5bn%40googlegroups.com
>>>>  
>>>> <https://groups.google.com/d/msgid/weewx-user/091560c7-e85f-46d0-b8eb-6e9201d7ab5bn%40googlegroups.com?utm_medium=email_source=footer>
>>>> .
>>>>
>>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "weewx-user" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to weewx-user+...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/4b24d477-3e5b-496b-95b8-5b29360678e2n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/weewx-user/4b24d477-3e5b-496b-95b8-5b29360678e2n%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/ee3af9b5-88c4-4065-b5e2-89b124478e2an%40googlegroups.com.

Re: [weewx-user] Updates from Davis Envoy have stopped

[Peter Tuft]

Tom,

Many thanks - I've done as you suggested, log attached.  It does show 
discrepancies in the times.  I tried the  weectl device commands to dump 
and clear the memory but my Pi says "command not found".  Where do I find 
that?

Because I believe in "ain't broke, don't fix it" I'm running old software - 
Weewx 4.5.1 under Raspbian 10.  But maybe it's "broke" - do I need to 
update to access weectl device?

Thanks,
Peter T.

On Friday, April 12, 2024 at 1:35:19 AM UTC+10 Tom Keffer wrote:

> Odds are it's a problem with corrupted memory 
> <https://github.com/weewx/weewx/wiki/Troubleshooting-the-Davis-Vantage-station#corrupt-station-memory>,
>  
> but this time, just to be sure, could you set debug=1, restart, then post 
> the log through the first reporting cycle.
>
>
>
> On Thu, Apr 11, 2024 at 6:41 AM Peter Tuft  wrote:
>
>> A couple of days ago I disconnected/reconnected the USB power and serial 
>> data cables between my Raspberry Pi and Davis Envoy.  Since then weewx 
>> seems to have stopped receiving updates from the Envoy - it just reports 
>> old data.  I've tested the connection using minicom as described here: 
>> https://github.com/weewx/weewx/wiki/Troubleshooting-the-Davis-Vantage-station.
>>   
>> That seemed to work OK.  That page also suggested powering down the Envoy 
>> for a few minutes then restarting which didn't help either.  
>>
>> So I'm at a loss.  Attached is a log of events since my most recent 
>> restart of weewx.  The system updates every 10 minutes and you can see two 
>> cycles of that at the end of the log.  That same pattern continues 
>> indefinitely, but the FTP upload is always of the same old data from a 
>> couple of days ago.
>>
>> I'll be most grateful for any advice.
>>
>> Thanks,
>> Peter T.
>>
>> -- 
>> 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/091560c7-e85f-46d0-b8eb-6e9201d7ab5bn%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/weewx-user/091560c7-e85f-46d0-b8eb-6e9201d7ab5bn%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/4b24d477-3e5b-496b-95b8-5b29360678e2n%40googlegroups.com.
Apr 12 10:02:54 raspberrypi systemd[1]: Stopping LSB: weewx weather system...
Apr 12 10:02:54 raspberrypi weewx[3886] INFO __main__: Received signal TERM 
(15).
Apr 12 10:02:54 raspberrypi weewx[3886] INFO weewx.engine: Main loop exiting. 
Shutting engine down.
Apr 12 10:02:54 raspberrypi weewx[3886] INFO weewx.engine: Shutting down 
StdReport thread
Apr 12 10:02:54 raspberrypi weewx[3886] INFO __main__: Terminating weewx 
version 4.5.1
Apr 12 10:02:54 raspberrypi weewx[5280]: Stopping weewx weather system: weewx.
Apr 12 10:02:54 raspberrypi systemd[1]: weewx.service: Succeeded.
Apr 12 10:02:54 raspberrypi systemd[1]: Stopped LSB: weewx weather system.
Apr 12 10:02:54 raspberrypi systemd[1]: Starting LSB: weewx weather system...
Apr 12 10:02:55 raspberrypi weewx[5312] INFO __main__: Initializing weewx 
version 4.5.1
Apr 12 10:02:55 raspberrypi weewx[5312] INFO __main__: Using Python 3.7.3 
(default, Jan 22 2021, 20:04:44) #012[GCC 8.3.0]
Apr 12 10:02:55 raspberrypi weewx[5312] INFO __main__: Platform 
Linux-5.10.63-v7+-armv7l-with-debian-10.11
Apr 12 10:02:55 raspberrypi weewx[5312] INFO __main__: Locale is 'en_AU.UTF-8'
Apr 12 10:02:55 raspberrypi weewx[5312] INFO __main__: PID file is 
/var/run/weewx.pid
Apr 12 10:02:55 raspberrypi weewx[5317] INFO __main__: Using configuration file 
/etc/weewx/weewx.conf
Apr 12 10:02:55 raspberrypi weewx[5317] INFO __main__: Debug is 1
Apr 12 10:02:55 raspberrypi weewx[5317] DEBUG __main__: Initializing engine
Apr 12 10:02:55 raspberrypi weewx[5317] INFO weewx.engine: Loading station type 
Vantage (weewx.drivers.vantage)
Apr 12 10:02:55 raspberrypi weewx[5317] DEBUG weewx.drivers.vantage: Driver 
version is 3.2.2
Apr 12 10:02:55 raspberrypi weewx[5317] DEBUG weewx.drivers.vantage: Option 
loop_request=1
Apr 12 10:02:55 raspberrypi weewx[5317] DEBUG weewx.drivers.vantage: Opened up 
serial port /dev/ttyUSB0; baud 19200; timeout 4.00
Apr 12 10:02:55 raspberrypi weewx[5317] DEBUG weewx.drivers.vantage: Gentle 
wake up of console successful
Apr 12 10:02:55 raspberrypi we

[weewx-user] Updates from Davis Envoy have stopped

[Peter Tuft]

A couple of days ago I disconnected/reconnected the USB power and serial 
data cables between my Raspberry Pi and Davis Envoy.  Since then weewx 
seems to have stopped receiving updates from the Envoy - it just reports 
old data.  I've tested the connection using minicom as described 
here: 
https://github.com/weewx/weewx/wiki/Troubleshooting-the-Davis-Vantage-station. 
 That seemed to work OK.  That page also suggested powering down the Envoy 
for a few minutes then restarting which didn't help either.  

So I'm at a loss.  Attached is a log of events since my most recent restart 
of weewx.  The system updates every 10 minutes and you can see two cycles 
of that at the end of the log.  That same pattern continues indefinitely, 
but the FTP upload is always of the same old data from a couple of days ago.

I'll be most grateful for any advice.

Thanks,
Peter T.

-- 
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/091560c7-e85f-46d0-b8eb-6e9201d7ab5bn%40googlegroups.com.
Apr 11 22:26:25 raspberrypi systemd[1]: Stopping LSB: weewx weather system...
Apr 11 22:26:25 raspberrypi weewx[3858]: Stopping weewx weather system: weewx 
not running
Apr 11 22:26:25 raspberrypi systemd[1]: weewx.service: Succeeded.
Apr 11 22:26:25 raspberrypi systemd[1]: Stopped LSB: weewx weather system.
Apr 11 22:26:25 raspberrypi systemd[1]: Starting LSB: weewx weather system...
Apr 11 22:26:26 raspberrypi weewx[3881] INFO __main__: Initializing weewx 
version 4.5.1
Apr 11 22:26:26 raspberrypi weewx[3881] INFO __main__: Using Python 3.7.3 
(default, Jan 22 2021, 20:04:44) #012[GCC 8.3.0]
Apr 11 22:26:26 raspberrypi weewx[3881] INFO __main__: Platform 
Linux-5.10.63-v7+-armv7l-with-debian-10.11
Apr 11 22:26:26 raspberrypi weewx[3881] INFO __main__: Locale is 'en_AU.UTF-8'
Apr 11 22:26:26 raspberrypi weewx[3881] INFO __main__: PID file is 
/var/run/weewx.pid
Apr 11 22:26:26 raspberrypi weewx[3886] INFO __main__: Using configuration file 
/etc/weewx/weewx.conf
Apr 11 22:26:26 raspberrypi weewx[3886] INFO __main__: Debug is 0
Apr 11 22:26:26 raspberrypi weewx[3886] INFO weewx.engine: Loading station type 
Vantage (weewx.drivers.vantage)
Apr 11 22:26:26 raspberrypi weewx[3869]: Starting weewx weather system: weewx.
Apr 11 22:26:26 raspberrypi systemd[1]: Started LSB: weewx weather system.
Apr 11 22:26:26 raspberrypi weewx[3886] INFO weewx.engine: StdConvert target 
unit is 0x1
Apr 11 22:26:26 raspberrypi weewx[3886] INFO weewx.engine: Archive will use 
data binding wx_binding
Apr 11 22:26:26 raspberrypi weewx[3886] INFO weewx.engine: Record generation 
will be attempted in 'hardware'
Apr 11 22:26:26 raspberrypi weewx[3886] ERROR weewx.engine: The archive 
interval in the configuration file (300) does not match the station hardware 
interval (600).
Apr 11 22:26:26 raspberrypi weewx[3886] INFO weewx.engine: Using archive 
interval of 600 seconds (specified by hardware)
Apr 11 22:26:26 raspberrypi weewx[3886] INFO weewx.restx: StationRegistry: 
Registration not requested.
Apr 11 22:26:26 raspberrypi weewx[3886] INFO weewx.restx: Wunderground: Posting 
not enabled.
Apr 11 22:26:26 raspberrypi weewx[3886] INFO weewx.restx: PWSweather: Posting 
not enabled.
Apr 11 22:26:26 raspberrypi weewx[3886] INFO weewx.restx: CWOP: Posting not 
enabled.
Apr 11 22:26:26 raspberrypi weewx[3886] INFO weewx.restx: WOW: Posting not 
enabled.
Apr 11 22:26:26 raspberrypi weewx[3886] INFO weewx.restx: AWEKAS: Posting not 
enabled.
Apr 11 22:26:26 raspberrypi weewx[3886] INFO __main__: Starting up weewx 
version 4.5.1
Apr 11 22:26:26 raspberrypi weewx[3886] INFO weewx.engine: Clock error is 
1934.11 seconds (positive is fast)
Apr 11 22:26:26 raspberrypi weewx[3886] INFO weewx.drivers.vantage: Clock set 
to 2024-04-11 22:26:27 AEST (1712838387)
Apr 11 22:26:26 raspberrypi weewx[3886] INFO weewx.engine: Using binding 
'wx_binding' to database 'weewx.sdb'
Apr 11 22:26:26 raspberrypi weewx[3886] INFO weewx.manager: Starting backfill 
of daily summaries
Apr 11 22:26:26 raspberrypi weewx[3886] INFO weewx.manager: Daily summaries up 
to date
Apr 11 22:26:30 raspberrypi weewx[3886] INFO weewx.engine: Starting main packet 
loop.
Apr 11 22:26:34 raspberrypi weewx[3886] ERROR weewx.drivers.vantage: LOOP try 
#1; error: Expected to read 99 chars; got 0 instead
Apr 11 22:26:38 raspberrypi weewx[3886] ERROR weewx.drivers.vantage: LOOP try 
#2; error: Expected to read 99 chars; got 0 instead
Apr 11 22:26:42 raspberrypi weewx[3886] ERROR weewx.drivers.vantage: LOOP try 
#3; error: Expected to read 99 chars; got 0 instead
Apr 11 22:26:46 raspberrypi systemd[1]: Started Session 33 of user pi.
Apr 11 22:26:46 raspberrypi systemd[1]: session-33.scope: Succeeded.
Apr 11 22:27:07 raspberrypi vncserver-x1

Re: [weewx-user] Catastrophic apt upgrade to V5.02 on Raspberry Pi

['Peter Fletcher' via weewx-user]

@matthew

I think that the below responds to all your specific questions. Let me know 
if there is any other information that would help you. I am running a 
single instance of weewx on a Raspberry Pi 3B, which also runs various 
systemd services which monitor and manage my heating system and components 
of my power and lighting systems. I am currently running the latest release 
of Bullseye on the Pi. I know that Bookworm has been out and nominally 
stable for a while, and am working with it on a spare system, but some of 
my other software isn't yet convinced that it is happy to run under some of 
the new 'rules' that come with the new version of the OS. I am a reasonably 
competent Unix user and a reasonably competent Python (among other 
languages) programmer, but most of my low level OS and programming 
experience was gained on Windows OSes.

weewx is hooked up to a Davis Vantage Pro 2 Plus weather station, by means 
of a Meteo-pi HAT (which includes a RTC). The interface is seen by the Pi 
as its first serial port (serial0). I have been using weewx to monitor and 
record the weather station's output here since 2020, and for a while before 
that at the house in Illinois from which I moved at that time. The Version 
number in the weewx.conf file (copy attached) is 4.10.2, but it was apt 
installed when I moved to Bullseye, a couple of years ago, so regular apt 
upgrades will have been keeping the software updated.

I have written and use a number of weewx user services to incorporate data 
from other sensors and to 'tweak' some of the data coming from the weather 
station before it gets stored. These have not caused any issues under the 
new version - they do do some file access, but only reading files, so 
access privileges would not be expected to be a problem (and aren't).

I have weewx set up to generate two sets of reports, both using skins based 
on an early version of the Seasons skin, but with some (different) 
modifications and deletions. One of the reports shows all the information 
available to it (including some from independent sensors around my house) 
and is 'for internal use'; the other shows only standard weather 
information and is used for two public sites, one associated with my own 
personal site, and the other with a HOA site that I manage for my 
community. The HOA site 'cross-loads' the charts it displays from my 
personal site, so weewx is not directly concerned with uploading these 
image files to it. However, the HOA site gets current weather information 
from a Cumulus realtime.txt file generated by weewx which is uploaded 
directly to it, so weewx.conf has two FTP stanzas - one for the public 
site, and one for the realtime.txt file.

The 'for internal use' report is written to /var/www/html/weewx, and served 
from there to the local network by an instance of nginx running on the Pi. 
nginx only needs read access to the files, so access rights weren't a 
problem. The public report is written to /var/www/html/weewx2, and FTP 
uploaded from there by weewx to my live site on an ISP's servers. The 
realtime.txt file is written to /var/www/html/weewx3, and FTP uploaded from 
there by weewx to a location on the HOA site. All the folders are regular 
'physical' folders and are directly declared in my conf file - I try to 
avoid using symlinks unless I absolutely have to, since I frequently find 
their behavior non-intuitive!

I actually had two classes of problems. weewx initially not running at all 
after the upgrade was deeply worrying, but relatively easy to troubleshoot, 
since the error reports from systemctl status were relatively clear in 
pointing to the problems. Once I got it running, by sorting out the most 
severe access problems, I had more difficult chasing down problems with my 
public reports, which were not being updated as a result of permissions 
errors that were not causing weewx to crash. As I noted also, my life was 
made immeasurably more difficult by the fact that the symptoms that I was 
initially seeing for the public reports suggested more problems of a type 
that I had already experienced from recent changes to my ISP's FTP servers, 
rather than issues with weewx generating them. I found getting the settings 
right for the two subfolders in my HTML report folders (NOAA and fonts) 
particularly tricky - probably because I initially used a recursive chmod 
command that was wrong for the directories affected.

On Wednesday, February 21, 2024 at 7:13:08 PM UTC-5 matthew wall wrote:

> On Wednesday, February 21, 2024 at 6:50:52 PM UTC-5 Peter Fletcher wrote:
>
> There were essentially no issues with the 4.x->5.x update. What I wasn't 
> prepared for was an update *from 5.01 to 5.02* clobbering everything *that 
> was previously working in 5.01*. I don't think that it is reasonable to 
> expect the user to carefully (re-)read all the documentation before 
> doing/allowing a 'second decimal place' update.
>
>
> peter, it would

Re: [weewx-user] Catastrophic apt upgrade to V5.02 on Raspberry Pi

['Peter Fletcher' via weewx-user]

I'm not ignoring you, but today has been a bit busy! I will try to write 
something up and post it later today or tomorrow.

On Wednesday, February 21, 2024 at 7:13:08 PM UTC-5 matthew wall wrote:

> On Wednesday, February 21, 2024 at 6:50:52 PM UTC-5 Peter Fletcher wrote:
>
> There were essentially no issues with the 4.x->5.x update. What I wasn't 
> prepared for was an update *from 5.01 to 5.02* clobbering everything *that 
> was previously working in 5.01*. I don't think that it is reasonable to 
> expect the user to carefully (re-)read all the documentation before 
> doing/allowing a 'second decimal place' update.
>
>
> peter, it would be helpful if you could describe a bit more about your 
> configuration. 
>
> are you running with hardware that required separate installation (e.g., 
> sdr) or hardware drivers or kernel modules?
>
> are you running multiple instances of weewd?
>
> are your reports all within a single directory tree, or are they scattered?
>
> did you implement the various report locations using symlinks, or is it 
> all explicitly declared within your weewx config file?
>
> did you have any issues with weewx integration to a local web server?  if 
> so, how did you configure that?
>
> do you have ssh or other configurations for remote access that were 
> affected by the permissions changes?  where are those located, and how are 
> they used?
>
> i'm working on a handful of adjustments to the deb/rpm packaging that will 
> hopefully avoid some of the issues you ran into.  so description of systems 
> that are more extensive than just 'apt install' are very helpful.  in 
> hindsight, we probably should have done the root-to-weewx change in the 
> 5.0.0 release, not a dot-dot.  it was not until 5.0 went out that we 
> realized how many *more* issues there would be if some people end up with 
> weewx running as root while others run unprivileged.
>
> apologies for the disruption it caused.
>
> 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/616a09d1-cd56-4796-901e-21ff9e25ab54n%40googlegroups.com.

Re: [weewx-user] Catastrophic apt upgrade to V5.02 on Raspberry Pi

['Peter Fletcher' via weewx-user]

I understand what you are saying. However, all the discussion that I read 
was about the change from V4.x to V5.x. I was very careful when I did that 
update, created a total system backup first, and was fully prepared to sort 
out issues. I have, in any event, been using systemd for many things, 
including weewx, for a very long time. There were essentially no issues 
with the 4.x->5.x update. What I wasn't prepared for was an update *from 
5.01 to 5.02* clobbering everything *that was previously working in 5.01*. 
I don't think that it is reasonable to expect the user to carefully 
(re-)read all the documentation before doing/allowing a 'second decimal 
place' update.

I have used the wee_xyz utilities so rarely, that I would need to look up 
how to do anything with them, anyway. I would expect to do the same with 
weectl.

My existing installation includes a number of custom skins and custom 
services. There would be *much* more than copying over the db involved in 
the ''clean install' approach, though I did think of doing that after 
everything fell apart.

On Wednesday, February 21, 2024 at 5:52:14 PM UTC-5 vince wrote:

> FWIW - you 'could' have remained on your old version basically forever if 
> you were so inclined.
>
> But to reply
>
> On Wednesday, February 21, 2024 at 2:18:49 PM UTC-8 Peter Fletcher wrote:
>
> That was one of the *many* permissions-related problems caused by the 
> update! Changing the registered user of a complex program that reads and 
> writes many files in many places, without making sure that the user knows 
> the consequences 
>
>
> Disagree.  Documented many many times and places from changelog to the 
> upgrade guide to FAQ and dozens of threads here over almost a year of 
> alpha/beta/release-candidate changes and improvements that resulted from 
> that testing.   The docs were totally redone and enhanced and are now very 
> easily searchable.  Same for the wiki.  Same for the FAQ. 
>
> The switch to running unprivileged is also implementing a decade+ design 
> goal to move away from running as root to the longstanding industry best 
> practice of running as a non-privileged user.  That in itself makes it 
> worth the pain to remove that legacy risk.
>  
> And what does the user need to learn new ?  Two things.  Use of systemd 
> for startup (the os's essentially force this) and the replacement of 
> wee_xyz utilities with an integrated weectl utility (very very well 
> documented for almost a year now).
>
> And where does the user have to possibly salt to taste ?  Two places.   
> Access to serial/usb ports and privs to write to their webserver document 
> root.  Just like every other unprivileged app that does either.
>
> ... the new registered user didn't have access to the serial port. 
>
>
> Hmmm - the user has to properly configure their os to let the 
> non-privileged user access the peripherals.  This is surprisingly difficult 
> given almost infinite variability of the possible os configurations and the 
> variety of devices that connect to those systems.  But the logs clearly say 
> permission denied when this happens and the how to fix it is very very well 
> documented for many months.
>
> Run debug=1.  See permission denied.  Search the forums/docs/wiki/faq for 
> folks who have been there before and what they did.
>
>  
>
> The crt problem was as you said and was the second one to surface after 
> the first had been fixed. Subsequent to fixing that, I had to correct the 
> access rights to the folders corresponding to a number of 'sites' that my 
> copy of weewx creates.
>
>
> Yes - the onus is on the user to integrate their weather station software 
> with their user-configured webserver.  That has always been their job.
>
> FWIW:
>
>- a clean new installation of v5 works right out of the box on 
>debian(ish) os and a raspi (which is debian-based) with no edits required
>- if you are on a pi specifically, the default 'pi' user gets access 
>to serial/usb from the default os for free so no work is required there
>- running the packaged variant frequently requires 'one time' work to 
>salt to taste, so to speak.  Weewx is no different than any other app in 
>this respect.
>
>  Again - this is a major upgrade that is 'optional' although recommended. 
>  In itself making the switch to running unprivileged is reason enough to 
> work a little 'once'.
>
> Or save your db, do a clean installation of v5, copy your db into place, 
> and start it up.  It will almost certainly work.
>
>

-- 
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/9ad0e558-d790-426e-a803-428e0fdccafan%40googlegroups.com.

Re: [weewx-user] Catastrophic apt upgrade to V5.02 on Raspberry Pi

['Peter Fletcher' via weewx-user]

That was one of the *many* permissions-related problems caused by the 
update! Changing the registered user of a complex program that reads and 
writes many files in many places, without making sure that the user knows 
the consequences of and necessary fixes for this makes changing horses in 
midstream look like a reasonable and appropriate thing to do! The first 
problem was that the new registered user didn't have access to the serial 
port. The crt problem was as you said and was the second one to surface 
after the first had been fixed. Subsequent to fixing that, I had to correct 
the access rights to the folders corresponding to a number of 'sites' that 
my copy of weewx creates.

Life was made substantially more difficult because my ISP has just changed 
how it manages FTP connections, and there are problems with the new 
implementation, so when things went wrong with the FTP-uploaded sites I 
originally blamed them on the ISP's FTP issues.

The crt extension puts its output in a subfolder of /var/www/html, whence 
weewx FTPs it to a different site (not one hosted by my regular ISP).

I was using V 0.21 of crt, but have now updated to V 0.23.

On Wednesday, February 21, 2024 at 4:02:39 PM UTC-5 matthew wall wrote:

> On Wednesday, February 21, 2024 at 3:54:31 PM UTC-5 Peter Fletcher wrote:
>
> It turns out that there were some other privilege problems, resulting from 
> the 5.02 update, but I managed to get journalctl to show me the detailed 
> error logs, which it apparently keeps, and /var/log/messages apparently 
> doesn't. The previous crt exceptions were, indeed, in journalctl's logs and 
> they allowed me to identify and fix the rest. I think that everything is 
> now really sorted, but a nominally minor utility update, liable to be 
> included in a routine apt full-upgrade, should not create this big a mess!
>
>
> peter,
>
> based on the logs you found, is this what happened:
>
> - crt extension could not write to the file it wanted to write to
> - when it tried to report the problem, the crt extension died, because the 
> 'traceback' function it tried to call no longer exists
>
> where does your crt extension put its output?
>
> have you updated to the latest crt extension?  (v0.23)
>
> 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/476c457a-da65-4e59-921e-0f1746221f56n%40googlegroups.com.

Re: [weewx-user] Catastrophic apt upgrade to V5.02 on Raspberry Pi

['Peter Fletcher' via weewx-user]

It turns out that there were some other privilege problems, resulting from 
the 5.02 update, but I managed to get journalctl to show me the detailed 
error logs, which it apparently keeps, and /var/log/messages apparently 
doesn't. The previous crt exceptions were, indeed, in journalctl's logs and 
they allowed me to identify and fix the rest. I think that everything is 
now really sorted, but a nominally minor utility update, liable to be 
included in a routine apt full-upgrade, should not create this big a mess!

On Wednesday, February 21, 2024 at 1:47:30 PM UTC-5 Peter Fletcher wrote:

> I'm blessed if I know why the log doesn't show anything about the crashes. 
> The crash information I showed earlier was actually from systemctl status, 
> after the second crash occurred (the first one reported the serial port 
> access failure). I cannot find a way to get the same detail in the history 
> from journalctl, and the log I am giving you is from running:
> sudo grep weewxd /var/log/messages >weewx0.log
> This may omit important detail lines, if they don't contain the string: 
> 'weewxd'
>
>
> On Wednesday, February 21, 2024 at 10:33:11 AM UTC-5 Tom Keffer wrote:
>
>> Glad it's working for you, but why were there log entries of the crt 
>> exception the first time, but not the last? 
>>
>> If a thread is exiting without telling us why, that's a bug. Looking 
>> through the crt code, the write to the disk is protected by an exception 
>> clause, so it should have caught the permissions error and logged it.
>>
>>
>>
>> On Tue, Feb 20, 2024 at 7:21 PM 'Peter Fletcher' via weewx-user <
>> weewx...@googlegroups.com> wrote:
>>
>>> That is the entire log from shortly before the update. I am guessing 
>>> that the known bug in crt.py results in the crash not being properly 
>>> reported.
>>>
>>> The good news is that I was able to figure out what was going on. I am 
>>> using crt to produce a file that allows the display of current weather 
>>> conditions on my HOA's website. It is written to a subfolder of its own in 
>>> /var/www/html and uploaded to the HOA site from there by weewx. Again, it 
>>> was the change from weewx running as root to it running as weewx that was 
>>> causing an access privilege error. Simply deleting the old version of the 
>>> file did not solve the problem, but assigning ownership of the relevant 
>>> *subfolder* to weewx:weewx restored normal functionality.
>>> On Tuesday, February 20, 2024 at 8:50:50 PM UTC-5 Tom Keffer wrote:
>>>
>>>> That's the end of the log? Where is the crt error?
>>>>
>>>> The record timestamped 2024-02-20 20:30:00 was downloaded from the 
>>>> logger at 20:32:22. I would expect the next record to be processed at 
>>>> 20:35:16 or so. Did you terminate the program? Is there something later in 
>>>> the log?
>>>>
>>>> On Tue, Feb 20, 2024 at 5:41 PM 'Peter Fletcher' via weewx-user <
>>>> weewx...@googlegroups.com> wrote:
>>>>
>>>>> Here is the log from before I applied the apt update, through now. 
>>>>> This includes one reboot. The last  start was after setting debug=1 in 
>>>>> the 
>>>>> config file. I hope that it helps you more than it does me!:
>>>>>
>>>>> Feb 20 18:20:19 bullseyepi weewxd[447]: INFO weewx.cheetahgenerator: 
>>>>> Generated 7 files for report SeasonsReport in 2.52 seconds
>>>>> Feb 20 18:20:21 bullseyepi weewxd[447]: INFO weewx.imagegenerator: 
>>>>> Generated 16 images for report SeasonsReport in 1.47 seconds
>>>>> Feb 20 18:20:21 bullseyepi weewxd[447]: INFO weewx.reportengine: 
>>>>> Copied 0 files to /var/www/html/weewx
>>>>> Feb 20 18:20:23 bullseyepi weewxd[447]: INFO weewx.cheetahgenerator: 
>>>>> Generated 8 files for report PublicReport in 2.19 seconds
>>>>> Feb 20 18:20:24 bullseyepi weewxd[447]: INFO weewx.imagegenerator: 
>>>>> Generated 16 images for report PublicReport in 1.39 seconds
>>>>> Feb 20 18:20:24 bullseyepi weewxd[447]: INFO weewx.reportengine: 
>>>>> Copied 0 files to /var/www/html/weewx2
>>>>> Feb 20 18:20:25 bullseyepi weewxd[447]: INFO weewx.reportengine: 
>>>>> ftpgenerator: Ftp'd 1 files in 0.75 seconds
>>>>> Feb 20 18:20:35 bullseyepi weewxd[447]: INFO weewx.reportengine: 
>>>>> ftpgenerator: Ftp'd 22 files in 10.12 seconds
>>>>> Feb 20 18:25:16 bullseyepi weewxd[447]: INFO weewx.manager: Added 
>>>>> recor

Re: [weewx-user] Catastrophic apt upgrade to V5.02 on Raspberry Pi

['Peter Fletcher' via weewx-user]

I'm blessed if I know why the log doesn't show anything about the crashes. 
The crash information I showed earlier was actually from systemctl status, 
after the second crash occurred (the first one reported the serial port 
access failure). I cannot find a way to get the same detail in the history 
from journalctl, and the log I am giving you is from running:
sudo grep weewxd /var/log/messages >weewx0.log
This may omit important detail lines, if they don't contain the string: 
'weewxd'


On Wednesday, February 21, 2024 at 10:33:11 AM UTC-5 Tom Keffer wrote:

> Glad it's working for you, but why were there log entries of the crt 
> exception the first time, but not the last? 
>
> If a thread is exiting without telling us why, that's a bug. Looking 
> through the crt code, the write to the disk is protected by an exception 
> clause, so it should have caught the permissions error and logged it.
>
>
>
> On Tue, Feb 20, 2024 at 7:21 PM 'Peter Fletcher' via weewx-user <
> weewx...@googlegroups.com> wrote:
>
>> That is the entire log from shortly before the update. I am guessing that 
>> the known bug in crt.py results in the crash not being properly reported.
>>
>> The good news is that I was able to figure out what was going on. I am 
>> using crt to produce a file that allows the display of current weather 
>> conditions on my HOA's website. It is written to a subfolder of its own in 
>> /var/www/html and uploaded to the HOA site from there by weewx. Again, it 
>> was the change from weewx running as root to it running as weewx that was 
>> causing an access privilege error. Simply deleting the old version of the 
>> file did not solve the problem, but assigning ownership of the relevant 
>> *subfolder* to weewx:weewx restored normal functionality.
>> On Tuesday, February 20, 2024 at 8:50:50 PM UTC-5 Tom Keffer wrote:
>>
>>> That's the end of the log? Where is the crt error?
>>>
>>> The record timestamped 2024-02-20 20:30:00 was downloaded from the 
>>> logger at 20:32:22. I would expect the next record to be processed at 
>>> 20:35:16 or so. Did you terminate the program? Is there something later in 
>>> the log?
>>>
>>> On Tue, Feb 20, 2024 at 5:41 PM 'Peter Fletcher' via weewx-user <
>>> weewx...@googlegroups.com> wrote:
>>>
>>>> Here is the log from before I applied the apt update, through now. This 
>>>> includes one reboot. The last  start was after setting debug=1 in the 
>>>> config file. I hope that it helps you more than it does me!:
>>>>
>>>> Feb 20 18:20:19 bullseyepi weewxd[447]: INFO weewx.cheetahgenerator: 
>>>> Generated 7 files for report SeasonsReport in 2.52 seconds
>>>> Feb 20 18:20:21 bullseyepi weewxd[447]: INFO weewx.imagegenerator: 
>>>> Generated 16 images for report SeasonsReport in 1.47 seconds
>>>> Feb 20 18:20:21 bullseyepi weewxd[447]: INFO weewx.reportengine: Copied 
>>>> 0 files to /var/www/html/weewx
>>>> Feb 20 18:20:23 bullseyepi weewxd[447]: INFO weewx.cheetahgenerator: 
>>>> Generated 8 files for report PublicReport in 2.19 seconds
>>>> Feb 20 18:20:24 bullseyepi weewxd[447]: INFO weewx.imagegenerator: 
>>>> Generated 16 images for report PublicReport in 1.39 seconds
>>>> Feb 20 18:20:24 bullseyepi weewxd[447]: INFO weewx.reportengine: Copied 
>>>> 0 files to /var/www/html/weewx2
>>>> Feb 20 18:20:25 bullseyepi weewxd[447]: INFO weewx.reportengine: 
>>>> ftpgenerator: Ftp'd 1 files in 0.75 seconds
>>>> Feb 20 18:20:35 bullseyepi weewxd[447]: INFO weewx.reportengine: 
>>>> ftpgenerator: Ftp'd 22 files in 10.12 seconds
>>>> Feb 20 18:25:16 bullseyepi weewxd[447]: INFO weewx.manager: Added 
>>>> record 2024-02-20 18:25:00 EST (1708471500) to database 'weewx.sdb'
>>>> Feb 20 18:25:16 bullseyepi weewxd[447]: INFO weewx.manager: Added 
>>>> record 2024-02-20 18:25:00 EST (1708471500) to daily summary in 'weewx.sdb'
>>>> Feb 20 18:25:19 bullseyepi weewxd[447]: INFO weewx.cheetahgenerator: 
>>>> Generated 7 files for report SeasonsReport in 2.53 seconds
>>>> Feb 20 18:25:20 bullseyepi weewxd[447]: INFO weewx.imagegenerator: 
>>>> Generated 16 images for report SeasonsReport in 1.41 seconds
>>>> Feb 20 18:25:20 bullseyepi weewxd[447]: INFO weewx.reportengine: Copied 
>>>> 0 files to /var/www/html/weewx
>>>> Feb 20 18:25:23 bullseyepi weewxd[447]: INFO weewx.cheetahgenerator: 
>>>> Generated 8 files for report PublicReport in 2.19 seconds
>>>> Feb 20 18:25:24 bullseyepi weewxd[

Re: [weewx-user] Catastrophic apt upgrade to V5.02 on Raspberry Pi

['Peter Fletcher' via weewx-user]

That is the entire log from shortly before the update. I am guessing that 
the known bug in crt.py results in the crash not being properly reported.

The good news is that I was able to figure out what was going on. I am 
using crt to produce a file that allows the display of current weather 
conditions on my HOA's website. It is written to a subfolder of its own in 
/var/www/html and uploaded to the HOA site from there by weewx. Again, it 
was the change from weewx running as root to it running as weewx that was 
causing an access privilege error. Simply deleting the old version of the 
file did not solve the problem, but assigning ownership of the relevant 
*subfolder* to weewx:weewx restored normal functionality.
On Tuesday, February 20, 2024 at 8:50:50 PM UTC-5 Tom Keffer wrote:

> That's the end of the log? Where is the crt error?
>
> The record timestamped 2024-02-20 20:30:00 was downloaded from the logger 
> at 20:32:22. I would expect the next record to be processed at 20:35:16 or 
> so. Did you terminate the program? Is there something later in the log?
>
> On Tue, Feb 20, 2024 at 5:41 PM 'Peter Fletcher' via weewx-user <
> weewx...@googlegroups.com> wrote:
>
>> Here is the log from before I applied the apt update, through now. This 
>> includes one reboot. The last  start was after setting debug=1 in the 
>> config file. I hope that it helps you more than it does me!:
>>
>> Feb 20 18:20:19 bullseyepi weewxd[447]: INFO weewx.cheetahgenerator: 
>> Generated 7 files for report SeasonsReport in 2.52 seconds
>> Feb 20 18:20:21 bullseyepi weewxd[447]: INFO weewx.imagegenerator: 
>> Generated 16 images for report SeasonsReport in 1.47 seconds
>> Feb 20 18:20:21 bullseyepi weewxd[447]: INFO weewx.reportengine: Copied 0 
>> files to /var/www/html/weewx
>> Feb 20 18:20:23 bullseyepi weewxd[447]: INFO weewx.cheetahgenerator: 
>> Generated 8 files for report PublicReport in 2.19 seconds
>> Feb 20 18:20:24 bullseyepi weewxd[447]: INFO weewx.imagegenerator: 
>> Generated 16 images for report PublicReport in 1.39 seconds
>> Feb 20 18:20:24 bullseyepi weewxd[447]: INFO weewx.reportengine: Copied 0 
>> files to /var/www/html/weewx2
>> Feb 20 18:20:25 bullseyepi weewxd[447]: INFO weewx.reportengine: 
>> ftpgenerator: Ftp'd 1 files in 0.75 seconds
>> Feb 20 18:20:35 bullseyepi weewxd[447]: INFO weewx.reportengine: 
>> ftpgenerator: Ftp'd 22 files in 10.12 seconds
>> Feb 20 18:25:16 bullseyepi weewxd[447]: INFO weewx.manager: Added record 
>> 2024-02-20 18:25:00 EST (1708471500) to database 'weewx.sdb'
>> Feb 20 18:25:16 bullseyepi weewxd[447]: INFO weewx.manager: Added record 
>> 2024-02-20 18:25:00 EST (1708471500) to daily summary in 'weewx.sdb'
>> Feb 20 18:25:19 bullseyepi weewxd[447]: INFO weewx.cheetahgenerator: 
>> Generated 7 files for report SeasonsReport in 2.53 seconds
>> Feb 20 18:25:20 bullseyepi weewxd[447]: INFO weewx.imagegenerator: 
>> Generated 16 images for report SeasonsReport in 1.41 seconds
>> Feb 20 18:25:20 bullseyepi weewxd[447]: INFO weewx.reportengine: Copied 0 
>> files to /var/www/html/weewx
>> Feb 20 18:25:23 bullseyepi weewxd[447]: INFO weewx.cheetahgenerator: 
>> Generated 8 files for report PublicReport in 2.19 seconds
>> Feb 20 18:25:24 bullseyepi weewxd[447]: INFO weewx.imagegenerator: 
>> Generated 16 images for report PublicReport in 1.40 seconds
>> Feb 20 18:25:24 bullseyepi weewxd[447]: INFO weewx.reportengine: Copied 0 
>> files to /var/www/html/weewx2
>> Feb 20 18:25:25 bullseyepi weewxd[447]: INFO weewx.reportengine: 
>> ftpgenerator: Ftp'd 1 files in 0.76 seconds
>> Feb 20 18:25:36 bullseyepi weewxd[447]: INFO weewx.reportengine: 
>> ftpgenerator: Ftp'd 22 files in 11.08 seconds
>> Feb 20 18:30:21 bullseyepi weewxd[447]: INFO weewx.manager: Added record 
>> 2024-02-20 18:30:00 EST (1708471800) to database 'weewx.sdb'
>> Feb 20 18:30:21 bullseyepi weewxd[447]: INFO weewx.manager: Added record 
>> 2024-02-20 18:30:00 EST (1708471800) to daily summary in 'weewx.sdb'
>> Feb 20 18:30:24 bullseyepi weewxd[447]: INFO weewx.cheetahgenerator: 
>> Generated 7 files for report SeasonsReport in 3.31 seconds
>> Feb 20 18:30:26 bullseyepi weewxd[447]: INFO weewx.imagegenerator: 
>> Generated 16 images for report SeasonsReport in 1.62 seconds
>> Feb 20 18:30:26 bullseyepi weewxd[447]: INFO weewx.reportengine: Copied 0 
>> files to /var/www/html/weewx
>> Feb 20 18:30:28 bullseyepi weewxd[447]: INFO weewx.cheetahgenerator: 
>> Generated 8 files for report PublicReport in 2.54 seconds
>> Feb 20 18:30:30 bullseyepi weewxd[447]: INFO weewx.imagegenerator: 
>> Generated 16 images for report PublicReport in 1.47 seconds
>> Feb 20 1

Re: [weewx-user] Catastrophic apt upgrade to V5.02 on Raspberry Pi

['Peter Fletcher' via weewx-user]

) to database 'weewx.sdb'
Feb 20 20:32:20 bullseyepi weewxd[17786]: INFO weewx.manager: Added record 
2024-02-20 20:30:00 EST (1708479000) to daily summary in 'weewx.sdb'
Feb 20 20:32:20 bullseyepi weewxd[17786]: INFO weewx.engine: Starting main 
packet loop.
Feb 20 20:32:22 bullseyepi weewxd[17786]: INFO weewx.engine: Main loop 
exiting. Shutting engine down.

On Tuesday, February 20, 2024 at 7:48:58 PM UTC-5 Tom Keffer wrote:

> The "AttributeError" problem is a known problem with crt. See this thread 
> <https://groups.google.com/g/weewx-user/c/Zb-T43uv_jo/m/OagAfiImAQAJ>. 
>
> But, it is not the actual problem --- it's just a reporting problem. For 
> the actual problem, we will need to see more of the log.
>
> On Tue, Feb 20, 2024 at 4:14 PM 'Peter Fletcher' via weewx-user <
> weewx...@googlegroups.com> wrote:
>
>> I have had weewx 4.x (apt installed) running happily on my Pi 3b for 
>> years. A month ago, since 5.0 seemed to be stable, I allowed the upgrade to 
>> the then current release of 5.0. Since there had been a few concerns raised 
>> about it, I did a complete image backup of the Pi before allowing the 
>> upgrade. This turned out not to be necessary, since the upgrade essentially 
>> 'just worked', though I did have to deal with the missing private key issue 
>> that has been discussed elsewhere. This evening, as part of a routine apt 
>> full-upgrade, , I was updated to 5.02, and the weewx installation appears 
>> to have been comprehensively clobbered. Sadly, it didn't occur to me to do 
>> an image backup before a minor update, So I don't have an easy way of going 
>> back. The initial error appeared to be an access violation to /dev/serial0, 
>> such as was described in another recent thread with this version of weewx, 
>> but changing the ownership of the serial port to weewx:weewx only changed 
>> the problem. systemctl status now reports:
>> * weewx.service - WeeWX
>>  Loaded: loaded (/lib/systemd/system/weewx.service; enabled; vendor 
>> preset: enabled)
>>  Active: failed (Result: exit-code) since Tue 2024-02-20 18:48:39 
>> EST; 31s ago
>>Docs: https://weewx.com/docs
>> Process: 3348 ExecStart=weewxd /etc/weewx/weewx.conf (code=exited, 
>> status=1/FAILURE)
>>Main PID: 3348 (code=exited, status=1/FAILURE)
>> CPU: 1.256s
>>
>> Feb 20 18:48:39 bullseyepi weewxd[3348]: CRITICAL __main__:  
>>  callback(event)
>> Feb 20 18:48:39 bullseyepi weewxd[3348]: CRITICAL __main__:    
>>  File "/etc/weewx/bin/user/crt.py", line 540, in handle_new_loop
>> Feb 20 18:48:39 bullseyepi weewxd[3348]: CRITICAL __main__:  
>>  self.handle_data(event.packet)
>> Feb 20 18:48:39 bullseyepi weewxd[3348]: CRITICAL __main__:    
>>  File "/etc/weewx/bin/user/crt.py", line 563, in handle_data
>> Feb 20 18:48:39 bullseyepi weewxd[3348]: CRITICAL __main__:  
>>  weeutil.weeutil.log_traceback('crt:  ')
>> Feb 20 18:48:39 bullseyepi weewxd[3348]: CRITICAL __main__:  
>>  AttributeError: module 'weeutil.weeutil' has no attribute 'log_traceback'
>> Feb 20 18:48:39 bullseyepi weewxd[3348]: CRITICAL __main__:  
>>  Exiting.
>> Feb 20 18:48:39 bullseyepi systemd[1]: weewx.service: Main process 
>> exited, code=exited, status=1/FAILURE
>> Feb 20 18:48:39 bullseyepi systemd[1]: weewx.service: Failed with result 
>> 'exit-code'.
>> Feb 20 18:48:39 bullseyepi systemd[1]: weewx.service: Consumed 1.256s CPU 
>> time.
>>
>> What is going 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/9e86020c-1a88-4b0a-b47f-6133c5432b88n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/weewx-user/9e86020c-1a88-4b0a-b47f-6133c5432b88n%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/96076e7b-357f-48a3-acb9-9a9e88093af6n%40googlegroups.com.

[weewx-user] Catastrophic apt upgrade to V5.02 on Raspberry Pi

['Peter Fletcher' via weewx-user]

I have had weewx 4.x (apt installed) running happily on my Pi 3b for years. 
A month ago, since 5.0 seemed to be stable, I allowed the upgrade to the 
then current release of 5.0. Since there had been a few concerns raised 
about it, I did a complete image backup of the Pi before allowing the 
upgrade. This turned out not to be necessary, since the upgrade essentially 
'just worked', though I did have to deal with the missing private key issue 
that has been discussed elsewhere. This evening, as part of a routine apt 
full-upgrade, , I was updated to 5.02, and the weewx installation appears 
to have been comprehensively clobbered. Sadly, it didn't occur to me to do 
an image backup before a minor update, So I don't have an easy way of going 
back. The initial error appeared to be an access violation to /dev/serial0, 
such as was described in another recent thread with this version of weewx, 
but changing the ownership of the serial port to weewx:weewx only changed 
the problem. systemctl status now reports:
* weewx.service - WeeWX
 Loaded: loaded (/lib/systemd/system/weewx.service; enabled; vendor 
preset: enabled)
 Active: failed (Result: exit-code) since Tue 2024-02-20 18:48:39 EST; 
31s ago
   Docs: https://weewx.com/docs
Process: 3348 ExecStart=weewxd /etc/weewx/weewx.conf (code=exited, 
status=1/FAILURE)
   Main PID: 3348 (code=exited, status=1/FAILURE)
CPU: 1.256s

Feb 20 18:48:39 bullseyepi weewxd[3348]: CRITICAL __main__:  
 callback(event)
Feb 20 18:48:39 bullseyepi weewxd[3348]: CRITICAL __main__:    
 File "/etc/weewx/bin/user/crt.py", line 540, in handle_new_loop
Feb 20 18:48:39 bullseyepi weewxd[3348]: CRITICAL __main__:  
 self.handle_data(event.packet)
Feb 20 18:48:39 bullseyepi weewxd[3348]: CRITICAL __main__:    
 File "/etc/weewx/bin/user/crt.py", line 563, in handle_data
Feb 20 18:48:39 bullseyepi weewxd[3348]: CRITICAL __main__:  
 weeutil.weeutil.log_traceback('crt:  ')
Feb 20 18:48:39 bullseyepi weewxd[3348]: CRITICAL __main__:  
 AttributeError: module 'weeutil.weeutil' has no attribute 'log_traceback'
Feb 20 18:48:39 bullseyepi weewxd[3348]: CRITICAL __main__:  
 Exiting.
Feb 20 18:48:39 bullseyepi systemd[1]: weewx.service: Main process exited, 
code=exited, status=1/FAILURE
Feb 20 18:48:39 bullseyepi systemd[1]: weewx.service: Failed with result 
'exit-code'.
Feb 20 18:48:39 bullseyepi systemd[1]: weewx.service: Consumed 1.256s CPU 
time.

What is going 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/9e86020c-1a88-4b0a-b47f-6133c5432b88n%40googlegroups.com.

Re: [weewx-user] Vantage Console wakeup failing again....

['Peter Fletcher' via weewx-user]

It is very unlikely to be the Pi power supply if the Pi itself is not 
flagging up power problems.

On Friday, February 2, 2024 at 9:23:04 PM UTC-5 Joe wrote:

> Its a standard PI4. No external USB devices are connected except for the 
> Vantage data logger.
> There are coils on both ends of the cable, too.  I'm going to try to find 
> another power supply though.
>
> On Friday, February 2, 2024 at 7:53:40 PM UTC-6 Tom Keffer wrote:
>
>> Is this a serial logger with a serial-to-USB converter? Or, a USB logger? 
>> If the former, try another converter.
>>
>> A couple of ferrite coils might help. See the wiki article on 
>> troubleshooting 
>> Davis stations 
>> 
>> .
>>
>> It's also possible that the power supply of the RPi is failing and can't 
>> deliver enough power. Try another power supply, or a powered USB hub.
>>
>>
>>
>> On Fri, Feb 2, 2024 at 5:36 PM Joe  wrote:
>>
>>> So this has starting being a problem again.  Its not really related to 
>>> version 5.  But it is still happening.
>>>
>>> This is a PI4 using the wifi option and a decent power connection and 
>>> USB cord .
>>>
>>> It seems to be a USB detection / conversion problem.
>>>
>>> I've tried restarting the vantage a few times, and the PI computer pull 
>>> the USB plug, and it restarts the USB device, attempts to begin pulling 
>>> data and gets an error.  
>>>
>>> Very frustrating after working for such a long time.
>>>
>>>
>>>
>>>
>>>
>>>
>>> Feb  2 19:30:56 raspberrypi weewxd[920]: INFO __main__: Starting up 
>>> weewx version 5.0.0
>>> Feb  2 19:30:57 raspberrypi weewxd[920]: INFO weewx.engine: Clock error 
>>> is -197.26 seconds (positive is fast)
>>> Feb  2 19:30:57 raspberrypi weewxd[920]: INFO weewx.drivers.vantage: 
>>> Clock set to 2024-02-02 19:30:58 CST (1706923858)
>>> Feb  2 19:30:57 raspberrypi weewxd[920]: INFO weewx.engine: Using 
>>> binding 'wx_binding' to database 'weewx.sdb'
>>> Feb  2 19:30:57 raspberrypi weewxd[920]: INFO weewx.manager: Starting 
>>> backfill of daily summaries
>>> Feb  2 19:30:57 raspberrypi weewxd[920]: INFO weewx.manager: Daily 
>>> summaries up to date
>>> Feb  2 19:30:59 raspberrypi kernel: [ 1426.892512] cp210x ttyUSB0: 
>>> usb_serial_generic_read_bulk_callback - urb stopped: -32
>>> Feb  2 19:30:59 raspberrypi kernel: [ 1426.892962] cp210x ttyUSB0: 
>>> usb_serial_generic_read_bulk_callback - urb stopped: -32
>>> Feb  2 19:30:59 raspberrypi kernel: [ 1426.983918] usb 1-1.3: USB 
>>> disconnect, device number 7
>>> Feb  2 19:30:59 raspberrypi kernel: [ 1426.984264] cp210x ttyUSB0: 
>>> failed set request 0x7 status: -19
>>> Feb  2 19:30:59 raspberrypi kernel: [ 1426.984298] cp210x ttyUSB0: 
>>> failed set request 0x12 status: -19
>>> Feb  2 19:30:59 raspberrypi kernel: [ 1426.984316] cp210x ttyUSB0: 
>>> failed set request 0x0 status: -19
>>> Feb  2 19:30:59 raspberrypi kernel: [ 1426.985025] cp210x ttyUSB0: 
>>> cp210x converter now disconnected from ttyUSB0
>>> Feb  2 19:30:59 raspberrypi kernel: [ 1426.985139] cp210x 1-1.3:1.0: 
>>> device disconnected
>>> Feb  2 19:30:59 raspberrypi weewxd[920]: ERROR weewx.drivers.vantage: 
>>> SerialException on read.
>>> Feb  2 19:30:59 raspberrypi weewxd[920]: ERROR weewx.drivers.vantage:   
>>>    device reports readiness to read but returned no data (device 
>>> disconnected or multiple access on port?)
>>> Feb  2 19:30:59 raspberrypi weewxd[920]: ERROR weewx.drivers.vantage:   
>>>    Is there a competing process running??
>>> Feb  2 19:31:03 raspberrypi weewxd[920]: ERROR weewx.drivers.vantage: 
>>> Unable to wake up Vantage console
>>> Feb  2 19:31:03 raspberrypi weewxd[920]: ERROR weewx.drivers.vantage: 
>>> DMPAFT try #1; error: Unable to wake up Vantage console
>>> Feb  2 19:31:08 raspberrypi weewxd[920]: ERROR weewx.drivers.vantage: 
>>> Unable to wake up Vantage console
>>> Feb  2 19:31:08 raspberrypi weewxd[920]: ERROR weewx.drivers.vantage: 
>>> DMPAFT try #2; error: Unable to wake up Vantage console
>>> Feb  2 19:31:13 raspberrypi weewxd[920]: ERROR weewx.drivers.vantage: 
>>> Unable to wake up Vantage console
>>> Feb  2 19:31:13 raspberrypi weewxd[920]: ERROR weewx.drivers.vantage: 
>>> DMPAFT try #3; error: Unable to wake up Vantage console
>>> Feb  2 19:31:18 raspberrypi weewxd[920]: ERROR weewx.drivers.vantage: 
>>> Unable to wake up Vantage console
>>> Feb  2 19:31:18 raspberrypi weewxd[920]: ERROR weewx.drivers.vantage: 
>>> DMPAFT try #4; error: Unable to wake up Vantage console
>>> Feb  2 19:31:18 raspberrypi weewxd[920]: ERROR weewx.drivers.vantage: 
>>> DMPAFT max tries (4) exceeded.
>>> Feb  2 19:31:18 raspberrypi weewxd[920]: INFO weewx.engine: Main loop 
>>> exiting. Shutting engine down.
>>> Feb  2 19:31:18 raspberrypi weewxd[920]: ERROR weewx.drivers.vantage: 
>>> SerialException on write.
>>> Feb  2 19:31:18 raspberrypi weewxd[920]: ERROR weewx.drivers.vantage:   
>>>    write failed: [Errno 5] Input/output error
>>> Feb  2 

Re: [weewx-user] SolarEdge PV API

['Peter Fletcher' via weewx-user]

I use the SolarEdge cloud API to download and save my PV production data on 
my Raspberry Pi, though I actually save it to a dedicated sqlite database 
rather than incorporating it into weewx's records. I haven't had any 
problems with it and download data every 5 minutes during the solar day 
without throttling. The API does have a declared *daily* limit of 300 
requests, which means that you may need to avoid querying it when it's dark 
out if you intermittently want to get some cumulative numbers as well as 
5-minute real-time ones (as I do), but I haven't found this to be a problem.

Let me know if you would like me to post the Python code.

On Tuesday, August 15, 2023 at 7:02:09 AM UTC-4 Graham Eddy wrote:

> i have been polling a SolarEdge HDWave inverter for a few years.
> my inverter has the LED, so it is not the latest version, and doesn’t have 
> direct API, so i use the API to the (yuck) vendor cloud API (and not happy 
> about it). vendor API throttles to about 1 call/15 mins.
> i have a simple daemon that polls then publishes to mqtt (then the route 
> into weewx is obvious).
> cheers
> *⊣GE⊢*
>
> On 15 Aug 2023, at 3:35 am, Dan'l B  wrote:
>
> Just got a new SolarEdge monitoring system running and looking for ways to 
> display its data in WeeWx. It looks as if I might have several options 
>  and I'm wondering if anyone 
> here has explored this project.
>
> -- 
> 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/dcd61c91-e9ed-420c-9e8b-f2f23a2a232en%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/3958dee9-37d6-4719-8e93-925c55dee6f4n%40googlegroups.com.

[weewx-user] Re: how to add new data from MQTT and include it into db

['Peter Fletcher' via weewx-user]

Your condition 2) is, of course, an absolute requirement. Your condition 1) 
isn't, strictly speaking. It is perfectly possible (and fairly common) for 
a Service triggered by the Archive record event to add (e.g.) a calculated 
value to the archive record being processed, which is then inserted in the 
database.

On Sunday, July 16, 2023 at 4:23:30 AM UTC-4 gjr80 wrote:

> For WeeWX to save data to the database two conditions must be met (1) the 
> data must be present in a field in a WeeWX generated archive record (lines 
> starting with REC: when running WeeWX directly) and (2) the same field must 
> exist in the database. If these conditions are not met then data for that 
> field will not be saved to database, whether the data is from a 
> service/driver or an import. Getting data from new fields into the database 
> is typically achieved by either re-purposing an existing, unused database 
> field (ie you rename the archive record field to match the repurposed 
> database field) or you add a new type to the database with the same name as 
> the field in your archive record. 
>
> I suggest you have a read of the Customising the database 
>  section 
> of the Customization Guide , 
> in particular the Modifying an existing database 
>  
> section.
>
> Gary
> On Sunday, 16 July 2023 at 08:17:47 UTC+1 IceNov wrote:
>
>> Just started experimenting with weewx - and using the simulator with 
>> lighttpd serving up the data to a great looking web page on my rPi.
>>
>> While I don't have a weather station yet, I've been trying to incorporate 
>> data from an mqtt service and have had partial success. I am using the 
>> MQTTSubscribeService.
>>
>> I can see the mqtt data when running weewxd from the command line - it is 
>> one of the fields showing up in the terminal output - but it's not being 
>> added to the database.
>>
>> I've also tried importing a csv file with timestamp and value - which 
>> reported success - but still no new column in the db.
>> How do I get a new measurement into the standard database?
>> Thanks
>> Tony
>>  
>>
>

-- 
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/037e608f-c933-4abb-848e-4acdcced73dcn%40googlegroups.com.

[weewx-user] Review of Startech.com RS232-to-Ethernet adaptor

[Peter Hill]

Hello, I thought people here might be interested in a review of the 
serial-to-Ethernet adaptor I recently added to our Weewx configuration.

We started with a Davis Vantage Pro+ in 2003, and upgraded to Vantage Pro2+ 
in 2013.  We've been using Weewx since 2013 with the Davis serial 
interface, and we like it a lot.

I'll talk about (1) the adaptor; (2) a fix and (3) a workaround for 
problems I've seen; and (4) the reason for the move from serial to TCP/IP 
communication.


1. The serial-to-Ethernet adaptor

There are adaptors that are very inexpensive, but I decided I would prefer 
an industrial one.  A relatively low-cost option is the StarTech.com 
*NETRS2321POE* with one DB9 port and one RJ45 jack.  It comes with a wall 
wart, but a selling point for me was POE (power over Ethernet) so I don't 
need another wart near the Vantage console.

The adaptor has a very basic built-in web server for configuration.  See 
the attached screenshot for my configuration.  You need to be patient, and 
sometimes you need to login again and re-enter your changes, before they 
stick.  I've seen other firmware like that, unfortunately.  Once the 
configuration is set, the adaptor does retain the configuration across 
power cycles.

Of course there are security concerns.  All of this equipment sits inside a 
very restrictive firewall.  I would never allow this adaptor to be 
accessible from the Internet.


2. Fix for occasional timeouts

I did see occasional error messages from Weewx, but I found that adjusting 
time delays in weewx.conf cleared that up.  I'm grateful to this forum for 
providing the information I needed for this fix.

Summary of changes to weewx.conf for the adaptor:

   - Change *type* from *serial* to *ethernet* 
   - Change *host* to the IP address configured in the adaptor
   - If you see Weewx log messages "ip-read error: timed out":
  - Increase *tcp_send_delay* from 0.5, I settled on 1.8 (seconds)
  - Change *timeout* from 4 to 5 (seconds) ... not sure this one is 
  needed
   
That's it.


3.  Workaround for startup problem

I found that any time Weewx restarts, or the Linux server restarts, then 
Weewx and the Davis console will exchange messages, but Weewx will give up 
with an error exit.

The error messages in the system log are misleading.  Systemd says 
"status=4/NOPERMISSION" and Weewx self.socket.connect() says 
"socket.timeout: timed out".  But the Linux tcpdump utility, snooping 
packets on the Ethernet, shows several messages in both directions between 
computer and adaptor, while Weewx is trying to start.  One solution is easy 
-- just power-cycle the adaptor, and Weewx starts right up.  That's not a 
good solution.

I did not dig into this problem.  Instead I wrote a small Linux shell 
script that resets the adaptor.  Several weeks of experience showed that I 
need to call the script from weewx, just before the 'try' block where weewx 
establishes communication with the Davis weather station (in engine.py).  

Now weewx runs without errors, for months at a time.

I'll attach the script as a text file, in case anybody finds a use for it. 
 See the comments in the script for more details.


4. Why use a serial-to-Ethernet adaptor?

In two words:  Dropped characters.

Late last year, I upgraded our Linux server (3.2 GHz 'Haswell' Pentium, 8 
GiB memory) from an ancient 3.x kernel to a more modern 5.x kernel.  Not 
long after the upgrade, I saw dropped characters on several of the RS-232 
devices attached to this computer.  

I tried two different Linux distros, with the same problem.  We settled on 
Debian 11 with the 5.10 kernel.  I suspect an issue in the kernel -- 
perhaps in the Linux perf subsystem, and I have experimented with the 
/proc/sys/kernel/perf* parameters -- but I don't have time to do more 
troubleshooting.

So I went straight to TCP/IP over Ethernet, and that solved the problem for 
Weewx -- which is the most important application on this server.

For other devices, I bought 'Gearmo' USB-to-serial converters based on the 
FTDI chip.  They do help, but there are still occasional dropped characters.

--Old Guy Yelling At A Cloud

-- 
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/929fc176-d6a1-4e51-a2af-7da588833845n%40googlegroups.com.


reset_netrs2321poe.sh.txt
Description: application/shellscript

Re: [weewx-user] How does weewx deal with null values in longer term graphs?

['Peter Fletcher' via weewx-user]

I would not expect the standard SQL behavior (ignoring nulls and averaging 
the rest of the values) to result in what I am seeing in the graphs, but 
you are probably right that I am going to have to define a specialty 
aggregation.

On Saturday, June 3, 2023 at 8:10:26 PM UTC-4 Tom Keffer wrote:

> WeeWX uses a SQL statement to calculate the averages. SQL ignores any 
> nulls in an aggregate interval. So, if there is nothing but nulls in an 
> interval, the result will be null, not zero.
>
> Null values signify unknown values, not zero. I didn't follow the 
> discussion of your service, but if you can't change it to store zero when 
> the value is, well, zero, then you'll have to define your own specialty 
> xtype aggregations, which treats null as a zero, perhaps by using the SQL 
> function IFNULL(). 
>
> Instructions on defining custom xtype aggregations: 
> https://github.com/weewx/weewx/wiki/xtypes#calculating-aggregates
>
>
> On Sat, Jun 3, 2023 at 4:39 PM 'Peter Fletcher' via weewx-user <
> weewx...@googlegroups.com> wrote:
>
>> For reasons discussed elsewhere, I have a user service which saves nulls. 
>> rather than zeros to the archive records for UV and solar radiation values 
>> during the night. Daily and weekly graphs continue to look as they should 
>> (with the daytime tracings arising from at or very near to the zero axis). 
>> On the monthly graphs, however, the tracings do not touch the zero axis at 
>> either end of the daytime peak, I am guessing that, in calculating averaged 
>> data points for the longer term graphs, weewx is treating the average of 
>> any group of values that contains a null value as null. There is some logic 
>> to this, but the results are unhelpful in this case. Am I right about the 
>> cause of the problem, and is there a workaround for it? 
>>
>> -- 
>> 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/aff03e49-1c45-4383-bc80-a3db9425ac8fn%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/weewx-user/aff03e49-1c45-4383-bc80-a3db9425ac8fn%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/0f0dab2d-ad9f-4297-a5db-c87c23981ae8n%40googlegroups.com.

Re: [weewx-user] New install of Weewx, Raspberry Pi, Apache 2.4.56 - 403 Forbidden

[Peter Hurn]

Thanks I tried the  sudo chmod -R 755 /var/www/html/weewx suggested, still 
the same issue unfortunately 
You don't have permission to access this resource.

On Friday, 19 May 2023 at 13:50:17 UTC+1 Rainer Lang wrote:

> did you change the permissions for weewx web folder
>
> /var/www/html/weewx
>
> or
>
> /home/weewx/public_html
>
> whichever you are using ?
>
> The example for the first path would be
>
> sudo chmod -R 755 /var/www/html/weewx
>
> only then the Apache webserver has the permission to read (and display) 
> the /var/www/html/weewx folder content
>
> (for a /home/weewx installation the command would be: 
> sudo chmod -R 755 /home/weewx/public_html  )
> On 18.05.2023 23:48, Peter Hurn wrote:
>
> Hello, 
>
> I am trying to install Weewx fresh on a Raspberry PI, running Debian 
> Bullseye,
> I would like to host the website internally from the Pi,
> I have installed Apache 2.4.56 and checked the default Apache page 
> displays correctly, which it does.
>
> I then followed the Weewx installation which installed.
>
> I then followed the instructions from the wiki article *Configure a web 
> server (Apache, NGINX or lighttpd)* 
> <https://github.com/weewx/weewx/wiki/Configure-a-web-server-(Apache,-NGINX-or-lighttpd)>
>  
>
> The section for Apache 2.4 worked however when I try to navigate to the 
> server address/weewx/ I now receive the following error.
>
> --
>
> Forbidden
> You don't have permission to access this resource.
>
> Apache/2.4.56 (Raspbian) Server at (IP) Port 80
>
> -----
>
> I have searched but don't seem to be having much luck resolving the issue, 
> any thoughts?
>
> Kind regards,
>
> Peter.
>
> -- 
> 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/b43bca91-0b12-42c0-b4db-dc06cfcf1fe0n%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/weewx-user/b43bca91-0b12-42c0-b4db-dc06cfcf1fe0n%40googlegroups.com?utm_medium=email_source=footer>
> .
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/eb612886-cc2a-4d0d-9c06-1486203b4c13n%40googlegroups.com.

[weewx-user] New install of Weewx, Raspberry Pi, Apache 2.4.56 - 403 Forbidden

[Peter Hurn]

Hello,

I am trying to install Weewx fresh on a Raspberry PI, running Debian 
Bullseye,
I would like to host the website internally from the Pi,
I have installed Apache 2.4.56 and checked the default Apache page displays 
correctly, which it does.

I then followed the Weewx installation which installed.

I then followed the instructions from the wiki article *Configure a web 
server (Apache, NGINX or lighttpd)* 
<https://github.com/weewx/weewx/wiki/Configure-a-web-server-(Apache,-NGINX-or-lighttpd)>
 

The section for Apache 2.4 worked however when I try to navigate to the 
server address/weewx/ I now receive the following error.

--

Forbidden
You don't have permission to access this resource.

Apache/2.4.56 (Raspbian) Server at (IP) Port 80

-

I have searched but don't seem to be having much luck resolving the issue, 
any thoughts?

Kind regards,

Peter.

-- 
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/b43bca91-0b12-42c0-b4db-dc06cfcf1fe0n%40googlegroups.com.

Re: [weewx-user] Strange problems using FTPgenerator just started happening.

[Peter Neilley]

Thanks Geoff, I hadn't thought to give the rsync option a try.  I'll need 
to refresh myself on how to set it up since I haven't used it in a long 
time, but good idea.

It's still very strange to me that some of the products I'm trying to 
upload are still getting through every once in awhile.  If 1and1 deprecated 
a core functionality, then you would think it would be all of nothing,  and 
not partially working intermittently.  Who knows   Anyway, thanks for 
the tip.  I'll report back if successful.

On Thursday, April 6, 2023 at 7:56:13 AM UTC-4 geoff...@gmail.com wrote:

> Pretty sure I saw this problem with ftp from weewx on RPi some time ago. 
>  It coincided with 1and1 deprecating ‘open’ ftp; as memory serves, RPi at 
> the time wouldn’t support the required flavour of secure ftp.
>
> I resolved the problem by using rsync to update my web pages.  It’s not 
> completely without problems - there are issues (I think) with server-side 
> caching, but, in general, it works ok.
>
> Hth
>
> Geoff
>
> On Thursday, 6 April 2023 at 01:28:25 UTC+1 Tom Keffer wrote:
>
>> Are you using secure_ftp?
>>
>> On Wed, Apr 5, 2023 at 3:34 PM Peter Neilley  wrote:
>>
>>> Hi! I've been using weewx on a raspberrypi for many years including 
>>> uploading reports to an account on a cloud provider (1and1.com)  to 
>>> post standard reports on my personal webpage.About 2 weeks ago I 
>>> started having problems with getting the reports uploaded to the cloud via 
>>> the weewx FTPgenerator process.  Digging through log files, I'm getting 
>>> "connection refused" errors from the ftpGenerator process.   I didn't make 
>>> any changes to weewx or the raspberrypi to trigger the errors, hence 
>>> suspect something changed on provider's side.  
>>>
>>> But the issue is strange and I can't figure it out hence posting here 
>>> even though I suspect the issue is not weewx related.  Since there's lots 
>>> of smart people here I thought I might get some ideas on how to solve it.  
>>>  Here's some facts:
>>>
>>>  1.  95% of the products I'm trying to ftp from weewx to the cloud 
>>> account are not getting through.  Mysteriously, a handful here and there do 
>>> make it through.
>>> 2.  I upgraded my rPi kernel to 4.19.x and weewx to 4.10.2 and no 
>>> improvement in the issue.
>>> 3. I can manually ftp the products using the command line ftp program 
>>> supplied with rPi linux with no issues at all.  Same if I use sftp or scp.
>>> 4.  I double checked my credentials in weewx.conf to make sure nothing 
>>> was wrong with those. But again, the fact that some products get through 
>>> suggests credentials are not the issue.
>>> 3.  log files in /var/log (both system.log and messages.log) indicate 
>>> the weewx ftpGenerator process is failing with a "connection refused" error 
>>> messages.
>>> 4. I can reproduce the error if I manually start a python shell and try 
>>> to upload the files manually using ftplib in python.  I'm using python 2.7
>>>
>>> This is telling me something about a new incompatibility between the 
>>> python library in rPi linux and my cloud provider's FTP server is causing 
>>> the issue.  But I haven't been able to figure it out.   So wonder if anyone 
>>> here has any guesses and ideas.
>>>
>>> Thanks for your support.
>>>
>>> -- 
>>> 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/761a1bfa-3ba4-47a7-97e8-9096d708c06an%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/weewx-user/761a1bfa-3ba4-47a7-97e8-9096d708c06an%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/f951749d-e030-4b6b-ac62-3d488d53864an%40googlegroups.com.

[weewx-user] Strange problems using FTPgenerator just started happening.

[Peter Neilley]

Hi! I've been using weewx on a raspberrypi for many years including 
uploading reports to an account on a cloud provider (1and1.com)  to post 
standard reports on my personal webpage.About 2 weeks ago I started 
having problems with getting the reports uploaded to the cloud via the 
weewx FTPgenerator process.  Digging through log files, I'm getting 
"connection refused" errors from the ftpGenerator process.   I didn't make 
any changes to weewx or the raspberrypi to trigger the errors, hence 
suspect something changed on provider's side.  

But the issue is strange and I can't figure it out hence posting here even 
though I suspect the issue is not weewx related.  Since there's lots of 
smart people here I thought I might get some ideas on how to solve it.  
 Here's some facts:

 1.  95% of the products I'm trying to ftp from weewx to the cloud account 
are not getting through.  Mysteriously, a handful here and there do make it 
through.
2.  I upgraded my rPi kernel to 4.19.x and weewx to 4.10.2 and no 
improvement in the issue.
3. I can manually ftp the products using the command line ftp program 
supplied with rPi linux with no issues at all.  Same if I use sftp or scp.
4.  I double checked my credentials in weewx.conf to make sure nothing was 
wrong with those. But again, the fact that some products get through 
suggests credentials are not the issue.
3.  log files in /var/log (both system.log and messages.log) indicate the 
weewx ftpGenerator process is failing with a "connection refused" error 
messages.
4. I can reproduce the error if I manually start a python shell and try to 
upload the files manually using ftplib in python.  I'm using python 2.7

This is telling me something about a new incompatibility between the python 
library in rPi linux and my cloud provider's FTP server is causing the 
issue.  But I haven't been able to figure it out.   So wonder if anyone 
here has any guesses and ideas.

Thanks for your support.

-- 
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/761a1bfa-3ba4-47a7-97e8-9096d708c06an%40googlegroups.com.

Re: [weewx-user] Raspberry Pi ... What's happening?

['Peter Fletcher' via weewx-user]

I would endorse the 'if it aint broke, don't replace it' approach. I have a 
1 GB 3B running the latest version of weewx and a number of other services 
for home control, and there would still be plenty of spare capacity if I 
could think of something else I wanted to do with it. An 8GB 4B would be 
extreme overkill unless you have some other specific reasons for needing a 
Pi with all that power.

On Wednesday, March 29, 2023 at 7:51:46 PM UTC-4 Greg Troxel wrote:

> Yves Martin  writes:
>
> > What model of motherboard with how much memory on it, do you suggest for 
> > weewx? I have here an old version (Raspberry Pi 2B 1GB) and it works 
> well 
> > but the board is 4-5 years old. It is time to upgrade. What is your 
> > suggestion?
>
> I am using a 3B with 1 GB of RAM, and it works fine. 4-5 years is just
> not that old for a computer. If it's reliable, and you aren't running
> out of cpu cycles, there's no need to change anything. If anything, you
> might want to use a USB SSD as your system and data disk.
>
> Also look at low-power server-type x86 boards. Possibilities include
> pcengines apu2 and protectli.
>

-- 
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/7e7d1a3e-13d0-46d4-b273-3372d684f945n%40googlegroups.com.

Re: [weewx-user] Raspberry Pi ... What's happening?

['Peter Fletcher' via weewx-user]

I would endorse the 'if it aint broke, don't replace it' approach. I have a 
1 GB 2B running the latest version of weewx and a number of other services 
for home control, and there would still be plenty of spare capacity if I 
could think of something else I wanted to do with it. An 8GB 4B would be 
extreme overkill unless you have some other specific reasons for needing a 
Pi with all that power.
On Wednesday, March 29, 2023 at 7:51:46 PM UTC-4 Greg Troxel wrote:

> Yves Martin  writes:
>
> > What model of motherboard with how much memory on it, do you suggest for 
> > weewx? I have here an old version (Raspberry Pi 2B 1GB) and it works 
> well 
> > but the board is 4-5 years old. It is time to upgrade. What is your 
> > suggestion?
>
> I am using a 3B with 1 GB of RAM, and it works fine. 4-5 years is just
> not that old for a computer. If it's reliable, and you aren't running
> out of cpu cycles, there's no need to change anything. If anything, you
> might want to use a USB SSD as your system and data disk.
>
> Also look at low-power server-type x86 boards. Possibilities include
> pcengines apu2 and protectli.
>

-- 
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/0a97e0eb-c2ce-4b91-950f-632267d7470fn%40googlegroups.com.

[weewx-user] Re: Weewx not picking up rain from ecowitt

[Peter Peter]

Thanks Gary. I did have it there but as I said it was something I had done. 
I have been creating backups of the config as I have been altering things 
and used the incorrect file. Looks like its showing a bit of data now so I 
will keep watching.
Many thanks

On Thursday, March 23, 2023 at 1:13:41 PM UTC+11 gjr80 wrote:

> Unfortunately it makes it a little difficult to be certain what fields are 
> there and what fields are missing. Assuming that rain and rainRate are 
> missing, but p_rainRate and (I suspect) p_yearRain are present, this 
> suggests that the field map has not been altered as per my first post. Did 
> you add a [[field_map_extensions]] stanza to weewx.conf as per my first 
> post? If not you will need to add it and restart WeeWX/try the above checks 
> again.
>
> Gary
>
> On Thursday, 23 March 2023 at 09:41:40 UTC+10 sale...@gmail.com wrote:
>
> I just did a screen copy from a terminal that I have going with ssh
>
> 2023-03-22 23:19:02 UTC (1679527142): 'dateTime': '1679527142', 
> 'daymaxwind': '4.1', '
> '64', 'extraTemp1': '20.8', 'inHumidity': '66', 'inTemp': '20.6', 
> 'lightning_distance'
> ning_last_det_time': '1679527051', 'lightning_strike_count': 'None', 
> 'lightningcount':
> ity': '3210.0', 'outHumidity': '96', 'outTemp': '15.1', 'p_dayRain': 
> '2.6', 'p_monthRa
> _rain': 'None', 'p_rainRate': '15.0', 'p_stormRain': '5.1', 'p_weekRain': 
> '5.6', 'p_ye
> , 'pressure': '944.3', 'relbarometer': '944.3', 'soilMoist1': '44', 
> 'soilMoist2': '22'
> : '68', 'usUnits': '17', 'UV': '0', 'uvradiation': '0.0', 'wh31_ch1_batt': 
> '0', 'wh31_
>  'wh51_ch1_batt': '1.6', 'wh51_ch1_sig': '4', 'wh51_ch2_batt': '1.6', 
> 'wh51_ch2_sig':
> _batt': '1.5', 'wh51_ch7_sig': '4', 'wh57_batt': '5', 'wh57_sig': '4', 
> 'windDir': '240
>  '1.7', 'windSpeed': '0.9', 'ws90_batt': '3.2', 'ws90_sig': '4'
>
>

-- 
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/45a000d2-80d6-4add-a9e2-5b87895cd81cn%40googlegroups.com.

[weewx-user] Re: Weewx not picking up rain from ecowitt

[Peter Peter]

y, March 23, 2023 at 10:07:09 AM UTC+11 gjr80 wrote:
>>
>>> There are a couple of checks you can do to confirm the gateway device is 
>>> working and WeeWX is receiving the expected data. The first check is to run 
>>> the driver directly with the --live-data command line option. This will 
>>> display the data received by the gateway device before the data is mapped 
>>> to any WeeWX field. This proves the gateway device is correctly talking to 
>>> the sensors. The second check is to again run the driver directly but this 
>>> time with the --test-driver command line option. This will result in 
>>> the driver emitting loop packets to the console. This again proves the 
>>> gateway device is talking to the sensors, but also proves the mapping of 
>>> gateway device data to WeeWX fields. If you like, it shows what data the 
>>> driver will send to WeeWX. The final check is to run WeeWX directly. This 
>>> check proves the sensors are communicating with the gateway device, the 
>>> driver is mapping the gateway device data to WeeWX fields and that WeeWX is 
>>> receiving the loop packet data from the gateway device driver. When running 
>>> WeeWX directly you should see rainfall data appearing in WeeWX rain related 
>>> fields, eg rain and rainRate. If this is not the case then it is 
>>> unlikely that any WeeWX generated outputs (reports, uploads etc) will 
>>> contain rain related data.
>>>
>>> Running the latter two of above checks are covered in the Gateway 
>>> driver readme 
>>> <https://github.com/gjr80/weewx-gw1000/blob/master/README.md#installation-as-a-weewx-driver>.
>>>  
>>> Running the driver directly with the --live-data command line option is 
>>> not covered in the readme, but it is identical to running the driver 
>>> directly with the --test-driver command line option you just need to 
>>> substitute the --live-data command line option. You can also use the 
>>> --help command line option when running the driver directly to display 
>>> details of each available command line option.
>>>
>>> Gary
>>>
>>> On Thursday, 23 March 2023 at 05:40:27 UTC+10 sale...@gmail.com wrote:
>>>
>>>> Hey again Garry. I am trying to work out if this is a weewx or 
>>>> weather34 issue. I can see as mentioned above the rain (or what I believe 
>>>> is the rain figures) in the loop but when I went to my cwop page after I 
>>>> went home it shows no rain either and that gets fed from Weewx. The 
>>>> wunderground page that gets fed directly from the GW2000 shows the rain.
>>>>
>>>> I am happy to post any logs etc if that helps or look at anything if 
>>>> you can point me in that direction.
>>>>
>>>> On Wednesday, March 22, 2023 at 12:17:58 PM UTC+11 Peter Peter wrote:
>>>>
>>>>> Thanks Gary. I was trying to beat you back here but alas I didnt. I 
>>>>> did a search on the gw2000 and found some posts and like you suggested 
>>>>> here 
>>>>> ran Weewx directly and can see both the rain in the loop and rec so that 
>>>>> parts seems ok. I will do a bit more research and see what I can find. I 
>>>>> have been trying the Weather34 skin/web stuff and thats how I noticed it 
>>>>> and then went and looked at other stuff. It gives me something to tinker 
>>>>> with
>>>>>
>>>>> On Wednesday, March 22, 2023 at 11:47:10 AM UTC+11 gjr80 wrote:
>>>>>
>>>>>> On Wednesday, 22 March 2023 at 10:05:31 UTC+10 sale...@gmail.com 
>>>>>> wrote:
>>>>>>
>>>>>> Hey all.
>>>>>>
>>>>>> I have been running Weewx together with my Ecowitt and using the 
>>>>>> GW1000 setup. My base unit is actually a GW2000C_V2.2.3C
>>>>>>
>>>>>> When I initially set it up I ran it in simulator mode and all seemed 
>>>>>> ok
>>>>>>
>>>>>> I have been waiting for rain and we have some today but it appears 
>>>>>> Weewx isnt picking up the rain info. The last update of the rain data in 
>>>>>> relation the the graphics was over a week ago and thats when I changed 
>>>>>> from 
>>>>>> Simulator to real. At that stage I deleted the database and let it start.
>>>>>>
>>>>>>  
>>>>>> What sensor is connected to your GW2000 a

[weewx-user] Re: Weewx not picking up rain from ecowitt

[Peter Peter]

> the loop packet data from the gateway device driver. When running WeeWX 
> directly you should see rainfall data appearing in WeeWX rain related 
> fields, eg rain and rainRate. If this is not the case then it is unlikely 
> that any WeeWX generated outputs (reports, uploads etc) will contain rain 
> related data.
>
> Running the latter two of above checks are covered in the Gateway driver 
> readme 
> <https://github.com/gjr80/weewx-gw1000/blob/master/README.md#installation-as-a-weewx-driver>.
>  
> Running the driver directly with the --live-data command line option is 
> not covered in the readme, but it is identical to running the driver 
> directly with the --test-driver command line option you just need to 
> substitute the --live-data command line option. You can also use the 
> --help command line option when running the driver directly to display 
> details of each available command line option.
>
> Gary
>
> On Thursday, 23 March 2023 at 05:40:27 UTC+10 sale...@gmail.com wrote:
>
>> Hey again Garry. I am trying to work out if this is a weewx or weather34 
>> issue. I can see as mentioned above the rain (or what I believe is the rain 
>> figures) in the loop but when I went to my cwop page after I went home it 
>> shows no rain either and that gets fed from Weewx. The wunderground page 
>> that gets fed directly from the GW2000 shows the rain.
>>
>> I am happy to post any logs etc if that helps or look at anything if you 
>> can point me in that direction.
>>
>> On Wednesday, March 22, 2023 at 12:17:58 PM UTC+11 Peter Peter wrote:
>>
>>> Thanks Gary. I was trying to beat you back here but alas I didnt. I did 
>>> a search on the gw2000 and found some posts and like you suggested here ran 
>>> Weewx directly and can see both the rain in the loop and rec so that parts 
>>> seems ok. I will do a bit more research and see what I can find. I have 
>>> been trying the Weather34 skin/web stuff and thats how I noticed it and 
>>> then went and looked at other stuff. It gives me something to tinker with
>>>
>>> On Wednesday, March 22, 2023 at 11:47:10 AM UTC+11 gjr80 wrote:
>>>
>>>> On Wednesday, 22 March 2023 at 10:05:31 UTC+10 sale...@gmail.com wrote:
>>>>
>>>> Hey all.
>>>>
>>>> I have been running Weewx together with my Ecowitt and using the GW1000 
>>>> setup. My base unit is actually a GW2000C_V2.2.3C
>>>>
>>>> When I initially set it up I ran it in simulator mode and all seemed ok
>>>>
>>>> I have been waiting for rain and we have some today but it appears 
>>>> Weewx isnt picking up the rain info. The last update of the rain data in 
>>>> relation the the graphics was over a week ago and thats when I changed 
>>>> from 
>>>> Simulator to real. At that stage I deleted the database and let it start.
>>>>
>>>>  
>>>> What sensor is connected to your GW2000 and reporting rain? I'm 
>>>> guessing it is a WS90? The GW2000 (and other Ecowitt gateway devices) 
>>>> simultaneously support traditional tipping type rain gauges (eg WH40) as 
>>>> well as piezo based WS90. A default install of the Ecowitt Gateway driver 
>>>> will map tipping rain gauge data through to WeeWX. If using a piezo based 
>>>> sensor (eg WS90) then the piezo rain data is passed through to WeeWX, but 
>>>> it must be manually mapped to suitable WeeWX fields. If you do indeed have 
>>>> a WS90 (and no other rain gauge) try adding a [[field_map_extensions]] 
>>>> stanza to [GW1000] in weewx.conf as follows:
>>>>
>>>> [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 
>>>>  
>>>> Stop WeeWX if it is running and try running WeeWX directly 
>>>> <http://weewx.com/docs/usersguide.htm#Running_directly>, you should 
>>>> see rainfall data appearing in the usual WeeWX rain fields. If you do 
>>>> indeed see rainfall data then stop WeeWX and restart it as a daemon.
>>>>
>>>> If you don't have a WS90 or have multiple rain gauges then some 
>>>> additional changes will be required. If this is the case, or the above 
>>>> does 
>>>> not work, po

[weewx-user] Re: Weewx not picking up rain from ecowitt

[Peter Peter]

And a link to the Weewx webpages hosted on a different server uploaded via 
ftp https://weewx.secs.net.au/index.html

On Thursday, March 23, 2023 at 6:40:27 AM UTC+11 Peter Peter wrote:

> Hey again Garry. I am trying to work out if this is a weewx or weather34 
> issue. I can see as mentioned above the rain (or what I believe is the rain 
> figures) in the loop but when I went to my cwop page after I went home it 
> shows no rain either and that gets fed from Weewx. The wunderground page 
> that gets fed directly from the GW2000 shows the rain.
>
> I am happy to post any logs etc if that helps or look at anything if you 
> can point me in that direction.
>
> On Wednesday, March 22, 2023 at 12:17:58 PM UTC+11 Peter Peter wrote:
>
>> Thanks Gary. I was trying to beat you back here but alas I didnt. I did a 
>> search on the gw2000 and found some posts and like you suggested here ran 
>> Weewx directly and can see both the rain in the loop and rec so that parts 
>> seems ok. I will do a bit more research and see what I can find. I have 
>> been trying the Weather34 skin/web stuff and thats how I noticed it and 
>> then went and looked at other stuff. It gives me something to tinker with
>>
>> On Wednesday, March 22, 2023 at 11:47:10 AM UTC+11 gjr80 wrote:
>>
>>> On Wednesday, 22 March 2023 at 10:05:31 UTC+10 sale...@gmail.com wrote:
>>>
>>> Hey all.
>>>
>>> I have been running Weewx together with my Ecowitt and using the GW1000 
>>> setup. My base unit is actually a GW2000C_V2.2.3C
>>>
>>> When I initially set it up I ran it in simulator mode and all seemed ok
>>>
>>> I have been waiting for rain and we have some today but it appears Weewx 
>>> isnt picking up the rain info. The last update of the rain data in relation 
>>> the the graphics was over a week ago and thats when I changed from 
>>> Simulator to real. At that stage I deleted the database and let it start.
>>>
>>>  
>>> What sensor is connected to your GW2000 and reporting rain? I'm guessing 
>>> it is a WS90? The GW2000 (and other Ecowitt gateway devices) simultaneously 
>>> support traditional tipping type rain gauges (eg WH40) as well as piezo 
>>> based WS90. A default install of the Ecowitt Gateway driver will map 
>>> tipping rain gauge data through to WeeWX. If using a piezo based sensor (eg 
>>> WS90) then the piezo rain data is passed through to WeeWX, but it must be 
>>> manually mapped to suitable WeeWX fields. If you do indeed have a WS90 (and 
>>> no other rain gauge) try adding a [[field_map_extensions]] stanza to 
>>> [GW1000] in weewx.conf as follows:
>>>
>>> [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 
>>>  
>>> Stop WeeWX if it is running and try running WeeWX directly 
>>> <http://weewx.com/docs/usersguide.htm#Running_directly>, you should see 
>>> rainfall data appearing in the usual WeeWX rain fields. If you do indeed 
>>> see rainfall data then stop WeeWX and restart it as a daemon.
>>>
>>> If you don't have a WS90 or have multiple rain gauges then some 
>>> additional changes will be required. If this is the case, or the above does 
>>> not work, post back here.
>>>  
>>>
>>> The only thing I notice in the debug syslog entry that may be related is 
>>> DEBUG user.gw1000: Unknown field address '7B' detected. Remaining data 
>>> '00' ignored.
>>>
>>>  
>>> You can safely ignore this; the GW2000 firmware includes an additional 
>>> field that was not identified in the Ecowitt Gateway API documentation on 
>>> which the v0.5.0b5 Ecwoitt Gateway driver is based. Consequently v0.5.0b5 
>>> ignores, but debug logs, the unknown field. Ecowitt has since documented 
>>> this unknown field as indicating whether or not radiation compensation is 
>>> applied when reporting outside temperature for WH65/WH69/WS80/WS90 devices.
>>>  
>>> 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/4d8ae555-a978-4cc0-a7f2-da8184b82188n%40googlegroups.com.

[weewx-user] Re: Weewx not picking up rain from ecowitt

[Peter Peter]

Hey again Garry. I am trying to work out if this is a weewx or weather34 
issue. I can see as mentioned above the rain (or what I believe is the rain 
figures) in the loop but when I went to my cwop page after I went home it 
shows no rain either and that gets fed from Weewx. The wunderground page 
that gets fed directly from the GW2000 shows the rain.

I am happy to post any logs etc if that helps or look at anything if you 
can point me in that direction.

On Wednesday, March 22, 2023 at 12:17:58 PM UTC+11 Peter Peter wrote:

> Thanks Gary. I was trying to beat you back here but alas I didnt. I did a 
> search on the gw2000 and found some posts and like you suggested here ran 
> Weewx directly and can see both the rain in the loop and rec so that parts 
> seems ok. I will do a bit more research and see what I can find. I have 
> been trying the Weather34 skin/web stuff and thats how I noticed it and 
> then went and looked at other stuff. It gives me something to tinker with
>
> On Wednesday, March 22, 2023 at 11:47:10 AM UTC+11 gjr80 wrote:
>
>> On Wednesday, 22 March 2023 at 10:05:31 UTC+10 sale...@gmail.com wrote:
>>
>> Hey all.
>>
>> I have been running Weewx together with my Ecowitt and using the GW1000 
>> setup. My base unit is actually a GW2000C_V2.2.3C
>>
>> When I initially set it up I ran it in simulator mode and all seemed ok
>>
>> I have been waiting for rain and we have some today but it appears Weewx 
>> isnt picking up the rain info. The last update of the rain data in relation 
>> the the graphics was over a week ago and thats when I changed from 
>> Simulator to real. At that stage I deleted the database and let it start.
>>
>>  
>> What sensor is connected to your GW2000 and reporting rain? I'm guessing 
>> it is a WS90? The GW2000 (and other Ecowitt gateway devices) simultaneously 
>> support traditional tipping type rain gauges (eg WH40) as well as piezo 
>> based WS90. A default install of the Ecowitt Gateway driver will map 
>> tipping rain gauge data through to WeeWX. If using a piezo based sensor (eg 
>> WS90) then the piezo rain data is passed through to WeeWX, but it must be 
>> manually mapped to suitable WeeWX fields. If you do indeed have a WS90 (and 
>> no other rain gauge) try adding a [[field_map_extensions]] stanza to 
>> [GW1000] in weewx.conf as follows:
>>
>> [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 
>>  
>> Stop WeeWX if it is running and try running WeeWX directly 
>> <http://weewx.com/docs/usersguide.htm#Running_directly>, you should see 
>> rainfall data appearing in the usual WeeWX rain fields. If you do indeed 
>> see rainfall data then stop WeeWX and restart it as a daemon.
>>
>> If you don't have a WS90 or have multiple rain gauges then some 
>> additional changes will be required. If this is the case, or the above does 
>> not work, post back here.
>>  
>>
>> The only thing I notice in the debug syslog entry that may be related is 
>> DEBUG user.gw1000: Unknown field address '7B' detected. Remaining data 
>> '00' ignored.
>>
>>  
>> You can safely ignore this; the GW2000 firmware includes an additional 
>> field that was not identified in the Ecowitt Gateway API documentation on 
>> which the v0.5.0b5 Ecwoitt Gateway driver is based. Consequently v0.5.0b5 
>> ignores, but debug logs, the unknown field. Ecowitt has since documented 
>> this unknown field as indicating whether or not radiation compensation is 
>> applied when reporting outside temperature for WH65/WH69/WS80/WS90 devices.
>>  
>> 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/94dfe061-5c38-4e20-b930-b2564036c181n%40googlegroups.com.

Re: [weewx-user] Re: Weather34 Skin and no rain

[Peter Peter]

A couple of points. Thank you for supporting users. I used to write 
sharewar back in the nineties and know that creating the initial product is 
10% of the work and supporting the users is the other 250%

In sniffing around my system after coming home (initialy started this 
whilst at work) I just noticed 
that https://www.pwsweather.com/station/pws/goulbnswgrs isnt showing the 
rain. That gets updated from Weewx. Wunderground gets updated from the 
gw2000 and it shows the rain.. I fully expect its something I have done 

On Wednesday, March 22, 2023 at 6:52:52 PM UTC+11 Peter Peter wrote:

> Yeah its public. Just been doing a debug and watching sys log etc
> Only fault I can see in syslog so far is  DEBUG weewx.reportengine: Cannot 
> read localization file /etc/weewx/skins/Weather34/lang/en.conf for report 
> 'Weather34Report': Config file not found: 
> "/etc/weewx/skins/Weather34/lang/en.conf".
>
> and website is
> https://weather.goulburnradioscan.org
>
> On Wednesday, March 22, 2023 at 6:36:49 PM UTC+11 Ian Millard wrote:
>
>> Is your website public. If so can you direct me to it please. Otherwise 
>> PM your w34realtime.txt file.
>> Thank you,
>> Ian
>>
>> Sent from my iPad.
>>
>> On 22 Mar 2023, at 02:10, Peter Peter  wrote:
>>
>> As a side note I also miss the solar radiation reading as well (but get 
>> the UV) so I am thinking as per the reading of other conversations that it 
>> has something to do with real time files
>>
>>
>>
>> On Wednesday, March 22, 2023 at 1:08:36 PM UTC+11 Peter Peter wrote:
>>
>>> First question: Is this the correct place/forum/group for Weather34?
>>>
>>> if yes see next
>>>
>>> Ok all and thanks to Garry we seem to be collecting data via Weewx 
>>> including rain butits not showing up in the Weather34 skin. I have been 
>>> searching around in the weewx conf file etc and looked at various things 
>>> but cannot find an explanation for the seetings so maybe there is no issue 
>>> and the settings are just incorrect.
>>>
>>> the main thing I can see is 
>>> Weather34RealTime]
>>> realtime_path_only = ""
>>> unit_system = METRICWX
>>> exclude_fields = rain
>>> cache_enable = True
>>> cache_stale_time = 900
>>>
>>> So I was wondering if the exclude_fields = rain is my issue or the 
>>> missing paths?
>>>
>>> and somewhere else there was something to do with rain, mm 5 and I 
>>> wondered if that was a minimum amount to register or something?
>>>
>>>
>>> weewx_port = 25252
>>> webserver_address = ""
>>> weewxserver_address = ""
>>> weewx_file_transfer = ""
>>> HTML_ROOT = ""
>>>
>>>
>>> -- 
>> 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/800ab33e-8ddc-4f16-8ddc-c464b445de0cn%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/weewx-user/800ab33e-8ddc-4f16-8ddc-c464b445de0cn%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/f7c1d301-88d6-4b00-9ff6-6bd2c0c467c1n%40googlegroups.com.

Re: [weewx-user] Re: Weather34 Skin and no rain

[Peter Peter]

Yeah its public. Just been doing a debug and watching sys log etc
Only fault I can see in syslog so far is  DEBUG weewx.reportengine: Cannot 
read localization file /etc/weewx/skins/Weather34/lang/en.conf for report 
'Weather34Report': Config file not found: 
"/etc/weewx/skins/Weather34/lang/en.conf".

and website is
https://weather.goulburnradioscan.org

On Wednesday, March 22, 2023 at 6:36:49 PM UTC+11 Ian Millard wrote:

> Is your website public. If so can you direct me to it please. Otherwise PM 
> your w34realtime.txt file.
> Thank you,
> Ian
>
> Sent from my iPad.
>
> On 22 Mar 2023, at 02:10, Peter Peter  wrote:
>
> As a side note I also miss the solar radiation reading as well (but get 
> the UV) so I am thinking as per the reading of other conversations that it 
> has something to do with real time files
>
>
>
> On Wednesday, March 22, 2023 at 1:08:36 PM UTC+11 Peter Peter wrote:
>
>> First question: Is this the correct place/forum/group for Weather34?
>>
>> if yes see next
>>
>> Ok all and thanks to Garry we seem to be collecting data via Weewx 
>> including rain butits not showing up in the Weather34 skin. I have been 
>> searching around in the weewx conf file etc and looked at various things 
>> but cannot find an explanation for the seetings so maybe there is no issue 
>> and the settings are just incorrect.
>>
>> the main thing I can see is 
>> Weather34RealTime]
>> realtime_path_only = ""
>> unit_system = METRICWX
>> exclude_fields = rain
>> cache_enable = True
>> cache_stale_time = 900
>>
>> So I was wondering if the exclude_fields = rain is my issue or the 
>> missing paths?
>>
>> and somewhere else there was something to do with rain, mm 5 and I 
>> wondered if that was a minimum amount to register or something?
>>
>>
>> weewx_port = 25252
>> webserver_address = ""
>> weewxserver_address = ""
>> weewx_file_transfer = ""
>> HTML_ROOT = ""
>>
>>
>> -- 
> 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/800ab33e-8ddc-4f16-8ddc-c464b445de0cn%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/weewx-user/800ab33e-8ddc-4f16-8ddc-c464b445de0cn%40googlegroups.com?utm_medium=email_source=footer>
> .
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/15664215-aa43-4c37-8101-51591ef2252an%40googlegroups.com.

[weewx-user] Re: Weather34 Skin and no rain

[Peter Peter]

As a side note I also miss the solar radiation reading as well (but get the 
UV) so I am thinking as per the reading of other conversations that it has 
something to do with real time files

On Wednesday, March 22, 2023 at 1:08:36 PM UTC+11 Peter Peter wrote:

> First question: Is this the correct place/forum/group for Weather34?
>
> if yes see next
>
> Ok all and thanks to Garry we seem to be collecting data via Weewx 
> including rain butits not showing up in the Weather34 skin. I have been 
> searching around in the weewx conf file etc and looked at various things 
> but cannot find an explanation for the seetings so maybe there is no issue 
> and the settings are just incorrect.
>
> the main thing I can see is 
> Weather34RealTime]
> realtime_path_only = ""
> unit_system = METRICWX
> exclude_fields = rain
> cache_enable = True
> cache_stale_time = 900
>
> So I was wondering if the exclude_fields = rain is my issue or the missing 
> paths?
>
> and somewhere else there was something to do with rain, mm 5 and I 
> wondered if that was a minimum amount to register or something?
>
>
> weewx_port = 25252
> webserver_address = ""
> weewxserver_address = ""
> weewx_file_transfer = ""
> HTML_ROOT = ""
>
>
>

-- 
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/800ab33e-8ddc-4f16-8ddc-c464b445de0cn%40googlegroups.com.

[weewx-user] Weather34 Skin and no rain

[Peter Peter]

First question: Is this the correct place/forum/group for Weather34?

if yes see next

Ok all and thanks to Garry we seem to be collecting data via Weewx 
including rain butits not showing up in the Weather34 skin. I have been 
searching around in the weewx conf file etc and looked at various things 
but cannot find an explanation for the seetings so maybe there is no issue 
and the settings are just incorrect.

the main thing I can see is 
Weather34RealTime]
realtime_path_only = ""
unit_system = METRICWX
exclude_fields = rain
cache_enable = True
cache_stale_time = 900

So I was wondering if the exclude_fields = rain is my issue or the missing 
paths?

and somewhere else there was something to do with rain, mm 5 and I wondered 
if that was a minimum amount to register or something?


weewx_port = 25252
webserver_address = ""
weewxserver_address = ""
weewx_file_transfer = ""
HTML_ROOT = ""


-- 
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/73857eea-26ce-4b00-9d8a-6ca2c79db630n%40googlegroups.com.

[weewx-user] Re: Weewx not picking up rain from ecowitt

[Peter Peter]

Thanks Gary. I was trying to beat you back here but alas I didnt. I did a 
search on the gw2000 and found some posts and like you suggested here ran 
Weewx directly and can see both the rain in the loop and rec so that parts 
seems ok. I will do a bit more research and see what I can find. I have 
been trying the Weather34 skin/web stuff and thats how I noticed it and 
then went and looked at other stuff. It gives me something to tinker with

On Wednesday, March 22, 2023 at 11:47:10 AM UTC+11 gjr80 wrote:

> On Wednesday, 22 March 2023 at 10:05:31 UTC+10 sale...@gmail.com wrote:
>
> Hey all.
>
> I have been running Weewx together with my Ecowitt and using the GW1000 
> setup. My base unit is actually a GW2000C_V2.2.3C
>
> When I initially set it up I ran it in simulator mode and all seemed ok
>
> I have been waiting for rain and we have some today but it appears Weewx 
> isnt picking up the rain info. The last update of the rain data in relation 
> the the graphics was over a week ago and thats when I changed from 
> Simulator to real. At that stage I deleted the database and let it start.
>
>  
> What sensor is connected to your GW2000 and reporting rain? I'm guessing 
> it is a WS90? The GW2000 (and other Ecowitt gateway devices) simultaneously 
> support traditional tipping type rain gauges (eg WH40) as well as piezo 
> based WS90. A default install of the Ecowitt Gateway driver will map 
> tipping rain gauge data through to WeeWX. If using a piezo based sensor (eg 
> WS90) then the piezo rain data is passed through to WeeWX, but it must be 
> manually mapped to suitable WeeWX fields. If you do indeed have a WS90 (and 
> no other rain gauge) try adding a [[field_map_extensions]] stanza to 
> [GW1000] in weewx.conf as follows:
>
> [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 
>  
> Stop WeeWX if it is running and try running WeeWX directly 
> , you should see 
> rainfall data appearing in the usual WeeWX rain fields. If you do indeed 
> see rainfall data then stop WeeWX and restart it as a daemon.
>
> If you don't have a WS90 or have multiple rain gauges then some additional 
> changes will be required. If this is the case, or the above does not work, 
> post back here.
>  
>
> The only thing I notice in the debug syslog entry that may be related is 
> DEBUG user.gw1000: Unknown field address '7B' detected. Remaining data 
> '00' ignored.
>
>  
> You can safely ignore this; the GW2000 firmware includes an additional 
> field that was not identified in the Ecowitt Gateway API documentation on 
> which the v0.5.0b5 Ecwoitt Gateway driver is based. Consequently v0.5.0b5 
> ignores, but debug logs, the unknown field. Ecowitt has since documented 
> this unknown field as indicating whether or not radiation compensation is 
> applied when reporting outside temperature for WH65/WH69/WS80/WS90 devices.
>  
> 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/23385a05-3e9e-41cd-a6dd-34fd8012db78n%40googlegroups.com.

[weewx-user] Weewx not picking up rain from ecowitt

[Peter Peter]

Hey all.

I have been running Weewx together with my Ecowitt and using the GW1000 
setup. My base unit is actually a GW2000C_V2.2.3C

When I initially set it up I ran it in simulator mode and all seemed ok

I have been waiting for rain and we have some today but it appears Weewx 
isnt picking up the rain info. The last update of the rain data in relation 
the the graphics was over a week ago and thats when I changed from 
Simulator to real. At that stage I deleted the database and let it start.

The only thing I notice in the debug syslog entry that may be related is 
DEBUG user.gw1000: Unknown field address '7B' detected. Remaining data '00' 
ignored.

What do I need to look for to figure this out?

-- 
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/dfb633ae-317e-43e1-8755-418ffcben%40googlegroups.com.

Re: [weewx-user] Is there a problem with the weewx-development group?

['Peter Fletcher' via weewx-user]

I reconstructed my original message and (re)submitted it to 
weewx-development via email, and it has appeared without problems. Hmmm.

On Saturday, March 11, 2023 at 1:56:16 PM UTC-5 vince wrote:

> FWIW, I had a couple messages eaten right away, most recently right before 
> my eyes after hitting send (Safari/MacOS).  Basically it accepted the post, 
> and then I saw I think 'message deleted' or the like briefly on the screen 
> in basically a fraction of a second.
>
> The last message had a small python patch in it for Tom, if that matters. 
>  I think the first message just asked a simple question.
>
> Might be worth posting a test message or two.
>
> On Saturday, March 11, 2023 at 7:17:56 AM UTC-8 Tom Keffer wrote:
>
>> It does seem to be behaving strangely --- you're not the only one who has 
>> had problems. However, there are no messages in quarantine, so I'm not sure 
>> what I can do.
>>
>> Were you posting from email, or directly to the weewx-development website?
>>
>> On Sat, Mar 11, 2023 at 5:59 AM 'Peter Fletcher' via weewx-user <
>> weewx...@googlegroups.com> wrote:
>>
>>> The last message in that group is from February 22, and I submitted two 
>>> messages to it a couple of days ago, which have not appeared. I was not a 
>>> member of that group until shortly before I submitted the first message, 
>>> but I would not have expected this long a moderation delay. 
>>>
>>> -- 
>>> 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/e8333f01-42a0-49e2-8ca2-d01ee64eaab3n%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/weewx-user/e8333f01-42a0-49e2-8ca2-d01ee64eaab3n%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/04e8d267-e94e-4f6d-8134-1fc1c374bec2n%40googlegroups.com.

[weewx-user] Is there a problem with the weewx-development group?

['Peter Fletcher' via weewx-user]

The last message in that group is from February 22, and I submitted two 
messages to it a couple of days ago, which have not appeared. I was not a 
member of that group until shortly before I submitted the first message, 
but I would not have expected this long a moderation delay.

-- 
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/e8333f01-42a0-49e2-8ca2-d01ee64eaab3n%40googlegroups.com.

[weewx-user] Re: Is there a way to augment loop packet with a data coming from database ?

['Peter Fletcher' via weewx-user]

I'm not 100% clear what you are trying to do here. I don't think that you 
can actually add data to the loop packet 'on the fly'. I am also not sure 
why you would want to do *anything* with tide height every loop. It is 
self-evidently a rather slow-changing datum, and could easily be dealt with 
at archive frequency. What you can certainly do is write a service that is 
triggered every time an archive packet is generated and processed which 
either gets data from somewhere (?MQTT) and saves it in the weewx database 
or gets data from the database and does something with it (or both).

On Sunday, February 12, 2023 at 2:27:58 AM UTC-5 eric9...@gmail.com wrote:

> Hi everybody:
>
> I have created a new data ("hauteur") in the database to graph the sea 
> tide. It works like a charm. See at http://chevrerie-du-cap.com/meteo/ at 
> the bottom.
>
> Now I would like to send the tide level observation with MQTT, then I need 
> it in the loop packet.
>
> So, is there a way to augment loop packet with a data coming from database 
> ?
>
> It tried to extend the field map of the GW1000 driver, but it doesn't work
>
> [[field_map_extensions]]
> hauteur = hauteur(data_binding=wx_binding)
> 
> 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/4d6ad33a-532d-496a-b0af-41baeb0938ebn%40googlegroups.com.

[weewx-user] Re: Is there a way to augment loop packet with a data coming from database ?

['Peter Fletcher' via weewx-user]

I'm not 100% clear what you are trying to do here. I don't think that you 
can actually add data to the loop packet 'on the fly'. What you can 
certainly do is write a service that is triggered every time a loop packet 
is received and processed which either gets data from somewhere (?MQTT) and 
saves it in the weewx database or gets data from the database and does 
something with it (or both).

On Sunday, February 12, 2023 at 2:27:58 AM UTC-5 eric9...@gmail.com wrote:

> Hi everybody:
>
> I have created a new data ("hauteur") in the database to graph the sea 
> tide. It works like a charm. See at http://chevrerie-du-cap.com/meteo/ at 
> the bottom.
>
> Now I would like to send the tide level observation with MQTT, then I need 
> it in the loop packet.
>
> So, is there a way to augment loop packet with a data coming from database 
> ?
>
> It tried to extend the field map of the GW1000 driver, but it doesn't work
>
> [[field_map_extensions]]
> hauteur = hauteur(data_binding=wx_binding)
> 
> 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/9cb9b926-43fb-4fe1-98d4-072501027ff9n%40googlegroups.com.

[weewx-user] Re: Weewx SFTP errors

['Peter Walker' via weewx-user]

No, I'm aware of that. Given that I've got the site working in a very 
non-purist way, I shall let if get on with it for the time being as I've 
got other things which are higher priority at the moment. When I come back 
to tackle it again, I shall certainly provide much more info.


On Wednesday, February 1, 2023 at 7:29:33 PM UTC vince wrote:

> In the absence of any logs or console transcripts we really can't help 
> you...
>
> On Wednesday, February 1, 2023 at 11:12:39 AM UTC-8 
> walke...@googlemail.com wrote:
>
>> I'm interested in this topic.
>>
>> I've tried and tried to get Weewx to write files to my server, firstly 
>> via FTP, with no success, (Ionos helpdesk said, after a few calls that FTP 
>> had been disabled on my server - it came back with an error 550 - but 
>> different guys said slightly conflicting things, but all agreed that FTP 
>> wasn't secure) and then using RSYNC. Again, I had no success by configuring 
>> weewx.conf - the error message was concerning the public and private keys 
>> (host key verification failed - rsync upload unexplained error (code 255).. 
>> I was trying as root, and I can SSH into the server without a password 
>> having set up the keys from the Raspberry Pi. I've done a botch to get 
>> round it by running rsync as a cron job at 01 and 31 past each hour and 
>> that works OK. "rsync -a /var/www/html/weewx/ 
>> ro...@nnn.nnn.nn.nnn:/var/www/.../weewx/". I would like to get to grips 
>> with this at some stage, but I've got other stuff which is higher priority 
>> now that the weather station is actually writing to the server. It's a 
>> retirement project so all for my own fun/edification.
>>
>> On Saturday, January 14, 2023 at 2:42:39 PM UTC axelle@gmail.com 
>> wrote:
>>
>>> As suggested, I used RSync instead of SFTP , and it works just fine :)
>>>
>>> On Thursday, January 12, 2023 at 10:36:16 PM UTC+1 Invisible Man wrote:
>>>
 A user suggests to use Rsync instead, as Rsync is running through SSH 
 for weewx. 
 see http://www.weewx.com/docs/usersguide.htm#config_RSYNC
 "*Fast, efficient, and secure, it does an incremental update, that is, 
 it only synchronizes those parts of a file that have changed, saving the 
 outgoing bandwidth of your Internet connection. *

 * If you wish to use rsync, you must configure passwordless ssh using 
 public/private key authentication from the user account that WeeWX runs, 
 to 
 the user account on the remote machine where the files will be copied.*
 "


 Indeed an option to try. I'll switch to that.

 On Tuesday, January 10, 2023 at 3:57:09 PM UTC+1 Invisible Man wrote:

> Hello, 
> I have recently enable sftp on Weewx, to upload the weewx web pages to 
> a remote site.
> Before that, I used ftp, and it worked no problem, but I'm have errors 
> with SFTP.
>
> - I'm using Weewx 4.9.1
> - Python 3.7.3
> - I can connect by hand to the remote sftp no problem
> - Not sure if I should be using passive or non passive for SFTP.
>
> ```
> Jan 10 15:52:16 vegan python3[7637]: weewx[7637] ERROR 
> weewx.reportengine: ftpgenerator: (2): caught exception ' 'socket.timeout'>': timed out
> Jan 10 15:52:16 vegan python3[7637]: weewx[7637] ERROR 
> weewx.reportengine:   Traceback (most recent call last):
> Jan 10 15:52:16 vegan python3[7637]: weewx[7637] ERROR 
> weewx.reportengine: File 
> "/usr/share/weewx/weewx/reportengine.py", line 437, in run
> Jan 10 15:52:16 vegan python3[7637]: weewx[7637] ERROR 
> weewx.reportengine:   n = ftp_data.run()
> Jan 10 15:52:16 vegan python3[7637]: weewx[7637] ERROR 
> weewx.reportengine: File 
> "/usr/share/weewx/weeutil/ftpupload.py", line 175, in run
> Jan 10 15:52:16 vegan python3[7637]: weewx[7637] ERROR 
> weewx.reportengine:   ftp_server.connect(self.server, 
> self.port)
> Jan 10 15:52:16 vegan python3[7637]: weewx[7637] ERROR 
> weewx.reportengine: File "/usr/lib/python3.7/ftplib.py", 
> line 155, in connect
> Jan 10 15:52:16 vegan python3[7637]: weewx[7637] ERROR 
> weewx.reportengine:   self.welcome = self.getresp()
> Jan 10 15:52:16 vegan python3[7637]: weewx[7637] ERROR 
> weewx.reportengine: File "/usr/lib/python3.7/ftplib.py", 
> line 236, in getresp
> Jan 10 15:52:16 vegan python3[7637]: weewx[7637] ERROR 
> weewx.reportengine:   resp = self.getmultiline()
> Jan 10 15:52:16 vegan python3[7637]: weewx[7637] ERROR 
> weewx.reportengine: File "/usr/lib/python3.7/ftplib.py", 
> line 226, in getmultiline
> Jan 10 15:52:16 vegan python3[7637]: weewx[7637] ERROR 
> weewx.reportengine:   nextline = self.getline()
> Jan 10 15:52:16 vegan python3[7637]: weewx[7637] ERROR 
> 

[weewx-user] Re: Weewx SFTP errors

['Peter Walker' via weewx-user]

I'm interested in this topic.

I've tried and tried to get Weewx to write files to my server, firstly via 
FTP, with no success, (Ionos helpdesk said, after a few calls that FTP had 
been disabled on my server - it came back with an error 550 - but different 
guys said slightly conflicting things, but all agreed that FTP wasn't 
secure) and then using RSYNC. Again, I had no success by configuring 
weewx.conf - the error message was concerning the public and private keys 
(host key verification failed - rsync upload unexplained error (code 255).. 
I was trying as root, and I can SSH into the server without a password 
having set up the keys from the Raspberry Pi. I've done a botch to get 
round it by running rsync as a cron job at 01 and 31 past each hour and 
that works OK. "rsync -a /var/www/html/weewx/ 
r...@nnn.nnn.nn.nnn:/var/www/.../weewx/". I would like to get to grips with 
this at some stage, but I've got other stuff which is higher priority now 
that the weather station is actually writing to the server. It's a 
retirement project so all for my own fun/edification.

On Saturday, January 14, 2023 at 2:42:39 PM UTC axelle@gmail.com wrote:

> As suggested, I used RSync instead of SFTP , and it works just fine :)
>
> On Thursday, January 12, 2023 at 10:36:16 PM UTC+1 Invisible Man wrote:
>
>> A user suggests to use Rsync instead, as Rsync is running through SSH for 
>> weewx. 
>> see http://www.weewx.com/docs/usersguide.htm#config_RSYNC
>> "*Fast, efficient, and secure, it does an incremental update, that is, 
>> it only synchronizes those parts of a file that have changed, saving the 
>> outgoing bandwidth of your Internet connection. *
>>
>> * If you wish to use rsync, you must configure passwordless ssh using 
>> public/private key authentication from the user account that WeeWX runs, to 
>> the user account on the remote machine where the files will be copied.*"
>>
>>
>> Indeed an option to try. I'll switch to that.
>>
>> On Tuesday, January 10, 2023 at 3:57:09 PM UTC+1 Invisible Man wrote:
>>
>>> Hello, 
>>> I have recently enable sftp on Weewx, to upload the weewx web pages to a 
>>> remote site.
>>> Before that, I used ftp, and it worked no problem, but I'm have errors 
>>> with SFTP.
>>>
>>> - I'm using Weewx 4.9.1
>>> - Python 3.7.3
>>> - I can connect by hand to the remote sftp no problem
>>> - Not sure if I should be using passive or non passive for SFTP.
>>>
>>> ```
>>> Jan 10 15:52:16 vegan python3[7637]: weewx[7637] ERROR 
>>> weewx.reportengine: ftpgenerator: (2): caught exception '>> 'socket.timeout'>': timed out
>>> Jan 10 15:52:16 vegan python3[7637]: weewx[7637] ERROR 
>>> weewx.reportengine:   Traceback (most recent call last):
>>> Jan 10 15:52:16 vegan python3[7637]: weewx[7637] ERROR 
>>> weewx.reportengine: File 
>>> "/usr/share/weewx/weewx/reportengine.py", line 437, in run
>>> Jan 10 15:52:16 vegan python3[7637]: weewx[7637] ERROR 
>>> weewx.reportengine:   n = ftp_data.run()
>>> Jan 10 15:52:16 vegan python3[7637]: weewx[7637] ERROR 
>>> weewx.reportengine: File 
>>> "/usr/share/weewx/weeutil/ftpupload.py", line 175, in run
>>> Jan 10 15:52:16 vegan python3[7637]: weewx[7637] ERROR 
>>> weewx.reportengine:   ftp_server.connect(self.server, 
>>> self.port)
>>> Jan 10 15:52:16 vegan python3[7637]: weewx[7637] ERROR 
>>> weewx.reportengine: File "/usr/lib/python3.7/ftplib.py", 
>>> line 155, in connect
>>> Jan 10 15:52:16 vegan python3[7637]: weewx[7637] ERROR 
>>> weewx.reportengine:   self.welcome = self.getresp()
>>> Jan 10 15:52:16 vegan python3[7637]: weewx[7637] ERROR 
>>> weewx.reportengine: File "/usr/lib/python3.7/ftplib.py", 
>>> line 236, in getresp
>>> Jan 10 15:52:16 vegan python3[7637]: weewx[7637] ERROR 
>>> weewx.reportengine:   resp = self.getmultiline()
>>> Jan 10 15:52:16 vegan python3[7637]: weewx[7637] ERROR 
>>> weewx.reportengine: File "/usr/lib/python3.7/ftplib.py", 
>>> line 226, in getmultiline
>>> Jan 10 15:52:16 vegan python3[7637]: weewx[7637] ERROR 
>>> weewx.reportengine:   nextline = self.getline()
>>> Jan 10 15:52:16 vegan python3[7637]: weewx[7637] ERROR 
>>> weewx.reportengine: File "/usr/lib/python3.7/ftplib.py", 
>>> line 204, in getline
>>> Jan 10 15:52:16 vegan python3[7637]: weewx[7637] ERROR 
>>> weewx.reportengine:   line = 
>>> self.file.readline(self.maxline + 1)
>>> Jan 10 15:52:16 vegan python3[7637]: weewx[7637] ERROR 
>>> weewx.reportengine: File "/usr/lib/python3.7/socket.py", 
>>> line 589, in readinto
>>> Jan 10 15:52:16 vegan python3[7637]: weewx[7637] ERROR 
>>> weewx.reportengine:   return self._sock.recv_into(b)
>>> Jan 10 15:52:16 vegan python3[7637]: weewx[7637] ERROR 
>>> weewx.reportengine:   socket.timeout: timed out
>>> ```
>>>
>>> this is my weewx.conf file:
>>>
>>> ```

Re: [weewx-user] Where is the formatting code for dates in the Seasons skin?

['Peter Fletcher' via weewx-user]

Thanks! You obviously replied to my original message before I deleted it, 
when I discovered that my Pi thought that it was living in the United 
Kingdom! Correcting that (I have no idea how/when it got changed, since I 
am sure I set the locale correctly when I installed Bullseye) sorted the 
problem.

On Tuesday, December 20, 2022 at 6:48:54 PM UTC-5 tke...@gmail.com wrote:

> This is set by the environment variable LANG. Double check your's.
>
> echo $LANG
>
> If you're in the US, it should read something like "en_US.UTF-8".
>
> On Tue, Dec 20, 2022 at 2:48 PM 'Peter Fletcher' via weewx-user <
> weewx...@googlegroups.com> wrote:
>
>> I have, for some years, used the Seasons skin as a base for two of the 
>> skins I employ for my weewx setup. I have just noticed that the date part 
>> of the datestamp at the top left of the main page is in (what I think of 
>> as) British format - DD/MM/. I am sure that it has always been that way 
>> and I have 'looked through it'. Since I am located on the other side of the 
>> pond, I would prefer to display it in US format (MM/DD/). Is there an 
>> easy way of doing this within the skin code? 
>>
>> -- 
>> 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/d9e43ac1-61ba-42be-8bf8-07770988159dn%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/weewx-user/d9e43ac1-61ba-42be-8bf8-07770988159dn%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/f3233f07-0dba-420e-b7c4-be3658116f4dn%40googlegroups.com.

[weewx-user] Where is the formatting code for dates in the Seasons skin?

['Peter Fletcher' via weewx-user]

I have, for some years, used the Seasons skin as a base for two of the 
skins I employ for my weewx setup. I have just noticed that the date part 
of the datestamp at the top left of the main page is in (what I think of 
as) British format - DD/MM/. I am sure that it has always been that way 
and I have 'looked through it'. Since I am located on the other side of the 
pond, I would prefer to display it in US format (MM/DD/). Is there an 
easy way of doing this within the skin code?

-- 
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/d9e43ac1-61ba-42be-8bf8-07770988159dn%40googlegroups.com.

[weewx-user] Re: Missing rainRate data

[Peter Cooper-Davis]

Hi Gary,

Thanks for the quick response. Your answer makes complete sense, but 
unfortunately it doesn't seem to work. Even after I have set the rainRate 
fields to NULL,  wee_database --calc-missing just seems to refill the 
rainRate with 0.0.

I've checked that I have definitely set the rain rate fields to NULL using 
the command you suggested above:

> SELECT dateTime,datetime(dateTime, 'unixepoch','localtime'),rain,rainRate 
FROM archive WHERE dateTime>=1661385600;
1661405100|2022-08-25 06:25:00|0.016904|
1661405400|2022-08-25 06:30:00|0.065687|
1661405700|2022-08-25 06:35:00|0.037562|
1661406000|2022-08-25 06:40:00|0.185201|
1661406300|2022-08-25 06:45:00|0.178290|
1661406600|2022-08-25 06:50:00|0.038078|
1661406900|2022-08-25 06:55:00|0.075650|
1661407200|2022-08-25 07:00:00|0.376993|
1661407500|2022-08-25 07:05:00|1.389899|
1661407800|2022-08-25 07:10:00|1.569504|
1661408100|2022-08-25 07:15:00|1.018610|

But after running wee_database --calc-missing --from=2022-08-25 the 
database looks like this

> SELECT dateTime,datetime(dateTime, 'unixepoch','localtime'),rain,rainRate 
FROM archive WHERE dateTime>=1661385600;
1661405100|2022-08-25 06:25:00|0.016904|0.0
1661405400|2022-08-25 06:30:00|0.065687|0.0
1661405700|2022-08-25 06:35:00|0.037562|0.0
1661406000|2022-08-25 06:40:00|0.185201|0.0
1661406300|2022-08-25 06:45:00|0.178290|0.0
1661406600|2022-08-25 06:50:00|0.038078|0.0
1661406900|2022-08-25 06:55:00|0.075650|0.0
1661407200|2022-08-25 07:00:00|0.376993|0.0
1661407500|2022-08-25 07:05:00|1.389899|0.0
1661407800|2022-08-25 07:10:00|1.569504|0.0
1661408100|2022-08-25 07:15:00|1.018610|0.0

Is there something obvious I am missing?

Pete

On Friday, 26 August 2022 at 03:40:09 UTC+1 gjr80 wrote:

> wee_database --calc-missing will only populate missing derived obs 
> provided (1) the missing derived obs field contains no data and (2) the 
> pre-requisites for the calculation exist. In your case you are failing on 
> the first test - your rainRate fields contain the value 0. You can try 
> setting the rainRate field to null in each affected record. Assuming you 
> are using a SQLite database this is most reliably done using the sqlite3 
> utility. To do this:
>
> 1. using something like Epoch Converter  
> to determine the epoch timestamp for the first and last archive records in 
> the block of records you wish to update, let's refer to these values as 
> start_timestamp and end_timestamp
>
> 2. install the sqlite3 utility if not already installed:
> $ sudo apt install sqlite3
>
> 3. stop WeeWX and make a backup of your WeeWX database, unless you have 
> changed it this will be /home/weewx/archive/weewx.sdb or 
> /var/lib/weewx/weewx.sdb depending on your WeeWX install type 
>
> 4. set the rainRate field for the records concerned to null:
> $ sqlite3 /home/weewx/archive/weewx.sdb
> > UPDATE archive SET rainRate=NULL WHERE dateTime>=start_timestamp AND 
> dateTime<=end_timestamp;
>
> replacing start_timestamp and end_timestamp with the actual epoch 
> timestamps. You can check the data has been cleared with the following 
> query:
> > SELECT dateTime,datetime(dateTime, 
> 'unixepoch','localtime'),rain,rainRate FROM archive 
> WHERE dateTime>=start_timestamp AND dateTime<=end_timestamp;
>
> 5. once happy the rainRate values have been nulled exit sqlite3 with .q
>
> 6. run wee_database --calc-missing to calculate the missing rainRate 
> data, use the --date or --from and --to 
>  to limit the 
> span of records that wee_database will operate on.
>
> 7. check the if rainRate has been correctly calculated:
> $ sqlite3 /home/weewx/archive/weewx.sdb
> > SELECT dateTime,datetime(dateTime, 
> 'unixepoch','localtime'),rain,rainRate FROM archive 
> WHERE dateTime>=start_timestamp AND dateTime<=end_timestamp;
> > .q
>
> If you are using MySQL/MariaDB the approach is the same, but you would use 
> mysql in lieu of sqlite3.
>
> Gary
> On Friday, 26 August 2022 at 05:50:12 UTC+10 peted...@gmail.com wrote:
>
>> I recently (25/08/2022) had to delete a 6 hour section of data from my 
>> database as the rain accumulation data contained in the LOOP packets from 
>> that period were incorrect. I refilled the database using the correct rain 
>> accumulation data from ARCHIVE packets over that 6 hours, and everything 
>> (in terms of the daily summaries etc.) now looks good. The only issue I 
>> have though is that there is no rainRate data in my database. Looking at a 
>> selection of records I can see rain accumulation, but no rainRate:
>>
>> dateTime|rain  |rainRate
>> 2022-08-25 06:15:00|1.018610|0.0
>> 2022-08-25 06:20:00|0.978673|0.0
>> 2022-08-25 06:25:00|1.367165|0.0
>> 2022-08-25 06:30:00|1.710911|0.0
>> 2022-08-25 06:35:00|1.588113|0.0
>> 2022-08-25 06:40:00|1.858461|0.0
>> 2022-08-25 06:45:00|1.654587|0.0
>> 2022-08-25 06:50:00|1.475450|0.0
>> 2022-08-25 

[weewx-user] Missing rainRate data

[Peter Cooper-Davis]

I recently (25/08/2022) had to delete a 6 hour section of data from my 
database as the rain accumulation data contained in the LOOP packets from 
that period were incorrect. I refilled the database using the correct rain 
accumulation data from ARCHIVE packets over that 6 hours, and everything 
(in terms of the daily summaries etc.) now looks good. The only issue I 
have though is that there is no rainRate data in my database. Looking at a 
selection of records I can see rain accumulation, but no rainRate:

dateTime|rain  |rainRate
2022-08-25 06:15:00|1.018610|0.0
2022-08-25 06:20:00|0.978673|0.0
2022-08-25 06:25:00|1.367165|0.0
2022-08-25 06:30:00|1.710911|0.0
2022-08-25 06:35:00|1.588113|0.0
2022-08-25 06:40:00|1.858461|0.0
2022-08-25 06:45:00|1.654587|0.0
2022-08-25 06:50:00|1.475450|0.0
2022-08-25 06:55:00|1.498110|0.0

I have tried using wee_database --calc-missing as I assumed rainRate was a 
derived value, but this doesn't seem to have made any difference. Can 
anyone advise how to fill the missing rainRate fields?

-- 
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/9f468d7b-f667-4658-bbfa-8242a85a11den%40googlegroups.com.

Re: [weewx-user] Off topic

['Peter Fletcher' via weewx-user]

It sounds as if your weewx/solar Pi installation was one or (probably) two 
versions behind the current ('Bullseye') version of the Pi's Debian-based 
OS. While it may be possible to upgrade the OS 'around' the existing 
installed programs, it would take a lot more Linux knowledge than I am 
guessing you have, and would not be guaranteed to work - either in the 
short or in the long term. The right solution (in addition to implementing 
a better backup strategy, going forward!) is almost certainly to be to 
install the latest version of the OS on a new SD Card, reinstall weewx and 
your solar monitoring program, and migrate your data.
weewx is easy! All the data is stored in its database - presumably 
weewx.sdb, in your case.
The solar monitoring program is obviously the issue. I assume that you 
didn't write it yourself, or you would know where it stores its data. Where 
did you get it? How did you originally install it? Was/is there no 
documentation? I assume that you know what it is called - I would try doing 
a Google search for '[program name] data location', and/or '[program name] 
migrate data'. In any event, unless this produces an easy answer, your best 
bet for knowledgeable further help is likely to be The Raspberry PI User 
forums .

On Tuesday, August 23, 2022 at 6:16:36 AM UTC-4 Greg Troxel wrote:

>
> Alastair L  writes:
>
> > Apologies in advance for this off topic question, but I'm sure someone 
> out 
> > there has had a similar issue and solved it. 
>
> It is but many struggle with RPIs.
>
> My advice is
>
> 0) Ask this in RPI-land instead.
> 1) first image the card you have, saving it
> 2) figure out and implement a backup strategy for your data
> 3) get another card, and do an install
> 4) mount it someplace and look at the files in the boot partition and
> see which is different from the card that was in the machine that
> broke. It is possible that your old system hasn't gotten the new
> packages.
> 5) think about using other small computers that are less pesky than the
> RPI. I like the PC engines apu2 series, but last I checked they too
> were having supply chain issues.
>

-- 
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/d786142a-02bb-4049-bc28-be113cf9291en%40googlegroups.com.

Re: [weewx-user] Sunshine Database

['Peter Fletcher' via weewx-user]

I have never explicitly used the schema management system, but my 
understanding is that it is only relevant if you want to create a whole new 
blank database using wee_database --create or --reconfigure. You don't 
appear to need it if you use other wee_database options to (e.g.) add, 
drop, or rename columns.
On Monday, July 18, 2022 at 10:35:03 AM UTC-4 jterr...@gmail.com wrote:

> @Peter : if one want to update the database using wee_database, the new 
> updated schema with the new field is needed.  Otherwise, in case of a 
> manual update of the database structure, the new schema is not needed.
>
> Le 18 juil. 2022 à 16:29, 'Peter Fletcher' via weewx-user <
> weewx...@googlegroups.com> a écrit :
>
> @Jacques: I initially had the same error (or a very similar one) as Jon B 
> and had to comment out that last line. I had already manually added the 
> sunshine_time field (as well as some others, previously) to my weewx 
> database, so it didn't seem to be necessary or useful. My installation also 
> did not seem to understand the schema assignment. Do you have a non-default 
> extension loaded that enables this?
>
>
> You received this message because you are subscribed to a topic in the 
> Google Groups "weewx-user" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/weewx-user/19ylVTRqbh4/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> weewx-user+...@googlegroups.com.
>
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/a85805b1-dfe9-41de-9079-56f4a951546bn%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/weewx-user/a85805b1-dfe9-41de-9079-56f4a951546bn%40googlegroups.com?utm_medium=email_source=footer>
> .
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/1a4d0ef0-60d3-403c-b15c-bef5f78deda3n%40googlegroups.com.

[weewx-user] Re: Missing sqlite database in directory

['Peter Fletcher' via weewx-user]

FWIW, weewx does work fine with a Vantage Pro 2 and a Meteo-Pi under 
bullseye.

On Thursday, July 7, 2022 at 10:43:40 AM UTC-4 taroka...@gmail.com wrote:

> Thank you Peter and Vince,
>
> An update: We got it to work!
>
> I did three things differently: 
> 1) since I am using the meteo-pi
>
> I edited the: */boot/config.txt* and add on the end
>
> *“enable_uart=1”*
>
> edit */boot/cmdline.txt* and remove
> *“console=serial0,115200”*
>
> This made dev/tty/S0 show up. 
>
> 2) Instead of using the installation on DEM based systems, I used the 
> python 3 setup.py method. This placed the weewx directory in the home 
> directory which may have had something to do with the issues I was running 
> into initially. 
>
> 3) Last thing I did was I switched from using bullseye 11 to Buster 10- 
> not sure if this really did anything but on the weewx installation guide 
> Buster was the last program that was mentioned.
>
> Cheers guys and thanks for the help. 
>
>
> Taro
>
>
> On Thursday, June 30, 2022 at 12:32:41 PM UTC-7 vince wrote:
>
>> The linux os won't create the /dev device(s) until something is connected 
>> to the pi, which the 'dmesg' command can tell you.  A quick search of the 
>> weewx archives says that it might matter which wire that came with the 
>> meteo pi hat - see (this thread) 
>> <https://groups.google.com/g/weewx-user/c/FZm_8mSvars> near the bottom 
>> of the thread.   Which wire did you use to connect the Meteo Pi to the 
>> zeroW ?
>>
>> Also since you're a new user, I'll mention that you should definitely 
>> read the FAQ for how to report a problem and how to debug your setup.  I 
>> posted a pointer to the FAQ yesterday.
>>
>> When you get it working, please follow up with what you did so the next 
>> person can get there a little easier based on you blazing the trail !
>>
>

-- 
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/9b78dd01-8e79-4142-9fe3-f7dde3f7c3e5n%40googlegroups.com.

Re: [weewx-user] Sunshine Database

['Peter Fletcher' via weewx-user]

@Jacques: I initially had the same error (or a very similar one) as Jon B 
and had to comment out that last line. I had already manually added the 
sunshine_time field (as well as some others, previously) to my weewx 
database, so it didn't seem to be necessary or useful. My installation also 
did not seem to understand the schema assignment. Do you have a non-default 
extension loaded that enables this?

On Monday, July 18, 2022 at 9:59:20 AM UTC-4 jterr...@gmail.com wrote:

> Hi,
>
> Please verify that the last line of the sunduration.py script is
>
>   schema_with_sunshine_time = schemas.wview.schema + [('sunshine_time', 
> 'REAL')]
>
>
> Le 18 juil. 2022 à 15:43, Jon B  a écrit :
>
> Sorry for piggybacking on this conversation, but it seemed like an 
> appropriate place to ask this.
>
> I'm trying to install the sunshine duration extension (
> https://github.com/Jterrettaz/sunduration) but I'm getting an error when 
> trying to create the new database. I've followed the installation 
> instructions as follows:
>
> - Saved sunduration.py to /usr/share/weewx/user/
> - Added user.sunduration.SunshineDuration to the process_services list
> - Changed the wx_binding schema to user.sunduration.
> schema_with_sunshine_time
> - Stopped weewx and ran wee_database weewx.conf --reconfigure 
>
> This gives the following error:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *Using configuration file weewx.confUsing database binding 'wx_binding', 
> which is bound to database 'archive_sqlite'Traceback (most recent call 
> last):  File "/usr/share/weewx/weeutil/weeutil.py", line 1155, in 
> get_objectmod = getattr(mod, part)AttributeError: module 
> 'user.sunduration' has no attribute 'schema_with_sunshine_time'During 
> handling of the above exception, another exception occurred:Traceback (most 
> recent call last):  File "/usr/share/weewx/wee_database", line 1170, in 
> main()  File "/usr/share/weewx/wee_database", line 216, in 
> mainreconfigMainDatabase(config_dict, db_binding)  File 
> "/usr/share/weewx/wee_database", line 439, in reconfigMainDatabase
> manager_dict = weewx.manager.get_manager_dict_from_config(config_dict,  
> File "/usr/share/weewx/weewx/manager.py", line 727, in 
> get_manager_dict_from_configmanager_dict['schema'] = 
> weeutil.weeutil.get_object(schema_name)  File 
> "/usr/share/weewx/weeutil/weeutil.py", line 1158, in get_objectraise 
> AttributeError(AttributeError: Module 'user.sunduration' has no attribute 
> 'schema_with_sunshine_time' when searching for 
> 'user.sunduration.schema_with_sunshine_time' *
>
> -- 
> You received this message because you are subscribed to a topic in the 
> Google Groups "weewx-user" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/weewx-user/19ylVTRqbh4/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> weewx-user+...@googlegroups.com.
>
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/e50560aa-d030-4096-97b4-7b9b614dc4cdn%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/a85805b1-dfe9-41de-9079-56f4a951546bn%40googlegroups.com.

Re: [weewx-user] Sunshine Database

['Peter Fletcher' via weewx-user]

My apparently ignoring the situations you highlight was a decision, rather 
than an omission! I run weewx on my 'workhorse' Pi, which is (at least by 
intention) up 24/7/365. I do reboot it occasionally after updates, but 
otherwise there should be no interruptions. The way I do the calculations 
for the archive values automatically corrects for 'short' archive 
intervals, and I would handle longer interruptions (if there were any) by 
running my update code on the database after the interruption.

On Saturday, July 16, 2022 at 11:34:07 AM UTC-4 jterr...@gmail.com wrote:

> Peter,
>
> Don't forget the fact that if for any reason Weewx is stopped, it will, 
> during restart, read from the datalogger memory any "missed" archive 
> packets that were not captured during the interruption period.  In that 
> case, no loop data are available for these archive records, and you have to 
> add code in your  newArchiveRecord() function to calculate, over the 
> archive interval, the sunshine duration on the basis of the archive 
> radiation value. Otherwise, the sunshine duration of these imported records 
> will be always 0!
>
> Even if Weewx interruption is short enough so that there is no missed 
> records to import from the datalogger memory, the LOOP packets received 
> after startup will not cover the full period of  the first archive record 
> captured , and sunshine duration calculated from the LOOP data will be 
> underestimated. In my code, I detect also this situation and the sunshine 
> duration of the first captured archive record  will be also calculated from 
> the archive radiation value over the archive interval.
>
>
> Le 16 juil. 2022 à 17:01, 'Peter Fletcher' via weewx-user <
> weewx...@googlegroups.com> a écrit :
>
> The code I am using is pasted below. The main threshold calculation is a 
> copy of the original Meto-France code used by Jacques, but the calculation 
> is only done when the radiation value changes or (approximately) every 
> minute, if it has not changed. Also included is code to store Davis’s 
> ‘Storm Rain’ value in the archive database. The stored value for sunshine 
> time has more apparent precision than is given by Jacques's code, but it is 
> probably neither more nor less accurate, since its accuracy is limited by 
> the relatively slow 'response' of the Davis sensor.
>
> -- 
> You received this message because you are subscribed to a topic in the 
> Google Groups "weewx-user" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/weewx-user/19ylVTRqbh4/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> weewx-user+...@googlegroups.com.
>
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/e11727db-7c89-4334-b24c-a5b2f7ca66dbn%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/weewx-user/e11727db-7c89-4334-b24c-a5b2f7ca66dbn%40googlegroups.com?utm_medium=email_source=footer>
> .
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/44c4e18c-4e64-4238-8ab9-35a46184bd73n%40googlegroups.com.

Re: [weewx-user] Sunshine Database

['Peter Fletcher' via weewx-user]

:05:15 Wetter weewx[3755]:  
>  self.service_obj.append(weeutil.weeutil._get_object(svc)(self, 
> config_dict))
> Jul 16 17:05:15 Wetter weewx[3755]: File 
> "/usr/share/weewx/weeutil/weeutil.py", line 1116, in _get_object
> Jul 16 17:05:15 Wetter weewx[3755]:   "Module '%s' has no 
> attribute '%s' when searching for '%s'" % (mod.__name__, part, 
> module_class))
> Jul 16 17:05:15 Wetter weewx[3755]:   AttributeError: Module 
> 'user.radiationhours' has no attribute 'RadiationHours' when searching for 
> 'user.radiationhours.RadiationHours'
> Jul 16 17:05:15 Wetter weewx[3755]:   Exiting.
>
> Can you Help me?
>
> Many Thanks
> Peter Fletcher schrieb am Samstag, 16. Juli 2022 um 17:01:34 UTC+2:
>
>> The code I am using is pasted below. The main threshold calculation is a 
>> copy of the original Meto-France code used by Jacques, but the calculation 
>> is only done when the radiation value changes or (approximately) every 
>> minute, if it has not changed. Also included is code to store Davis’s 
>> ‘Storm Rain’ value in the archive database. The stored value for sunshine 
>> time has more apparent precision than is given by Jacques's code, but it is 
>> probably neither more nor less accurate, since its accuracy is limited by 
>> the relatively slow 'response' of the Davis sensor.import syslog
>> from math import sin,cos,pi,asin
>>
>>
>> from datetime import datetime
>> import time
>>
>> import weewx
>> from weewx.wxengine import StdService
>>
>> import weewx.units
>> weewx.units.obs_group_dict['sunshine_time'] = 'group_sunshine'
>> weewx.units.USUnits['group_sunshine'] = 'minute'
>> weewx.units.MetricUnits['group_sunshine'] = 'minute'
>> weewx.units.MetricWXUnits['group_sunshine'] = 'minute'
>> weewx.units.default_unit_format_dict['minute'] = '%.0f'
>> weewx.units.default_unit_label_dict['minute'] = 'min'
>>
>> weewx.units.obs_group_dict['stormRain'] = 'group_rain'
>>
>> packet_count = 0
>> avg_radiation = 0
>> last_radiation = 0
>> last_calc_time = 0
>> cum_sunshine = 0
>> cum_time = 0
>> last_stormRain = 0
>>
>> class LoopSunshineDuration(StdService):
>> def __init__(self, engine, config_dict):
>> super(LoopSunshineDuration, self).__init__(engine, config_dict)
>> self.bind(weewx.NEW_LOOP_PACKET,self.newLoopRecord)
>>
>> def newLoopRecord(self, event):
>> global packet_count, last_radiation, cum_sunshine, cum_time, 
>> last_calc_time, last_stormRain
>> # The VP 2 radiation value normally only changes ~ every 50 
>> seconds (or multiple thereof)
>> pkt_radiation = event.packet.get('radiation')
>> last_stormRain = event.packet.get('stormRain')
>> if (pkt_radiation is None) or (pkt_radiation<=0):
>> pass
>> elif (packet_count < 29) and (pkt_radiation == last_radiation): 
>> packet_count += 1
>> else:
>> radiation = last_radiation
>> last_radiation = pkt_radiation
>> packet_count = 0
>> timestamp = event.packet.get('dateTime')
>> # Process the last value
>> duration = timestamp - last_calc_time
>> last_calc_time = timestamp
>> seuil = 0
>> coeff = 0.9
>> if radiation > 0:
>> utcdate = 
>> datetime.utcfromtimestamp(event.packet.get('dateTime'))
>> dayofyear = 
>> int(time.strftime("%j",time.gmtime(event.packet.get('dateTime'
>>
>>
>> theta = 360 * dayofyear / 365
>> equatemps = 0.0172 + 0.4281 * cos((pi / 180) * theta) - 
>> 7.3515 * sin(
>> (pi / 180) * theta) - 3.3495 * cos(2 * (pi / 180) * 
>> theta) - 9.3619 * sin(
>> 2 * (pi / 180) * theta)
>>
>> latitude= float(self.config_dict["Station"]["latitude"])
>> longitude = 
>> float(self.config_dict["Station"]["longitude"])
>>
>>
>> corrtemps = longitude * 4
>> declinaison = asin(0.006918 - 0.399912 * cos((pi / 180) * 
>> theta) + 0.070257 * sin(
>> (pi / 180) * theta) - 0.006758 * cos(2 * (pi / 180) * 
>> theta) + 0.000908 * sin(
>> 2 * (pi / 180) * theta)) * (180 / pi)
>>
>> minutesjour = utcdate.hour*60 + 

Re: [weewx-user] Sunshine Database

['Peter Fletcher' via weewx-user]

y 16, 2022 at 6:18:05 AM UTC-4 Meteo Oberwallis wrote:

> Hello, everyone.
> I eagerly await your experiences. It's very interesting what you can do. 
> Now I wanted to ask you if there is already a finished code that you can 
> use? Did I understand correctly that with these calculations you can 
> measure the hours of sunshine by minutes and not just by the interval of 
> the data logger?
> Can you use it to fill up past values? So e.g. from the year 2019 or 
> something?
>
> Best regards
> Stefan
>
> Peter Fletcher schrieb am Freitag, 1. Juli 2022 um 19:37:54 UTC+2:
>
>> I'm sure you are right about the triggering circumstances. The code in my 
>> weewx User routines was correct (using the Meteo France limit), but I had 
>> put in some modifications around the hauteur_soleil test in connection with 
>> the method I am using to average and 'normalize' the observations for the 
>> archive reports. I suspect that, in taking out those modifications for the 
>> archive update code, I inadvertently also removed the original test.
>>
>> On Friday, July 1, 2022 at 10:47:43 AM UTC-4 jterr...@gmail.com wrote:
>>
>>> OK. 
>>> The variable "hauteur_soleil is the elevation of the sun, in degree.
>>> From sunset to sunrise, this value will be negative (i.e. sun below the 
>>> horizon).  
>>> The formula developed by Metro France was validated to be effective only 
>>> if sun elevation is > 3°.
>>>
>>> In my own implantation of this algorithm, I decided to start the 
>>> calculation of the sun threshold as soon as the sun elevation was > 0° 
>>> *and* that the global radiation as measured by the Davis pyranometer 
>>> was greeter than 20 W/m2.
>>>
>>> I suspect that the few dateTime that trigger your  errors were in a 
>>> situation in which sun elevation was just below zero and that the measured 
>>> radiation was just higher than 20 W/m2
>>>
>>> Le 1 juil. 2022 à 16:19, 'Peter Fletcher' via weewx-user <
>>> weewx...@googlegroups.com> a écrit :
>>>
>>> Something like that is obviously needed. I don't know how my copy of the 
>>> code omitted the test for hauteur_soleil being > 0. There are a number of 
>>> sources from which I may have copied it, and I didn't keep links to all of 
>>> them, but I can't imagine why I would have deleted the test if my source 
>>> had included it. I will obviously add it to my working code.
>>>
>>> On Friday, July 1, 2022 at 2:45:42 AM UTC-4 jterr...@gmail.com wrote:
>>>
>>>> OK.  What I don't understand is that my code had always a test 
>>>>
>>>> if hauteur_soleil > 3:  (according to Météo France)
>>>>
>>>> or more recently
>>>>
>>>>  if hauteur_soleil > 0: 
>>>>
>>>> in the function, and this test is not on your function.
>>>>
>>>> It should be :
>>>>
>>>>  hauteur_soleil = asin(sin((pi / 180) * latitude) * sin((pi / 180) * 
>>>> declinaison) + cos(
>>>> (pi / 180) * latitude) * cos((pi / 180) * declinaison) * 
>>>> cos((pi / 180) * angle_horaire)) * (180 / pi)
>>>>  If hauteur_soleil > 0:
>>>>
>>>>   seuil = (0.73 + 0.06 * cos((pi / 180) * 360 * dayofyear / 365)) * 
>>>> 1080 * pow(
>>>>  (sin(pi / 180) * hauteur_soleil), 1.25) * coeff
>>>>   else :
>>>> seuil = 0
>>>>  return seuil
>>>>
>>>> Le 30 juin 2022 à 22:52, 'Peter Fletcher' via weewx-user <
>>>> weewx...@googlegroups.com> a écrit :
>>>>
>>>> That was going to be my next step! In fact, iterating through a list of 
>>>> the dateTime values that produce the errors in the real code and passing 
>>>> each value to the function confirms that it is the specific dateTime 
>>>> values 
>>>> that are causing the function to misbehave. The returned results are all 
>>>> complex numbers with negative and numerically identical (for a given 
>>>> dateTime) real and imaginary components. It does seem to be a bug in the 
>>>> function. I assume that hauteur_soleil should always be >=0. It appears 
>>>> that, for my latitude and longitude and for the given specific values of 
>>>> dateTime, it becomes negative. The last step in the calculation then 
>>>> involves raising a negative number to a non-integral power, which is 
>>>> guaranteed to produce interesting results! The really odd 

Re: [weewx-user] is PCE-FWS 20N a re-badged fine offset device?

[Peter Wilkinson]

a) <200 GBP
b) sorry, yes, sloppy of me. Not really raw.
I am replacing a system built from very old fine offset spare parts (now
seized up) . I interpret the wind speed and rain pulses and wind direction
ohmic resistance in a raspberry pi. Direct from the sensors.
Temp, pressure, humidity and solar intensity all handled with i2c chips.
These can all stay.
Hoping for slightly less raw than that!
c) only said USB because I thought that was only way of accessing data
locally (ie without round-tripping to external service) WiFi would be fine
d) need stream of readings to populate (existing) database. (existing)
Analysis and website then query that database
e) can handle other sensors myself. Only really need wind and rainfall. See
b) above.
f) no console needed
g) raspberry 2 and 3 (have several - long story...)
h) no position on this

BTW Good level of programming skills - Go, C, C++ as well as Linux and
networking

And thanks again for your help
 Peter





On Wed, 13 Jul 2022, 8:36 am Rainer Lang,  wrote:

> Now, this depends on various factors:
> a) what does "modestly priced" mean for you ? (price range - upper limit)
> b) what do you mean exactly by "raw data" - what is it supposed to look
> like ?
> c) is USB a must or just "having used so far" ? could it also be WiFi or
> LAN (via a WiFi router/access point) ?
> d) what's your use case/scenario ?
> e) any plans for extension/expansion (e.g. wanting to use more, different
> sensors) ?
> f) do you need a display console or is viewing live data on a smartphone
> or old tablet enough/acceptable ?
> g) what's your "processing infrastructure" ? e.g. a RaspberryPi (models 3
> or 4B)
> h) do you want a more "integrated" solution (outdoor sensor array) or a
> more distributed solution (separate sensors and locations) ?
>
> Depending on the answers to these questions, a +/- tailored
> proposal/suggestion could be made based on FineOffset/Ecowitt weather
> station/sensor combinations and maybe some additional tools like weewx and
> even some more
>
>
> There are many (more) modern Fine Offset / Ecowitt (clone) solutions
> available, which can also be nicely handled by weewx.
>
> If you want to know what can be combined (console with sensors) in the
> FineOffset/Ecowitt ecosystem, have a look at
> https://www.wxforum.net/index.php?topic=40730.0 (free of charge
> registration required to see pictures)
>
> P.S. if you don't want to go public with the answers to a) thru h), reply
> to my mail address only
>
>
> On 13.07.2022 09:05, Peter Wilkinson wrote:
>
> Thanks for full and helpful information.
>
> Sounds ideal, actually. I need USB connection for further processing
> locally and I can handle upload to e.g. Met office Wow myself.
>
> Hard to find a modestly priced system that supports local output of mor
> e-or-less raw data. Recommendations for alternative, more modern, setups
> that permit this would be welcome.
>
> Peter
>
> On Wed, 13 Jul 2022, 07:37 Rainer Lang,  wrote:
>
>> This looks like a clone of the old Fine Offset WH1080 weather station
>> which is no longer sold by Ecowitt due to old technology.
>> Console connectivity is USB only, no WiFi, no connection to the weather
>> networks. No solar sensor either. (a solar panel for running the outdoor
>> array, yes).
>> The outdoor array is likely to be not compatible to the modern WiFi
>> consoles and gateways like GW1000/GW1100/GW2000 due to using a different
>> modulation for the sensor signal transmission. This is also true vice versa
>> - the WH1080 console cannot receive any of the modern FineOffset/Ecowitt
>> sensors.
>>
>> On 12.07.2022 18:57, Peter Wilkinson wrote:
>>
>> Certainly looks like it might be but would appreciate confirmation.
>>
>> Full skinny here:
>>
>>
>> https://www.pce-instruments.com/english/index.htm?id=google-uk&_artnr=5933243&_p=159.6&_pmode=0&_pbexkey=37&_date=20220711011313&_pbhash=3d8b84805bd95306b3a50a774dd67505122ac3489016cd2c6f36fdfad65bdb14=CjwKCAjwt7SWBhAnEiwAx8ZLatQOmma6jcmlAcX4VrmK6PGwtHcBqai4WNgA6a3U6YK5dAVj_OUZZBoCo5IQAvD_BwE
>> --
>> 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/fa97e9d4-7f56-4b64-8f81-59ab915b0519n%40googlegroups.com
>> <https://groups.google.com/d/msgid/weewx-user/fa97e9d4-7f56-4b64-8f81-59ab915b0519n%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>>

Re: [weewx-user] is PCE-FWS 20N a re-badged fine offset device?

[Peter Wilkinson]

Thanks for full and helpful information.

Sounds ideal, actually. I need USB connection for further processing
locally and I can handle upload to e.g. Met office Wow myself.

Hard to find a modestly priced system that supports local output of
more-or-less raw data. Recommendations for alternative, more modern, setups
that permit this would be welcome.

Peter

On Wed, 13 Jul 2022, 07:37 Rainer Lang,  wrote:

> This looks like a clone of the old Fine Offset WH1080 weather station
> which is no longer sold by Ecowitt due to old technology.
> Console connectivity is USB only, no WiFi, no connection to the weather
> networks. No solar sensor either. (a solar panel for running the outdoor
> array, yes).
> The outdoor array is likely to be not compatible to the modern WiFi
> consoles and gateways like GW1000/GW1100/GW2000 due to using a different
> modulation for the sensor signal transmission. This is also true vice versa
> - the WH1080 console cannot receive any of the modern FineOffset/Ecowitt
> sensors.
>
> On 12.07.2022 18:57, Peter Wilkinson wrote:
>
> Certainly looks like it might be but would appreciate confirmation.
>
> Full skinny here:
>
>
> https://www.pce-instruments.com/english/index.htm?id=google-uk&_artnr=5933243&_p=159.6&_pmode=0&_pbexkey=37&_date=20220711011313&_pbhash=3d8b84805bd95306b3a50a774dd67505122ac3489016cd2c6f36fdfad65bdb14=CjwKCAjwt7SWBhAnEiwAx8ZLatQOmma6jcmlAcX4VrmK6PGwtHcBqai4WNgA6a3U6YK5dAVj_OUZZBoCo5IQAvD_BwE
> --
> 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/fa97e9d4-7f56-4b64-8f81-59ab915b0519n%40googlegroups.com
> <https://groups.google.com/d/msgid/weewx-user/fa97e9d4-7f56-4b64-8f81-59ab915b0519n%40googlegroups.com?utm_medium=email_source=footer>
> .
>
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "weewx-user" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/weewx-user/Vpqj61ff-SI/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> weewx-user+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-user/b8403e7e-4d20-5d6d-6498-e06ac4d1c350%40gmail.com
> <https://groups.google.com/d/msgid/weewx-user/b8403e7e-4d20-5d6d-6498-e06ac4d1c350%40gmail.com?utm_medium=email_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/CADMzL2%2BRdeb6ON-%3DuxniFpe7y7vq8WYtkeZWknHvsUYh0Ny2uw%40mail.gmail.com.

[weewx-user] is PCE-FWS 20N a re-badged fine offset device?

[Peter Wilkinson]

Certainly looks like it might be but would appreciate confirmation.

Full skinny here:

https://www.pce-instruments.com/english/index.htm?id=google-uk&_artnr=5933243&_p=159.6&_pmode=0&_pbexkey=37&_date=20220711011313&_pbhash=3d8b84805bd95306b3a50a774dd67505122ac3489016cd2c6f36fdfad65bdb14=CjwKCAjwt7SWBhAnEiwAx8ZLatQOmma6jcmlAcX4VrmK6PGwtHcBqai4WNgA6a3U6YK5dAVj_OUZZBoCo5IQAvD_BwE

-- 
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/fa97e9d4-7f56-4b64-8f81-59ab915b0519n%40googlegroups.com.

Re: [weewx-user] Generating longer-term reports on added data

['Peter Fletcher' via weewx-user]

No, I didn't, though I *thought* that I checked that the relevant generated 
images had times corresponding to when I ran wee_reports. I'm not, in any 
event, concerned about the NOAA reports, and I knew that they don't 
automatically get updated. In any event, deleting all the image files 
before rerunning wee_reports seems to have fixed not only the display 
problem but also filled in the missing data in the relevant daily summary 
table - which I certainly didn't expect. Thanks!

On Saturday, July 2, 2022 at 6:34:33 PM UTC-4 tke...@gmail.com wrote:

> Older plots and NOAA records are not automatically regenerated. Did you 
> delete everything before running wee_reports?
>
> On Sat, Jul 2, 2022 at 2:46 PM 'Peter Fletcher' via weewx-user <
> weewx...@googlegroups.com> wrote:
>
>> I have recently added a 'Sunshine minutes/hours' field to weewx's 
>> database - calculated on the fly from measured solar radiation. Since I 
>> have radiation records going back a couple of years, I wanted to backfill 
>> the sunshine time records to display on longer term reports. After a couple 
>> of glitches (my fault), I was able to update the Archive records, and I 
>> have checked that they appear correct. I also used wee_database to drop and 
>> recreate the daily summary tables. I still don't see any data displayed for 
>> dates earlier than the last 30 days. I have checked that non-zero sunshine 
>> archive records exist, going back to the beginning of the database, but the 
>> time fields (except for dateTime) are null and the numeric fields are blank 
>> in the daily summary table for all dates before the last 30 days. Any 
>> suggestions?
>>
>> -- 
>> 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/1ac1036b-e209-4432-9d23-ad1430778ec9n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/weewx-user/1ac1036b-e209-4432-9d23-ad1430778ec9n%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/cb3d5343-eb0d-4bde-938b-20afebf39739n%40googlegroups.com.

[weewx-user] Re: Apt update source for weewx.

['Peter Fletcher' via weewx-user]

Thanks!

On Saturday, July 2, 2022 at 5:38:23 PM UTC-4 matthew wall wrote:

> On Saturday, July 2, 2022 at 4:14:37 PM UTC-4 Peter Fletcher wrote:
>
>> The installation instructions add 'http://weewx.com/apt/python3 *buster* 
>> InRelease' to apt's list of sources for Debian installs, and this works.
>>
>
> you can replace 'buster' with whatever you want.
>
> we do not track specific debian (or ubuntu, or mint, or whatever) 
> releases.  basically we target two debian releases: squeeze (for python2) 
> and buster (for python3).
>
> the weewx python2 deb package first worked with debian 6 (squeeze), and 
> works with every subsequent debian release until the python2 packages are 
> no longer provided.
>
> the weewx python3 deb package first worked with debian 10 (buster) and 
> will continue to work with every subsequent debian release until debian 
> breaks the python3 packages.
>
> 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/3468ed94-3839-457f-96fb-03546443ad76n%40googlegroups.com.

[weewx-user] Generating longer-term reports on added data

['Peter Fletcher' via weewx-user]

I have recently added a 'Sunshine minutes/hours' field to weewx's database 
- calculated on the fly from measured solar radiation. Since I have 
radiation records going back a couple of years, I wanted to backfill the 
sunshine time records to display on longer term reports. After a couple of 
glitches (my fault), I was able to update the Archive records, and I have 
checked that they appear correct. I also used wee_database to drop and 
recreate the daily summary tables. I still don't see any data displayed for 
dates earlier than the last 30 days. I have checked that non-zero sunshine 
archive records exist, going back to the beginning of the database, but the 
time fields (except for dateTime) are null and the numeric fields are blank 
in the daily summary table for all dates before the last 30 days. Any 
suggestions?

-- 
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/1ac1036b-e209-4432-9d23-ad1430778ec9n%40googlegroups.com.

[weewx-user] Apt update source for weewx.

['Peter Fletcher' via weewx-user]

The installation instructions add 'http://weewx.com/apt/python3 *buster* 
InRelease' to apt's list of sources for Debian installs, and this works. 
However, Debian and Raspbian have been up to bullseye for long enough that 
I have recently upgraded my main Pi (!) and weewx appears to run perfectly 
happily under bullseye. Has the old repository specification been retained 
to avoid confusion and because weewx is equally happy under the two recent 
versions of Debian, or does the wget installation source need to be updated?

-- 
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/cd2c6ce4-78cc-4987-a6f4-a0df21e2176an%40googlegroups.com.

Re: [weewx-user] Sunshine Database

['Peter Fletcher' via weewx-user]

I'm sure you are right about the triggering circumstances. The code in my 
weewx User routines was correct (using the Meteo France limit), but I had 
put in some modifications around the hauteur_soleil test in connection with 
the method I am using to average and 'normalize' the observations for the 
archive reports. I suspect that, in taking out those modifications for the 
archive update code, I inadvertently also removed the original test.

On Friday, July 1, 2022 at 10:47:43 AM UTC-4 jterr...@gmail.com wrote:

> OK. 
> The variable "hauteur_soleil is the elevation of the sun, in degree.
> From sunset to sunrise, this value will be negative (i.e. sun below the 
> horizon).  
> The formula developed by Metro France was validated to be effective only 
> if sun elevation is > 3°.
>
> In my own implantation of this algorithm, I decided to start the 
> calculation of the sun threshold as soon as the sun elevation was > 0° 
> *and* that the global radiation as measured by the Davis pyranometer was 
> greeter than 20 W/m2.
>
> I suspect that the few dateTime that trigger your  errors were in a 
> situation in which sun elevation was just below zero and that the measured 
> radiation was just higher than 20 W/m2
>
> Le 1 juil. 2022 à 16:19, 'Peter Fletcher' via weewx-user <
> weewx...@googlegroups.com> a écrit :
>
> Something like that is obviously needed. I don't know how my copy of the 
> code omitted the test for hauteur_soleil being > 0. There are a number of 
> sources from which I may have copied it, and I didn't keep links to all of 
> them, but I can't imagine why I would have deleted the test if my source 
> had included it. I will obviously add it to my working code.
>
> On Friday, July 1, 2022 at 2:45:42 AM UTC-4 jterr...@gmail.com wrote:
>
>> OK.  What I don't understand is that my code had always a test 
>>
>> if hauteur_soleil > 3:  (according to Météo France)
>>
>> or more recently
>>
>>  if hauteur_soleil > 0: 
>>
>> in the function, and this test is not on your function.
>>
>> It should be :
>>
>>  hauteur_soleil = asin(sin((pi / 180) * latitude) * sin((pi / 180) * 
>> declinaison) + cos(
>> (pi / 180) * latitude) * cos((pi / 180) * declinaison) * cos((pi 
>> / 180) * angle_horaire)) * (180 / pi)
>>  If hauteur_soleil > 0:
>>
>>   seuil = (0.73 + 0.06 * cos((pi / 180) * 360 * dayofyear / 365)) * 1080 
>> * pow(
>>  (sin(pi / 180) * hauteur_soleil), 1.25) * coeff
>>   else :
>> seuil = 0
>>  return seuil
>>
>> Le 30 juin 2022 à 22:52, 'Peter Fletcher' via weewx-user <
>> weewx...@googlegroups.com> a écrit :
>>
>> That was going to be my next step! In fact, iterating through a list of 
>> the dateTime values that produce the errors in the real code and passing 
>> each value to the function confirms that it is the specific dateTime values 
>> that are causing the function to misbehave. The returned results are all 
>> complex numbers with negative and numerically identical (for a given 
>> dateTime) real and imaginary components. It does seem to be a bug in the 
>> function. I assume that hauteur_soleil should always be >=0. It appears 
>> that, for my latitude and longitude and for the given specific values of 
>> dateTime, it becomes negative. The last step in the calculation then 
>> involves raising a negative number to a non-integral power, which is 
>> guaranteed to produce interesting results! The really odd thing is that 
>> math.pow is not returning a ValueError, which the docs say is what should 
>> happen under these circumstances, but apparently trying to return a 
>> (possibly) valid complex result.
>> On Thursday, June 30, 2022 at 3:07:38 PM UTC-4 jterr...@gmail.com wrote:
>>
>>> The only clue I have is that the problem is not due to an 
>>> « overloading » of your raspberry pi, but seems to occur with specific 
>>> dateTime values.
>>> You can try to run your script only with a « bad » dateTime :
>>>
>>> "SELECT dateTime, Radiation from archive where dateTime = 1592614500 »
>>>
>>> Does the error occurs ? If yes, you can try to add debugging print 
>>> commands inside the sunshineThreshold function to try to understand.
>>>
>>>
>>>
>>> Le 30 juin 2022 à 19:51, 'Peter Fletcher' via weewx-user >> googlegroups.com> a écrit :
>>>
>>> It did as it seems you predicted - passed 1592614800 and stopped at 
>>> 1632611100. You obviously have a clue as to what is going on. Please 
>>> explain!
>>>
>>> On Thursday, Jun

Re: [weewx-user] Sunshine Database

['Peter Fletcher' via weewx-user]

Something like that is obviously needed. I don't know how my copy of the 
code omitted the test for hauteur_soleil being > 0. There are a number of 
sources from which I may have copied it, and I didn't keep links to all of 
them, but I can't imagine why I would have deleted the test if my source 
had included it. I will obviously add it to my working code.

On Friday, July 1, 2022 at 2:45:42 AM UTC-4 jterr...@gmail.com wrote:

> OK.  What I don't understand is that my code had always a test 
>
> if hauteur_soleil > 3:  (according to Météo France)
>
> or more recently
>
>  if hauteur_soleil > 0: 
>
> in the function, and this test is not on your function.
>
> It should be :
>
>  hauteur_soleil = asin(sin((pi / 180) * latitude) * sin((pi / 180) * 
> declinaison) + cos(
> (pi / 180) * latitude) * cos((pi / 180) * declinaison) * cos((pi / 
> 180) * angle_horaire)) * (180 / pi)
>  If hauteur_soleil > 0:
>
>   seuil = (0.73 + 0.06 * cos((pi / 180) * 360 * dayofyear / 365)) * 1080 
> * pow(
>  (sin(pi / 180) * hauteur_soleil), 1.25) * coeff
>   else :
> seuil = 0
>  return seuil
>
> Le 30 juin 2022 à 22:52, 'Peter Fletcher' via weewx-user <
> weewx...@googlegroups.com> a écrit :
>
> That was going to be my next step! In fact, iterating through a list of 
> the dateTime values that produce the errors in the real code and passing 
> each value to the function confirms that it is the specific dateTime values 
> that are causing the function to misbehave. The returned results are all 
> complex numbers with negative and numerically identical (for a given 
> dateTime) real and imaginary components. It does seem to be a bug in the 
> function. I assume that hauteur_soleil should always be >=0. It appears 
> that, for my latitude and longitude and for the given specific values of 
> dateTime, it becomes negative. The last step in the calculation then 
> involves raising a negative number to a non-integral power, which is 
> guaranteed to produce interesting results! The really odd thing is that 
> math.pow is not returning a ValueError, which the docs say is what should 
> happen under these circumstances, but apparently trying to return a 
> (possibly) valid complex result.
> On Thursday, June 30, 2022 at 3:07:38 PM UTC-4 jterr...@gmail.com wrote:
>
>> The only clue I have is that the problem is not due to an « overloading » 
>> of your raspberry pi, but seems to occur with specific dateTime values.
>> You can try to run your script only with a « bad » dateTime :
>>
>> "SELECT dateTime, Radiation from archive where dateTime = 1592614500 »
>>
>> Does the error occurs ? If yes, you can try to add debugging print 
>> commands inside the sunshineThreshold function to try to understand.
>>
>>
>>
>> Le 30 juin 2022 à 19:51, 'Peter Fletcher' via weewx-user <
>> weewx...@googlegroups.com> a écrit :
>>
>> It did as it seems you predicted - passed 1592614800 and stopped at 
>> 1632611100. You obviously have a clue as to what is going on. Please 
>> explain!
>>
>> On Thursday, June 30, 2022 at 8:59:48 AM UTC-4 jterr...@gmail.com wrote:
>>
>>> If you exclude the first one,1592614500 , with a query like "SELECT 
>>> dateTime, Radiation from archive where dateTime <> 1592614500", will the 
>>> script stop at 1592614800 ( the next dateTime) or will it continue and stop 
>>> at 1632611100 ?
>>>
>>> Le 30 juin 2022 à 14:34, 'Peter Fletcher' via weewx-user <
>>> weewx...@googlegroups.com> a écrit :
>>>
>>> 1592614500
>>> 1632611100
>>> 1632611400
>>> 1647688800
>>>
>>> I can't see a pattern or any common features.
>>>
>>> On Thursday, June 30, 2022 at 3:55:49 AM UTC-4 jterr...@gmail.com wrote:
>>>
>>>> No, I never had weewx  crashes related to the sunshine calculations. 
>>>>
>>>> What are the dateTime values that trigger the error ?
>>>>
>>>>
>>>>
>>>> Le mercredi 29 juin 2022 à 23:23:16 UTC+2, Peter Fletcher a écrit :
>>>>
>>>>> Have you had any odd weewx errors or crashes related to the sunshine 
>>>>> calculations? I ask because I hadn't, but I decided to try to 'backfill' 
>>>>> my 
>>>>> database with sunshine times, based on the 5-minute radiation values, and 
>>>>> I 
>>>>> ran into a bizarre bug. I used the code shown below (on a copy of my live 
>>>>> weewx database). As you will see, the threshold calculation code is 
>>>>> essentially

Re: [weewx-user] Sunshine Database

['Peter Fletcher' via weewx-user]

That was going to be my next step! In fact, iterating through a list of the 
dateTime values that produce the errors in the real code and passing each 
value to the function confirms that it is the specific dateTime values that 
are causing the function to misbehave. The returned results are all complex 
numbers with negative and numerically identical (for a given dateTime) real 
and imaginary components. It does seem to be a bug in the function. I 
assume that hauteur_soleil should always be >=0. It appears that, for my 
latitude and longitude and for the given specific values of dateTime, it 
becomes negative. The last step in the calculation then involves raising a 
negative number to a non-integral power, which is guaranteed to produce 
interesting results! The really odd thing is that math.pow is not returning 
a ValueError, which the docs say is what should happen under these 
circumstances, but apparently trying to return a (possibly) valid complex 
result.
On Thursday, June 30, 2022 at 3:07:38 PM UTC-4 jterr...@gmail.com wrote:

> The only clue I have is that the problem is not due to an « overloading » 
> of your raspberry pi, but seems to occur with specific dateTime values.
> You can try to run your script only with a « bad » dateTime :
>
> "SELECT dateTime, Radiation from archive where dateTime = 1592614500 »
>
> Does the error occurs ? If yes, you can try to add debugging print 
> commands inside the sunshineThreshold function to try to understand.
>
>
>
> Le 30 juin 2022 à 19:51, 'Peter Fletcher' via weewx-user <
> weewx...@googlegroups.com> a écrit :
>
> It did as it seems you predicted - passed 1592614800 and stopped at 
> 1632611100. You obviously have a clue as to what is going on. Please 
> explain!
>
> On Thursday, June 30, 2022 at 8:59:48 AM UTC-4 jterr...@gmail.com wrote:
>
>> If you exclude the first one,1592614500 , with a query like "SELECT 
>> dateTime, Radiation from archive where dateTime <> 1592614500", will the 
>> script stop at 1592614800 ( the next dateTime) or will it continue and stop 
>> at 1632611100 ?
>>
>> Le 30 juin 2022 à 14:34, 'Peter Fletcher' via weewx-user <
>> weewx...@googlegroups.com> a écrit :
>>
>> 1592614500
>> 1632611100
>> 1632611400
>> 1647688800
>>
>> I can't see a pattern or any common features.
>>
>> On Thursday, June 30, 2022 at 3:55:49 AM UTC-4 jterr...@gmail.com wrote:
>>
>>> No, I never had weewx  crashes related to the sunshine calculations. 
>>>
>>> What are the dateTime values that trigger the error ?
>>>
>>>
>>>
>>> Le mercredi 29 juin 2022 à 23:23:16 UTC+2, Peter Fletcher a écrit :
>>>
>>>> Have you had any odd weewx errors or crashes related to the sunshine 
>>>> calculations? I ask because I hadn't, but I decided to try to 'backfill' 
>>>> my 
>>>> database with sunshine times, based on the 5-minute radiation values, and 
>>>> I 
>>>> ran into a bizarre bug. I used the code shown below (on a copy of my live 
>>>> weewx database). As you will see, the threshold calculation code is 
>>>> essentially identical to yours, except that it has been converted to a 
>>>> regular function (no 'self' parameter) and my station's latitude and 
>>>> longitude are hard coded in it. When the code is run under Python 3.9.2 on 
>>>> my Pi, it initially runs without problems, but crashes after 8,000+ 
>>>> records 
>>>> have been processed with a ValueError on the MaxThreshold vs threshold 
>>>> comparison, reporting that it can't compare a complex with a float! If I 
>>>> intercept and log the errors, it turns out that, for a few specific values 
>>>> of dateTime, the function returns a complex number! Even more bizarrely, 
>>>> it 
>>>> only seems to do that in the context of the running code. If I manually 
>>>> run 
>>>> through all the operations from the function code at the Python command 
>>>> line, using the value of dateTime that produces the first crash, all the 
>>>> intermediate results and the final result are sane floats.
>>>> There appears to be a second issue, possibly related to my reading and 
>>>> writing the database at relatively high frequency, which stalls the 
>>>> process 
>>>> after about 18,000 records have been processed, but removing the database 
>>>> writes allows it to run to completion without abolishing the consistent, 
>>>> albeit infrequent, ValueErrors.
>>>>
>>>> [backfill.py]
>>>> import sq

Re: [weewx-user] Sunshine Database

['Peter Fletcher' via weewx-user]

It did as it seems you predicted - passed 1592614800 and stopped at 
1632611100. You obviously have a clue as to what is going on. Please 
explain!

On Thursday, June 30, 2022 at 8:59:48 AM UTC-4 jterr...@gmail.com wrote:

> If you exclude the first one,1592614500 , with a query like "SELECT 
> dateTime, Radiation from archive where dateTime <> 1592614500", will the 
> script stop at 1592614800 ( the next dateTime) or will it continue and stop 
> at 1632611100 ?
>
> Le 30 juin 2022 à 14:34, 'Peter Fletcher' via weewx-user <
> weewx...@googlegroups.com> a écrit :
>
> 1592614500
> 1632611100
> 1632611400
> 1647688800
>
> I can't see a pattern or any common features.
>
> On Thursday, June 30, 2022 at 3:55:49 AM UTC-4 jterr...@gmail.com wrote:
>
>> No, I never had weewx  crashes related to the sunshine calculations. 
>>
>> What are the dateTime values that trigger the error ?
>>
>>
>>
>> Le mercredi 29 juin 2022 à 23:23:16 UTC+2, Peter Fletcher a écrit :
>>
>>> Have you had any odd weewx errors or crashes related to the sunshine 
>>> calculations? I ask because I hadn't, but I decided to try to 'backfill' my 
>>> database with sunshine times, based on the 5-minute radiation values, and I 
>>> ran into a bizarre bug. I used the code shown below (on a copy of my live 
>>> weewx database). As you will see, the threshold calculation code is 
>>> essentially identical to yours, except that it has been converted to a 
>>> regular function (no 'self' parameter) and my station's latitude and 
>>> longitude are hard coded in it. When the code is run under Python 3.9.2 on 
>>> my Pi, it initially runs without problems, but crashes after 8,000+ records 
>>> have been processed with a ValueError on the MaxThreshold vs threshold 
>>> comparison, reporting that it can't compare a complex with a float! If I 
>>> intercept and log the errors, it turns out that, for a few specific values 
>>> of dateTime, the function returns a complex number! Even more bizarrely, it 
>>> only seems to do that in the context of the running code. If I manually run 
>>> through all the operations from the function code at the Python command 
>>> line, using the value of dateTime that produces the first crash, all the 
>>> intermediate results and the final result are sane floats.
>>> There appears to be a second issue, possibly related to my reading and 
>>> writing the database at relatively high frequency, which stalls the process 
>>> after about 18,000 records have been processed, but removing the database 
>>> writes allows it to run to completion without abolishing the consistent, 
>>> albeit infrequent, ValueErrors.
>>>
>>> [backfill.py]
>>> import sqlite3
>>> from datetime import datetime
>>> import time
>>> from math import sin, cos, pi, asin
>>>
>>> def sunshineThreshold(mydatetime):
>>> coeff = 0.9  # change to calibrate with your sensor
>>> utcdate = datetime.utcfromtimestamp(mydatetime)
>>> dayofyear = int(time.strftime("%j", time.gmtime(mydatetime)))
>>> theta = 360 * dayofyear / 365
>>> equatemps = 0.0172 + 0.4281 * cos((pi / 180) * theta) - 7.3515 * 
>>> sin(
>>> (pi / 180) * theta) - 3.3495 * cos(2 * (pi / 180) * theta) - 
>>> 9.3619 * sin(
>>> 2 * (pi / 180) * theta)
>>>
>>> latitude = 43.0346213
>>> longitude = -78.689362
>>>
>>> corrtemps = longitude * 4
>>> declinaison = asin(0.006918 - 0.399912 * cos((pi / 180) * theta) + 
>>> 0.070257 * sin(
>>> (pi / 180) * theta) - 0.006758 * cos(2 * (pi / 180) * theta) + 
>>> 0.000908 * sin(
>>> 2 * (pi / 180) * theta)) * (180 / pi)
>>> minutesjour = utcdate.hour * 60 + utcdate.minute
>>> tempsolaire = (minutesjour + corrtemps + equatemps) / 60
>>> angle_horaire = (tempsolaire - 12) * 15
>>> hauteur_soleil = asin(sin((pi / 180) * latitude) * sin((pi / 180) * 
>>> declinaison) + cos(
>>> (pi / 180) * latitude) * cos((pi / 180) * declinaison) * 
>>> cos((pi / 180) * angle_horaire)) * (180 / pi)
>>> seuil = (0.73 + 0.06 * cos((pi / 180) * 360 * dayofyear / 365)) * 
>>> 1080 * pow(
>>> (sin(pi / 180) * hauteur_soleil), 1.25) * coeff
>>> return seuil
>>>
>>>
>>> database = 'weewx.sdb'
>>>
>>> maxThreshold=0
>>> count=0
>>> conn=sqlite3.connect(database)
>&

Re: [weewx-user] Sunshine Database

['Peter Fletcher' via weewx-user]

1592614500
1632611100
1632611400
1647688800

I can't see a pattern or any common features.

On Thursday, June 30, 2022 at 3:55:49 AM UTC-4 jterr...@gmail.com wrote:

> No, I never had weewx  crashes related to the sunshine calculations. 
>
> What are the dateTime values that trigger the error ?
>
>
>
> Le mercredi 29 juin 2022 à 23:23:16 UTC+2, Peter Fletcher a écrit :
>
>> Have you had any odd weewx errors or crashes related to the sunshine 
>> calculations? I ask because I hadn't, but I decided to try to 'backfill' my 
>> database with sunshine times, based on the 5-minute radiation values, and I 
>> ran into a bizarre bug. I used the code shown below (on a copy of my live 
>> weewx database). As you will see, the threshold calculation code is 
>> essentially identical to yours, except that it has been converted to a 
>> regular function (no 'self' parameter) and my station's latitude and 
>> longitude are hard coded in it. When the code is run under Python 3.9.2 on 
>> my Pi, it initially runs without problems, but crashes after 8,000+ records 
>> have been processed with a ValueError on the MaxThreshold vs threshold 
>> comparison, reporting that it can't compare a complex with a float! If I 
>> intercept and log the errors, it turns out that, for a few specific values 
>> of dateTime, the function returns a complex number! Even more bizarrely, it 
>> only seems to do that in the context of the running code. If I manually run 
>> through all the operations from the function code at the Python command 
>> line, using the value of dateTime that produces the first crash, all the 
>> intermediate results and the final result are sane floats.
>> There appears to be a second issue, possibly related to my reading and 
>> writing the database at relatively high frequency, which stalls the process 
>> after about 18,000 records have been processed, but removing the database 
>> writes allows it to run to completion without abolishing the consistent, 
>> albeit infrequent, ValueErrors.
>>
>> [backfill.py]
>> import sqlite3
>> from datetime import datetime
>> import time
>> from math import sin, cos, pi, asin
>>
>> def sunshineThreshold(mydatetime):
>> coeff = 0.9  # change to calibrate with your sensor
>> utcdate = datetime.utcfromtimestamp(mydatetime)
>> dayofyear = int(time.strftime("%j", time.gmtime(mydatetime)))
>> theta = 360 * dayofyear / 365
>> equatemps = 0.0172 + 0.4281 * cos((pi / 180) * theta) - 7.3515 * sin(
>> (pi / 180) * theta) - 3.3495 * cos(2 * (pi / 180) * theta) - 
>> 9.3619 * sin(
>> 2 * (pi / 180) * theta)
>>
>> latitude = 43.0346213
>> longitude = -78.689362
>>
>> corrtemps = longitude * 4
>> declinaison = asin(0.006918 - 0.399912 * cos((pi / 180) * theta) + 
>> 0.070257 * sin(
>> (pi / 180) * theta) - 0.006758 * cos(2 * (pi / 180) * theta) + 
>> 0.000908 * sin(
>> 2 * (pi / 180) * theta)) * (180 / pi)
>> minutesjour = utcdate.hour * 60 + utcdate.minute
>> tempsolaire = (minutesjour + corrtemps + equatemps) / 60
>> angle_horaire = (tempsolaire - 12) * 15
>> hauteur_soleil = asin(sin((pi / 180) * latitude) * sin((pi / 180) * 
>> declinaison) + cos(
>> (pi / 180) * latitude) * cos((pi / 180) * declinaison) * cos((pi 
>> / 180) * angle_horaire)) * (180 / pi)
>> seuil = (0.73 + 0.06 * cos((pi / 180) * 360 * dayofyear / 365)) * 
>> 1080 * pow(
>> (sin(pi / 180) * hauteur_soleil), 1.25) * coeff
>> return seuil
>>
>>
>> database = 'weewx.sdb'
>>
>> maxThreshold=0
>> count=0
>> conn=sqlite3.connect(database)
>> cur=conn.execute("SELECT dateTime, Radiation from archive")
>> for row in cur:
>> count += 1
>> if (row[1] is not None) and (row[1] > 20):
>> threshold = sunshineThreshold(row[0])
>> if threshold > maxThreshold:
>> maxThreshold = threshold
>> if row[1] > threshold:
>> conn.execute("UPDATE archive set SunshineTime = 5 WHERE dateTime 
>> = " + str(row[0]))
>> if count % 1000 == 0:
>> print(count, 'Max Threshold', maxThreshold)
>> conn.close
>> [/backfill.py] 
>>
>> On Friday, June 10, 2022 at 3:29:40 AM UTC-4 jterr...@gmail.com wrote:
>>
>>> On my side, I have looked at the CPU utilization on my raspberry Pi 3B+. 
>>> I have the mqtt  service service installed, so at each loop all data of the 
>>> packet are sent to the mqtt broker.
>>>
>>> Wi

Re: [weewx-user] Sunshine Database

['Peter Fletcher' via weewx-user]

Have you had any odd weewx errors or crashes related to the sunshine 
calculations? I ask because I hadn't, but I decided to try to 'backfill' my 
database with sunshine times, based on the 5-minute radiation values, and I 
ran into a bizarre bug. I used the code shown below (on a copy of my live 
weewx database). As you will see, the threshold calculation code is 
essentially identical to yours, except that it has been converted to a 
regular function (no 'self' parameter) and my station's latitude and 
longitude are hard coded in it. When the code is run under Python 3.9.2 on 
my Pi, it initially runs without problems, but crashes after 8,000+ records 
have been processed with a ValueError on the MaxThreshold vs threshold 
comparison, reporting that it can't compare a complex with a float! If I 
intercept and log the errors, it turns out that, for a few specific values 
of dateTime, the function returns a complex number! Even more bizarrely, it 
only seems to do that in the context of the running code. If I manually run 
through all the operations from the function code at the Python command 
line, using the value of dateTime that produces the first crash, all the 
intermediate results and the final result are sane floats.
There appears to be a second issue, possibly related to my reading and 
writing the database at relatively high frequency, which stalls the process 
after about 18,000 records have been processed, but removing the database 
writes allows it to run to completion without abolishing the consistent, 
albeit infrequent, ValueErrors.

[backfill.py]
import sqlite3
from datetime import datetime
import time
from math import sin, cos, pi, asin

def sunshineThreshold(mydatetime):
coeff = 0.9  # change to calibrate with your sensor
utcdate = datetime.utcfromtimestamp(mydatetime)
dayofyear = int(time.strftime("%j", time.gmtime(mydatetime)))
theta = 360 * dayofyear / 365
equatemps = 0.0172 + 0.4281 * cos((pi / 180) * theta) - 7.3515 * sin(
(pi / 180) * theta) - 3.3495 * cos(2 * (pi / 180) * theta) - 9.3619 
* sin(
2 * (pi / 180) * theta)

latitude = 43.0346213
longitude = -78.689362

corrtemps = longitude * 4
declinaison = asin(0.006918 - 0.399912 * cos((pi / 180) * theta) + 
0.070257 * sin(
(pi / 180) * theta) - 0.006758 * cos(2 * (pi / 180) * theta) + 
0.000908 * sin(
2 * (pi / 180) * theta)) * (180 / pi)
minutesjour = utcdate.hour * 60 + utcdate.minute
tempsolaire = (minutesjour + corrtemps + equatemps) / 60
angle_horaire = (tempsolaire - 12) * 15
hauteur_soleil = asin(sin((pi / 180) * latitude) * sin((pi / 180) * 
declinaison) + cos(
(pi / 180) * latitude) * cos((pi / 180) * declinaison) * cos((pi / 
180) * angle_horaire)) * (180 / pi)
seuil = (0.73 + 0.06 * cos((pi / 180) * 360 * dayofyear / 365)) * 1080 
* pow(
(sin(pi / 180) * hauteur_soleil), 1.25) * coeff
return seuil


database = 'weewx.sdb'

maxThreshold=0
count=0
conn=sqlite3.connect(database)
cur=conn.execute("SELECT dateTime, Radiation from archive")
for row in cur:
count += 1
if (row[1] is not None) and (row[1] > 20):
threshold = sunshineThreshold(row[0])
if threshold > maxThreshold:
maxThreshold = threshold
if row[1] > threshold:
conn.execute("UPDATE archive set SunshineTime = 5 WHERE dateTime = 
" + str(row[0]))
if count % 1000 == 0:
print(count, 'Max Threshold', maxThreshold)
conn.close
[/backfill.py] 

On Friday, June 10, 2022 at 3:29:40 AM UTC-4 jterr...@gmail.com wrote:

> On my side, I have looked at the CPU utilization on my raspberry Pi 3B+. I 
> have the mqtt  service service installed, so at each loop all data of the 
> packet are sent to the mqtt broker.
>
> With mqtt and when calculations of the sunshine threshold is done for each 
> loop packet, the total CPU utilization of python3 is about 0.75%
> With mqtt and without calculation of sunshine threshold : 0.5% of total 
> CPU.
>
> So one can estimate that 0.25 % of total CPU is needed for the calculation 
> of the threshold value for each LOOP packet.
>
>
> Le 9 juin 2022 à 22:26, 'Peter Fletcher' via weewx-user <
> weewx...@googlegroups.com> a écrit :
>
> After some experimentation, I found that the radiation value in the VP2 
> LOOP packets does, indeed, normally change every 50-52 seconds, but, 
> perhaps about a fifth of the 'gaps' are a *multiple* of that time - most 
> often 100+ or 150+ seconds, but occasionally more than that (I saw one 250+ 
> second 'gap'). I saw this under conditions of variable sunshine and clouds 
> when it seemed unlikely that the actual radiation value would have been 
> precisely constant for that length of time, so I am not sure exactly what 
> is going on. In any event, I am revising the code I am using on the basis 
> of doing the threshold calculation when the

Re: [weewx-user] Determine archive interval from within weewx

['Peter Fletcher' via weewx-user]

Thanks! I take it that the interval returned by the engine in this way is 
the same as that in the archive packet - i.e. the hardware interval, if it 
is longer that that specified in weewx.conf.

On Tuesday, June 14, 2022 at 3:19:48 PM UTC-4 tke...@gmail.com wrote:

> When you instantiate a service, one of the parameters is the engine 
> instance:
>
> def __init__(self, engine, config_dict):
>
> The archive interval used by the engine can be obtained from it as
>
> engine.console.archive_interval
>
> -tk
>
>
>
> On Fri, Jun 10, 2022 at 11:07 AM 'Peter Fletcher' via weewx-user <
> weewx...@googlegroups.com> wrote:
>
>> Yes. This is potentially even more of a problem if you only determine 
>> whether the sun is shining when the radiation value changes, which is what 
>> I now do (with a timeout to deal with the instances when the 'gap' is a 
>> multiple of 50+ seconds). I have addressed it slightly differently - I 
>> accumulate seconds of sunshine and the total seconds elapsed between 
>> computations in the LOOP code and use the *ratio* of these (for each 
>> archive interval) to determine sunshine time for that interval.
>>
>> On Friday, June 10, 2022 at 10:40:09 AM UTC-4 jterr...@gmail.com wrote:
>>
>>> The Davis VP2 archive are recorded in the datalogger at the exact 
>>> archive interval. 
>>> So even if for any reason a service bound to NEW_ARCHIVE_RECORD is 
>>> running a little bit later that the time the record was captured by the 
>>> VP2, the data will still be valid, and the "*event.record['interval'] " 
>>> *will be the interval between the two last recors received from the VP2.
>>>
>>> Concerning our context of doing sunshine duration measurements based  on 
>>> LOOP packets, these loop packets may be not always in phase with the 
>>> archive  at the time an archive record is processed by weewx for our service
>>> So for instance, I saw initially  with my archive interval of 5 min and 
>>> during  a period of full sunshine, that the sunshine duration derived from 
>>> loop packets during  an "archive" interval"  was a little bit higher that 5 
>>> min, or sometimes a little bit lower :
>>>
>>> 2022-06-06 11:30:19  weewx[4501] INFO user.sunduration: Sunshine 
>>> duration from loop packets = 5.016667 min, last radiation = 828.00, and 
>>> last threshold = 639.982068
>>>
>>> Given the context of "slow" update of solar radiation of the VP2 
>>> compared to the LOOP interval, I decided to round up the sunshine duration 
>>> to full minutes
>>>
>>> Le 10 juin 2022 à 15:52, 'Peter Fletcher' via weewx-user <
>>> weewx...@googlegroups.com> a écrit :
>>>
>>> Thanks to all! Granted that you are most likely to need to know the 
>>> archive interval in the context of an archive interrupt service, where it 
>>> is easily available and the returned value is reliable, it would be nice if 
>>> the actual working value (rather than just the value from weewx.conf) were 
>>> readily available in other contexts.
>>>
>>> On Friday, June 10, 2022 at 9:04:06 AM UTC-4 jterr...@gmail.com wrote:
>>>
>>>> "Using the interval field from the current archive record should always 
>>>> give the correct value.".
>>>>
>>>> I use it in my extension and it works very well: 
>>>> *event.record['interval'] *
>>>>
>>>> Le vendredi 10 juin 2022 à 05:04:45 UTC+2, gjr80 a écrit :
>>>>
>>>>> Whilst in almost all cases the archive interval used by WeeWX will 
>>>>> match the archive_interval config option in weewx.conf [StdArchive] this 
>>>>> is not always the case. Installs that use software record generation 
>>>>> always 
>>>>> use an archive interval that matches the archive_interval config 
>>>>> option; however, when using hardware record generation if the archive 
>>>>> interval set in the station hardware is different to the 
>>>>> archive_interval config option the archive_interval config option is 
>>>>> ignored and the station hardware archive interval is used instead. This 
>>>>> is 
>>>>> most commonly seen with Davis stations used with a default WeeWX install. 
>>>>> The Davis station uses an out-of-the-box 30 minute archive interval and 
>>>>> that value overrides the default WeeWX archive interval of five minutes.
>>>>>
>

Re: [weewx-user] Determine archive interval from within weewx

['Peter Fletcher' via weewx-user]

Yes. This is potentially even more of a problem if you only determine 
whether the sun is shining when the radiation value changes, which is what 
I now do (with a timeout to deal with the instances when the 'gap' is a 
multiple of 50+ seconds). I have addressed it slightly differently - I 
accumulate seconds of sunshine and the total seconds elapsed between 
computations in the LOOP code and use the *ratio* of these (for each 
archive interval) to determine sunshine time for that interval.

On Friday, June 10, 2022 at 10:40:09 AM UTC-4 jterr...@gmail.com wrote:

> The Davis VP2 archive are recorded in the datalogger at the exact archive 
> interval. 
> So even if for any reason a service bound to NEW_ARCHIVE_RECORD is running 
> a little bit later that the time the record was captured by the VP2, the 
> data will still be valid, and the "*event.record['interval'] " *will be 
> the interval between the two last recors received from the VP2.
>
> Concerning our context of doing sunshine duration measurements based  on 
> LOOP packets, these loop packets may be not always in phase with the 
> archive  at the time an archive record is processed by weewx for our service
> So for instance, I saw initially  with my archive interval of 5 min and 
> during  a period of full sunshine, that the sunshine duration derived from 
> loop packets during  an "archive" interval"  was a little bit higher that 5 
> min, or sometimes a little bit lower :
>
> 2022-06-06 11:30:19  weewx[4501] INFO user.sunduration: Sunshine duration 
> from loop packets = 5.016667 min, last radiation = 828.00, and last 
> threshold = 639.982068
>
> Given the context of "slow" update of solar radiation of the VP2 compared 
> to the LOOP interval, I decided to round up the sunshine duration to full 
> minutes
>
> Le 10 juin 2022 à 15:52, 'Peter Fletcher' via weewx-user <
> weewx...@googlegroups.com> a écrit :
>
> Thanks to all! Granted that you are most likely to need to know the 
> archive interval in the context of an archive interrupt service, where it 
> is easily available and the returned value is reliable, it would be nice if 
> the actual working value (rather than just the value from weewx.conf) were 
> readily available in other contexts.
>
> On Friday, June 10, 2022 at 9:04:06 AM UTC-4 jterr...@gmail.com wrote:
>
>> "Using the interval field from the current archive record should always 
>> give the correct value.".
>>
>> I use it in my extension and it works very well: 
>> *event.record['interval'] *
>>
>> Le vendredi 10 juin 2022 à 05:04:45 UTC+2, gjr80 a écrit :
>>
>>> Whilst in almost all cases the archive interval used by WeeWX will match 
>>> the archive_interval config option in weewx.conf [StdArchive] this is 
>>> not always the case. Installs that use software record generation always 
>>> use an archive interval that matches the archive_interval config 
>>> option; however, when using hardware record generation if the archive 
>>> interval set in the station hardware is different to the 
>>> archive_interval config option the archive_interval config option is 
>>> ignored and the station hardware archive interval is used instead. This is 
>>> most commonly seen with Davis stations used with a default WeeWX install. 
>>> The Davis station uses an out-of-the-box 30 minute archive interval and 
>>> that value overrides the default WeeWX archive interval of five minutes.
>>>
>>> Using the interval field from the current archive record should always 
>>> give the correct value.
>>>
>>> Gary
>>>
>>
> -- 
> You received this message because you are subscribed to a topic in the 
> Google Groups "weewx-user" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/weewx-user/W0jG1kElJ1k/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> weewx-user+...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/87e7270c-2cbf-4438-a60b-638be2005049n%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/weewx-user/87e7270c-2cbf-4438-a60b-638be2005049n%40googlegroups.com?utm_medium=email_source=footer>
> .
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/d030a216-4cfd-4df3-ad3c-55ae8df63cf8n%40googlegroups.com.

Re: [weewx-user] Determine archive interval from within weewx

['Peter Fletcher' via weewx-user]

Thanks to all! Granted that you are most likely to need to know the archive 
interval in the context of an archive interrupt service, where it is easily 
available and the returned value is reliable, it would be nice if the 
actual working value (rather than just the value from weewx.conf) were 
readily available in other contexts.

On Friday, June 10, 2022 at 9:04:06 AM UTC-4 jterr...@gmail.com wrote:

> "Using the interval field from the current archive record should always 
> give the correct value.".
>
> I use it in my extension and it works very well: 
> *event.record['interval'] *
>
> Le vendredi 10 juin 2022 à 05:04:45 UTC+2, gjr80 a écrit :
>
>> Whilst in almost all cases the archive interval used by WeeWX will match 
>> the archive_interval config option in weewx.conf [StdArchive] this is 
>> not always the case. Installs that use software record generation always 
>> use an archive interval that matches the archive_interval config option; 
>> however, when using hardware record generation if the archive interval set 
>> in the station hardware is different to the archive_interval config 
>> option the archive_interval config option is ignored and the station 
>> hardware archive interval is used instead. This is most commonly seen with 
>> Davis stations used with a default WeeWX install. The Davis station uses an 
>> out-of-the-box 30 minute archive interval and that value overrides the 
>> default WeeWX archive interval of five minutes.
>>
>> Using the interval field from the current archive record should always 
>> give the correct value.
>>
>> 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/87e7270c-2cbf-4438-a60b-638be2005049n%40googlegroups.com.

Re: [weewx-user] Determine archive interval from within weewx

['Peter Fletcher' via weewx-user]

I know what my current archive interval is (Davis's default of 5 minutes) 
and I don't have any plans to change it, but, in writing user 
services/extensions, which others may conceivably use in the future, I 
don't like to hard-code a value which may be different in a different 
setup. I am sure that the current value of the parameter is accessible to 
code running 'within' weewx (but not within an archive record handler), but 
I couldn't find how to access it.

On Thursday, June 9, 2022 at 4:55:36 PM UTC-4 lang@googlemail.com wrote:

> Not sure what you are exactly looking for,
> but you can see your current archive interval in the syslog (usually in 
> /var/log/syslog - just see two subsequent archiving log items) 
>
> or 
>
> in your weewx.conf (/etc/weewx/weewx.conf or /home/weewx/weewx.conf)
>
> [StdArchive]
>
> # If the station hardware supports data logging then the archive 
> interval
> # will be downloaded from the station. Otherwise, specify it (in 
> seconds).
> archive_interval = 300  #example
>
> Am 09.06.2022 um 21:40 schrieb 'Peter Fletcher' via weewx-user:
>
> This may seem like a very stupid question, but I have not been able to 
> google an answer. Is there a method or parameter that is accessible from 
> within (e.g.) a user extension which gives the current archive interval?
>
> -- 
> 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/7ac93a73-ba27-4599-b30b-ff20d26e6970n%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/weewx-user/7ac93a73-ba27-4599-b30b-ff20d26e6970n%40googlegroups.com?utm_medium=email_source=footer>
> .
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/52fcc7c6-c222-4dbc-8f2a-aa7443910c48n%40googlegroups.com.

[weewx-user] Re: Determine archive interval from within weewx

['Peter Fletcher' via weewx-user]

Approaching the search from a different angle, I have now found that, 
within an archive event handler (which is where I needed it), you can get 
it from the event record as ['interval'], but is there another and/or more 
general way?

On Thursday, June 9, 2022 at 3:40:03 PM UTC-4 Peter Fletcher wrote:

> This may seem like a very stupid question, but I have not been able to 
> google an answer. Is there a method or parameter that is accessible from 
> within (e.g.) a user extension which gives the current archive interval?
>

-- 
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/070e1c51-9778-4aee-8027-4324d7554d4bn%40googlegroups.com.

Re: [weewx-user] Sunshine Database

['Peter Fletcher' via weewx-user]

After some experimentation, I found that the radiation value in the VP2 
LOOP packets does, indeed, normally change every 50-52 seconds, but, 
perhaps about a fifth of the 'gaps' are a *multiple* of that time - most 
often 100+ or 150+ seconds, but occasionally more than that (I saw one 250+ 
second 'gap'). I saw this under conditions of variable sunshine and clouds 
when it seemed unlikely that the actual radiation value would have been 
precisely constant for that length of time, so I am not sure exactly what 
is going on. In any event, I am revising the code I am using on the basis 
of doing the threshold calculation when the radiation level changes, but at 
least every minute, if it remains constant for more than the normal 50-52 
seconds..

On Sunday, June 5, 2022 at 12:33:47 PM UTC-4 jterr...@gmail.com wrote:

> I think it is also OK to do an average for every 30 seconds.  It depends 
> also on the weather station used.
> For  instance, a Davis Vantage Pro 2 ISS transmits an updated  solar 
> radiation value every 50 to 60 seconds. So with this weather station, even 
> a 1 minute average would not be very different  since anyway the solar 
> radiation values of the LOOP packet are the same for at least 50 seconds.!
>
> Le 5 juin 2022 à 18:02, 'Peter Fletcher' via weewx-user <
> weewx...@googlegroups.com> a écrit :
>
> I chose to average the LOOP radiation readings and only to do the 
> threshold calculation and make the sun/no sun determination every 30 
> seconds because I thought doing it on every LOOP might overload LOOP 
> processing (I am running weewx on a Pi 3B, which is also doing a few other 
> things which use the CPU). If this is an unnecessary concern, as it may 
> very well be, your modified code is much cleaner than mine.
>
> On Saturday, June 4, 2022 at 12:41:08 PM UTC-4 jterr...@gmail.com wrote:
>
>> It is a very good idea to calculate the sunshine duration for each LOOP 
>> packet and sum these values to make the final archive sunshine duration.  I 
>> have modified my script accordingly :  
>> https://github.com/Jterrettaz/sunduration.
>> The logic is the following :  for each received LOOP packet, the 
>> radiation is compared to a calculated threshold. If the radiation is above 
>> the threshold value, the sunshine time for the LOOP packet is equal to the 
>> time elapsed between the  previous loop packet and this packet (most of the 
>> time 2 seconds with a Vantage Davis Pro).
>> The final archive sunshine duration is the sum of all the LOOP value 
>> within the archive period.
>> Le vendredi 3 juin 2022 à 21:59:36 UTC+2, Peter Fletcher a écrit :
>>
>>> That makes some sense when you are getting data from an 'external' 
>>> sensor, though there are (IMHO) simpler ways of doing it. weewx already has 
>>> access to the LOOP radiation data from the VP2, so handling the processing 
>>> and data storage within weewx makes more sense to me in this case.
>>>
>>> On Friday, June 3, 2022 at 3:24:23 PM UTC-4 vince wrote:
>>>
>>>> On Friday, June 3, 2022 at 11:17:00 AM UTC-7 Meteo Oberwallis wrote:
>>>>
>>>>>  if the interval of Weewx and the data logger is set to 10 minutes, I 
>>>>> would have liked to read the value of the solar sensor every minute and 
>>>>> then write it into a separate .sdb database as possible sunshine.
>>>>
>>>>
>>>> Personally I'd use an external program called via cron and posting a 
>>>> message to a MQTT topic.  Have weewx subscribe to that topic to get the 
>>>> data into your db.
>>>>
>>>> This is how I used to get my DS18b20 temperature sensor data into weewx.
>>>>
>>>>
> -- 
> You received this message because you are subscribed to a topic in the 
> Google Groups "weewx-user" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/weewx-user/19ylVTRqbh4/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> weewx-user+...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/0e631671-0a74-4963-9f1c-e5f81bc7c366n%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/weewx-user/0e631671-0a74-4963-9f1c-e5f81bc7c366n%40googlegroups.com?utm_medium=email_source=footer>
> .
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/f0ecc86f-a615-4a24-a43f-ee0d3963b8adn%40googlegroups.com.

[weewx-user] Determine archive interval from within weewx

['Peter Fletcher' via weewx-user]

This may seem like a very stupid question, but I have not been able to 
google an answer. Is there a method or parameter that is accessible from 
within (e.g.) a user extension which gives the current archive interval?

-- 
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/7ac93a73-ba27-4599-b30b-ff20d26e6970n%40googlegroups.com.

Re: [weewx-user] Sunshine Database

['Peter Fletcher' via weewx-user]

I am using a Vantage Pro 2, and I had forgotten (if I ever knew!) that the 
solar radiation value had a slower update rate than most other weather 
values, but it is certainly another reason not to worry about processing 
every LOOP value separately. You could even argue that (for this hardware) 
the LOOP code should accumulate time until the reported radiation value 
actually changes (or until an appropriately set  maximum time elapses) 
before processing the previous period's values.

On Sunday, June 5, 2022 at 12:33:47 PM UTC-4 jterr...@gmail.com wrote:

> I think it is also OK to do an average for every 30 seconds.  It depends 
> also on the weather station used.
> For  instance, a Davis Vantage Pro 2 ISS transmits an updated  solar 
> radiation value every 50 to 60 seconds. So with this weather station, even 
> a 1 minute average would not be very different  since anyway the solar 
> radiation values of the LOOP packet are the same for at least 50 seconds.!
>
> Le 5 juin 2022 à 18:02, 'Peter Fletcher' via weewx-user <
> weewx...@googlegroups.com> a écrit :
>
> I chose to average the LOOP radiation readings and only to do the 
> threshold calculation and make the sun/no sun determination every 30 
> seconds because I thought doing it on every LOOP might overload LOOP 
> processing (I am running weewx on a Pi 3B, which is also doing a few other 
> things which use the CPU). If this is an unnecessary concern, as it may 
> very well be, your modified code is much cleaner than mine.
>
> On Saturday, June 4, 2022 at 12:41:08 PM UTC-4 jterr...@gmail.com wrote:
>
>> It is a very good idea to calculate the sunshine duration for each LOOP 
>> packet and sum these values to make the final archive sunshine duration.  I 
>> have modified my script accordingly :  
>> https://github.com/Jterrettaz/sunduration.
>> The logic is the following :  for each received LOOP packet, the 
>> radiation is compared to a calculated threshold. If the radiation is above 
>> the threshold value, the sunshine time for the LOOP packet is equal to the 
>> time elapsed between the  previous loop packet and this packet (most of the 
>> time 2 seconds with a Vantage Davis Pro).
>> The final archive sunshine duration is the sum of all the LOOP value 
>> within the archive period.
>> Le vendredi 3 juin 2022 à 21:59:36 UTC+2, Peter Fletcher a écrit :
>>
>>> That makes some sense when you are getting data from an 'external' 
>>> sensor, though there are (IMHO) simpler ways of doing it. weewx already has 
>>> access to the LOOP radiation data from the VP2, so handling the processing 
>>> and data storage within weewx makes more sense to me in this case.
>>>
>>> On Friday, June 3, 2022 at 3:24:23 PM UTC-4 vince wrote:
>>>
>>>> On Friday, June 3, 2022 at 11:17:00 AM UTC-7 Meteo Oberwallis wrote:
>>>>
>>>>>  if the interval of Weewx and the data logger is set to 10 minutes, I 
>>>>> would have liked to read the value of the solar sensor every minute and 
>>>>> then write it into a separate .sdb database as possible sunshine.
>>>>
>>>>
>>>> Personally I'd use an external program called via cron and posting a 
>>>> message to a MQTT topic.  Have weewx subscribe to that topic to get the 
>>>> data into your db.
>>>>
>>>> This is how I used to get my DS18b20 temperature sensor data into weewx.
>>>>
>>>>
> -- 
> You received this message because you are subscribed to a topic in the 
> Google Groups "weewx-user" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/weewx-user/19ylVTRqbh4/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> weewx-user+...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/0e631671-0a74-4963-9f1c-e5f81bc7c366n%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/weewx-user/0e631671-0a74-4963-9f1c-e5f81bc7c366n%40googlegroups.com?utm_medium=email_source=footer>
> .
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/72776a59-cc07-4bd3-9fa2-382bb45b73c5n%40googlegroups.com.

Re: [weewx-user] Sunshine Database

['Peter Fletcher' via weewx-user]

I chose to average the LOOP radiation readings and only to do the threshold 
calculation and make the sun/no sun determination every 30 seconds because 
I thought doing it on every LOOP might overload LOOP processing (I am 
running weewx on a Pi 3B, which is also doing a few other things which use 
the CPU). If this is an unnecessary concern, as it may very well be, your 
modified code is much cleaner than mine.

On Saturday, June 4, 2022 at 12:41:08 PM UTC-4 jterr...@gmail.com wrote:

> It is a very good idea to calculate the sunshine duration for each LOOP 
> packet and sum these values to make the final archive sunshine duration.  I 
> have modified my script accordingly :  
> https://github.com/Jterrettaz/sunduration.
> The logic is the following :  for each received LOOP packet, the radiation 
> is compared to a calculated threshold. If the radiation is above the 
> threshold value, the sunshine time for the LOOP packet is equal to the time 
> elapsed between the  previous loop packet and this packet (most of the time 
> 2 seconds with a Vantage Davis Pro).
> The final archive sunshine duration is the sum of all the LOOP value 
> within the archive period.
> Le vendredi 3 juin 2022 à 21:59:36 UTC+2, Peter Fletcher a écrit :
>
>> That makes some sense when you are getting data from an 'external' 
>> sensor, though there are (IMHO) simpler ways of doing it. weewx already has 
>> access to the LOOP radiation data from the VP2, so handling the processing 
>> and data storage within weewx makes more sense to me in this case.
>>
>> On Friday, June 3, 2022 at 3:24:23 PM UTC-4 vince wrote:
>>
>>> On Friday, June 3, 2022 at 11:17:00 AM UTC-7 Meteo Oberwallis wrote:
>>>
>>>>  if the interval of Weewx and the data logger is set to 10 minutes, I 
>>>> would have liked to read the value of the solar sensor every minute and 
>>>> then write it into a separate .sdb database as possible sunshine.
>>>
>>>
>>> Personally I'd use an external program called via cron and posting a 
>>> message to a MQTT topic.  Have weewx subscribe to that topic to get the 
>>> data into your db.
>>>
>>> This is how I used to get my DS18b20 temperature sensor data into weewx.
>>>
>>>

-- 
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/0e631671-0a74-4963-9f1c-e5f81bc7c366n%40googlegroups.com.

Re: [weewx-user] Scaling Units for different reports

['Peter Fletcher' via weewx-user]

Thanks!
I assume that this works 'out of the box' because I have defined the unit 
for sunshine time as 'minute' (rather than something like 'sun_minute') and 
weewx already 'knows' how to convert between common units of time. For my 
solar production example, you would presumably need to use the unit names 
as they are defined in one of the energy groups..

On Friday, June 3, 2022 at 7:41:33 PM UTC-4 tke...@gmail.com wrote:

> Sure. Just tell the report to use hours instead of minutes.
>
> For example, for tags, it becomes $week.sunshine.sum.hour
>
> For a plot, use option 'unit' in skin.conf.
>
> [ImageGenerator]
>   ...
>   [[week_images]]
> ...
> [[[week_sunshine]]]
>   unit = hour
>   sunshine
>   
> All documented in the Customizing Guide 
> <http://www.weewx.com/docs/customizing.htm>.
>
> On Fri, Jun 3, 2022 at 4:31 PM 'Peter Fletcher' via weewx-user <
> weewx...@googlegroups.com> wrote:
>
>> As noted in a different thread, I am working on a small extension to 
>> calculate and store sunshine time (time when the sun is out, rather than 
>> covered by clouds). I am saving the number of *minutes* of sunshine 
>> during the archive period in each archive record. Sunshine minutes are fine 
>> for display on daily reports and graphs, but I would rather display the 
>> more usual sunshine hours on weekly, monthly, and longer reports. Is there 
>> an easy way to tell the report generator to scale the units it uses for 
>> different report periods? I can see this being useful for other categories 
>> of data, too. You might, for example want to display solar production in Wh 
>> for the daily reports but in kWh for monthly and longer ones.
>>
>> I feel that XTypes may provide the answer to this, but couldn't really 
>> get my head around how it would work, in practice.
>>
>> -- 
>> 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/2df447f0-c12d-4947-9bf4-9a2ab9491411n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/weewx-user/2df447f0-c12d-4947-9bf4-9a2ab9491411n%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/e033d8fb-4ec7-4d63-ae5a-d8df1da26dcen%40googlegroups.com.

[weewx-user] Scaling Units for different reports

['Peter Fletcher' via weewx-user]

As noted in a different thread, I am working on a small extension to 
calculate and store sunshine time (time when the sun is out, rather than 
covered by clouds). I am saving the number of *minutes* of sunshine during 
the archive period in each archive record. Sunshine minutes are fine for 
display on daily reports and graphs, but I would rather display the more 
usual sunshine hours on weekly, monthly, and longer reports. Is there an 
easy way to tell the report generator to scale the units it uses for 
different report periods? I can see this being useful for other categories 
of data, too. You might, for example want to display solar production in Wh 
for the daily reports but in kWh for monthly and longer ones.

I feel that XTypes may provide the answer to this, but couldn't really get 
my head around how it would work, in practice.

-- 
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/2df447f0-c12d-4947-9bf4-9a2ab9491411n%40googlegroups.com.

Re: [weewx-user] Sunshine Database

['Peter Fletcher' via weewx-user]

That makes some sense when you are getting data from an 'external' sensor, 
though there are (IMHO) simpler ways of doing it. weewx already has access 
to the LOOP radiation data from the VP2, so handling the processing and 
data storage within weewx makes more sense to me in this case.

On Friday, June 3, 2022 at 3:24:23 PM UTC-4 vince wrote:

> On Friday, June 3, 2022 at 11:17:00 AM UTC-7 Meteo Oberwallis wrote:
>
>>  if the interval of Weewx and the data logger is set to 10 minutes, I 
>> would have liked to read the value of the solar sensor every minute and 
>> then write it into a separate .sdb database as possible sunshine.
>
>
> Personally I'd use an external program called via cron and posting a 
> message to a MQTT topic.  Have weewx subscribe to that topic to get the 
> data into your db.
>
> This is how I used to get my DS18b20 temperature sensor data into weewx.
>
>

-- 
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/ab0422b6-e5b2-4029-a437-570edfb5bb8an%40googlegroups.com.

Re: [weewx-user] Sunshine Database

['Peter Fletcher' via weewx-user]

I do understand what the script is doing. It's not perfect, or at least it 
almost certainly won't perfectly agree with other definitions of whether 
the sun is shining or not - based (e.g.) on the presence or absence of 
shadows under marginal conditiions - but it should be pretty reliable for 
most reasonable circumstances, and I had been thinking of 'home-brewing' a 
similar approach. I assume (perhaps incorrectly) that you are primarily 
interested in getting as precisely as possible a measurement of total 
sunshine time during a period of interest - rather than being able to say 
whether it was sunny at precisely 14:05 local time two days ago. My 
approach will do what (I think) you want - the sunny/not sunny decision is 
made every 30 seconds, and the archive records contain the number of 
seconds in the archive period during which it was sunny, with 30 second 
precision and granularity. You could save the LOOP radiation values in a 
separate database and get down to 2 second precision, but I am not sure why 
you would want to.

I will post the code here when I am sure that it is working properly.
On Friday, June 3, 2022 at 2:17:00 PM UTC-4 Meteo Oberwallis wrote:

> Hello folks.
>
> I don't know if you understood me properly. With the help of the solar 
> sensor of the Davis, the possibility of sunshine can be determined via 
> script and the coordinates. That works fine so far.
> But what I would like to do is, if the interval of Weewx and the data 
> logger is set to 10 minutes, I would have liked to read the value of the 
> solar sensor every minute and then write it into a separate .sdb database 
> as possible sunshine. With this you can prevent that you can not measure 
> the sunshine in the interval of 10 minutes, but every minute. That would be 
> my goal. Since the data logger of the Davis is full within 8 days with an 
> interval of 5 minutes, an increase to a 10-minute storage interval could 
> increase it to a whopping 16 days. But if I set the interval to 10 minutes, 
> then the possible sunshine is only recorded every 10 minutes. Not 
> everything in between. If the solar value is then high enough at the 
> measuring point, the full 10 minutes are registered as sunshine. With a 
> minute interval, this could be obtained even more precisely
>
> Thank you for your feedback
>
> Peter Fletcher schrieb am Donnerstag, 2. Juni 2022 um 23:54:11 UTC+2:
>
>> Well, sort of! I had been wanting to look at sunshine hours for a while, 
>> but it is decidedly non-trivial unless you actually have a sensor that can 
>> tell when the sun is out (they exist, and use the fact that the sun casts 
>> shadows when it is out, but they are very expensive). The approach used by 
>> the OP looks promising as a good approximation if you only have the 
>> standard VP 2 sensors. What I am doing with it is averaging the LOOP 
>> radiation readings over 30 seconds (15 LOOP packets), running the average 
>> through the algorithm he uses to get a binary indication of the sun being 
>> out during that period, and adding 30 (seconds) to a local variable for 
>> 'sun' and 0 for 'no sun'. The archive interval process simply stores the 
>> contents of the local variable in the appropriate archive record and then 
>> clears the local variable. I still have to work on summarizing and 
>> displaying the data.
>>
>> On Thursday, June 2, 2022 at 11:57:13 AM UTC-4 tke...@gmail.com wrote:
>>
>>> That would make sense.
>>>
>>> I've had this same problem with pulse counters. Assuming that the sensor 
>>> returns 0 or 1, one resolution is to use an accumulator that extracts the 
>>> sum of values (rather than the default average). Then at the end of the 
>>> archive interval, multiply the sum by the loop interval. The result will be 
>>> the amount of time the sensor returned 1 during the archive interval, which 
>>> should be the amount of time the sun was out.
>>>
>>>
>>>
>>> On Thu, Jun 2, 2022 at 6:27 AM 'Peter Fletcher' via weewx-user <
>>> weewx...@googlegroups.com> wrote:
>>>
>>>> I think that this is a sensor issue. If the sensor returns only a 
>>>> binary (sun/no sun) value, which appears to be the case for this computed 
>>>> 'sensor', then sampling it every 10 minutes will give results with a 
>>>> granularity of 10 minutes, as the OP describes; if the sensor returns the 
>>>> minutes (or seconds) of sunshine within the archive interval (similarly to 
>>>> the way the Vantage Rain sensor works), then it doesn't matter (within 
>>>> reason) how frequently or infrequently you sample it - the total will be 
>>>> valid. For a Davis setup 

Re: [weewx-user] Sunshine Database

['Peter Fletcher' via weewx-user]

Well, sort of! I had been wanting to look at sunshine hours for a while, 
but it is decidedly non-trivial unless you actually have a sensor that can 
tell when the sun is out (they exist, and use the fact that the sun casts 
shadows when it is out, but they are very expensive). The approach used by 
the OP looks promising as a good approximation if you only have the 
standard VP 2 sensors. What I am doing with it is averaging the LOOP 
radiation readings over 30 seconds (15 LOOP packets), running the average 
through the algorithm he uses to get a binary indication of the sun being 
out during that period, and adding 30 (seconds) to a local variable for 
'sun' and 0 for 'no sun'. The archive interval process simply stores the 
contents of the local variable in the appropriate archive record and then 
clears the local variable. I still have to work on summarizing and 
displaying the data.

On Thursday, June 2, 2022 at 11:57:13 AM UTC-4 tke...@gmail.com wrote:

> That would make sense.
>
> I've had this same problem with pulse counters. Assuming that the sensor 
> returns 0 or 1, one resolution is to use an accumulator that extracts the 
> sum of values (rather than the default average). Then at the end of the 
> archive interval, multiply the sum by the loop interval. The result will be 
> the amount of time the sensor returned 1 during the archive interval, which 
> should be the amount of time the sun was out.
>
>
>
> On Thu, Jun 2, 2022 at 6:27 AM 'Peter Fletcher' via weewx-user <
> weewx...@googlegroups.com> wrote:
>
>> I think that this is a sensor issue. If the sensor returns only a binary 
>> (sun/no sun) value, which appears to be the case for this computed 
>> 'sensor', then sampling it every 10 minutes will give results with a 
>> granularity of 10 minutes, as the OP describes; if the sensor returns the 
>> minutes (or seconds) of sunshine within the archive interval (similarly to 
>> the way the Vantage Rain sensor works), then it doesn't matter (within 
>> reason) how frequently or infrequently you sample it - the total will be 
>> valid. For a Davis setup and this sort of computed 'sensor', the 'sensor' 
>> will probably need to be sampled for each LOOP packet and the results 
>> accumulated internally and the totals saved in each archive record.
>>
>> On Wednesday, June 1, 2022 at 9:50:47 AM UTC-4 tke...@gmail.com wrote:
>>
>>> My apologies, but I don't fully understand the problem. If the type you 
>>> are trying to record is literally the amount of time the sun was out during 
>>> the archive interval, then, in your example, why would no sunshine be 
>>> recorded for the full 10 minutes? Wouldn't it be something less, but 
>>> greater than zero. Say 8 minutes of sunshine?
>>>
>>> What, exactly, is the type that you are trying to put in the database? 
>>> There is no type 'sunshine' within WeeWX. 
>>>
>>>
>>>
>>> On Wed, Jun 1, 2022 at 5:33 AM Meteo Oberwallis  
>>> wrote:
>>>
>>>> Hello, everyone.
>>>> I have a question. Would it be possible to create a separate database 
>>>> for sunshine time? The reason is actually that if the recording interval 
>>>> is 
>>>> set to 10 minutes, the hours of sunshine are then only recorded at 
>>>> intervals of 10 minutes. More precisely, if the solar value is too low in 
>>>> minute 10 or 20 etc., but the value was higher during 8 minutes, then it 
>>>> automatically takes the whole 10 minutes as no sunshine. But if you query 
>>>> the solar value every minute via weewx and compare it with the "Sunshine 
>>>> Time", you would have a much better record. If there was a separate sql 
>>>> for 
>>>> the sunshine time, like e.g. the air quality sensor. In order to make the 
>>>> whole thing even gentler, one could solve it in such a way that the 
>>>> "automation" only becomes active as soon as the solar sensor delivers a 
>>>> value. Is there any of that already? The graphics etc. can then be 
>>>> uploaded 
>>>> normally every 5 or 10 minutes. But I would just like to have my own .sql 
>>>> for the hours of sunshine, which reads the value every minute. The script "
>>>> https://github.com/Jterrettaz/sunduration; already exists.
>>>>
>>>> Thank you for your feedback 
>>>>
>>>> -- 
>>>> 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 
>>

Re: [weewx-user] Sunshine Database

['Peter Fletcher' via weewx-user]

I think that this is a sensor issue. If the sensor returns only a binary 
(sun/no sun) value, which appears to be the case for this computed 
'sensor', then sampling it every 10 minutes will give results with a 
granularity of 10 minutes, as the OP describes; if the sensor returns the 
minutes (or seconds) of sunshine within the archive interval (similarly to 
the way the Vantage Rain sensor works), then it doesn't matter (within 
reason) how frequently or infrequently you sample it - the total will be 
valid. For a Davis setup and this sort of computed 'sensor', the 'sensor' 
will probably need to be sampled for each LOOP packet and the results 
accumulated internally and the totals saved in each archive record.

On Wednesday, June 1, 2022 at 9:50:47 AM UTC-4 tke...@gmail.com wrote:

> My apologies, but I don't fully understand the problem. If the type you 
> are trying to record is literally the amount of time the sun was out during 
> the archive interval, then, in your example, why would no sunshine be 
> recorded for the full 10 minutes? Wouldn't it be something less, but 
> greater than zero. Say 8 minutes of sunshine?
>
> What, exactly, is the type that you are trying to put in the database? 
> There is no type 'sunshine' within WeeWX. 
>
>
>
> On Wed, Jun 1, 2022 at 5:33 AM Meteo Oberwallis  
> wrote:
>
>> Hello, everyone.
>> I have a question. Would it be possible to create a separate database for 
>> sunshine time? The reason is actually that if the recording interval is set 
>> to 10 minutes, the hours of sunshine are then only recorded at intervals of 
>> 10 minutes. More precisely, if the solar value is too low in minute 10 or 
>> 20 etc., but the value was higher during 8 minutes, then it automatically 
>> takes the whole 10 minutes as no sunshine. But if you query the solar value 
>> every minute via weewx and compare it with the "Sunshine Time", you would 
>> have a much better record. If there was a separate sql for the sunshine 
>> time, like e.g. the air quality sensor. In order to make the whole thing 
>> even gentler, one could solve it in such a way that the "automation" only 
>> becomes active as soon as the solar sensor delivers a value. Is there any 
>> of that already? The graphics etc. can then be uploaded normally every 5 or 
>> 10 minutes. But I would just like to have my own .sql for the hours of 
>> sunshine, which reads the value every minute. The script "
>> https://github.com/Jterrettaz/sunduration; already exists.
>>
>> Thank you for your feedback 
>>
>> -- 
>> 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/8ba76e85-40d0-4e20-84ea-a33b38120e3bn%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/81f1fd56-ea21-4d69-9e9e-f76368201026n%40googlegroups.com.

[weewx-user] Re: weewx extra sensors

['Peter Fletcher' via weewx-user]

In the StdReport section, you add and enable a new named subsection 
specifying the skin you want to use for the public report, and with an 
HTML_ROOT specifier *within that subsection*, declaring the folder you want 
to put it in. If you use the FTP approach, as I do, you also have to add 
the necessary parameters to the FTP subsection, and enable it.

On Thursday, June 2, 2022 at 6:03:54 AM UTC-4 hajsek...@gmail.com wrote:

> Ok so if I enable another skin, I can have that.
> So I just add another skin in weewx,conf?
> how can I make this skin to create files in another folder and not the 
> same as first skin? 
> After that I can lock that folder in apache with password.
> I use interceptor driver on my Froggit HP1000SE weather station, because 
> weather station is at home and server with weewx is on another location.
> And I have alot of extra sensors for water leak, soil humidity, 
> temperature, lightning, etc.
> And I like to add some to my web page.
>
> sreda, 1. junij 2022 ob 22:00:29 UTC+2 je oseba Peter Fletcher napisala:
>
>> I handle the public/private page issue by having an additional skin 
>> enabled with the sensors I want to be publicly visible pointing at a local 
>> directory and then using weewx's FTP pseudo-report option to upload the 
>> contents of that directory to a folder on (and linked to) my public 
>> website. I do this mainly because my sites are hosted remotely with a 
>> commercial ISP, but it is also more secure than giving outsiders access to 
>> my internal network.
>>
>> On Tuesday, May 31, 2022 at 9:00:58 AM UTC-4 f4n...@gmail.com wrote:
>>
>>> In the skin.conf, make sure the added sensors are listed/added in:
>>>
>>>  observations_current =
>>>  plot_groups =  
>>>
>>> e.g. add them like this:
>>> plot_groups = extraHumid1, extraTemp2, extraHumid2, soilMoist1, 
>>> soilMoist2,  
>>>
>>> Given that your station driver or in case of sdr the sensor map has any 
>>> data input for these values.
>>>
>>> Not sure about the public/private page thing, you could use an 
>>> additional skin for all values and protect the web output folder for this 
>>> skin with htpasswd.
>>>
>>>
>>> hajsek...@gmail.com schrieb am Dienstag, 31. Mai 2022 um 13:57:12 UTC+2:
>>>
>>>> I see in skin.conf there are added multiple sensors, like example below.
>>>> how to enable those sensors to shou up data on web page.
>>>> Is there any tuttorial?
>>>> Also is it possible to create public web page where only certain data 
>>>> is show up and private page, locked with password to show up all sensors 
>>>> and data?
>>>>
>>>> [[[dayhumext]]]
>>>> extraHumid1
>>>> extraHumid2
>>>> extraHumid3
>>>> extraHumid4
>>>>
>>>> [[[dayhumext2]]]
>>>> extraHumid5
>>>> extraHumid6
>>>> extraHumid7
>>>> extraHumid8
>>>>
>>>> [[[daytempleaf]]]
>>>> leafTemp1
>>>> leafTemp2
>>>>
>>>> [[[daywetleaf]]]
>>>> leafWet1
>>>> leafWet2
>>>>
>>>> [[[daytempsoil]]]
>>>> soilTemp1
>>>> soilTemp2
>>>> soilTemp3
>>>> soilTemp4
>>>>
>>>> [[[daymoistsoil]]]
>>>> soilMoist1
>>>> soilMoist2
>>>> soilMoist3
>>>> soilMoist4
>>>>
>>>

-- 
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/f0b56d39-75c1-4006-83ac-0ecf908b87ddn%40googlegroups.com.

[weewx-user] Re: weewx extra sensors

['Peter Fletcher' via weewx-user]

I handle the public/private page issue by having an additional skin enabled 
with the sensors I want to be publicly visible pointing at a local 
directory and then using weewx's FTP pseudo-report option to upload the 
contents of that directory to a folder on (and linked to) my public 
website. I do this mainly because my sites are hosted remotely with a 
commercial ISP, but it is also more secure than giving outsiders access to 
my internal network.

On Tuesday, May 31, 2022 at 9:00:58 AM UTC-4 f4n...@gmail.com wrote:

> In the skin.conf, make sure the added sensors are listed/added in:
>
>  observations_current =
>  plot_groups =  
>
> e.g. add them like this:
> plot_groups = extraHumid1, extraTemp2, extraHumid2, soilMoist1, 
> soilMoist2,  
>
> Given that your station driver or in case of sdr the sensor map has any 
> data input for these values.
>
> Not sure about the public/private page thing, you could use an additional 
> skin for all values and protect the web output folder for this skin with 
> htpasswd.
>
>
> hajsek...@gmail.com schrieb am Dienstag, 31. Mai 2022 um 13:57:12 UTC+2:
>
>> I see in skin.conf there are added multiple sensors, like example below.
>> how to enable those sensors to shou up data on web page.
>> Is there any tuttorial?
>> Also is it possible to create public web page where only certain data is 
>> show up and private page, locked with password to show up all sensors and 
>> data?
>>
>> [[[dayhumext]]]
>> extraHumid1
>> extraHumid2
>> extraHumid3
>> extraHumid4
>>
>> [[[dayhumext2]]]
>> extraHumid5
>> extraHumid6
>> extraHumid7
>> extraHumid8
>>
>> [[[daytempleaf]]]
>> leafTemp1
>> leafTemp2
>>
>> [[[daywetleaf]]]
>> leafWet1
>> leafWet2
>>
>> [[[daytempsoil]]]
>> soilTemp1
>> soilTemp2
>> soilTemp3
>> soilTemp4
>>
>> [[[daymoistsoil]]]
>> soilMoist1
>> soilMoist2
>> soilMoist3
>> soilMoist4
>>
>

-- 
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/5ac10382-d9af-42de-b8d7-5fb07ec3cc7cn%40googlegroups.com.

[weewx-user] Re: WeeWX and pv?

['Peter Fletcher' via weewx-user]

To expand slightly on Tom's response to the second half of your query, 
wee_import is designed to import *complete archive records* (or, at least, 
as complete as the source device produces) from an external source into the 
weewx database. It is not intended to update selected fields *in existing 
records*, which is what you want to do, nor can it be used to do so. 
Depending on your comfort with SQL and/or Python programming, you will need 
either to use the sqlite3 app directly to update the records or follow one 
of his suggested strategies.

On Thursday, January 20, 2022 at 2:50:07 AM UTC-5 udo.kl...@gmail.com wrote:

> Since I only want to display a few PV data, I decided to use the two 
> database fields "signal1" and "signal2" as storage location for the output 
> data of my two inverters.
> In principle, this also works, but I do not receive totalized yield data. 
> This means that at the end of the day, I can display the history, but not 
> the daily output.
>
> Another issue is the subsequent import of the stored data into the WeeWX 
> database. I wanted, to have the year 2022 complete, to transfer the data 
> saved as csv to the WeeWX database afterwards using wee_import. 
>
> I have prepared the csv accordingly and assigned "signal1" and "signal2" 
> to the group group_energy in the units.py file. If I start the import with 
> the parameter "--dry-run" everything is fine. Without "--dry-run" the 
> process also runs without errors, but the data is not included in the 
> database due to a UNIQUE problem.
>
> However, I would like to add the PV values to the respective existing data 
> record and not create a new data record. Is there no way to keep the 
> existing record and only save the additional values?
>
> I am very thankful for any tip
> kludo schrieb am Sonntag, 9. Januar 2022 um 16:22:25 UTC+1:
>
>> Thank you for the answers, I will have to look into the subject more 
>> intensively. My PV system is already very old and there is no support from 
>> the manufacturer, but I can tap the harvest data via serial interface. 
>> Let's see which solution brings me the faster success.
>>
>> kk44...@gmail.com schrieb am Freitag, 7. Januar 2022 um 15:56:14 UTC+1:
>>
>>> There is no general solution to include PV values in WeeWX. As far as I 
>>> know, an extension is available for one single german manufacturer, only.
>>>
>>> Peter Fletcher schrieb am Freitag, 7. Januar 2022 um 15:11:26 UTC+1:
>>>
>>>> You have at least two options. One is to keep your detailed solar 
>>>> records separately and pull the data items you want to display into either 
>>>> new fields or 'spare' fields in the weewx database. The other, of course, 
>>>> is to add all the fields you need to the weewx database. AFAIK, there is 
>>>> no 
>>>> ready-made 'package' that does this.
>>>>
>>>> I don't incorporate my solar data in weewx, because I created a 
>>>> separate application that records all the data locally before I got into 
>>>> weather, and my solar provider has an excellent web-based App which 
>>>> displays the real-time data. I do, however, use the first approach to 
>>>> combine some of the data from my ecobee thermostat with weewx's weather 
>>>> data for display. Assuming that you have some degree of comfort with 
>>>> database design and Python programming, the weewx documentation will help 
>>>> you greatly with either approach, but you will also be able to get useful 
>>>> help and advice about implementation details here.
>>>>
>>>> On Friday, January 7, 2022 at 5:05:13 AM UTC-5 udo.kl...@gmail.com 
>>>> wrote:
>>>>
>>>>> I have installed WeeWX in the last few weeks and have come to know and 
>>>>> appreciate the software.
>>>>>
>>>>> But now i would like to add the solar yield of my pv system to the 
>>>>> weewx database as well. Unfortunately, I have not found any suitable 
>>>>> database fields for this. Do I have to adapt the database schema for 
>>>>> this? 
>>>>> Is there possibly already a ready-made solution for this?
>>>>>
>>>>> 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/39ad7edb-9f47-4609-a231-bd6d295ec78en%40googlegroups.com.

[weewx-user] Re: WeeWX and pv?

['Peter Fletcher' via weewx-user]

You have at least two options. One is to keep your detailed solar records 
separately and pull the data items you want to display into either new 
fields or 'spare' fields in the weewx database. The other, of course, is to 
add all the fields you need to the weewx database. AFAIK, there is no 
ready-made 'package' that does this.

I don't incorporate my solar data in weewx, because I created a separate 
application that records all the data locally before I got into weather, 
and my solar provider has an excellent web-based App which displays the 
real-time data. I do, however, use the first approach to combine some of 
the data from my ecobee thermostat with weewx's weather data for display. 
Assuming that you have some degree of comfort with database design and 
Python programming, the weewx documentation will help you greatly with 
either approach, but you will also be able to get useful help and advice 
about implementation details here.

On Friday, January 7, 2022 at 5:05:13 AM UTC-5 udo.kl...@gmail.com wrote:

> I have installed WeeWX in the last few weeks and have come to know and 
> appreciate the software.
>
> But now i would like to add the solar yield of my pv system to the weewx 
> database as well. Unfortunately, I have not found any suitable database 
> fields for this. Do I have to adapt the database schema for this? Is there 
> possibly already a ready-made solution for this?
>
> 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/caa427a6-ef7d-43b5-88ad-3a0fcdc607ban%40googlegroups.com.

[weewx-user] Re: WeeWX on Raspberry Pi Pico and MicroPython

['Peter Fletcher' via weewx-user]

Highly unlikely! Even if the weewx code and its associated libraries do not 
use Python functionalities that MicroPython doesn't support, and you can 
deal with the interfacing, there probably isn't enough memory space to fit 
the interpreter and all the code and libraries on the device, especially 
not while leaving room to store any saved data. 

On Friday, December 24, 2021 at 11:05:30 PM UTC-5 garrya...@gmail.com wrote:

> Davis Pro2 by USB.
>
> On Thursday, December 23, 2021 at 8:06:59 PM UTC-8 vince wrote:
>
>> On Thursday, December 23, 2021 at 6:02:57 PM UTC-8 garrya...@gmail.com 
>> wrote:
>>
>>> With apologies if there is already a thread about this but will WeeWX 
>>> run on a Raspberry Pi Pico with MicroPython?
>>> If no one has actually tried it, and the consensus is that it 
>>> might/should work, I might give it a try and report back.
>>>
>>>
>> For starters - what kind of station do you have and how would you 
>> interface it with a pico ?
>>
>> But I'd be a bit surprised if it met the python prerequisites for weewx, 
>> specifically the imaging libraries and Cheetah.
>>
>>

-- 
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/7ff2ad5d-bb3d-4789-91a1-d4487fa940e4n%40googlegroups.com.

[weewx-user] Publish Seasons Skin to webserver

[Peter Gillbrand]

Dear group, once again I put my hope to your competence and willingness to 
help.

I want to publish my weather data to my web page in the Seasons skin format 
using the FTP transfer method in weewx.conf. This seems to work only with 
skin=FTP which of course give the FTP skin look at the webpage. Is there 
any way I can get the webpage to present data with Seasons look and feel?

Thanks for your help!


-- 
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/7e01b1d4-4d3a-4a7d-a421-943b86cc5d1an%40googlegroups.com.

[weewx-user] Re: Date and time format in the seasons skin

[Peter Gillbrand]

Thanks a lot Gary! The header part worked perfectly. I´ll try the plots 
tomorrow

On Tuesday, May 4, 2021 at 10:44:10 PM UTC+2 gjr80 wrote:

> Hi,
>
> There are a few ways to handle the date-time in the header. Basically the 
> options come down to changing the format used by the tag used to generate 
> that date-time or altering the default format used by date-time tags in all 
> reports or just the Seasons skin. I suspect you probably want the former.
>
> To change the format used by the tag used to generate that date-time you 
> need to edit skins/Seasons/titlebar.inc and change the following line from 
> (untested):
>
> $current.dateTime
>
> to:
>
> $current.dateTime.format(format_string="%Y-%m-%d 
> %H:%M")
>
> Save the file and the change should occur on the next report cycle. For 
> info, the available format codes are listed in the table here 
> 
> .
>
> For the date-time formats used in the plot labels you need to alter 
> settings under the [ImageGenerator] stanza in the Season skin config file 
> (skins/Seasons/skin.conf), specifically the bottom_label_format setting. 
> The ImageGenerator label options are covered here 
>  in the 
> Customization Guide. The format codes used by bottom_label_format are the 
> same as linked earlier in this post. Note also that bottom_label_format is 
> set for each set (day, week, month, year) of plots.
>
> The above changes should be retained across WeeWX upgrades but you may 
> wish to make note of your changes should you need to restore them in the 
> future.
>
> Gary
>
> On Wednesday, 5 May 2021 at 05:41:33 UTC+10 p.gil...@gmail.com wrote:
>
>> This should be a simple config question but I have failed. How can I 
>> change the date and time format from something like 05/04/2021 09:15:00 PM 
>> to 2021-05-04 21:15 in the header of the Seasons skin as well as in the day 
>> plots? 
>> Thanks for any support to solve this minor but irritating issue. 
>>
>>

-- 
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/4333e44e-ed0c-46b1-b5d7-b09ccac22535n%40googlegroups.com.

[weewx-user] Date and time format in the seasons skin

[Peter Gillbrand]

This should be a simple config question but I have failed. How can I change 
the date and time format from something like 05/04/2021 09:15:00 PM to 
2021-05-04 21:15 in the header of the Seasons skin as well as in the day 
plots? 
Thanks for any support to solve this minor but irritating issue. 

-- 
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/17ddb591-439f-42ae-ab62-4f16a5ee2e93n%40googlegroups.com.

Re: [weewx-user] Re: possible for weewx to accept data via MQTT devices?

[Peter Gillbrand]

I have manage to get a weather station to be the main provider of data to 
R-Pi based Weewx installation with add on data into the database coming 
from a sensor providing MQTT messages. If that it is similar to what you 
are aiming for,  maybe this conversation can provide 
guidance https://github.com/bellrichm/WeeWX-MQTTSubscribe/discussions/132

On Tuesday, May 4, 2021 at 7:24:13 PM UTC+2 eric.k...@gmail.com wrote:

> > DId you read
> > https://github.com/bellrichm/WeeWX-MQTTSubscribe/wiki/Configuring
>
> No, I wanted to make sure MQTT was usable simultaneously with another 
> weewx "driver", before I spent a lot of time on it.
>
> Thanks for the pointer to service vs. driver configuration!
> I'll read through it.
> On Tuesday, May 4, 2021 at 11:33:07 AM UTC-5 Greg Troxel wrote:
>
>>
>> Eric Koester  writes:
>>
>> > Thanks for the pointer, Peter.
>> > I looked through the install instructions and I don't see any mention 
>> of 
>> > the weewx.conf file.
>>
>> DId you read
>>
>> https://github.com/bellrichm/WeeWX-MQTTSubscribe/wiki/Configuring
>>
>> Agreed that it doesn't say that it is talking about the config file.
>>
>> A big point is driver vs service. It seems clear that you want
>> service, where MQTT input is secondary.
>>
>>

-- 
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/11b9113d-aaa7-46a1-9489-c15efceea72fn%40googlegroups.com.

[weewx-user] Re: possible for weewx to accept data via MQTT devices?

[Peter Gillbrand]

Check this: https://github.com/bellrichm/WeeWX-MQTTSubscribe

On Tuesday, May 4, 2021 at 12:31:55 AM UTC+2 eric.k...@gmail.com wrote:

> I'm currently reading data into weewx using an Acurite Atlas, an RTL-SDR, 
> rtl_433, and weewx-sdr.
>
> I'd like to import barometric pressure sensor data into weewx via MQTT 
> from a wifi pressure sensor.  Is that possible?  
> If yes, is it possible to import data via 2 different drivers?
>
> The potential plan is to connect an BME280 sensor (via i2c) to a ESP8266 
> wifi module loaded with Tasmota open-source firmware.
> see:  https://tasmota.github.io/docs/BME280/
> Tasmota sends the data a tele/%topic%/SENSOR JSON response.
>
> Assuming that weewx can accept data via MQTT, I'm not sure what the 
> device-facing variable name would be inside of weewx.
> example of known device-facing variable name:  
> outTemp = temperature.001.AcuriteAtlaspacket
>

-- 
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/5c1d72f7-5af1-4d2c-8daf-f06f0c2f269dn%40googlegroups.com.

[weewx-user] Re: One month later another serious Weewx upload failure

[Peter Dougherty]

Sorry, I hit send before completing the post

After stopping the service again, and invoking the wee_device --dump and  
wee_device --clear-memory commands, and then restarting weewx, it started 
working again. Both CWOP And WU are getting data. And while that's great, 
it's hinting at a reliability problem that had never existed until last 
month. Is there anything I can do to solve this permanently and get it back 
to the way it always was?

Conversely, is there any sort of black-box device or  that I can 
use to just send this info out without needing to play with Linux? I don't 
want to replace the weather station; the hardware outside is fine, but the 
the convoluted way it reports to WU and CWOP are a headache I don't want, 
especially if it's turning into a monthly circus.

On Friday, April 23, 2021 at 11:24:24 PM UTC-4 Peter Dougherty wrote:

> Last month (Mar. 22) I was experiencing upload problems to CWOP. Today a 
> similar (worse) problem. Nothing was done to the Pi since the end of last 
> month's troubles. It just stopped uploading to both CWOP and WU about an 
> hour ago.
>
> I've tried unplugging the console, restarting the process, restarting the 
> pi and nothing is working. Again. This ran for years without corruption and 
> now twice in a month. What can I do to get it working again, and how on 
> Earth can I get this back to be the reliable device it was for almost four 
> years in a row? Linux is massively out of my comfort zone.
>
> The relevant part of my config file and the last few lines of my log 
> follow:
>
> # WEEWX CONFIGURATION FILE
> #
> # Copyright (c) 2009-2015 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 = /
>
> # 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 = 3.6.2
>
>
> ##
>
> #   This section is for information about the station.
>
> [Station]
> 
> # Description of the station location
> location = "West Caldwell, NJ"
> 
> # Latitude and longitude in decimal degrees
> latitude = 40.8615
> longitude = -74.2775
> 
> # Altitude of the station, with unit it is in. This is downloaded from
> # from the station if the hardware supports it.
> altitude = 261, foot
> 
> # Set to type of station hardware. There must be a corresponding stanza
> # in this file with a 'driver' parameter indicating the driver to be 
> used.
> station_type = Vantage
> 
> # If you have a website, you may specify an URL
> #station_url = http://www.example.com
> 
> # The start of the rain year (1=January; 10=October, etc.). This is
> # downloaded from the station if the hardware supports it.
> rain_year_start = 1
> 
> # Start of week (0=Monday, 6=Sunday)
> week_start = 6
>
>
> ##
>
> [Vantage]
> type = serial
> port = /dev/ttyUSB0
> driver = weewx.drivers.vantage
> 
> 
> # The time (in seconds) between LOOP packets.
> loop_interval = 2.5
>
>
>
> ##
>
> #   This section is for uploading data to Internet sites
>
> [StdRESTful]
> 
> [[StationRegistry]]
> # To register this weather station with weewx, set this to true
> register_this_station = true
> 
> [[AWEKAS]]
> # This section is for configuring posts to AWEKAS.
> 
> # If you wish to do this, set the option 'enable' to true,
> # and specify a username and password.
> enable = false
> username = replace_me
> password = replace_me
> 
> 
> [[CWOP]]
> # This section is for configuring posts to CWOP.
> 
> # If you wish to do this, set the option 'enable' to true,
> # and specify the station ID (e.g., CW1234).
> enable = true
> station = W2IRT
> post_interval = 300
> log_success = True
> log_failure = True
> server_list = rotate.aprs.net:14580, rotate.aprs2.net:14580, 
> cwop.aprs.net:14580, swop.aprs.net:23
>  

[weewx-user] One month later another serious Weewx upload failure

[Peter Dougherty]

Last month (Mar. 22) I was experiencing upload problems to CWOP. Today a 
similar (worse) problem. Nothing was done to the Pi since the end of last 
month's troubles. It just stopped uploading to both CWOP and WU about an 
hour ago.

I've tried unplugging the console, restarting the process, restarting the 
pi and nothing is working. Again. This ran for years without corruption and 
now twice in a month. What can I do to get it working again, and how on 
Earth can I get this back to be the reliable device it was for almost four 
years in a row? Linux is massively out of my comfort zone.

The relevant part of my config file and the last few lines of my log follow:

# WEEWX CONFIGURATION FILE
#
# Copyright (c) 2009-2015 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 = /

# 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 = 3.6.2

##

#   This section is for information about the station.

[Station]

# Description of the station location
location = "West Caldwell, NJ"

# Latitude and longitude in decimal degrees
latitude = 40.8615
longitude = -74.2775

# Altitude of the station, with unit it is in. This is downloaded from
# from the station if the hardware supports it.
altitude = 261, foot

# Set to type of station hardware. There must be a corresponding stanza
# in this file with a 'driver' parameter indicating the driver to be 
used.
station_type = Vantage

# If you have a website, you may specify an URL
#station_url = http://www.example.com

# The start of the rain year (1=January; 10=October, etc.). This is
# downloaded from the station if the hardware supports it.
rain_year_start = 1

# Start of week (0=Monday, 6=Sunday)
week_start = 6

##

[Vantage]
type = serial
port = /dev/ttyUSB0
driver = weewx.drivers.vantage


# The time (in seconds) between LOOP packets.
loop_interval = 2.5


##

#   This section is for uploading data to Internet sites

[StdRESTful]

[[StationRegistry]]
# To register this weather station with weewx, set this to true
register_this_station = true

[[AWEKAS]]
# This section is for configuring posts to AWEKAS.

# If you wish to do this, set the option 'enable' to true,
# and specify a username and password.
enable = false
username = replace_me
password = replace_me


[[CWOP]]
# This section is for configuring posts to CWOP.

# If you wish to do this, set the option 'enable' to true,
# and specify the station ID (e.g., CW1234).
enable = true
station = W2IRT
post_interval = 300
log_success = True
log_failure = True
server_list = rotate.aprs.net:14580, rotate.aprs2.net:14580, 
cwop.aprs.net:14580, swop.aprs.net:23

# If this is an APRS (radio amateur) station, uncomment
# the following and replace with a passcode (e.g., 12345).
passcode = [removed by me]


[[PWSweather]]
# This section is for configuring posts to PWSweather.com.

# If you wish to do this, set the option 'enable' to true,
# and specify a station and password.
enable = true
station = w2irt
password = [removed for privacy]

[[WOW]]
# This section is for configuring posts to WOW.

# If you wish to do this, set the option 'enable' to true,
# and specify a station and password.
enable = false
station = replace_me
password = replace_me

[[Wunderground]]
# This section is for configuring posts to the Weather Underground.

# If you wish to do this, set the option 'enable' to true,
# and specify a station (e.g., 'KORHOODR3') and password.
enable = true
station = KNJWESTC2
password = [removed for privacy]

# Set the following to True to have weewx use the WU "Rapidfire"
# protocol. Not all hardware can support it. See the User's Guide.
rapidfire = True

#[[Twitter]]
#oauth_token_secret = OAUTH_TOKEN_SECRET
#oauth_token = OAUTH_TOKEN
#app_key_secret = APP_KEY_SECRET
#app_key = APP_KEY




LOG 

Re: [weewx-user] Davis vantage pro2

['Peter Fletcher' via weewx-user]

I have used a variety of loggers with my Davis VP 2+ - for many years 
directly connected to Windows systems; subsequently (but also for 2-3 years 
now) to a Raspberry Pi. I can say without doubt that the Meteo-Pi, once set 
up, has given me fewer problems than the Davis alternatives. It also allows 
the Davis console to be powered directly from the Pi through the same cable 
as carries the serial data, slightly reducing cable clutter. The console 
draws so little power that the extra load is no problem for a Pi power 
supply. I should, perhaps, add the disclaimer that I was a beta-tester for 
a number of the devices created and sold by the Meteo-Pi''s producer, so I 
got mine free, but I get no other income or other benefit from ongoing 
sales of the devices.

On Saturday, April 10, 2021 at 3:29:36 PM UTC-4 vince wrote:

> On Saturday, April 10, 2021 at 11:18:07 AM UTC-7 chris.th...@gmail.com 
> wrote:
>
>> so I found this:
>> https://shop.weatherstations.co.uk/meteo-pi-1832-p.asp
>> seems like you can connect the davis console directly to raspberry pi 
>> header and use via serial.
>> anyone tried this with weewx?
>> Seems a bit cheaper than the weatherlink option and maybe more suitable 
>> for my needs.
>>
>
> A real Davis logger is $30 US more expensive than a Meteo-pi.   You have 
> to ask yourself how important that 30 bucks is, as compared to your time 
> and stress level of using a third-party logger.  Personally I'd recommend 
> just going Davis all the way.
>
>
>

-- 
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/640040fd-0277-496c-baa3-9bc64c7a7404n%40googlegroups.com.

Re: [weewx-user] Re: Version 4.5.0 released

['Peter Fletcher' via weewx-user]

Yes, that is what I did with the more extensively modified version of 
Seasons I use for my public site, but the version I use locally just had 
some minor tweaks, so I didn't change the name, and apt appears to be 
handling it as I would wish and as mwall describes (though I have never 
touched conffiles, so the default for weewx may have changed).

On Friday, April 2, 2021 at 5:56:42 PM UTC-4 vince wrote:

> FWIW, it's more work but a generally better way to approach essentially 
> forking things in core weewx is to create your own skin based on some 
> starting point, disable the skin that comes with weewx, and enable your 
> custom skin that has a different name.  Bonus points if you make your 
> custom skin installable with wee_extension.
>
> That keeps you safe from your modifications being altered by a future 
> weewx update, as weewx won't stomp on things that didn't come with weewx.
>
>
>

-- 
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/8c1adc43-7a38-4603-b8b3-d172210421fcn%40googlegroups.com.

Re: [weewx-user] Re: Version 4.5.0 released

['Peter Fletcher' via weewx-user]

I'm using the regular Raspberry Pi version of Debian, and I am afraid that 
I don't have a copy of the output of the apt session. However, diffing my 
Seasons skin.conf with the new version saved as skin.conf.dpkg-dist shows 
(apart from my modifications, of course) changes in the predefined 
radar_url and radar_img parameters, a change in the available and default 
encoding parameters, and  the use of text descriptors (day, week, etc) 
instead of numbers of seconds for aggregate_interval parameters. None of 
these are a problem for me (since the old seconds counts seem to still 
work), and I don't see anything else.

On Friday, April 2, 2021 at 4:59:46 PM UTC-4 tke...@gmail.com wrote:

> Peter: are you using a Debian or Redhat system?
>
> Do you have the output from the session?
>
> On Fri, Apr 2, 2021 at 11:56 AM 'Peter Fletcher' via weewx-user <
> weewx...@googlegroups.com> wrote:
>
>> What has changed in the Seasons skin? When I apt upgraded my Pi today, I 
>> got the usual "What do you want to do about weewx.conf?" prompt (which I 
>> answered, as usual, by opting to keep my existing version), but I also got 
>> a similar prompt for the Seasons skin.conf. I have made some minor 
>> modifications to Seasons for my own use, but I also use a more heavily 
>> modified version of it for my publicly visible site. It would be good to 
>> know if I need to think about changing anything.
>>
>> On Friday, April 2, 2021 at 11:11:42 AM UTC-4 tke...@gmail.com wrote:
>>
>>> *Change log*
>>>
>>> The utility wee_database has new options --add-column, --rename-column, and
>>> --drop-columns for adding, renaming, and deleting columns in the database.
>>>
>>> New optional tag ".series()", for creating and formatting series in 
>>> templates.
>>> See the document series_tags.md in the docs subdirectory. This is still
>>> experimental and subject to change! Addresses issue #341.
>>>
>>> New optional tag ".json()" for formatting results as JSON.
>>>
>>> New optional tag ".round()". Useful for rounding results of .raw and .json 
>>> tags.
>>>
>>> Improved performance when calculating series using aggregation periods that 
>>> are
>>> multiples of a day.
>>>
>>> Changed NOAA reports to use the 'normalized_ascii' encoding instead of 
>>> 'utf8'
>>> (which did not display correctly for most browsers). Fixes issue #646.
>>>
>>> Plots longer than 2 years use a 6 month time increment.
>>>
>>> Uploads to PWSWeather and WOW now use HTTPS. Fixes issue #650.
>>>
>>> Fixed bug that prevented the Vantage driver from waiting before a wakeup 
>>> retry.
>>> Thanks to user Les Niles!
>>>
>>> Changed the way of expressing the old "wview" schema to the new V4 way.
>>> Hopefully, this will lead to fewer support issues. Fixes issue #651.
>>>
>>> Fixed problem where iterating over a time period without an aggregation 
>>> would
>>> wrongly include the record on the left.
>>>
>>> Fixed bug that caused the incorrect label to be applied to plots where the
>>> aggregation type changes the unit. Fixes issue #654.
>>>
>>> Plots now locate the x-coordinate in the middle of the aggregation interval 
>>> for
>>> all aggregation types (not just min, max, avg). Revisits PR #232.
>>>
>>> Added new time units 'unix_epoch_ms' and 'unix_epoch_ns', which are unix 
>>> epoch
>>> time in milliseconds and nanoseconds, respectively.
>>>
>>> The FTP uploader now calculates and saves a hash value for each uploaded 
>>> file.
>>> If it does not change, the file is not uploaded, resulting in significant
>>> time savings. PR #655. Thanks to user Karen!
>>>
>>> Updated the version of six.py included with WeeWX to 1.15.0. Fixes issue 
>>> #657.
>>>
>>> Option aggregate_interval can now be specified by using one of the 
>>> "shortcuts",
>>> that is, 'hour', 'day', 'week', 'month', or 'year'.
>>>
>>> Options "log_success" and "log_failure" are now honored by the StdArchive
>>> service.
>>>
>>>
>>> -- 
>> 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/c7459b0f-d03a-4022-8003-5875a23fd10dn%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/weewx-user/c7459b0f-d03a-4022-8003-5875a23fd10dn%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/e838fa2a-46d7-4a99-94f9-8e273edfabb6n%40googlegroups.com.

[weewx-user] Re: Version 4.5.0 released

['Peter Fletcher' via weewx-user]

What has changed in the Seasons skin? When I apt upgraded my Pi today, I 
got the usual "What do you want to do about weewx.conf?" prompt (which I 
answered, as usual, by opting to keep my existing version), but I also got 
a similar prompt for the Seasons skin.conf. I have made some minor 
modifications to Seasons for my own use, but I also use a more heavily 
modified version of it for my publicly visible site. It would be good to 
know if I need to think about changing anything.

On Friday, April 2, 2021 at 11:11:42 AM UTC-4 tke...@gmail.com wrote:

> *Change log*
>
> The utility wee_database has new options --add-column, --rename-column, and
> --drop-columns for adding, renaming, and deleting columns in the database.
>
> New optional tag ".series()", for creating and formatting series in templates.
> See the document series_tags.md in the docs subdirectory. This is still
> experimental and subject to change! Addresses issue #341.
>
> New optional tag ".json()" for formatting results as JSON.
>
> New optional tag ".round()". Useful for rounding results of .raw and .json 
> tags.
>
> Improved performance when calculating series using aggregation periods that 
> are
> multiples of a day.
>
> Changed NOAA reports to use the 'normalized_ascii' encoding instead of 'utf8'
> (which did not display correctly for most browsers). Fixes issue #646.
>
> Plots longer than 2 years use a 6 month time increment.
>
> Uploads to PWSWeather and WOW now use HTTPS. Fixes issue #650.
>
> Fixed bug that prevented the Vantage driver from waiting before a wakeup 
> retry.
> Thanks to user Les Niles!
>
> Changed the way of expressing the old "wview" schema to the new V4 way.
> Hopefully, this will lead to fewer support issues. Fixes issue #651.
>
> Fixed problem where iterating over a time period without an aggregation would
> wrongly include the record on the left.
>
> Fixed bug that caused the incorrect label to be applied to plots where the
> aggregation type changes the unit. Fixes issue #654.
>
> Plots now locate the x-coordinate in the middle of the aggregation interval 
> for
> all aggregation types (not just min, max, avg). Revisits PR #232.
>
> Added new time units 'unix_epoch_ms' and 'unix_epoch_ns', which are unix epoch
> time in milliseconds and nanoseconds, respectively.
>
> The FTP uploader now calculates and saves a hash value for each uploaded file.
> If it does not change, the file is not uploaded, resulting in significant
> time savings. PR #655. Thanks to user Karen!
>
> Updated the version of six.py included with WeeWX to 1.15.0. Fixes issue #657.
>
> Option aggregate_interval can now be specified by using one of the 
> "shortcuts",
> that is, 'hour', 'day', 'week', 'month', or 'year'.
>
> Options "log_success" and "log_failure" are now honored by the StdArchive
> service.
>
>
>

-- 
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/c7459b0f-d03a-4022-8003-5875a23fd10dn%40googlegroups.com.

RE: [weewx-user] Not uploading to CWOP - still not working

[Peter Dougherty]

Yes! So far so good!

 

- pjd

 

From: weewx-user@googlegroups.com  On Behalf Of 
John Kline
Sent: Monday, March 22, 2021 10:57 PM
To: weewx-user@googlegroups.com
Subject: Re: [weewx-user] Not uploading to CWOP - still not working

 

It looks like every 5 minutes to me, no?

http://www.findu.com/cgi-bin/raw.cgi?call=W2IRT

 

 





On Mar 22, 2021, at 7:03 PM, Peter Dougherty mailto:pjdoughe...@gmail.com> > wrote:



Sorry to be so daft, but I honestly could not understand this. I’m a 
“set-it-and-forget-it” user so I’m not up on all the terminology, I’m afraid. I 
last did anything of consequence to this RPi in 2019, and it was built by a 
Linux-competent friend in 2017. 

I did tell the weewx config file to upload to CWOP every 300 seconds, but it 
only seems to show up every 600s (10 minutes) instead.

 

- pjd

 

From: weewx-user@googlegroups.com <mailto:weewx-user@googlegroups.com>  
mailto:weewx-user@googlegroups.com> > On Behalf 
Of Tom Keffer
Sent: Monday, March 22, 2021 9:57 PM
To: weewx-user mailto:weewx-user@googlegroups.com> >
Subject: Re: [weewx-user] Not uploading to CWOP - still not working

 

It should have put the data right in your database. You should be able to tell 
by looking at the image plots.

 

Mind you: they are refreshed only as often as the aggregation interval. If you 
want to see them right away, delete them and they will be automatically 
regenerated in the next reporting cycle.

 

-tk

 

On Mon, Mar 22, 2021 at 6:54 PM Peter Dougherty mailto:pjdoughe...@gmail.com> > wrote:

I did use the - -  dump command. But (a) I don’t know where it put the data, 
(b) how to recover it, or (c) does it need to even be recovered now?

 

- pjd

 

From: weewx-user@googlegroups.com <mailto:weewx-user@googlegroups.com>  
mailto:weewx-user@googlegroups.com> > On Behalf 
Of Tom Keffer
Sent: Monday, March 22, 2021 9:30 PM
To: weewx-user mailto:weewx-user@googlegroups.com> >
Subject: Re: [weewx-user] Not uploading to CWOP - still not working

 

If you did the "wee_device --dump" command as suggested by the Wiki, you should 
have recovered all the data off the logger.

 

If not, you can use wee_import 
<http://www.weewx.com/docs/utilities.htm#wee_import_utility>  to recover from 
the Weather Underground.

 

-- 
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 
<mailto:weewx-user+unsubscr...@googlegroups.com> .
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/062f01d71f87%2475641be0%24602c53a0%24%40gmail.com
 
<https://groups.google.com/d/msgid/weewx-user/062f01d71f87%2475641be0%24602c53a0%24%40gmail.com?utm_medium=email_source=footer>
 .

-- 
You received this message because you are subscribed to a topic in the Google 
Groups "weewx-user" group.
To unsubscribe from this topic, visit 
https://groups.google.com/d/topic/weewx-user/h0AhMSztDvI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to 
weewx-user+unsubscr...@googlegroups.com 
<mailto:weewx-user+unsubscr...@googlegroups.com> .
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/CAPq0zEC1-FaM%3D04BFBiNvZaxDO_HsZTyggCaMt-96_VAUfA9cQ%40mail.gmail.com
 
<https://groups.google.com/d/msgid/weewx-user/CAPq0zEC1-FaM%3D04BFBiNvZaxDO_HsZTyggCaMt-96_VAUfA9cQ%40mail.gmail.com?utm_medium=email_source=footer>
 .

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com 
<mailto:weewx-user+unsubscr...@googlegroups.com> .
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/064401d71f88%24c678ae50%24536a0af0%24%40gmail.com
 
<https://groups.google.com/d/msgid/weewx-user/064401d71f88%24c678ae50%24536a0af0%24%40gmail.com?utm_medium=email_source=footer>
 .

-- 
You received this message because you are subscribed to a topic in the Google 
Groups "weewx-user" group.
To unsubscribe from this topic, visit 
https://groups.google.com/d/topic/weewx-user/h0AhMSztDvI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to 
weewx-user+unsubscr...@googlegroups.com 
<mailto:weewx-user+unsubscr...@googlegroups.com> .
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/9F506130-A298-4627-9FFE-CA831FAA1C7F%40johnkline.com
 
<https://groups.google.com/d/msgid/weewx-user/9F506130-A298-4627-9FFE-CA831FAA1C7F%40johnkline.com?utm_medium=email_source=footer>
 .

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

RE: [weewx-user] Not uploading to CWOP - still not working

[Peter Dougherty]

Sorry to be so daft, but I honestly could not understand this. I’m a 
“set-it-and-forget-it” user so I’m not up on all the terminology, I’m afraid. I 
last did anything of consequence to this RPi in 2019, and it was built by a 
Linux-competent friend in 2017. 

I did tell the weewx config file to upload to CWOP every 300 seconds, but it 
only seems to show up every 600s (10 minutes) instead.

 

- pjd

 

From: weewx-user@googlegroups.com  On Behalf Of 
Tom Keffer
Sent: Monday, March 22, 2021 9:57 PM
To: weewx-user 
Subject: Re: [weewx-user] Not uploading to CWOP - still not working

 

It should have put the data right in your database. You should be able to tell 
by looking at the image plots.

 

Mind you: they are refreshed only as often as the aggregation interval. If you 
want to see them right away, delete them and they will be automatically 
regenerated in the next reporting cycle.

 

-tk

 

On Mon, Mar 22, 2021 at 6:54 PM Peter Dougherty mailto:pjdoughe...@gmail.com> > wrote:

I did use the - -  dump command. But (a) I don’t know where it put the data, 
(b) how to recover it, or (c) does it need to even be recovered now?

 

- pjd

 

From: weewx-user@googlegroups.com <mailto:weewx-user@googlegroups.com>  
mailto:weewx-user@googlegroups.com> > On Behalf 
Of Tom Keffer
Sent: Monday, March 22, 2021 9:30 PM
To: weewx-user mailto:weewx-user@googlegroups.com> >
Subject: Re: [weewx-user] Not uploading to CWOP - still not working

 

If you did the "wee_device --dump" command as suggested by the Wiki, you should 
have recovered all the data off the logger.

 

If not, you can use wee_import 
<http://www.weewx.com/docs/utilities.htm#wee_import_utility>  to recover from 
the Weather Underground.

 

-- 
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 
<mailto:weewx-user+unsubscr...@googlegroups.com> .
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/062f01d71f87%2475641be0%24602c53a0%24%40gmail.com
 
<https://groups.google.com/d/msgid/weewx-user/062f01d71f87%2475641be0%24602c53a0%24%40gmail.com?utm_medium=email_source=footer>
 .

-- 
You received this message because you are subscribed to a topic in the Google 
Groups "weewx-user" group.
To unsubscribe from this topic, visit 
https://groups.google.com/d/topic/weewx-user/h0AhMSztDvI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to 
weewx-user+unsubscr...@googlegroups.com 
<mailto:weewx-user+unsubscr...@googlegroups.com> .
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/CAPq0zEC1-FaM%3D04BFBiNvZaxDO_HsZTyggCaMt-96_VAUfA9cQ%40mail.gmail.com
 
<https://groups.google.com/d/msgid/weewx-user/CAPq0zEC1-FaM%3D04BFBiNvZaxDO_HsZTyggCaMt-96_VAUfA9cQ%40mail.gmail.com?utm_medium=email_source=footer>
 .

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/064401d71f88%24c678ae50%24536a0af0%24%40gmail.com.

RE: [weewx-user] Not uploading to CWOP - still not working

[Peter Dougherty]

I did use the - -  dump command. But (a) I don’t know where it put the data, 
(b) how to recover it, or (c) does it need to even be recovered now?

 

- pjd

 

From: weewx-user@googlegroups.com  On Behalf Of 
Tom Keffer
Sent: Monday, March 22, 2021 9:30 PM
To: weewx-user 
Subject: Re: [weewx-user] Not uploading to CWOP - still not working

 

If you did the "wee_device --dump" command as suggested by the Wiki, you should 
have recovered all the data off the logger.

 

If not, you can use wee_import 
  to recover from 
the Weather Underground.

 

-- 
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/062f01d71f87%2475641be0%24602c53a0%24%40gmail.com.

RE: [weewx-user] Not uploading to CWOP (Long log file attached)

[Peter Dougherty]

So…a tiny bit of progress (maybe??)

I stopped the Vantage console for a few minutes and pulled out the batteries. 
Restarted it, then unplugged the RPi and reconnected it. It seems to have 
started adding the missing data and I’m seeing “restx” messages again, but 
after 10 minutes, nothing seems to actually have gotten posted to CWOP.

So I stopped Weewx and restarted it again, a few seconds before the 19:35EDT 
update time. Nothing seems to have gotten posted to CWOP, however; I have 
refreshed the page numerous times since.

Once again, there are no restx messages being displayed. Log follows:

Mar 22 19:12:01 wx weewx[3062]: vantage: LOOP try #1; error: Expected to read 
99 chars; got 0 instead
Mar 22 19:12:01 wx weewx[3062]: vantage: Requesting 200 LOOP packets.
Mar 22 19:12:05 wx weewx[3062]: vantage: retry  #0 failed
Mar 22 19:12:09 wx weewx[3062]: vantage: retry  #1 failed
Mar 22 19:12:13 wx weewx[3062]: vantage: retry  #2 failed
Mar 22 19:12:17 wx weewx[3062]: vantage: retry  #3 failed
Mar 22 19:12:17 wx weewx[3062]: vantage: Unable to wake up console
Mar 22 19:12:17 wx weewx[3062]: vantage: LOOP try #2; error: Unable to wake up 
Vantage console
Mar 22 19:12:17 wx weewx[3062]: vantage: Requesting 200 LOOP packets.
Mar 22 19:12:21 wx weewx[3062]: vantage: retry  #0 failed
Mar 22 19:12:25 wx weewx[3062]: vantage: retry  #1 failed
Mar 22 19:12:29 wx weewx[3062]: vantage: retry  #2 failed
Mar 22 19:12:33 wx weewx[3062]: vantage: retry  #3 failed
Mar 22 19:12:33 wx weewx[3062]: vantage: Unable to wake up console
Mar 22 19:12:33 wx weewx[3062]: vantage: LOOP try #3; error: Unable to wake up 
Vantage console
Mar 22 19:12:33 wx weewx[3062]: vantage: Requesting 200 LOOP packets.
Mar 22 19:12:37 wx weewx[3062]: vantage: retry  #0 failed
Mar 22 19:12:41 wx weewx[3062]: vantage: retry  #1 failed
Mar 22 19:12:45 wx weewx[3062]: vantage: retry  #2 failed
Mar 22 19:12:49 wx weewx[3062]: vantage: retry  #3 failed
Mar 22 19:12:49 wx weewx[3062]: vantage: Unable to wake up console
Mar 22 19:12:49 wx weewx[3062]: vantage: LOOP try #4; error: Unable to wake up 
Vantage console
Mar 22 19:12:49 wx weewx[3062]: vantage: LOOP max tries (4) exceeded.
Mar 22 19:12:49 wx weewx[3062]: engine: Main loop exiting. Shutting engine down.
Mar 22 19:12:49 wx weewx[3062]: engine: Shutting down StdReport thread
Mar 22 19:12:49 wx weewx[3062]: engine: StdReport thread has been terminated
Mar 22 19:12:49 wx weewx[3062]: restx: Shut down CWOP thread.
Mar 22 19:12:49 wx weewx[3062]: restx: Shut down PWSWeather thread.
Mar 22 19:12:49 wx weewx[3062]: restx: Shut down Wunderground-RF thread.
Mar 22 19:12:49 wx weewx[3062]: engine: Caught WeeWxIOError: Max tries exceeded 
while getting LOOP data.
Mar 22 19:12:49 wx weewx[3062]:   Waiting 60 seconds then retrying...
Mar 22 19:13:49 wx weewx[3062]: engine: retrying...
Mar 22 19:13:49 wx weewx[3062]: engine: Using configuration file 
/etc/weewx/weewx.conf
Mar 22 19:13:49 wx weewx[3062]: engine: Initializing engine
Mar 22 19:13:49 wx weewx[3062]: engine: Loading station type Vantage 
(weewx.drivers.vantage)
Mar 22 19:13:49 wx weewx[3062]: vantage: driver version is 3.0.9
Mar 22 19:13:49 wx weewx[3062]: vantage: Opened up serial port /dev/ttyUSB0; 
baud 19200; timeout 4.00
Mar 22 19:13:53 wx weewx[3062]: vantage: retry  #0 failed
Mar 22 19:13:57 wx weewx[3062]: vantage: retry  #1 failed
Mar 22 19:14:01 wx weewx[3062]: vantage: retry  #2 failed
Mar 22 19:14:05 wx weewx[3062]: vantage: retry  #3 failed
Mar 22 19:14:05 wx weewx[3062]: vantage: Unable to wake up console
Mar 22 19:14:05 wx weewx[3062]: import of driver failed: Unable to wake up 
Vantage console ()
Mar 22 19:14:05 wx weewx[3062]: engine: Unable to load driver: Unable to wake 
up Vantage console
Mar 22 19:14:05 wx weewx[3062]:   Exiting...
Mar 22 19:17:13 wx weewx[575]: Starting weewx weather system: weewxerror: 
unexpectedly disconnected from boot status daemon
Mar 22 19:17:16 wx weewx[784]: engine: Initializing weewx version 3.6.2
Mar 22 19:17:16 wx weewx[784]: engine: Using Python 2.7.9 (default, Sep 16 
2019, 18:29:54) #012[GCC 4.9.2]
Mar 22 19:17:16 wx weewx[784]: engine: Platform 
Linux-4.9.35-v7+-armv7l-with-debian-8.0
Mar 22 19:17:16 wx weewx[784]: engine: pid file is /var/run/weewx.pid
Mar 22 19:17:16 wx weewx[1053]: engine: Using configuration file 
/etc/weewx/weewx.conf
Mar 22 19:17:16 wx weewx[1053]: engine: Initializing engine
Mar 22 19:17:16 wx weewx[1053]: engine: Loading station type Vantage 
(weewx.drivers.vantage)
Mar 22 19:17:16 wx weewx[575]: .
Mar 22 19:17:16 wx weewx[1053]: vantage: driver version is 3.0.9
Mar 22 19:17:16 wx weewx[1053]: vantage: Opened up serial port /dev/ttyUSB0; 
baud 19200; timeout 4.00
Mar 22 19:17:16 wx weewx[1053]: vantage: gentle wake up of console successful
Mar 22 19:17:16 wx weewx[1053]: vantage: _setup; hardware type is 16
Mar 22 19:17:16 wx weewx[1053]: engine: Loading service 
weewx.engine.StdTimeSynch
Mar 22 19:17:16 wx weewx[1053]: engine: Finished loading service 

RE: [weewx-user] Not uploading to CWOP (continued from previous post)

[Peter Dougherty]

I will de-power the Vantage for 5 minutes and see what happens, and reboot the 
Raspberry Pi once the Vantage console is back on line.

 

- pjd

 

From: weewx-user@googlegroups.com  On Behalf Of 
Tom Keffer
Sent: Monday, March 22, 2021 7:08 PM
To: weewx-user 
Subject: Re: [weewx-user] Not uploading to CWOP (continued from previous post)

 

As suspected (and as I guessed in your original thread), you are using 
RapidFire. It uses LOOP packets, and so will be unaffected by a corrupt logger.

 

Again, as noted in the other thread, clear the logger 
<https://github.com/weewx/weewx/wiki/Troubleshooting-the-Davis-Vantage-station#corrupt-station-memory>
  and all will be well.

 

-tk

 

 

On Mon, Mar 22, 2021 at 4:05 PM Peter Dougherty mailto:pjdoughe...@gmail.com> > wrote:

OK, now that is bizarre. Why would it just suddenly disappear, I wonder? I will 
post over there but there’s gotta be more involved.

The end goal is to have the data not just posted to CWOP itself, but also 
disseminated to the APRS network.

 

- pjd

 

From: weewx-user@googlegroups.com <mailto:weewx-user@googlegroups.com>  
mailto:weewx-user@googlegroups.com> > On Behalf 
Of John Kline
Sent: Monday, March 22, 2021 7:01 PM
To: weewx-user@googlegroups.com <mailto:weewx-user@googlegroups.com> 
Subject: Re: [weewx-user] Not uploading to CWOP (continued from previous post)

 

I don’t see W2IRT listed here:

http://www.wxqa.com/members.txt

 

I’m not sure; but perhaps it is no longer registered?  A better place to ask 
that question (is it registered), is here:

https://www.wxforum.net/index.php?board=15.0

 

 

On Mar 22, 2021, at 3:38 PM, Peter Dougherty mailto:pjdoughe...@gmail.com> > wrote:

It occurred to me that you might also need to see the log from process start, 
so I stopped the service and restarted it, and have pasted the relevant portion 
of the log below. This is from within 3 minutes of my typing out this post.

 

Mar 22 18:34:16 wx weewx[2460]: engine: Received signal TERM.

Mar 22 18:34:16 wx weewx[2460]: engine: Main loop exiting. Shutting engine down.

Mar 22 18:34:16 wx weewx[2460]: engine: Shutting down StdReport thread

Mar 22 18:34:16 wx weewx[2460]: engine: StdReport thread has been terminated

Mar 22 18:34:16 wx weewx[2460]: restx: Shut down CWOP thread.

Mar 22 18:34:16 wx weewx[2460]: restx: Shut down PWSWeather thread.

Mar 22 18:34:16 wx weewx[2460]: restx: Shut down Wunderground-RF thread.

Mar 22 18:34:16 wx weewx[2460]: engine: Terminating weewx version 3.6.2

Mar 22 18:34:22 wx weewx[2980]: Stopping weewx weather system: weewx..

Mar 22 18:35:06 wx weewx[3058]: engine: Initializing weewx version 3.6.2

Mar 22 18:35:06 wx weewx[3058]: engine: Using Python 2.7.9 (default, Sep 16 
2019, 18:29:54) #012[GCC 4.9.2]

Mar 22 18:35:06 wx weewx[3058]: engine: Platform 
Linux-4.9.35-v7+-armv7l-with-debian-8.0

Mar 22 18:35:06 wx weewx[3058]: engine: pid file is /var/run/weewx.pid

Mar 22 18:35:06 wx weewx[3048]: Starting weewx weather system: weewx.

Mar 22 18:35:06 wx weewx[3062]: engine: Using configuration file 
/etc/weewx/weewx.conf

Mar 22 18:35:06 wx weewx[3062]: engine: Initializing engine

Mar 22 18:35:06 wx weewx[3062]: engine: Loading station type Vantage 
(weewx.drivers.vantage)

Mar 22 18:35:06 wx weewx[3062]: vantage: driver version is 3.0.9

Mar 22 18:35:06 wx weewx[3062]: vantage: Opened up serial port /dev/ttyUSB0; 
baud 19200; timeout 4.00

Mar 22 18:35:06 wx weewx[3062]: vantage: gentle wake up of console successful

Mar 22 18:35:06 wx weewx[3062]: vantage: _setup; hardware type is 16

Mar 22 18:35:06 wx weewx[3062]: engine: Loading service 
weewx.engine.StdTimeSynch

Mar 22 18:35:06 wx weewx[3062]: engine: Finished loading service 
weewx.engine.StdTimeSynch

Mar 22 18:35:06 wx weewx[3062]: engine: Loading service weewx.engine.StdConvert

Mar 22 18:35:06 wx weewx[3062]: engine: StdConvert target unit is 0x1

Mar 22 18:35:06 wx weewx[3062]: engine: Finished loading service 
weewx.engine.StdConvert

Mar 22 18:35:06 wx weewx[3062]: engine: Loading service 
weewx.engine.StdCalibrate

Mar 22 18:35:06 wx weewx[3062]: engine: Finished loading service 
weewx.engine.StdCalibrate

Mar 22 18:35:06 wx weewx[3062]: engine: Loading service weewx.engine.StdQC

Mar 22 18:35:06 wx weewx[3062]: engine: Finished loading service 
weewx.engine.StdQC

Mar 22 18:35:06 wx weewx[3062]: engine: Loading service 
weewx.wxservices.StdWXCalculate

Mar 22 18:35:06 wx weewx[3062]: wxcalculate: The following values will be 
calculated: barometer=prefer_hardware, windchill=prefer_hardware, 
dewpoint=prefer_hardware, appTemp=prefer_hardware, rainRate=prefer_hardware, 
windrun=prefer_hardware, heatindex=prefer_hardware, 
maxSolarRad=prefer_hardware, humidex=prefer_hardware, pressure=prefer_hardware, 
inDewpoint=prefer_hardware, ET=prefer_hardware, altimeter=prefer_hardware, 
cloudbase=prefer_hardware

Mar 22 18:35:06 wx weewx[3062]: wxcalculate: The following algorithms will be 
use