[weewx-user] Re: Shutdown of Tempest-dataflow & display

[gjr80]

Further to what Vince said, WeeWX runs the report generator and 
re-generates reports when a new archive record arrives. When using software 
record generation (as I understand is the case with the Weatherflow UDP 
driver) WeeWX synthesises a new archive record when an out-of-archive 
period loop packet arrives from the driver - if no loop packets arrive from 
the driver then no archive records are generated and no reports are 
generated. This may give the appearance that WeeWX is 'frozen', but I think 
this is better characterised as the 'station' is frozen; WeeWX is still 
running just sitting waiting for loop packets. A characteristic of this 
situation, if using one of the included skins, is that the date-time 
displayed on, say, the Seasons home page and included plots does not 
change. This situation is usually very apparent when you look at the log, 
there will be little or no activity and certainly no report cycles 
appearing in the log. 

If a driver emits loop packets that contain no observational data then 
WeeWX will generate archive records, albeit lacking in observational data, 
which in turn causes reports to be updated. In this case date-times on the 
likes of the Seasons home page and plots will update, but the displayed 
data may be stale or N/A. Usually not so obvious in the logs as everything 
is working, it's just that no data is being presented to WeeWX (actually 
depending on the extent of driver's debug output the lack of data from the 
driver may or may not be evident in the log).

Gary

On Friday, 10 June 2022 at 09:07:10 UTC+10 vince wrote:

> On Thursday, June 9, 2022 at 10:46:04 AM UTC-7 ton...@gmail.com wrote:
>
>> is it correct observation that when an interface-driver of WeeWX has no 
>> inputs with changing time-validity, then all subsequent dataflows also stop 
>> & freeze?
>>
>> If the hub is emitting no data, weewx has no data to process so I would 
> expect it to show NA and nothing on the graphs.
>
> We cannot help without seeing actual data.
>
>- https://github.com/weewx/weewx/wiki/faq-how-to-report-a-problem
>
> For a WeatherFlow system, always check 'their' server to see if there is 
> any data there.  The red light means your hub lost the wifi connection 
> according to a quick search of the WeatherFlow forums (link) 
> .
>  
>  Did you possibly change something in your network or firewall 
> configuration on your LAN ?
>
> The problem is almost certainly with your Hub, not weewx or Domoticz or 
> WeatherDisplay or any other add-on software.
>
>
>

-- 
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/919dda8b-d4c3-4d38-99af-d76040a52682n%40googlegroups.com.

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

[gjr80]

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/fe088665-ed01-4dde-9558-8578a86b53f8n%40googlegroups.com.

[weewx-user] Re: Tried installation using Raspbian Bullseye on an RPi4

[mup...@gmail.com]

I am pleased to say that my station is once again reporting as it used to.  
It did seem to take an extra bit of time to get everything recognized by 
WxUnderground, but the wait was worth it.
Thanks to all for your input and patience.

Regards,
Michael
K6MLE

On Thursday, June 9, 2022 at 4:30:44 PM UTC-7 mup...@gmail.com wrote:

>
> Just took an installation that used the deb file and changed the 
> /etc/weewx/weewx.conf to reflect /dev/ttyS0.
> I no longer get the data spitting out to the console as before.
> What I do see is lots of data coming out of sudo tail -f /var/log/syslog.
> That seems like it might be a 'good thing'?I've not yet seen my 
> posting to Weatherunderground at KCAPLACE82.
> Perhaps I need to wait a while?  It's been offline for about 3 weeks.
> Thanks for coming back to me!
>
> Michael
> On Thursday, June 9, 2022 at 3:56:23 PM UTC-7 vince wrote:
>
>> I thought you told me via email that things worked when you used 
>> /dev/ttyS0 ?
>>
>> Perhaps you might capture the "bunch of data being spit out" and share it 
>> with us, because it sure sounds like it's working as expected.
>>
>>
>> On Thursday, June 9, 2022 at 2:43:15 PM UTC-7 mup...@gmail.com wrote:
>>
>>> Update:
>>> I am becoming more certain that the issue I'm having is with the ability 
>>> to get the serial ports configured properly on a Pi 4.
>>> Any recommendations would be welcomed.
>>> Thank you!
>>> Michael
>>>
>>> On Wednesday, June 8, 2022 at 12:31:27 PM UTC-7 mup...@gmail.com wrote:
>>>
 Meant to post this to all!
 Got through the installation process and populated my info in the 
 weewx.conf file.  The issue now appears to be one with the serial port 
 selection.
 Using /dev/ttyS0, the result is a bunch of data being spit out to my 
 screen, which doesn't appear to be where it should go.

>>>

-- 
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/07577cc8-62cc-4d43-b038-1fdc11904606n%40googlegroups.com.

[weewx-user] Re: Tried installation using Raspbian Bullseye on an RPi4

[mup...@gmail.com]

Just took an installation that used the deb file and changed the 
/etc/weewx/weewx.conf to reflect /dev/ttyS0.
I no longer get the data spitting out to the console as before.
What I do see is lots of data coming out of sudo tail -f /var/log/syslog.
That seems like it might be a 'good thing'?I've not yet seen my posting 
to Weatherunderground at KCAPLACE82.
Perhaps I need to wait a while?  It's been offline for about 3 weeks.
Thanks for coming back to me!

Michael
On Thursday, June 9, 2022 at 3:56:23 PM UTC-7 vince wrote:

> I thought you told me via email that things worked when you used 
> /dev/ttyS0 ?
>
> Perhaps you might capture the "bunch of data being spit out" and share it 
> with us, because it sure sounds like it's working as expected.
>
>
> On Thursday, June 9, 2022 at 2:43:15 PM UTC-7 mup...@gmail.com wrote:
>
>> Update:
>> I am becoming more certain that the issue I'm having is with the ability 
>> to get the serial ports configured properly on a Pi 4.
>> Any recommendations would be welcomed.
>> Thank you!
>> Michael
>>
>> On Wednesday, June 8, 2022 at 12:31:27 PM UTC-7 mup...@gmail.com wrote:
>>
>>> Meant to post this to all!
>>> Got through the installation process and populated my info in the 
>>> weewx.conf file.  The issue now appears to be one with the serial port 
>>> selection.
>>> Using /dev/ttyS0, the result is a bunch of data being spit out to my 
>>> screen, which doesn't appear to be where it should go.
>>>
>>

-- 
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/fa924d6b-3d68-4cb3-a803-545de9d7d502n%40googlegroups.com.

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

[Glenn McKechnie]

On 10/06/2022, 'Peter Fletcher' via weewx-user
 wrote:
> 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.

If you are using StdService then config_dict is available.

In UradMon I've used that to fetch the default value along the lines of

sf_int = to_int(config_dict['StdArchive'].get('archive_interval', 300))

Full code from line 292. Adjust to fit.

(Hopefully the following link can be recreated if it gets mangled)

https://github.com/glennmckechnie/weewx-uradmon/blob/73fc63371944d3b5480c1cca0e9fa35feb68c649/bin/user/uradmon.py#L292


-- 


Cheers
 Glenn

rorpi - read only raspberry pi & various weewx addons
https://github.com/glennmckechnie

-- 
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/CAAraAzjkt63QnVF%3D-5cu6z_bS%2BKP03P74LpKwLGAXdK6X8gmoQ%40mail.gmail.com.

[weewx-user] Re: Shutdown of Tempest-dataflow & display

[vince]

On Thursday, June 9, 2022 at 10:46:04 AM UTC-7 ton...@gmail.com wrote:

> is it correct observation that when an interface-driver of WeeWX has no 
> inputs with changing time-validity, then all subsequent dataflows also stop 
> & freeze?
>
> If the hub is emitting no data, weewx has no data to process so I would 
expect it to show NA and nothing on the graphs.

We cannot help without seeing actual data.

   - https://github.com/weewx/weewx/wiki/faq-how-to-report-a-problem
   
For a WeatherFlow system, always check 'their' server to see if there is 
any data there.  The red light means your hub lost the wifi connection 
according to a quick search of the WeatherFlow forums (link) 
.
 
 Did you possibly change something in your network or firewall 
configuration on your LAN ?

The problem is almost certainly with your Hub, not weewx or Domoticz or 
WeatherDisplay or any other add-on software.


-- 
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/b51ea02d-306a-4230-862f-78f1d0452f15n%40googlegroups.com.

[weewx-user] Re: Tried installation using Raspbian Bullseye on an RPi4

[vince]

I thought you told me via email that things worked when you used /dev/ttyS0 
?

Perhaps you might capture the "bunch of data being spit out" and share it 
with us, because it sure sounds like it's working as expected.


On Thursday, June 9, 2022 at 2:43:15 PM UTC-7 mup...@gmail.com wrote:

> Update:
> I am becoming more certain that the issue I'm having is with the ability 
> to get the serial ports configured properly on a Pi 4.
> Any recommendations would be welcomed.
> Thank you!
> Michael
>
> On Wednesday, June 8, 2022 at 12:31:27 PM UTC-7 mup...@gmail.com wrote:
>
>> Meant to post this to all!
>> Got through the installation process and populated my info in the 
>> weewx.conf file.  The issue now appears to be one with the serial port 
>> selection.
>> Using /dev/ttyS0, the result is a bunch of data being spit out to my 
>> screen, which doesn't appear to be where it should go.
>>
>

-- 
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/d1f21446-fa6e-4d51-933a-94370f3f0a3en%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
>  
> 
> .
>
>

-- 
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: Tried installation using Raspbian Bullseye on an RPi4

[mup...@gmail.com]

Update:
I am becoming more certain that the issue I'm having is with the ability to 
get the serial ports configured properly on a Pi 4.
Any recommendations would be welcomed.
Thank you!
Michael

On Wednesday, June 8, 2022 at 12:31:27 PM UTC-7 mup...@gmail.com wrote:

> Meant to post this to all!
> Got through the installation process and populated my info in the 
> weewx.conf file.  The issue now appears to be one with the serial port 
> selection.
> Using /dev/ttyS0, the result is a bunch of data being spit out to my 
> screen, which doesn't appear to be where it should go.
> Using /dev/ttyAMA0 locks up the terminal window!
> The output from dmesg is:
> dmesg | grep tty
> [0.00] Kernel command line: coherent_pool=1M 8250.nr_uarts=1 
> snd_bcm2835.enable_compat_alsa=0 snd_bcm2835.enable_hdmi=1 
>  smsc95xx.macaddr=DC:A6:32:93:DF:F3 vc_mem.mem_base=0x3ec0 
> vc_mem.mem_size=0x4000  console=tty1 root=PARTUUID=6eead863-02 
> rootfstype=ext4 fsck.repair=yes rootwait quiet splash 
> plymouth.ignore-serial-consoles
> [0.000359] printk: console [tty1] enabled
> [1.410360] fe201000.serial: ttyAMA0 at MMIO 0xfe201000 (irq = 34, 
> base_baud = 0) is a PL011 rev2
> [1.419455] fe215040.serial: ttyS0 at MMIO 0xfe215040 (irq = 36, 
> base_baud = 6250) is a 16550
> [3.091117] systemd[1]: Created slice system-getty.slice.
>
> --
> The connection being used is the same from my previous install (original 
> RPi), which uses a MAX3232 IC tied to GPIO pins 8 & 10.  Might there be a 
> permissions issue?  Not sure where to look for a solution at this point.
> Another note ... in the previous installation, I found a recommendation 
> that said to purge the hwclock from the system.  Is this still applicable?
>
> Thank you all!
> On Wednesday, June 8, 2022 at 11:24:09 AM UTC-7 vince wrote:
>
>> The instructions are actually ok as written, as there is no right/wrong 
>> rule for where to download/expand the .tar.gz file into.  FWIW -  typically 
>> I use /var/tmp when I do it, but there is no right or wrong answer there.
>>
>> In your case, I suspect you simply neglected to 'cd /home/weewx' in 
>> step-4 before running the sudo command.   You need to be in the 'installed' 
>> location when you run the sudo command, not the 'source' directory your 
>> .tar.gz file expanded into.
>>
>>
>>
>>

-- 
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/a3eec51f-a129-4071-a1a7-5605f2981ed0n%40googlegroups.com.

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

['Rainer Lang' via weewx-user]

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


--
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/f60ceaba-c3e0-fb62-b245-aa8427d312e7%40gmail.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] Re: Belchertown Charts Color

[Schnidrig Stefan]

HelloThank you very much. It works. The standart is 30 ms, when the intervall is 5minutes. I have 10minutes, also 60ms. ThxHolen Sie sich Outlook für Android



-- 
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/A0445B7E-E7E8-524E-AEF0-1470058F35A3%40hxcore.ol.

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

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

[weewx-user] Re: Shutdown of Tempest-dataflow & display

[Ton vanN]

Additional info.
WeatherDisplay parallel reading output from the Tempest-hub, same as 
Domoticz reports fixed values since that time, also with actual time-stamp, 
not the 'freezing' as for WeeWX.

Op donderdag 9 juni 2022 om 19:46:04 UTC+2 schreef Ton vanN:

> Some 24 hours ago I observed a 'freezing' of the WeeWX-picture at 
> https://vannwnhzn.nl/WeeWX0/index.html
> Still continues.
>
> First thought is that upload for the html-file has stopped.
> Because for upload using the FTP-function in WeeWX, implicitly it means 
> that WeeWX has to be checked.
> Observation in WeeWX is that all files of WeeWX still get actual 
> datestamp, but contents have completely been frozen on approx. June 8th, 
> 16:25
> Restart of WeeWX (regardless of route) has no effects: no further visible 
> processing.
>
> This afternoon (as second thought) the penny dropped that this was also 
> the time that Weatherflow_Tempest as datafeeding sensor through UDP went on 
> strike:
> Tempest hub shows red light, meaning that the dataflow from the sensor (or 
> the hub itself) has problems.
> Also see at the Weatherflow-server that data & display has been frozen at 
> the time mentioned above.
> Locally in Domoticz I see that since that time the data from the 
> UDP-sniffer is also solid as a rock.
> Hard reset of the Tempest hub has no effect.
>
> *Question:*
> is it correct observation that when an interface-driver of WeeWX has no 
> inputs with changing time-validity, then all subsequent dataflows also stop 
> & freeze?
> *Or* is this apparently simultaneous event just an unhappy coincidence? 
> *Or* some aspects specific for the Tempest hub & interface-driver? 
>

-- 
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/7e792e16-03e4-486d-b2db-a6ad16b7e2a9n%40googlegroups.com.

[weewx-user] Shutdown of Tempest-dataflow & display

[Anton vanNwnhzn@GMail]

Some 24 hours ago I observed a 'freezing' of the WeeWX-picture at 
https://vannwnhzn.nl/WeeWX0/index.html

Still continues.

First thought is that upload for the html-file has stopped.
Because for upload using the FTP-function in WeeWX, implicitly it means 
that WeeWX has to be checked.
Observation in WeeWX is that all files of WeeWX still get actual 
datestamp, but contents have completely been frozen on approx. June 8th, 
16:25
Restart of WeeWX (regardless of route) has no effects: no further 
visible processing.


This afternoon (as second thought) the penny dropped that this was also 
the time that Weatherflow_Tempest as datafeeding sensor through UDP went 
on strike:
Tempest hub shows red light, meaning that the dataflow from the sensor 
(or the hub itself) has problems.
Also see at the Weatherflow-server that data & display has been frozen 
at the time mentioned above.
Locally in Domoticz I see that since that time the data from the 
UDP-sniffer is also solid as a rock.

Hard reset of the Tempest hub has no effect.

*_Question:_*
is it correct observation that when an interface-driver of WeeWX has no 
inputs with changing time-validity, then all subsequent dataflows also 
stop & freeze?

*_Or_* is this apparently simultaneous event just an unhappy coincidence?
*_Or_* some aspects specific for the Tempest hub & interface-driver?

--
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/34d0e582-ece0-3fcd-8c08-489a05700243%40gmail.com.

[weewx-user] Re: Installing WS 6in1 for Bresser 5-in1

[Bob Atchley]

Hi Weewx-user,

line 369 is simply an import of crcmod.  It has failed showing that the 
crcmod library is not available for python to use.
You need to follow the readme, but maybe there are complications caused by 
Arch Linux (?)

pip3 install crcmod
sudo apt install python3-crcmod   [or the pacman equivalent]

If that still doesn't work you could try running the pip3 command with sudo.

Hope that helps

Bob

On Thursday, 9 June 2022 at 11:55:43 UTC+1 Ξ wrote:

> is there a way to test crcmod some other way to confirm it's running and 
> installed properly?
>

-- 
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/f3be5de1-a401-4d49-8abf-4a7cbf7e3671n%40googlegroups.com.

Re: [weewx-user] Re: Adding lightening sensor to weewx

[Greg Troxel]

I am monitoring acurite strike data (6045M with rtl_433 not weewx).

One tricky thing about acurite is that strike count

  1) is a cumulative count of strikes, so it needs differencing if you
  want strikes in some interval.  Presumably that's the count in the
  archive interval for weewx.

  2) rolls over from 255 to 0, so you also need to undo that if you want
  cumulative count as a number.  Then you need to figure out when you do
  want to reset it, or how you want to deal with that, because the
  un-wrapped value will increase without bound.  But it will likely not
  overflow an int32_t in your lifetime.  I'm really unclear on how
  people deal with this issue.

and then as your code indicates, distance is only valid in a
transmission where count has increased from the previous transmission.
That's complicated because if you miss a transmssion where it
increments, you miss it, but it seems the next one you will perceive the
incremented count and the distance will still be the same.

Hope this helps more than it is confounding.

  

-- 
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/rmih74tzynt.fsf%40s1.lexort.com.


signature.asc
Description: PGP signature

Re: [weewx-user] Re: Adding lightening sensor to weewx

[Andy]

I have tried to get this to work with varying degrees of success. We seldom 
have lightning which makes troubleshooting more involved.

###
Comparing the raw output of your sdr driver (sdr.txt) with your sensor map 
in the first post, this looks correct. 

lightning_distance = *strike_distance.0010.AcuriteAtlasPacket*
lightning_strike_count = *strike_count.0010.AcuriteAtlasPacket*

parsed: {'dateTime': 1654733294, 'usUnits': 1, 
'model.0010.AcuriteAtlasPacket': 'Acurite-Atlas', 
'channel.0010.AcuriteAtlasPacket': 'A', 
'sequence_num.0010.AcuriteAtlasPacket': 2, 
'message_type.0010.AcuriteAtlasPacket': 39, '
*strike_count.0010.AcuriteAtlasPacket*': 27, '
*strike_distance.0010.AcuriteAtlasPacket*': 7, 
'wind_speed.0010.AcuriteAtlasPacket': 8.0, 'uv.0010.AcuriteAtlasPacket': 1, 
'lux.0010.AcuriteAtlasPacket': 45660, 'battery.0010.AcuriteAtlasPacket': 0}

###
And from the weewx log, we have a delta, which looks a bit odd:

INFO user.sdr: deltas is {'rain': 'rain_total', 'lightning_strike_count': 
'lightning_strike_count'}

Reading here  adds 
some background.

This is what I have, it may not be correct:

INFO user.sdr: deltas is {'lightning_strike_count': 'strikes_total', 
'rain': 'rain_total'}

lightning_distance = distance.3C47.AcuriteLightningPacket
strikes_total = strikes_total.3C47.AcuriteLightningPacket

[StdCalibrate]

[[Corrections]]

#lightning_distance = lightning_distance if lightning_strike_count 
> 0 else None
lightning_distance = None if lightning_strike_count == 0 or 
lightning_strike_count is None else lightning_distance

[Accumulator]
[[lightning_strike_count]]
extractor = sum
[[lightning_distance]]
extractor = min
merger = minmax

[image: Screenshot_2022-06-09_06-42-31.png]
[image: Screenshot_2022-06-09_07-28-30.png]


root@debian:/home/weewx/skins/Seasons# sqlite3 
/home/weewx/archive/weewx.sdb -header -column "select dateTime, 
lightning_distance, lightning_strike_count from archive where 
lightning_strike_count > 0 ORDER BY dateTime DESC LIMIT 10 ;" 
dateTimelightning_distance  lightning_strike_count
--  --  --
1654476300  28.01.0   
1654434900  28.039.0  
1654325400  28.0128.0 
1653567000  28.039.0  
1653128100  28.01.0   
1653127800  28.01.0   
1653095100  28.01.0   
1652670600  0.0 128.0 
165700  28.01.0   
1652220600  15.02.0 

Andy

On Wednesday, June 8, 2022 at 5:49:17 PM UTC-7 dave.sp...@gmail.com wrote:

> Thanks for all the info you provided below, but I am still stumped. I only 
> have one the Acurite Atlas with lightning detector and BME280. Might be 
> thinking that my RTL-SDR is picking up other weather stations nearby.
>
>  
>
> I have attached separate files showing that the lightning distance and 
> count that there is data there. 
>
>  
>
> MySQL even shows that the data is there.
>
>  
>
>  
>
> But the issue is on the website. There is no graph/data show lightning 
> distance and strike count. Here is what the website is showing. 
>
>  
>
>  
>
>  
>
>  
>
> Any other ideas on what could be going on?
>
>  
>
> Thanks
>
> Dave
>
>  
>
>  
>
> *From:* weewx...@googlegroups.com  *On Behalf 
> Of *gjr80
> *Sent:* Tuesday, June 7, 2022 9:41 PM
> *To:* weewx-user 
> *Subject:* Re: [weewx-user] Re: Adding lightening sensor to weewx
>
>  
>
> Dave,
>
>  
>
> Thanks, the log is great resource for troubleshooting; if you include the 
> WeeWX startup portion of the log it provides detail on how WeeWX is 
> configured and if you have debug set high enough you get a good picture of 
> what is going on. The log is the first place to look when things don't work.
>
>  
>
> It looks like the SDR driver is not being fed any data from rtl_433 that 
> contains lightning related data. Your sensor map maps fields from 
> AcuriteAtlasPacket packets (which appears to be correct) and correctly 
> sets up lightning_strike_count as a delta:
>
>  
>
> Jun  7 16:14:29 raspberrypi weewx[25278] INFO user.sdr: sensor map is 
> {'outTemp': 'temperature.0010.AcuriteAtlasPacket', 'outHumidity': 
> 'humidity.0010.AcuriteAtlasPacket', 'windSpeed': 
> 'wind_speed.0010.AcuriteAtlasPacket', 'windDir': 
> 'wind_dir.0010.AcuriteAtlasPacket', 'UV': 'uv.0010.AcuriteAtlasPacket', 
> 'rain_total': 'rain_total.0010.AcuriteAtlasPacket', 'radiation': 
> 'lux.0010.AcuriteAtlasPacket', 'outTempBatteryStatus': 
> 'battery.0010.AcuriteAtlasPacket', 'lightning_distance': 
> 'strike_distance.0010.AcuriteAtlasPacket', 'lightning_strike_count': 
> 'strike_count.0010.AcuriteAtlasPacket', 'luminosity': 
> 'lux.0010.AcuriteAtlasPacket'}
> Jun  7 16:14:29 

Re: [weewx-user] Re: altitude for barometer calibration

[Greg Troxel]

"gszla...@gmail.com"  writes:

> If you are comparing your external sensors to your console's barometer keep 
> in mind that the offset does not mean the sensor is out-of-spec. An 
> absolute offset is not a specification. It is just the sensor correction 
> offset so that all your barometers read the same absolute pressure. I am 
> assuming you using the console as your reference and you have calibrated it 
> with a close-by airport using METAR or mesowest readings or equivalent.

What I have done so far is that I entered an elevation that I knew was
very approximate, and watched the barometric pressure compared to
official readings at airports around me, and on days when the pressure
was steady and similar adjusted by elevation (because that's all you can
do on VP2 console) to get a matching value.  I knew that was bogus
because it's doing station pressure calibration by having the wrong
altitude, but it got me decent values.

However what I should be doing is having a calibration offset for
station pressure, and then using the correct altitude (which I now
know).  The pressure sensor has some spec, and if the calibration
magnitude is higher than that, then yes the device doesn't meet spec.
The VP2 is specified to +/- 1.0 hPa.  If the calibration offset were 1.5
hPa, then it would be out of spec.  But my best guess this minute is
that I need to add 0.1 hPa to the station pressure to get the true
value.

> To answer your question if QNH = Altimeter? Altimeter includes a landing 
> gear offset of 10 feet = 0.3mb/.01 inHg. I believe that QNH does not have 
> that peculiar offset. Although most sources equate the two, I think the 
> equations are different.

Interesting.  I'll try to understand this better, but I suspect that the
altimeter pressure used by CWOP (US again) and calculated by weewx does
not have this offset.

> Lastly you were asking about different definitions of SLP?

No, I was asking "what does sea level mean, when weather people say
'pressure reduced to sea level'".   How to reduce from a known elevation
is less confusing.

> It is easy to get confused here because it is confusing.

Yes, and particularly because height and sea level are both very
difficult subjects if you want to get them right.

> I know of at least 6 different equations for Altimeter and there might be 
> dozens of different country-specific equations for (M)SLP.
> To make things more interesting both Altimeter and (M)SLP can be referred 
> to as "SLP".as both are reduced to sea level elevation.

They are, but in US usage "Sea Level Pressure" means "barometric
pressure" meaning a reduction equation that uses temperature.

> As you are aware, if you hook up your console to WeeWX, WeeWX will 
> automatically calculate Altimeter and (M)SLP using the proper algorithms. 
> Need to adjust the current algorithm for your region?  You can modify it.

Sure, but with VP2 it defaults to using hardware calculation for
barometric pressure.  I thought station pressure was also hardware, but
https://www.weewx.com/docs/hardware.htm#vantage_notes says S.  That may
be the next missing link in my understanding.

-- 
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/rmik09q10hk.fsf%40s1.lexort.com.


signature.asc
Description: PGP signature

[weewx-user] Re: Installing WS 6in1 for Bresser 5-in1

[Ξ]

is there a way to test crcmod some other way to confirm it's running and 
installed properly?

-- 
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/49abe8e7-7d0a-400c-b82f-9799cf20d566n%40googlegroups.com.

[weewx-user] Re: Installing WS 6in1 for Bresser 5-in1

[Ξ]

so I've tried running --reconfigure after installing 4.8.0 but I still get 
this message:

Indicate the preferred units for display: ['us', 'metric', 'metricwx']
unit system [us]: metricwx

Installed drivers include:
  0) ?   (user.ws6in1) No module named 'crcmod'
  1) AcuRite (weewx.drivers.acurite)
  2) ?   (weewx.drivers.cc3000)No module named 'serial'
  3) FineOffsetUSB   (weewx.drivers.fousb)
  4) Simulator   (weewx.drivers.simulator)
  5) TE923   (weewx.drivers.te923)
  6) ?   (weewx.drivers.ultimeter) No module named 'serial'
  7) Vantage (weewx.drivers.vantage)
  8) WMR100  (weewx.drivers.wmr100)
  9) WMR300  (weewx.drivers.wmr300)
 10) ?   (weewx.drivers.wmr9x8)No module named 'serial'
 11) WS1 (weewx.drivers.ws1)
 12) WS23xx  (weewx.drivers.ws23xx)
 13) WS28xx  (weewx.drivers.ws28xx)
choose a driver [4]: 0
Traceback (most recent call last):
  File "./wee_config", line 128, in 
main()
  File "./wee_config", line 122, in main
config_mgr.run(args, options)
  File "/home/weewx/bin/weecfg/config.py", line 123, in run
stn_info = self.get_stn_info(config_dict, options)
  File "/home/weewx/bin/weecfg/config.py", line 164, in get_stn_info
stn_info.update(weecfg.prompt_for_driver_settings(driver, config_dict))
  File "/home/weewx/bin/weecfg/__init__.py", line 1630, in 
prompt_for_driver_settings
__import__(driver)
  File "/home/weewx/bin/user/ws6in1.py", line 369, in 
import crcmod
ModuleNotFoundError: No module named 'crcmod'


How do I 'help' it recognise the fact that crcmod is there and installed? I 
installed 4.8.0 by running the command with python3
[root@alarmpi weewx-4.8.0]# python3 ./setup.py install
running install
running build
running build_py
running build_scripts
[...]


-- 
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/264bddc6-ef96-4e36-ac70-724cbc406951n%40googlegroups.com.

Re: [weewx-user] Re: Belchertown Charts Color

[Karen K]

Then, gapSize is your friend.

Meteo Oberwallis schrieb am Donnerstag, 9. Juni 2022 um 09:58:15 UTC+2:

> Hello.
> Thx for the reponse. The database is correct. When i go with the Mouse 
> over the Grafik, i can see the datapoint. 
>
> Holen Sie sich Outlook für Android 
>

-- 
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/3be25208-d673-4384-89dd-eea5f7048253n%40googlegroups.com.

[weewx-user] Re: Installing WS 6in1 for Bresser 5-in1

[Ξ]

Heya Bob,

I wanted to avoid new installation but I guess I have not many options 
here. I did install python-crcmod but I saw it's in the python3 directory 
and I've configured during install weewx to use python2.
As for Arch Linux, they dropped in March support for armv6 but luckily 
there's still a backup of the old/official repositories.

I'll try to install the latest version of weewx and see how it goes.

Thanks for the input!

-- 
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/015f-4b2b-4ad6-b6e0-28c5d71d99fan%40googlegroups.com.

Re: [weewx-user] Re: Belchertown Charts Color

[Schnidrig Stefan]

Hello.Thx for the reponse. The database is correct. When i go with the Mouse over the Grafik, i can see the datapoint. Holen Sie sich Outlook für Android



-- 
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/97B5F2FA-8673-9D4B-905B-9CDABE7268E3%40hxcore.ol.

[weewx-user] Re: Belchertown Charts Color

[Karen K]

It could be a problem of gap configuration. I would try to set gapSize to a 
higher value. If that helps, the real reason behind the scenes can be, that 
data is missing in the database.

Meteo Oberwallis schrieb am Donnerstag, 9. Juni 2022 um 08:30:33 UTC+2:

> Good Morning.
>
> I have a Problem with the Chart Color. The Charts Line is away. See here:
> [image: Unbenannt.JPG]
> I have weewx Version: 
>
>- Programm version: 3.9.2
>- Skin Version: 1.0.1
>
> Can i help me? This all happened a few days ago without making any changes.
>
> Thx for 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/cbf28f5a-53a0-4d08-921a-c477bc0a7543n%40googlegroups.com.

[weewx-user] Belchertown Charts Color

[Meteo Oberwallis]

Good Morning.

I have a Problem with the Chart Color. The Charts Line is away. See here:
[image: Unbenannt.JPG]
I have weewx Version: 
- Programm version: 3.9.2
- Skin Version: 1.0.1
Can i help me? This all happened a few days ago without making any changes.

Thx for 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/6ca12f82-7c97-427f-836e-b62906742029n%40googlegroups.com.