[weewx-user] New Weewx Extension - zbx-sender (send data to zabbix)

[HoracioDos]

Hello!
For those who might be interested in zabbix. I created a new weewx 
extension to send weather data to zabbix with some new features like: 
unit_system, record or archive data and data formating. 
https://github.com/HoracioDos/weewx-zbxsender

It is based on zabbix extension already made by Marc Pignat and the Aprx 
extension by Gary Roderick. Thank you both for sharing your weewx 
extensions.





-- 
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/0f6a67cb-3b5a-41cb-99ac-239741f859a8n%40googlegroups.com.

[weewx-user] Re: LinuxMint

[vince]

One thing to check for - if your Hub is on a different subnet than your 
weewx system, that's not going to work because broadcasts don't route.  You 
need both computers on the same broadcast domain (network).

On Friday, July 1, 2022 at 2:29:21 PM UTC-7 oha...@gmail.com wrote:

> Okay, guess I will need to head to a Linux Mint group to see what is 
> blocking It. Thanks
>
>
> On Friday, July 1, 2022 at 4:24:59 PM UTC-5 vince wrote:
>
>> If my listener doesn't hear anything, weewx won't either.
>
>

-- 
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/f912da6b-075b-4efd-87e9-285d872fceecn%40googlegroups.com.

[weewx-user] Re: LinuxMint

[Oren Haydel III]

Okay, guess I will need to head to a Linux Mint group to see what is 
blocking It. Thanks


On Friday, July 1, 2022 at 4:24:59 PM UTC-5 vince wrote:

> If my listener doesn't hear anything, weewx won't either.

-- 
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/030ba422-7abf-4c12-913b-5ea30a765b5bn%40googlegroups.com.

[weewx-user] Re: LinuxMint

[vince]

If my listener doesn't hear anything, weewx won't either.

-- 
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/c1c06a99-8227-4929-a813-cd3403ef8396n%40googlegroups.com.

[weewx-user] Re: LinuxMint

[Oren Haydel III]

Thanks Vince,

Yes I am using a WeatherFlow Tempest.  I am running Linux Mint on a 
dedicated PC that is connected via WiFi to my home network.  I tried 
running your listener, but nothing displayed.  Here is a copy of a snippet 
of my logs.  I hadn't left the firewall off for an hour, so I am waiting to 
see if it starts decoding again.  Like I said before, when I initally 
changed it to DMZ, it started working briefly then Stopped.

Jul  1 15:30:37 HAYDEL-MINT weewx[1913] INFO weewx.manager: Added record 
2022-07-01 15:30:00 CDT (1656707400) to database 'weewx.sdb'
Jul  1 15:30:37 HAYDEL-MINT weewx[1913] INFO weewx.manager: Added record 
2022-07-01 15:30:00 CDT (1656707400) to daily summary in 'weewx.sdb'
Jul  1 15:30:37 HAYDEL-MINT weewx[1913] DEBUG weewx.reportengine: Running 
reports for latest time in the database.
Jul  1 15:30:37 HAYDEL-MINT weewx[1913] DEBUG weewx.reportengine: Running 
report 'SeasonsReport'
Jul  1 15:30:37 HAYDEL-MINT /weewxd: weatherflowudp: MainThread: Listening 
for UDP broadcasts to IP address  on port 50222, with timeout 90 
and share_socket True...
Jul  1 15:30:37 HAYDEL-MINT weewx[1913] DEBUG weewx.reportengine: Found 
configuration file /etc/weewx/skins/Seasons/skin.conf for report 
'SeasonsReport'
Jul  1 15:30:37 HAYDEL-MINT systemd[1]: Started Run anacron jobs.
Jul  1 15:30:37 HAYDEL-MINT anacron[2861]: Anacron 2.3 started on 2022-07-01
Jul  1 15:30:37 HAYDEL-MINT systemd[1]: anacron.service: Succeeded.
Jul  1 15:30:37 HAYDEL-MINT anacron[2861]: Normal exit (0 jobs run)
Jul  1 15:30:37 HAYDEL-MINT weewx[1913] DEBUG weewx.cheetahgenerator: Using 
search list ['weewx.cheetahgenerator.Almanac', 
'weewx.cheetahgenerator.Current', 'weewx.cheetahgenerator.DisplayOptions', 
'weewx.cheetahgenerator.Extras', 'weewx.cheetahgenerator.Gettext', 
'weewx.cheetahgenerator.JSONHelpers', 'weewx.cheetahgenerator.PlotInfo', 
'weewx.cheetahgenerator.SkinInfo', 'weewx.cheetahgenerator.Station', 
'weewx.cheetahgenerator.Stats', 'weewx.cheetahgenerator.UnitInfo']
Jul  1 15:30:37 HAYDEL-MINT weewx[1913] DEBUG weewx.manager: Daily summary 
version is 4.0
Jul  1 15:30:37 HAYDEL-MINT weewx[1913] DEBUG weewx.restx: CWOP: Connected 
to server cwop.aprs.net:14580
Jul  1 15:30:37 HAYDEL-MINT weewx[1913] INFO weewx.restx: CWOP: Published 
record 2022-07-01 15:30:00 CDT (1656707400)
Jul  1 15:30:37 HAYDEL-MINT weewx[1913] INFO weewx.cheetahgenerator: 
Generated 8 files for report SeasonsReport in 0.21 seconds
Jul  1 15:30:37 HAYDEL-MINT weewx[1913] DEBUG weewx.manager: Daily summary 
version is 4.0
Jul  1 15:30:37 HAYDEL-MINT weewx[1913] INFO weewx.imagegenerator: 
Generated 1 images for report SeasonsReport in 0.10 seconds
Jul  1 15:30:37 HAYDEL-MINT weewx[1913] INFO weewx.reportengine: Copied 0 
files to /var/www/html/weewx
Jul  1 15:30:37 HAYDEL-MINT weewx[1913] DEBUG weewx.reportengine: Report 
'SmartphoneReport' not enabled. Skipping.
Jul  1 15:30:37 HAYDEL-MINT weewx[1913] DEBUG weewx.reportengine: Report 
'MobileReport' not enabled. Skipping.
Jul  1 15:30:37 HAYDEL-MINT weewx[1913] DEBUG weewx.reportengine: Report 
'StandardReport' not enabled. Skipping.
Jul  1 15:30:37 HAYDEL-MINT weewx[1913] DEBUG weewx.reportengine: Report 
'FTP' not enabled. Skipping.
Jul  1 15:30:37 HAYDEL-MINT weewx[1913] DEBUG weewx.reportengine: Report 
'RSYNC' not enabled. Skipping.
Jul  1 15:31:42 HAYDEL-MINT dbus-daemon[1099]: [session uid=1000 pid=1099] 
Activating service name='org.cinnamon.ScreenSaver' requested by ':1.90' 
(uid=1000 pid=2879 comm="/usr/bin/python3 
/usr/bin/cinnamon-screensaver-com" label="unconfined")
Jul  1 15:31:42 HAYDEL-MINT dbus-daemon[1099]: [session uid=1000 pid=1099] 
Successfully activated service 'org.cinnamon.ScreenSaver'
Jul  1 15:31:42 HAYDEL-MINT cinnamon-session[1081]: WARNING: t+1413.18905s: 
Detected that screensaver has appeared on the bus
Jul  1 15:33:51 HAYDEL-MINT systemd[1]: Starting Message of the Day...
Jul  1 15:33:51 HAYDEL-MINT systemd[1]: motd-news.service: Succeeded.
Jul  1 15:33:51 HAYDEL-MINT systemd[1]: Finished Message of the Day.
Jul  1 15:35:36 HAYDEL-MINT weewx[1913] INFO weewx.manager: Added record 
2022-07-01 15:35:00 CDT (1656707700) to database 'weewx.sdb'
Jul  1 15:35:37 HAYDEL-MINT weewx[1913] INFO weewx.manager: Added record 
2022-07-01 15:35:00 CDT (1656707700) to daily summary in 'weewx.sdb'
Jul  1 15:35:37 HAYDEL-MINT weewx[1913] DEBUG weewx.restx: CWOP: wait 
interval (300 < 600) has not passed for record 2022-07-01 15:35:00 CDT 
(1656707700)
Jul  1 15:35:37 HAYDEL-MINT /weewxd: weatherflowudp: MainThread: Listening 
for UDP broadcasts to IP address  on port 50222, with timeout 90 
and share_socket True...
Jul  1 15:35:37 HAYDEL-MINT weewx[1913] DEBUG weewx.reportengine: Running 
reports for latest time in the database.
Jul  1 15:35:37 HAYDEL-MINT weewx[1913] DEBUG weewx.reportengine: Running 
report 'SeasonsReport'
Jul  1 15:35:37 HAYDEL-MINT weewx[1913] DEBUG weewx.reportengine: Found 
configuration file /etc/weewx/skins/Seasons/skin.conf for 

[weewx-user] Re: LinuxMint

[vince]

Looking for udp/50222 almost certainly means you have a WeatherFlow system, 
but you've provided no info on your network setup really.

Again - the 
FAQ https://github.com/weewx/weewx/wiki/faq-how-to-report-a-problem 
applies.We need more info on your setup and need to see your debug=1 
logs.

I don't run Mint so I can't speculate what firewall setup it comes with, 
but if you turn your firewall off (for an hour), reset weewx, and it works 
for an hourand then it fails after a few minutes after you re-enable 
the firewall, it is your firewall setup for sure.

You can also run my UDP listener to see what the os sees 
- https://github.com/vinceskahan/weatherflow-udp-listener is the link for 
that.  Just run it with the "--raw --decoded" options.

On Friday, July 1, 2022 at 12:52:52 PM UTC-7 oha...@gmail.com wrote:

> Hello,
>
> I am running the latest Version of Linux Mint with WeeWx.  I appear to 
> have everything running correctly in the system.  The issue I am having 
> is:  WeeWx is timing out waiting for a UDP connection to 50222.  I 
> suspected it had something to do with the Firewall, so on my network 
> adapter, I changed the Firewall zone to "DMZ" temporarily to see if that 
> solved the issue.  It did.  On the logs,  the data started flowing from my 
> sensors immediately.  Then after a few minutes, it stopped again.  And I 
> cannot get it to restart, no matter what I try.  The firewall does not 
> appear to be making a difference as I have disabled it.  I can see the UDP 
> packets fine on my phone using a UDP app.  Any suggestions?
>
> Thanks in advance.
> OLH
>
>

-- 
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/1e297cf7-1285-43bf-be51-e3ddf345196bn%40googlegroups.com.

[weewx-user] LinuxMint

[Oren Haydel III]

Hello,

I am running the latest Version of Linux Mint with WeeWx.  I appear to have 
everything running correctly in the system.  The issue I am having is:  
WeeWx is timing out waiting for a UDP connection to 50222.  I suspected it 
had something to do with the Firewall, so on my network adapter, I changed 
the Firewall zone to "DMZ" temporarily to see if that solved the issue.  It 
did.  On the logs,  the data started flowing from my sensors immediately.  
Then after a few minutes, it stopped again.  And I cannot get it to 
restart, no matter what I try.  The firewall does not appear to be making a 
difference as I have disabled it.  I can see the UDP packets fine on my 
phone using a UDP app.  Any suggestions?

Thanks in advance.
OLH

-- 
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/7be9127f-28b4-4b2c-bcfb-4789bdfe3b4an%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, 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 >>> googlegroups.com> a écrit :

 1592614500
 1632611100
 1632611400
 1647688800

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

 On Thursday, 

Re: [weewx-user] Re: Unable to publish to previmeteo

[vince]

I just did a clean package install of weewx on a pi3 and then installed the 
extension with the two commands I posted above. Worked fine.

My guess in the absence of much info is that you don't have a good copy of 
the .tar.gz for the extension.

Check your file size and checksum:

pi@pi3jr-wifi:/var/tmp $ ls -al weewx-previmeteo-v0.1.tar.gz
-rw-r--r-- 1 pi pi 1446 Jul  1 08:46 weewx-previmeteo-v0.1.tar.gz

pi@pi3jr-wifi:/var/tmp $ sha1sum weewx-previmeteo-v0.1.tar.gz
ca62d2821862de3dbad53707ca41761300b75487  weewx-previmeteo-v0.1.tar.gz

Your size and sha1sum should match 'exactly'.  If it doesn't, you have a 
truncated/corrupted download.


-- 
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/d32d8128-9a08-45ce-b55a-c54f354ae2f5n%40googlegroups.com.

Re: [weewx-user] Sunshine Database

[Jacques Terrettaz]

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

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

Re: [weewx-user] Re: Unable to publish to previmeteo

[Glenn McKechnie]

also, there technically should be an equals sign in that command.

wee_extension --help

with that it becomes...

sudo wee_extension --install=weewx-previmeteo-v0.1.tar.gz

It's never made a difference for me, perhaps your installation requires it?



On 01/07/2022, Glenn McKechnie  wrote:
> make that at the 'weewx-p'. The last character you type.
>
> On 01/07/2022, Glenn McKechnie  wrote:
>> On 01/07/2022, Kruse Ludington  wrote:
>>> When I do a simple "ls" command, the file is right there!
>>
>> Okay.
>> type in the first part of your command...
>>
>> sudo wee_extension --install weewx-p
>>
>> At that 'w' press the tab key once and the rest of the filename should
>> auto complete ... be filled in. If it does that then the command line,
>> recognizes that file is there (assuming you don't get a choice of
>> files, in which case select the correct one.)
>>
>> If that does complete okay and it still doesn't install then it may
>> pay to check the actual file... Is it a gzip archive?
>>
>> In the terminal, use the command 'file'.
>> What does it return?
>>
>> 10:56 PM $ file weewx-previmeteo-v0.1.tar.gz
>> weewx-previmeteo-v0.1.tar.gz: gzip compressed data, from Unix,
>> original size modulo 2^32 10240
>>
>> If it's anything other than above - html? then it's a corrupted file.
>> Download it again.
>>
>> --
>>
>>
>> Cheers
>>  Glenn
>>
>> rorpi - read only raspberry pi & various weewx addons
>> https://github.com/glennmckechnie
>>
>
>
> --
>
>
> Cheers
>  Glenn
>
> rorpi - read only raspberry pi & various weewx addons
> https://github.com/glennmckechnie
>


-- 


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/CAAraAzhb45_u5AxXRLYUg2%3DrXFR5Hv2xhdYzY1CeSYb1sVV84g%40mail.gmail.com.

Re: [weewx-user] Re: Unable to publish to previmeteo

[Glenn McKechnie]

make that at the 'weewx-p'. The last character you type.

On 01/07/2022, Glenn McKechnie  wrote:
> On 01/07/2022, Kruse Ludington  wrote:
>> When I do a simple "ls" command, the file is right there!
>
> Okay.
> type in the first part of your command...
>
> sudo wee_extension --install weewx-p
>
> At that 'w' press the tab key once and the rest of the filename should
> auto complete ... be filled in. If it does that then the command line,
> recognizes that file is there (assuming you don't get a choice of
> files, in which case select the correct one.)
>
> If that does complete okay and it still doesn't install then it may
> pay to check the actual file... Is it a gzip archive?
>
> In the terminal, use the command 'file'.
> What does it return?
>
> 10:56 PM $ file weewx-previmeteo-v0.1.tar.gz
> weewx-previmeteo-v0.1.tar.gz: gzip compressed data, from Unix,
> original size modulo 2^32 10240
>
> If it's anything other than above - html? then it's a corrupted file.
> Download it again.
>
> --
>
>
> Cheers
>  Glenn
>
> rorpi - read only raspberry pi & various weewx addons
> https://github.com/glennmckechnie
>


-- 


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/CAAraAzin%3DWg46ghinq4mLsHHPn2WV_WHrbg_EOrxBFR_gbhR_w%40mail.gmail.com.

Re: [weewx-user] Re: Unable to publish to previmeteo

[Glenn McKechnie]

On 01/07/2022, Kruse Ludington  wrote:
> When I do a simple "ls" command, the file is right there!

Okay.
type in the first part of your command...

sudo wee_extension --install weewx-p

At that 'w' press the tab key once and the rest of the filename should
auto complete ... be filled in. If it does that then the command line,
recognizes that file is there (assuming you don't get a choice of
files, in which case select the correct one.)

If that does complete okay and it still doesn't install then it may
pay to check the actual file... Is it a gzip archive?

In the terminal, use the command 'file'.
What does it return?

10:56 PM $ file weewx-previmeteo-v0.1.tar.gz
weewx-previmeteo-v0.1.tar.gz: gzip compressed data, from Unix,
original size modulo 2^32 10240

If it's anything other than above - html? then it's a corrupted file.
Download it again.

-- 


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/CAAraAzgHTmVonVTyPzz%2BrDE%2BoH77452fQtTySbV_sp6iZf6bxg%40mail.gmail.com.

Re: [weewx-user] Re: Unable to publish to previmeteo

[Kruse Ludington]

When I do a simple "ls" command, the file is right there!

On Friday, July 1, 2022 at 12:01:35 AM UTC-4 Glenn McKechnie wrote:

> I've just run through those instructions here and it works for me.
>
> What directory are you in, the one that you are running that command
> from? Does it contain the file weewx-previmeteo-v0.1.tar.gz ?
>
> wee_extension is running okay, it just complains about a read error
> for the target file - "file could not be opened successfully". Meaning
> it can't read (or find) the file that you've specified (which is your
> current directory).
>
> Give the full path to that file... eg:-
> /where/it/was/stored/weewx-previmeteo-v0.1.tar.gz
>
> There is an odd chance that the downloaded file is corrupt, but my
> first instinct is that it literally can't find the file with the
> instruction you gave it.
>
> On 01/07/2022, rklud...@gmail.com  wrote:
> > Well here are the two attempts…. All the other extensions worked fine 
> for me
> > (I did have to use sudo for those as well) but they were all zip files. 
> As
> > this one is a ‘tar.gz’ am I missing the utility for doing so on my rpi
> > maybe? – or I was searching around and is it possible someone tried to
> > compress it twice?
> >
> >
> >
> > pi@kruse-pi:~ $ sudo wee_extension --install weewx-previmeteo-v0.1.tar.gz
> >
> > Request to install 'weewx-previmeteo-v0.1.tar.gz'
> >
> > Extracting from tar archive weewx-previmeteo-v0.1.tar.gz
> >
> > Traceback (most recent call last):
> >
> > File "/usr/share/weewx/wee_extension", line 92, in 
> >
> > main()
> >
> > File "/usr/share/weewx/wee_extension", line 84, in main
> >
> > ext.install_extension(options.install)
> >
> > File "/usr/share/weewx/weecfg/extension.py", line 122, in
> > install_extension
> >
> > member_names = weecfg.extract_tar(extension_path,
> >
> > File "/usr/share/weewx/weecfg/__init__.py", line 1805, in extract_tar
> >
> > tar_archive = tarfile.open(filename, mode='r')
> >
> > File "/usr/lib/python3.9/tarfile.py", line 1616, in open
> >
> > raise ReadError("file could not be opened successfully")
> >
> > tarfile.ReadError: file could not be opened successfully
> >
> >
> >
> > pi@kruse-pi:~ $ sudo /home/weewx/bin/wee_extension --install
> > weewx-previmeteo-v0.1.tar.gz
> >
> > sudo: /home/weewx/bin/wee_extension: command not found
> >
> >
> >
> > -Kruse
> >
> > (M): > +1.201.925.4410 
> <(201)%20925-4410>
> >
> > (O): > +1.862.308.7040 
> <(862)%20308-7040>
> >
> > (H): > +1.201.857.8307 
> <(201)%20857-8307>
> >
> > (F): > +1.201.857.7188 
> <(201)%20857-7188>
> >
> >
> >
> > From: rklud...@gmail.com 
> > Sent: Thursday, June 30, 2022 10:35 PM
> > To: 'weewx...@googlegroups.com' 
> > Subject: RE: [weewx-user] Re: Unable to publish to previmeteo
> >
> >
> >
> > I’ll give them both a shot - thanks
> >
> >
> >
> > -Kruse
> >
> > (M): > +1.201.925.4410 
> <(201)%20925-4410>
> >
> > (O): > +1.862.308.7040 
> <(862)%20308-7040>
> >
> > (H): > +1.201.857.8307
> >
> > (F): > +1.201.857.7188
> >
> >
> >
> > From: weewx...@googlegroups.com 
> > mailto:weewx...@googlegroups.com> > On
> > Behalf Of vince
> > Sent: Thursday, June 30, 2022 10:20 PM
> > To: weewx-user  >  >
> > Subject: [weewx-user] Re: Unable to publish to previmeteo
> >
> >
> >
> > If you did a package install of weewx, try "sudo wee_extension --install
> > weewx-previmeteo-v0.1.tar.gz", assuming you are in the same working
> > directory as the .tar.gz file
> >
> >
> >
> > If you did a setup.py install of weewx, it would be "sudo
> > /home/weewx/bin/wee_extension --install weewx-previmeteo-v0.1.tar.gz"
> >
> >
> >
> > On Thursday, June 30, 2022 at 7:00:50 PM UTC-7 rklud...@gmail.com
> >  wrote:
> >
> > Regarding this:
> >
> > https://github.com/previmeteo/weewx-previmeteo#readme
> >
> > Running this:
> >
> > setup.py install --extension weewx-previmeteo-v0.1.tar.gz
> >
> > ends up giving me this error:
> >
> > bash: setup.py: command not found
> >
> > So I also tried….
> >
> > python3 setup.py install --extension weewx-previmeteo-v0.1.tar.gz
> >
> > which gives me a similar error about not being able to fins setup.py
> >
> > FYI, there are about a gazillion “setup.py” files all over my machine – 
> all
> > different sizes - but none in any weewx directory I can find –
> >
> > Thoughts? Anyone publishing to previmeteo?
> >
> > --
> > 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/WN4vQOyNFrQ/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/76727a09-c125-4f57-bd4a-26df9cb66df4n%40googlegroups.com
> > <
> 

Re: [weewx-user] Sunshine Database

[Jacques Terrettaz]

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