[weewx-user] Re: Data Logger

[rich T]

My Acurite console been full for over a month now; but data is being saved 
in a database, so I'm not to worried. 

On Friday, February 8, 2019 at 9:17:06 PM UTC-5, John Clark wrote:
>
> Every once in a while I see "data logger full" on the screen of my 
> Acurite  interface and I was wondering, is there a way to force a dump? 
> Normally wouldn't care but I had to restart early on and was figuring there 
> might be some info in there I lost (unless it is a FIFO system). Far from 
> stressing over it, just curious.
> -- 
>
> *John Clark, WØAVQ w0a...@gmail.com *
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Data Logger

[John Clark]

Every once in a while I see "data logger full" on the screen of my 
Acurite  interface and I was wondering, is there a way to force a dump? 
Normally wouldn't care but I had to restart early on and was figuring 
there might be some info in there I lost (unless it is a FIFO system). 
Far from stressing over it, just curious.


--
*/John Clark, WØAVQ
w0av...@gmail.com/*

--
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] AWEKAS stop accepting my posts

[ted frohling]

I recently became aware that AWEKAS stopped accepting my weewx uploads.  
The errors I'm getting in the logs  are:

Feb 08 16:15:56 weewx weewx[13603]: restx: AWEKAS: Failed to publish record 
2019-02-08 16:10:00 MST (1549667400): server returned 'too many requests - 
try again later '
Feb 08 16:15:57 weewx weewx[13603]: restx: AWEKAS: Failed to publish record 
2019-02-08 16:15:00 MST (1549667700): server returned 'too many requests - 
try again later'

Of course, I've restarted weewx many times.  This is running on a Pi 3.  
All the other uploads are working just fine.

Any thoughts?

Thanks,

ted


-- 
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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: V3.9.1

[mwall]

On Friday, February 8, 2019 at 6:45:36 PM UTC-5, Eelco F wrote:
>
> dpkg: fout: --compare-versions verwacht drie argumenten:  
>  
>
> So it's still running 3.8.2. Where is the error here?
>
>>
did you remove the line 'version = ...' from your weewx.conf at some 
point?  did you delete the weewx.conf.dist file at some point?

please post the output from these two commands:

grep version /etc/weewx/weewx.conf | sed -e 's/\s*version\s*=\s*//' | sed 
-e 's/-.*//'

and:

grep version /etc/weewx/weewx.conf.dist | sed -e 's/\s*version\s*=\s*//' | 
sed -e 's/-.*//'

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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: V3.9.1

[Walter Smith]

Hi I'm using Raspian Stretch Lite Linux version 4.14.79.  The error was:
Feb  8 15:03:04 raspberrypi2 weewx[432]: engine: Launch of report thread 
aborted: existing report thread still running
I'm not getting the error any longer.  After a restart of weewx and/or a 
reboot of the Pi,, it seems to have gone away.  I made a copy of the 
syslog.  It may be due to some time snafu on the pi.  Between the startup 
of weewx and the error messages, the system changed its time ahead about 90 
minutes.  I agree with you on Edge, I think it won't get a fresh copy from 
the pi for some reason, no matter what I do.  Edge has it's problems.  This 
isn't the first time I've been disappointed with it.  Thanks for your help.

On Friday, February 8, 2019 at 5:43:55 PM UTC-6, tor...@torrin.org wrote:
>
> On item 1) I am using the season skin with weewx 3.9.1 and it is working 
> fine in Edge (as is Belchertown)   The issue is almost certainly tied to 
> your nginx configuration (Full disclosure, I am using apache)
> On Item 2) I checked my system look for any already running error messages 
> and I do not see that error occurring.
>
> What OS and version are you running on your new pi?
>
> On Friday, February 8, 2019 at 5:13:40 PM UTC-6, Walter Smith wrote:
>>
>> Sorry about the empty response a second ago.  I got a new Pi and got 
>> version 3.9.1 on a clean install this morning.  All is working pretty well 
>> and I like the new skins.  I had the following issues:
>>
>> 1.  The Microsoft Edge browser refuses to show any web pages.  I can see 
>> them fine in Explorer and Firefox.  I do have a new IP address with the new 
>> Pi but I've tried all sorts of reboots and InPrivate browsing and I still 
>> can't get Edge to display anything.  It has to be Edge's fault because it 
>> won't show the "Welcome to Nginx!" page either.
>>
>> 2.  I noticed but did not copy down or save an error message in the log 
>> that was repeated at each interval, something to the effect of "can't start 
>> thread X because another thread X is already running".  Sorry for the 
>> imprecision.  
>>
>> Other than that it's doing well.  Some graphs are incomplete because I 
>> had to copy over the old SQLite db file.  And it will catch up eventually?  
>> I ran wee_reports utility but it did not change the incomplete graphs.
>>
>> Thanks everyone for a great system.
>>
>> Walt
>>
>> On Wednesday, February 6, 2019 at 7:40:34 AM UTC-6, Thomas Keffer wrote:
>>>
>>> Well, that was a record short release. We found a serious bug in v3.9.0 
>>> that could break skins that do not have fonts defined, such as cmon.
>>>
>>> So, we are releasing v3.9.1, found in the usual place 
>>> .
>>>
>>> -tk
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: V3.9.1

[Eelco F]

Oh, and i'm getting this error now from crt.py (v0.18)

Feb  9 00:25:12 weerstation weewx[32454]: crt: crt: Exception while 
handling data: unsupported operand type(s) for -: 'NoneType' and 'NoneType'
Feb  9 00:25:12 weerstation weewx[32454]: crt:  Traceback (most recent 
call last):
Feb  9 00:25:12 weerstation weewx[32454]: crt:    File 
"/usr/share/weewx/user/crt.py", line 456, in handle_data
Feb  9 00:25:12 weerstation weewx[32454]: crt:  data = 
self.calculate(event_data, dbm)
Feb  9 00:25:12 weerstation weewx[32454]: crt:    File 
"/usr/share/weewx/user/crt.py", line 647, in calculate
Feb  9 00:25:12 weerstation weewx[32454]: crt: 
 data['sunshine_hours'] = calc_daylight_hours(alm)
Feb  9 00:25:12 weerstation weewx[32454]: crt:    File 
"/usr/share/weewx/user/crt.py", line 285, in calc_daylight_hours
Feb  9 00:25:12 weerstation weewx[32454]: crt:  return (sunset - 
sunrise) / 3600.0
Feb  9 00:25:12 weerstation weewx[32454]: crt:  TypeError: unsupported 
operand type(s) for -: 'NoneType' and 'NoneType'


Op woensdag 6 februari 2019 14:40:34 UTC+1 schreef Thomas Keffer:
>
> Well, that was a record short release. We found a serious bug in v3.9.0 
> that could break skins that do not have fonts defined, such as cmon.
>
> So, we are releasing v3.9.1, found in the usual place 
> .
>
> -tk
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Re: NOAA reports not available

[mwall]

On Friday, February 8, 2019 at 6:43:14 PM UTC-5, bgrattan wrote:
>
> I have removed ForecastVariables in skin.conf. All of the month/year 
> selections appear as they should--you can have a look. The forecast items 
> no longer appear.
>

please post these files:

skins/Standard/index.html.tmpl
skins/Standard/skin.conf
weewx.conf (remove all passwords first)

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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: V3.9.1

[Eelco F]

I just did an update on one of my weather stations through apt update and 
apt upgrade on ubuntu 16.04, I choose to keep the old version of weewx.conf
However it yields an error:
dpkg: fout: --compare-versions verwacht drie argumenten:   


This is in dutch, but it means:
dpkg:error: --compare-versions expects three arguments:  
 


Complete output (in dutch):

Instellen van weewx (3.9.1-1) ...

Configuratiebestand '/etc/weewx/weewx.conf'
 ==> Gewijzigd (door u of door een script) sinds de installatie.
 ==> Pakketdistributeur heeft een bijgewerkte versie gemaakt.
   Wat wilt u er aan doen ?  De volgende keuzes zijn mogelijk:
Y of I  : installeer de versie van de pakketbeheerder
N of O  : behoud de huidige geïnstalleerde versie
  D : toon de verschillen tussen de versies
  Z : start een shell om de situatie te onderzoeken
 De standaardactie is om uw huidige versie te behouden.
*** weewx.conf (Y/I/N/O/D/Z) [standaard=N] ? N
Nieuwe versie van configuratiebestand /etc/weewx/weewx.conf.dist wordt 
geïnstalleerd ...
Nieuwe versie van configuratiebestand 
/etc/weewx/logwatch/scripts/services/weewx wordt geïnstalleerd ...
Nieuwe versie van configuratiebestand /etc/weewx/skins/Rsync/skin.conf 
wordt geïnstalleerd ...
Nieuwe versie van configuratiebestand 
/etc/weewx/skins/Standard/index.html.tmpl wordt geïnstalleerd ...
Nieuwe versie van configuratiebestand /etc/weewx/skins/Standard/skin.conf 
wordt geïnstalleerd ...
Nieuwe versie van configuratiebestand /etc/weewx/skins/Ftp/skin.conf wordt 
geïnstalleerd ...
Nieuwe versie van configuratiebestand /etc/weewx/import/wu-example.conf 
wordt geïnstalleerd ...
Nieuwe versie van configuratiebestand 
/etc/weewx/import/cumulus-example.conf wordt geïnstalleerd ...
Nieuwe versie van configuratiebestand /etc/weewx/import/csv-example.conf 
wordt geïnstalleerd ...
dpkg: fout: --compare-versions verwacht drie argumenten:   


So it's still running 3.8.2. Where is the error here?

Regards,

Eelco


Op woensdag 6 februari 2019 14:40:34 UTC+1 schreef Thomas Keffer:
>
> Well, that was a record short release. We found a serious bug in v3.9.0 
> that could break skins that do not have fonts defined, such as cmon.
>
> So, we are releasing v3.9.1, found in the usual place 
> .
>
> -tk
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: V3.9.1

[torrin]

On item 1) I am using the season skin with weewx 3.9.1 and it is working 
fine in Edge (as is Belchertown)   The issue is almost certainly tied to 
your nginx configuration (Full disclosure, I am using apache)
On Item 2) I checked my system look for any already running error messages 
and I do not see that error occurring.

What OS and version are you running on your new pi?

On Friday, February 8, 2019 at 5:13:40 PM UTC-6, Walter Smith wrote:
>
> Sorry about the empty response a second ago.  I got a new Pi and got 
> version 3.9.1 on a clean install this morning.  All is working pretty well 
> and I like the new skins.  I had the following issues:
>
> 1.  The Microsoft Edge browser refuses to show any web pages.  I can see 
> them fine in Explorer and Firefox.  I do have a new IP address with the new 
> Pi but I've tried all sorts of reboots and InPrivate browsing and I still 
> can't get Edge to display anything.  It has to be Edge's fault because it 
> won't show the "Welcome to Nginx!" page either.
>
> 2.  I noticed but did not copy down or save an error message in the log 
> that was repeated at each interval, something to the effect of "can't start 
> thread X because another thread X is already running".  Sorry for the 
> imprecision.  
>
> Other than that it's doing well.  Some graphs are incomplete because I had 
> to copy over the old SQLite db file.  And it will catch up eventually?  I 
> ran wee_reports utility but it did not change the incomplete graphs.
>
> Thanks everyone for a great system.
>
> Walt
>
> On Wednesday, February 6, 2019 at 7:40:34 AM UTC-6, Thomas Keffer wrote:
>>
>> Well, that was a record short release. We found a serious bug in v3.9.0 
>> that could break skins that do not have fonts defined, such as cmon.
>>
>> So, we are releasing v3.9.1, found in the usual place 
>> .
>>
>> -tk
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Re: NOAA reports not available

[bgrattan]

Matt,

I have removed ForecastVariables in skin.conf. All of the month/year 
selections appear as they should--you can have a look. The forecast items 
no longer appear.

The  [[[DAILYCHARTS]]], [[[MONTHLYCHARTS]]], and [[[YEARLYCHARTS]]] are 
from trying to install the WX-HWS page which I haven't mastered yet. I can 
remove them if you think it will help.

On Friday, February 8, 2019 at 4:35:48 PM UTC-5, mwall wrote:

Thanks.
Bob 

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: V3.9.1

[Walter Smith]

Sorry about the empty response a second ago.  I got a new Pi and got 
version 3.9.1 on a clean install this morning.  All is working pretty well 
and I like the new skins.  I had the following issues:

1.  The Microsoft Edge browser refuses to show any web pages.  I can see 
them fine in Explorer and Firefox.  I do have a new IP address with the new 
Pi but I've tried all sorts of reboots and InPrivate browsing and I still 
can't get Edge to display anything.  It has to be Edge's fault because it 
won't show the "Welcome to Nginx!" page either.

2.  I noticed but did not copy down or save an error message in the log 
that was repeated at each interval, something to the effect of "can't start 
thread X because another thread X is already running".  Sorry for the 
imprecision.  

Other than that it's doing well.  Some graphs are incomplete because I had 
to copy over the old SQLite db file.  And it will catch up eventually?  I 
ran wee_reports utility but it did not change the incomplete graphs.

Thanks everyone for a great system.

Walt

On Wednesday, February 6, 2019 at 7:40:34 AM UTC-6, Thomas Keffer wrote:
>
> Well, that was a record short release. We found a serious bug in v3.9.0 
> that could break skins that do not have fonts defined, such as cmon.
>
> So, we are releasing v3.9.1, found in the usual place 
> .
>
> -tk
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: V3.9.1

[Walter Smith]

On Wednesday, February 6, 2019 at 7:40:34 AM UTC-6, Thomas Keffer wrote:
>
> Well, that was a record short release. We found a serious bug in v3.9.0 
> that could break skins that do not have fonts defined, such as cmon.
>
> So, we are releasing v3.9.1, found in the usual place 
> .
>
> -tk
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Re: NOAA reports not available

[mwall]

On Friday, February 8, 2019 at 3:03:34 PM UTC-5, Glenn McKechnie wrote:
>
>
> The commented code that you see in Bob's template is not the actual 
> NOAA generating code. It is a duplicate that I included when we were 
> troubleshooting this originally.  The original #for...#end for code is 
> still contained in the template. 
>

color me confused.

this is the code in the original index.html.tmpl file:


#for $monthYear in $SummaryByMonth
$monthYear
#end for
-Select month-


Yearly summary:  
 

#for $yr in $SummaryByYear
$yr
#end for
-Select year-


this is an example of the resulting index.html:


2019-02 -Select 
month-Yearly summary:  
  2019-Select year-   
 


this came from the Standard skin, with two lines added to index.html.tmpl:



#include "forecast_compact.inc"


and with the ForecastVariables enabled in weewx.conf like this:

[StdReport]
...
[[Standard]]
...
[[[CheetahGenerator]]]
search_list_extensions = user.forecast.ForecastVariables

but this is what i see in bob's index.html:


-Select month-
Yearly summary:   
-Select year-


so two questions for bob:

1) what do you get in the index.html when you disable ForecastVariables?

2) what are the [[[DAILYCHARTS]]], [[[MONTHLYCHARTS]]], and [[[YEARLYCHARTS]]] 
sections for in your skin.conf?

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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: V3.9.1

[weerman]

Thanks a lot for the great update, Tom, Matthew and Gary

Update went pretty well and smooth.

Regards

Georg
 

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Re: NOAA reports not available

[Glenn McKechnie]

Hi Matt,

Further to Bob's comment regarding those html comments.

The commented code that you see in Bob's template is not the actual
NOAA generating code. It is a duplicate that I included when we were
troubleshooting this originally.  The original #for...#end for code is
still contained in the template.

I wanted to see if the variables were being found and populated when
it was being parsed by weewx. They weren't and if you're seeing them
again then we're back to the same state as before. The javascript is
being skipped, perhaps because the variables aren't being filled.?

On 09/02/2019, bgrat...@umw.edu  wrote:
> Matt,
>
> Thanks for the quick reply. I've been trying to fix things and forgot to
> clean up some of the test code changes, sorry. However, when I make the
> corrections the drop down NOAA menus are still missing. I have attached my
> corrected index.html.tmpl file.
> No errors are showing up that I see. Thanks.
> Bob
>
> On Friday, February 8, 2019 at 10:41:28 AM UTC-5, mwall wrote:
>>
>>
>>
>> On Friday, February 8, 2019 at 10:04:35 AM UTC-5, bgrattan wrote:
>>>
>>> Any idea what's going on here? You say its working for you but I can't
>>> seem to find the correct setting to have both the forecast and NOAA
>>> summaries. I have attached my Standard/skin.conf
>>>
>>
>> in your index.html.tmpl you have commented out the cheetah code that
>> generates the 'select' items for the NOAA menus.
>>
>> this is what i see in your generated html:
>>
>> 
>>
>> -Select month-
>> 
>> 
>> Yearly summary:
>> 
>> 
>> -Select year-
>> 
>>
>> this is what is in the original index.html.tmpl:
>>
>> 
>> #for $monthYear in $SummaryByMonth
>> $monthYear
>> #end for
>> -Select month-
>> 
>> 
>> Yearly summary:
>>
>>
>> 
>> #for $yr in $SummaryByYear
>> $yr
>> #end for
>> -Select year-
>> 
>>
>> you have removed the '#for' loops, so the menus are not generated.
>>
>> 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.
> For more options, visit https://groups.google.com/d/optout.
>


-- 


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.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Re: I have looked for days trying to change the output of W/m² to lux.

[Greg Troxel]

Thomas Keffer  writes:

>  Very nice write up, Greg.
>
> May I cut and paste it into a Wiki article? This is not the first time this
> has come up.

Sure, that's fine.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: WH65B no pressure

[torrin]

I did the same.  I will be taking a swing at the WH32B this weekend to 
capture data to be added as a new device, but the WH25 worked with 30 
seconds of setup.



On Friday, February 8, 2019 at 10:52:06 AM UTC-6, G Hammer wrote:
>
> You can purchase a WH25B then you'll have indoor temp humidity and 
> barometer with SDR.
> I spent quite a bit of time on sniffing the data and eventually decided to 
> get the dongle and WH25B and forget Interceptor.
>
>
> On Tuesday, January 1, 2019 at 7:03:59 AM UTC-5, Zsolt Máté wrote:
>>
>> I tried, something is not working or I'm doing something wrong.
>>
>> On Wednesday, January 2, 2019 at 12:53:42 AM UTC+13, Andrew Milner wrote:
>>>
>>> with the interceptor driver
>>>
>>>
>>>
>>> On Tuesday, 1 January 2019 13:42:18 UTC+2, Zsolt Máté wrote:

 I ran tcpdump on my router an I got this:
 GET 
 /weatherstation/updateweatherstation.php?ID=*==72.5=64.4=59.7=64.4=52=85=0.0=0.0=198=29.63=29.60=0.00=0.00=0.31=0.00=0.00=0=2019-1-1%2011:38:47=EasyWeatherV1.2.3=updateraw=1=5
  
 HTTP/1.0

 The question is, how can I intercept and interpret this communication 
 from my raspi?

 On Wednesday, January 2, 2019 at 12:32:34 AM UTC+13, Zsolt Máté wrote:
>
> The console has no USB port, it's communicating via WiFi.
>
> On Tuesday, January 1, 2019 at 8:05:28 PM UTC+13, mwall wrote:
>>
>>
>>
>> On Tuesday, January 1, 2019 at 12:10:46 AM UTC-5, Zsolt Máté wrote:
>>>
>>>
>>> Is there a way to get the barometer readout as well?
>>>
>>
>> not using rtl_433/weewx-sdr.  the pressure sensor is located in your 
>> weather station console, so the pressure data are never sent.  rtl_433 
>> picks up only the transmissions from the instrument cluster (and any 
>> remote 
>> temperature/humidity sensors), not the console.
>>
>> you'll have to intercept the data sent by the console (e.g., using 
>> the weewx-interceptor driver) or figure out some way to probe the 
>> console 
>> for data (does it have a usb port that responds to data requests?)
>>
>> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Re: V3.9.1

[torrin]

Upgraded directly to 3.9.1 and with a little configuration file tweak, it 
was seamless and working great, thanks for all of the hard work here!

On Friday, February 8, 2019 at 11:50:44 AM UTC-6, Christian Peters wrote:
>
> OK ... RTFM! :-D 
>
> Will try this. 
>
> Regards,
>
> Christian 
>
> Am Freitag, 8. Februar 2019 18:44:13 UTC+1 schrieb Thomas Keffer:
>>
>> See the upgrading guide section *Do you need to change anything?*
>>
>> -tk
>>
>> On Fri, Feb 8, 2019 at 9:26 AM 'Christian Peters' via weewx-user <
>> weewx...@googlegroups.com> wrote:
>>
>>> Hi Tom, 
>>>
>>> I just updated from 3.8.2 to 3.9.1 but my units seemed to be overwritten 
>>> (using metrics in 3.8.2 - Celsius, Km/h, mbar) now my Standard skin shows 
>>> F, inHG and mpH!? 
>>> Should I uncoment the new section in the weewx.conf file named 
>>> [[Defaults]] ? 
>>> I upgraded via .deb and kept all old config file ('N' while updateing).
>>>
>>> In my skin.conf the metrics units where set - but the new weewx.conf 
>>> seems to be the 'master' and overwrite it!?  
>>> Or do I have to set my untits done in the skin.conf now in the 
>>> weewx.conf [[Defaults]] section too?
>>>
>>> Regards,
>>>
>>> Christian 
>>>
>>>
>>> Am Mittwoch, 6. Februar 2019 14:40:34 UTC+1 schrieb Thomas Keffer:

 Well, that was a record short release. We found a serious bug in v3.9.0 
 that could break skins that do not have fonts defined, such as cmon.

 So, we are releasing v3.9.1, found in the usual place 
 .

 -tk

>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "weewx-user" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to weewx-user+...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Re: V3.9.1

['Christian Peters' via weewx-user]

OK ... RTFM! :-D 

Will try this. 

Regards,

Christian 

Am Freitag, 8. Februar 2019 18:44:13 UTC+1 schrieb Thomas Keffer:
>
> See the upgrading guide section *Do you need to change anything?*
>
> -tk
>
> On Fri, Feb 8, 2019 at 9:26 AM 'Christian Peters' via weewx-user <
> weewx...@googlegroups.com > wrote:
>
>> Hi Tom, 
>>
>> I just updated from 3.8.2 to 3.9.1 but my units seemed to be overwritten 
>> (using metrics in 3.8.2 - Celsius, Km/h, mbar) now my Standard skin shows 
>> F, inHG and mpH!? 
>> Should I uncoment the new section in the weewx.conf file named 
>> [[Defaults]] ? 
>> I upgraded via .deb and kept all old config file ('N' while updateing).
>>
>> In my skin.conf the metrics units where set - but the new weewx.conf 
>> seems to be the 'master' and overwrite it!?  
>> Or do I have to set my untits done in the skin.conf now in the weewx.conf 
>> [[Defaults]] section too?
>>
>> Regards,
>>
>> Christian 
>>
>>
>> Am Mittwoch, 6. Februar 2019 14:40:34 UTC+1 schrieb Thomas Keffer:
>>>
>>> Well, that was a record short release. We found a serious bug in v3.9.0 
>>> that could break skins that do not have fonts defined, such as cmon.
>>>
>>> So, we are releasing v3.9.1, found in the usual place 
>>> .
>>>
>>> -tk
>>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "weewx-user" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to weewx-user+...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Re: I have looked for days trying to change the output of W/m² to lux.

[Thomas Keffer]

 Very nice write up, Greg.

May I cut and paste it into a Wiki article? This is not the first time this
has come up.

-tk

On Fri, Feb 8, 2019 at 7:04 AM Greg Troxel  wrote:

> Colin Larsen  writes:
>
> > I believe it's a pretty complicated beast to do properly but a factor of
> > Lux * 0.0079 gets you W/m2 (approx?) from what I've read . so just
> the
> > reverse?
> > I'm looking at sensors at the moment that output Lux and converting it to
> > Wm/2 which where I found that conversion.
>
> It simply does not make technical sense to convert a sensor value in
> W/m^2 to lux (which is lm/m^2, lm being lumen).  They are incompatible
> units measuring different things.
>
> Sensors like the Davis solar radiation sensor measure "irradiance" in
> W/m^2, which is the amount of power arriving in an area.  By definition,
> power at all wavelengths is treated equally.
>
> lux is a unit of illuminance, which measures the amount of light in an
> area in terms of the response of the human eye, according to a
> standardized response curve obtained from experiments.
>
> For a single wavelength, one can ask what the value of one measurement
> is given the other, multiplying or dividing by the standarized response
> curve.  Using a spectroradiometer, one can measure the power at a
> variety of wavelenghts, say at 10 nm intervals, and then sum the
> converted powers.
>
> Another way to obtain lux is to use a device with a filter that matches
> the standard curve.   There are instruments for lighting, and for
> photography that do this.   There are also sky brightness meters (which
> I have read about but do have not experience with):
>   http://unihedron.com/projects/darksky/
>
> Typically people care about illuminance for management of artificial
> lighting or light pollution, and the values are very low compared to
> values that can be read on a solar radiation sensor.
>
> This stackexchange answer claims 6.8 mW/m^2 at full moon, and a full
> moon is known to produce about 0.3 lux.  Note that this ratio cannot be
> applied to sunlight; moonlight has a very high color temperature,
> meaning that it has more blue than red compared to sunlight.
>
> https://physics.stackexchange.com/questions/89181/how-is-the-earth-heated-by-a-full-moon#89197
>
> So basically, you just cannot convert sensor output and weewx should not
> try.  If you want to measure lux you need a lux sensor, and to measure
> W/m^w you need a radiation sensor.
>
> One could go out on a limb and start making assumptions about the
> spectral distribution of different kinds of daylight that are likely for
> various irradiance levels.  For example, full sun with no clouds is well
> characterized.  But as soon as you get into dawn/dusk and clouds, there
> is much more variability.  Trying to guess spectral distribution based
> on illuminance or irradiance and converting, and comparing that to a
> sensor that measures the other, would be an interesting science
> experiment.
>
> https://en.wikipedia.org/wiki/Photometry_(optics)
>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Re: V3.9.1

[Thomas Keffer]

See the upgrading guide section *Do you need to change anything?
*

-tk

On Fri, Feb 8, 2019 at 9:26 AM 'Christian Peters' via weewx-user <
weewx-user@googlegroups.com> wrote:

> Hi Tom,
>
> I just updated from 3.8.2 to 3.9.1 but my units seemed to be overwritten
> (using metrics in 3.8.2 - Celsius, Km/h, mbar) now my Standard skin shows
> F, inHG and mpH!?
> Should I uncoment the new section in the weewx.conf file named
> [[Defaults]] ?
> I upgraded via .deb and kept all old config file ('N' while updateing).
>
> In my skin.conf the metrics units where set - but the new weewx.conf seems
> to be the 'master' and overwrite it!?
> Or do I have to set my untits done in the skin.conf now in the weewx.conf
> [[Defaults]] section too?
>
> Regards,
>
> Christian
>
>
> Am Mittwoch, 6. Februar 2019 14:40:34 UTC+1 schrieb Thomas Keffer:
>>
>> Well, that was a record short release. We found a serious bug in v3.9.0
>> that could break skins that do not have fonts defined, such as cmon.
>>
>> So, we are releasing v3.9.1, found in the usual place
>> .
>>
>> -tk
>>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-user+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: V3.9.1

['Christian Peters' via weewx-user]

Hi Tom, 

I just updated from 3.8.2 to 3.9.1 but my units seemed to be overwritten 
(using metrics in 3.8.2 - Celsius, Km/h, mbar) now my Standard skin shows 
F, inHG and mpH!? 
Should I uncoment the new section in the weewx.conf file named [[Defaults]] 
? 
I upgraded via .deb and kept all old config file ('N' while updateing).

In my skin.conf the metrics units where set - but the new weewx.conf seems 
to be the 'master' and overwrite it!?  
Or do I have to set my untits done in the skin.conf now in the weewx.conf 
[[Defaults]] section too?

Regards,

Christian 


Am Mittwoch, 6. Februar 2019 14:40:34 UTC+1 schrieb Thomas Keffer:
>
> Well, that was a record short release. We found a serious bug in v3.9.0 
> that could break skins that do not have fonts defined, such as cmon.
>
> So, we are releasing v3.9.1, found in the usual place 
> .
>
> -tk
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Re: NOAA reports not available

[bgrattan]

Matt,

Thanks for the quick reply. I've been trying to fix things and forgot to 
clean up some of the test code changes, sorry. However, when I make the 
corrections the drop down NOAA menus are still missing. I have attached my 
corrected index.html.tmpl file.
No errors are showing up that I see. Thanks.
Bob

On Friday, February 8, 2019 at 10:41:28 AM UTC-5, mwall wrote:
>
>
>
> On Friday, February 8, 2019 at 10:04:35 AM UTC-5, bgrattan wrote:
>>
>> Any idea what's going on here? You say its working for you but I can't 
>> seem to find the correct setting to have both the forecast and NOAA 
>> summaries. I have attached my Standard/skin.conf
>>
>
> in your index.html.tmpl you have commented out the cheetah code that 
> generates the 'select' items for the NOAA menus.
>
> this is what i see in your generated html:
>
> 
>
> -Select month-
> 
> 
> Yearly summary:
> 
> 
> -Select year-
> 
>
> this is what is in the original index.html.tmpl:
>
> 
> #for $monthYear in $SummaryByMonth
> $monthYear
> #end for
> -Select month-
> 
> 
> Yearly summary:  
>  
> 
> #for $yr in $SummaryByYear
> $yr
> #end for
> -Select year-
> 
>
> you have removed the '#for' loops, so the menus are not generated.
>
> 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.
For more options, visit https://groups.google.com/d/optout.


indexn4mrv.html.tmpl
Description: Binary data

[weewx-user] Re: WH65B no pressure

[G Hammer]

You can purchase a WH25B then you'll have indoor temp humidity and 
barometer with SDR.
I spent quite a bit of time on sniffing the data and eventually decided to 
get the dongle and WH25B and forget Interceptor.


On Tuesday, January 1, 2019 at 7:03:59 AM UTC-5, Zsolt Máté wrote:
>
> I tried, something is not working or I'm doing something wrong.
>
> On Wednesday, January 2, 2019 at 12:53:42 AM UTC+13, Andrew Milner wrote:
>>
>> with the interceptor driver
>>
>>
>>
>> On Tuesday, 1 January 2019 13:42:18 UTC+2, Zsolt Máté wrote:
>>>
>>> I ran tcpdump on my router an I got this:
>>> GET 
>>> /weatherstation/updateweatherstation.php?ID=*==72.5=64.4=59.7=64.4=52=85=0.0=0.0=198=29.63=29.60=0.00=0.00=0.31=0.00=0.00=0=2019-1-1%2011:38:47=EasyWeatherV1.2.3=updateraw=1=5
>>>  
>>> HTTP/1.0
>>>
>>> The question is, how can I intercept and interpret this communication 
>>> from my raspi?
>>>
>>> On Wednesday, January 2, 2019 at 12:32:34 AM UTC+13, Zsolt Máté wrote:

 The console has no USB port, it's communicating via WiFi.

 On Tuesday, January 1, 2019 at 8:05:28 PM UTC+13, mwall wrote:
>
>
>
> On Tuesday, January 1, 2019 at 12:10:46 AM UTC-5, Zsolt Máté wrote:
>>
>>
>> Is there a way to get the barometer readout as well?
>>
>
> not using rtl_433/weewx-sdr.  the pressure sensor is located in your 
> weather station console, so the pressure data are never sent.  rtl_433 
> picks up only the transmissions from the instrument cluster (and any 
> remote 
> temperature/humidity sensors), not the console.
>
> you'll have to intercept the data sent by the console (e.g., using the 
> weewx-interceptor driver) or figure out some way to probe the console for 
> data (does it have a usb port that responds to data requests?)
>
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Re: NOAA reports not available

[mwall]

On Friday, February 8, 2019 at 10:04:35 AM UTC-5, bgrattan wrote:
>
> Any idea what's going on here? You say its working for you but I can't 
> seem to find the correct setting to have both the forecast and NOAA 
> summaries. I have attached my Standard/skin.conf
>

in your index.html.tmpl you have commented out the cheetah code that 
generates the 'select' items for the NOAA menus.

this is what i see in your generated html:


   
-Select month-


Yearly summary:


-Select year-


this is what is in the original index.html.tmpl:


#for $monthYear in $SummaryByMonth
$monthYear
#end for
-Select month-


Yearly summary:  
 

#for $yr in $SummaryByYear
$yr
#end for
-Select year-


you have removed the '#for' loops, so the menus are not generated.

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.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Re: NOAA reports not available

[bgrattan]

Matt,

I have upgraded to weewx 3.9.1 and forecast 3.3.2. I thought all was fine 
but then found that my NOAA summary drop down menus had disappeared again. 
I added the forecast_compact to the Standard skin (with your help, thanks) 
and everything seems good except the NOAA menus.  The NOAA *.txt files are 
being created properly.

Once again, if I remove the "search_list_extensions = 
user.forecast.ForecastVariables" from skin.conf under [CheetahGenerator] 
the NOAA drop downs are available but then the compact forecast is gone.

Any idea what's going on here? You say its working for you but I can't seem 
to find the correct setting to have both the forecast and NOAA summaries. I 
have attached my Standard/skin.conf

Thanks,
Bob

http://grattans.org/wx

##
On Wednesday, February 6, 2019 at 10:25:09 AM UTC-5, mwall wrote:
>
> another data point:  forecast 3.3.2 works fine with the standard skin, as 
> show in the attached screenshot.
>
> i included the forecast by adding two lines to index.html.tmpl in the 
> Standard skin:
>
>   
>
> 
> #include "forecast_compact.inc"
>
> 
>   
> Current Conditions
>   
>
> the NOAA menus work 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.
For more options, visit https://groups.google.com/d/optout.
 ###
# STANDARD SKIN CONFIGURATION FILE#
# Copyright (c) 2010 Tom Keffer#
###

[Extras]
# Put any extra tags here that you want to be available in the templates

# Here's an example. 
# This radar image would be available as $Extras.radar_img
radar_img = http://radar.weather.gov/ridge/lite/NCR/AKQ_loop.gif
# This URL will be used as the image hyperlink:
radar_url = 
http://radar.weather.gov/ridge/radar.php?product=NCR=AKQ=yes

# Here's another. If you have a Google Analytics ID, uncomment and edit 
# the next line, and the analytics code will automatically be included
# in your generated HTML files:
#googleAnalyticsId = UA-12345678-1

###

[Units]
# This section is for managing the selection and formatting of units.

[[Groups]]
# For each group of measurements, this section sets what units to
# use for it.
# NB: The unit is always in the singular. I.e., 'mile_per_hour',
# NOT 'miles_per_hour'

group_altitude = foot # Options are 'foot' or 
'meter'
group_degree_day   = degree_F_day # Options are 'degree_F_day' 
or 'degree_C_day'
group_direction= degree_compass
group_moisture = centibar
group_percent  = percent
group_pressure = inHg # Options are 'inHg', 'mmHg', 
'mbar', or 'hPa'
group_radiation= watt_per_meter_squared
group_rain = inch # Options are 'inch', 'cm', 
or 'mm'
group_rainrate = inch_per_hour# Options are 
'inch_per_hour', 'cm_per_hour', or 'mm_per_hour'
group_speed= mile_per_hour# Options are 
'mile_per_hour', 'km_per_hour', 'knot', or 'meter_per_second'
group_speed2   = mile_per_hour2   # Options are 
'mile_per_hour2', 'km_per_hour2', 'knot2', or 'meter_per_second2'
group_temperature  = degree_F # Options are 'degree_F' or 
'degree_C'
group_uv   = uv_index
group_volt = volt

# The following are used internally and should not be changed:
group_count= count
group_interval = minute
group_time = unix_epoch
group_elapsed  = second

[[StringFormats]]
# This section sets the string formatting for each type of unit.

centibar   = %.0f
cm = %.2f
cm_per_hour= %.2f
degree_C   = %.1f
degree_F   = %.1f
degree_compass = %.0f
foot   = %.0f
hPa= %.1f
hour   = %.1f
inHg   = %.3f
inch   = %.2f
inch_per_hour  = %.2f
km_per_hour= %.0f
km_per_hour2   = %.1f
knot   = %.0f
knot2  = %.1f
mbar   = %.1f
meter  = %.0f
meter_per_second   = %.1f
meter_per_second2  = %.1f
mile_per_hour  = %.0f
mile_per_hour2 = %.1f
mm 

Re: [weewx-user] Re: I have looked for days trying to change the output of W/m² to lux.

[Greg Troxel]

Colin Larsen  writes:

> I believe it's a pretty complicated beast to do properly but a factor of
> Lux * 0.0079 gets you W/m2 (approx?) from what I've read . so just the
> reverse?
> I'm looking at sensors at the moment that output Lux and converting it to
> Wm/2 which where I found that conversion.

It simply does not make technical sense to convert a sensor value in
W/m^2 to lux (which is lm/m^2, lm being lumen).  They are incompatible
units measuring different things.

Sensors like the Davis solar radiation sensor measure "irradiance" in
W/m^2, which is the amount of power arriving in an area.  By definition,
power at all wavelengths is treated equally.

lux is a unit of illuminance, which measures the amount of light in an
area in terms of the response of the human eye, according to a
standardized response curve obtained from experiments.

For a single wavelength, one can ask what the value of one measurement
is given the other, multiplying or dividing by the standarized response
curve.  Using a spectroradiometer, one can measure the power at a
variety of wavelenghts, say at 10 nm intervals, and then sum the
converted powers.

Another way to obtain lux is to use a device with a filter that matches
the standard curve.   There are instruments for lighting, and for
photography that do this.   There are also sky brightness meters (which
I have read about but do have not experience with):
  http://unihedron.com/projects/darksky/

Typically people care about illuminance for management of artificial
lighting or light pollution, and the values are very low compared to
values that can be read on a solar radiation sensor.

This stackexchange answer claims 6.8 mW/m^2 at full moon, and a full
moon is known to produce about 0.3 lux.  Note that this ratio cannot be
applied to sunlight; moonlight has a very high color temperature,
meaning that it has more blue than red compared to sunlight.
https://physics.stackexchange.com/questions/89181/how-is-the-earth-heated-by-a-full-moon#89197

So basically, you just cannot convert sensor output and weewx should not
try.  If you want to measure lux you need a lux sensor, and to measure
W/m^w you need a radiation sensor.

One could go out on a limb and start making assumptions about the
spectral distribution of different kinds of daylight that are likely for
various irradiance levels.  For example, full sun with no clouds is well
characterized.  But as soon as you get into dawn/dusk and clouds, there
is much more variability.  Trying to guess spectral distribution based
on illuminance or irradiance and converting, and comparing that to a
sensor that measures the other, would be an interesting science
experiment.

https://en.wikipedia.org/wiki/Photometry_(optics)

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: NOAA Reports Belchertown Skin

[Pat]

The NOAA files Belchertown skin are using are from the Standard skin. When 
comparing 3.9.1's Standard skin NOAA files, there are no changes to what 
Belchertown has now. It appears as though the Belchertown NOAA files 
already have the same Barometer checks 

 that 
Standard does. 

However, when comparing 3.9.1's Season's NOAA files, there's plenty of 
changes but seem limited to just taking advantage of the newer .format() 
options (e.g. add_label=False). 



On Friday, February 8, 2019 at 12:10:05 AM UTC-5, gjr80 wrote:
>
> Ah yes, should have remembered there is a check in the NOAA templates to 
> see whether data is to be output for that row (day or month) - the check is 
> whether there is barometer data for that row. No barometer data the row is 
> left blank, have barometer data the row is populated. This has come up 
> before and I thought it was addressed, perhaps not. Then again, as the 
> results you posted so far you did not actually run the Standard skin (the 
> Belchertown skin was being called under [[StandardReport]]) it is possible 
> the Standard skin NOAA templates were fixed but perhaps the Belchertown 
> NOAA templates have not been similarly fixed. Needs more investigation, at 
> least we know where to look now.
>
> thanks
>
> Gary  
>
> On Friday, 8 February 2019 14:58:37 UTC+10, tor...@torrin.org wrote:
>>
>> Well, it appears that I solved this.  I picked up a WH25 to get barometer 
>> and inside temp to weewx until I could figure out how to capture the 
>> WH32B.  Once I started capturing a barometer reading again, it started 
>> generating the NOAA reports.  Odd, but that was the only thing IO changed.  
>> I will let it run overnight, then work to upgrade to 3.91.
>>
>>
>>
>> On Monday, February 4, 2019 at 9:02:05 AM UTC-6, tor...@torrin.org wrote:
>>>
>>> Thanks guys, I am travelling and will be away from my pi until Thursday, 
>>> I will try the suggested changes then and report back.
>>>
>>> Thanks!
>>>
>>> On Sunday, February 3, 2019 at 10:47:42 PM UTC-6, gjr80 wrote:

 I agree with Pat that some changes are needed to [StdReport]. I don't 
 expect the Belchertown extension would be interfering with other skins, 
 but 
 for some reason it appears that a number of settings in [StdReport] 
 have changed from default and would appear to be conflicting (the 
 conflicts 
 may not be the cause of the problem but they certainly limit 
 troubleshooting). We should have been seeing [[StandardReport]] and 
 [[Belchertown]] both producing NOAA format reports. Unfortunately the skin 
 = Belchertown setting under [[StandardReport]] meant that the Standard 
 skin was never called. As it turns out even if [[StandardReport]] had skin 
 = Standard we would not have had any Standard skin NOAA reports to 
 look at as the HTML_ROOT = /var/www/html/weewx appearing under 
 [StdReport] and [[Belchertown]] would mean that all NOAA reports 
 (whether from the Standard skin or Belchertown skin would have gone to 
 /var/www/html/weewx/NOAA and since the Belchertown report was listed 
 after StandardReport the Belchertown NOAA files would have overwritten 
 those generated by StandardReport.

 I suggest a few changes to [StdReport] so we can see if both the 
 Standard skin and Belchertown are having the same problem generating the 
 NOAA reports. Based on the Belchertown and WeeWX defaults I would change 
 [StdReport] to be:

 [StdReport]

 # Where the skins reside, relative to WEEWX_ROOT
 SKIN_ROOT = /etc/weewx/skins

 # Where the generated reports should go, relative to WEEWX_ROOT
 HTML_ROOT = /var/www/html/weewx

 # The database binding indicates which data should be used in reports.
 data_binding = wx_binding

 # Each of the following subsections defines a report that will be run.

 [[StandardReport]]
 # See the customizing guide to change the units, plot types and 
 line
 # colors, modify the fonts, display additional sensor data, and 
 other
 # customizations. Many of those changes can be made here by 
 overriding
 # parameters, or by modifying templates within the skin itself.

 # The StandardReport uses the 'Standard' skin, which contains the
 # images, templates and plots for the report.
 skin = Standard
 [[Highcharts_Belchertown]]
 HTML_ROOT = /var/www/html/weewx/belchertown
 skin = Highcharts_Belchertown
 [[Belchertown]]
 HTML_ROOT = /var/www/html/weewx/belchertown
 skin = Belchertown
 [[[Extras]]]
 footer_copyright_text = "mydomain.com"
 forecast_enabled = 1
 darksky_secret_key = 

[weewx-user] Re: NEW!!! --- OutOfSpan: Attempt to merge an accumulator whose timespan is not a subset

[Bryan Peter]

Matthew,

 Sorry forgot to answer your question on wx_ftp_upload and wx_cp_index. 
They are a couple of services I added in the early days of using weewx
wx_ftp_load - to upload some camera images from my local directories. I 
could easily remove and put the images in the html path, but just haven't 
got around to it.
wx_cp_index -  I was using as a cheap copy of the index.html file to a 
network drive so I can have a monitoring system check to see if the weewx 
system has failed and perform some restart operations and send out some 
admin email messages. One of my remote sites uses a couple of cheap 
TEMPerHum sensors that I have had  trouble with causing USB hangs on the 
RPi, so monitoring for a stale index file was the approach I took to detect 
this type of system failure. As you know USB hangs are problematic for 
Acurite stations as sometimes the Acurite stations stop talking completely 
when it happens. Only solution I have found that works consistently is to 
power down the weewx RPi and wait for 30mins for the Acurite to reset 
itself due to no USB traffic then reboot the RPi. So I set up a separate 
RPi as a system monitor and it handles all that via GPIO pins on the weewx 
RPi

As for stale data I have just started seeing that from both stations that 
past few weeks, generally not an issue. My thinking is that the batteries 
in the 5 in 1's are reaching the end of the life cycle and will need to be 
changed.

Thanks,

On Tuesday, February 5, 2019 at 9:22:37 AM UTC-5, mwall wrote:
>
> the OutOfSpan failure killed the report thread, and that brought down 
> weewx.  imho this is a bug - weewx should continue to collect data, even if 
> the report thread cannot do its job.  however, tom and gary know the 
> accumulator code better than i do, so they could say whether OutOfSpan 
> should be a fatal failure, versus a just "restart the report engine" 
> failure.  but first we need to know the root cause of OutOfSpan.
>
> a few observations:
>
> - here is the analysis of report generation times from the syslog.2 file.  
> nothing unusual here.
>
> report cycle for record 2019-02-01 06:28:00
> StdReport - 14 files in 18.82s + 36 images in 18.89s
> cmon - 1 file in 0.7s + 32 images in 82.48s
> exfoliation - 9 files in 100.62s + 62 images in 38.07s
> forecast - 12 files in 110.11s
> ftp - 353 files in 110.13s
>
> report cycle for record 2019-02-01 03:35:00
> skipped because report generator still running previous record
>
> report cycle for record 2019-02-01 06:42:00
> StdReport - 14 files in 5.53s + 12 images in 3.07s
> cmon - 1 file in 0.15s + 32 images in 81.32s
> exfoliation - 8 files in 9.64s + 48 images in 27.97s
> forecast - 12 files in 82.3s
> ftp - 127 files in 35.62s
>
> report cycle for record 2019-02-01 06:49:00
> StdReport - 14 files in 2.89s + 12 images in 2.89s
> cmon - 1 file in 0.15s + 32 images in 81.12s
> exfoliation - 8 files in 9.63s + 28 images in 9.37s
> forecast 12 files in 83.02s
> ftp - 107 files in 33.38s
>
> so the first run is longer, as expected.  you should see longer report 
> generation times whenever the monthly/yearly plots are updated as well.
>
> you could eliminate LOTS of overhead by removing the forecast skin.  the 
> exfoliation skin has forecast reporting built in, so you don't need the 
> forecast skin too.  the forecast skin is designed to illustrate how 
> forecasting works and to provide lots of examples of how to use it.  you 
> probably don't want to run it in 'production'.
>
> - what are wx_ftp_upload and wx_cp_index?
>
> - you are getting stale data from the acurite sensor cluster (see circa 
> 07:13:47 in syslog.2). this is not unusual, but if it happens a lot then 
> you should look at way of making your connection stronger (eliminate 
> interference, re-orient the console, put console closer to sensors, dance 
> naked around a fire at the next full moon, etc).
>
> - you might want to plot the 'ignoring stale data' messages over time.  
> that is a good way to see if there is a pattern to the interference timing.
>
> - don't generate forecasts any more often than you must.  once every 4 
> hours is typically sufficient.  i think exfoliation is set up to do this - 
> it only generates forecast.html every 4 hours.  and the forecast download 
> services are set up to download the data based on when the sources update.  
> once again, get rid of forecast skin, because i think it regenerates every 
> report cycle, even though that frequency is pointless.
>
> - be sure that you have a sane max_age in the [Forecast] section in 
> weewx.conf.  something like 604800 is reasonable.  you should only use 
> max_age=none if you intend to retain forecasts indefinitely, e.g., for 
> doing forecast comparisons over extended periods.
>
>

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

Re: [weewx-user] Re: NEW!!! --- OutOfSpan: Attempt to merge an accumulator whose timespan is not a subset

[Bryan Peter]

Tom,

It seems that with Acurite no matter what setting is for record 
generation it is really always using software. I have run a couple of tests 
with different archive_interval settings that indicate there is some kind 
of issue with the accumulator (accum.py) code that triggers this shutdown. 
If I use an archive_interval value that is integer divisible into the 
1440mins, I used 360 for my test, of a 1 day cycle the timestamp for 
weewx.sdb record additions matches to the minute with the system time stamp 
in the syslog log. However, if I use the archive_interval of 7min (420), or 
I suspect 14min (840) the timestamps for weewx.sdb get off track pretty 
quickly (the issue that Gary pointed out).

As you say this is likely a small issue, but may make sense at some point 
to not allow certain archive intervals given that they cause issues for 
accumulated stat generation processes.

As an aside, why does cmon skin always have the correct and exact match to 
the system timestamp for its record add time? I'm assuming it is because it 
does not need to do accumulated stats so it just grabs the system time 
instead of calculating time as accum.py, manager.py, and engine.py do. 

Thanks,

Bryan

On Tuesday, February 5, 2019 at 9:43:58 AM UTC-5, Thomas Keffer wrote:
>
> On Tue, Feb 5, 2019 at 6:22 AM mwall > 
> wrote:
>
>> the OutOfSpan failure killed the report thread, and that brought down 
>> weewx.  imho this is a bug - weewx should continue to collect data, even if 
>> the report thread cannot do its job. 
>>
>
> I'm not seeing that. When the engine shuts down, it calls the shutDown() 
> method of all running services. Then the engine exits. I think what you are 
> seeing is the results of calling StdReport.shutDown().
>
> Perhaps this could be made more clear by having the engine put a message 
> in the log to the effect ("Engine exiting; starting shutdown of all 
> services") before calling all the shutDown() methods.
>
> As to the root cause, it's probably the unusual archive interval (420 
> seconds). There may be an underlying assumption in the code that the 
> midnight boundary will always fall at the end of an archive interval and, 
> when it doesn't, this failure occurs. I'd have to test.
>
> But, is it important? Yes, there's probably a bug, but it's a pretty minor 
> one. Alternatively, we could test the archive interval to make sure it's 
> divisible into 60 and refuse to run if it isn't.
>
> -tk
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: NEW!!! --- OutOfSpan: Attempt to merge an accumulator whose timespan is not a subset

[Bryan Peter]

Matthew,

 Thanks for the helpful tips will implement to reduce overhead. It runs 
fairly sanely with an archive interval of 360 with forecast skin in so 
taking that out should get me back to 300.

Best,

Bryan


On Tuesday, February 5, 2019 at 9:22:37 AM UTC-5, mwall wrote:
>
> the OutOfSpan failure killed the report thread, and that brought down 
> weewx.  imho this is a bug - weewx should continue to collect data, even if 
> the report thread cannot do its job.  however, tom and gary know the 
> accumulator code better than i do, so they could say whether OutOfSpan 
> should be a fatal failure, versus a just "restart the report engine" 
> failure.  but first we need to know the root cause of OutOfSpan.
>
> a few observations:
>
> - here is the analysis of report generation times from the syslog.2 file.  
> nothing unusual here.
>
> report cycle for record 2019-02-01 06:28:00
> StdReport - 14 files in 18.82s + 36 images in 18.89s
> cmon - 1 file in 0.7s + 32 images in 82.48s
> exfoliation - 9 files in 100.62s + 62 images in 38.07s
> forecast - 12 files in 110.11s
> ftp - 353 files in 110.13s
>
> report cycle for record 2019-02-01 03:35:00
> skipped because report generator still running previous record
>
> report cycle for record 2019-02-01 06:42:00
> StdReport - 14 files in 5.53s + 12 images in 3.07s
> cmon - 1 file in 0.15s + 32 images in 81.32s
> exfoliation - 8 files in 9.64s + 48 images in 27.97s
> forecast - 12 files in 82.3s
> ftp - 127 files in 35.62s
>
> report cycle for record 2019-02-01 06:49:00
> StdReport - 14 files in 2.89s + 12 images in 2.89s
> cmon - 1 file in 0.15s + 32 images in 81.12s
> exfoliation - 8 files in 9.63s + 28 images in 9.37s
> forecast 12 files in 83.02s
> ftp - 107 files in 33.38s
>
> so the first run is longer, as expected.  you should see longer report 
> generation times whenever the monthly/yearly plots are updated as well.
>
> you could eliminate LOTS of overhead by removing the forecast skin.  the 
> exfoliation skin has forecast reporting built in, so you don't need the 
> forecast skin too.  the forecast skin is designed to illustrate how 
> forecasting works and to provide lots of examples of how to use it.  you 
> probably don't want to run it in 'production'.
>
> - what are wx_ftp_upload and wx_cp_index?
>
> - you are getting stale data from the acurite sensor cluster (see circa 
> 07:13:47 in syslog.2). this is not unusual, but if it happens a lot then 
> you should look at way of making your connection stronger (eliminate 
> interference, re-orient the console, put console closer to sensors, dance 
> naked around a fire at the next full moon, etc).
>
> - you might want to plot the 'ignoring stale data' messages over time.  
> that is a good way to see if there is a pattern to the interference timing.
>
> - don't generate forecasts any more often than you must.  once every 4 
> hours is typically sufficient.  i think exfoliation is set up to do this - 
> it only generates forecast.html every 4 hours.  and the forecast download 
> services are set up to download the data based on when the sources update.  
> once again, get rid of forecast skin, because i think it regenerates every 
> report cycle, even though that frequency is pointless.
>
> - be sure that you have a sane max_age in the [Forecast] section in 
> weewx.conf.  something like 604800 is reasonable.  you should only use 
> max_age=none if you intend to retain forecasts indefinitely, e.g., for 
> doing forecast comparisons over extended periods.
>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: Run Cumulus in another PC and weewx on raspberry.

[Andrew Milner]

Assuming that you only need an easyweather.dat file in the format described 
here

https://cumuluswiki.wxforum.net/a/EasyWeather_Format

and only the fields in bold are used by cumulus then it should be easy 
enough to create such a data file just by creating the appropriate template 
called easyweather.dta.tmpl and letting weewx populate the fields.

Whilst you will no doubt need an appropriate number of commas to skip over 
the unused fields you will need to experiment to see if you need the raw  
data on the end of each record.





On Friday, 8 February 2019 09:22:06 UTC+2, Ruben Navarro Huedo wrote:
>
> I think Cumulus can only read easyweather format files.
> I don't find a Easyweather output extension for weewx.
>
> Thank's for your answer.
>
> El viernes, 8 de febrero de 2019, 6:13:24 (UTC+1), gjr80 escribió:
>>
>> Hi,
>>
>> Suggest the way ahead is for you to find out what Cumulus can read/accept 
>> and then come back and see how that could be supported by WeeWX. I could 
>> suggest a dozen different file output formats that WeeWX can produce but I 
>> will guarantee that most will not work with Cumulus.
>>
>> Gary
>>
>> On Friday, 8 February 2019 08:59:05 UTC+10, Ruben Navarro Huedo wrote:
>>>
>>> Hello friends:
>>>
>>> I am running weewx in a raspberry.
>>> Using Meteostick connected to the raspberry.
>>> I want run cumulus in my desktop computer.
>>> Raspberry has samba installed.
>>> My question is:  Do you know if cumulus can read weather data from a 
>>> file exported by weewx?
>>> If yes... what extension do i need?
>>>
>>

-- 
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.
For more options, visit https://groups.google.com/d/optout.