subject:"Re\: \[weewx\-user\] Questions about weewx\-loopdata"

> remote_server = ftpupload.net
I would expect the remote server to be kairos.moudania.com
It looks like you are trying to use an ftp server.  If so, that simply won’t 
work.
If you don’t have ssh access to your server, such that you can get rsync to 
work, you will not be able to use the loopdata extension.

> On Jan 26, 2021, at 12:00 PM, Δημήτρης Βήχος  wrote:
> 
> i have setup for loopdata
> 
> [LoopData]
> [[FileSpec]]
> loop_data_dir = .
> filename = loop-data.txt
> [[Formatting]]
> target_report = LoopDataReport
> [[LoopFrequency]]
> seconds = 30
> [[RsyncSpec]]
> enable = true
> remote_server = ftpupload.net
> remote_user = epiz_27298028
> remote_dir = /htdocs/test
> compress = true
> log_success = true
> ssh_options = -o ConnectTimeout=1
> timeout = 1
> skip_if_older_than = 3
> [[Include]]
> fields = trend.outTemp, trend.barometer.desc, current.barometer, 
> current.dateTime.raw, current.dewpoint, current.dewpoint.formatted, 
> current.heatindex, current.outHumidity, current.outTemp, 
> current.outTemp.formatted, current.rain, current.rainRate, 
> current.rainRate.formatted, current.windchill, 
> current.windDir.ordinal_compass, current.windSpeed, 
> current.windSpeed.formatted, current.windSpeed.raw, 
> 10m.outTemp.max.formatted, 10m.outTemp.min.formatted, 10m.rain.sum.formatted, 
> 10m.wind.rms.formatted, 10m.windGust.max, 10m.windGust.max.formatted, 
> day.outTemp.max.formatted, day.outTemp.min.formatted, day.rain.sum, 
> day.rain.sum.formatted, day.wind.rms.formatted, day.windGust.max, 
> day.windGust.max.formatted, week.outTemp.max.formatted, 
> week.outTemp.min.formatted, week.rain.sum.formatted, week.wind.rms.formatted, 
> week.windGust.max.formatted, month.outTemp.max.formatted, 
> month.outTemp.min.formatted, month.rain.sum.formatted, 
> month.wind.rms.formatted, month.windGust.max.formatted, 
> year.outTemp.max.formatted, year.outTemp.min.formatted, 
> year.rain.sum.formatted, year.wind.rms.formatted, 
> year.windGust.max.formatted, rainyear.outTemp.max.formatted, 
> rainyear.outTemp.min.formatted, rainyear.rain.sum.formatted, 
> rainyear.wind.rms.formatted, rainyear.windGust.max.formatted
> [[BarometerTrendDescriptions]]
> RISING_VERY_RAPIDLY = Rising Very Rapidly
> RISING_QUICKLY = Rising Quickly
> RISING = Rising
> RISING_SLOWLY = Rising Slowly
> STEADY = Steady
> FALLING_SLOWLY = Falling Slowly
> FALLING = Falling
> FALLING_QUICKLY = Falling Quickly
> FALLING_VERY_RAPIDLY = Falling Very Rapidly
> 
> Στις Τρίτη, 26 Ιανουαρίου 2021 στις 9:12:55 μ.μ. UTC+2, ο χρήστης 
> jo...@johnkline.com έγραψε:
>> As the README states:
>> If you need the loop-data.txt file pushed to a remote webserver, you will 
>> also need to fill in the RsyncSpec fields; but one can fill that in later, 
>> after LoopData is up and running.
>> 
>> It appears loopdata is up and running and working on the local machine.  
>> Have you set up rsync for loopdata?
>> 
>> Please see the following sections of the README:
>> 
>> https://github.com/chaunceygardiner/weewx-loopdata#entries-in-loopdata-sections-of-weewxconf
>> 
>> https://github.com/chaunceygardiner/weewx-loopdata#rsync-isnt-working-for-me-help
>> 
>> https://github.com/chaunceygardiner/weewx-loopdata#do-i-have-to-use-rsync-to-sync-loop-datatxt-to-a-remote-server
>> 
>> https://github.com/chaunceygardiner/weewx-loopdata#what-about-those-rsync-errors-in-the-log
>> 
 On Jan 26, 2021, at 10:34 AM, Δημήτρης Βήχος  wrote:
 
>>> its correct i have remote server. in remote server uploading the 
>>> loop-data.txt but uploadind every 5 minutes . 
>> 
>>> 
>>> 
>>> Στις Τρίτη, 26 Ιανουαρίου 2021 στις 6:20:42 μ.μ. UTC+2, ο χρήστης 
>>> jo...@johnkline.com έγραψε:
 OK, the behavior we are seeing leads me to believe your web server is on a 
 remote machine; i.e., not on the same machine as weewx.  Is that correct?  
 If so, you’ll need to use rsync by filling out and enabling it under:
 
 [LoopData]
 [[RsyncSpec]]
 
 
>> On Jan 26, 2021, at 7:57 AM, Δημήτρης Βήχος  wrote:
>> 
> well the actuall  /loopdata   localhost/weewx/loopdata  , refreshing 
> every 60 seconds its ok. but in weather page  refreshing every 5 minutes
> 
> Στις Τρίτη, 26 Ιανουαρίου 2021 στις 5:45:32 μ.μ. UTC+2, ο χρήστης 
> jo...@johnkline.com έγραψε:
>> Again, how often does your driver write loop records?
>> 
>> loop-data.txt is not written in reporting cycles.  I am asking you to 
>> look at the actual loop-data.txt file that is written to the 
>> .../loopdata directory.  How often does the contents of that file change.
>> 
>> Also, please show what entries you are seeing in the log every one 
>> minute.
>> 
 On Jan 26, 2021, at 7:37 AM, Δημήτρης Βήχος  
 wrote:

Re: [weewx-user] Questions about weewx-loopdata

i have setup for loopdata

[LoopData]
[[FileSpec]]
loop_data_dir = .
filename = loop-data.txt
[[Formatting]]
target_report = LoopDataReport
[[LoopFrequency]]
seconds = 30
[[RsyncSpec]]
enable = true
remote_server = ftpupload.net
remote_user = epiz_27298028
remote_dir = /htdocs/test
compress = true
log_success = true
ssh_options = -o ConnectTimeout=1
timeout = 1
skip_if_older_than = 3
[[Include]]
fields = trend.outTemp, trend.barometer.desc, current.barometer, 
current.dateTime.raw, current.dewpoint, current.dewpoint.formatted, 
current.heatindex, current.outHumidity, current.outTemp, 
current.outTemp.formatted, current.rain, current.rainRate, 
current.rainRate.formatted, current.windchill, 
current.windDir.ordinal_compass, current.windSpeed, 
current.windSpeed.formatted, current.windSpeed.raw, 
10m.outTemp.max.formatted, 10m.outTemp.min.formatted, 
10m.rain.sum.formatted, 10m.wind.rms.formatted, 10m.windGust.max, 
10m.windGust.max.formatted, day.outTemp.max.formatted, 
day.outTemp.min.formatted, day.rain.sum, day.rain.sum.formatted, 
day.wind.rms.formatted, day.windGust.max, day.windGust.max.formatted, 
week.outTemp.max.formatted, week.outTemp.min.formatted, 
week.rain.sum.formatted, week.wind.rms.formatted, 
week.windGust.max.formatted, month.outTemp.max.formatted, 
month.outTemp.min.formatted, month.rain.sum.formatted, 
month.wind.rms.formatted, month.windGust.max.formatted, 
year.outTemp.max.formatted, year.outTemp.min.formatted, 
year.rain.sum.formatted, year.wind.rms.formatted, 
year.windGust.max.formatted, rainyear.outTemp.max.formatted, 
rainyear.outTemp.min.formatted, rainyear.rain.sum.formatted, 
rainyear.wind.rms.formatted, rainyear.windGust.max.formatted
[[BarometerTrendDescriptions]]
RISING_VERY_RAPIDLY = Rising Very Rapidly
RISING_QUICKLY = Rising Quickly
RISING = Rising
RISING_SLOWLY = Rising Slowly
STEADY = Steady
FALLING_SLOWLY = Falling Slowly
FALLING = Falling
FALLING_QUICKLY = Falling Quickly
FALLING_VERY_RAPIDLY = Falling Very Rapidly

Στις Τρίτη, 26 Ιανουαρίου 2021 στις 9:12:55 μ.μ. UTC+2, ο χρήστης 
jo...@johnkline.com έγραψε:

> As the README states:
>
>- If you need the loop-data.txt file pushed to a remote webserver, you 
>will also need to fill in the RsyncSpec fields; but one can fill that 
>in later, after LoopData is up and running.
>
>
> It appears loopdata is up and running and working on the local machine. 
>  Have you set up rsync for loopdata?
>
> Please see the following sections of the README:
>
>
> https://github.com/chaunceygardiner/weewx-loopdata#entries-in-loopdata-sections-of-weewxconf
>
>
> https://github.com/chaunceygardiner/weewx-loopdata#rsync-isnt-working-for-me-help
>
>
> https://github.com/chaunceygardiner/weewx-loopdata#do-i-have-to-use-rsync-to-sync-loop-datatxt-to-a-remote-server
>
>
> https://github.com/chaunceygardiner/weewx-loopdata#what-about-those-rsync-errors-in-the-log
>
> On Jan 26, 2021, at 10:34 AM, Δημήτρης Βήχος  wrote:
>
> its correct i have remote server. in remote server uploading the 
> loop-data.txt but uploadind every 5 minutes . 
>
>
>
> Στις Τρίτη, 26 Ιανουαρίου 2021 στις 6:20:42 μ.μ. UTC+2, ο χρήστης 
> jo...@johnkline.com έγραψε:
>
>> OK, the behavior we are seeing leads me to believe your web server is on 
>> a remote machine; i.e., not on the same machine as weewx.  Is that correct? 
>>  If so, you’ll need to use rsync by filling out and enabling it under:
>>
>> [LoopData]
>> [[RsyncSpec]]
>>
>>
>> On Jan 26, 2021, at 7:57 AM, Δημήτρης Βήχος  wrote:
>>
>> well the actuall  /loopdata   localhost/weewx/loopdata  , refreshing 
>> every 60 seconds its ok. but in weather page  refreshing every 5 minutes
>>
>> Στις Τρίτη, 26 Ιανουαρίου 2021 στις 5:45:32 μ.μ. UTC+2, ο χρήστης jo...@
>> johnkline.com έγραψε:
>>
>>> Again, how often does your driver write loop records?
>>>
>>> loop-data.txt is not written in reporting cycles.  I am asking you to 
>>> look at the actual loop-data.txt file that is written to the .../loopdata 
>>> directory.  How often does the contents of that file change.
>>>
>>> Also, please show what entries you are seeing in the log every one 
>>> minute.
>>>
>>> On Jan 26, 2021, at 7:37 AM, Δημήτρης Βήχος  wrote:
>>>
>>> loop-data.txt updates every 5 minutes in web page. but in log see 
>>> loop-data.txt every 60 secs
>>>
>>>
>>>
>>> Στις Τρίτη, 26 Ιανουαρίου 2021 στις 5:19:17 μ.μ. UTC+2, ο χρήστης 
>>> jo...@johnkline.com έγραψε:
>>>
 How often does your driver write loop records?
 Would you please check the actual loop-data.txt file, rather than the 
 skin’s report, to see if that file is being updated on every loop record?

 On Jan 26, 2021, at 7:15 AM, Δημήτρης Βήχος  
 wrote:

 the loop-data.txt 

 https://kairos.moudania.com/kolxiko/loopdata/

Re: [weewx-user] Questions about weewx-loopdata

As the README states:
If you need the loop-data.txt file pushed to a remote webserver, you will also 
need to fill in the RsyncSpec fields; but one can fill that in later, after 
LoopData is up and running.

It appears loopdata is up and running and working on the local machine.  Have 
you set up rsync for loopdata?

Please see the following sections of the README:

https://github.com/chaunceygardiner/weewx-loopdata#entries-in-loopdata-sections-of-weewxconf

https://github.com/chaunceygardiner/weewx-loopdata#rsync-isnt-working-for-me-help

https://github.com/chaunceygardiner/weewx-loopdata#do-i-have-to-use-rsync-to-sync-loop-datatxt-to-a-remote-server

https://github.com/chaunceygardiner/weewx-loopdata#what-about-those-rsync-errors-in-the-log

> On Jan 26, 2021, at 10:34 AM, Δημήτρης Βήχος  wrote:
> 
> its correct i have remote server. in remote server uploading the 
> loop-data.txt but uploadind every 5 minutes . 
> 
> Στις Τρίτη, 26 Ιανουαρίου 2021 στις 6:20:42 μ.μ. UTC+2, ο χρήστης 
> jo...@johnkline.com έγραψε:
>> OK, the behavior we are seeing leads me to believe your web server is on a 
>> remote machine; i.e., not on the same machine as weewx.  Is that correct?  
>> If so, you’ll need to use rsync by filling out and enabling it under:
>> 
>> [LoopData]
>> [[RsyncSpec]]
>> 
>> 
 On Jan 26, 2021, at 7:57 AM, Δημήτρης Βήχος  wrote:
 
>>> well the actuall  /loopdata   localhost/weewx/loopdata  , refreshing every 
>>> 60 seconds its ok. but in weather page  refreshing every 5 minutes
>>> 
>>> Στις Τρίτη, 26 Ιανουαρίου 2021 στις 5:45:32 μ.μ. UTC+2, ο χρήστης 
>>> jo...@johnkline.com έγραψε:
 Again, how often does your driver write loop records?
 
 loop-data.txt is not written in reporting cycles.  I am asking you to look 
 at the actual loop-data.txt file that is written to the .../loopdata 
 directory.  How often does the contents of that file change.
 
 Also, please show what entries you are seeing in the log every one minute.
 
>> On Jan 26, 2021, at 7:37 AM, Δημήτρης Βήχος  wrote:
>> 
> loop-data.txt updates every 5 minutes in web page. but in log see 
> loop-data.txt every 60 secs
 
> 
> 
> Στις Τρίτη, 26 Ιανουαρίου 2021 στις 5:19:17 μ.μ. UTC+2, ο χρήστης 
> jo...@johnkline.com έγραψε:
>> How often does your driver write loop records?
>> Would you please check the actual loop-data.txt file, rather than the 
>> skin’s report, to see if that file is being updated on every loop record?
>> 
 On Jan 26, 2021, at 7:15 AM, Δημήτρης Βήχος  
 wrote:
 
>>> the loop-data.txt 
>> 
>>> 
>>> https://kairos.moudania.com/kolxiko/loopdata/
>>> 
>>> Στις Τρίτη, 26 Ιανουαρίου 2021 στις 5:07:58 μ.μ. UTC+2, ο χρήστης 
>>> jo...@johnkline.com έγραψε:
 > but data refresh every 5 minutes, with the rest skins of weewx
 
 Exactly what data are you talking about that refreshes every five 
 minutes?
 
>> On Jan 26, 2021, at 6:02 AM, Δημήτρης Βήχος  
>> wrote:
>> 
> i was easily installed the loop-data extension yesterday. i use 
> weewx 4.3 with wh1080 weather station, but data refresh every 5 
> minutes, with the rest skins of weewx
 
> 
> 
> Στις Πέμπτη, 26 Νοεμβρίου 2020 στις 6:46:10 μ.μ. UTC+2, ο χρήστης 
> jo...@johnkline.com έγραψε:
>> Thanks for letting me know.
>> 
 On Nov 26, 2020, at 7:32 AM, geoffs...@gmail.com 
  wrote:
 
>>> Hi John,
>>> 
>>> Works great. Here is what I added to the loop-data.py
>>> 
>>> Line 735 self.ten_min_packets, self.cfg.ten_min_obstypes)
>>> # Added to allow specific null keys if no data 
>>> available in loop packet
>>> must_have_keys = [ 'current.dateTime', 
>>> 'current.extraTemp1.raw', 'current.extraTemp2.raw', 
>>> 'current.extraTemp3.raw', 'current.extraHumid1.raw', 
>>> 'current.extraHumid2.raw', 'current.extraHumid3.raw' ]
>>> for must_have_key in must_have_keys:
>>> if must_have_key not in loopdata_pkt:
>>> loopdata_pkt[must_have_key] = None
>>> 
>>> Thanks!
 On Wednesday, November 25, 2020 at 7:06:46 AM UTC-8 
 geoffs...@gmail.com wrote:
 Awesome! This is sort of what I suspected that most use cases, 
 NULL is a problem. I can just hard code the entire Davis loop 
 which will work for my needs.
 
 Thanks you,
 
 Geoff
 
> On Wednesday, November 25, 2020 at 6:45:44 AM UTC-8 
> jo...@johnkline.com wrote:
> In the general case, including keys in the loop packet for 
>

Re: [weewx-user] Questions about weewx-loopdata

its correct i have remote server. in remote server uploading the 
loop-data.txt but uploadind every 5 minutes . 

Στις Τρίτη, 26 Ιανουαρίου 2021 στις 6:20:42 μ.μ. UTC+2, ο χρήστης 
jo...@johnkline.com έγραψε:

> OK, the behavior we are seeing leads me to believe your web server is on a 
> remote machine; i.e., not on the same machine as weewx.  Is that correct? 
>  If so, you’ll need to use rsync by filling out and enabling it under:
>
> [LoopData]
> [[RsyncSpec]]
>
>
> On Jan 26, 2021, at 7:57 AM, Δημήτρης Βήχος  wrote:
>
> well the actuall  /loopdata   localhost/weewx/loopdata  , refreshing every 
> 60 seconds its ok. but in weather page  refreshing every 5 minutes
>
> Στις Τρίτη, 26 Ιανουαρίου 2021 στις 5:45:32 μ.μ. UTC+2, ο χρήστης jo...@
> johnkline.com έγραψε:
>
>> Again, how often does your driver write loop records?
>>
>> loop-data.txt is not written in reporting cycles.  I am asking you to 
>> look at the actual loop-data.txt file that is written to the .../loopdata 
>> directory.  How often does the contents of that file change.
>>
>> Also, please show what entries you are seeing in the log every one minute.
>>
>> On Jan 26, 2021, at 7:37 AM, Δημήτρης Βήχος  wrote:
>>
>> loop-data.txt updates every 5 minutes in web page. but in log see 
>> loop-data.txt every 60 secs
>>
>>
>>
>> Στις Τρίτη, 26 Ιανουαρίου 2021 στις 5:19:17 μ.μ. UTC+2, ο χρήστης 
>> jo...@johnkline.com έγραψε:
>>
>>> How often does your driver write loop records?
>>> Would you please check the actual loop-data.txt file, rather than the 
>>> skin’s report, to see if that file is being updated on every loop record?
>>>
>>> On Jan 26, 2021, at 7:15 AM, Δημήτρης Βήχος  wrote:
>>>
>>> the loop-data.txt 
>>>
>>>
>>> https://kairos.moudania.com/kolxiko/loopdata/
>>>
>>> Στις Τρίτη, 26 Ιανουαρίου 2021 στις 5:07:58 μ.μ. UTC+2, ο χρήστης 
>>> jo...@johnkline.com έγραψε:
>>>
 > but data refresh every 5 minutes, with the rest skins of weewx

 Exactly what data are you talking about that refreshes every five 
 minutes?

 On Jan 26, 2021, at 6:02 AM, Δημήτρης Βήχος  
 wrote:

 i was easily installed the loop-data extension yesterday. i use weewx 
 4.3 with wh1080 weather station, but data refresh every 5 minutes, with 
 the 
 rest skins of weewx



 Στις Πέμπτη, 26 Νοεμβρίου 2020 στις 6:46:10 μ.μ. UTC+2, ο χρήστης 
 jo...@johnkline.com έγραψε:

> Thanks for letting me know.
>
> On Nov 26, 2020, at 7:32 AM, geoffs...@gmail.com  
> wrote:
>
> Hi John,
>
> Works great. Here is what I added to the loop-data.py
>
> Line 735 self.ten_min_packets, self.cfg.ten_min_obstypes)
> # Added to allow specific null keys if no data 
> available in loop packet
> must_have_keys = [ 'current.dateTime', 
> 'current.extraTemp1.raw', 'current.extraTemp2.raw', 
> 'current.extraTemp3.raw', 'current.extraHumid1.raw', 
> 'current.extraHumid2.raw', 'current.extraHumid3.raw' ]
> for must_have_key in must_have_keys:
> if must_have_key not in loopdata_pkt:
> loopdata_pkt[must_have_key] = None
>
> Thanks!
> On Wednesday, November 25, 2020 at 7:06:46 AM UTC-8 
> geoffs...@gmail.com wrote:
>
>> Awesome! This is sort of what I suspected that most use cases, NULL 
>> is a problem. I can just hard code the entire Davis loop which will work 
>> for my needs.
>>
>> Thanks you,
>>
>> Geoff
>>
>> On Wednesday, November 25, 2020 at 6:45:44 AM UTC-8 
>> jo...@johnkline.com wrote:
>>
>>> In the general case, including keys in the loop packet for 
>>> non-existent data is not a good idea.  This would break existing code 
>>> (e.g., JavaScript code I use in my skins).
>>>
>>> You could easily fork the extension and add in what you need.  At 
>>> line 736, right before write_packet_to_file is called, simply check for 
>>> the 
>>> keys you need to exist, and add them if they are not there. The 
>>> following 
>>> should work.  Just replace the keys I’ve listed with the ones you need 
>>> in 
>>> the packet.
>>>
>>> must_have_keys = [ 'current.outTemp', 'current.outHumidity' ]
>>> for must_have_key in must_have_keys:
>>> if must_have_key not in loopdata_pkt:
>>> loopdata_pkt[must_have_key] = None
>>>
>>> If you don’t want to hard code the keys, you’ll have a bigger task; 
>>> but you could just copy the code used to process the ‘fields’ entry in 
>>> the 
>>> LoopData section of weewx.conf.
>>>
>>> Cheers,
>>> John
>>>
>>> On Nov 24, 2020, at 8:54 PM, geoffs...@gmail.com <
>>> geoffs...@gmail.com> wrote:
>>>
>>> Hi John,
>>>
>>>
>>> This is a great extension. I'm wondering if there is a way to be 
>>> able to include

Re: [weewx-user] Questions about weewx-loopdata

OK, the behavior we are seeing leads me to believe your web server is on a 
remote machine; i.e., not on the same machine as weewx.  Is that correct?  If 
so, you’ll need to use rsync by filling out and enabling it under:

[LoopData]
[[RsyncSpec]]


> On Jan 26, 2021, at 7:57 AM, Δημήτρης Βήχος  wrote:
> 
> well the actuall  /loopdata   localhost/weewx/loopdata  , refreshing every 60 
> seconds its ok. but in weather page  refreshing every 5 minutes
> 
> Στις Τρίτη, 26 Ιανουαρίου 2021 στις 5:45:32 μ.μ. UTC+2, ο χρήστης 
> jo...@johnkline.com έγραψε:
> Again, how often does your driver write loop records?
> 
> loop-data.txt is not written in reporting cycles.  I am asking you to look at 
> the actual loop-data.txt file that is written to the .../loopdata directory.  
> How often does the contents of that file change.
> 
> Also, please show what entries you are seeing in the log every one minute.
> 
>> On Jan 26, 2021, at 7:37 AM, Δημήτρης Βήχος > > wrote:
>> 
>> loop-data.txt updates every 5 minutes in web page. but in log see 
>> loop-data.txt every 60 secs
> 
>> 
>> 
>> Στις Τρίτη, 26 Ιανουαρίου 2021 στις 5:19:17 μ.μ. UTC+2, ο χρήστης 
>> jo...@johnkline.com  
>> έγραψε:
>> How often does your driver write loop records?
>> Would you please check the actual loop-data.txt file, rather than the skin’s 
>> report, to see if that file is being updated on every loop record?
>> 
>>> On Jan 26, 2021, at 7:15 AM, Δημήτρης Βήχος > wrote:
>>> 
>>> the loop-data.txt 
>> 
>>> 
>>> https://kairos.moudania.com/kolxiko/loopdata/ 
>>> 
>>> 
>>> Στις Τρίτη, 26 Ιανουαρίου 2021 στις 5:07:58 μ.μ. UTC+2, ο χρήστης 
>>> jo...@johnkline.com <> έγραψε:
>>> > but data refresh every 5 minutes, with the rest skins of weewx
>>> 
>>> Exactly what data are you talking about that refreshes every five minutes?
>>> 
 On Jan 26, 2021, at 6:02 AM, Δημήτρης Βήχος > wrote:
 
 i was easily installed the loop-data extension yesterday. i use weewx 4.3 
 with wh1080 weather station, but data refresh every 5 minutes, with the 
 rest skins of weewx
>>> 
 
 
 Στις Πέμπτη, 26 Νοεμβρίου 2020 στις 6:46:10 μ.μ. UTC+2, ο χρήστης 
 jo...@johnkline.com <> έγραψε:
 Thanks for letting me know.
 
> On Nov 26, 2020, at 7:32 AM, geoffs...@gmail.com <>  <>> wrote:
> 
 
> Hi John,
> 
> Works great. Here is what I added to the loop-data.py
> 
> Line 735 self.ten_min_packets, self.cfg.ten_min_obstypes)
> # Added to allow specific null keys if no data available 
> in loop packet
> must_have_keys = [ 'current.dateTime', 
> 'current.extraTemp1.raw', 'current.extraTemp2.raw', 
> 'current.extraTemp3.raw', 'current.extraHumid1.raw', 
> 'current.extraHumid2.raw', 'current.extraHumid3.raw' ]
> for must_have_key in must_have_keys:
> if must_have_key not in loopdata_pkt:
> loopdata_pkt[must_have_key] = None
> 
> Thanks!
> On Wednesday, November 25, 2020 at 7:06:46 AM UTC-8 geoffs...@gmail.com 
> <> wrote:
> Awesome! This is sort of what I suspected that most use cases, NULL is a 
> problem. I can just hard code the entire Davis loop which will work for 
> my needs.
> 
> Thanks you,
> 
> Geoff
> 
> On Wednesday, November 25, 2020 at 6:45:44 AM UTC-8 jo...@johnkline.com 
> <> wrote:
> In the general case, including keys in the loop packet for non-existent 
> data is not a good idea.  This would break existing code (e.g., 
> JavaScript code I use in my skins).
> 
> You could easily fork the extension and add in what you need.  At line 
> 736, right before write_packet_to_file is called, simply check for the 
> keys you need to exist, and add them if they are not there. The following 
> should work.  Just replace the keys I’ve listed with the ones you need in 
> the packet.
> 
> must_have_keys = [ 'current.outTemp', 'current.outHumidity' ]
> for must_have_key in must_have_keys:
> if must_have_key not in loopdata_pkt:
> loopdata_pkt[must_have_key] = None
> 
> If you don’t want to hard code the keys, you’ll have a bigger task; but 
> you could just copy the code used to process the ‘fields’ entry in the 
> LoopData section of weewx.conf.
> 
> Cheers,
> John
> 
>> On Nov 24, 2020, at 8:54 PM, geoffs...@gmail.com <> > <>> wrote:
>> 
>> Hi John,
> 
>> 
>> This is a great extension. I'm wondering if there is a way to be able to 
>> include sending data that is null  or none for a particular key? I'm 
>> using a davis vantage pro2, weewx 4.2. I'd like to use this to make a 
>> JSON output that can be ingested into a home automation system. So far 
>> it works great as long as the data is available to be sent, but

Re: [weewx-user] Questions about weewx-loopdata

well the actuall  /loopdata   localhost/weewx/loopdata  , refreshing every 
60 seconds its ok. but in weather page  refreshing every 5 minutes

Στις Τρίτη, 26 Ιανουαρίου 2021 στις 5:45:32 μ.μ. UTC+2, ο χρήστης 
jo...@johnkline.com έγραψε:

> Again, how often does your driver write loop records?
>
> loop-data.txt is not written in reporting cycles.  I am asking you to look 
> at the actual loop-data.txt file that is written to the .../loopdata 
> directory.  How often does the contents of that file change.
>
> Also, please show what entries you are seeing in the log every one minute.
>
> On Jan 26, 2021, at 7:37 AM, Δημήτρης Βήχος  wrote:
>
> loop-data.txt updates every 5 minutes in web page. but in log see 
> loop-data.txt every 60 secs
>
>
>
> Στις Τρίτη, 26 Ιανουαρίου 2021 στις 5:19:17 μ.μ. UTC+2, ο χρήστης 
> jo...@johnkline.com έγραψε:
>
>> How often does your driver write loop records?
>> Would you please check the actual loop-data.txt file, rather than the 
>> skin’s report, to see if that file is being updated on every loop record?
>>
>> On Jan 26, 2021, at 7:15 AM, Δημήτρης Βήχος  wrote:
>>
>> the loop-data.txt 
>>
>>
>> https://kairos.moudania.com/kolxiko/loopdata/
>>
>> Στις Τρίτη, 26 Ιανουαρίου 2021 στις 5:07:58 μ.μ. UTC+2, ο χρήστης 
>> jo...@johnkline.com έγραψε:
>>
>>> > but data refresh every 5 minutes, with the rest skins of weewx
>>>
>>> Exactly what data are you talking about that refreshes every five 
>>> minutes?
>>>
>>> On Jan 26, 2021, at 6:02 AM, Δημήτρης Βήχος  wrote:
>>>
>>> i was easily installed the loop-data extension yesterday. i use weewx 
>>> 4.3 with wh1080 weather station, but data refresh every 5 minutes, with the 
>>> rest skins of weewx
>>>
>>>
>>>
>>> Στις Πέμπτη, 26 Νοεμβρίου 2020 στις 6:46:10 μ.μ. UTC+2, ο χρήστης 
>>> jo...@johnkline.com έγραψε:
>>>
 Thanks for letting me know.

 On Nov 26, 2020, at 7:32 AM, geoffs...@gmail.com  
 wrote:

 Hi John,

 Works great. Here is what I added to the loop-data.py

 Line 735 self.ten_min_packets, self.cfg.ten_min_obstypes)
 # Added to allow specific null keys if no data 
 available in loop packet
 must_have_keys = [ 'current.dateTime', 
 'current.extraTemp1.raw', 'current.extraTemp2.raw', 
 'current.extraTemp3.raw', 'current.extraHumid1.raw', 
 'current.extraHumid2.raw', 'current.extraHumid3.raw' ]
 for must_have_key in must_have_keys:
 if must_have_key not in loopdata_pkt:
 loopdata_pkt[must_have_key] = None

 Thanks!
 On Wednesday, November 25, 2020 at 7:06:46 AM UTC-8 geoffs...@gmail.com 
 wrote:

> Awesome! This is sort of what I suspected that most use cases, NULL is 
> a problem. I can just hard code the entire Davis loop which will work for 
> my needs.
>
> Thanks you,
>
> Geoff
>
> On Wednesday, November 25, 2020 at 6:45:44 AM UTC-8 
> jo...@johnkline.com wrote:
>
>> In the general case, including keys in the loop packet for 
>> non-existent data is not a good idea.  This would break existing code 
>> (e.g., JavaScript code I use in my skins).
>>
>> You could easily fork the extension and add in what you need.  At 
>> line 736, right before write_packet_to_file is called, simply check for 
>> the 
>> keys you need to exist, and add them if they are not there. The 
>> following 
>> should work.  Just replace the keys I’ve listed with the ones you need 
>> in 
>> the packet.
>>
>> must_have_keys = [ 'current.outTemp', 'current.outHumidity' ]
>> for must_have_key in must_have_keys:
>> if must_have_key not in loopdata_pkt:
>> loopdata_pkt[must_have_key] = None
>>
>> If you don’t want to hard code the keys, you’ll have a bigger task; 
>> but you could just copy the code used to process the ‘fields’ entry in 
>> the 
>> LoopData section of weewx.conf.
>>
>> Cheers,
>> John
>>
>> On Nov 24, 2020, at 8:54 PM, geoffs...@gmail.com  
>> wrote:
>>
>> Hi John,
>>
>>
>> This is a great extension. I'm wondering if there is a way to be able 
>> to include sending data that is null  or none for a particular key? I'm 
>> using a davis vantage pro2, weewx 4.2. I'd like to use this to make a 
>> JSON 
>> output that can be ingested into a home automation system. So far it 
>> works 
>> great as long as the data is available to be sent, but I have not 
>> figured 
>> out how to send a key with a Null or none value. It looks like a key 
>> with a 
>> null or none value gets cleaved off the JSON output. If a battery dies 
>> on a 
>> sensor and it just disappears from the JSON output, that is much harder 
>> for 
>> the HA system to handle than a null, none or zero value. 
>>
>> On Monday,

Re: [weewx-user] Questions about weewx-loopdata

Again, how often does your driver write loop records?

loop-data.txt is not written in reporting cycles.  I am asking you to look at 
the actual loop-data.txt file that is written to the .../loopdata directory.  
How often does the contents of that file change.

Also, please show what entries you are seeing in the log every one minute.

> On Jan 26, 2021, at 7:37 AM, Δημήτρης Βήχος  wrote:
> 
> loop-data.txt updates every 5 minutes in web page. but in log see 
> loop-data.txt every 60 secs
> 
> Στις Τρίτη, 26 Ιανουαρίου 2021 στις 5:19:17 μ.μ. UTC+2, ο χρήστης 
> jo...@johnkline.com έγραψε:
>> How often does your driver write loop records?
>> Would you please check the actual loop-data.txt file, rather than the skin’s 
>> report, to see if that file is being updated on every loop record?
>> 
 On Jan 26, 2021, at 7:15 AM, Δημήτρης Βήχος  wrote:
 
>>> the loop-data.txt 
>> 
>>> 
>>> https://kairos.moudania.com/kolxiko/loopdata/
>>> 
>>> Στις Τρίτη, 26 Ιανουαρίου 2021 στις 5:07:58 μ.μ. UTC+2, ο χρήστης 
>>> jo...@johnkline.com έγραψε:
 > but data refresh every 5 minutes, with the rest skins of weewx
 
 Exactly what data are you talking about that refreshes every five minutes?
 
>> On Jan 26, 2021, at 6:02 AM, Δημήτρης Βήχος  wrote:
>> 
> i was easily installed the loop-data extension yesterday. i use weewx 
> 4.3 with wh1080 weather station, but data refresh every 5 minutes, with 
> the rest skins of weewx
 
> 
> 
> Στις Πέμπτη, 26 Νοεμβρίου 2020 στις 6:46:10 μ.μ. UTC+2, ο χρήστης 
> jo...@johnkline.com έγραψε:
>> Thanks for letting me know.
>> 
 On Nov 26, 2020, at 7:32 AM, geoffs...@gmail.com  
 wrote:
 
>>> Hi John,
>>> 
>>> Works great. Here is what I added to the loop-data.py
>>> 
>>> Line 735 self.ten_min_packets, self.cfg.ten_min_obstypes)
>>> # Added to allow specific null keys if no data 
>>> available in loop packet
>>> must_have_keys = [ 'current.dateTime', 
>>> 'current.extraTemp1.raw', 'current.extraTemp2.raw', 
>>> 'current.extraTemp3.raw', 'current.extraHumid1.raw', 
>>> 'current.extraHumid2.raw', 'current.extraHumid3.raw' ]
>>> for must_have_key in must_have_keys:
>>> if must_have_key not in loopdata_pkt:
>>> loopdata_pkt[must_have_key] = None
>>> 
>>> Thanks!
 On Wednesday, November 25, 2020 at 7:06:46 AM UTC-8 
 geoffs...@gmail.com wrote:
 Awesome! This is sort of what I suspected that most use cases, NULL is 
 a problem. I can just hard code the entire Davis loop which will work 
 for my needs.
 
 Thanks you,
 
 Geoff
 
> On Wednesday, November 25, 2020 at 6:45:44 AM UTC-8 
> jo...@johnkline.com wrote:
> In the general case, including keys in the loop packet for 
> non-existent data is not a good idea.  This would break existing code 
> (e.g., JavaScript code I use in my skins).
> 
> You could easily fork the extension and add in what you need.  At 
> line 736, right before write_packet_to_file is called, simply check 
> for the keys you need to exist, and add them if they are not there. 
> The following should work.  Just replace the keys I’ve listed with 
> the ones you need in the packet.
> 
> must_have_keys = [ 'current.outTemp', 'current.outHumidity' ]
> for must_have_key in must_have_keys:
> if must_have_key not in loopdata_pkt:
> loopdata_pkt[must_have_key] = None
> 
> If you don’t want to hard code the keys, you’ll have a bigger task; 
> but you could just copy the code used to process the ‘fields’ entry 
> in the LoopData section of weewx.conf.
> 
> Cheers,
> John
> 
>>> On Nov 24, 2020, at 8:54 PM, geoffs...@gmail.com 
>>>  wrote:
>>> 
>> Hi John,
> 
>> 
>> This is a great extension. I'm wondering if there is a way to be 
>> able to include sending data that is null  or none for a particular 
>> key? I'm using a davis vantage pro2, weewx 4.2. I'd like to use this 
>> to make a JSON output that can be ingested into a home automation 
>> system. So far it works great as long as the data is available to be 
>> sent, but I have not figured out how to send a key with a Null or 
>> none value. It looks like a key with a null or none value gets 
>> cleaved off the JSON output. If a battery dies on a sensor and it 
>> just disappears from the JSON output, that is much harder for the HA 
>> system to handle than a null, none or zero value. 
>> 
>>> On Monday, November 16, 2020 at 2:57:13 PM UTC-8

Re: [weewx-user] Questions about weewx-loopdata

loop-data.txt updates every 5 minutes in web page. but in log see 
loop-data.txt every 60 secs

Στις Τρίτη, 26 Ιανουαρίου 2021 στις 5:19:17 μ.μ. UTC+2, ο χρήστης 
jo...@johnkline.com έγραψε:

> How often does your driver write loop records?
> Would you please check the actual loop-data.txt file, rather than the 
> skin’s report, to see if that file is being updated on every loop record?
>
> On Jan 26, 2021, at 7:15 AM, Δημήτρης Βήχος  wrote:
>
> the loop-data.txt 
>
>
> https://kairos.moudania.com/kolxiko/loopdata/
>
> Στις Τρίτη, 26 Ιανουαρίου 2021 στις 5:07:58 μ.μ. UTC+2, ο χρήστης 
> jo...@johnkline.com έγραψε:
>
>> > but data refresh every 5 minutes, with the rest skins of weewx
>>
>> Exactly what data are you talking about that refreshes every five minutes?
>>
>> On Jan 26, 2021, at 6:02 AM, Δημήτρης Βήχος  wrote:
>>
>> i was easily installed the loop-data extension yesterday. i use weewx 
>> 4.3 with wh1080 weather station, but data refresh every 5 minutes, with the 
>> rest skins of weewx
>>
>>
>>
>> Στις Πέμπτη, 26 Νοεμβρίου 2020 στις 6:46:10 μ.μ. UTC+2, ο χρήστης 
>> jo...@johnkline.com έγραψε:
>>
>>> Thanks for letting me know.
>>>
>>> On Nov 26, 2020, at 7:32 AM, geoffs...@gmail.com  
>>> wrote:
>>>
>>> Hi John,
>>>
>>> Works great. Here is what I added to the loop-data.py
>>>
>>> Line 735 self.ten_min_packets, self.cfg.ten_min_obstypes)
>>> # Added to allow specific null keys if no data available 
>>> in loop packet
>>> must_have_keys = [ 'current.dateTime', 
>>> 'current.extraTemp1.raw', 'current.extraTemp2.raw', 
>>> 'current.extraTemp3.raw', 'current.extraHumid1.raw', 
>>> 'current.extraHumid2.raw', 'current.extraHumid3.raw' ]
>>> for must_have_key in must_have_keys:
>>> if must_have_key not in loopdata_pkt:
>>> loopdata_pkt[must_have_key] = None
>>>
>>> Thanks!
>>> On Wednesday, November 25, 2020 at 7:06:46 AM UTC-8 geoffs...@gmail.com 
>>> wrote:
>>>
 Awesome! This is sort of what I suspected that most use cases, NULL is 
 a problem. I can just hard code the entire Davis loop which will work for 
 my needs.

 Thanks you,

 Geoff

 On Wednesday, November 25, 2020 at 6:45:44 AM UTC-8 jo...@johnkline.com 
 wrote:

> In the general case, including keys in the loop packet for 
> non-existent data is not a good idea.  This would break existing code 
> (e.g., JavaScript code I use in my skins).
>
> You could easily fork the extension and add in what you need.  At line 
> 736, right before write_packet_to_file is called, simply check for the 
> keys 
> you need to exist, and add them if they are not there. The following 
> should 
> work.  Just replace the keys I’ve listed with the ones you need in the 
> packet.
>
> must_have_keys = [ 'current.outTemp', 'current.outHumidity' ]
> for must_have_key in must_have_keys:
> if must_have_key not in loopdata_pkt:
> loopdata_pkt[must_have_key] = None
>
> If you don’t want to hard code the keys, you’ll have a bigger task; 
> but you could just copy the code used to process the ‘fields’ entry in 
> the 
> LoopData section of weewx.conf.
>
> Cheers,
> John
>
> On Nov 24, 2020, at 8:54 PM, geoffs...@gmail.com  
> wrote:
>
> Hi John,
>
>
> This is a great extension. I'm wondering if there is a way to be able 
> to include sending data that is null  or none for a particular key? I'm 
> using a davis vantage pro2, weewx 4.2. I'd like to use this to make a 
> JSON 
> output that can be ingested into a home automation system. So far it 
> works 
> great as long as the data is available to be sent, but I have not figured 
> out how to send a key with a Null or none value. It looks like a key with 
> a 
> null or none value gets cleaved off the JSON output. If a battery dies on 
> a 
> sensor and it just disappears from the JSON output, that is much harder 
> for 
> the HA system to handle than a null, none or zero value. 
>
> On Monday, November 16, 2020 at 2:57:13 PM UTC-8 jo...@johnkline.com 
> wrote:
>
>> A fix is released (v2.7.2).  There is no hurry to install the new 
>> release; but once you’ve installed it, you can remove the field I asked 
>> you 
>> to add to weewx.conf.
>>
>> On Nov 16, 2020, at 9:04 AM, Geni  wrote:
>>
>> Ok, works
>>
>>
>> Thank you
>>
>> jo...@johnkline.com schrieb am Montag, 16. November 2020 um 16:05:21 
>> UTC+1:
>>
>>> I can duplicate this problem and will issue a fix.
>>>
>>> In the meantime, you can add:
>>> rainyear.outTemp.max
>>> to the fields clause in the LoopData section of weewx.conf?
>>>
>>> That will stop this problem.  If you get similar errors for other 
>>> periods

Re: [weewx-user] Questions about weewx-loopdata

How often does your driver write loop records?
Would you please check the actual loop-data.txt file, rather than the skin’s 
report, to see if that file is being updated on every loop record?

> On Jan 26, 2021, at 7:15 AM, Δημήτρης Βήχος  wrote:
> 
> the loop-data.txt 
> 
> https://kairos.moudania.com/kolxiko/loopdata/
> 
> Στις Τρίτη, 26 Ιανουαρίου 2021 στις 5:07:58 μ.μ. UTC+2, ο χρήστης 
> jo...@johnkline.com έγραψε:
>> > but data refresh every 5 minutes, with the rest skins of weewx
>> 
>> Exactly what data are you talking about that refreshes every five minutes?
>> 
 On Jan 26, 2021, at 6:02 AM, Δημήτρης Βήχος  wrote:
 
>>> i was easily installed the loop-data extension yesterday. i use weewx 4.3 
>>> with wh1080 weather station, but data refresh every 5 minutes, with the 
>>> rest skins of weewx
>> 
>>> 
>>> 
>>> Στις Πέμπτη, 26 Νοεμβρίου 2020 στις 6:46:10 μ.μ. UTC+2, ο χρήστης 
>>> jo...@johnkline.com έγραψε:
 Thanks for letting me know.
 
>> On Nov 26, 2020, at 7:32 AM, geoffs...@gmail.com  
>> wrote:
>> 
> Hi John,
> 
> Works great. Here is what I added to the loop-data.py
> 
> Line 735 self.ten_min_packets, self.cfg.ten_min_obstypes)
> # Added to allow specific null keys if no data available 
> in loop packet
> must_have_keys = [ 'current.dateTime', 
> 'current.extraTemp1.raw', 'current.extraTemp2.raw', 
> 'current.extraTemp3.raw', 'current.extraHumid1.raw', 
> 'current.extraHumid2.raw', 'current.extraHumid3.raw' ]
> for must_have_key in must_have_keys:
> if must_have_key not in loopdata_pkt:
> loopdata_pkt[must_have_key] = None
> 
> Thanks!
>> On Wednesday, November 25, 2020 at 7:06:46 AM UTC-8 geoffs...@gmail.com 
>> wrote:
>> Awesome! This is sort of what I suspected that most use cases, NULL is a 
>> problem. I can just hard code the entire Davis loop which will work for 
>> my needs.
>> 
>> Thanks you,
>> 
>> Geoff
>> 
>>> On Wednesday, November 25, 2020 at 6:45:44 AM UTC-8 jo...@johnkline.com 
>>> wrote:
>>> In the general case, including keys in the loop packet for non-existent 
>>> data is not a good idea.  This would break existing code (e.g., 
>>> JavaScript code I use in my skins).
>>> 
>>> You could easily fork the extension and add in what you need.  At line 
>>> 736, right before write_packet_to_file is called, simply check for the 
>>> keys you need to exist, and add them if they are not there. The 
>>> following should work.  Just replace the keys I’ve listed with the ones 
>>> you need in the packet.
>>> 
>>> must_have_keys = [ 'current.outTemp', 'current.outHumidity' ]
>>> for must_have_key in must_have_keys:
>>> if must_have_key not in loopdata_pkt:
>>> loopdata_pkt[must_have_key] = None
>>> 
>>> If you don’t want to hard code the keys, you’ll have a bigger task; but 
>>> you could just copy the code used to process the ‘fields’ entry in the 
>>> LoopData section of weewx.conf.
>>> 
>>> Cheers,
>>> John
>>> 
> On Nov 24, 2020, at 8:54 PM, geoffs...@gmail.com 
>  wrote:
> 
 Hi John,
>>> 
 
 This is a great extension. I'm wondering if there is a way to be able 
 to include sending data that is null  or none for a particular key? 
 I'm using a davis vantage pro2, weewx 4.2. I'd like to use this to 
 make a JSON output that can be ingested into a home automation system. 
 So far it works great as long as the data is available to be sent, but 
 I have not figured out how to send a key with a Null or none value. It 
 looks like a key with a null or none value gets cleaved off the JSON 
 output. If a battery dies on a sensor and it just disappears from the 
 JSON output, that is much harder for the HA system to handle than a 
 null, none or zero value. 
 
> On Monday, November 16, 2020 at 2:57:13 PM UTC-8 jo...@johnkline.com 
> wrote:
> A fix is released (v2.7.2).  There is no hurry to install the new 
> release; but once you’ve installed it, you can remove the field I 
> asked you to add to weewx.conf.
> 
>> On Nov 16, 2020, at 9:04 AM, Geni  wrote:
>> 
>> Ok, works
> 
>> 
>> Thank you
>> 
>> jo...@johnkline.com schrieb am Montag, 16. November 2020 um 16:05:21 
>> UTC+1:
>>> I can duplicate this problem and will issue a fix.
>>> 
>>> In the meantime, you can add:
>>> rainyear.outTemp.max
>>> to the fields clause in the LoopData section of weewx.conf?
>>> 
>>> That will stop this problem.  If you get similar errors for other

Re: [weewx-user] Questions about weewx-loopdata

the loop-data.txt 

https://kairos.moudania.com/kolxiko/loopdata/

Στις Τρίτη, 26 Ιανουαρίου 2021 στις 5:07:58 μ.μ. UTC+2, ο χρήστης 
jo...@johnkline.com έγραψε:

> > but data refresh every 5 minutes, with the rest skins of weewx
>
> Exactly what data are you talking about that refreshes every five minutes?
>
> On Jan 26, 2021, at 6:02 AM, Δημήτρης Βήχος  wrote:
>
> i was easily installed the loop-data extension yesterday. i use weewx 4.3 
> with wh1080 weather station, but data refresh every 5 minutes, with the 
> rest skins of weewx
>
>
>
> Στις Πέμπτη, 26 Νοεμβρίου 2020 στις 6:46:10 μ.μ. UTC+2, ο χρήστης 
> jo...@johnkline.com έγραψε:
>
>> Thanks for letting me know.
>>
>> On Nov 26, 2020, at 7:32 AM, geoffs...@gmail.com  
>> wrote:
>>
>> Hi John,
>>
>> Works great. Here is what I added to the loop-data.py
>>
>> Line 735 self.ten_min_packets, self.cfg.ten_min_obstypes)
>> # Added to allow specific null keys if no data available 
>> in loop packet
>> must_have_keys = [ 'current.dateTime', 
>> 'current.extraTemp1.raw', 'current.extraTemp2.raw', 
>> 'current.extraTemp3.raw', 'current.extraHumid1.raw', 
>> 'current.extraHumid2.raw', 'current.extraHumid3.raw' ]
>> for must_have_key in must_have_keys:
>> if must_have_key not in loopdata_pkt:
>> loopdata_pkt[must_have_key] = None
>>
>> Thanks!
>> On Wednesday, November 25, 2020 at 7:06:46 AM UTC-8 geoffs...@gmail.com 
>> wrote:
>>
>>> Awesome! This is sort of what I suspected that most use cases, NULL is a 
>>> problem. I can just hard code the entire Davis loop which will work for my 
>>> needs.
>>>
>>> Thanks you,
>>>
>>> Geoff
>>>
>>> On Wednesday, November 25, 2020 at 6:45:44 AM UTC-8 jo...@johnkline.com 
>>> wrote:
>>>
 In the general case, including keys in the loop packet for non-existent 
 data is not a good idea.  This would break existing code (e.g., JavaScript 
 code I use in my skins).

 You could easily fork the extension and add in what you need.  At line 
 736, right before write_packet_to_file is called, simply check for the 
 keys 
 you need to exist, and add them if they are not there. The following 
 should 
 work.  Just replace the keys I’ve listed with the ones you need in the 
 packet.

 must_have_keys = [ 'current.outTemp', 'current.outHumidity' ]
 for must_have_key in must_have_keys:
 if must_have_key not in loopdata_pkt:
 loopdata_pkt[must_have_key] = None

 If you don’t want to hard code the keys, you’ll have a bigger task; but 
 you could just copy the code used to process the ‘fields’ entry in the 
 LoopData section of weewx.conf.

 Cheers,
 John

 On Nov 24, 2020, at 8:54 PM, geoffs...@gmail.com  
 wrote:

 Hi John,


 This is a great extension. I'm wondering if there is a way to be able 
 to include sending data that is null  or none for a particular key? I'm 
 using a davis vantage pro2, weewx 4.2. I'd like to use this to make a JSON 
 output that can be ingested into a home automation system. So far it works 
 great as long as the data is available to be sent, but I have not figured 
 out how to send a key with a Null or none value. It looks like a key with 
 a 
 null or none value gets cleaved off the JSON output. If a battery dies on 
 a 
 sensor and it just disappears from the JSON output, that is much harder 
 for 
 the HA system to handle than a null, none or zero value. 

 On Monday, November 16, 2020 at 2:57:13 PM UTC-8 jo...@johnkline.com 
 wrote:

> A fix is released (v2.7.2).  There is no hurry to install the new 
> release; but once you’ve installed it, you can remove the field I asked 
> you 
> to add to weewx.conf.
>
> On Nov 16, 2020, at 9:04 AM, Geni  wrote:
>
> Ok, works
>
>
> Thank you
>
> jo...@johnkline.com schrieb am Montag, 16. November 2020 um 16:05:21 
> UTC+1:
>
>> I can duplicate this problem and will issue a fix.
>>
>> In the meantime, you can add:
>> rainyear.outTemp.max
>> to the fields clause in the LoopData section of weewx.conf?
>>
>> That will stop this problem.  If you get similar errors for other 
>> periods where you have no fields listed, you’ll have to temporarily add 
>> a 
>> field for those periods also.
>>
>> I should have a fix shortly.  I don’t know that this is related to 
>> WeeWX 4.2, not that that really matters. 
>>
>> On Nov 16, 2020, at 2:45 AM, Geni  wrote:
>>
>> 
>>
>>
>> Hi john
>> since weewx 4.2.0 the loop-data.txt is no longer generated?
>> regards Geni
>>
>>
>> -- 
>> You received this message because you are subscribed to the Google 
>> Groups "weewx-user" group.
>> To unsubscribe from this group

Re: [weewx-user] Questions about weewx-loopdata

> but data refresh every 5 minutes, with the rest skins of weewx

Exactly what data are you talking about that refreshes every five minutes?

> On Jan 26, 2021, at 6:02 AM, Δημήτρης Βήχος  wrote:
> 
> i was easily installed the loop-data extension yesterday. i use weewx 4.3 
> with wh1080 weather station, but data refresh every 5 minutes, with the rest 
> skins of weewx
> 
> Στις Πέμπτη, 26 Νοεμβρίου 2020 στις 6:46:10 μ.μ. UTC+2, ο χρήστης 
> jo...@johnkline.com έγραψε:
>> Thanks for letting me know.
>> 
 On Nov 26, 2020, at 7:32 AM, geoffs...@gmail.com  
 wrote:
 
>>> Hi John,
>>> 
>>> Works great. Here is what I added to the loop-data.py
>>> 
>>> Line 735 self.ten_min_packets, self.cfg.ten_min_obstypes)
>>> # Added to allow specific null keys if no data available in 
>>> loop packet
>>> must_have_keys = [ 'current.dateTime', 
>>> 'current.extraTemp1.raw', 'current.extraTemp2.raw', 
>>> 'current.extraTemp3.raw', 'current.extraHumid1.raw', 
>>> 'current.extraHumid2.raw', 'current.extraHumid3.raw' ]
>>> for must_have_key in must_have_keys:
>>> if must_have_key not in loopdata_pkt:
>>> loopdata_pkt[must_have_key] = None
>>> 
>>> Thanks!
 On Wednesday, November 25, 2020 at 7:06:46 AM UTC-8 geoffs...@gmail.com 
 wrote:
 Awesome! This is sort of what I suspected that most use cases, NULL is a 
 problem. I can just hard code the entire Davis loop which will work for my 
 needs.
 
 Thanks you,
 
 Geoff
 
> On Wednesday, November 25, 2020 at 6:45:44 AM UTC-8 jo...@johnkline.com 
> wrote:
> In the general case, including keys in the loop packet for non-existent 
> data is not a good idea.  This would break existing code (e.g., 
> JavaScript code I use in my skins).
> 
> You could easily fork the extension and add in what you need.  At line 
> 736, right before write_packet_to_file is called, simply check for the 
> keys you need to exist, and add them if they are not there. The following 
> should work.  Just replace the keys I’ve listed with the ones you need in 
> the packet.
> 
> must_have_keys = [ 'current.outTemp', 'current.outHumidity' ]
> for must_have_key in must_have_keys:
> if must_have_key not in loopdata_pkt:
> loopdata_pkt[must_have_key] = None
> 
> If you don’t want to hard code the keys, you’ll have a bigger task; but 
> you could just copy the code used to process the ‘fields’ entry in the 
> LoopData section of weewx.conf.
> 
> Cheers,
> John
> 
>>> On Nov 24, 2020, at 8:54 PM, geoffs...@gmail.com  
>>> wrote:
>>> 
>> Hi John,
> 
>> 
>> This is a great extension. I'm wondering if there is a way to be able to 
>> include sending data that is null  or none for a particular key? I'm 
>> using a davis vantage pro2, weewx 4.2. I'd like to use this to make a 
>> JSON output that can be ingested into a home automation system. So far 
>> it works great as long as the data is available to be sent, but I have 
>> not figured out how to send a key with a Null or none value. It looks 
>> like a key with a null or none value gets cleaved off the JSON output. 
>> If a battery dies on a sensor and it just disappears from the JSON 
>> output, that is much harder for the HA system to handle than a null, 
>> none or zero value. 
>> 
>>> On Monday, November 16, 2020 at 2:57:13 PM UTC-8 jo...@johnkline.com 
>>> wrote:
>>> A fix is released (v2.7.2).  There is no hurry to install the new 
>>> release; but once you’ve installed it, you can remove the field I asked 
>>> you to add to weewx.conf.
>>> 
 On Nov 16, 2020, at 9:04 AM, Geni  wrote:
 
 Ok, works
>>> 
 
 Thank you
 
 jo...@johnkline.com schrieb am Montag, 16. November 2020 um 16:05:21 
 UTC+1:
> I can duplicate this problem and will issue a fix.
> 
> In the meantime, you can add:
> rainyear.outTemp.max
> to the fields clause in the LoopData section of weewx.conf?
> 
> That will stop this problem.  If you get similar errors for other 
> periods where you have no fields listed, you’ll have to temporarily 
> add a field for those periods also.
> 
> I should have a fix shortly.  I don’t know that this is related to 
> WeeWX 4.2, not that that really matters. 
> 
>>> On Nov 16, 2020, at 2:45 AM, Geni  wrote:
>>> 
>> 
> 
>> 
>> Hi john
>> since weewx 4.2.0 the loop-data.txt is no longer generated?
>> regards Geni
>> 
>> 
> 
>> -- 
>> You received this message because you are subscribed to the Google 
>> Groups "weewx-user" group.

Re: [weewx-user] Questions about weewx-loopdata

2020-07-16 Thread 'hctp...@googlemail.com' via weewx-user

i was easily installed the loop-data extension yesterday. i use weewx 4.3 
with wh1080 weather station, but data refresh every 5 minutes, with the 
rest skins of weewx

Στις Πέμπτη, 26 Νοεμβρίου 2020 στις 6:46:10 μ.μ. UTC+2, ο χρήστης 
jo...@johnkline.com έγραψε:

> Thanks for letting me know.
>
> On Nov 26, 2020, at 7:32 AM, geoffs...@gmail.com  
> wrote:
>
> Hi John,
>
> Works great. Here is what I added to the loop-data.py
>
> Line 735 self.ten_min_packets, self.cfg.ten_min_obstypes)
> # Added to allow specific null keys if no data available 
> in loop packet
> must_have_keys = [ 'current.dateTime', 
> 'current.extraTemp1.raw', 'current.extraTemp2.raw', 
> 'current.extraTemp3.raw', 'current.extraHumid1.raw', 
> 'current.extraHumid2.raw', 'current.extraHumid3.raw' ]
> for must_have_key in must_have_keys:
> if must_have_key not in loopdata_pkt:
> loopdata_pkt[must_have_key] = None
>
> Thanks!
> On Wednesday, November 25, 2020 at 7:06:46 AM UTC-8 geoffs...@gmail.com 
> wrote:
>
>> Awesome! This is sort of what I suspected that most use cases, NULL is a 
>> problem. I can just hard code the entire Davis loop which will work for my 
>> needs.
>>
>> Thanks you,
>>
>> Geoff
>>
>> On Wednesday, November 25, 2020 at 6:45:44 AM UTC-8 jo...@johnkline.com 
>> wrote:
>>
>>> In the general case, including keys in the loop packet for non-existent 
>>> data is not a good idea.  This would break existing code (e.g., JavaScript 
>>> code I use in my skins).
>>>
>>> You could easily fork the extension and add in what you need.  At line 
>>> 736, right before write_packet_to_file is called, simply check for the keys 
>>> you need to exist, and add them if they are not there. The following should 
>>> work.  Just replace the keys I’ve listed with the ones you need in the 
>>> packet.
>>>
>>> must_have_keys = [ 'current.outTemp', 'current.outHumidity' ]
>>> for must_have_key in must_have_keys:
>>> if must_have_key not in loopdata_pkt:
>>> loopdata_pkt[must_have_key] = None
>>>
>>> If you don’t want to hard code the keys, you’ll have a bigger task; but 
>>> you could just copy the code used to process the ‘fields’ entry in the 
>>> LoopData section of weewx.conf.
>>>
>>> Cheers,
>>> John
>>>
>>> On Nov 24, 2020, at 8:54 PM, geoffs...@gmail.com  
>>> wrote:
>>>
>>> Hi John,
>>>
>>>
>>> This is a great extension. I'm wondering if there is a way to be able to 
>>> include sending data that is null  or none for a particular key? I'm using 
>>> a davis vantage pro2, weewx 4.2. I'd like to use this to make a JSON output 
>>> that can be ingested into a home automation system. So far it works great 
>>> as long as the data is available to be sent, but I have not figured out how 
>>> to send a key with a Null or none value. It looks like a key with a null or 
>>> none value gets cleaved off the JSON output. If a battery dies on a sensor 
>>> and it just disappears from the JSON output, that is much harder for the HA 
>>> system to handle than a null, none or zero value. 
>>>
>>> On Monday, November 16, 2020 at 2:57:13 PM UTC-8 jo...@johnkline.com 
>>> wrote:
>>>
 A fix is released (v2.7.2).  There is no hurry to install the new 
 release; but once you’ve installed it, you can remove the field I asked 
 you 
 to add to weewx.conf.

 On Nov 16, 2020, at 9:04 AM, Geni  wrote:

 Ok, works


 Thank you

 jo...@johnkline.com schrieb am Montag, 16. November 2020 um 16:05:21 
 UTC+1:

> I can duplicate this problem and will issue a fix.
>
> In the meantime, you can add:
> rainyear.outTemp.max
> to the fields clause in the LoopData section of weewx.conf?
>
> That will stop this problem.  If you get similar errors for other 
> periods where you have no fields listed, you’ll have to temporarily add a 
> field for those periods also.
>
> I should have a fix shortly.  I don’t know that this is related to 
> WeeWX 4.2, not that that really matters. 
>
> On Nov 16, 2020, at 2:45 AM, Geni  wrote:
>
> 
>
>
> Hi john
> since weewx 4.2.0 the loop-data.txt is no longer generated?
> regards Geni
>
>
> -- 
> You received this message because you are subscribed to the Google 
> Groups "weewx-user" group.
> To unsubscribe from this group and stop receiving emails from it, send 
> an email to weewx-user+...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/3f89791f-c06b-43d1-beac-0afa58df59d6n%40googlegroups.com
>  
> 
> .
> 
>
> -- 
 You received this message because you are subscribed to the Google 
 Groups "weewx-user" group.
 To

Re: [weewx-user] Questions about weewx-loopdata

2020-11-26 Thread John Kline

Thanks for letting me know.

> On Nov 26, 2020, at 7:32 AM, geoffs...@gmail.com  
> wrote:
> 
> Hi John,
> 
> Works great. Here is what I added to the loop-data.py
> 
> Line 735 self.ten_min_packets, self.cfg.ten_min_obstypes)
> # Added to allow specific null keys if no data available in 
> loop packet
> must_have_keys = [ 'current.dateTime', 
> 'current.extraTemp1.raw', 'current.extraTemp2.raw', 'current.extraTemp3.raw', 
> 'current.extraHumid1.raw', 'current.extraHumid2.raw', 
> 'current.extraHumid3.raw' ]
> for must_have_key in must_have_keys:
> if must_have_key not in loopdata_pkt:
> loopdata_pkt[must_have_key] = None
> 
> Thanks!
>> On Wednesday, November 25, 2020 at 7:06:46 AM UTC-8 geoffs...@gmail.com 
>> wrote:
>> Awesome! This is sort of what I suspected that most use cases, NULL is a 
>> problem. I can just hard code the entire Davis loop which will work for my 
>> needs.
>> 
>> Thanks you,
>> 
>> Geoff
>> 
>>> On Wednesday, November 25, 2020 at 6:45:44 AM UTC-8 jo...@johnkline.com 
>>> wrote:
>>> In the general case, including keys in the loop packet for non-existent 
>>> data is not a good idea.  This would break existing code (e.g., JavaScript 
>>> code I use in my skins).
>>> 
>>> You could easily fork the extension and add in what you need.  At line 736, 
>>> right before write_packet_to_file is called, simply check for the keys you 
>>> need to exist, and add them if they are not there. The following should 
>>> work.  Just replace the keys I’ve listed with the ones you need in the 
>>> packet.
>>> 
>>> must_have_keys = [ 'current.outTemp', 'current.outHumidity' ]
>>> for must_have_key in must_have_keys:
>>> if must_have_key not in loopdata_pkt:
>>> loopdata_pkt[must_have_key] = None
>>> 
>>> If you don’t want to hard code the keys, you’ll have a bigger task; but you 
>>> could just copy the code used to process the ‘fields’ entry in the LoopData 
>>> section of weewx.conf.
>>> 
>>> Cheers,
>>> John
>>> 
> On Nov 24, 2020, at 8:54 PM, geoffs...@gmail.com  
> wrote:
> 
 Hi John,
>>> 
 
 This is a great extension. I'm wondering if there is a way to be able to 
 include sending data that is null  or none for a particular key? I'm using 
 a davis vantage pro2, weewx 4.2. I'd like to use this to make a JSON 
 output that can be ingested into a home automation system. So far it works 
 great as long as the data is available to be sent, but I have not figured 
 out how to send a key with a Null or none value. It looks like a key with 
 a null or none value gets cleaved off the JSON output. If a battery dies 
 on a sensor and it just disappears from the JSON output, that is much 
 harder for the HA system to handle than a null, none or zero value. 
 
> On Monday, November 16, 2020 at 2:57:13 PM UTC-8 jo...@johnkline.com 
> wrote:
> A fix is released (v2.7.2).  There is no hurry to install the new 
> release; but once you’ve installed it, you can remove the field I asked 
> you to add to weewx.conf.
> 
>> On Nov 16, 2020, at 9:04 AM, Geni  wrote:
>> 
>> Ok, works
> 
>> 
>> Thank you
>> 
>> jo...@johnkline.com schrieb am Montag, 16. November 2020 um 16:05:21 
>> UTC+1:
>>> I can duplicate this problem and will issue a fix.
>>> 
>>> In the meantime, you can add:
>>> rainyear.outTemp.max
>>> to the fields clause in the LoopData section of weewx.conf?
>>> 
>>> That will stop this problem.  If you get similar errors for other 
>>> periods where you have no fields listed, you’ll have to temporarily add 
>>> a field for those periods also.
>>> 
>>> I should have a fix shortly.  I don’t know that this is related to 
>>> WeeWX 4.2, not that that really matters. 
>>> 
> On Nov 16, 2020, at 2:45 AM, Geni  wrote:
> 
 
>>> 
 
 Hi john
 since weewx 4.2.0 the loop-data.txt is no longer generated?
 regards Geni
 
 
>>> 
 -- 
 You received this message because you are subscribed to the Google 
 Groups "weewx-user" group.
 To unsubscribe from this group and stop receiving emails from it, send 
 an email to weewx-user+...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/weewx-user/3f89791f-c06b-43d1-beac-0afa58df59d6n%40googlegroups.com.
 
>> 
>> -- 
>> You received this message because you are subscribed to the Google 
>> Groups "weewx-user" group.
>> To unsubscribe from this group and stop receiving emails from it, send 
>> an email to weewx-user+...@googlegroups.com.
> 
>> To view this discussion on the web visit 
>>

Re: [weewx-user] Questions about weewx-loopdata

2020-11-26 Thread geoffs...@gmail.com

Hi John,

Works great. Here is what I added to the loop-data.py

Line 735 self.ten_min_packets, self.cfg.ten_min_obstypes)
# Added to allow specific null keys if no data available in 
loop packet
must_have_keys = [ 'current.dateTime', 
'current.extraTemp1.raw', 'current.extraTemp2.raw', 
'current.extraTemp3.raw', 'current.extraHumid1.raw', 
'current.extraHumid2.raw', 'current.extraHumid3.raw' ]
for must_have_key in must_have_keys:
if must_have_key not in loopdata_pkt:
loopdata_pkt[must_have_key] = None

Thanks!
On Wednesday, November 25, 2020 at 7:06:46 AM UTC-8 geoffs...@gmail.com 
wrote:

> Awesome! This is sort of what I suspected that most use cases, NULL is a 
> problem. I can just hard code the entire Davis loop which will work for my 
> needs.
>
> Thanks you,
>
> Geoff
>
> On Wednesday, November 25, 2020 at 6:45:44 AM UTC-8 jo...@johnkline.com 
> wrote:
>
>> In the general case, including keys in the loop packet for non-existent 
>> data is not a good idea.  This would break existing code (e.g., JavaScript 
>> code I use in my skins).
>>
>> You could easily fork the extension and add in what you need.  At line 
>> 736, right before write_packet_to_file is called, simply check for the keys 
>> you need to exist, and add them if they are not there. The following should 
>> work.  Just replace the keys I’ve listed with the ones you need in the 
>> packet.
>>
>> must_have_keys = [ 'current.outTemp', 'current.outHumidity' ]
>> for must_have_key in must_have_keys:
>> if must_have_key not in loopdata_pkt:
>> loopdata_pkt[must_have_key] = None
>>
>> If you don’t want to hard code the keys, you’ll have a bigger task; but 
>> you could just copy the code used to process the ‘fields’ entry in the 
>> LoopData section of weewx.conf.
>>
>> Cheers,
>> John
>>
>> On Nov 24, 2020, at 8:54 PM, geoffs...@gmail.com  
>> wrote:
>>
>> Hi John,
>>
>>
>> This is a great extension. I'm wondering if there is a way to be able to 
>> include sending data that is null  or none for a particular key? I'm using 
>> a davis vantage pro2, weewx 4.2. I'd like to use this to make a JSON output 
>> that can be ingested into a home automation system. So far it works great 
>> as long as the data is available to be sent, but I have not figured out how 
>> to send a key with a Null or none value. It looks like a key with a null or 
>> none value gets cleaved off the JSON output. If a battery dies on a sensor 
>> and it just disappears from the JSON output, that is much harder for the HA 
>> system to handle than a null, none or zero value. 
>>
>> On Monday, November 16, 2020 at 2:57:13 PM UTC-8 jo...@johnkline.com 
>> wrote:
>>
>>> A fix is released (v2.7.2).  There is no hurry to install the new 
>>> release; but once you’ve installed it, you can remove the field I asked you 
>>> to add to weewx.conf.
>>>
>>> On Nov 16, 2020, at 9:04 AM, Geni  wrote:
>>>
>>> Ok, works
>>>
>>>
>>> Thank you
>>>
>>> jo...@johnkline.com schrieb am Montag, 16. November 2020 um 16:05:21 
>>> UTC+1:
>>>
 I can duplicate this problem and will issue a fix.

 In the meantime, you can add:
 rainyear.outTemp.max
 to the fields clause in the LoopData section of weewx.conf?

 That will stop this problem.  If you get similar errors for other 
 periods where you have no fields listed, you’ll have to temporarily add a 
 field for those periods also.

 I should have a fix shortly.  I don’t know that this is related to 
 WeeWX 4.2, not that that really matters. 

 On Nov 16, 2020, at 2:45 AM, Geni  wrote:

 


 Hi john
 since weewx 4.2.0 the loop-data.txt is no longer generated?
 regards Geni


 -- 
 You received this message because you are subscribed to the Google 
 Groups "weewx-user" group.
 To unsubscribe from this group and stop receiving emails from it, send 
 an email to weewx-user+...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/weewx-user/3f89791f-c06b-43d1-beac-0afa58df59d6n%40googlegroups.com
  
 
 .
 

 -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "weewx-user" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to weewx-user+...@googlegroups.com.
>>>
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/weewx-user/0f6cb227-1cdd-4fbb-9cf9-6f4c59521262n%40googlegroups.com
>>>  
>>> 
>>> .
>>>
>>> -- 
>> You received this message because you are subscribed to the Google

Re: [weewx-user] Questions about weewx-loopdata

2020-11-25 Thread geoffs...@gmail.com

Awesome! This is sort of what I suspected that most use cases, NULL is a 
problem. I can just hard code the entire Davis loop which will work for my 
needs.

Thanks you,

Geoff

On Wednesday, November 25, 2020 at 6:45:44 AM UTC-8 jo...@johnkline.com 
wrote:

> In the general case, including keys in the loop packet for non-existent 
> data is not a good idea.  This would break existing code (e.g., JavaScript 
> code I use in my skins).
>
> You could easily fork the extension and add in what you need.  At line 
> 736, right before write_packet_to_file is called, simply check for the keys 
> you need to exist, and add them if they are not there. The following should 
> work.  Just replace the keys I’ve listed with the ones you need in the 
> packet.
>
> must_have_keys = [ 'current.outTemp', 'current.outHumidity' ]
> for must_have_key in must_have_keys:
> if must_have_key not in loopdata_pkt:
> loopdata_pkt[must_have_key] = None
>
> If you don’t want to hard code the keys, you’ll have a bigger task; but 
> you could just copy the code used to process the ‘fields’ entry in the 
> LoopData section of weewx.conf.
>
> Cheers,
> John
>
> On Nov 24, 2020, at 8:54 PM, geoffs...@gmail.com  
> wrote:
>
> Hi John,
>
>
> This is a great extension. I'm wondering if there is a way to be able to 
> include sending data that is null  or none for a particular key? I'm using 
> a davis vantage pro2, weewx 4.2. I'd like to use this to make a JSON output 
> that can be ingested into a home automation system. So far it works great 
> as long as the data is available to be sent, but I have not figured out how 
> to send a key with a Null or none value. It looks like a key with a null or 
> none value gets cleaved off the JSON output. If a battery dies on a sensor 
> and it just disappears from the JSON output, that is much harder for the HA 
> system to handle than a null, none or zero value. 
>
> On Monday, November 16, 2020 at 2:57:13 PM UTC-8 jo...@johnkline.com 
> wrote:
>
>> A fix is released (v2.7.2).  There is no hurry to install the new 
>> release; but once you’ve installed it, you can remove the field I asked you 
>> to add to weewx.conf.
>>
>> On Nov 16, 2020, at 9:04 AM, Geni  wrote:
>>
>> Ok, works
>>
>>
>> Thank you
>>
>> jo...@johnkline.com schrieb am Montag, 16. November 2020 um 16:05:21 
>> UTC+1:
>>
>>> I can duplicate this problem and will issue a fix.
>>>
>>> In the meantime, you can add:
>>> rainyear.outTemp.max
>>> to the fields clause in the LoopData section of weewx.conf?
>>>
>>> That will stop this problem.  If you get similar errors for other 
>>> periods where you have no fields listed, you’ll have to temporarily add a 
>>> field for those periods also.
>>>
>>> I should have a fix shortly.  I don’t know that this is related to WeeWX 
>>> 4.2, not that that really matters. 
>>>
>>> On Nov 16, 2020, at 2:45 AM, Geni  wrote:
>>>
>>> 
>>>
>>>
>>> Hi john
>>> since weewx 4.2.0 the loop-data.txt is no longer generated?
>>> regards Geni
>>>
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "weewx-user" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to weewx-user+...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/weewx-user/3f89791f-c06b-43d1-beac-0afa58df59d6n%40googlegroups.com
>>>  
>>> 
>>> .
>>> 
>>>
>>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "weewx-user" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to weewx-user+...@googlegroups.com.
>>
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/0f6cb227-1cdd-4fbb-9cf9-6f4c59521262n%40googlegroups.com
>>  
>> 
>> .
>>
>> -- 
> You received this message because you are subscribed to the Google Groups 
> "weewx-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to weewx-user+...@googlegroups.com.
>
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/0611c189-0c9f-4ab6-b6be-4d797e80bb96n%40googlegroups.com
>  
> 
> .
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit

Re: [weewx-user] Questions about weewx-loopdata

2020-11-24 Thread geoffs...@gmail.com

Hi John,

This is a great extension. I'm wondering if there is a way to be able to 
include sending data that is null  or none for a particular key? I'm using 
a davis vantage pro2, weewx 4.2. I'd like to use this to make a JSON output 
that can be ingested into a home automation system. So far it works great 
as long as the data is available to be sent, but I have not figured out how 
to send a key with a Null or none value. It looks like a key with a null or 
none value gets cleaved off the JSON output. If a battery dies on a sensor 
and it just disappears from the JSON output, that is much harder for the HA 
system to handle than a null, none or zero value. 

On Monday, November 16, 2020 at 2:57:13 PM UTC-8 jo...@johnkline.com wrote:

> A fix is released (v2.7.2).  There is no hurry to install the new release; 
> but once you’ve installed it, you can remove the field I asked you to add 
> to weewx.conf.
>
> On Nov 16, 2020, at 9:04 AM, Geni  wrote:
>
> Ok, works
>
>
> Thank you
>
> jo...@johnkline.com schrieb am Montag, 16. November 2020 um 16:05:21 
> UTC+1:
>
>> I can duplicate this problem and will issue a fix.
>>
>> In the meantime, you can add:
>> rainyear.outTemp.max
>> to the fields clause in the LoopData section of weewx.conf?
>>
>> That will stop this problem.  If you get similar errors for other periods 
>> where you have no fields listed, you’ll have to temporarily add a field for 
>> those periods also.
>>
>> I should have a fix shortly.  I don’t know that this is related to WeeWX 
>> 4.2, not that that really matters. 
>>
>> On Nov 16, 2020, at 2:45 AM, Geni  wrote:
>>
>> 
>>
>>
>> Hi john
>> since weewx 4.2.0 the loop-data.txt is no longer generated?
>> regards Geni
>>
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "weewx-user" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to weewx-user+...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/3f89791f-c06b-43d1-beac-0afa58df59d6n%40googlegroups.com
>>  
>> 
>> .
>> 
>>
>> -- 
> You received this message because you are subscribed to the Google Groups 
> "weewx-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to weewx-user+...@googlegroups.com.
>
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/0f6cb227-1cdd-4fbb-9cf9-6f4c59521262n%40googlegroups.com
>  
> 
> .
>
>

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

Re: [weewx-user] Questions about weewx-loopdata

2020-11-16 Thread John Kline

A fix is released (v2.7.2).  There is no hurry to install the new release; but 
once you’ve installed it, you can remove the field I asked you to add to 
weewx.conf.

> On Nov 16, 2020, at 9:04 AM, Geni  wrote:
> 
> Ok, works
> Thank you
> 
> jo...@johnkline.com schrieb am Montag, 16. November 2020 um 16:05:21 UTC+1:
>> I can duplicate this problem and will issue a fix.
>> 
>> In the meantime, you can add:
>> rainyear.outTemp.max
>> to the fields clause in the LoopData section of weewx.conf?
>> 
>> That will stop this problem.  If you get similar errors for other periods 
>> where you have no fields listed, you’ll have to temporarily add a field for 
>> those periods also.
>> 
>> I should have a fix shortly.  I don’t know that this is related to WeeWX 
>> 4.2, not that that really matters. 
>> 
 On Nov 16, 2020, at 2:45 AM, Geni  wrote:
 
>>> 
>> 
>>> 
>>> Hi john
>>> since weewx 4.2.0 the loop-data.txt is no longer generated?
>>> regards Geni
>>> 
>>> 
>> 
>>> -- 
>>> You received this message because you are subscribed to the Google Groups 
>>> "weewx-user" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>> email to weewx-user+...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/weewx-user/3f89791f-c06b-43d1-beac-0afa58df59d6n%40googlegroups.com.
>>> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "weewx-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to weewx-user+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/0f6cb227-1cdd-4fbb-9cf9-6f4c59521262n%40googlegroups.com.

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/1F79D9DD-276F-4A97-9E84-5F0E11E858B7%40johnkline.com.

Re: [weewx-user] Questions about weewx-loopdata

2020-11-16 Thread Geni

Ok, works
Thank you

jo...@johnkline.com schrieb am Montag, 16. November 2020 um 16:05:21 UTC+1:

> I can duplicate this problem and will issue a fix.
>
> In the meantime, you can add:
> rainyear.outTemp.max
> to the fields clause in the LoopData section of weewx.conf?
>
> That will stop this problem.  If you get similar errors for other periods 
> where you have no fields listed, you’ll have to temporarily add a field for 
> those periods also.
>
> I should have a fix shortly.  I don’t know that this is related to WeeWX 
> 4.2, not that that really matters. 
>
> On Nov 16, 2020, at 2:45 AM, Geni  wrote:
>
> 
>
>
> Hi john
> since weewx 4.2.0 the loop-data.txt is no longer generated?
> regards Geni
>
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "weewx-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to weewx-user+...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/3f89791f-c06b-43d1-beac-0afa58df59d6n%40googlegroups.com
>  
> 
> .
> 
>
>

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

Re: [weewx-user] Questions about weewx-loopdata

2020-11-16 Thread John Kline

I can duplicate this problem and will issue a fix.

In the meantime, you can add:
rainyear.outTemp.max
to the fields clause in the LoopData section of weewx.conf?

That will stop this problem.  If you get similar errors for other periods where 
you have no fields listed, you’ll have to temporarily add a field for those 
periods also.

I should have a fix shortly.  I don’t know that this is related to WeeWX 4.2, 
not that that really matters. 

> On Nov 16, 2020, at 2:45 AM, Geni  wrote:
> 
> 
> Hi john
> since weewx 4.2.0 the loop-data.txt is no longer generated?
> regards Geni
> 
> 
> -- 
> 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/3f89791f-c06b-43d1-beac-0afa58df59d6n%40googlegroups.com.
> 

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/54DD3EFB-3691-4D44-8856-2C5699B93F29%40johnkline.com.

Re: [weewx-user] Questions about weewx-loopdata 1.3.x

2020-07-20 Thread John Kline

That slipped through in the upgrade section.  Yes, you want 
trend.barometer.formatted if you are looking if you don’t want a label.  (Use 
trend.barometer if you want a label.)

I’ll fix that in the upgrade section today (or just remove the upgrade section.)

> On Jul 20, 2020, at 12:23 AM, geni08...@gmail.com  
> wrote:
> 
> Hi John, since version 2.0.b8 the display works as expected. I have just 
> installed 2.0.b10 and see no difference on the fast.
> What I don't understand is why the documented field 
> "trend.barometerRate.formatted" does not provide any information in the 
> loop-data.txt. Do I get my information from "trend.barometer.formatted"?
> 
> jo...@johnkline.com schrieb am Samstag, 18. Juli 2020 um 22:23:49 UTC+2:
>> Give 2.0.b7 a spin.
>> 
>> trend has now been generalized (as opposed to only working with barometer).  
>> It will also honor the time_span configured for the target report.
>> 
>> If the numbers don’t look right to you, the last 36 records in the archive 
>> table would be more helpful than sending screenshots of the value differing 
>> from what report generation produces.
>> 
>> trend.barometer.desc (i.e, the .desc suffix) is still an oddball.  It 
>> shouldn’t be part of LoopData.  I’m going to remove it, but I need to move 
>> the code (to produce the description) to JavasSript (for one of my personal 
>> reports, not as part of LoopData).
>> 
 On Jul 18, 2020, at 6:05 AM, John Kline  wrote:
 
>>> 
>> 
>>> I’ve already well on my way to replacing this.  Trend will work for all 
>>> scalar values, not just barometer.  The code is done, but I need to add it 
>>> to the tests.
>>> 
> On Jul 17, 2020, at 11:17 PM, geni08...@gmail.com  
> wrote:
> 
  I don't think there are any errors in the database, the barometer trend 
 is displayed in my season with a credible value that also matches the 
 value in the index.html from the weatherboard (as documented in the older 
 answer).
 I also attached the file loop-data-xxx.txt, in the upper part you can see 
 the values generated by loop-data in the lower part my entry in 
 weewx.conf. It is striking that the values "trend.barometerRate.desc" and 
 "trend.barometerRate" are missing.
 Yesterday at noon I noticed that the value of the 
 "trend.barometer.formatted", which is now> 300 is exactly at 12h (GTM + 2) 
 on the expected value. Will watch this today). 
 
 jo...@johnkline.com schrieb am Freitag, 17. Juli 2020 um 16:23:27 UTC+2:
> 
> As the documentation states, trend.barometer and 10m.windGust are special 
> cases.
> 
> In this case, where we are talking about trend.barometer, it is alway the 
> delta from three hours ago and uses archive records to compute the 
> starting reading.  Also, it is expressed as a per hour rate.  Thus, it 
> would be 1/3 of the three hour delta.  I did it this way because my sole 
> purpose was to compute the text description (e.g., rising slowly).
> 
> Perhaps you have some bad data in your database?  Have you checked that 
> to see what the actual delta and per hour delta should be?
> 
> In any event, I need to make trend less special.  I think I’ll do that 
> this weekend.  It should honor the $delta.time_delta for the skin and 
> report the actual delta, not on a per hour basis.  While I’m doing that, 
> I’ll make sure my tests around trend.barometer are good enough.  If there 
> is a bug, I should find it then.
> 
> 
>>> On Jul 16, 2020, at 11:07 PM, geni08...@gmail.com  
>>> wrote:
>>> 
>> Thank you very much, the script is a good idea.
> 
>> 
>> 
>> There was another question regarding "trend.barometerRate.formatted". At 
>> the beginning this gave plausible values, from yesterday evening it 
>> delivers impossible values.
>> Is it possible that 2 sources supply data and interfere?
>> I tried to keep a momentary status.
>> 
>> Display liveboard
> 
>> 
>> 
>> 
>> index.html
>> 
>> 
>> 
>> loop-data.txt
> 
>> 
>> 
>> 
>> index.html.tmpl
>> 
>> 
>> $current.barometer(> id="trend.barometer.formatted">$trend.barometer.formatted)->  id="current.outHumidity">$current.outHumidity 
>> 
>> 
>> 
>> 
>> jo...@johnkline.com schrieb am Freitag, 17. Juli 2020 um 00:02:36 UTC+2:
>>> I’m not sure which parts of Bechlertown rely on MQTT and which parts 
>>> rely on auto refreshing the page.  For the former, if the info is 
>>> available in LoopData, you would need to add an id to the HTML element 
>>> and then set the contents via javascript in the same way as 
>>> WeatherBoard does it.
>>> 
>>> Bechlertown appears to be a well supported skin with frequent updates.  
>>> You do need to worry about taking updates of the skin since you’ll be 
>>> making modifications.

Re: [weewx-user] Questions about weewx-loopdata 1.3.x

2020-07-20 Thread geni08...@gmail.com

Hi John, since version 2.0.b8 the display works as expected. I have just 
installed 2.0.b10 and see no difference on the fast.
What I don't understand is why the documented field 
"trend.barometerRate.formatted" does not provide any information in the 
loop-data.txt. Do I get my information from "trend.barometer.formatted"?

jo...@johnkline.com schrieb am Samstag, 18. Juli 2020 um 22:23:49 UTC+2:

> Give 2.0.b7 a spin.
>
> trend has now been generalized (as opposed to only working with 
> barometer).  It will also honor the time_span configured for the target 
> report.
>
> If the numbers don’t look right to you, the last 36 records in the archive 
> table would be more helpful than sending screenshots of the value differing 
> from what report generation produces.
>
> trend.barometer.desc (i.e, the .desc suffix) is still an oddball.  It 
> shouldn’t be part of LoopData.  I’m going to remove it, but I need to move 
> the code (to produce the description) to JavasSript (for one of my personal 
> reports, not as part of LoopData).
>
> On Jul 18, 2020, at 6:05 AM, John Kline  wrote:
>
> 
>
> I’ve already well on my way to replacing this.  Trend will work for all 
> scalar values, not just barometer.  The code is done, but I need to add it 
> to the tests.
>
> On Jul 17, 2020, at 11:17 PM, geni08...@gmail.com  
> wrote:
>
>  I don't think there are any errors in the database, the barometer trend 
> is displayed in my season with 
> a credible value that also matches the value in the index.html from the 
> weatherboard (as documented in the older answer).
> I also attached the file loop-data-xxx.txt, in the upper part you can see 
> the values generated by loop-data in the lower part my entry in weewx.conf. 
> It 
> is striking that the values "trend.barometerRate.desc" and 
> "trend.barometerRate" are missing.
> Yesterday at noon I noticed that the value of the 
> "trend.barometer.formatted", which is now> 300 is exactly at 12h (GTM + 2) 
> on the expected value. Will watch this today). 
>
> jo...@johnkline.com schrieb am Freitag, 17. Juli 2020 um 16:23:27 UTC+2:
>
>> 
>> As the documentation states, trend.barometer and 10m.windGust are special 
>> cases.
>>
>> In this case, where we are talking about trend.barometer, it is alway the 
>> delta from three hours ago and uses archive records to compute the starting 
>> reading.  Also, it is expressed as a per hour rate.  Thus, it would be 1/3 
>> of the three hour delta.  I did it this way because my sole purpose was to 
>> compute the text description (e.g., rising slowly).
>>
>> Perhaps you have some bad data in your database?  Have you checked that 
>> to see what the actual delta and per hour delta should be?
>>
>> In any event, I need to make trend less special.  I think I’ll do that 
>> this weekend.  It should honor the $delta.time_delta for the skin and 
>> report the actual delta, not on a per hour basis.  While I’m doing that, 
>> I’ll make sure my tests around trend.barometer are good enough.  If there 
>> is a bug, I should find it then.
>>
>>
>> On Jul 16, 2020, at 11:07 PM, geni08...@gmail.com  
>> wrote:
>>
>> Thank you very much, the script is a good idea.
>>
>>
>>
>> There was another question regarding "trend.barometerRate.formatted". At 
>> the beginning this gave plausible values, from yesterday evening it 
>> delivers impossible values.
>> Is it possible that 2 sources supply data and interfere?
>> I tried to keep a momentary status.
>>
>> Display liveboard
>>
>> 
>>
>>
>> index.html
>> 
>>
>>
>> loop-data.txt
>>
>> 
>>
>>
>> index.html.tmpl
>> 
>> 
>> $current.barometer(> id="trend.barometer.formatted">$trend.barometer.formatted)->  
>> id="current.outHumidity">$current.outHumidity 
>> 
>> 
>>
>>
>> jo...@johnkline.com schrieb am Freitag, 17. Juli 2020 um 00:02:36 UTC+2:
>>
>>> I’m not sure which parts of Bechlertown rely on MQTT and which parts 
>>> rely on auto refreshing the page.  For the former, if the info is available 
>>> in LoopData, you would need to add an id to the HTML element and then set 
>>> the contents via javascript in the same way as WeatherBoard does it.
>>>
>>> Bechlertown appears to be a well supported skin with frequent updates. 
>>>  You do need to worry about taking updates of the skin since you’ll be 
>>> making modifications.  Ideally, you would write a script to add the ids in 
>>> the right place and add a line to include the javascript.
>>>
>>> On Jul 16, 2020, at 8:18 AM, geni08...@gmail.com  
>>> wrote:
>>>
>>>  
>>>
>>> Hi John, Thank you for your help so far, my next goal is to update the 
>>> Belchertown template with weewx-loopdata.
>>> MQTT needs an infrastructure there ... I find your solution really 
>>> elegant. Do you have a tip for me where to start?
>>>
>>>
>>> jo...@johnkline.com schrieb am Donnerstag, 16. Juli 2020 um 15:46:28 
>>> UTC+2:
>>>
 It looks like you are on a roll!

 I think you are asking why I don’t have the actual

Re: [weewx-user] Questions about weewx-loopdata 1.3.x

2020-07-18 Thread John Kline

Give 2.0.b7 a spin.

trend has now been generalized (as opposed to only working with barometer).  It 
will also honor the time_span configured for the target report.

If the numbers don’t look right to you, the last 36 records in the archive 
table would be more helpful than sending screenshots of the value differing 
from what report generation produces.

trend.barometer.desc (i.e, the .desc suffix) is still an oddball.  It shouldn’t 
be part of LoopData.  I’m going to remove it, but I need to move the code (to 
produce the description) to JavasSript (for one of my personal reports, not as 
part of LoopData).

> On Jul 18, 2020, at 6:05 AM, John Kline  wrote:
> 
> 
> I’ve already well on my way to replacing this.  Trend will work for all 
> scalar values, not just barometer.  The code is done, but I need to add it to 
> the tests.
> 
>>> On Jul 17, 2020, at 11:17 PM, geni08...@gmail.com  
>>> wrote:
>>> 
>>  I don't think there are any errors in the database, the barometer trend is 
>> displayed in my season with a credible value that also matches the value in 
>> the index.html from the weatherboard (as documented in the older answer).
>> I also attached the file loop-data-xxx.txt, in the upper part you can see 
>> the values generated by loop-data in the lower part my entry in weewx.conf. 
>> It is striking that the values "trend.barometerRate.desc" and 
>> "trend.barometerRate" are missing.
>> Yesterday at noon I noticed that the value of the 
>> "trend.barometer.formatted", which is now> 300 is exactly at 12h (GTM + 2) 
>> on the expected value. Will watch this today). 
>> 
>> jo...@johnkline.com schrieb am Freitag, 17. Juli 2020 um 16:23:27 UTC+2:
>>> 
>>> As the documentation states, trend.barometer and 10m.windGust are special 
>>> cases.
>>> 
>>> In this case, where we are talking about trend.barometer, it is alway the 
>>> delta from three hours ago and uses archive records to compute the starting 
>>> reading.  Also, it is expressed as a per hour rate.  Thus, it would be 1/3 
>>> of the three hour delta.  I did it this way because my sole purpose was to 
>>> compute the text description (e.g., rising slowly).
>>> 
>>> Perhaps you have some bad data in your database?  Have you checked that to 
>>> see what the actual delta and per hour delta should be?
>>> 
>>> In any event, I need to make trend less special.  I think I’ll do that this 
>>> weekend.  It should honor the $delta.time_delta for the skin and report the 
>>> actual delta, not on a per hour basis.  While I’m doing that, I’ll make 
>>> sure my tests around trend.barometer are good enough.  If there is a bug, I 
>>> should find it then.
>>> 
>>> 
> On Jul 16, 2020, at 11:07 PM, geni08...@gmail.com  
> wrote:
> 
 Thank you very much, the script is a good idea.
>>> 
 
 
 There was another question regarding "trend.barometerRate.formatted". At 
 the beginning this gave plausible values, from yesterday evening it 
 delivers impossible values.
 Is it possible that 2 sources supply data and interfere?
 I tried to keep a momentary status.
 
 Display liveboard
>>> 
 
 
 
 index.html
 
 
 
 loop-data.txt
>>> 
 
 
 
 index.html.tmpl
 
 
 $current.barometer(>>> id="trend.barometer.formatted">$trend.barometer.formatted)->>>  id="current.outHumidity">$current.outHumidity 
 
 
 
 
 jo...@johnkline.com schrieb am Freitag, 17. Juli 2020 um 00:02:36 UTC+2:
> I’m not sure which parts of Bechlertown rely on MQTT and which parts rely 
> on auto refreshing the page.  For the former, if the info is available in 
> LoopData, you would need to add an id to the HTML element and then set 
> the contents via javascript in the same way as WeatherBoard does it.
> 
> Bechlertown appears to be a well supported skin with frequent updates.  
> You do need to worry about taking updates of the skin since you’ll be 
> making modifications.  Ideally, you would write a script to add the ids 
> in the right place and add a line to include the javascript.
> 
>>> On Jul 16, 2020, at 8:18 AM, geni08...@gmail.com  
>>> wrote:
>>> 
>> 
> 
>> Hi John, Thank you for your help so far, my next goal is to update the 
>> Belchertown template with weewx-loopdata.
>> MQTT needs an infrastructure there ... I find your solution really 
>> elegant. Do you have a tip for me where to start?
>> 
>> 
>> jo...@johnkline.com schrieb am Donnerstag, 16. Juli 2020 um 15:46:28 
>> UTC+2:
>>> It looks like you are on a roll!
>>> 
>>> I think you are asking why I don’t have the actual values filled in for 
>>> windGust in the template.
>>> 
>>> The answer for $10m.windGust.max is that the $10m period is only 
>>> understood by LoopData.  If you put $10m.windGust.max in the template, 
>>> it would cause an error.  There is probably a way to

Re: [weewx-user] Questions about weewx-loopdata 1.3.x

2020-07-18 Thread John Kline

I’ve already well on my way to replacing this.  Trend will work for all scalar 
values, not just barometer.  The code is done, but I need to add it to the 
tests.

> On Jul 17, 2020, at 11:17 PM, geni08...@gmail.com  
> wrote:
> 
>  I don't think there are any errors in the database, the barometer trend is 
> displayed in my season with a credible value that also matches the value in 
> the index.html from the weatherboard (as documented in the older answer).
> I also attached the file loop-data-xxx.txt, in the upper part you can see the 
> values generated by loop-data in the lower part my entry in weewx.conf. It is 
> striking that the values "trend.barometerRate.desc" and "trend.barometerRate" 
> are missing.
> Yesterday at noon I noticed that the value of the 
> "trend.barometer.formatted", which is now> 300 is exactly at 12h (GTM + 2) on 
> the expected value. Will watch this today). 
> 
> jo...@johnkline.com schrieb am Freitag, 17. Juli 2020 um 16:23:27 UTC+2:
>> 
>> As the documentation states, trend.barometer and 10m.windGust are special 
>> cases.
>> 
>> In this case, where we are talking about trend.barometer, it is alway the 
>> delta from three hours ago and uses archive records to compute the starting 
>> reading.  Also, it is expressed as a per hour rate.  Thus, it would be 1/3 
>> of the three hour delta.  I did it this way because my sole purpose was to 
>> compute the text description (e.g., rising slowly).
>> 
>> Perhaps you have some bad data in your database?  Have you checked that to 
>> see what the actual delta and per hour delta should be?
>> 
>> In any event, I need to make trend less special.  I think I’ll do that this 
>> weekend.  It should honor the $delta.time_delta for the skin and report the 
>> actual delta, not on a per hour basis.  While I’m doing that, I’ll make sure 
>> my tests around trend.barometer are good enough.  If there is a bug, I 
>> should find it then.
>> 
>> 
 On Jul 16, 2020, at 11:07 PM, geni08...@gmail.com  
 wrote:
 
>>> Thank you very much, the script is a good idea.
>> 
>>> 
>>> 
>>> There was another question regarding "trend.barometerRate.formatted". At 
>>> the beginning this gave plausible values, from yesterday evening it 
>>> delivers impossible values.
>>> Is it possible that 2 sources supply data and interfere?
>>> I tried to keep a momentary status.
>>> 
>>> Display liveboard
>> 
>>> 
>>> 
>>> 
>>> index.html
>>> 
>>> 
>>> 
>>> loop-data.txt
>> 
>>> 
>>> 
>>> 
>>> index.html.tmpl
>>> 
>>> 
>>> $current.barometer(>> id="trend.barometer.formatted">$trend.barometer.formatted)->>  id="current.outHumidity">$current.outHumidity 
>>> 
>>> 
>>> 
>>> 
>>> jo...@johnkline.com schrieb am Freitag, 17. Juli 2020 um 00:02:36 UTC+2:
 I’m not sure which parts of Bechlertown rely on MQTT and which parts rely 
 on auto refreshing the page.  For the former, if the info is available in 
 LoopData, you would need to add an id to the HTML element and then set the 
 contents via javascript in the same way as WeatherBoard does it.
 
 Bechlertown appears to be a well supported skin with frequent updates.  
 You do need to worry about taking updates of the skin since you’ll be 
 making modifications.  Ideally, you would write a script to add the ids in 
 the right place and add a line to include the javascript.
 
>> On Jul 16, 2020, at 8:18 AM, geni08...@gmail.com  
>> wrote:
>> 
> 
 
> Hi John, Thank you for your help so far, my next goal is to update the 
> Belchertown template with weewx-loopdata.
> MQTT needs an infrastructure there ... I find your solution really 
> elegant. Do you have a tip for me where to start?
> 
> 
> jo...@johnkline.com schrieb am Donnerstag, 16. Juli 2020 um 15:46:28 
> UTC+2:
>> It looks like you are on a roll!
>> 
>> I think you are asking why I don’t have the actual values filled in for 
>> windGust in the template.
>> 
>> The answer for $10m.windGust.max is that the $10m period is only 
>> understood by LoopData.  If you put $10m.windGust.max in the template, 
>> it would cause an error.  There is probably a way to compute the 10 
>> minute high gust, but I didn’t bother to figure that out since the value 
>> will appear anyway on the next loop.
>> 
>> For $day.windGust.max, adding it to the template should work just fine.  
>> It’s not needed.  In fact, none of the values are needed since they are 
>> overwritten by the JavaScript.
>> 
>> 
>> 
 On Jul 16, 2020, at 5:26 AM, geni08...@gmail.com  
 wrote:
 
>>>  Hi John, it could even add winDir and barometer and humidity!
>> 
>>> What I would like to know why is enough for the two windGust values 
>>> only the id in index.html.tmpl 
>>> https://affolter.familyds.net/wetter/live/
>>> 
>> 
>>> 
>>> 
>>> 
>>> jo...@johnkline.com schrieb am

Re: [weewx-user] Questions about weewx-loopdata 1.3.x

2020-07-18 Thread geni08...@gmail.com

 I don't think there are any errors in the database, the barometer trend is 
displayed in my season with 
a credible value that also matches the value in the index.html from the 
weatherboard (as documented in the older answer).
I also attached the file loop-data-xxx.txt, in the upper part you can see 
the values generated by loop-data in the lower part my entry in weewx.conf. It 
is striking that the values "trend.barometerRate.desc" and 
"trend.barometerRate" are missing.
Yesterday at noon I noticed that the value of the 
"trend.barometer.formatted", which is now> 300 is exactly at 12h (GTM + 2) 
on the expected value. Will watch this today). 

jo...@johnkline.com schrieb am Freitag, 17. Juli 2020 um 16:23:27 UTC+2:

> 
> As the documentation states, trend.barometer and 10m.windGust are special 
> cases.
>
> In this case, where we are talking about trend.barometer, it is alway the 
> delta from three hours ago and uses archive records to compute the starting 
> reading.  Also, it is expressed as a per hour rate.  Thus, it would be 1/3 
> of the three hour delta.  I did it this way because my sole purpose was to 
> compute the text description (e.g., rising slowly).
>
> Perhaps you have some bad data in your database?  Have you checked that to 
> see what the actual delta and per hour delta should be?
>
> In any event, I need to make trend less special.  I think I’ll do that 
> this weekend.  It should honor the $delta.time_delta for the skin and 
> report the actual delta, not on a per hour basis.  While I’m doing that, 
> I’ll make sure my tests around trend.barometer are good enough.  If there 
> is a bug, I should find it then.
>
>
> On Jul 16, 2020, at 11:07 PM, geni08...@gmail.com  
> wrote:
>
> Thank you very much, the script is a good idea.
>
>
>
> There was another question regarding "trend.barometerRate.formatted". At 
> the beginning this gave plausible values, from yesterday evening it 
> delivers impossible values.
> Is it possible that 2 sources supply data and interfere?
> I tried to keep a momentary status.
>
> Display liveboard
>
> 
>
>
> index.html
> 
>
>
> loop-data.txt
>
> 
>
>
> index.html.tmpl
> 
> 
> $current.barometer( id="trend.barometer.formatted">$trend.barometer.formatted)-  
> id="current.outHumidity">$current.outHumidity 
> 
> 
>
>
> jo...@johnkline.com schrieb am Freitag, 17. Juli 2020 um 00:02:36 UTC+2:
>
>> I’m not sure which parts of Bechlertown rely on MQTT and which parts rely 
>> on auto refreshing the page.  For the former, if the info is available in 
>> LoopData, you would need to add an id to the HTML element and then set the 
>> contents via javascript in the same way as WeatherBoard does it.
>>
>> Bechlertown appears to be a well supported skin with frequent updates. 
>>  You do need to worry about taking updates of the skin since you’ll be 
>> making modifications.  Ideally, you would write a script to add the ids in 
>> the right place and add a line to include the javascript.
>>
>> On Jul 16, 2020, at 8:18 AM, geni08...@gmail.com  
>> wrote:
>>
>>  
>>
>> Hi John, Thank you for your help so far, my next goal is to update the 
>> Belchertown template with weewx-loopdata.
>> MQTT needs an infrastructure there ... I find your solution really 
>> elegant. Do you have a tip for me where to start?
>>
>>
>> jo...@johnkline.com schrieb am Donnerstag, 16. Juli 2020 um 15:46:28 
>> UTC+2:
>>
>>> It looks like you are on a roll!
>>>
>>> I think you are asking why I don’t have the actual values filled in for 
>>> windGust in the template.
>>>
>>> The answer for $10m.windGust.max is that the $10m period is only 
>>> understood by LoopData.  If you put $10m.windGust.max in the template, it 
>>> would cause an error.  There is probably a way to compute the 10 minute 
>>> high gust, but I didn’t bother to figure that out since the value will 
>>> appear anyway on the next loop.
>>>
>>> For $day.windGust.max, adding it to the template should work just fine. 
>>>  It’s not needed.  In fact, none of the values are needed since they are 
>>> overwritten by the JavaScript.
>>>
>>>
>>>
>>> On Jul 16, 2020, at 5:26 AM, geni08...@gmail.com  
>>> wrote:
>>>
>>>  Hi John, it could even add winDir and barometer and humidity!
>>>
>>> What I would like to know why is enough for the two windGust values only 
>>> the id in index.html.tmpl 
>>> https://affolter.familyds.net/wetter/live/
>>>
>>> 
>>>
>>>
>>> jo...@johnkline.com schrieb am Mittwoch, 15. Juli 2020 um 22:32:15 
>>> UTC+2:
>>>
 Thanks for sending those links.

 Again, I don’t think it’s necessary to move the file to ram disk.  With 
 modern SSDs and wear leveling, and especially with a file this size.  You 
 might want to do some web searches before deciding if its worth the effort.

 On Jul 15, 2020, at 1:14 PM, 'hctp...@googlemail.com' via weewx-user <
 weewx...@googlegroups.com> wrote:

 John,

 so maybe a project for the next

Re: [weewx-user] Questions about weewx-loopdata 1.3.x

2020-07-17 Thread John Kline

As the documentation states, trend.barometer and 10m.windGust are special cases.

In this case, where we are talking about trend.barometer, it is alway the delta 
from three hours ago and uses archive records to compute the starting reading.  
Also, it is expressed as a per hour rate.  Thus, it would be 1/3 of the three 
hour delta.  I did it this way because my sole purpose was to compute the text 
description (e.g., rising slowly).

Perhaps you have some bad data in your database?  Have you checked that to see 
what the actual delta and per hour delta should be?

In any event, I need to make trend less special.  I think I’ll do that this 
weekend.  It should honor the $delta.time_delta for the skin and report the 
actual delta, not on a per hour basis.  While I’m doing that, I’ll make sure my 
tests around trend.barometer are good enough.  If there is a bug, I should find 
it then.

>> On Jul 16, 2020, at 11:07 PM, geni08...@gmail.com  
>> wrote:
> Thank you very much, the script is a good idea.
> 
> There was another question regarding "trend.barometerRate.formatted". At the 
> beginning this gave plausible values, from yesterday evening it delivers 
> impossible values.
> Is it possible that 2 sources supply data and interfere?
> I tried to keep a momentary status.
> 
> Display liveboard
> 
> 
> 
> index.html
> 
> 
> 
> loop-data.txt
> 
> 
> 
> index.html.tmpl
> 
> 
> $current.barometer( id="trend.barometer.formatted">$trend.barometer.formatted)-  id="current.outHumidity">$current.outHumidity 
> 
> 
> 
> 
> jo...@johnkline.com schrieb am Freitag, 17. Juli 2020 um 00:02:36 UTC+2:
>> I’m not sure which parts of Bechlertown rely on MQTT and which parts rely on 
>> auto refreshing the page.  For the former, if the info is available in 
>> LoopData, you would need to add an id to the HTML element and then set the 
>> contents via javascript in the same way as WeatherBoard does it.
>> 
>> Bechlertown appears to be a well supported skin with frequent updates.  You 
>> do need to worry about taking updates of the skin since you’ll be making 
>> modifications.  Ideally, you would write a script to add the ids in the 
>> right place and add a line to include the javascript.
>> 
 On Jul 16, 2020, at 8:18 AM, geni08...@gmail.com  
 wrote:
>>> 
>> 
>>> Hi John, Thank you for your help so far, my next goal is to update the 
>>> Belchertown template with weewx-loopdata.
>>> MQTT needs an infrastructure there ... I find your solution really elegant. 
>>> Do you have a tip for me where to start?
>>> 
>>> 
>>> jo...@johnkline.com schrieb am Donnerstag, 16. Juli 2020 um 15:46:28 UTC+2:
 It looks like you are on a roll!

 I think you are asking why I don’t have the actual values filled in for 
 windGust in the template.

 The answer for $10m.windGust.max is that the $10m period is only 
 understood by LoopData.  If you put $10m.windGust.max in the template, it 
 would cause an error.  There is probably a way to compute the 10 minute 
 high gust, but I didn’t bother to figure that out since the value will 
 appear anyway on the next loop.

 For $day.windGust.max, adding it to the template should work just fine.  
 It’s not needed.  In fact, none of the values are needed since they are 
 overwritten by the JavaScript.

>> On Jul 16, 2020, at 5:26 AM, geni08...@gmail.com  
>> wrote:
>  Hi John, it could even add winDir and barometer and humidity!

> What I would like to know why is enough for the two windGust values only 
> the id in index.html.tmpl 
> https://affolter.familyds.net/wetter/live/

> 
> 
> 
> jo...@johnkline.com schrieb am Mittwoch, 15. Juli 2020 um 22:32:15 UTC+2:
>> Thanks for sending those links.
>> 
>> Again, I don’t think it’s necessary to move the file to ram disk.  With 
>> modern SSDs and wear leveling, and especially with a file this size.  
>> You might want to do some web searches before deciding if its worth the 
>> effort.
>> 
 On Jul 15, 2020, at 1:14 PM, 'hctp...@googlemail.com' via weewx-user 
  wrote:
>>> John,
>>> 
>>> so maybe a project for the next days to put the loop-data.tx into ram 
>>> and serve it via apache2. 
>>> The WeatherBoard site:
>>> 
>>> https://livewetter.hcpeters.de
>>> 
>>> and my main weather site:
>>> 
>>> https://wetter.hcpeters.de/
>>> 
>>> .
>>> The gauges you see on the main site seems to use Javascript so that's 
>>> why I asked...! :-D 
>>> At the moment I just give a fixed value and render the entire site 
>>> every minute...near realtime... ;-) 
>>> 
>>> But diving into java would be a big task not sure I'm ready for 
>>> thatalready fighting with Python...! :-D
>>> 
>>> Regards,
>>> 
>>> Christian 
>>> 
>>> 
>>> 
>>> jo...@johnkline.com schrieb am Mittwoch, 15.

Re: [weewx-user] Questions about weewx-loopdata 1.3.x

2020-07-16 Thread John Kline

I’m not sure which parts of Bechlertown rely on MQTT and which parts rely on 
auto refreshing the page.  For the former, if the info is available in 
LoopData, you would need to add an id to the HTML element and then set the 
contents via javascript in the same way as WeatherBoard does it.

Bechlertown appears to be a well supported skin with frequent updates.  You do 
need to worry about taking updates of the skin since you’ll be making 
modifications.  Ideally, you would write a script to add the ids in the right 
place and add a line to include the javascript.

> On Jul 16, 2020, at 8:18 AM, geni08...@gmail.com  
> wrote:
> 
> 
> Hi John, Thank you for your help so far, my next goal is to update the 
> Belchertown template with weewx-loopdata.
> MQTT needs an infrastructure there ... I find your solution really elegant. 
> Do you have a tip for me where to start?
> 
> 
> jo...@johnkline.com schrieb am Donnerstag, 16. Juli 2020 um 15:46:28 UTC+2:
>> It looks like you are on a roll!
>> 
>> I think you are asking why I don’t have the actual values filled in for 
>> windGust in the template.
>> 
>> The answer for $10m.windGust.max is that the $10m period is only understood 
>> by LoopData.  If you put $10m.windGust.max in the template, it would cause 
>> an error.  There is probably a way to compute the 10 minute high gust, but I 
>> didn’t bother to figure that out since the value will appear anyway on the 
>> next loop.
>> 
>> For $day.windGust.max, adding it to the template should work just fine.  
>> It’s not needed.  In fact, none of the values are needed since they are 
>> overwritten by the JavaScript.
>> 
>> 
>> 
 On Jul 16, 2020, at 5:26 AM, geni08...@gmail.com  
 wrote:
 
>>>  Hi John, it could even add winDir and barometer and humidity!
>> 
>>> What I would like to know why is enough for the two windGust values only 
>>> the id in index.html.tmpl 
>>> https://affolter.familyds.net/wetter/live/
>>> 
>> 
>>> 
>>> 
>>> 
>>> jo...@johnkline.com schrieb am Mittwoch, 15. Juli 2020 um 22:32:15 UTC+2:
 Thanks for sending those links.
 
 Again, I don’t think it’s necessary to move the file to ram disk.  With 
 modern SSDs and wear leveling, and especially with a file this size.  You 
 might want to do some web searches before deciding if its worth the effort.
 
>> On Jul 15, 2020, at 1:14 PM, 'hctp...@googlemail.com' via weewx-user 
>>  wrote:
>> 
> John,
> 
> so maybe a project for the next days to put the loop-data.tx into ram and 
> serve it via apache2. 
> The WeatherBoard site:
> 
> https://livewetter.hcpeters.de
> 
> and my main weather site:
> 
> https://wetter.hcpeters.de/
> 
> .
> The gauges you see on the main site seems to use Javascript so that's why 
> I asked...! :-D 
> At the moment I just give a fixed value and render the entire site every 
> minute...near realtime... ;-) 
> 
> But diving into java would be a big task not sure I'm ready for 
> thatalready fighting with Python...! :-D
> 
> Regards,
> 
> Christian 
> 
> 
> 
> jo...@johnkline.com schrieb am Mittwoch, 15. Juli 2020 um 21:59:47 UTC+2:
>> I do not personally regard it as a problem.  Others may have a different 
>> opinion.
>> 
>> It certainly is not necessary to have it on the SSD, but you would have 
>> to configure apache2 (or whatever web server you are using), to be able 
>> to serve loop-data.txt.
>> 
>> BTW, is your site visible externally?  If so, would you send a link?
>> 
 On Jul 15, 2020, at 12:46 PM, 'hctp...@googlemail.com' via weewx-user 
  wrote:
 
>>> John,
>> 
>>> 
>>> is this a problem to write the loop-data.txt file every 2sec on a SSD 
>>> regarding durability!?
>>> Or would it be better to place it on a ramdisk (tmpfs) like /dev/shm ...
>>> 
>>> Regards,
>>> 
>>> Christian 
>>> 
>>> jo...@johnkline.com schrieb am Mittwoch, 15. Juli 2020 um 21:35:27 
>>> UTC+2:
 Great news!
 
 The purpose of LoopData is to be able to add to any skin, but it does 
 require knowledge of JavaScript.
 
>> On Jul 15, 2020, at 12:33 PM, John Kline  wrote:
>> 
> 
 
> 
> tail -f loop-data.txt won’t work because a new file is created on 
> every loop.
> 
> You can use:
> watch cat loop-data.txt
> 
> You screen shots are not of any javascript errors that might be on 
> the page.
> 
> Would you send me the following file?
> /var/www/html/weewx/weatherboard/index.html
> 
>>> On Jul 15, 2020, at 12:07 PM, 'hctp...@googlemail.com' via 
>>> weewx-user  wrote:
>>> 
>> ok...last post for now...maybe this is the problem, see 
>> screenshot...

Re: [weewx-user] Questions about weewx-loopdata 1.3.x

2020-07-16 Thread John Kline

Cool.

This is looking good:  https://livewetter.hcpeters.de/

> On Jul 16, 2020, at 2:53 PM, 'hctp...@googlemail.com' via weewx-user 
>  wrote:
> 
> John,
> 
> I think you are right as there a many processes writing files on and on to 
> disk...
> But it took me 20sec to move the loop-data.txt to tempfs! So I did just for 
> fun:
> 
> changed 
> loop_data_dir = /dev/shm
> 
> and made a softlink in the weatherboard html dir:
> 
> loop-data.txt -> /dev/shm/loop-data.txt
> 
> Voila!
> 
> So loop-data.txt now written to ram...! ;-) 
> 
> Regards,
> 
> Christian 
> 
> 
> 
> 
> 
> 
> jo...@johnkline.com schrieb am Mittwoch, 15. Juli 2020 um 22:32:15 UTC+2:
>> Thanks for sending those links.
>> 
>> Again, I don’t think it’s necessary to move the file to ram disk.  With 
>> modern SSDs and wear leveling, and especially with a file this size.  You 
>> might want to do some web searches before deciding if its worth the effort.
>> 
 On Jul 15, 2020, at 1:14 PM, 'hctp...@googlemail.com' via weewx-user 
  wrote:
 
>>> John,
>>> 
>>> so maybe a project for the next days to put the loop-data.tx into ram and 
>>> serve it via apache2. 
>>> The WeatherBoard site:
>>> 
>>> https://livewetter.hcpeters.de
>>> 
>>> and my main weather site:
>>> 
>>> https://wetter.hcpeters.de/
>>> 
>>> .
>>> The gauges you see on the main site seems to use Javascript so that's why I 
>>> asked...! :-D 
>>> At the moment I just give a fixed value and render the entire site every 
>>> minute...near realtime... ;-) 
>>> 
>>> But diving into java would be a big task not sure I'm ready for 
>>> thatalready fighting with Python...! :-D
>>> 
>>> Regards,
>>> 
>>> Christian 
>>> 
>>> 
>>> 
>>> jo...@johnkline.com schrieb am Mittwoch, 15. Juli 2020 um 21:59:47 UTC+2:
 I do not personally regard it as a problem.  Others may have a different 
 opinion.
 
 It certainly is not necessary to have it on the SSD, but you would have to 
 configure apache2 (or whatever web server you are using), to be able to 
 serve loop-data.txt.
 
 BTW, is your site visible externally?  If so, would you send a link?
 
>> On Jul 15, 2020, at 12:46 PM, 'hctp...@googlemail.com' via weewx-user 
>>  wrote:
>> 
> John,
 
> 
> is this a problem to write the loop-data.txt file every 2sec on a SSD 
> regarding durability!?
> Or would it be better to place it on a ramdisk (tmpfs) like /dev/shm ...
> 
> Regards,
> 
> Christian 
> 
> jo...@johnkline.com schrieb am Mittwoch, 15. Juli 2020 um 21:35:27 UTC+2:
>> Great news!
>> 
>> The purpose of LoopData is to be able to add to any skin, but it does 
>> require knowledge of JavaScript.
>> 
 On Jul 15, 2020, at 12:33 PM, John Kline  wrote:
 
>>> 
>> 
>>> 
>>> tail -f loop-data.txt won’t work because a new file is created on every 
>>> loop.
>>> 
>>> You can use:
>>> watch cat loop-data.txt
>>> 
>>> You screen shots are not of any javascript errors that might be on the 
>>> page.
>>> 
>>> Would you send me the following file?
>>> /var/www/html/weewx/weatherboard/index.html
>>> 
> On Jul 15, 2020, at 12:07 PM, 'hctp...@googlemail.com' via weewx-user 
>  wrote:
> 
 ok...last post for now...maybe this is the problem, see screenshot...
 
 hctp...@googlemail.com schrieb am Mittwoch, 15. Juli 2020 um 20:54:42 
 UTC+2:
> ...and the error form the browser after changes as screenshot
> 
> hctp...@googlemail.com schrieb am Mittwoch, 15. Juli 2020 um 20:49:18 
> UTC+2:
>> Ok, 
>> cat /var/www/html/weewx/loop-data.txt 
>> 
>> {"current.dateTime.raw": 1594838795, 
>> "current.windDir.ordinal_compass": "NW", "day.rain.sum": "3,0 mm", 
>> "current.dewpoint": "8,9\u00b0C", "current.outTemp": "16,7\u00b0C", 
>> "current.rainRate": "0,0 mm/h", "current.windSpeed": "3,2 km/h", 
>> "day.windGust.max": "27,4 km/h", "10m.windGust.max": "8,0 km/h", 
>> "current.windSpeed.raw": 3.218688}
>> 
>> (with missing "current.windSpeed.raw")
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> hctp...@googlemail.com schrieb am Mittwoch, 15. Juli 2020 um 
>> 20:39:01 UTC+2:
>>> John,
>>> 
>>> strange...maybe I really should delete anything and start from 
>>> scratch?
>>> 
>>> But before one more try.. I'm sure the loopdata is made, see some 
>>> 'cat' of the file:
>>> cat /var/www/html/weewx/loop-data.txt 
>>> {"current.dateTime.raw": 1594836959, 
>>> "current.windDir.ordinal_compass": "NW", "day.rain.sum": "3,0 mm", 
>>> "current.dewpoint": "8,7\u00b0C", "current.outTemp": "17,1\u00b0C", 
>>>

Re: [weewx-user] Questions about weewx-loopdata 1.3.x

John,

I think you are right as there a many processes writing files on and on to 
disk...
But it took me 20sec to move the loop-data.txt to tempfs! So I did just for 
fun:

changed 

loop_data_dir = /dev/shm

and made a softlink in the weatherboard html dir:

*loop-data.txt* -> /dev/shm/loop-data.txt

Voila!

So loop-data.txt now written to ram...! ;-) 

Regards,

Christian 




jo...@johnkline.com schrieb am Mittwoch, 15. Juli 2020 um 22:32:15 UTC+2:

> Thanks for sending those links.
>
> Again, I don’t think it’s necessary to move the file to ram disk.  With 
> modern SSDs and wear leveling, and especially with a file this size.  You 
> might want to do some web searches before deciding if its worth the effort.
>
> On Jul 15, 2020, at 1:14 PM, 'hctp...@googlemail.com' via weewx-user <
> weewx...@googlegroups.com> wrote:
>
> John,
>
> so maybe a project for the next days to put the loop-data.tx into ram and 
> serve it via apache2. 
> The WeatherBoard site:
>
> https://livewetter.hcpeters.de
>
> and my main weather site:
>
> https://wetter.hcpeters.de/
>
> .
> The gauges you see on the main site seems to use Javascript so that's why 
> I asked...! :-D 
> At the moment I just give a fixed value and render the entire site every 
> minute...near realtime... ;-) 
>
> But diving into java would be a big task not sure I'm ready for 
> thatalready fighting with Python...! :-D
>
> Regards,
>
> Christian 
>
>
>
> jo...@johnkline.com schrieb am Mittwoch, 15. Juli 2020 um 21:59:47 UTC+2:
>
>> I do not personally regard it as a problem.  Others may have a different 
>> opinion.
>>
>> It certainly is not necessary to have it on the SSD, but you would have 
>> to configure apache2 (or whatever web server you are using), to be able to 
>> serve loop-data.txt.
>>
>> BTW, is your site visible externally?  If so, would you send a link?
>>
>> On Jul 15, 2020, at 12:46 PM, 'hctp...@googlemail.com' via weewx-user <
>> weewx...@googlegroups.com> wrote:
>>
>> John,
>>
>>
>> is this a problem to write the loop-data.txt file every 2sec on a SSD 
>> regarding durability!?
>> Or would it be better to place it on a ramdisk (tmpfs) like /dev/shm ...
>>
>> Regards,
>>
>> Christian 
>>
>> jo...@johnkline.com schrieb am Mittwoch, 15. Juli 2020 um 21:35:27 UTC+2:
>>
>>> Great news!
>>>
>>> The purpose of LoopData is to be able to add to any skin, but it does 
>>> require knowledge of JavaScript.
>>>
>>> On Jul 15, 2020, at 12:33 PM, John Kline  wrote:
>>>
>>> 
>>>
>>> 
>>> tail -f loop-data.txt won’t work because a new file is created on every 
>>> loop.
>>>
>>> You can use:
>>> watch cat loop-data.txt
>>>
>>> You screen shots are not of any javascript errors that might be on the 
>>> page.
>>>
>>> Would you send me the following file?
>>> /var/www/html/weewx/weatherboard/index.html
>>>
>>> On Jul 15, 2020, at 12:07 PM, 'hctp...@googlemail.com' via weewx-user <
>>> weewx...@googlegroups.com> wrote:
>>>
>>> ok...last post for now...maybe this is the problem, see screenshot...
>>>
>>> hctp...@googlemail.com schrieb am Mittwoch, 15. Juli 2020 um 20:54:42 
>>> UTC+2:
>>>
 ...and the error form the browser after changes as screenshot

 hctp...@googlemail.com schrieb am Mittwoch, 15. Juli 2020 um 20:49:18 
 UTC+2:

> Ok, 
>
> cat /var/www/html/weewx/loop-data.txt 
>
> {"current.dateTime.raw": 1594838795, 
> "current.windDir.ordinal_compass": "NW", "day.rain.sum": "3,0 mm", 
> "current.dewpoint": "8,9\u00b0C", "current.outTemp": "16,7\u00b0C", 
> "current.rainRate": "0,0 mm/h", "current.windSpeed": "3,2 km/h", 
> "day.windGust.max": "27,4 km/h", "10m.windGust.max": "8,0 
> km/h", "current.windSpeed.raw": 3.218688}
>
> (with missing "current.windSpeed.raw")
>
> 
>
>
>
>
>
>
> hctp...@googlemail.com schrieb am Mittwoch, 15. Juli 2020 um 20:39:01 
> UTC+2:
>
>> John,
>>
>> strange...maybe I really should delete anything and start from 
>> scratch?
>>
>> But before one more try.. I'm sure the loopdata is made, see some 
>> 'cat' of the file:
>>
>> *cat /var/www/html/weewx/loop-data.txt {"current.dateTime.raw": 
>> 1594836959, "current.windDir.ordinal_compass": "NW", "day.rain.sum": 
>> "3,0 
>> mm", "current.dewpoint": "8,7\u00b0C", "current.outTemp": "17,1\u00b0C", 
>> "current.rainRate": "1,2 mm/h", "current.windSpeed": "3,2 km/h", 
>> "day.windGust.max": "27,4 km/h", "10m.windGust.max": "14,5 km/h"}*
>>
>>
>> *cat /var/www/html/weewx/loop-data.txt {"current.dateTime.raw": 
>> 1594836976, "current.windDir.ordinal_compass": "NNW", "day.rain.sum": 
>> "3,0 
>> mm", "current.dewpoint": "8,7\u00b0C", "current.outTemp": "17,1\u00b0C", 
>> "current.rainRate": "1,0 mm/h", "current.windSpeed": "8,0 km/h", 
>> "day.windGust.max": "27,4 km/h", "10m.windGust.max": "14,5 km/h"}*
>>
>>
>> *cat /var/www/html/weewx/loop-data.txt

Re: [weewx-user] Questions about weewx-loopdata 1.3.x

2020-07-16 Thread geni08...@gmail.com

 Hi John, Thank you for your help so far, my next goal is to update the 
Belchertown template with weewx-loopdata.
MQTT needs an infrastructure there ... I find your solution really elegant. Do 
you have a tip for me where to start?


jo...@johnkline.com schrieb am Donnerstag, 16. Juli 2020 um 15:46:28 UTC+2:

> It looks like you are on a roll!
>
> I think you are asking why I don’t have the actual values filled in for 
> windGust in the template.
>
> The answer for $10m.windGust.max is that the $10m period is only 
> understood by LoopData.  If you put $10m.windGust.max in the template, it 
> would cause an error.  There is probably a way to compute the 10 minute 
> high gust, but I didn’t bother to figure that out since the value will 
> appear anyway on the next loop.
>
> For $day.windGust.max, adding it to the template should work just fine. 
>  It’s not needed.  In fact, none of the values are needed since they are 
> overwritten by the JavaScript.
>
>
>
> On Jul 16, 2020, at 5:26 AM, geni08...@gmail.com  
> wrote:
>
>  Hi John, it could even add winDir and barometer and humidity!
>
> What I would like to know why is enough for the two windGust values only 
> the id in index.html.tmpl 
> https://affolter.familyds.net/wetter/live/
>
> 
>
>
> jo...@johnkline.com schrieb am Mittwoch, 15. Juli 2020 um 22:32:15 UTC+2:
>
>> Thanks for sending those links.
>>
>> Again, I don’t think it’s necessary to move the file to ram disk.  With 
>> modern SSDs and wear leveling, and especially with a file this size.  You 
>> might want to do some web searches before deciding if its worth the effort.
>>
>> On Jul 15, 2020, at 1:14 PM, 'hctp...@googlemail.com' via weewx-user <
>> weewx...@googlegroups.com> wrote:
>>
>> John,
>>
>> so maybe a project for the next days to put the loop-data.tx into ram and 
>> serve it via apache2. 
>> The WeatherBoard site:
>>
>> https://livewetter.hcpeters.de
>>
>> and my main weather site:
>>
>> https://wetter.hcpeters.de/
>>
>> .
>> The gauges you see on the main site seems to use Javascript so that's why 
>> I asked...! :-D 
>> At the moment I just give a fixed value and render the entire site every 
>> minute...near realtime... ;-) 
>>
>> But diving into java would be a big task not sure I'm ready for 
>> thatalready fighting with Python...! :-D
>>
>> Regards,
>>
>> Christian 
>>
>>
>>
>> jo...@johnkline.com schrieb am Mittwoch, 15. Juli 2020 um 21:59:47 UTC+2:
>>
>>> I do not personally regard it as a problem.  Others may have a different 
>>> opinion.
>>>
>>> It certainly is not necessary to have it on the SSD, but you would have 
>>> to configure apache2 (or whatever web server you are using), to be able to 
>>> serve loop-data.txt.
>>>
>>> BTW, is your site visible externally?  If so, would you send a link?
>>>
>>> On Jul 15, 2020, at 12:46 PM, 'hctp...@googlemail.com' via weewx-user <
>>> weewx...@googlegroups.com> wrote:
>>>
>>> John,
>>>
>>>
>>> is this a problem to write the loop-data.txt file every 2sec on a SSD 
>>> regarding durability!?
>>> Or would it be better to place it on a ramdisk (tmpfs) like /dev/shm ...
>>>
>>> Regards,
>>>
>>> Christian 
>>>
>>> jo...@johnkline.com schrieb am Mittwoch, 15. Juli 2020 um 21:35:27 
>>> UTC+2:
>>>
 Great news!

 The purpose of LoopData is to be able to add to any skin, but it does 
 require knowledge of JavaScript.

 On Jul 15, 2020, at 12:33 PM, John Kline  wrote:

 

 
 tail -f loop-data.txt won’t work because a new file is created on every 
 loop.

 You can use:
 watch cat loop-data.txt

 You screen shots are not of any javascript errors that might be on the 
 page.

 Would you send me the following file?
 /var/www/html/weewx/weatherboard/index.html

 On Jul 15, 2020, at 12:07 PM, 'hctp...@googlemail.com' via weewx-user <
 weewx...@googlegroups.com> wrote:

 ok...last post for now...maybe this is the problem, see screenshot...

 hctp...@googlemail.com schrieb am Mittwoch, 15. Juli 2020 um 20:54:42 
 UTC+2:

> ...and the error form the browser after changes as screenshot
>
> hctp...@googlemail.com schrieb am Mittwoch, 15. Juli 2020 um 20:49:18 
> UTC+2:
>
>> Ok, 
>>
>> cat /var/www/html/weewx/loop-data.txt 
>>
>> {"current.dateTime.raw": 1594838795, 
>> "current.windDir.ordinal_compass": "NW", "day.rain.sum": "3,0 mm", 
>> "current.dewpoint": "8,9\u00b0C", "current.outTemp": "16,7\u00b0C", 
>> "current.rainRate": "0,0 mm/h", "current.windSpeed": "3,2 km/h", 
>> "day.windGust.max": "27,4 km/h", "10m.windGust.max": "8,0 
>> km/h", "current.windSpeed.raw": 3.218688}
>>
>> (with missing "current.windSpeed.raw")
>>
>> 
>>
>>
>>
>>
>>
>>
>> hctp...@googlemail.com schrieb am Mittwoch, 15. Juli 2020 um 
>> 20:39:01 UTC+2:
>>
>>> John,
>>>
>>> strange...maybe I really should

Re: [weewx-user] Questions about weewx-loopdata 1.3.x

2020-07-16 Thread John Kline

It looks like you are on a roll!

I think you are asking why I don’t have the actual values filled in for 
windGust in the template.

The answer for $10m.windGust.max is that the $10m period is only understood by 
LoopData.  If you put $10m.windGust.max in the template, it would cause an 
error.  There is probably a way to compute the 10 minute high gust, but I 
didn’t bother to figure that out since the value will appear anyway on the next 
loop.

For $day.windGust.max, adding it to the template should work just fine.  It’s 
not needed.  In fact, none of the values are needed since they are overwritten 
by the JavaScript.



>> On Jul 16, 2020, at 5:26 AM, geni08...@gmail.com  
>> wrote:
>  Hi John, it could even add winDir and barometer and humidity!
> What I would like to know why is enough for the two windGust values only the 
> id in index.html.tmpl 
> https://affolter.familyds.net/wetter/live/
> 
> 
> 
> 
> jo...@johnkline.com schrieb am Mittwoch, 15. Juli 2020 um 22:32:15 UTC+2:
>> Thanks for sending those links.
>> 
>> Again, I don’t think it’s necessary to move the file to ram disk.  With 
>> modern SSDs and wear leveling, and especially with a file this size.  You 
>> might want to do some web searches before deciding if its worth the effort.
>> 
 On Jul 15, 2020, at 1:14 PM, 'hctp...@googlemail.com' via weewx-user 
  wrote:
>>> John,
>>> 
>>> so maybe a project for the next days to put the loop-data.tx into ram and 
>>> serve it via apache2. 
>>> The WeatherBoard site:
>>> 
>>> https://livewetter.hcpeters.de
>>> 
>>> and my main weather site:
>>> 
>>> https://wetter.hcpeters.de/
>>> 
>>> .
>>> The gauges you see on the main site seems to use Javascript so that's why I 
>>> asked...! :-D 
>>> At the moment I just give a fixed value and render the entire site every 
>>> minute...near realtime... ;-) 
>>> 
>>> But diving into java would be a big task not sure I'm ready for 
>>> thatalready fighting with Python...! :-D
>>> 
>>> Regards,
>>> 
>>> Christian 
>>> 
>>> 
>>> 
>>> jo...@johnkline.com schrieb am Mittwoch, 15. Juli 2020 um 21:59:47 UTC+2:
 I do not personally regard it as a problem.  Others may have a different 
 opinion.
 
 It certainly is not necessary to have it on the SSD, but you would have to 
 configure apache2 (or whatever web server you are using), to be able to 
 serve loop-data.txt.
 
 BTW, is your site visible externally?  If so, would you send a link?
 
>> On Jul 15, 2020, at 12:46 PM, 'hctp...@googlemail.com' via weewx-user 
>>  wrote:
> John,
 
> 
> is this a problem to write the loop-data.txt file every 2sec on a SSD 
> regarding durability!?
> Or would it be better to place it on a ramdisk (tmpfs) like /dev/shm ...
> 
> Regards,
> 
> Christian 
> 
> jo...@johnkline.com schrieb am Mittwoch, 15. Juli 2020 um 21:35:27 UTC+2:
>> Great news!
>> 
>> The purpose of LoopData is to be able to add to any skin, but it does 
>> require knowledge of JavaScript.
>> 
 On Jul 15, 2020, at 12:33 PM, John Kline  wrote:
>>> 
>> 
>>> 
>>> tail -f loop-data.txt won’t work because a new file is created on every 
>>> loop.
>>> 
>>> You can use:
>>> watch cat loop-data.txt
>>> 
>>> You screen shots are not of any javascript errors that might be on the 
>>> page.
>>> 
>>> Would you send me the following file?
>>> /var/www/html/weewx/weatherboard/index.html
>>> 
> On Jul 15, 2020, at 12:07 PM, 'hctp...@googlemail.com' via weewx-user 
>  wrote:
 ok...last post for now...maybe this is the problem, see screenshot...
 
 hctp...@googlemail.com schrieb am Mittwoch, 15. Juli 2020 um 20:54:42 
 UTC+2:
> ...and the error form the browser after changes as screenshot
> 
> hctp...@googlemail.com schrieb am Mittwoch, 15. Juli 2020 um 20:49:18 
> UTC+2:
>> Ok, 
>> cat /var/www/html/weewx/loop-data.txt 
>> 
>> {"current.dateTime.raw": 1594838795, 
>> "current.windDir.ordinal_compass": "NW", "day.rain.sum": "3,0 mm", 
>> "current.dewpoint": "8,9\u00b0C", "current.outTemp": "16,7\u00b0C", 
>> "current.rainRate": "0,0 mm/h", "current.windSpeed": "3,2 km/h", 
>> "day.windGust.max": "27,4 km/h", "10m.windGust.max": "8,0 km/h", 
>> "current.windSpeed.raw": 3.218688}
>> 
>> (with missing "current.windSpeed.raw")
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> hctp...@googlemail.com schrieb am Mittwoch, 15. Juli 2020 um 
>> 20:39:01 UTC+2:
>>> John,
>>> 
>>> strange...maybe I really should delete anything and start from 
>>> scratch?
>>> 
>>> But before one more try.. I'm sure the loopdata is made, see some

Re: [weewx-user] Questions about weewx-loopdata 1.3.x

2020-07-15 Thread 'hctp...@googlemail.com' via weewx-user

Thanks for sending those links.

Again, I don’t think it’s necessary to move the file to ram disk.  With modern 
SSDs and wear leveling, and especially with a file this size.  You might want 
to do some web searches before deciding if its worth the effort.

> On Jul 15, 2020, at 1:14 PM, 'hctp...@googlemail.com' via weewx-user 
>  wrote:
> 
> John,
> 
> so maybe a project for the next days to put the loop-data.tx into ram and 
> serve it via apache2. 
> The WeatherBoard site:
> 
> https://livewetter.hcpeters.de
> 
> and my main weather site:
> 
> https://wetter.hcpeters.de/
> 
> .
> The gauges you see on the main site seems to use Javascript so that's why I 
> asked...! :-D 
> At the moment I just give a fixed value and render the entire site every 
> minute...near realtime... ;-) 
> 
> But diving into java would be a big task not sure I'm ready for 
> thatalready fighting with Python...! :-D
> 
> Regards,
> 
> Christian 
> 
> 
> 
> jo...@johnkline.com schrieb am Mittwoch, 15. Juli 2020 um 21:59:47 UTC+2:
>> I do not personally regard it as a problem.  Others may have a different 
>> opinion.
>> 
>> It certainly is not necessary to have it on the SSD, but you would have to 
>> configure apache2 (or whatever web server you are using), to be able to 
>> serve loop-data.txt.
>> 
>> BTW, is your site visible externally?  If so, would you send a link?
>> 
 On Jul 15, 2020, at 12:46 PM, 'hctp...@googlemail.com' via weewx-user 
  wrote:
 
>>> John,
>> 
>>> 
>>> is this a problem to write the loop-data.txt file every 2sec on a SSD 
>>> regarding durability!?
>>> Or would it be better to place it on a ramdisk (tmpfs) like /dev/shm ...
>>> 
>>> Regards,
>>> 
>>> Christian 
>>> 
>>> jo...@johnkline.com schrieb am Mittwoch, 15. Juli 2020 um 21:35:27 UTC+2:
 Great news!
 
 The purpose of LoopData is to be able to add to any skin, but it does 
 require knowledge of JavaScript.
 
>> On Jul 15, 2020, at 12:33 PM, John Kline  wrote:
>> 
> 
 
> 
> tail -f loop-data.txt won’t work because a new file is created on every 
> loop.
> 
> You can use:
> watch cat loop-data.txt
> 
> You screen shots are not of any javascript errors that might be on the 
> page.
> 
> Would you send me the following file?
> /var/www/html/weewx/weatherboard/index.html
> 
>>> On Jul 15, 2020, at 12:07 PM, 'hctp...@googlemail.com' via weewx-user 
>>>  wrote:
>>> 
>> ok...last post for now...maybe this is the problem, see screenshot...
>> 
>> hctp...@googlemail.com schrieb am Mittwoch, 15. Juli 2020 um 20:54:42 
>> UTC+2:
>>> ...and the error form the browser after changes as screenshot
>>> 
>>> hctp...@googlemail.com schrieb am Mittwoch, 15. Juli 2020 um 20:49:18 
>>> UTC+2:
 Ok, 
 cat /var/www/html/weewx/loop-data.txt 
 
 {"current.dateTime.raw": 1594838795, 
 "current.windDir.ordinal_compass": "NW", "day.rain.sum": "3,0 mm", 
 "current.dewpoint": "8,9\u00b0C", "current.outTemp": "16,7\u00b0C", 
 "current.rainRate": "0,0 mm/h", "current.windSpeed": "3,2 km/h", 
 "day.windGust.max": "27,4 km/h", "10m.windGust.max": "8,0 km/h", 
 "current.windSpeed.raw": 3.218688}
 
 (with missing "current.windSpeed.raw")
 
 
 
 
 
 
 
 
 
 
 hctp...@googlemail.com schrieb am Mittwoch, 15. Juli 2020 um 20:39:01 
 UTC+2:
> John,
> 
> strange...maybe I really should delete anything and start from 
> scratch?
> 
> But before one more try.. I'm sure the loopdata is made, see some 
> 'cat' of the file:
> cat /var/www/html/weewx/loop-data.txt 
> {"current.dateTime.raw": 1594836959, 
> "current.windDir.ordinal_compass": "NW", "day.rain.sum": "3,0 mm", 
> "current.dewpoint": "8,7\u00b0C", "current.outTemp": "17,1\u00b0C", 
> "current.rainRate": "1,2 mm/h", "current.windSpeed": "3,2 km/h", 
> "day.windGust.max": "27,4 km/h", "10m.windGust.max": "14,5 km/h"}
> 
> cat /var/www/html/weewx/loop-data.txt 
> {"current.dateTime.raw": 1594836976, 
> "current.windDir.ordinal_compass": "NNW", "day.rain.sum": "3,0 mm", 
> "current.dewpoint": "8,7\u00b0C", "current.outTemp": "17,1\u00b0C", 
> "current.rainRate": "1,0 mm/h", "current.windSpeed": "8,0 km/h", 
> "day.windGust.max": "27,4 km/h", "10m.windGust.max": "14,5 km/h"}
> 
> cat /var/www/html/weewx/loop-data.txt 
> {"current.dateTime.raw": 1594836979, 
> "current.windDir.ordinal_compass": "NNW", "day.rain.sum": "3,0 mm", 
> "current.dewpoint": "8,7\u00b0C", "current.outTemp": "17,1\u00b0C", 
> "current.rainRate": "1,0 mm/h", "current.windSpeed": "6,4 km/h", 
> "day.windGust.max":

Re: [weewx-user] Questions about weewx-loopdata 1.3.x

John,

so maybe a project for the next days to put the loop-data.tx into ram and 
serve it via apache2. 
The WeatherBoard site:

https://livewetter.hcpeters.de

and my main weather site:

https://wetter.hcpeters.de/

.
The gauges you see on the main site seems to use Javascript so that's why I 
asked...! :-D 
At the moment I just give a fixed value and render the entire site every 
minute...near realtime... ;-) 

But diving into java would be a big task not sure I'm ready for 
thatalready fighting with Python...! :-D

Regards,

Christian 



jo...@johnkline.com schrieb am Mittwoch, 15. Juli 2020 um 21:59:47 UTC+2:

> I do not personally regard it as a problem.  Others may have a different 
> opinion.
>
> It certainly is not necessary to have it on the SSD, but you would have to 
> configure apache2 (or whatever web server you are using), to be able to 
> serve loop-data.txt.
>
> BTW, is your site visible externally?  If so, would you send a link?
>
> On Jul 15, 2020, at 12:46 PM, 'hctp...@googlemail.com' via weewx-user <
> weewx...@googlegroups.com> wrote:
>
> John,
>
>
> is this a problem to write the loop-data.txt file every 2sec on a SSD 
> regarding durability!?
> Or would it be better to place it on a ramdisk (tmpfs) like /dev/shm ...
>
> Regards,
>
> Christian 
>
> jo...@johnkline.com schrieb am Mittwoch, 15. Juli 2020 um 21:35:27 UTC+2:
>
>> Great news!
>>
>> The purpose of LoopData is to be able to add to any skin, but it does 
>> require knowledge of JavaScript.
>>
>> On Jul 15, 2020, at 12:33 PM, John Kline  wrote:
>>
>> 
>>
>> 
>> tail -f loop-data.txt won’t work because a new file is created on every 
>> loop.
>>
>> You can use:
>> watch cat loop-data.txt
>>
>> You screen shots are not of any javascript errors that might be on the 
>> page.
>>
>> Would you send me the following file?
>> /var/www/html/weewx/weatherboard/index.html
>>
>> On Jul 15, 2020, at 12:07 PM, 'hctp...@googlemail.com' via weewx-user <
>> weewx...@googlegroups.com> wrote:
>>
>> ok...last post for now...maybe this is the problem, see screenshot...
>>
>> hctp...@googlemail.com schrieb am Mittwoch, 15. Juli 2020 um 20:54:42 
>> UTC+2:
>>
>>> ...and the error form the browser after changes as screenshot
>>>
>>> hctp...@googlemail.com schrieb am Mittwoch, 15. Juli 2020 um 20:49:18 
>>> UTC+2:
>>>
 Ok, 

 cat /var/www/html/weewx/loop-data.txt 

 {"current.dateTime.raw": 1594838795, "current.windDir.ordinal_compass": 
 "NW", "day.rain.sum": "3,0 mm", "current.dewpoint": "8,9\u00b0C", 
 "current.outTemp": "16,7\u00b0C", "current.rainRate": "0,0 mm/h", 
 "current.windSpeed": "3,2 km/h", "day.windGust.max": "27,4 km/h", 
 "10m.windGust.max": "8,0 km/h", "current.windSpeed.raw": 3.218688}

 (with missing "current.windSpeed.raw")

 






 hctp...@googlemail.com schrieb am Mittwoch, 15. Juli 2020 um 20:39:01 
 UTC+2:

> John,
>
> strange...maybe I really should delete anything and start from scratch?
>
> But before one more try.. I'm sure the loopdata is made, see some 
> 'cat' of the file:
>
> *cat /var/www/html/weewx/loop-data.txt {"current.dateTime.raw": 
> 1594836959, "current.windDir.ordinal_compass": "NW", "day.rain.sum": "3,0 
> mm", "current.dewpoint": "8,7\u00b0C", "current.outTemp": "17,1\u00b0C", 
> "current.rainRate": "1,2 mm/h", "current.windSpeed": "3,2 km/h", 
> "day.windGust.max": "27,4 km/h", "10m.windGust.max": "14,5 km/h"}*
>
>
> *cat /var/www/html/weewx/loop-data.txt {"current.dateTime.raw": 
> 1594836976, "current.windDir.ordinal_compass": "NNW", "day.rain.sum": 
> "3,0 
> mm", "current.dewpoint": "8,7\u00b0C", "current.outTemp": "17,1\u00b0C", 
> "current.rainRate": "1,0 mm/h", "current.windSpeed": "8,0 km/h", 
> "day.windGust.max": "27,4 km/h", "10m.windGust.max": "14,5 km/h"}*
>
>
> *cat /var/www/html/weewx/loop-data.txt {"current.dateTime.raw": 
> 1594836979, "current.windDir.ordinal_compass": "NNW", "day.rain.sum": 
> "3,0 
> mm", "current.dewpoint": "8,7\u00b0C", "current.outTemp": "17,1\u00b0C", 
> "current.rainRate": "1,0 mm/h", "current.windSpeed": "6,4 km/h", 
> "day.windGust.max": "27,4 km/h", "10m.windGust.max": "14,5 km/h"}*
>
>
>
> * cat /var/www/html/weewx/loop-data.txt {"current.dateTime.raw": 
> 1594836981, "current.windDir.ordinal_compass": "NNW", "day.rain.sum": 
> "3,0 
> mm", "current.dewpoint": "8,7\u00b0C", "current.outTemp": "17,1\u00b0C", 
> "current.rainRate": "1,0 mm/h", "current.windSpeed": "6,4 km/h", 
> "day.windGust.max": "27,4 km/h", "10m.windGust.max": "14,5 km/h"} *
>
>
>
> *cat /var/www/html/weewx/loop-data.txt {"current.dateTime.raw": 
> 1594836985, "current.windDir.ordinal_compass": "NW", "day.rain.sum": "3,0 
> mm", "current.dewpoint": "8,7\u00b0C", "current.outTemp": "17,1\u00b0C", 
>

Re: [weewx-user] Questions about weewx-loopdata 1.3.x

2020-07-15 Thread 'hctp...@googlemail.com' via weewx-user

I do not personally regard it as a problem.  Others may have a different 
opinion.

It certainly is not necessary to have it on the SSD, but you would have to 
configure apache2 (or whatever web server you are using), to be able to serve 
loop-data.txt.

BTW, is your site visible externally?  If so, would you send a link?

> On Jul 15, 2020, at 12:46 PM, 'hctp...@googlemail.com' via weewx-user 
>  wrote:
> 
> John,
> 
> is this a problem to write the loop-data.txt file every 2sec on a SSD 
> regarding durability!?
> Or would it be better to place it on a ramdisk (tmpfs) like /dev/shm ...
> 
> Regards,
> 
> Christian 
> 
> jo...@johnkline.com schrieb am Mittwoch, 15. Juli 2020 um 21:35:27 UTC+2:
>> Great news!
>> 
>> The purpose of LoopData is to be able to add to any skin, but it does 
>> require knowledge of JavaScript.
>> 
 On Jul 15, 2020, at 12:33 PM, John Kline  wrote:
 
>>> 
>> 
>>> 
>>> tail -f loop-data.txt won’t work because a new file is created on every 
>>> loop.
>>> 
>>> You can use:
>>> watch cat loop-data.txt
>>> 
>>> You screen shots are not of any javascript errors that might be on the page.
>>> 
>>> Would you send me the following file?
>>> /var/www/html/weewx/weatherboard/index.html
>>> 
> On Jul 15, 2020, at 12:07 PM, 'hctp...@googlemail.com' via weewx-user 
>  wrote:
> 
 ok...last post for now...maybe this is the problem, see screenshot...
 
 hctp...@googlemail.com schrieb am Mittwoch, 15. Juli 2020 um 20:54:42 
 UTC+2:
> ...and the error form the browser after changes as screenshot
> 
> hctp...@googlemail.com schrieb am Mittwoch, 15. Juli 2020 um 20:49:18 
> UTC+2:
>> Ok, 
>> cat /var/www/html/weewx/loop-data.txt 
>> 
>> {"current.dateTime.raw": 1594838795, "current.windDir.ordinal_compass": 
>> "NW", "day.rain.sum": "3,0 mm", "current.dewpoint": "8,9\u00b0C", 
>> "current.outTemp": "16,7\u00b0C", "current.rainRate": "0,0 mm/h", 
>> "current.windSpeed": "3,2 km/h", "day.windGust.max": "27,4 km/h", 
>> "10m.windGust.max": "8,0 km/h", "current.windSpeed.raw": 3.218688}
>> 
>> (with missing "current.windSpeed.raw")
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> hctp...@googlemail.com schrieb am Mittwoch, 15. Juli 2020 um 20:39:01 
>> UTC+2:
>>> John,
>>> 
>>> strange...maybe I really should delete anything and start from scratch?
>>> 
>>> But before one more try.. I'm sure the loopdata is made, see some 'cat' 
>>> of the file:
>>> cat /var/www/html/weewx/loop-data.txt 
>>> {"current.dateTime.raw": 1594836959, "current.windDir.ordinal_compass": 
>>> "NW", "day.rain.sum": "3,0 mm", "current.dewpoint": "8,7\u00b0C", 
>>> "current.outTemp": "17,1\u00b0C", "current.rainRate": "1,2 mm/h", 
>>> "current.windSpeed": "3,2 km/h", "day.windGust.max": "27,4 km/h", 
>>> "10m.windGust.max": "14,5 km/h"}
>>> 
>>> cat /var/www/html/weewx/loop-data.txt 
>>> {"current.dateTime.raw": 1594836976, "current.windDir.ordinal_compass": 
>>> "NNW", "day.rain.sum": "3,0 mm", "current.dewpoint": "8,7\u00b0C", 
>>> "current.outTemp": "17,1\u00b0C", "current.rainRate": "1,0 mm/h", 
>>> "current.windSpeed": "8,0 km/h", "day.windGust.max": "27,4 km/h", 
>>> "10m.windGust.max": "14,5 km/h"}
>>> 
>>> cat /var/www/html/weewx/loop-data.txt 
>>> {"current.dateTime.raw": 1594836979, "current.windDir.ordinal_compass": 
>>> "NNW", "day.rain.sum": "3,0 mm", "current.dewpoint": "8,7\u00b0C", 
>>> "current.outTemp": "17,1\u00b0C", "current.rainRate": "1,0 mm/h", 
>>> "current.windSpeed": "6,4 km/h", "day.windGust.max": "27,4 km/h", 
>>> "10m.windGust.max": "14,5 km/h"}
>>> 
>>> cat /var/www/html/weewx/loop-data.txt 
>>> {"current.dateTime.raw": 1594836981, "current.windDir.ordinal_compass": 
>>> "NNW", "day.rain.sum": "3,0 mm", "current.dewpoint": "8,7\u00b0C", 
>>> "current.outTemp": "17,1\u00b0C", "current.rainRate": "1,0 mm/h", 
>>> "current.windSpeed": "6,4 km/h", "day.windGust.max": "27,4 km/h", 
>>> "10m.windGust.max": "14,5 km/h"} 
>>> 
>>> cat /var/www/html/weewx/loop-data.txt 
>>> {"current.dateTime.raw": 1594836985, "current.windDir.ordinal_compass": 
>>> "NW", "day.rain.sum": "3,0 mm", "current.dewpoint": "8,7\u00b0C", 
>>> "current.outTemp": "17,1\u00b0C", "current.rainRate": "1,0 mm/h", 
>>> "current.windSpeed": "4,8 km/h", "day.windGust.max": "27,4 km/h", 
>>> "10m.windGust.max": "14,5 km/h"}# 
>>> 
>>> What I think is a little bit strange, a: 
>>> 
>>> tail -f /var/www/html/weewx/loop-data.txt 
>>> 
>>> doesn't show any changes after two seconds? Is there some cachingI 
>>> dont use the rsync Anyway...
>>> '
>>> by the way, I sometimes see floats at the time value like 
>>> "current.dateTime.raw": 1594837199.0..? 
>>> 
>>> Yes, I added this 
>>>

Re: [weewx-user] Questions about weewx-loopdata 1.3.x

John,

is this a problem to write the loop-data.txt file every 2sec on a SSD 
regarding durability!?
Or would it be better to place it on a ramdisk (tmpfs) like /dev/shm ...

Regards,

Christian 

jo...@johnkline.com schrieb am Mittwoch, 15. Juli 2020 um 21:35:27 UTC+2:

> Great news!
>
> The purpose of LoopData is to be able to add to any skin, but it does 
> require knowledge of JavaScript.
>
> On Jul 15, 2020, at 12:33 PM, John Kline  wrote:
>
> 
>
> 
> tail -f loop-data.txt won’t work because a new file is created on every 
> loop.
>
> You can use:
> watch cat loop-data.txt
>
> You screen shots are not of any javascript errors that might be on the 
> page.
>
> Would you send me the following file?
> /var/www/html/weewx/weatherboard/index.html
>
> On Jul 15, 2020, at 12:07 PM, 'hctp...@googlemail.com' via weewx-user <
> weewx...@googlegroups.com> wrote:
>
> ok...last post for now...maybe this is the problem, see screenshot...
>
> hctp...@googlemail.com schrieb am Mittwoch, 15. Juli 2020 um 20:54:42 
> UTC+2:
>
>> ...and the error form the browser after changes as screenshot
>>
>> hctp...@googlemail.com schrieb am Mittwoch, 15. Juli 2020 um 20:49:18 
>> UTC+2:
>>
>>> Ok, 
>>>
>>> cat /var/www/html/weewx/loop-data.txt 
>>>
>>> {"current.dateTime.raw": 1594838795, "current.windDir.ordinal_compass": 
>>> "NW", "day.rain.sum": "3,0 mm", "current.dewpoint": "8,9\u00b0C", 
>>> "current.outTemp": "16,7\u00b0C", "current.rainRate": "0,0 mm/h", 
>>> "current.windSpeed": "3,2 km/h", "day.windGust.max": "27,4 km/h", 
>>> "10m.windGust.max": "8,0 km/h", "current.windSpeed.raw": 3.218688}
>>>
>>> (with missing "current.windSpeed.raw")
>>>
>>> 
>>>
>>>
>>>
>>>
>>>
>>>
>>> hctp...@googlemail.com schrieb am Mittwoch, 15. Juli 2020 um 20:39:01 
>>> UTC+2:
>>>
 John,

 strange...maybe I really should delete anything and start from scratch?

 But before one more try.. I'm sure the loopdata is made, see some 'cat' 
 of the file:

 *cat /var/www/html/weewx/loop-data.txt {"current.dateTime.raw": 
 1594836959, "current.windDir.ordinal_compass": "NW", "day.rain.sum": "3,0 
 mm", "current.dewpoint": "8,7\u00b0C", "current.outTemp": "17,1\u00b0C", 
 "current.rainRate": "1,2 mm/h", "current.windSpeed": "3,2 km/h", 
 "day.windGust.max": "27,4 km/h", "10m.windGust.max": "14,5 km/h"}*


 *cat /var/www/html/weewx/loop-data.txt {"current.dateTime.raw": 
 1594836976, "current.windDir.ordinal_compass": "NNW", "day.rain.sum": "3,0 
 mm", "current.dewpoint": "8,7\u00b0C", "current.outTemp": "17,1\u00b0C", 
 "current.rainRate": "1,0 mm/h", "current.windSpeed": "8,0 km/h", 
 "day.windGust.max": "27,4 km/h", "10m.windGust.max": "14,5 km/h"}*


 *cat /var/www/html/weewx/loop-data.txt {"current.dateTime.raw": 
 1594836979, "current.windDir.ordinal_compass": "NNW", "day.rain.sum": "3,0 
 mm", "current.dewpoint": "8,7\u00b0C", "current.outTemp": "17,1\u00b0C", 
 "current.rainRate": "1,0 mm/h", "current.windSpeed": "6,4 km/h", 
 "day.windGust.max": "27,4 km/h", "10m.windGust.max": "14,5 km/h"}*



 * cat /var/www/html/weewx/loop-data.txt {"current.dateTime.raw": 
 1594836981, "current.windDir.ordinal_compass": "NNW", "day.rain.sum": "3,0 
 mm", "current.dewpoint": "8,7\u00b0C", "current.outTemp": "17,1\u00b0C", 
 "current.rainRate": "1,0 mm/h", "current.windSpeed": "6,4 km/h", 
 "day.windGust.max": "27,4 km/h", "10m.windGust.max": "14,5 km/h"} *



 *cat /var/www/html/weewx/loop-data.txt {"current.dateTime.raw": 
 1594836985, "current.windDir.ordinal_compass": "NW", "day.rain.sum": "3,0 
 mm", "current.dewpoint": "8,7\u00b0C", "current.outTemp": "17,1\u00b0C", 
 "current.rainRate": "1,0 mm/h", "current.windSpeed": "4,8 km/h", 
 "day.windGust.max": "27,4 km/h", "10m.windGust.max": "14,5 km/h"}# *

 What I think is a little bit strange, a: 

 *tail -f /var/www/html/weewx/loop-data.txt *

 doesn't show any changes after two seconds? Is there some cachingI 
 dont use the rsync Anyway...
 '
 by the way, I sometimes see floats at the time value like 
 "current.dateTime.raw": 1594837199.0..? 

 Yes, I added this 

 *report_services = weewx.engine.StdPrint, weewx.engine.StdReport, 
 user.loopdata.LoopData*

 and if I turn on debug=1 I see the file is written every loop.
 a 
 *cat /var/www/html/weewx/loop-data.txt*:
 {"current.dateTime.raw": 1594837649, "current.windDir.ordinal_compass": 
 "N", "day.rain.sum": "3,0 mm", "current.dewpoint": "9,0\u00b0C", 
 "current.outTemp": "16,8\u00b0C", "current.rainRate": "0,0 mm/h", 
 "current.windSpeed": "4,8 km/h", "day.windGust.max": "27,4 km/h", 
 "10m.windGust.max": "11,3 km/h"}
 {"current.dateTime.raw": 1594837577, "current.windDir.ordinal_compass": 
 "NW", "day.rain.sum": "3,0 mm", "current.dewpoint": "9,1\u00b0C",

Re: [weewx-user] Questions about weewx-loopdata 1.3.x

Great news!

The purpose of LoopData is to be able to add to any skin, but it does require 
knowledge of JavaScript.

> On Jul 15, 2020, at 12:33 PM, John Kline  wrote:
> 
> 
> 
> tail -f loop-data.txt won’t work because a new file is created on every loop.
> 
> You can use:
> watch cat loop-data.txt
> 
> You screen shots are not of any javascript errors that might be on the page.
> 
> Would you send me the following file?
> /var/www/html/weewx/weatherboard/index.html
> 
>>> On Jul 15, 2020, at 12:07 PM, 'hctp...@googlemail.com' via weewx-user 
>>>  wrote:
>>> 
>> ok...last post for now...maybe this is the problem, see screenshot...
>> 
>> hctp...@googlemail.com schrieb am Mittwoch, 15. Juli 2020 um 20:54:42 UTC+2:
>>> ...and the error form the browser after changes as screenshot
>>> 
>>> hctp...@googlemail.com schrieb am Mittwoch, 15. Juli 2020 um 20:49:18 UTC+2:
 Ok, 
 cat /var/www/html/weewx/loop-data.txt 
 
 {"current.dateTime.raw": 1594838795, "current.windDir.ordinal_compass": 
 "NW", "day.rain.sum": "3,0 mm", "current.dewpoint": "8,9\u00b0C", 
 "current.outTemp": "16,7\u00b0C", "current.rainRate": "0,0 mm/h", 
 "current.windSpeed": "3,2 km/h", "day.windGust.max": "27,4 km/h", 
 "10m.windGust.max": "8,0 km/h", "current.windSpeed.raw": 3.218688}
 
 (with missing "current.windSpeed.raw")
 
 
 
 
 
 
 
 
 
 
 hctp...@googlemail.com schrieb am Mittwoch, 15. Juli 2020 um 20:39:01 
 UTC+2:
> John,
> 
> strange...maybe I really should delete anything and start from scratch?
> 
> But before one more try.. I'm sure the loopdata is made, see some 'cat' 
> of the file:
> cat /var/www/html/weewx/loop-data.txt 
> {"current.dateTime.raw": 1594836959, "current.windDir.ordinal_compass": 
> "NW", "day.rain.sum": "3,0 mm", "current.dewpoint": "8,7\u00b0C", 
> "current.outTemp": "17,1\u00b0C", "current.rainRate": "1,2 mm/h", 
> "current.windSpeed": "3,2 km/h", "day.windGust.max": "27,4 km/h", 
> "10m.windGust.max": "14,5 km/h"}
> 
> cat /var/www/html/weewx/loop-data.txt 
> {"current.dateTime.raw": 1594836976, "current.windDir.ordinal_compass": 
> "NNW", "day.rain.sum": "3,0 mm", "current.dewpoint": "8,7\u00b0C", 
> "current.outTemp": "17,1\u00b0C", "current.rainRate": "1,0 mm/h", 
> "current.windSpeed": "8,0 km/h", "day.windGust.max": "27,4 km/h", 
> "10m.windGust.max": "14,5 km/h"}
> 
> cat /var/www/html/weewx/loop-data.txt 
> {"current.dateTime.raw": 1594836979, "current.windDir.ordinal_compass": 
> "NNW", "day.rain.sum": "3,0 mm", "current.dewpoint": "8,7\u00b0C", 
> "current.outTemp": "17,1\u00b0C", "current.rainRate": "1,0 mm/h", 
> "current.windSpeed": "6,4 km/h", "day.windGust.max": "27,4 km/h", 
> "10m.windGust.max": "14,5 km/h"}
> 
> cat /var/www/html/weewx/loop-data.txt 
> {"current.dateTime.raw": 1594836981, "current.windDir.ordinal_compass": 
> "NNW", "day.rain.sum": "3,0 mm", "current.dewpoint": "8,7\u00b0C", 
> "current.outTemp": "17,1\u00b0C", "current.rainRate": "1,0 mm/h", 
> "current.windSpeed": "6,4 km/h", "day.windGust.max": "27,4 km/h", 
> "10m.windGust.max": "14,5 km/h"} 
> 
> cat /var/www/html/weewx/loop-data.txt 
> {"current.dateTime.raw": 1594836985, "current.windDir.ordinal_compass": 
> "NW", "day.rain.sum": "3,0 mm", "current.dewpoint": "8,7\u00b0C", 
> "current.outTemp": "17,1\u00b0C", "current.rainRate": "1,0 mm/h", 
> "current.windSpeed": "4,8 km/h", "day.windGust.max": "27,4 km/h", 
> "10m.windGust.max": "14,5 km/h"}# 
> 
> What I think is a little bit strange, a: 
> 
> tail -f /var/www/html/weewx/loop-data.txt 
> 
> doesn't show any changes after two seconds? Is there some cachingI 
> dont use the rsync Anyway...
> '
> by the way, I sometimes see floats at the time value like 
> "current.dateTime.raw": 1594837199.0..? 
> 
> Yes, I added this 
> 
> report_services = weewx.engine.StdPrint, weewx.engine.StdReport, 
> user.loopdata.LoopData
> 
> and if I turn on debug=1 I see the file is written every loop.
> a 
> cat /var/www/html/weewx/loop-data.txt:
> {"current.dateTime.raw": 1594837649, "current.windDir.ordinal_compass": 
> "N", "day.rain.sum": "3,0 mm", "current.dewpoint": "9,0\u00b0C", 
> "current.outTemp": "16,8\u00b0C", "current.rainRate": "0,0 mm/h", 
> "current.windSpeed": "4,8 km/h", "day.windGust.max": "27,4 km/h", 
> "10m.windGust.max": "11,3 km/h"}
> {"current.dateTime.raw": 1594837577, "current.windDir.ordinal_compass": 
> "NW", "day.rain.sum": "3,0 mm", "current.dewpoint": "9,1\u00b0C", 
> "current.outTemp": "16,9\u00b0C", "current.rainRate": "0,0 mm/h", 
> "current.windSpeed": "6,4 km/h", "day.windGust.max": "27,4 km/h", 
> "10m.windGust.max": "11,3 km/h"}
> 
> a ls -laht

Re: [weewx-user] Questions about weewx-loopdata 1.3.x

2020-07-15 Thread 'hctp...@googlemail.com' via weewx-user


tail -f loop-data.txt won’t work because a new file is created on every loop.

You can use:
watch cat loop-data.txt

You screen shots are not of any javascript errors that might be on the page.

Would you send me the following file?
/var/www/html/weewx/weatherboard/index.html

>> On Jul 15, 2020, at 12:07 PM, 'hctp...@googlemail.com' via weewx-user 
>>  wrote:
> ok...last post for now...maybe this is the problem, see screenshot...
> 
> hctp...@googlemail.com schrieb am Mittwoch, 15. Juli 2020 um 20:54:42 UTC+2:
>> ...and the error form the browser after changes as screenshot
>> 
>> hctp...@googlemail.com schrieb am Mittwoch, 15. Juli 2020 um 20:49:18 UTC+2:
>>> Ok, 
>>> cat /var/www/html/weewx/loop-data.txt 
>>> 
>>> {"current.dateTime.raw": 1594838795, "current.windDir.ordinal_compass": 
>>> "NW", "day.rain.sum": "3,0 mm", "current.dewpoint": "8,9\u00b0C", 
>>> "current.outTemp": "16,7\u00b0C", "current.rainRate": "0,0 mm/h", 
>>> "current.windSpeed": "3,2 km/h", "day.windGust.max": "27,4 km/h", 
>>> "10m.windGust.max": "8,0 km/h", "current.windSpeed.raw": 3.218688}
>>> 
>>> (with missing "current.windSpeed.raw")
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> hctp...@googlemail.com schrieb am Mittwoch, 15. Juli 2020 um 20:39:01 UTC+2:
 John,
 
 strange...maybe I really should delete anything and start from scratch?
 
 But before one more try.. I'm sure the loopdata is made, see some 'cat' of 
 the file:
 cat /var/www/html/weewx/loop-data.txt 
 {"current.dateTime.raw": 1594836959, "current.windDir.ordinal_compass": 
 "NW", "day.rain.sum": "3,0 mm", "current.dewpoint": "8,7\u00b0C", 
 "current.outTemp": "17,1\u00b0C", "current.rainRate": "1,2 mm/h", 
 "current.windSpeed": "3,2 km/h", "day.windGust.max": "27,4 km/h", 
 "10m.windGust.max": "14,5 km/h"}
 
 cat /var/www/html/weewx/loop-data.txt 
 {"current.dateTime.raw": 1594836976, "current.windDir.ordinal_compass": 
 "NNW", "day.rain.sum": "3,0 mm", "current.dewpoint": "8,7\u00b0C", 
 "current.outTemp": "17,1\u00b0C", "current.rainRate": "1,0 mm/h", 
 "current.windSpeed": "8,0 km/h", "day.windGust.max": "27,4 km/h", 
 "10m.windGust.max": "14,5 km/h"}
 
 cat /var/www/html/weewx/loop-data.txt 
 {"current.dateTime.raw": 1594836979, "current.windDir.ordinal_compass": 
 "NNW", "day.rain.sum": "3,0 mm", "current.dewpoint": "8,7\u00b0C", 
 "current.outTemp": "17,1\u00b0C", "current.rainRate": "1,0 mm/h", 
 "current.windSpeed": "6,4 km/h", "day.windGust.max": "27,4 km/h", 
 "10m.windGust.max": "14,5 km/h"}
 
 cat /var/www/html/weewx/loop-data.txt 
 {"current.dateTime.raw": 1594836981, "current.windDir.ordinal_compass": 
 "NNW", "day.rain.sum": "3,0 mm", "current.dewpoint": "8,7\u00b0C", 
 "current.outTemp": "17,1\u00b0C", "current.rainRate": "1,0 mm/h", 
 "current.windSpeed": "6,4 km/h", "day.windGust.max": "27,4 km/h", 
 "10m.windGust.max": "14,5 km/h"} 
 
 cat /var/www/html/weewx/loop-data.txt 
 {"current.dateTime.raw": 1594836985, "current.windDir.ordinal_compass": 
 "NW", "day.rain.sum": "3,0 mm", "current.dewpoint": "8,7\u00b0C", 
 "current.outTemp": "17,1\u00b0C", "current.rainRate": "1,0 mm/h", 
 "current.windSpeed": "4,8 km/h", "day.windGust.max": "27,4 km/h", 
 "10m.windGust.max": "14,5 km/h"}# 
 
 What I think is a little bit strange, a: 
 
 tail -f /var/www/html/weewx/loop-data.txt 
 
 doesn't show any changes after two seconds? Is there some cachingI 
 dont use the rsync Anyway...
 '
 by the way, I sometimes see floats at the time value like 
 "current.dateTime.raw": 1594837199.0..? 
 
 Yes, I added this 
 
 report_services = weewx.engine.StdPrint, weewx.engine.StdReport, 
 user.loopdata.LoopData
 
 and if I turn on debug=1 I see the file is written every loop.
 a 
 cat /var/www/html/weewx/loop-data.txt:
 {"current.dateTime.raw": 1594837649, "current.windDir.ordinal_compass": 
 "N", "day.rain.sum": "3,0 mm", "current.dewpoint": "9,0\u00b0C", 
 "current.outTemp": "16,8\u00b0C", "current.rainRate": "0,0 mm/h", 
 "current.windSpeed": "4,8 km/h", "day.windGust.max": "27,4 km/h", 
 "10m.windGust.max": "11,3 km/h"}
 {"current.dateTime.raw": 1594837577, "current.windDir.ordinal_compass": 
 "NW", "day.rain.sum": "3,0 mm", "current.dewpoint": "9,1\u00b0C", 
 "current.outTemp": "16,9\u00b0C", "current.rainRate": "0,0 mm/h", 
 "current.windSpeed": "6,4 km/h", "day.windGust.max": "27,4 km/h", 
 "10m.windGust.max": "11,3 km/h"}
 
 a ls -laht /var/www/html/weewx/weatherboard
 
 drwxr-xr-x 12 www-data www-data 4,0K Jul 15 20:28 ..
 drwxr-xr-x  2 root root 4,0K Jul 15 20:27 .
 -rw-r--r--  1 root root  12K Jul 15 20:27 index.html
 -rw-r--r--  1 root root 1,7K Jul 15 19:41 weatherboard.css
 -rw-r--r--  1 root root

Re: [weewx-user] Questions about weewx-loopdata 1.3.x

John,

the path was wrong, you were right all the time. 
The loop-data.txt must be placed into the weatherboard html dir! 
Now found the java console in Safari and it gives me the error with the 
wrong path!
Now it updates and runs fine! 
Would be nice to add the live functionality in any skin but I fear there 
must be added some Java code
Maybe a future project! 

Thanks for you help! 
Now enjoying the new skin with live data! :-)

Regards,

Christian  

hctp...@googlemail.com schrieb am Mittwoch, 15. Juli 2020 um 21:07:22 UTC+2:

> ok...last post for now...maybe this is the problem, see screenshot...
>
> hctp...@googlemail.com schrieb am Mittwoch, 15. Juli 2020 um 20:54:42 
> UTC+2:
>
>> ...and the error form the browser after changes as screenshot
>>
>> hctp...@googlemail.com schrieb am Mittwoch, 15. Juli 2020 um 20:49:18 
>> UTC+2:
>>
>>> Ok, 
>>>
>>> cat /var/www/html/weewx/loop-data.txt 
>>>
>>> {"current.dateTime.raw": 1594838795, "current.windDir.ordinal_compass": 
>>> "NW", "day.rain.sum": "3,0 mm", "current.dewpoint": "8,9\u00b0C", 
>>> "current.outTemp": "16,7\u00b0C", "current.rainRate": "0,0 mm/h", 
>>> "current.windSpeed": "3,2 km/h", "day.windGust.max": "27,4 km/h", 
>>> "10m.windGust.max": "8,0 km/h", "current.windSpeed.raw": 3.218688}
>>>
>>> (with missing "current.windSpeed.raw")
>>>
>>> 
>>>
>>>
>>>
>>>
>>>
>>>
>>> hctp...@googlemail.com schrieb am Mittwoch, 15. Juli 2020 um 20:39:01 
>>> UTC+2:
>>>
 John,

 strange...maybe I really should delete anything and start from scratch?

 But before one more try.. I'm sure the loopdata is made, see some 'cat' 
 of the file:

 *cat /var/www/html/weewx/loop-data.txt {"current.dateTime.raw": 
 1594836959, "current.windDir.ordinal_compass": "NW", "day.rain.sum": "3,0 
 mm", "current.dewpoint": "8,7\u00b0C", "current.outTemp": "17,1\u00b0C", 
 "current.rainRate": "1,2 mm/h", "current.windSpeed": "3,2 km/h", 
 "day.windGust.max": "27,4 km/h", "10m.windGust.max": "14,5 km/h"}*


 *cat /var/www/html/weewx/loop-data.txt {"current.dateTime.raw": 
 1594836976, "current.windDir.ordinal_compass": "NNW", "day.rain.sum": "3,0 
 mm", "current.dewpoint": "8,7\u00b0C", "current.outTemp": "17,1\u00b0C", 
 "current.rainRate": "1,0 mm/h", "current.windSpeed": "8,0 km/h", 
 "day.windGust.max": "27,4 km/h", "10m.windGust.max": "14,5 km/h"}*


 *cat /var/www/html/weewx/loop-data.txt {"current.dateTime.raw": 
 1594836979, "current.windDir.ordinal_compass": "NNW", "day.rain.sum": "3,0 
 mm", "current.dewpoint": "8,7\u00b0C", "current.outTemp": "17,1\u00b0C", 
 "current.rainRate": "1,0 mm/h", "current.windSpeed": "6,4 km/h", 
 "day.windGust.max": "27,4 km/h", "10m.windGust.max": "14,5 km/h"}*



 * cat /var/www/html/weewx/loop-data.txt {"current.dateTime.raw": 
 1594836981, "current.windDir.ordinal_compass": "NNW", "day.rain.sum": "3,0 
 mm", "current.dewpoint": "8,7\u00b0C", "current.outTemp": "17,1\u00b0C", 
 "current.rainRate": "1,0 mm/h", "current.windSpeed": "6,4 km/h", 
 "day.windGust.max": "27,4 km/h", "10m.windGust.max": "14,5 km/h"} *



 *cat /var/www/html/weewx/loop-data.txt {"current.dateTime.raw": 
 1594836985, "current.windDir.ordinal_compass": "NW", "day.rain.sum": "3,0 
 mm", "current.dewpoint": "8,7\u00b0C", "current.outTemp": "17,1\u00b0C", 
 "current.rainRate": "1,0 mm/h", "current.windSpeed": "4,8 km/h", 
 "day.windGust.max": "27,4 km/h", "10m.windGust.max": "14,5 km/h"}# *

 What I think is a little bit strange, a: 

 *tail -f /var/www/html/weewx/loop-data.txt *

 doesn't show any changes after two seconds? Is there some cachingI 
 dont use the rsync Anyway...
 '
 by the way, I sometimes see floats at the time value like 
 "current.dateTime.raw": 1594837199.0..? 

 Yes, I added this 

 *report_services = weewx.engine.StdPrint, weewx.engine.StdReport, 
 user.loopdata.LoopData*

 and if I turn on debug=1 I see the file is written every loop.
 a 
 *cat /var/www/html/weewx/loop-data.txt*:
 {"current.dateTime.raw": 1594837649, "current.windDir.ordinal_compass": 
 "N", "day.rain.sum": "3,0 mm", "current.dewpoint": "9,0\u00b0C", 
 "current.outTemp": "16,8\u00b0C", "current.rainRate": "0,0 mm/h", 
 "current.windSpeed": "4,8 km/h", "day.windGust.max": "27,4 km/h", 
 "10m.windGust.max": "11,3 km/h"}
 {"current.dateTime.raw": 1594837577, "current.windDir.ordinal_compass": 
 "NW", "day.rain.sum": "3,0 mm", "current.dewpoint": "9,1\u00b0C", 
 "current.outTemp": "16,9\u00b0C", "current.rainRate": "0,0 mm/h", 
 "current.windSpeed": "6,4 km/h", "day.windGust.max": "27,4 km/h", 
 "10m.windGust.max": "11,3 km/h"}

 a* ls -laht /var/www/html/weewx/weatherboard*

 drwxr-xr-x 12 www-data www-data 4,0K Jul 15 20:28 ..
 drwxr-xr-x  2 root root

Re: [weewx-user] Questions about weewx-loopdata 1.3.x

2020-07-15 Thread 'hctp...@googlemail.com' via weewx-user

ok...last post for now...maybe this is the problem, see screenshot...

hctp...@googlemail.com schrieb am Mittwoch, 15. Juli 2020 um 20:54:42 UTC+2:

> ...and the error form the browser after changes as screenshot
>
> hctp...@googlemail.com schrieb am Mittwoch, 15. Juli 2020 um 20:49:18 
> UTC+2:
>
>> Ok, 
>>
>> cat /var/www/html/weewx/loop-data.txt 
>>
>> {"current.dateTime.raw": 1594838795, "current.windDir.ordinal_compass": 
>> "NW", "day.rain.sum": "3,0 mm", "current.dewpoint": "8,9\u00b0C", 
>> "current.outTemp": "16,7\u00b0C", "current.rainRate": "0,0 mm/h", 
>> "current.windSpeed": "3,2 km/h", "day.windGust.max": "27,4 km/h", 
>> "10m.windGust.max": "8,0 km/h", "current.windSpeed.raw": 3.218688}
>>
>> (with missing "current.windSpeed.raw")
>>
>> 
>>
>>
>>
>>
>>
>>
>> hctp...@googlemail.com schrieb am Mittwoch, 15. Juli 2020 um 20:39:01 
>> UTC+2:
>>
>>> John,
>>>
>>> strange...maybe I really should delete anything and start from scratch?
>>>
>>> But before one more try.. I'm sure the loopdata is made, see some 'cat' 
>>> of the file:
>>>
>>> *cat /var/www/html/weewx/loop-data.txt {"current.dateTime.raw": 
>>> 1594836959, "current.windDir.ordinal_compass": "NW", "day.rain.sum": "3,0 
>>> mm", "current.dewpoint": "8,7\u00b0C", "current.outTemp": "17,1\u00b0C", 
>>> "current.rainRate": "1,2 mm/h", "current.windSpeed": "3,2 km/h", 
>>> "day.windGust.max": "27,4 km/h", "10m.windGust.max": "14,5 km/h"}*
>>>
>>>
>>> *cat /var/www/html/weewx/loop-data.txt {"current.dateTime.raw": 
>>> 1594836976, "current.windDir.ordinal_compass": "NNW", "day.rain.sum": "3,0 
>>> mm", "current.dewpoint": "8,7\u00b0C", "current.outTemp": "17,1\u00b0C", 
>>> "current.rainRate": "1,0 mm/h", "current.windSpeed": "8,0 km/h", 
>>> "day.windGust.max": "27,4 km/h", "10m.windGust.max": "14,5 km/h"}*
>>>
>>>
>>> *cat /var/www/html/weewx/loop-data.txt {"current.dateTime.raw": 
>>> 1594836979, "current.windDir.ordinal_compass": "NNW", "day.rain.sum": "3,0 
>>> mm", "current.dewpoint": "8,7\u00b0C", "current.outTemp": "17,1\u00b0C", 
>>> "current.rainRate": "1,0 mm/h", "current.windSpeed": "6,4 km/h", 
>>> "day.windGust.max": "27,4 km/h", "10m.windGust.max": "14,5 km/h"}*
>>>
>>>
>>>
>>> * cat /var/www/html/weewx/loop-data.txt {"current.dateTime.raw": 
>>> 1594836981, "current.windDir.ordinal_compass": "NNW", "day.rain.sum": "3,0 
>>> mm", "current.dewpoint": "8,7\u00b0C", "current.outTemp": "17,1\u00b0C", 
>>> "current.rainRate": "1,0 mm/h", "current.windSpeed": "6,4 km/h", 
>>> "day.windGust.max": "27,4 km/h", "10m.windGust.max": "14,5 km/h"} *
>>>
>>>
>>>
>>> *cat /var/www/html/weewx/loop-data.txt {"current.dateTime.raw": 
>>> 1594836985, "current.windDir.ordinal_compass": "NW", "day.rain.sum": "3,0 
>>> mm", "current.dewpoint": "8,7\u00b0C", "current.outTemp": "17,1\u00b0C", 
>>> "current.rainRate": "1,0 mm/h", "current.windSpeed": "4,8 km/h", 
>>> "day.windGust.max": "27,4 km/h", "10m.windGust.max": "14,5 km/h"}# *
>>>
>>> What I think is a little bit strange, a: 
>>>
>>> *tail -f /var/www/html/weewx/loop-data.txt *
>>>
>>> doesn't show any changes after two seconds? Is there some cachingI 
>>> dont use the rsync Anyway...
>>> '
>>> by the way, I sometimes see floats at the time value like 
>>> "current.dateTime.raw": 1594837199.0..? 
>>>
>>> Yes, I added this 
>>>
>>> *report_services = weewx.engine.StdPrint, weewx.engine.StdReport, 
>>> user.loopdata.LoopData*
>>>
>>> and if I turn on debug=1 I see the file is written every loop.
>>> a 
>>> *cat /var/www/html/weewx/loop-data.txt*:
>>> {"current.dateTime.raw": 1594837649, "current.windDir.ordinal_compass": 
>>> "N", "day.rain.sum": "3,0 mm", "current.dewpoint": "9,0\u00b0C", 
>>> "current.outTemp": "16,8\u00b0C", "current.rainRate": "0,0 mm/h", 
>>> "current.windSpeed": "4,8 km/h", "day.windGust.max": "27,4 km/h", 
>>> "10m.windGust.max": "11,3 km/h"}
>>> {"current.dateTime.raw": 1594837577, "current.windDir.ordinal_compass": 
>>> "NW", "day.rain.sum": "3,0 mm", "current.dewpoint": "9,1\u00b0C", 
>>> "current.outTemp": "16,9\u00b0C", "current.rainRate": "0,0 mm/h", 
>>> "current.windSpeed": "6,4 km/h", "day.windGust.max": "27,4 km/h", 
>>> "10m.windGust.max": "11,3 km/h"}
>>>
>>> a* ls -laht /var/www/html/weewx/weatherboard*
>>>
>>> drwxr-xr-x 12 www-data www-data 4,0K Jul 15 20:28 ..
>>> drwxr-xr-x  2 root root 4,0K Jul 15 20:27 .
>>> -rw-r--r--  1 root root  12K Jul 15 20:27 index.html
>>> -rw-r--r--  1 root root 1,7K Jul 15 19:41 weatherboard.css
>>> -rw-r--r--  1 root root 3,5K Jul 15 19:41 favicon.ico
>>>
>>> So I'm not familiar with .js, I hope I opened the right one in my FF 
>>> browser. Never did anything with JavaScript! :-O  But I got some errors, 
>>> see attached screenshot. 
>>> Thanks for your patience!
>>> Maybe something is blocked by Apache2 (I host the site by myself)
>>>
>>> Regards,
>>>
>>> Christian 
>>> jo...@johnkline.com schrieb am Mittwoch, 15. Juli 2020 um 20:12:27 
>>> UTC+2:
>>>
 
 
 Hi

Re: [weewx-user] Questions about weewx-loopdata 1.3.x

2020-07-15 Thread 'hctp...@googlemail.com' via weewx-user

Ok, 

cat /var/www/html/weewx/loop-data.txt 

{"current.dateTime.raw": 1594838795, "current.windDir.ordinal_compass": 
"NW", "day.rain.sum": "3,0 mm", "current.dewpoint": "8,9\u00b0C", 
"current.outTemp": "16,7\u00b0C", "current.rainRate": "0,0 mm/h", 
"current.windSpeed": "3,2 km/h", "day.windGust.max": "27,4 km/h", 
"10m.windGust.max": "8,0 km/h", "current.windSpeed.raw": 3.218688}

(with missing "current.windSpeed.raw")








hctp...@googlemail.com schrieb am Mittwoch, 15. Juli 2020 um 20:39:01 UTC+2:

> John,
>
> strange...maybe I really should delete anything and start from scratch?
>
> But before one more try.. I'm sure the loopdata is made, see some 'cat' of 
> the file:
>
> *cat /var/www/html/weewx/loop-data.txt {"current.dateTime.raw": 
> 1594836959, "current.windDir.ordinal_compass": "NW", "day.rain.sum": "3,0 
> mm", "current.dewpoint": "8,7\u00b0C", "current.outTemp": "17,1\u00b0C", 
> "current.rainRate": "1,2 mm/h", "current.windSpeed": "3,2 km/h", 
> "day.windGust.max": "27,4 km/h", "10m.windGust.max": "14,5 km/h"}*
>
>
> *cat /var/www/html/weewx/loop-data.txt {"current.dateTime.raw": 
> 1594836976, "current.windDir.ordinal_compass": "NNW", "day.rain.sum": "3,0 
> mm", "current.dewpoint": "8,7\u00b0C", "current.outTemp": "17,1\u00b0C", 
> "current.rainRate": "1,0 mm/h", "current.windSpeed": "8,0 km/h", 
> "day.windGust.max": "27,4 km/h", "10m.windGust.max": "14,5 km/h"}*
>
>
> *cat /var/www/html/weewx/loop-data.txt {"current.dateTime.raw": 
> 1594836979, "current.windDir.ordinal_compass": "NNW", "day.rain.sum": "3,0 
> mm", "current.dewpoint": "8,7\u00b0C", "current.outTemp": "17,1\u00b0C", 
> "current.rainRate": "1,0 mm/h", "current.windSpeed": "6,4 km/h", 
> "day.windGust.max": "27,4 km/h", "10m.windGust.max": "14,5 km/h"}*
>
>
>
> * cat /var/www/html/weewx/loop-data.txt {"current.dateTime.raw": 
> 1594836981, "current.windDir.ordinal_compass": "NNW", "day.rain.sum": "3,0 
> mm", "current.dewpoint": "8,7\u00b0C", "current.outTemp": "17,1\u00b0C", 
> "current.rainRate": "1,0 mm/h", "current.windSpeed": "6,4 km/h", 
> "day.windGust.max": "27,4 km/h", "10m.windGust.max": "14,5 km/h"} *
>
>
>
> *cat /var/www/html/weewx/loop-data.txt {"current.dateTime.raw": 
> 1594836985, "current.windDir.ordinal_compass": "NW", "day.rain.sum": "3,0 
> mm", "current.dewpoint": "8,7\u00b0C", "current.outTemp": "17,1\u00b0C", 
> "current.rainRate": "1,0 mm/h", "current.windSpeed": "4,8 km/h", 
> "day.windGust.max": "27,4 km/h", "10m.windGust.max": "14,5 km/h"}# *
>
> What I think is a little bit strange, a: 
>
> *tail -f /var/www/html/weewx/loop-data.txt *
>
> doesn't show any changes after two seconds? Is there some cachingI 
> dont use the rsync Anyway...
> '
> by the way, I sometimes see floats at the time value like 
> "current.dateTime.raw": 1594837199.0..? 
>
> Yes, I added this 
>
> *report_services = weewx.engine.StdPrint, weewx.engine.StdReport, 
> user.loopdata.LoopData*
>
> and if I turn on debug=1 I see the file is written every loop.
> a 
> *cat /var/www/html/weewx/loop-data.txt*:
> {"current.dateTime.raw": 1594837649, "current.windDir.ordinal_compass": 
> "N", "day.rain.sum": "3,0 mm", "current.dewpoint": "9,0\u00b0C", 
> "current.outTemp": "16,8\u00b0C", "current.rainRate": "0,0 mm/h", 
> "current.windSpeed": "4,8 km/h", "day.windGust.max": "27,4 km/h", 
> "10m.windGust.max": "11,3 km/h"}
> {"current.dateTime.raw": 1594837577, "current.windDir.ordinal_compass": 
> "NW", "day.rain.sum": "3,0 mm", "current.dewpoint": "9,1\u00b0C", 
> "current.outTemp": "16,9\u00b0C", "current.rainRate": "0,0 mm/h", 
> "current.windSpeed": "6,4 km/h", "day.windGust.max": "27,4 km/h", 
> "10m.windGust.max": "11,3 km/h"}
>
> a* ls -laht /var/www/html/weewx/weatherboard*
>
> drwxr-xr-x 12 www-data www-data 4,0K Jul 15 20:28 ..
> drwxr-xr-x  2 root root 4,0K Jul 15 20:27 .
> -rw-r--r--  1 root root  12K Jul 15 20:27 index.html
> -rw-r--r--  1 root root 1,7K Jul 15 19:41 weatherboard.css
> -rw-r--r--  1 root root 3,5K Jul 15 19:41 favicon.ico
>
> So I'm not familiar with .js, I hope I opened the right one in my FF 
> browser. Never did anything with JavaScript! :-O  But I got some errors, 
> see attached screenshot. 
> Thanks for your patience!
> Maybe something is blocked by Apache2 (I host the site by myself)
>
> Regards,
>
> Christian 
> jo...@johnkline.com schrieb am Mittwoch, 15. Juli 2020 um 20:12:27 UTC+2:
>
>> 
>> 
>> Hi Christian,
>>
>> wee_extension should not have been using python2 if you did a python3 
>> install of weewx; but let’s put that aside.
>>
>> Of course, you should care that WeatherBoard is not updating on every 
>> loop cycle, that’s the whole point of it.
>>
>> I might be better if you deleted all you have done manually and do a 
>> proper install, but let’s try to work with what you have.
>>
>> Are you sure loop-data.txt is being generated?
>>
>> If in weewx.conf, under [Engine][[Services]], on the report_services 
>> line, do you see

Re: [weewx-user] Questions about weewx-loopdata 1.3.x

Also, please add all of the fields required by WeatherBoard (see the README).

current.dateTime.raw
current.windDir.ordinal_compass
day.rain.sum
current.dewpoint
current.outTemp
current.rainRate
current.windSpeed
current.windSpeed.raw
10m.windGust.max
day.windGust.max

You are missing current.windSpeed.raw.  It looks like you have 
current.windSpeed twice.  I think you meant one of them to be 
current.windSpeed.raw

>> fields = current.dateTime.raw,current.windDir.ordinal_compass, day.rain.sum, 
>> current.dewpoint,current.outTemp, current.rainRate, 
>> current.windSpeed,day.windGust.max, 10m.windGust.max, current.windSpeed


After you have fixed this, and with the loop-data.txt file you are sending, 
let’s see if there are missing observations.

> On Jul 15, 2020, at 11:12 AM, John Kline  wrote:
> 
> 
> 
> 
> Hi Christian,
> 
> wee_extension should not have been using python2 if you did a python3 install 
> of weewx; but let’s put that aside.
> 
> Of course, you should care that WeatherBoard is not updating on every loop 
> cycle, that’s the whole point of it.
> 
> I might be better if you deleted all you have done manually and do a proper 
> install, but let’s try to work with what you have.
> 
> Are you sure loop-data.txt is being generated?
> 
> If in weewx.conf, under [Engine][[Services]], on the report_services line, do 
> you see user.loopdata.LoopData?
> 
> Would you send me a copy of /var/www/html/weewx/loop-data.txt?
> 
> Would you send me a directory listing of /var/www/html/weewx/weatherboard?
> 
> Lastly, from your browser, would you bring up the JavaScript console and tell 
> me the error(s) you see?
> 
>>> On Jul 15, 2020, at 10:53 AM, 'Christian Peters' via weewx-user 
>>>  wrote:
>>> 
>> 
>> John,
>> 
>> I struggeld installing the extension. I got:
>> Traceback (most recent call last):
>>   File "/usr/share/weewx/wee_extension", line 13, in 
>> import weecfg.extension
>>   File "/usr/share/weewx/weecfg/__init__.py", line 22, in 
>> import configobj
>> ImportError: No module named configobj
>> 
>> ..but the module was installed! 
>> I then figured out that wee_extension uses python2 but not python3 so the 
>> module was missing in python 2!  ;-)
>> I treid to gove Python3 a try with weewx this time as I reinstalled it!
>> I changed in we_extension the first line to 
>> 
>> #!/usr/bin/env python3
>> 
>> and it works. 
>> 
>> But first I installed the loop-data exxtension by hand...but I think all is 
>> in the right place as the loop-data.txt is build.
>> 
>> The WeatherBoardReport section in weewx.conf:
>> 
>> [[WeatherBoardReport]]
>> HTML_ROOT = /var/www/html/weewx/weatherboard
>> enable = true
>> skin = WeatherBoard
>> [[[Extras]]]
>> meta_title = Live-Wetter Langenseifen, Hessen  Weather at a 
>> Glance WeatherBoard
>> title = Live-Wetter Langenseifen Hessen WeatherBoard
>> subtitle = Fortlaufend aktualisiert.
>> logo = ""
>> loop_data_file = ../loop-data.txt
>> contact_email = ""
>> expiration_time = 4
>> page_update_pwd = foobar
>> googleAnalyticsId = ""
>> analytics_host = ""
>> show_purple = False
>> [[[Labels]]]
>> Generic
>> air_quality_index = Air Quality Index
>> contact = Kontakt
>> legend = Legende
>> rain_today = Regen heute
>> ten_min_max_gust = 10min Boee
>> time_of_day = Uhrzeit
>> high_gust_today = Booe max.
>> [[[Units]]]
>> StringFormats
>> mile_per_hour = %.1f
>> degree_C = %.1f
>> km_per_hour = %.1f
>> degree_F = %.1f
>> 
>> This section I added at the end of weewx.conf by hand:
>> 
>> # 
>> 
>> # Options for extension 'weewx-loopdata'
>> 
>> [LoopData]
>> [[FileSpec]]
>> loop_data_dir = /var/www/html/weewx
>> filename = loop-data.txt
>> [[Formatting]]
>> target_report = WeatherBoardReport
>> [[RsyncSpec]]
>> enable = false
>> remote_server = foo.bar.com
>> remote_user = root
>> remote_dir = /var/www/html
>> compress = False
>> log_success = False
>> ssh_options = -o ConnectTimeout=1
>> timeout = 1
>> skip_if_older_than = 3
>> [[Include]]
>> fields = current.dateTime.raw, current.windDir.ordinal_compass, 
>> day.rain.sum, current.dewpoint, current.outTemp, current.rainRate, 
>> current.windSpeed, day.windGust.max, 10m.windGust.max, current.windSpeed
>> 
>> But there is even a skin.conf at /etc/weew/skinWeatherboard/ ...
>> 
>> # Copyright (C)2020 by John A Kline (j...@johnkline.com)
>> # Distributed under the terms of the GNU Public License (GPLv3)
>> # See

Re: [weewx-user] Questions about weewx-loopdata 1.3.x



Hi Christian,

wee_extension should not have been using python2 if you did a python3 install 
of weewx; but let’s put that aside.

Of course, you should care that WeatherBoard is not updating on every loop 
cycle, that’s the whole point of it.

I might be better if you deleted all you have done manually and do a proper 
install, but let’s try to work with what you have.

Are you sure loop-data.txt is being generated?

If in weewx.conf, under [Engine][[Services]], on the report_services line, do 
you see user.loopdata.LoopData?

Would you send me a copy of /var/www/html/weewx/loop-data.txt?

Would you send me a directory listing of /var/www/html/weewx/weatherboard?

Lastly, from your browser, would you bring up the JavaScript console and tell 
me the error(s) you see?

>> On Jul 15, 2020, at 10:53 AM, 'Christian Peters' via weewx-user 
>>  wrote:
> 
> John,
> 
> I struggeld installing the extension. I got:
> Traceback (most recent call last):
>   File "/usr/share/weewx/wee_extension", line 13, in 
> import weecfg.extension
>   File "/usr/share/weewx/weecfg/__init__.py", line 22, in 
> import configobj
> ImportError: No module named configobj
> 
> ..but the module was installed! 
> I then figured out that wee_extension uses python2 but not python3 so the 
> module was missing in python 2!  ;-)
> I treid to gove Python3 a try with weewx this time as I reinstalled it!
> I changed in we_extension the first line to 
> 
> #!/usr/bin/env python3
> 
> and it works. 
> 
> But first I installed the loop-data exxtension by hand...but I think all is 
> in the right place as the loop-data.txt is build.
> 
> The WeatherBoardReport section in weewx.conf:
> 
> [[WeatherBoardReport]]
> HTML_ROOT = /var/www/html/weewx/weatherboard
> enable = true
> skin = WeatherBoard
> [[[Extras]]]
> meta_title = Live-Wetter Langenseifen, Hessen  Weather at a 
> Glance WeatherBoard
> title = Live-Wetter Langenseifen Hessen WeatherBoard
> subtitle = Fortlaufend aktualisiert.
> logo = ""
> loop_data_file = ../loop-data.txt
> contact_email = ""
> expiration_time = 4
> page_update_pwd = foobar
> googleAnalyticsId = ""
> analytics_host = ""
> show_purple = False
> [[[Labels]]]
> Generic
> air_quality_index = Air Quality Index
> contact = Kontakt
> legend = Legende
> rain_today = Regen heute
> ten_min_max_gust = 10min Boee
> time_of_day = Uhrzeit
> high_gust_today = Booe max.
> [[[Units]]]
> StringFormats
> mile_per_hour = %.1f
> degree_C = %.1f
> km_per_hour = %.1f
> degree_F = %.1f
> 
> This section I added at the end of weewx.conf by hand:
> 
> # 
> 
> # Options for extension 'weewx-loopdata'
> 
> [LoopData]
> [[FileSpec]]
> loop_data_dir = /var/www/html/weewx
> filename = loop-data.txt
> [[Formatting]]
> target_report = WeatherBoardReport
> [[RsyncSpec]]
> enable = false
> remote_server = foo.bar.com
> remote_user = root
> remote_dir = /var/www/html
> compress = False
> log_success = False
> ssh_options = -o ConnectTimeout=1
> timeout = 1
> skip_if_older_than = 3
> [[Include]]
> fields = current.dateTime.raw, current.windDir.ordinal_compass, 
> day.rain.sum, current.dewpoint, current.outTemp, current.rainRate, 
> current.windSpeed, day.windGust.max, 10m.windGust.max, current.windSpeed
> 
> But there is even a skin.conf at /etc/weew/skinWeatherboard/ ...
> 
> # Copyright (C)2020 by John A Kline (j...@johnkline.com)
> # Distributed under the terms of the GNU Public License (GPLv3)
> # See LICENSE for your rights.
> 
> [Extras]
> # Fill path of loop data file.  If not a full path,
> # it will be interpreted as relative to this skin's HTML_ROOT.
> loop_data_file = '../loop-data.txt'
> 
> # Refresh rate is the rate at which the report should refresh with
> # the latest readings.  A good choice is the rate at which your
> # weather stations driver is feeing loop data.  Expressed in units
> # of seconds.  Default: 2 seconds.
> refresh_rate = 2
> 
> # Fill in a sutiable title/subtitle for the report.
> title = 'my-weather-website.com WeatherBoard'
> subtitle = 'Updated continuously.'
> 
> # If you have a log, specify it here.
> logo = ''
> 
> # Fill in contact email to display on the report.
> contact_email = 'weather...@my-weather-website.com'
> 
> # Choose your own password.  without ?page_update_pwd='xxx'
> # at the end of the URL, auto updating will timeout.
> # Note:

Re: [weewx-user] Questions about weewx-loopdata 1.3.x

2020-07-15 Thread 'Christian Peters' via weewx-user

John,

I struggeld installing the extension. I got:
Traceback (most recent call last):
  File "/usr/share/weewx/wee_extension", line 13, in 
import weecfg.extension
  File "/usr/share/weewx/weecfg/__init__.py", line 22, in 
import configobj
ImportError: No module named configobj

..but the module was installed! 
I then figured out that wee_extension uses python2 but not python3 so the 
module was missing in python 2!  ;-)
I treid to gove Python3 a try with weewx this time as I reinstalled it!
I changed in we_extension the first line to 

#!/usr/bin/env python3

and it works. 

But first I installed the loop-data exxtension by hand...but I think all is 
in the right place as the loop-data.txt is build.

The WeatherBoardReport section in weewx.conf:

[[WeatherBoardReport]]
HTML_ROOT = /var/www/html/weewx/weatherboard
enable = true
skin = WeatherBoard
[[[Extras]]]
meta_title = Live-Wetter Langenseifen, Hessen  Weather at a 
Glance WeatherBoard
title = Live-Wetter Langenseifen Hessen WeatherBoard
subtitle = Fortlaufend aktualisiert.
logo = ""
loop_data_file = ../loop-data.txt
contact_email = ""
expiration_time = 4
page_update_pwd = foobar
googleAnalyticsId = ""
analytics_host = ""
show_purple = False
[[[Labels]]]
Generic
air_quality_index = Air Quality Index
contact = Kontakt
legend = Legende
rain_today = Regen heute
ten_min_max_gust = 10min Boee
time_of_day = Uhrzeit
high_gust_today = Booe max.
[[[Units]]]
StringFormats
mile_per_hour = %.1f
degree_C = %.1f
km_per_hour = %.1f
degree_F = %.1f

This section I added at the end of weewx.conf by hand:

# 

# Options for extension 'weewx-loopdata'

[LoopData]
[[FileSpec]]
loop_data_dir = /var/www/html/weewx
filename = loop-data.txt
[[Formatting]]
target_report = WeatherBoardReport
[[RsyncSpec]]
enable = false
remote_server = foo.bar.com
remote_user = root
remote_dir = /var/www/html
compress = False
log_success = False
ssh_options = -o ConnectTimeout=1
timeout = 1
skip_if_older_than = 3
[[Include]]
fields = current.dateTime.raw, current.windDir.ordinal_compass, day.
rain.sum, current.dewpoint, current.outTemp, current.rainRate, current.
windSpeed, day.windGust.max, 10m.windGust.max, current.windSpeed

But there is even a skin.conf at /etc/weew/skinWeatherboard/ ...

# Copyright (C)2020 by John A Kline (j...@johnkline.com)
# Distributed under the terms of the GNU Public License (GPLv3)
# See LICENSE for your rights.

[Extras]
# Fill path of loop data file.  If not a full path,
# it will be interpreted as relative to this skin's HTML_ROOT.
loop_data_file = '../loop-data.txt'

# Refresh rate is the rate at which the report should refresh with
# the latest readings.  A good choice is the rate at which your
# weather stations driver is feeing loop data.  Expressed in units
# of seconds.  Default: 2 seconds.
refresh_rate = 2

# Fill in a sutiable title/subtitle for the report.
title = 'my-weather-website.com WeatherBoard'
subtitle = 'Updated continuously.'

# If you have a log, specify it here.
logo = ''

# Fill in contact email to display on the report.
contact_email = 'weather...@my-weather-website.com'

# Choose your own password.  without ?page_update_pwd='xxx'
# at the end of the URL, auto updating will timeout.
# Note: This password will be viaible to users looking
# at page source in their browser.
page_update_pwd = 'foobar'

# Page expiration time is the number of hours the report will request
# loop data and update.  After which, a mouse clice will be needed
# to start refreshing again.  Default 4 hours.
expiration_time = 4

# If you have a google analytics id, uncomment the following line
# and fill in the ID.
# googleAnalyticsId =
# If you only want to use the ID on a certain host, uncomment the
# following line and fill in the hostname.
# analytics_host = www.example.com

# If a PurpleAir sensor is set up and both weewx-purple and
# purple-proxy are installed, or just weewx-purple is installed;
# change the 'False' below to 'True'.
# The weewx-purple extension can be found here:
#https://github.com/chaunceygardiner/weewx-purple
# The purple-proxy server can be found here:
#https://github.com/chaunceygardiner/purple-proxy
# It is preferable to install both weewx-purple and purple proxy
# as the proxy

Re: [weewx-user] Questions about weewx-loopdata 1.3.x

2020-07-15 Thread geni08...@gmail.com

That's correct, I have a problem understanding the JavaScript entries and 
the WeatherBord template.
I started again with the original files.
As soon as I make the smallest change, the wind update no longer works. I 
work with Notepad++ and then copy the file into the skin folder via the 
console. Could this have an impact? Are there rules about the encoding of 
the file? UTF-8 or UTF-8-BOM or something else?

jo...@johnkline.com schrieb am Mittwoch, 15. Juli 2020 um 16:21:06 UTC+2:

> 
> 
> You need to be care as to how you state things.  I can clearly see that 
> you have added current.inHumidity to LoopData and you show that it is 
> appearing correctly in the loop-data.txt.
>
> inHumidity is not part of the WeatherBoard skin.  You have added it.  You 
> have a JavaScript error that says inHumidity not defined.  Perhaps you 
> should restate your question.  Are you having problems with the JavaScript 
> changes you have made to WeatherBoard?
>
> On Jul 15, 2020, at 5:54 AM, geni08...@gmail.com  
> wrote:
>
> 
>
>Also, why are you using 2.0.b3?  Please use the latest on master as 
> I’ve merged it in.  It is 2.0.b6 (which happens to be what you were 
> claiming to use in the last email). 
> this was watherboard version
>
> 
>
>
> my loop-data.txt:
> {"current.dateTime.raw": 1594817282, "current.windchill": "17.6\u00b0C", 
> "current.windSpeed": "0.0 km/h", "current.windSpeed.raw": 0.0, 
> "day.windGust.max": "12.9 km/h", "10m.windGust.max": "8.0 km/h", 
> "10m.windGust.max.formatted": "8.0", "current.barometer": "1013.5 hPa", 
> "trend.barometer.formatted": "0.3", "current.rain": "0.0 mm", 
> "current.rainRate": "0 mm/h", "day.rain.sum": "0.8 mm", "current.appTemp": 
> "18.9\u00b0C", "current.outTemp": "17.6\u00b0C", "current.inTemp": 
> "24.2\u00b0C", "current.inHumidity": "50%", "current.outHumidity": "81%"}
>
> 
>
>
> I still have problems with version 2, the update no longer works as in 
> version 1.xx. 
>
> jo...@johnkline.com schrieb am Dienstag, 14. Juli 2020 um 18:35:21 UTC+2:
>
> Of course inHumidity is not defined. You need to read the doc and 
>> specifically the part about upgrading.
>>
>> inHumidity is now current.inHumidity.formatted
>> It’s in the doc.
>>
>> Also, why are you using 2.0.b3?  Please use the latest on master as I’ve 
>> merged it in.  It is 2.0.b6 (which happens to be what you were claiming to 
>> use in the last email).
>>
>> Again, please read the upgrade section of LoopData.  The names changed. 
>>  There is ample warning about that at the top:
>>
>> LoopData 2.x is a breaking change from 1.x. See "How to Upgrade from 
>> LoopData 1.x." below.
>>
>> inHumidity would fall under this conversion rule:
>>
>>-  -> current..formatted
>>
>>
>> On Jul 14, 2020, at 8:29 AM, Geni 0815  wrote:
>>
>> 
>>
>> @John: WeaterBoard 2.0b3 causes problems. everything worked until the 
>> time with the old version.
>> With version 2 I get the error: Uncaught ReferenceError: inHumidity is 
>> not defined, and refreshing doesn't seem to work properly.
>> The syntax also seems different?
>>
>> I'll test that with current.dateTime.raw in a moment
>>
>> Am Dienstag, 14. Juli 2020 15:52:13 UTC+2 schrieb John Kline:
>>
>> It looks like you are missing the following in the fields line:
>>>
>>> current.dateTime.raw
>>>
>>> That is, to upgrade, dateTime needs to be changed to 
>>> current.dateTime.raw
>>>
>>> I’ll update the How to Upgrade section to reflect that.
>>>
>>> On Jul 14, 2020, at 6:01 AM, Geni 0815  wrote:
>>>
>>> 
>>>
>>> @John: I installed version 2.0.b6, almost everything worked right away, 
>>> congratulations.
>>> What is not yet running is the label: Live and the clock at the bottom 
>>> right.
>>>
>>>
>>> Am Freitag, 10. Juli 2020 20:09:30 UTC+2 schrieb John Kline:
>>>
>>> I had a look.  You never actually write FMT_windDir in the JavaScript. 
  Just add:
 + ‘ (‘ + result[‘FMT_windDir’] + ‘)’
 on the appropriate line in realtime_updater.inc.

 As for barometerRate.  I do see it.  I just spills over to the next 
 line.  It looks like I am not properly formatting barometerRate.  I will 
 fix that as part of the 2.0 release which I am working on and hope to have 
 out this weekend.

 On Jul 10, 2020, at 9:03 AM, geni08...@gmail.com  
 wrote:

  
 Hi John, I'm on the mountain, there was more. Can you please keep an 
 eye on the two files?


 jo...@johnkline.com schrieb am Freitag, 10. Juli 2020 um 16:05:18 
 UTC+2:

 You need to add the fields:
> barometerRate
> FMT_windDir
> to the fields line in the LoopData section of weewx.conf.
>
> After you do that and restart WeeWX, verify that you see these 
> readings in loop-data.txt.
>
> Finally, you need to set these values in the JavaScript.
>
> If you have already done all of the above, perhaps you have a 
> JavaScript error.  Have a look in the JavaScript console in your browser 
> (note: it may

Re: [weewx-user] Questions about weewx-loopdata 1.3.x



You need to be care as to how you state things.  I can clearly see that you 
have added current.inHumidity to LoopData and you show that it is appearing 
correctly in the loop-data.txt.

inHumidity is not part of the WeatherBoard skin.  You have added it.  You have 
a JavaScript error that says inHumidity not defined.  Perhaps you should 
restate your question.  Are you having problems with the JavaScript changes you 
have made to WeatherBoard?

>> On Jul 15, 2020, at 5:54 AM, geni08...@gmail.com  
>> wrote:
> 
>Also, why are you using 2.0.b3?  Please use the latest on master as I’ve 
> merged it in.  It is 2.0.b6 (which happens to be what you were claiming to 
> use in the last email). 
> this was watherboard version
> 
> 
> 
> my loop-data.txt:
> {"current.dateTime.raw": 1594817282, "current.windchill": "17.6\u00b0C", 
> "current.windSpeed": "0.0 km/h", "current.windSpeed.raw": 0.0, 
> "day.windGust.max": "12.9 km/h", "10m.windGust.max": "8.0 km/h", 
> "10m.windGust.max.formatted": "8.0", "current.barometer": "1013.5 hPa", 
> "trend.barometer.formatted": "0.3", "current.rain": "0.0 mm", 
> "current.rainRate": "0 mm/h", "day.rain.sum": "0.8 mm", "current.appTemp": 
> "18.9\u00b0C", "current.outTemp": "17.6\u00b0C", "current.inTemp": 
> "24.2\u00b0C", "current.inHumidity": "50%", "current.outHumidity": "81%"}
> 
> 
> 
> 
> I still have problems with version 2, the update no longer works as in 
> version 1.xx.
> 
> jo...@johnkline.com schrieb am Dienstag, 14. Juli 2020 um 18:35:21 UTC+2:
>> Of course inHumidity is not defined. You need to read the doc and 
>> specifically the part about upgrading.
>> 
>> inHumidity is now current.inHumidity.formatted
>> It’s in the doc.
>> 
>> Also, why are you using 2.0.b3?  Please use the latest on master as I’ve 
>> merged it in.  It is 2.0.b6 (which happens to be what you were claiming to 
>> use in the last email).
>> 
>> Again, please read the upgrade section of LoopData.  The names changed.  
>> There is ample warning about that at the top:
>> 
>> LoopData 2.x is a breaking change from 1.x. See "How to Upgrade from 
>> LoopData 1.x." below.
>> 
>> inHumidity would fall under this conversion rule:
>>  -> current..formatted
>> 
 On Jul 14, 2020, at 8:29 AM, Geni 0815  wrote:
>>> 
>> 
>>> @John: WeaterBoard 2.0b3 causes problems. everything worked until the time 
>>> with the old version.
>>> With version 2 I get the error: Uncaught ReferenceError: inHumidity is not 
>>> defined, and refreshing doesn't seem to work properly.
>>> The syntax also seems different?
>>> 
>>> I'll test that with current.dateTime.raw in a moment
>>> 
>>> Am Dienstag, 14. Juli 2020 15:52:13 UTC+2 schrieb John Kline:
 
 It looks like you are missing the following in the fields line:
 
 current.dateTime.raw
 
 That is, to upgrade, dateTime needs to be changed to current.dateTime.raw
 
 I’ll update the How to Upgrade section to reflect that.
 
>> On Jul 14, 2020, at 6:01 AM, Geni 0815  wrote:
> 
> @John: I installed version 2.0.b6, almost everything worked right away, 
> congratulations.
> What is not yet running is the label: Live and the clock at the bottom 
> right.
> 
> 
> Am Freitag, 10. Juli 2020 20:09:30 UTC+2 schrieb John Kline:
>> 
>> I had a look.  You never actually write FMT_windDir in the JavaScript.  
>> Just add:
>> + ‘ (‘ + result[‘FMT_windDir’] + ‘)’
>> on the appropriate line in realtime_updater.inc.
>> 
>> As for barometerRate.  I do see it.  I just spills over to the next 
>> line.  It looks like I am not properly formatting barometerRate.  I will 
>> fix that as part of the 2.0 release which I am working on and hope to 
>> have out this weekend.
>> 
 On Jul 10, 2020, at 9:03 AM, geni08...@gmail.com  
 wrote:
>>> 
>>> Hi John, I'm on the mountain, there was more. Can you please keep an 
>>> eye on the two files?
>>> 
>>> 
>>> jo...@johnkline.com schrieb am Freitag, 10. Juli 2020 um 16:05:18 UTC+2:
 You need to add the fields:
 barometerRate
 FMT_windDir
 to the fields line in the LoopData section of weewx.conf.
 
 After you do that and restart WeeWX, verify that you see these 
 readings in loop-data.txt.
 
 Finally, you need to set these values in the JavaScript.
 
 If you have already done all of the above, perhaps you have a 
 JavaScript error.  Have a look in the JavaScript console in your 
 browser (note: it may be called something else, search for how to see 
 JavaScript errors).
 
 BTW, this weekend, I should have a version of LoopData out that uses 
 the same naming scheme as cheetah.  As such, you will then specify 
 $current.windSpeed, $current.windDir.ordinal_compass and 
 $current.windDir (for example) in the fields line in weewx.conf and

Re: [weewx-user] Questions about weewx-loopdata 1.3.x

Hi Christian,

Please let me know what was tricky about installing loop-data.

Since you are getting loop-data, I suspect that the LoopData extension and the 
WeatherBoard extension don’t agree about where to find the loop-data.txt file.

Would you send both the LoopData section and the WeatherBoard section of 
weewx.conf?

Cheers,
John

> On Jul 15, 2020, at 5:16 AM, 'Christian Peters' via weewx-user 
>  wrote:
> 
> 
> John,
> 
> I just installed the loop-data extension and the weatherboard skin to give it 
> a try. :-) 
> A really nice extension. 
> 
> It was a bit tricky to install it but I hope loop-data is running. I get this 
> /var/www/html/weewx/loop-data.txt file with this text:
> 
> {"current.dateTime.raw": 1594814866, "current.windDir.ordinal_compass": "N", 
> "day.rain.sum": "2,6 mm", "current.dewpoint": "11,3\u00b0C", 
> "current.outTemp": "20,3\u00b0C", "current.rainRate": "0,0 mm/h", 
> "current.windSpeed": "6,4 km/h", "day.windGust.max": "19,3 km/h", 
> "10m.windGust.max": "11,3 km/h"}
> 
> It updates every 2 sec, winddir for example changesso it seems to work I 
> think. 
> 
> What not works it the wartherboard skin. 
> 
> https://livewetter.hcpeters.de
> 
> It doesn't update (only if I do a manual refresh on the borwser and not every 
> time it really refreshes to the most recent values). 
> and there is something not working as the time field is missing, even 
> 10m.windGust.max and day.windGust.max ... see screenshot.
> 
> Am I doing something wrong? I got the most recent .zip files from your site 
> (today). But I'm not sure where to tweak the weatherboard skin ( in 
> weewx.conf or in weatherboard/skin/skin.conf ) ?
> 
> Thanks in advance for any idea or hint!
> 
> Regards,
> 
> Christian 
> 
> 
> 
> 
> 
> -- 
> 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/adaaa9c1-dbdd-4534-bda8-784875ce2103o%40googlegroups.com.
> 

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/ADC0A5E8-5D3C-4BB6-969C-175D62ADCAA6%40johnkline.com.

Re: [weewx-user] Questions about weewx-loopdata 1.3.x

2020-07-15 Thread 'Christian Peters' via weewx-user

John,

I just installed the loop-data extension and the weatherboard skin to give
it a try. :-)
A really nice extension.

It was a bit tricky to install it but I hope loop-data is running. I get
this
/var/www/html/weewx/loop-data.txt file with this text:

{"current.dateTime.raw": 1594814866, "current.windDir.ordinal_compass":
"N", "day.rain.sum": "2,6 mm", "current.dewpoint": "11,3\u00b0C",
"current.outTemp": "20,3\u00b0C", "current.rainRate": "0,0 mm/h",
"current.windSpeed": "6,4 km/h", "day.windGust.max": "19,3 km/h",
"10m.windGust.max": "11,3 km/h"}

It updates every 2 sec, winddir for example changesso it seems to work
I think.

What not works it the wartherboard skin.

https://livewetter.hcpeters.de

It doesn't update (only if I do a manual refresh on the borwser and not
every time it really refreshes to the most recent values).
and there is something not working as the time field is missing, even
10m.windGust.max and day.windGust.max ... see screenshot.

Am I doing something wrong? I got the most recent .zip files from your site
(today). But I'm not sure where to tweak the weatherboard skin ( in
weewx.conf or in weatherboard/skin/skin.conf ) ?

Thanks in advance for any idea or hint!

Regards,

Christian

--
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/adaaa9c1-dbdd-4534-bda8-784875ce2103o%40googlegroups.com.

Re: [weewx-user] Questions about weewx-loopdata 1.3.x

2020-07-14 Thread John Kline

Of course inHumidity is not defined. You need to read the doc and specifically 
the part about upgrading.

inHumidity is now current.inHumidity.formatted
It’s in the doc.

Also, why are you using 2.0.b3?  Please use the latest on master as I’ve merged 
it in.  It is 2.0.b6 (which happens to be what you were claiming to use in the 
last email).

Again, please read the upgrade section of LoopData.  The names changed.  There 
is ample warning about that at the top:

LoopData 2.x is a breaking change from 1.x. See "How to Upgrade from LoopData 
1.x." below.

inHumidity would fall under this conversion rule:
 -> current..formatted

> On Jul 14, 2020, at 8:29 AM, Geni 0815  wrote:
> 
> 
> @John: WeaterBoard 2.0b3 causes problems. everything worked until the time 
> with the old version.
> With version 2 I get the error: Uncaught ReferenceError: inHumidity is not 
> defined, and refreshing doesn't seem to work properly.
> The syntax also seems different?
> 
> I'll test that with current.dateTime.raw in a moment
> 
> Am Dienstag, 14. Juli 2020 15:52:13 UTC+2 schrieb John Kline:
>> 
>> It looks like you are missing the following in the fields line:
>> 
>> current.dateTime.raw
>> 
>> That is, to upgrade, dateTime needs to be changed to current.dateTime.raw
>> 
>> I’ll update the How to Upgrade section to reflect that.
>> 
>>> On Jul 14, 2020, at 6:01 AM, Geni 0815  wrote:
>>> 
>>> 
>>> @John: I installed version 2.0.b6, almost everything worked right away, 
>>> congratulations.
>>> What is not yet running is the label: Live and the clock at the bottom 
>>> right.
>>> 
>>> 
>>> Am Freitag, 10. Juli 2020 20:09:30 UTC+2 schrieb John Kline:
 
 I had a look.  You never actually write FMT_windDir in the JavaScript.  
 Just add:
 + ‘ (‘ + result[‘FMT_windDir’] + ‘)’
 on the appropriate line in realtime_updater.inc.
 
 As for barometerRate.  I do see it.  I just spills over to the next line.  
 It looks like I am not properly formatting barometerRate.  I will fix that 
 as part of the 2.0 release which I am working on and hope to have out this 
 weekend.
 
> On Jul 10, 2020, at 9:03 AM, geni08...@gmail.com  
> wrote:
> 
> 
> Hi John, I'm on the mountain, there was more. Can you please keep an eye 
> on the two files?
> 
> 
> jo...@johnkline.com schrieb am Freitag, 10. Juli 2020 um 16:05:18 UTC+2:
>> You need to add the fields:
>> barometerRate
>> FMT_windDir
>> to the fields line in the LoopData section of weewx.conf.
>> 
>> After you do that and restart WeeWX, verify that you see these readings 
>> in loop-data.txt.
>> 
>> Finally, you need to set these values in the JavaScript.
>> 
>> If you have already done all of the above, perhaps you have a JavaScript 
>> error.  Have a look in the JavaScript console in your browser (note: it 
>> may be called something else, search for how to see JavaScript errors).
>> 
>> BTW, this weekend, I should have a version of LoopData out that uses the 
>> same naming scheme as cheetah.  As such, you will then specify 
>> $current.windSpeed, $current.windDir.ordinal_compass and 
>> $current.windDir (for example) in the fields line in weewx.conf and 
>> those keys will show up in loop-data.txt.  There was no good reason to 
>> invent a new language for this. 
>> 
>>> On Jul 10, 2020, at 1:54 AM, geni08...@gmail.com  
>>> wrote:
>>> 
>>> 
>> 
>>> what do I have to change so that the two values (in the yellow circle) 
>>> are always displayed? Now they only flash briefly during a manual 
>>> refresh.
>> 
>>> 
>>> 
>>> in index.html.templ:
>>>  >> style="font-family:monospace;font-size:85px;text-align:center;">$current.windSpeed
>>>  $current.windDir.ordinal_compass ($current.windDir)
>>> $current.barometer 
>>> ($trend.barometer.formatted)->> id="FMT_outHumidity">$current.outHumidity
>>> 
>>> jo...@johnkline.com schrieb am Donnerstag, 9. Juli 2020 um 15:40:48 
>>> UTC+2:
 
 
> On Jul 9, 2020, at 1:52 AM, geni08...@gmail.com  
> wrote:
> 
> Question for my understanding:
 
> 
> If or why is the id = string supplemented with $current, $day or not 
> at all?
 
> 
 
 In the examples, no IDs is supplemented with current, day or none at 
 all.  Some values say $current, which means the current observation.  
 Some say day, which would be for the day and have an aggregator 
 ($day.rain.sum).  In any event, all of these values are overwritten 
 every couple of seconds by the javascript.  As such, they could be 
 removed.
 
 As for the ids.  They could be anything you wish.  They just are used 
 by the JavaScript to look up the element.  As a naming scheme for ids, 
 I

Re: [weewx-user] Questions about weewx-loopdata 1.3.x

2020-07-14 Thread Geni 0815

@John: WeaterBoard 2.0b3 causes problems. everything worked until the time 
with the old version.
With version 2 I get the error: Uncaught ReferenceError: inHumidity is not 
defined, and refreshing doesn't seem to work properly.
The syntax also seems different?

I'll test that with current.dateTime.raw in a moment

Am Dienstag, 14. Juli 2020 15:52:13 UTC+2 schrieb John Kline:
>
> It looks like you are missing the following in the fields line:
>
> current.dateTime.raw
>
> That is, to upgrade, dateTime needs to be changed to current.dateTime.raw
>
> I’ll update the How to Upgrade section to reflect that.
>
> On Jul 14, 2020, at 6:01 AM, Geni 0815 > 
> wrote:
>
> 
> @John: I installed version 2.0.b6, almost everything worked right away, 
> congratulations.
> What is not yet running is the label: Live and the clock at the bottom 
> right.
>
>
> Am Freitag, 10. Juli 2020 20:09:30 UTC+2 schrieb John Kline:
>>
>> I had a look.  You never actually write FMT_windDir in the JavaScript. 
>>  Just add:
>> + ‘ (‘ + result[‘FMT_windDir’] + ‘)’
>> on the appropriate line in realtime_updater.inc.
>>
>> As for barometerRate.  I do see it.  I just spills over to the next line. 
>>  It looks like I am not properly formatting barometerRate.  I will fix that 
>> as part of the 2.0 release which I am working on and hope to have out this 
>> weekend.
>>
>> On Jul 10, 2020, at 9:03 AM, geni08...@gmail.com  
>> wrote:
>>
>>  
>> Hi John, I'm on the mountain, there was more. Can you please keep an eye 
>> on the two files?
>>
>>
>> jo...@johnkline.com schrieb am Freitag, 10. Juli 2020 um 16:05:18 UTC+2:
>>
>>> You need to add the fields:
>>> barometerRate
>>> FMT_windDir
>>> to the fields line in the LoopData section of weewx.conf.
>>>
>>> After you do that and restart WeeWX, verify that you see these readings 
>>> in loop-data.txt.
>>>
>>> Finally, you need to set these values in the JavaScript.
>>>
>>> If you have already done all of the above, perhaps you have a JavaScript 
>>> error.  Have a look in the JavaScript console in your browser (note: it may 
>>> be called something else, search for how to see JavaScript errors).
>>>
>>> BTW, this weekend, I should have a version of LoopData out that uses the 
>>> same naming scheme as cheetah.  As such, you will then specify 
>>> $current.windSpeed, $current.windDir.ordinal_compass and $current.windDir 
>>> (for example) in the fields line in weewx.conf and those keys will show up 
>>> in loop-data.txt.  There was no good reason to invent a new language for 
>>> this. 
>>>
>>> On Jul 10, 2020, at 1:54 AM, geni08...@gmail.com  
>>> wrote:
>>>
>>>  
>>>
>>> what do I have to change so that the two values (in the yellow circle) 
>>> are always displayed? Now they only flash briefly during a manual 
>>> refresh.
>>>
>>> 
>>>
>>> in index.html.templ:
>>>  >> style="font-family:monospace;font-size:85px;text-align:center;">$current.windSpeed
>>>  
>>> $current.windDir.ordinal_compass ($current.windDir)
>>> $current.barometer 
>>> ($trend.barometer.formatted)->> id="FMT_outHumidity">$current.outHumidity
>>>
>>> jo...@johnkline.com schrieb am Donnerstag, 9. Juli 2020 um 15:40:48 
>>> UTC+2:
>>>

 On Jul 9, 2020, at 1:52 AM, geni08...@gmail.com  
 wrote:

 Question for my understanding:

 If or why is the id = string supplemented with $current, $day or not at 
 all?

 In the examples, no IDs is supplemented with current, day or none at 
 all.  Some values say $current, which means the current observation.  Some 
 say day, which would be for the day and have an aggregator 
 ($day.rain.sum). 
  In any event, all of these values are overwritten every couple of seconds 
 by the javascript.  As such, they could be removed.

 As for the ids.  They could be anything you wish.  They just are used 
 by the JavaScript to look up the element.  As a naming scheme for ids, I 
 chose to to name them for the corresponding key in loop-data.txt.

 For example, FMT_HI_windGust.  The JavaScript will get lookup the 
 element with the id FMT_HI_windGust.  It will then lookup the value in 
 loop-data.txt for the key FMT_HI_windGust and set the contents of the HTML 
 tag (innerHTML property) to that value.

 If the id was foo on this element, the JavaScript would have to find 
 the foo element in the DOM.  Of course, it will still need to use the key 
 FMT_HI_windGust for looking up the loop-data value.

 As for the naming scheme in loop-data.txt:
 FMT_HI_windGust
 The FMT_ means include the label.
 The HI_ means give me today’s high.

 FMT_windGust would be for the current observation and would include the 
 label.

 windGust would be for the current observation. It would NOT include a 
 label, but it would still be formatted.  That is, if wind should have 1 
 decimal place, it be formatted as such (e.g., 4.0).

 The

Re: [weewx-user] Questions about weewx-loopdata 1.3.x

2020-07-14 Thread John Kline

It looks like you are missing the following in the fields line:

current.dateTime.raw

That is, to upgrade, dateTime needs to be changed to current.dateTime.raw

I’ll update the How to Upgrade section to reflect that.

> On Jul 14, 2020, at 6:01 AM, Geni 0815  wrote:
> 
> 
> @John: I installed version 2.0.b6, almost everything worked right away, 
> congratulations.
> What is not yet running is the label: Live and the clock at the bottom right.
> 
> 
> Am Freitag, 10. Juli 2020 20:09:30 UTC+2 schrieb John Kline:
>> 
>> I had a look.  You never actually write FMT_windDir in the JavaScript.  Just 
>> add:
>> + ‘ (‘ + result[‘FMT_windDir’] + ‘)’
>> on the appropriate line in realtime_updater.inc.
>> 
>> As for barometerRate.  I do see it.  I just spills over to the next line.  
>> It looks like I am not properly formatting barometerRate.  I will fix that 
>> as part of the 2.0 release which I am working on and hope to have out this 
>> weekend.
>> 
 On Jul 10, 2020, at 9:03 AM, geni08...@gmail.com  
 wrote:
 
>>> 
>>> Hi John, I'm on the mountain, there was more. Can you please keep an eye on 
>>> the two files?
>>> 
>>> 
>>> jo...@johnkline.com schrieb am Freitag, 10. Juli 2020 um 16:05:18 UTC+2:
 You need to add the fields:
 barometerRate
 FMT_windDir
 to the fields line in the LoopData section of weewx.conf.
 
 After you do that and restart WeeWX, verify that you see these readings in 
 loop-data.txt.
 
 Finally, you need to set these values in the JavaScript.
 
 If you have already done all of the above, perhaps you have a JavaScript 
 error.  Have a look in the JavaScript console in your browser (note: it 
 may be called something else, search for how to see JavaScript errors).
 
 BTW, this weekend, I should have a version of LoopData out that uses the 
 same naming scheme as cheetah.  As such, you will then specify 
 $current.windSpeed, $current.windDir.ordinal_compass and $current.windDir 
 (for example) in the fields line in weewx.conf and those keys will show up 
 in loop-data.txt.  There was no good reason to invent a new language for 
 this. 
 
>> On Jul 10, 2020, at 1:54 AM, geni08...@gmail.com  
>> wrote:
>> 
> 
 
> what do I have to change so that the two values (in the yellow circle) 
> are always displayed? Now they only flash briefly during a manual refresh.
 
> 
> 
> in index.html.templ:
>   style="font-family:monospace;font-size:85px;text-align:center;">$current.windSpeed
>  $current.windDir.ordinal_compass ($current.windDir)
> $current.barometer 
> ($trend.barometer.formatted)- id="FMT_outHumidity">$current.outHumidity
> 
> jo...@johnkline.com schrieb am Donnerstag, 9. Juli 2020 um 15:40:48 UTC+2:
>> 
>> 
 On Jul 9, 2020, at 1:52 AM, geni08...@gmail.com  
 wrote:
 
>>> Question for my understanding:
>> 
>>> 
>>> If or why is the id = string supplemented with $current, $day or not at 
>>> all?
>> 
>>> 
>> 
>> In the examples, no IDs is supplemented with current, day or none at 
>> all.  Some values say $current, which means the current observation.  
>> Some say day, which would be for the day and have an aggregator 
>> ($day.rain.sum).  In any event, all of these values are overwritten 
>> every couple of seconds by the javascript.  As such, they could be 
>> removed.
>> 
>> As for the ids.  They could be anything you wish.  They just are used by 
>> the JavaScript to look up the element.  As a naming scheme for ids, I 
>> chose to to name them for the corresponding key in loop-data.txt.
>> 
>> For example, FMT_HI_windGust.  The JavaScript will get lookup the 
>> element with the id FMT_HI_windGust.  It will then lookup the value in 
>> loop-data.txt for the key FMT_HI_windGust and set the contents of the 
>> HTML tag (innerHTML property) to that value.
>> 
>> If the id was foo on this element, the JavaScript would have to find the 
>> foo element in the DOM.  Of course, it will still need to use the key 
>> FMT_HI_windGust for looking up the loop-data value.
>> 
>> As for the naming scheme in loop-data.txt:
>> FMT_HI_windGust
>> The FMT_ means include the label.
>> The HI_ means give me today’s high.
>> 
>> FMT_windGust would be for the current observation and would include the 
>> label.
>> 
>> windGust would be for the current observation. It would NOT include a 
>> label, but it would still be formatted.  That is, if wind should have 1 
>> decimal place, it be formatted as such (e.g., 4.0).
>> 
>> The README has this info, but to summarize:
>> 
>> If the key is missing an aggregator (HI, LO, AVG, WAVG, SUM, RMS, 
>> VEC_AVG, VEC_DIR), it is the current observation.  If it has an 
>> aggregator prefix, it

Re: [weewx-user] Questions about weewx-loopdata 1.3.x

2020-07-14 Thread Geni 0815

@John: I installed version 2.0.b6, almost everything worked right away, 
congratulations.
What is not yet running is the label: Live and the clock at the bottom 
right.


Am Freitag, 10. Juli 2020 20:09:30 UTC+2 schrieb John Kline:
>
> I had a look.  You never actually write FMT_windDir in the JavaScript. 
>  Just add:
> + ‘ (‘ + result[‘FMT_windDir’] + ‘)’
> on the appropriate line in realtime_updater.inc.
>
> As for barometerRate.  I do see it.  I just spills over to the next line. 
>  It looks like I am not properly formatting barometerRate.  I will fix that 
> as part of the 2.0 release which I am working on and hope to have out this 
> weekend.
>
> On Jul 10, 2020, at 9:03 AM, geni08...@gmail.com  > wrote:
>
>  
> Hi John, I'm on the mountain, there was more. Can you please keep an eye 
> on the two files?
>
>
> jo...@johnkline.com schrieb am Freitag, 10. Juli 2020 um 16:05:18 UTC+2:
>
>> You need to add the fields:
>> barometerRate
>> FMT_windDir
>> to the fields line in the LoopData section of weewx.conf.
>>
>> After you do that and restart WeeWX, verify that you see these readings 
>> in loop-data.txt.
>>
>> Finally, you need to set these values in the JavaScript.
>>
>> If you have already done all of the above, perhaps you have a JavaScript 
>> error.  Have a look in the JavaScript console in your browser (note: it may 
>> be called something else, search for how to see JavaScript errors).
>>
>> BTW, this weekend, I should have a version of LoopData out that uses the 
>> same naming scheme as cheetah.  As such, you will then specify 
>> $current.windSpeed, $current.windDir.ordinal_compass and $current.windDir 
>> (for example) in the fields line in weewx.conf and those keys will show up 
>> in loop-data.txt.  There was no good reason to invent a new language for 
>> this. 
>>
>> On Jul 10, 2020, at 1:54 AM, geni08...@gmail.com  
>> wrote:
>>
>>  
>>
>> what do I have to change so that the two values (in the yellow circle) 
>> are always displayed? Now they only flash briefly during a manual 
>> refresh.
>>
>> 
>>
>> in index.html.templ:
>>  > style="font-family:monospace;font-size:85px;text-align:center;">$current.windSpeed
>>  
>> $current.windDir.ordinal_compass ($current.windDir)
>> $current.barometer 
>> ($trend.barometer.formatted)-> id="FMT_outHumidity">$current.outHumidity
>>
>> jo...@johnkline.com schrieb am Donnerstag, 9. Juli 2020 um 15:40:48 
>> UTC+2:
>>
>>>
>>>
>>> On Jul 9, 2020, at 1:52 AM, geni08...@gmail.com  
>>> wrote:
>>>
>>> Question for my understanding:
>>>
>>>
>>> If or why is the id = string supplemented with $current, $day or not at 
>>> all?
>>>
>>> 
>>>
>>>
>>> In the examples, no IDs is supplemented with current, day or none at 
>>> all.  Some values say $current, which means the current observation.  Some 
>>> say day, which would be for the day and have an aggregator ($day.rain.sum). 
>>>  In any event, all of these values are overwritten every couple of seconds 
>>> by the javascript.  As such, they could be removed.
>>>
>>> As for the ids.  They could be anything you wish.  They just are used by 
>>> the JavaScript to look up the element.  As a naming scheme for ids, I chose 
>>> to to name them for the corresponding key in loop-data.txt.
>>>
>>> For example, FMT_HI_windGust.  The JavaScript will get lookup the 
>>> element with the id FMT_HI_windGust.  It will then lookup the value in 
>>> loop-data.txt for the key FMT_HI_windGust and set the contents of the HTML 
>>> tag (innerHTML property) to that value.
>>>
>>> If the id was foo on this element, the JavaScript would have to find the 
>>> foo element in the DOM.  Of course, it will still need to use the key 
>>> FMT_HI_windGust for looking up the loop-data value.
>>>
>>> As for the naming scheme in loop-data.txt:
>>> FMT_HI_windGust
>>> The FMT_ means include the label.
>>> The HI_ means give me today’s high.
>>>
>>> FMT_windGust would be for the current observation and would include the 
>>> label.
>>>
>>> windGust would be for the current observation. It would NOT include a 
>>> label, but it would still be formatted.  That is, if wind should have 1 
>>> decimal place, it be formatted as such (e.g., 4.0).
>>>
>>> The README has this info, but to summarize:
>>>
>>> If the key is missing an aggregator (HI, LO, AVG, WAVG, SUM, RMS, 
>>> VEC_AVG, VEC_DIR), it is the current observation.  If it has an aggregator 
>>> prefix, it is for the day.  Exceptions are the items I made up 10mMaxGust 
>>> (which is 10 minutes) and barometerRate (which is a delta from 3 hours ago) 
>>> and windRose.
>>>
>>> FMT_ includes the label.
>>>
>>> UNITS_ is the unit for the observation.
>>>
>>> LABEL_ is the label for the observation.
>>>
>>> COMPASS_ for windDIr and windGustDir gives compass (text) direction.
>>>
>>> DESC_ for barometer rate gives a text description of the rate (and 
>>> probably needs to be internationalized).
>>>
>>> T_ is the time of the observation.  For example, T_HI_ would be the 
>>> time today that the

Re: [weewx-user] Questions about weewx-loopdata 1.3.x

2020-07-11 Thread John Kline

Of course, loop-data.txt is not created with all fields.  It would be huge.  
Rather, it is created with the fields you specify in the LoopData fields line 
in weewx.conf.

The equivalent of $current.barometer in LoopData is barometer.  You don’t 
specify that field.  Instead, you specify FMT_barometer.  As such, you 
loop-data.txt file has the following (change FMT_barometer to barometer to get 
what you want):

"FMT_barometer": "1020.3 hPa"

The equivalent of $trend.barometer.formatted in LoopData is barometerRate.  I 
see it in your loop-data.txt file:

barometerRate": "0.00879"

It is barometerRate that might have too many decimal digits.  I will double 
check that for the next revision.

BTW, as I mentioned, I’m changing the language to specify LoopData.  In the 
next revision, you would specify $current.barometer and 
$trend.barometer.formatted in the fields entry in weewx.conf.

>> On Jul 11, 2020, at 2:03 AM, geni08...@gmail.com  
>> wrote:
> The loop-data.txt file is not created with all fields!
> 
> The entry: $current.barometer ($trend.barometer.formatted)
> in the index.html.tmpl results in the correct formatting.
> 
> 
> jo...@johnkline.com schrieb am Freitag, 10. Juli 2020 um 20:09:30 UTC+2:
>> I had a look.  You never actually write FMT_windDir in the JavaScript.  Just 
>> add:
>> + ‘ (‘ + result[‘FMT_windDir’] + ‘)’
>> on the appropriate line in realtime_updater.inc.
>> 
>> As for barometerRate.  I do see it.  I just spills over to the next line.  
>> It looks like I am not properly formatting barometerRate.  I will fix that 
>> as part of the 2.0 release which I am working on and hope to have out this 
>> weekend.
>> 
>>> On Jul 10, 2020, at 9:03 AM, geni08...@gmail.com  
>>> wrote:
>>> 
>> 
>>> Hi John, I'm on the mountain, there was more. Can you please keep an eye on 
>>> the two files?
>>> 
>>> 
>>> jo...@johnkline.com schrieb am Freitag, 10. Juli 2020 um 16:05:18 UTC+2:
 You need to add the fields:
 barometerRate
 FMT_windDir
 to the fields line in the LoopData section of weewx.conf.

 After you do that and restart WeeWX, verify that you see these readings in 
 loop-data.txt.

 Finally, you need to set these values in the JavaScript.

 If you have already done all of the above, perhaps you have a JavaScript 
 error.  Have a look in the JavaScript console in your browser (note: it 
 may be called something else, search for how to see JavaScript errors).

 BTW, this weekend, I should have a version of LoopData out that uses the 
 same naming scheme as cheetah.  As such, you will then specify 
 $current.windSpeed, $current.windDir.ordinal_compass and $current.windDir 
 (for example) in the fields line in weewx.conf and those keys will show up 
 in loop-data.txt.  There was no good reason to invent a new language for 
 this. 

>> On Jul 10, 2020, at 1:54 AM, geni08...@gmail.com  
>> wrote:
> 

> what do I have to change so that the two values (in the yellow circle) 
> are always displayed? Now they only flash briefly during a manual refresh.

> 
> 
> in index.html.templ:
>   style="font-family:monospace;font-size:85px;text-align:center;">$current.windSpeed
>  $current.windDir.ordinal_compass ($current.windDir)
> $current.barometer 
> ($trend.barometer.formatted)- id="FMT_outHumidity">$current.outHumidity
> 
> jo...@johnkline.com schrieb am Donnerstag, 9. Juli 2020 um 15:40:48 UTC+2:
>> 
>> 
 On Jul 9, 2020, at 1:52 AM, geni08...@gmail.com  
 wrote:
>>> Question for my understanding:
>> 
>>> 
>>> If or why is the id = string supplemented with $current, $day or not at 
>>> all?
>> 
>>> 
>> 
>> In the examples, no IDs is supplemented with current, day or none at 
>> all.  Some values say $current, which means the current observation.  
>> Some say day, which would be for the day and have an aggregator 
>> ($day.rain.sum).  In any event, all of these values are overwritten 
>> every couple of seconds by the javascript.  As such, they could be 
>> removed.
>> 
>> As for the ids.  They could be anything you wish.  They just are used by 
>> the JavaScript to look up the element.  As a naming scheme for ids, I 
>> chose to to name them for the corresponding key in loop-data.txt.
>> 
>> For example, FMT_HI_windGust.  The JavaScript will get lookup the 
>> element with the id FMT_HI_windGust.  It will then lookup the value in 
>> loop-data.txt for the key FMT_HI_windGust and set the contents of the 
>> HTML tag (innerHTML property) to that value.
>> 
>> If the id was foo on this element, the JavaScript would have to find the 
>> foo element in the DOM.  Of course, it will still need to use the key 
>> FMT_HI_windGust for looking up the loop-data value.
>> 
>> As for the naming scheme in

Re: [weewx-user] Questions about weewx-loopdata 1.3.x

2020-07-11 Thread geni08...@gmail.com

The loop-data.txt file is not created with all fields!

The entry: $current.barometer ($trend.barometer.formatted)
in the index.html.tmpl results in the correct formatting.


jo...@johnkline.com schrieb am Freitag, 10. Juli 2020 um 20:09:30 UTC+2:

> I had a look.  You never actually write FMT_windDir in the JavaScript. 
>  Just add:
> + ‘ (‘ + result[‘FMT_windDir’] + ‘)’
> on the appropriate line in realtime_updater.inc.
>
> As for barometerRate.  I do see it.  I just spills over to the next line. 
>  It looks like I am not properly formatting barometerRate.  I will fix that 
> as part of the 2.0 release which I am working on and hope to have out this 
> weekend.
>
> On Jul 10, 2020, at 9:03 AM, geni08...@gmail.com  
> wrote:
>
>  
>
> Hi John, I'm on the mountain, there was more. Can you please keep an eye 
> on the two files?
>
>
> jo...@johnkline.com schrieb am Freitag, 10. Juli 2020 um 16:05:18 UTC+2:
>
>> You need to add the fields:
>> barometerRate
>> FMT_windDir
>> to the fields line in the LoopData section of weewx.conf.
>>
>> After you do that and restart WeeWX, verify that you see these readings 
>> in loop-data.txt.
>>
>> Finally, you need to set these values in the JavaScript.
>>
>> If you have already done all of the above, perhaps you have a JavaScript 
>> error.  Have a look in the JavaScript console in your browser (note: it may 
>> be called something else, search for how to see JavaScript errors).
>>
>> BTW, this weekend, I should have a version of LoopData out that uses the 
>> same naming scheme as cheetah.  As such, you will then specify 
>> $current.windSpeed, $current.windDir.ordinal_compass and $current.windDir 
>> (for example) in the fields line in weewx.conf and those keys will show up 
>> in loop-data.txt.  There was no good reason to invent a new language for 
>> this. 
>>
>> On Jul 10, 2020, at 1:54 AM, geni08...@gmail.com  
>> wrote:
>>
>>  
>>
>> what do I have to change so that the two values (in the yellow circle) 
>> are always displayed? Now they only flash briefly during a manual 
>> refresh.
>>
>> 
>>
>> in index.html.templ:
>>  > style="font-family:monospace;font-size:85px;text-align:center;">$current.windSpeed
>>  
>> $current.windDir.ordinal_compass ($current.windDir)
>> $current.barometer 
>> ($trend.barometer.formatted)-> id="FMT_outHumidity">$current.outHumidity
>>
>> jo...@johnkline.com schrieb am Donnerstag, 9. Juli 2020 um 15:40:48 
>> UTC+2:
>>
>>>
>>>
>>> On Jul 9, 2020, at 1:52 AM, geni08...@gmail.com  
>>> wrote:
>>>
>>> Question for my understanding:
>>>
>>>
>>> If or why is the id = string supplemented with $current, $day or not at 
>>> all?
>>>
>>> 
>>>
>>>
>>> In the examples, no IDs is supplemented with current, day or none at 
>>> all.  Some values say $current, which means the current observation.  Some 
>>> say day, which would be for the day and have an aggregator ($day.rain.sum). 
>>>  In any event, all of these values are overwritten every couple of seconds 
>>> by the javascript.  As such, they could be removed.
>>>
>>> As for the ids.  They could be anything you wish.  They just are used by 
>>> the JavaScript to look up the element.  As a naming scheme for ids, I chose 
>>> to to name them for the corresponding key in loop-data.txt.
>>>
>>> For example, FMT_HI_windGust.  The JavaScript will get lookup the 
>>> element with the id FMT_HI_windGust.  It will then lookup the value in 
>>> loop-data.txt for the key FMT_HI_windGust and set the contents of the HTML 
>>> tag (innerHTML property) to that value.
>>>
>>> If the id was foo on this element, the JavaScript would have to find the 
>>> foo element in the DOM.  Of course, it will still need to use the key 
>>> FMT_HI_windGust for looking up the loop-data value.
>>>
>>> As for the naming scheme in loop-data.txt:
>>> FMT_HI_windGust
>>> The FMT_ means include the label.
>>> The HI_ means give me today’s high.
>>>
>>> FMT_windGust would be for the current observation and would include the 
>>> label.
>>>
>>> windGust would be for the current observation. It would NOT include a 
>>> label, but it would still be formatted.  That is, if wind should have 1 
>>> decimal place, it be formatted as such (e.g., 4.0).
>>>
>>> The README has this info, but to summarize:
>>>
>>> If the key is missing an aggregator (HI, LO, AVG, WAVG, SUM, RMS, 
>>> VEC_AVG, VEC_DIR), it is the current observation.  If it has an aggregator 
>>> prefix, it is for the day.  Exceptions are the items I made up 10mMaxGust 
>>> (which is 10 minutes) and barometerRate (which is a delta from 3 hours ago) 
>>> and windRose.
>>>
>>> FMT_ includes the label.
>>>
>>> UNITS_ is the unit for the observation.
>>>
>>> LABEL_ is the label for the observation.
>>>
>>> COMPASS_ for windDIr and windGustDir gives compass (text) direction.
>>>
>>> DESC_ for barometer rate gives a text description of the rate (and 
>>> probably needs to be internationalized).
>>>
>>> T_ is the time of the observation.  For example, T_HI_ would be the 
>>>

Re: [weewx-user] Questions about weewx-loopdata 1.3.x

2020-07-10 Thread John Kline

I had a look.  You never actually write FMT_windDir in the JavaScript.  Just 
add:
+ ‘ (‘ + result[‘FMT_windDir’] + ‘)’
on the appropriate line in realtime_updater.inc.

As for barometerRate.  I do see it.  I just spills over to the next line.  It 
looks like I am not properly formatting barometerRate.  I will fix that as part 
of the 2.0 release which I am working on and hope to have out this weekend.

> On Jul 10, 2020, at 9:03 AM, geni08...@gmail.com  
> wrote:
> 
> 
> Hi John, I'm on the mountain, there was more. Can you please keep an eye on 
> the two files?
> 
> 
> jo...@johnkline.com schrieb am Freitag, 10. Juli 2020 um 16:05:18 UTC+2:
>> You need to add the fields:
>> barometerRate
>> FMT_windDir
>> to the fields line in the LoopData section of weewx.conf.
>> 
>> After you do that and restart WeeWX, verify that you see these readings in 
>> loop-data.txt.
>> 
>> Finally, you need to set these values in the JavaScript.
>> 
>> If you have already done all of the above, perhaps you have a JavaScript 
>> error.  Have a look in the JavaScript console in your browser (note: it may 
>> be called something else, search for how to see JavaScript errors).
>> 
>> BTW, this weekend, I should have a version of LoopData out that uses the 
>> same naming scheme as cheetah.  As such, you will then specify 
>> $current.windSpeed, $current.windDir.ordinal_compass and $current.windDir 
>> (for example) in the fields line in weewx.conf and those keys will show up 
>> in loop-data.txt.  There was no good reason to invent a new language for 
>> this. 
>> 
 On Jul 10, 2020, at 1:54 AM, geni08...@gmail.com  
 wrote:

>>> 
>> 
>>> what do I have to change so that the two values (in the yellow circle) are 
>>> always displayed? Now they only flash briefly during a manual refresh.
>> 
>>> 
>>> 
>>> in index.html.templ:
>>>  >> style="font-family:monospace;font-size:85px;text-align:center;">$current.windSpeed
>>>  $current.windDir.ordinal_compass ($current.windDir)
>>> $current.barometer 
>>> ($trend.barometer.formatted)->> id="FMT_outHumidity">$current.outHumidity
>>> 
>>> jo...@johnkline.com schrieb am Donnerstag, 9. Juli 2020 um 15:40:48 UTC+2:

>> On Jul 9, 2020, at 1:52 AM, geni08...@gmail.com  
>> wrote:
>> 
> Question for my understanding:

> 
> If or why is the id = string supplemented with $current, $day or not at 
> all?

> 

 In the examples, no IDs is supplemented with current, day or none at all.  
 Some values say $current, which means the current observation.  Some say 
 day, which would be for the day and have an aggregator ($day.rain.sum).  
 In any event, all of these values are overwritten every couple of seconds 
 by the javascript.  As such, they could be removed.

 As for the ids.  They could be anything you wish.  They just are used by 
 the JavaScript to look up the element.  As a naming scheme for ids, I 
 chose to to name them for the corresponding key in loop-data.txt.

 For example, FMT_HI_windGust.  The JavaScript will get lookup the element 
 with the id FMT_HI_windGust.  It will then lookup the value in 
 loop-data.txt for the key FMT_HI_windGust and set the contents of the HTML 
 tag (innerHTML property) to that value.

 If the id was foo on this element, the JavaScript would have to find the 
 foo element in the DOM.  Of course, it will still need to use the key 
 FMT_HI_windGust for looking up the loop-data value.

 As for the naming scheme in loop-data.txt:
 FMT_HI_windGust
 The FMT_ means include the label.
 The HI_ means give me today’s high.

 FMT_windGust would be for the current observation and would include the 
 label.

 windGust would be for the current observation. It would NOT include a 
 label, but it would still be formatted.  That is, if wind should have 1 
 decimal place, it be formatted as such (e.g., 4.0).

 The README has this info, but to summarize:

 If the key is missing an aggregator (HI, LO, AVG, WAVG, SUM, RMS, VEC_AVG, 
 VEC_DIR), it is the current observation.  If it has an aggregator prefix, 
 it is for the day.  Exceptions are the items I made up 10mMaxGust (which 
 is 10 minutes) and barometerRate (which is a delta from 3 hours ago) and 
 windRose.

 FMT_ includes the label.

 UNITS_ is the unit for the observation.

 LABEL_ is the label for the observation.

 COMPASS_ for windDIr and windGustDir gives compass (text) direction.

 DESC_ for barometer rate gives a text description of the rate (and 
 probably needs to be internationalized).

 T_ is the time of the observation.  For example, T_HI_ would be the 
 time today that the high was reached for the observation.

 Just to mention the other things you pointed to:
 FMT_SUM_rain is today’s rain with a label.

Re: [weewx-user] Questions about weewx-loopdata 1.3.x

2020-07-10 Thread geni08...@gmail.com

 Hi John, I'm on the mountain, there was more. Can you please keep an eye 
on the two files?


jo...@johnkline.com schrieb am Freitag, 10. Juli 2020 um 16:05:18 UTC+2:

> You need to add the fields:
> barometerRate
> FMT_windDir
> to the fields line in the LoopData section of weewx.conf.
>
> After you do that and restart WeeWX, verify that you see these readings in 
> loop-data.txt.
>
> Finally, you need to set these values in the JavaScript.
>
> If you have already done all of the above, perhaps you have a JavaScript 
> error.  Have a look in the JavaScript console in your browser (note: it may 
> be called something else, search for how to see JavaScript errors).
>
> BTW, this weekend, I should have a version of LoopData out that uses the 
> same naming scheme as cheetah.  As such, you will then specify 
> $current.windSpeed, $current.windDir.ordinal_compass and $current.windDir 
> (for example) in the fields line in weewx.conf and those keys will show up 
> in loop-data.txt.  There was no good reason to invent a new language for 
> this. 
>
> On Jul 10, 2020, at 1:54 AM, geni08...@gmail.com  
> wrote:
>
>  
>
> what do I have to change so that the two values (in the yellow circle) are 
> always displayed? Now they only flash briefly during a manual refresh.
>
> 
>
> in index.html.templ:
>   style="font-family:monospace;font-size:85px;text-align:center;">$current.windSpeed
>  
> $current.windDir.ordinal_compass ($current.windDir)
> $current.barometer 
> ($trend.barometer.formatted)- id="FMT_outHumidity">$current.outHumidity
>
> jo...@johnkline.com schrieb am Donnerstag, 9. Juli 2020 um 15:40:48 UTC+2:
>
>>
>>
>> On Jul 9, 2020, at 1:52 AM, geni08...@gmail.com  
>> wrote:
>>
>> Question for my understanding:
>>
>>
>> If or why is the id = string supplemented with $current, $day or not at 
>> all?
>>
>> 
>>
>>
>> In the examples, no IDs is supplemented with current, day or none at all. 
>>  Some values say $current, which means the current observation.  Some say 
>> day, which would be for the day and have an aggregator ($day.rain.sum).  In 
>> any event, all of these values are overwritten every couple of seconds by 
>> the javascript.  As such, they could be removed.
>>
>> As for the ids.  They could be anything you wish.  They just are used by 
>> the JavaScript to look up the element.  As a naming scheme for ids, I chose 
>> to to name them for the corresponding key in loop-data.txt.
>>
>> For example, FMT_HI_windGust.  The JavaScript will get lookup the element 
>> with the id FMT_HI_windGust.  It will then lookup the value in 
>> loop-data.txt for the key FMT_HI_windGust and set the contents of the HTML 
>> tag (innerHTML property) to that value.
>>
>> If the id was foo on this element, the JavaScript would have to find the 
>> foo element in the DOM.  Of course, it will still need to use the key 
>> FMT_HI_windGust for looking up the loop-data value.
>>
>> As for the naming scheme in loop-data.txt:
>> FMT_HI_windGust
>> The FMT_ means include the label.
>> The HI_ means give me today’s high.
>>
>> FMT_windGust would be for the current observation and would include the 
>> label.
>>
>> windGust would be for the current observation. It would NOT include a 
>> label, but it would still be formatted.  That is, if wind should have 1 
>> decimal place, it be formatted as such (e.g., 4.0).
>>
>> The README has this info, but to summarize:
>>
>> If the key is missing an aggregator (HI, LO, AVG, WAVG, SUM, RMS, 
>> VEC_AVG, VEC_DIR), it is the current observation.  If it has an aggregator 
>> prefix, it is for the day.  Exceptions are the items I made up 10mMaxGust 
>> (which is 10 minutes) and barometerRate (which is a delta from 3 hours ago) 
>> and windRose.
>>
>> FMT_ includes the label.
>>
>> UNITS_ is the unit for the observation.
>>
>> LABEL_ is the label for the observation.
>>
>> COMPASS_ for windDIr and windGustDir gives compass (text) direction.
>>
>> DESC_ for barometer rate gives a text description of the rate (and 
>> probably needs to be internationalized).
>>
>> T_ is the time of the observation.  For example, T_HI_ would be the 
>> time today that the high was reached for the observation.
>>
>> Just to mention the other things you pointed to:
>> FMT_SUM_rain is today’s rain with a label.  The FMT_ gives the label. 
>>  Since SUM_ is an aggregator, it is for today.
>>
>> FMT_rainRate is the current rate of rain (since it is missing an 
>> aggregator) and it includes a label (FMT_).  FMT_HI_rainRate would be 
>> today’s high rainRate.  FMT_T_HI_rainRate would be the formatted time when 
>> today’s high rain rate happened.
>>
>> Note that the packet time presented in WeatherBoard is not formatted.  It 
>> uses rainRate.  That time is then localized with toLocaleTimeString in 
>> JavaScript.  In that way, the time presented is local time for the viewer 
>> of the web page.
>>
>>
>>
>> jo...@johnkline.com schrieb am Mittwoch, 8. Juli 2020 um 20:35:22 UTC+2:
>>
>>>
>>>
>>> On Jul 8, 2020, at

Re: [weewx-user] Questions about weewx-loopdata 1.3.x

2020-07-10 Thread John Kline

You need to add the fields:
barometerRate
FMT_windDir
to the fields line in the LoopData section of weewx.conf.

After you do that and restart WeeWX, verify that you see these readings in 
loop-data.txt.

Finally, you need to set these values in the JavaScript.

If you have already done all of the above, perhaps you have a JavaScript error. 
 Have a look in the JavaScript console in your browser (note: it may be called 
something else, search for how to see JavaScript errors).

BTW, this weekend, I should have a version of LoopData out that uses the same 
naming scheme as cheetah.  As such, you will then specify $current.windSpeed, 
$current.windDir.ordinal_compass and $current.windDir (for example) in the 
fields line in weewx.conf and those keys will show up in loop-data.txt.  There 
was no good reason to invent a new language for this. 

> On Jul 10, 2020, at 1:54 AM, geni08...@gmail.com  
> wrote:
> 
> 
> what do I have to change so that the two values (in the yellow circle) are 
> always displayed? Now they only flash briefly during a manual refresh.
> 
> 
> in index.html.templ:
>   style="font-family:monospace;font-size:85px;text-align:center;">$current.windSpeed
>  $current.windDir.ordinal_compass ($current.windDir)
> $current.barometer 
> ($trend.barometer.formatted)- id="FMT_outHumidity">$current.outHumidity
> 
> jo...@johnkline.com schrieb am Donnerstag, 9. Juli 2020 um 15:40:48 UTC+2:
>> 
>> 
 On Jul 9, 2020, at 1:52 AM, geni08...@gmail.com  
 wrote:
 
>>> Question for my understanding:
>> 
>>> 
>>> If or why is the id = string supplemented with $current, $day or not at all?
>> 
>>> 
>> 
>> In the examples, no IDs is supplemented with current, day or none at all.  
>> Some values say $current, which means the current observation.  Some say 
>> day, which would be for the day and have an aggregator ($day.rain.sum).  In 
>> any event, all of these values are overwritten every couple of seconds by 
>> the javascript.  As such, they could be removed.
>> 
>> As for the ids.  They could be anything you wish.  They just are used by the 
>> JavaScript to look up the element.  As a naming scheme for ids, I chose to 
>> to name them for the corresponding key in loop-data.txt.
>> 
>> For example, FMT_HI_windGust.  The JavaScript will get lookup the element 
>> with the id FMT_HI_windGust.  It will then lookup the value in loop-data.txt 
>> for the key FMT_HI_windGust and set the contents of the HTML tag (innerHTML 
>> property) to that value.
>> 
>> If the id was foo on this element, the JavaScript would have to find the foo 
>> element in the DOM.  Of course, it will still need to use the key 
>> FMT_HI_windGust for looking up the loop-data value.
>> 
>> As for the naming scheme in loop-data.txt:
>> FMT_HI_windGust
>> The FMT_ means include the label.
>> The HI_ means give me today’s high.
>> 
>> FMT_windGust would be for the current observation and would include the 
>> label.
>> 
>> windGust would be for the current observation. It would NOT include a label, 
>> but it would still be formatted.  That is, if wind should have 1 decimal 
>> place, it be formatted as such (e.g., 4.0).
>> 
>> The README has this info, but to summarize:
>> 
>> If the key is missing an aggregator (HI, LO, AVG, WAVG, SUM, RMS, VEC_AVG, 
>> VEC_DIR), it is the current observation.  If it has an aggregator prefix, it 
>> is for the day.  Exceptions are the items I made up 10mMaxGust (which is 10 
>> minutes) and barometerRate (which is a delta from 3 hours ago) and windRose.
>> 
>> FMT_ includes the label.
>> 
>> UNITS_ is the unit for the observation.
>> 
>> LABEL_ is the label for the observation.
>> 
>> COMPASS_ for windDIr and windGustDir gives compass (text) direction.
>> 
>> DESC_ for barometer rate gives a text description of the rate (and probably 
>> needs to be internationalized).
>> 
>> T_ is the time of the observation.  For example, T_HI_ would be the 
>> time today that the high was reached for the observation.
>> 
>> Just to mention the other things you pointed to:
>> FMT_SUM_rain is today’s rain with a label.  The FMT_ gives the label.  Since 
>> SUM_ is an aggregator, it is for today.
>> 
>> FMT_rainRate is the current rate of rain (since it is missing an aggregator) 
>> and it includes a label (FMT_).  FMT_HI_rainRate would be today’s high 
>> rainRate.  FMT_T_HI_rainRate would be the formatted time when today’s high 
>> rain rate happened.
>> 
>> Note that the packet time presented in WeatherBoard is not formatted.  It 
>> uses rainRate.  That time is then localized with toLocaleTimeString in 
>> JavaScript.  In that way, the time presented is local time for the viewer of 
>> the web page.
>> 
>>> 
>>> 
>>> jo...@johnkline.com schrieb am Mittwoch, 8. Juli 2020 um 20:35:22 UTC+2:
 
 
>> On Jul 8, 2020, at 1:36 AM, geni08...@gmail.com  
>> wrote:
>> 
>  weewx-weatherboard 1.3a the label entries are implemented.
 
> 
> What is the easiest way now
> Indoor

Re: [weewx-user] Questions about weewx-loopdata 1.3.x

2020-07-09 Thread John Kline

>> On Jul 9, 2020, at 1:52 AM, geni08...@gmail.com  
>> wrote:
> Question for my understanding:
> If or why is the id = string supplemented with $current, $day or not at all?
> 

In the examples, no IDs is supplemented with current, day or none at all.  Some 
values say $current, which means the current observation.  Some say day, which 
would be for the day and have an aggregator ($day.rain.sum).  In any event, all 
of these values are overwritten every couple of seconds by the javascript.  As 
such, they could be removed.

As for the ids.  They could be anything you wish.  They just are used by the 
JavaScript to look up the element.  As a naming scheme for ids, I chose to to 
name them for the corresponding key in loop-data.txt.

For example, FMT_HI_windGust.  The JavaScript will get lookup the element with 
the id FMT_HI_windGust.  It will then lookup the value in loop-data.txt for the 
key FMT_HI_windGust and set the contents of the HTML tag (innerHTML property) 
to that value.

If the id was foo on this element, the JavaScript would have to find the foo 
element in the DOM.  Of course, it will still need to use the key 
FMT_HI_windGust for looking up the loop-data value.

As for the naming scheme in loop-data.txt:
FMT_HI_windGust
The FMT_ means include the label.
The HI_ means give me today’s high.

FMT_windGust would be for the current observation and would include the label.

windGust would be for the current observation. It would NOT include a label, 
but it would still be formatted.  That is, if wind should have 1 decimal place, 
it be formatted as such (e.g., 4.0).

The README has this info, but to summarize:

If the key is missing an aggregator (HI, LO, AVG, WAVG, SUM, RMS, VEC_AVG, 
VEC_DIR), it is the current observation.  If it has an aggregator prefix, it is 
for the day.  Exceptions are the items I made up 10mMaxGust (which is 10 
minutes) and barometerRate (which is a delta from 3 hours ago) and windRose.

FMT_ includes the label.

UNITS_ is the unit for the observation.

LABEL_ is the label for the observation.

COMPASS_ for windDIr and windGustDir gives compass (text) direction.

DESC_ for barometer rate gives a text description of the rate (and probably 
needs to be internationalized).

T_ is the time of the observation.  For example, T_HI_ would be the time 
today that the high was reached for the observation.

Just to mention the other things you pointed to:
FMT_SUM_rain is today’s rain with a label.  The FMT_ gives the label.  Since 
SUM_ is an aggregator, it is for today.

FMT_rainRate is the current rate of rain (since it is missing an aggregator) 
and it includes a label (FMT_).  FMT_HI_rainRate would be today’s high 
rainRate.  FMT_T_HI_rainRate would be the formatted time when today’s high rain 
rate happened.

Note that the packet time presented in WeatherBoard is not formatted.  It uses 
rainRate.  That time is then localized with toLocaleTimeString in JavaScript.  
In that way, the time presented is local time for the viewer of the web page.
> 
> 
> jo...@johnkline.com schrieb am Mittwoch, 8. Juli 2020 um 20:35:22 UTC+2:
>> 
>> 
 On Jul 8, 2020, at 1:36 AM, geni08...@gmail.com  
 wrote:
>>>  weewx-weatherboard 1.3a the label entries are implemented.
>> 
>>> 
>>> What is the easiest way now
>>> Indoor temperature
>>> barometer
>>> Indoor and outdoor humidity
>>> to show signs on the display?
>> 
>> 
>> To get these readings in loop-data.txt, add the following to the end of the 
>> fields line in the LoopData section of weewx.conf:
>> , FMT_inTemp, FMT_barometer, FMT_inHumidity, FMT_outHumidity
>> 
>> As for adding them to a skin, it would be helpful to know your end goal and 
>> your familiarity with the technologies.
>> 
>> WeatherBoard is designed for display on a tablet sitting on a bookshelf or 
>> hanging on a wall.  It’s meant to be viewed from across the room.  That’s 
>> why there’s a small amount of data in large fonts and why I chose the color 
>> scheme.
>> 
>> Are you trying to have something that looks like WeatherBoard but just these 
>> four extra items on it?  Will you want more after you add these four?  Extra 
>> items will mean smaller fonts.  How will this skin be viewed?  I’m assuming 
>> you are not looking for the across the room viewing that I targeted with 
>> this skin.
>> 
>> Are you looking to write an entirely new skin?
>> 
>> Are you looking to add “update on every loop” capabilities to another skin 
>> that you like?
>> 
>> How comfortable are you working with html, css and JavaScript?
>> 
>> Cheers,
>> John
>> 
>> 
>>> 
>>> jo...@johnkline.com schrieb am Dienstag, 7. Juli 2020 um 20:10:24 UTC+2:
 Most of the WeatherBoard will now use the strings in Defaults, so you 
 should see it in German after you install.  For the custom strings, just 
 update the strings in the WeatherBoard>Labels>Generic section of 
 weewx.conf.

>> On Jul 7, 2020, at 6:47 AM, John Kline  wrote:
> 

> I’ve created a

Re: [weewx-user] Questions about weewx-loopdata 1.3.x

2020-07-09 Thread geni08...@gmail.com

Question for my understanding:
If or why is the id = string supplemented with $current, $day or not at all?
[image: loop1.jpg]

jo...@johnkline.com schrieb am Mittwoch, 8. Juli 2020 um 20:35:22 UTC+2:

>
>
> On Jul 8, 2020, at 1:36 AM, geni08...@gmail.com  
> wrote:
>
>  weewx-weatherboard 1.3a the label entries are implemented.
>
>
> What is the easiest way now
> Indoor temperature
> barometer
> Indoor and outdoor humidity
> to show signs on the display?
>
>
>
> To get these readings in loop-data.txt, add the following to the end of 
> the fields line in the LoopData section of weewx.conf:
> , FMT_inTemp, FMT_barometer, FMT_inHumidity, FMT_outHumidity
>
> As for adding them to a skin, it would be helpful to know your end goal 
> and your familiarity with the technologies.
>
> WeatherBoard is designed for display on a tablet sitting on a bookshelf or 
> hanging on a wall.  It’s meant to be viewed from across the room.  That’s 
> why there’s a small amount of data in large fonts and why I chose the color 
> scheme.
>
> Are you trying to have something that looks like WeatherBoard but just 
> these four extra items on it?  Will you want more after you add these four? 
>  Extra items will mean smaller fonts.  How will this skin be viewed?  I’m 
> assuming you are not looking for the across the room viewing that I 
> targeted with this skin.
>
> Are you looking to write an entirely new skin?
>
> Are you looking to add “update on every loop” capabilities to another skin 
> that you like?
>
> How comfortable are you working with html, css and JavaScript?
>
> Cheers,
> John
>
>
> jo...@johnkline.com schrieb am Dienstag, 7. Juli 2020 um 20:10:24 UTC+2:
>
>> Most of the WeatherBoard will now use the strings in Defaults, so you 
>> should see it in German after you install.  For the custom strings, just 
>> update the strings in the WeatherBoard>Labels>Generic section of weewx.conf.
>>
>> On Jul 7, 2020, at 6:47 AM, John Kline  wrote:
>>
>> 
>>
>> I’ve created a branch of WeatherBoard that substitutes appTemp for 
>> dewpoint.
>>
>> It is here:
>> https://github.com/chaunceygardiner/weewx-weatherboard/tree/appTemp
>>
>> On Jul 7, 2020, at 12:09 AM, John Kline  wrote:
>>
>> 
>> There was a subtle difference in how I was creating the next day 
>> accumulator vs. how WeeWX proper is doing it.  I’ve changed that.  Please 
>> install 1.3.15 and let me know how it goes at midnight.
>>
>> On Jul 6, 2020, at 10:44 PM, geni08...@gmail.com  
>> wrote:
>>
>> Jul  7 00:00:01 Wetter-Raspi rsyslogd:  [origin software="rsyslogd" 
>> swVersion="8.1901.0" x-pid="295" x-info="https://www.rsyslog.com;] 
>> rsyslogd was HUPed
>> Jul  7 00:00:01 Wetter-Raspi systemd[1]: logrotate.service: Succeeded.
>> Jul  7 00:00:01 Wetter-Raspi systemd[1]: Started Rotate log files.
>> Jul  7 00:00:02 Wetter-Raspi systemd[1]: man-db.service: Succeeded.
>> Jul  7 00:00:02 Wetter-Raspi systemd[1]: Started Daily man-db 
>> regeneration.
>> Jul  7 00:00:15 Wetter-Raspi weewx[18476] INFO weewx.manager: Added 
>> record 2020-07-07 00:00:00 CEST (1594072800) to database 'weewx'
>> Jul  7 00:00:15 Wetter-Raspi weewx[18476] INFO weewx.manager: Added 
>> record 2020-07-07 00:00:00 CEST (1594072800) to daily summary in 'weewx'
>>
>>
>> geni08...@gmail.com schrieb am Dienstag, 7. Juli 2020 um 07:39:52 UTC+2:
>>
>>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata: 
>>>   Traceback (most recent call last):
>>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata: 
>>> File "/usr/share/weewx/user/loopdata.py", line 365, in process_queue
>>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata: 
>>>   self.day_accum.addRecord(pkt)
>>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata: 
>>> File "/usr/share/weewx/weewx/accum.py", line 423, in addRecord
>>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata: 
>>>   % (record['dateTime'], self.timespan))
>>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata: 
>>>   weewx.accum.OutOfSpan: Attempt to add out-of-interval record 
>>> (1594072801) to timespan ([2020-07-06 00:00:00 CEST (1593986400) -> 
>>> 2020-07-07 00:00:00 CEST (1594072800)])
>>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata: 
>>>   
>>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata: 
>>>   During handling of the above exception, another exception occurred:
>>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata: 
>>>   
>>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata: 
>>>   Traceback (most recent call last):
>>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata: 
>>> File "/usr/share/weewx/user/loopdata.py", line 370, in process_queue
>>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata: 
>>>   self.day_accum.addRecord(pkt)
>>> Jul  7

Re: [weewx-user] Questions about weewx-loopdata 1.3.x

2020-07-08 Thread John Kline



> On Jul 8, 2020, at 1:36 AM, geni08...@gmail.com  
> wrote:
> 
>  weewx-weatherboard 1.3a the label entries are implemented.
> What is the easiest way now
> Indoor temperature
> barometer
> Indoor and outdoor humidity
> to show signs on the display? 

To get these readings in loop-data.txt, add the following to the end of the 
fields line in the LoopData section of weewx.conf:
, FMT_inTemp, FMT_barometer, FMT_inHumidity, FMT_outHumidity

As for adding them to a skin, it would be helpful to know your end goal and 
your familiarity with the technologies.

WeatherBoard is designed for display on a tablet sitting on a bookshelf or 
hanging on a wall.  It’s meant to be viewed from across the room.  That’s why 
there’s a small amount of data in large fonts and why I chose the color scheme.

Are you trying to have something that looks like WeatherBoard but just these 
four extra items on it?  Will you want more after you add these four?  Extra 
items will mean smaller fonts.  How will this skin be viewed?  I’m assuming you 
are not looking for the across the room viewing that I targeted with this skin.

Are you looking to write an entirely new skin?

Are you looking to add “update on every loop” capabilities to another skin that 
you like?

How comfortable are you working with html, css and JavaScript?

Cheers,
John

> 
> jo...@johnkline.com schrieb am Dienstag, 7. Juli 2020 um 20:10:24 UTC+2:
>> Most of the WeatherBoard will now use the strings in Defaults, so you should 
>> see it in German after you install.  For the custom strings, just update the 
>> strings in the WeatherBoard>Labels>Generic section of weewx.conf.
>> 
 On Jul 7, 2020, at 6:47 AM, John Kline  wrote:
 
>>> 
>> 
>>> I’ve created a branch of WeatherBoard that substitutes appTemp for dewpoint.
>>> 
>>> It is here:
>>> https://github.com/chaunceygardiner/weewx-weatherboard/tree/appTemp
>>> 
> On Jul 7, 2020, at 12:09 AM, John Kline  wrote:
> 
 
 There was a subtle difference in how I was creating the next day 
 accumulator vs. how WeeWX proper is doing it.  I’ve changed that.  Please 
 install 1.3.15 and let me know how it goes at midnight.
 
>> On Jul 6, 2020, at 10:44 PM, geni08...@gmail.com  
>> wrote:
>> 
> Jul  7 00:00:01 Wetter-Raspi rsyslogd:  [origin software="rsyslogd" 
> swVersion="8.1901.0" x-pid="295" x-info="https://www.rsyslog.com;] 
> rsyslogd was HUPed
> Jul  7 00:00:01 Wetter-Raspi systemd[1]: logrotate.service: Succeeded.
> Jul  7 00:00:01 Wetter-Raspi systemd[1]: Started Rotate log files.
> Jul  7 00:00:02 Wetter-Raspi systemd[1]: man-db.service: Succeeded.
> Jul  7 00:00:02 Wetter-Raspi systemd[1]: Started Daily man-db 
> regeneration.
> Jul  7 00:00:15 Wetter-Raspi weewx[18476] INFO weewx.manager: Added 
> record 2020-07-07 00:00:00 CEST (1594072800) to database 'weewx'
> Jul  7 00:00:15 Wetter-Raspi weewx[18476] INFO weewx.manager: Added 
> record 2020-07-07 00:00:00 CEST (1594072800) to daily summary in 'weewx'
> 
> 
> geni08...@gmail.com schrieb am Dienstag, 7. Juli 2020 um 07:39:52 UTC+2:
>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata: 
>>   Traceback (most recent call last):
>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata: 
>> File "/usr/share/weewx/user/loopdata.py", line 365, in 
>> process_queue
>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata: 
>>   self.day_accum.addRecord(pkt)
>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata: 
>> File "/usr/share/weewx/weewx/accum.py", line 423, in addRecord
>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata: 
>>   % (record['dateTime'], self.timespan))
>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata: 
>>   weewx.accum.OutOfSpan: Attempt to add out-of-interval record 
>> (1594072801) to timespan ([2020-07-06 00:00:00 CEST (1593986400) -> 
>> 2020-07-07 00:00:00 CEST (1594072800)])
>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata: 
>>   
>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata: 
>>   During handling of the above exception, another exception occurred:
>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata: 
>>   
>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata: 
>>   Traceback (most recent call last):
>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata: 
>> File "/usr/share/weewx/user/loopdata.py", line 370, in 
>> process_queue
>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata: 
>>   self.day_accum.addRecord(pkt)
>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata: 
>> File

Re: [weewx-user] Questions about weewx-loopdata 1.3.x

2020-07-08 Thread geni08...@gmail.com

 weewx-weatherboard 1.3a the label entries are implemented.
What is the easiest way now
Indoor temperature
barometer
Indoor and outdoor humidity
to show signs on the display? 

jo...@johnkline.com schrieb am Dienstag, 7. Juli 2020 um 20:10:24 UTC+2:

> Most of the WeatherBoard will now use the strings in Defaults, so you 
> should see it in German after you install.  For the custom strings, just 
> update the strings in the WeatherBoard>Labels>Generic section of weewx.conf.
>
> On Jul 7, 2020, at 6:47 AM, John Kline  wrote:
>
> 
>
> I’ve created a branch of WeatherBoard that substitutes appTemp for 
> dewpoint.
>
> It is here:
> https://github.com/chaunceygardiner/weewx-weatherboard/tree/appTemp
>
> On Jul 7, 2020, at 12:09 AM, John Kline  wrote:
>
> 
> There was a subtle difference in how I was creating the next day 
> accumulator vs. how WeeWX proper is doing it.  I’ve changed that.  Please 
> install 1.3.15 and let me know how it goes at midnight.
>
> On Jul 6, 2020, at 10:44 PM, geni08...@gmail.com  
> wrote:
>
> Jul  7 00:00:01 Wetter-Raspi rsyslogd:  [origin software="rsyslogd" 
> swVersion="8.1901.0" x-pid="295" x-info="https://www.rsyslog.com;] 
> rsyslogd was HUPed
> Jul  7 00:00:01 Wetter-Raspi systemd[1]: logrotate.service: Succeeded.
> Jul  7 00:00:01 Wetter-Raspi systemd[1]: Started Rotate log files.
> Jul  7 00:00:02 Wetter-Raspi systemd[1]: man-db.service: Succeeded.
> Jul  7 00:00:02 Wetter-Raspi systemd[1]: Started Daily man-db regeneration.
> Jul  7 00:00:15 Wetter-Raspi weewx[18476] INFO weewx.manager: Added record 
> 2020-07-07 00:00:00 CEST (1594072800) to database 'weewx'
> Jul  7 00:00:15 Wetter-Raspi weewx[18476] INFO weewx.manager: Added record 
> 2020-07-07 00:00:00 CEST (1594072800) to daily summary in 'weewx'
>
>
> geni08...@gmail.com schrieb am Dienstag, 7. Juli 2020 um 07:39:52 UTC+2:
>
>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata: 
>>   Traceback (most recent call last):
>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata: 
>> File "/usr/share/weewx/user/loopdata.py", line 365, in process_queue
>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata: 
>>   self.day_accum.addRecord(pkt)
>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata: 
>> File "/usr/share/weewx/weewx/accum.py", line 423, in addRecord
>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata: 
>>   % (record['dateTime'], self.timespan))
>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata: 
>>   weewx.accum.OutOfSpan: Attempt to add out-of-interval record 
>> (1594072801) to timespan ([2020-07-06 00:00:00 CEST (1593986400) -> 
>> 2020-07-07 00:00:00 CEST (1594072800)])
>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata: 
>>   
>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata: 
>>   During handling of the above exception, another exception occurred:
>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata: 
>>   
>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata: 
>>   Traceback (most recent call last):
>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata: 
>> File "/usr/share/weewx/user/loopdata.py", line 370, in process_queue
>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata: 
>>   self.day_accum.addRecord(pkt)
>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata: 
>> File "/usr/share/weewx/weewx/accum.py", line 423, in addRecord
>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata: 
>>   % (record['dateTime'], self.timespan))
>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata: 
>>   weewx.accum.OutOfSpan: Attempt to add out-of-interval record 
>> (1594072801) to timespan ([2020-07-06 00:00:00 CEST (1593986400) -> 
>> 2020-07-07 00:00:00 CEST (1594072800)])
>> Jul  7 00:00:00 Wetter-Raspi systemd[1]: Starting Rotate log files...
>> Jul  7 00:00:00 Wetter-Raspi systemd[1]: Starting Daily man-db 
>> regeneration...
>>
>>
>> jo...@johnkline.com schrieb am Dienstag, 7. Juli 2020 um 07:09:28 UTC+2:
>>
>>> It looks like loopdata stopped again at midnight (I looked at your 
>>> sight).
>>>
>>> I think it likely that something in the packet at midnight is causing 
>>> this.  Loopdata does print a stack trace on an unexpected exception before 
>>> exiting.  Would you have a look in the log and send it?
>>>
>>> If the stack trace doesn’t give me the info I need, I will send you an 
>>> instrumented version of loopdata.py that will, among other things, log loop 
>>> packets around midnight.
>>>
>>> On Jul 6, 2020, at 10:26 AM, John Kline  wrote:
>>>
>>> 
>>>
>>> BTW, I should probably make dewpoint position on the weatherboard 
>>> configurable between dewpoint and appTemp.  That would save you from having 
>>> to hack on the

Re: [weewx-user] Questions about weewx-loopdata 1.3.x

2020-07-07 Thread geni08...@gmail.com

no error in the log file, and weewx-loopdate has mastered midnight.

I will look at weewx-weatherboard in a moment

jo...@johnkline.com schrieb am Dienstag, 7. Juli 2020 um 20:10:24 UTC+2:

> Most of the WeatherBoard will now use the strings in Defaults, so you 
> should see it in German after you install.  For the custom strings, just 
> update the strings in the WeatherBoard>Labels>Generic section of weewx.conf.
>
> On Jul 7, 2020, at 6:47 AM, John Kline  wrote:
>
> 
>
> I’ve created a branch of WeatherBoard that substitutes appTemp for 
> dewpoint.
>
> It is here:
> https://github.com/chaunceygardiner/weewx-weatherboard/tree/appTemp
>
> On Jul 7, 2020, at 12:09 AM, John Kline  wrote:
>
> 
> There was a subtle difference in how I was creating the next day 
> accumulator vs. how WeeWX proper is doing it.  I’ve changed that.  Please 
> install 1.3.15 and let me know how it goes at midnight.
>
> On Jul 6, 2020, at 10:44 PM, geni08...@gmail.com  
> wrote:
>
> Jul  7 00:00:01 Wetter-Raspi rsyslogd:  [origin software="rsyslogd" 
> swVersion="8.1901.0" x-pid="295" x-info="https://www.rsyslog.com;] 
> rsyslogd was HUPed
> Jul  7 00:00:01 Wetter-Raspi systemd[1]: logrotate.service: Succeeded.
> Jul  7 00:00:01 Wetter-Raspi systemd[1]: Started Rotate log files.
> Jul  7 00:00:02 Wetter-Raspi systemd[1]: man-db.service: Succeeded.
> Jul  7 00:00:02 Wetter-Raspi systemd[1]: Started Daily man-db regeneration.
> Jul  7 00:00:15 Wetter-Raspi weewx[18476] INFO weewx.manager: Added record 
> 2020-07-07 00:00:00 CEST (1594072800) to database 'weewx'
> Jul  7 00:00:15 Wetter-Raspi weewx[18476] INFO weewx.manager: Added record 
> 2020-07-07 00:00:00 CEST (1594072800) to daily summary in 'weewx'
>
>
> geni08...@gmail.com schrieb am Dienstag, 7. Juli 2020 um 07:39:52 UTC+2:
>
>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata: 
>>   Traceback (most recent call last):
>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata: 
>> File "/usr/share/weewx/user/loopdata.py", line 365, in process_queue
>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata: 
>>   self.day_accum.addRecord(pkt)
>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata: 
>> File "/usr/share/weewx/weewx/accum.py", line 423, in addRecord
>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata: 
>>   % (record['dateTime'], self.timespan))
>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata: 
>>   weewx.accum.OutOfSpan: Attempt to add out-of-interval record 
>> (1594072801) to timespan ([2020-07-06 00:00:00 CEST (1593986400) -> 
>> 2020-07-07 00:00:00 CEST (1594072800)])
>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata: 
>>   
>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata: 
>>   During handling of the above exception, another exception occurred:
>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata: 
>>   
>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata: 
>>   Traceback (most recent call last):
>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata: 
>> File "/usr/share/weewx/user/loopdata.py", line 370, in process_queue
>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata: 
>>   self.day_accum.addRecord(pkt)
>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata: 
>> File "/usr/share/weewx/weewx/accum.py", line 423, in addRecord
>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata: 
>>   % (record['dateTime'], self.timespan))
>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata: 
>>   weewx.accum.OutOfSpan: Attempt to add out-of-interval record 
>> (1594072801) to timespan ([2020-07-06 00:00:00 CEST (1593986400) -> 
>> 2020-07-07 00:00:00 CEST (1594072800)])
>> Jul  7 00:00:00 Wetter-Raspi systemd[1]: Starting Rotate log files...
>> Jul  7 00:00:00 Wetter-Raspi systemd[1]: Starting Daily man-db 
>> regeneration...
>>
>>
>> jo...@johnkline.com schrieb am Dienstag, 7. Juli 2020 um 07:09:28 UTC+2:
>>
>>> It looks like loopdata stopped again at midnight (I looked at your 
>>> sight).
>>>
>>> I think it likely that something in the packet at midnight is causing 
>>> this.  Loopdata does print a stack trace on an unexpected exception before 
>>> exiting.  Would you have a look in the log and send it?
>>>
>>> If the stack trace doesn’t give me the info I need, I will send you an 
>>> instrumented version of loopdata.py that will, among other things, log loop 
>>> packets around midnight.
>>>
>>> On Jul 6, 2020, at 10:26 AM, John Kline  wrote:
>>>
>>> 
>>>
>>> BTW, I should probably make dewpoint position on the weatherboard 
>>> configurable between dewpoint and appTemp.  That would save you from having 
>>> to hack on the javaascript.
>>>
>>> Also, I could make the legend configurable

Re: [weewx-user] Questions about weewx-loopdata 1.3.x

2020-07-07 Thread John Kline

Most of the WeatherBoard will now use the strings in Defaults, so you should 
see it in German after you install.  For the custom strings, just update the 
strings in the WeatherBoard>Labels>Generic section of weewx.conf.

> On Jul 7, 2020, at 6:47 AM, John Kline  wrote:
> 
> 
> I’ve created a branch of WeatherBoard that substitutes appTemp for dewpoint.
> 
> It is here:
> https://github.com/chaunceygardiner/weewx-weatherboard/tree/appTemp
> 
>>> On Jul 7, 2020, at 12:09 AM, John Kline  wrote:
>>> 
>> 
>> There was a subtle difference in how I was creating the next day accumulator 
>> vs. how WeeWX proper is doing it.  I’ve changed that.  Please install 1.3.15 
>> and let me know how it goes at midnight.
>> 
 On Jul 6, 2020, at 10:44 PM, geni08...@gmail.com  
 wrote:
 
>>> Jul  7 00:00:01 Wetter-Raspi rsyslogd:  [origin software="rsyslogd" 
>>> swVersion="8.1901.0" x-pid="295" x-info="https://www.rsyslog.com;] rsyslogd 
>>> was HUPed
>>> Jul  7 00:00:01 Wetter-Raspi systemd[1]: logrotate.service: Succeeded.
>>> Jul  7 00:00:01 Wetter-Raspi systemd[1]: Started Rotate log files.
>>> Jul  7 00:00:02 Wetter-Raspi systemd[1]: man-db.service: Succeeded.
>>> Jul  7 00:00:02 Wetter-Raspi systemd[1]: Started Daily man-db regeneration.
>>> Jul  7 00:00:15 Wetter-Raspi weewx[18476] INFO weewx.manager: Added record 
>>> 2020-07-07 00:00:00 CEST (1594072800) to database 'weewx'
>>> Jul  7 00:00:15 Wetter-Raspi weewx[18476] INFO weewx.manager: Added record 
>>> 2020-07-07 00:00:00 CEST (1594072800) to daily summary in 'weewx'
>>> 
>>> 
>>> geni08...@gmail.com schrieb am Dienstag, 7. Juli 2020 um 07:39:52 UTC+2:
 Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata:  
  Traceback (most recent call last):
 Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata:  
File "/usr/share/weewx/user/loopdata.py", line 365, in process_queue
 Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata:  
  self.day_accum.addRecord(pkt)
 Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata:  
File "/usr/share/weewx/weewx/accum.py", line 423, in addRecord
 Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata:  
  % (record['dateTime'], self.timespan))
 Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata:  
  weewx.accum.OutOfSpan: Attempt to add out-of-interval record (1594072801) 
 to timespan ([2020-07-06 00:00:00 CEST (1593986400) -> 2020-07-07 00:00:00 
 CEST (1594072800)])
 Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata:  
  
 Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata:  
  During handling of the above exception, another exception occurred:
 Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata:  
  
 Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata:  
  Traceback (most recent call last):
 Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata:  
File "/usr/share/weewx/user/loopdata.py", line 370, in process_queue
 Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata:  
  self.day_accum.addRecord(pkt)
 Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata:  
File "/usr/share/weewx/weewx/accum.py", line 423, in addRecord
 Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata:  
  % (record['dateTime'], self.timespan))
 Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata:  
  weewx.accum.OutOfSpan: Attempt to add out-of-interval record (1594072801) 
 to timespan ([2020-07-06 00:00:00 CEST (1593986400) -> 2020-07-07 00:00:00 
 CEST (1594072800)])
 Jul  7 00:00:00 Wetter-Raspi systemd[1]: Starting Rotate log files...
 Jul  7 00:00:00 Wetter-Raspi systemd[1]: Starting Daily man-db 
 regeneration...
 
 
 jo...@johnkline.com schrieb am Dienstag, 7. Juli 2020 um 07:09:28 UTC+2:
> It looks like loopdata stopped again at midnight (I looked at your sight).
> 
> I think it likely that something in the packet at midnight is causing 
> this.  Loopdata does print a stack trace on an unexpected exception 
> before exiting.  Would you have a look in the log and send it?
> 
> If the stack trace doesn’t give me the info I need, I will send you an 
> instrumented version of loopdata.py that will, among other things, log 
> loop packets around midnight.
> 
>>> On Jul 6, 2020, at 10:26 AM, John Kline  wrote:
>>> 
>> 
> 
>> BTW, I should probably make dewpoint position on the weatherboard 
>> configurable between dewpoint and appTemp.  That would save you from 
>> having to hack on the javaascript.
>> 
>> Also, I could make the legend configurable for translation.
>>

Re: [weewx-user] Questions about weewx-loopdata 1.3.x

2020-07-07 Thread John Kline

I’ve created a branch of WeatherBoard that substitutes appTemp for dewpoint.

It is here:
https://github.com/chaunceygardiner/weewx-weatherboard/tree/appTemp

> On Jul 7, 2020, at 12:09 AM, John Kline  wrote:
> 
> 
> There was a subtle difference in how I was creating the next day accumulator 
> vs. how WeeWX proper is doing it.  I’ve changed that.  Please install 1.3.15 
> and let me know how it goes at midnight.
> 
>>> On Jul 6, 2020, at 10:44 PM, geni08...@gmail.com  
>>> wrote:
>>> 
>> Jul  7 00:00:01 Wetter-Raspi rsyslogd:  [origin software="rsyslogd" 
>> swVersion="8.1901.0" x-pid="295" x-info="https://www.rsyslog.com;] rsyslogd 
>> was HUPed
>> Jul  7 00:00:01 Wetter-Raspi systemd[1]: logrotate.service: Succeeded.
>> Jul  7 00:00:01 Wetter-Raspi systemd[1]: Started Rotate log files.
>> Jul  7 00:00:02 Wetter-Raspi systemd[1]: man-db.service: Succeeded.
>> Jul  7 00:00:02 Wetter-Raspi systemd[1]: Started Daily man-db regeneration.
>> Jul  7 00:00:15 Wetter-Raspi weewx[18476] INFO weewx.manager: Added record 
>> 2020-07-07 00:00:00 CEST (1594072800) to database 'weewx'
>> Jul  7 00:00:15 Wetter-Raspi weewx[18476] INFO weewx.manager: Added record 
>> 2020-07-07 00:00:00 CEST (1594072800) to daily summary in 'weewx'
>> 
>> 
>> geni08...@gmail.com schrieb am Dienstag, 7. Juli 2020 um 07:39:52 UTC+2:
>>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata:   
>>> Traceback (most recent call last):
>>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata:   
>>>   File "/usr/share/weewx/user/loopdata.py", line 365, in process_queue
>>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata:   
>>> self.day_accum.addRecord(pkt)
>>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata:   
>>>   File "/usr/share/weewx/weewx/accum.py", line 423, in addRecord
>>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata:   
>>> % (record['dateTime'], self.timespan))
>>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata:   
>>> weewx.accum.OutOfSpan: Attempt to add out-of-interval record (1594072801) 
>>> to timespan ([2020-07-06 00:00:00 CEST (1593986400) -> 2020-07-07 00:00:00 
>>> CEST (1594072800)])
>>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata:   
>>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata:   
>>> During handling of the above exception, another exception occurred:
>>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata:   
>>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata:   
>>> Traceback (most recent call last):
>>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata:   
>>>   File "/usr/share/weewx/user/loopdata.py", line 370, in process_queue
>>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata:   
>>> self.day_accum.addRecord(pkt)
>>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata:   
>>>   File "/usr/share/weewx/weewx/accum.py", line 423, in addRecord
>>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata:   
>>> % (record['dateTime'], self.timespan))
>>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata:   
>>> weewx.accum.OutOfSpan: Attempt to add out-of-interval record (1594072801) 
>>> to timespan ([2020-07-06 00:00:00 CEST (1593986400) -> 2020-07-07 00:00:00 
>>> CEST (1594072800)])
>>> Jul  7 00:00:00 Wetter-Raspi systemd[1]: Starting Rotate log files...
>>> Jul  7 00:00:00 Wetter-Raspi systemd[1]: Starting Daily man-db 
>>> regeneration...
>>> 
>>> 
>>> jo...@johnkline.com schrieb am Dienstag, 7. Juli 2020 um 07:09:28 UTC+2:
 It looks like loopdata stopped again at midnight (I looked at your sight).
 
 I think it likely that something in the packet at midnight is causing 
 this.  Loopdata does print a stack trace on an unexpected exception before 
 exiting.  Would you have a look in the log and send it?
 
 If the stack trace doesn’t give me the info I need, I will send you an 
 instrumented version of loopdata.py that will, among other things, log 
 loop packets around midnight.
 
>> On Jul 6, 2020, at 10:26 AM, John Kline  wrote:
>> 
> 
 
> BTW, I should probably make dewpoint position on the weatherboard 
> configurable between dewpoint and appTemp.  That would save you from 
> having to hack on the javaascript.
> 
> Also, I could make the legend configurable for translation.
> 
> I’ll try to do that today or tomorrow.
> 
>>> On Jul 6, 2020, at 10:19 AM, John Kline  wrote:
>>> 
>> 
>> Yep, you’ll need to make your changes to switch to appTemp.  That’s both 
>> a change in index.html.tmpl and in the realtime_updater.inc file.
>> 
>> A new day accumulator gets created at midnight, so I am very interested 
>> in that

Re: [weewx-user] Questions about weewx-loopdata 1.3.x

2020-07-07 Thread John Kline

There was a subtle difference in how I was creating the next day accumulator 
vs. how WeeWX proper is doing it.  I’ve changed that.  Please install 1.3.15 
and let me know how it goes at midnight.

> On Jul 6, 2020, at 10:44 PM, geni08...@gmail.com  
> wrote:
> 
> Jul  7 00:00:01 Wetter-Raspi rsyslogd:  [origin software="rsyslogd" 
> swVersion="8.1901.0" x-pid="295" x-info="https://www.rsyslog.com;] rsyslogd 
> was HUPed
> Jul  7 00:00:01 Wetter-Raspi systemd[1]: logrotate.service: Succeeded.
> Jul  7 00:00:01 Wetter-Raspi systemd[1]: Started Rotate log files.
> Jul  7 00:00:02 Wetter-Raspi systemd[1]: man-db.service: Succeeded.
> Jul  7 00:00:02 Wetter-Raspi systemd[1]: Started Daily man-db regeneration.
> Jul  7 00:00:15 Wetter-Raspi weewx[18476] INFO weewx.manager: Added record 
> 2020-07-07 00:00:00 CEST (1594072800) to database 'weewx'
> Jul  7 00:00:15 Wetter-Raspi weewx[18476] INFO weewx.manager: Added record 
> 2020-07-07 00:00:00 CEST (1594072800) to daily summary in 'weewx'
> 
> 
> geni08...@gmail.com schrieb am Dienstag, 7. Juli 2020 um 07:39:52 UTC+2:
>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata:   
>> Traceback (most recent call last):
>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata:    
>>  File "/usr/share/weewx/user/loopdata.py", line 365, in process_queue
>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata:    
>>self.day_accum.addRecord(pkt)
>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata:    
>>  File "/usr/share/weewx/weewx/accum.py", line 423, in addRecord
>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata:    
>>% (record['dateTime'], self.timespan))
>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata:   
>> weewx.accum.OutOfSpan: Attempt to add out-of-interval record (1594072801) to 
>> timespan ([2020-07-06 00:00:00 CEST (1593986400) -> 2020-07-07 00:00:00 CEST 
>> (1594072800)])
>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata:   
>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata:   
>> During handling of the above exception, another exception occurred:
>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata:   
>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata:   
>> Traceback (most recent call last):
>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata:    
>>  File "/usr/share/weewx/user/loopdata.py", line 370, in process_queue
>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata:    
>>self.day_accum.addRecord(pkt)
>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata:    
>>  File "/usr/share/weewx/weewx/accum.py", line 423, in addRecord
>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata:    
>>% (record['dateTime'], self.timespan))
>> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata:   
>> weewx.accum.OutOfSpan: Attempt to add out-of-interval record (1594072801) to 
>> timespan ([2020-07-06 00:00:00 CEST (1593986400) -> 2020-07-07 00:00:00 CEST 
>> (1594072800)])
>> Jul  7 00:00:00 Wetter-Raspi systemd[1]: Starting Rotate log files...
>> Jul  7 00:00:00 Wetter-Raspi systemd[1]: Starting Daily man-db 
>> regeneration...
>> 
>> 
>> jo...@johnkline.com schrieb am Dienstag, 7. Juli 2020 um 07:09:28 UTC+2:
>>> It looks like loopdata stopped again at midnight (I looked at your sight).
>>> 
>>> I think it likely that something in the packet at midnight is causing this. 
>>>  Loopdata does print a stack trace on an unexpected exception before 
>>> exiting.  Would you have a look in the log and send it?
>>> 
>>> If the stack trace doesn’t give me the info I need, I will send you an 
>>> instrumented version of loopdata.py that will, among other things, log loop 
>>> packets around midnight.
>>> 
> On Jul 6, 2020, at 10:26 AM, John Kline  wrote:
> 
 
>>> 
 BTW, I should probably make dewpoint position on the weatherboard 
 configurable between dewpoint and appTemp.  That would save you from 
 having to hack on the javaascript.
 
 Also, I could make the legend configurable for translation.
 
 I’ll try to do that today or tomorrow.
 
>> On Jul 6, 2020, at 10:19 AM, John Kline  wrote:
>> 
> 
> Yep, you’ll need to make your changes to switch to appTemp.  That’s both 
> a change in index.html.tmpl and in the realtime_updater.inc file.
> 
> A new day accumulator gets created at midnight, so I am very interested 
> in that loopdata crash.  Do you have a stacktrace in the log?  Please 
> send what you have.  If it’s not descriptive enough, I’ll update loopdata 
> to provide more info on that crash.
> 
>> On Jul 6, 2020, at 8:20 AM, geni08...@gmail.com  
>> wrote:
>> 
>> 
>> I have replaced the

Re: [weewx-user] Questions about weewx-loopdata 1.3.x

2020-07-06 Thread geni08...@gmail.com

Jul  7 00:00:01 Wetter-Raspi rsyslogd:  [origin software="rsyslogd" 
swVersion="8.1901.0" x-pid="295" x-info="https://www.rsyslog.com;] rsyslogd 
was HUPed
Jul  7 00:00:01 Wetter-Raspi systemd[1]: logrotate.service: Succeeded.
Jul  7 00:00:01 Wetter-Raspi systemd[1]: Started Rotate log files.
Jul  7 00:00:02 Wetter-Raspi systemd[1]: man-db.service: Succeeded.
Jul  7 00:00:02 Wetter-Raspi systemd[1]: Started Daily man-db regeneration.
Jul  7 00:00:15 Wetter-Raspi weewx[18476] INFO weewx.manager: Added record 
2020-07-07 00:00:00 CEST (1594072800) to database 'weewx'
Jul  7 00:00:15 Wetter-Raspi weewx[18476] INFO weewx.manager: Added record 
2020-07-07 00:00:00 CEST (1594072800) to daily summary in 'weewx'


geni08...@gmail.com schrieb am Dienstag, 7. Juli 2020 um 07:39:52 UTC+2:

> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata: 
>   Traceback (most recent call last):
> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata: 
> File "/usr/share/weewx/user/loopdata.py", line 365, in process_queue
> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata: 
>   self.day_accum.addRecord(pkt)
> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata: 
> File "/usr/share/weewx/weewx/accum.py", line 423, in addRecord
> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata: 
>   % (record['dateTime'], self.timespan))
> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata: 
>   weewx.accum.OutOfSpan: Attempt to add out-of-interval record 
> (1594072801) to timespan ([2020-07-06 00:00:00 CEST (1593986400) -> 
> 2020-07-07 00:00:00 CEST (1594072800)])
> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata: 
>   
> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata: 
>   During handling of the above exception, another exception occurred:
> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata: 
>   
> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata: 
>   Traceback (most recent call last):
> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata: 
> File "/usr/share/weewx/user/loopdata.py", line 370, in process_queue
> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata: 
>   self.day_accum.addRecord(pkt)
> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata: 
> File "/usr/share/weewx/weewx/accum.py", line 423, in addRecord
> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata: 
>   % (record['dateTime'], self.timespan))
> Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata: 
>   weewx.accum.OutOfSpan: Attempt to add out-of-interval record 
> (1594072801) to timespan ([2020-07-06 00:00:00 CEST (1593986400) -> 
> 2020-07-07 00:00:00 CEST (1594072800)])
> Jul  7 00:00:00 Wetter-Raspi systemd[1]: Starting Rotate log files...
> Jul  7 00:00:00 Wetter-Raspi systemd[1]: Starting Daily man-db 
> regeneration...
>
>
> jo...@johnkline.com schrieb am Dienstag, 7. Juli 2020 um 07:09:28 UTC+2:
>
>> It looks like loopdata stopped again at midnight (I looked at your sight).
>>
>> I think it likely that something in the packet at midnight is causing 
>> this.  Loopdata does print a stack trace on an unexpected exception before 
>> exiting.  Would you have a look in the log and send it?
>>
>> If the stack trace doesn’t give me the info I need, I will send you an 
>> instrumented version of loopdata.py that will, among other things, log loop 
>> packets around midnight.
>>
>> On Jul 6, 2020, at 10:26 AM, John Kline  wrote:
>>
>> 
>>
>> BTW, I should probably make dewpoint position on the weatherboard 
>> configurable between dewpoint and appTemp.  That would save you from having 
>> to hack on the javaascript.
>>
>> Also, I could make the legend configurable for translation.
>>
>> I’ll try to do that today or tomorrow.
>>
>> On Jul 6, 2020, at 10:19 AM, John Kline  wrote:
>>
>> 
>> Yep, you’ll need to make your changes to switch to appTemp.  That’s both 
>> a change in index.html.tmpl and in the realtime_updater.inc file.
>>
>> A new day accumulator gets created at midnight, so I am very interested 
>> in that loopdata crash.  Do you have a stacktrace in the log?  Please send 
>> what you have.  If it’s not descriptive enough, I’ll update loopdata to 
>> provide more info on that crash.
>>
>> On Jul 6, 2020, at 8:20 AM, geni08...@gmail.com  
>> wrote:
>>
>>  
>> I have replaced the index.html.tmpl with an old version! However, the 
>> appTemp is not yet running. Loopdate also crashed at midnight, so watch 
>> that today.
>>
>> jo...@johnkline.com schrieb am Montag, 6. Juli 2020 um 15:50:11 UTC+2:
>>
>>> Now that I’m up for the morning, I went to look at your WeatherBoard 
>>> page to see what the JavaScript error was, but I see that it is up and 
>>> runnning!
>>>
>>> On Jul 6, 2020, at 3:44 AM, John

Re: [weewx-user] Questions about weewx-loopdata 1.3.x

2020-07-06 Thread geni08...@gmail.com

Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata:   
Traceback (most recent call last):
Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata: 
File "/usr/share/weewx/user/loopdata.py", line 365, in process_queue
Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata: 
  self.day_accum.addRecord(pkt)
Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata: 
File "/usr/share/weewx/weewx/accum.py", line 423, in addRecord
Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata: 
  % (record['dateTime'], self.timespan))
Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata:   
weewx.accum.OutOfSpan: Attempt to add out-of-interval record (1594072801) 
to timespan ([2020-07-06 00:00:00 CEST (1593986400) -> 2020-07-07 00:00:00 
CEST (1594072800)])
Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata:   
Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata:   
During handling of the above exception, another exception occurred:
Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata:   
Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata:   
Traceback (most recent call last):
Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata: 
File "/usr/share/weewx/user/loopdata.py", line 370, in process_queue
Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata: 
  self.day_accum.addRecord(pkt)
Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata: 
File "/usr/share/weewx/weewx/accum.py", line 423, in addRecord
Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata: 
  % (record['dateTime'], self.timespan))
Jul  7 00:00:00 Wetter-Raspi weewx[18476] CRITICAL user.loopdata:   
weewx.accum.OutOfSpan: Attempt to add out-of-interval record (1594072801) 
to timespan ([2020-07-06 00:00:00 CEST (1593986400) -> 2020-07-07 00:00:00 
CEST (1594072800)])
Jul  7 00:00:00 Wetter-Raspi systemd[1]: Starting Rotate log files...
Jul  7 00:00:00 Wetter-Raspi systemd[1]: Starting Daily man-db 
regeneration...


jo...@johnkline.com schrieb am Dienstag, 7. Juli 2020 um 07:09:28 UTC+2:

> It looks like loopdata stopped again at midnight (I looked at your sight).
>
> I think it likely that something in the packet at midnight is causing 
> this.  Loopdata does print a stack trace on an unexpected exception before 
> exiting.  Would you have a look in the log and send it?
>
> If the stack trace doesn’t give me the info I need, I will send you an 
> instrumented version of loopdata.py that will, among other things, log loop 
> packets around midnight.
>
> On Jul 6, 2020, at 10:26 AM, John Kline  wrote:
>
> 
>
> BTW, I should probably make dewpoint position on the weatherboard 
> configurable between dewpoint and appTemp.  That would save you from having 
> to hack on the javaascript.
>
> Also, I could make the legend configurable for translation.
>
> I’ll try to do that today or tomorrow.
>
> On Jul 6, 2020, at 10:19 AM, John Kline  wrote:
>
> 
> Yep, you’ll need to make your changes to switch to appTemp.  That’s both a 
> change in index.html.tmpl and in the realtime_updater.inc file.
>
> A new day accumulator gets created at midnight, so I am very interested in 
> that loopdata crash.  Do you have a stacktrace in the log?  Please send 
> what you have.  If it’s not descriptive enough, I’ll update loopdata to 
> provide more info on that crash.
>
> On Jul 6, 2020, at 8:20 AM, geni08...@gmail.com  
> wrote:
>
>  
> I have replaced the index.html.tmpl with an old version! However, the 
> appTemp is not yet running. Loopdate also crashed at midnight, so watch 
> that today.
>
> jo...@johnkline.com schrieb am Montag, 6. Juli 2020 um 15:50:11 UTC+2:
>
>> Now that I’m up for the morning, I went to look at your WeatherBoard page 
>> to see what the JavaScript error was, but I see that it is up and runnning!
>>
>> On Jul 6, 2020, at 3:44 AM, John Kline  wrote:
>>
>> 
>>
>> Send realtime_updater.inc and weewx.conf.
>> The JavaScript is broken. I’ll have a look.
>>
>> On Jul 5, 2020, at 10:35 PM, geni08...@gmail.com  
>> wrote:
>>
>> I have weewx-loopdata 1.1.13, only the default km_per_hour definition -> 
>> the loop-data.txt is OK.
>> Why is my WeatherBoard not working? Only time is running.
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "weewx-user" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to weewx-user+...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/b24a6c1c-9b40-4c1b-abde-cf1c40d127e2n%40googlegroups.com
>>  
>> 
>> .
>> 
>>
>> -- 
> You received this

Re: [weewx-user] Questions about weewx-loopdata 1.3.x

It looks like loopdata stopped again at midnight (I looked at your sight).

I think it likely that something in the packet at midnight is causing this.  
Loopdata does print a stack trace on an unexpected exception before exiting.  
Would you have a look in the log and send it?

If the stack trace doesn’t give me the info I need, I will send you an 
instrumented version of loopdata.py that will, among other things, log loop 
packets around midnight.

> On Jul 6, 2020, at 10:26 AM, John Kline  wrote:
> 
> 
> BTW, I should probably make dewpoint position on the weatherboard 
> configurable between dewpoint and appTemp.  That would save you from having 
> to hack on the javaascript.
> 
> Also, I could make the legend configurable for translation.
> 
> I’ll try to do that today or tomorrow.
> 
>>> On Jul 6, 2020, at 10:19 AM, John Kline  wrote:
>>> 
>> 
>> Yep, you’ll need to make your changes to switch to appTemp.  That’s both a 
>> change in index.html.tmpl and in the realtime_updater.inc file.
>> 
>> A new day accumulator gets created at midnight, so I am very interested in 
>> that loopdata crash.  Do you have a stacktrace in the log?  Please send what 
>> you have.  If it’s not descriptive enough, I’ll update loopdata to provide 
>> more info on that crash.
>> 
>>> On Jul 6, 2020, at 8:20 AM, geni08...@gmail.com  
>>> wrote:
>>> 
>>> 
>>> I have replaced the index.html.tmpl with an old version! However, the 
>>> appTemp is not yet running. Loopdate also crashed at midnight, so watch 
>>> that today.
>>> 
>>> jo...@johnkline.com schrieb am Montag, 6. Juli 2020 um 15:50:11 UTC+2:
 Now that I’m up for the morning, I went to look at your WeatherBoard page 
 to see what the JavaScript error was, but I see that it is up and runnning!
 
>> On Jul 6, 2020, at 3:44 AM, John Kline  wrote:
>> 
> 
 
> Send realtime_updater.inc and weewx.conf.
> The JavaScript is broken. I’ll have a look.
> 
>>> On Jul 5, 2020, at 10:35 PM, geni08...@gmail.com  
>>> wrote:
>>> 
>> I have weewx-loopdata 1.1.13, only the default km_per_hour definition 
>> -> the loop-data.txt is OK.
>> Why is my WeatherBoard not working? Only time is running.
>> 
>> -- 
>> You received this message because you are subscribed to the Google 
>> Groups "weewx-user" group.
>> To unsubscribe from this group and stop receiving emails from it, send 
>> an email to weewx-user+...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/b24a6c1c-9b40-4c1b-abde-cf1c40d127e2n%40googlegroups.com.
>> 
>>> 
>>> -- 
>>> You received this message because you are subscribed to the Google Groups 
>>> "weewx-user" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>> email to weewx-user+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/weewx-user/441af783-906b-4497-a023-733da7ec6cc3n%40googlegroups.com.

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/2B027296-ACA8-41CB-BD2A-9E62985F155D%40johnkline.com.

Re: [weewx-user] Questions about weewx-loopdata 1.3.x

BTW, I should probably make dewpoint position on the weatherboard configurable 
between dewpoint and appTemp.  That would save you from having to hack on the 
javaascript.

Also, I could make the legend configurable for translation.

I’ll try to do that today or tomorrow.

> On Jul 6, 2020, at 10:19 AM, John Kline  wrote:
> 
> 
> Yep, you’ll need to make your changes to switch to appTemp.  That’s both a 
> change in index.html.tmpl and in the realtime_updater.inc file.
> 
> A new day accumulator gets created at midnight, so I am very interested in 
> that loopdata crash.  Do you have a stacktrace in the log?  Please send what 
> you have.  If it’s not descriptive enough, I’ll update loopdata to provide 
> more info on that crash.
> 
>>> On Jul 6, 2020, at 8:20 AM, geni08...@gmail.com  
>>> wrote:
>>> 
>> 
>> I have replaced the index.html.tmpl with an old version! However, the 
>> appTemp is not yet running. Loopdate also crashed at midnight, so watch that 
>> today.
>> 
>> jo...@johnkline.com schrieb am Montag, 6. Juli 2020 um 15:50:11 UTC+2:
>>> Now that I’m up for the morning, I went to look at your WeatherBoard page 
>>> to see what the JavaScript error was, but I see that it is up and runnning!
>>> 
> On Jul 6, 2020, at 3:44 AM, John Kline  wrote:
> 
 
>>> 
 Send realtime_updater.inc and weewx.conf.
 The JavaScript is broken. I’ll have a look.
 
>> On Jul 5, 2020, at 10:35 PM, geni08...@gmail.com  
>> wrote:
>> 
> I have weewx-loopdata 1.1.13, only the default km_per_hour definition -> 
> the loop-data.txt is OK.
> Why is my WeatherBoard not working? Only time is running.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "weewx-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to weewx-user+...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/b24a6c1c-9b40-4c1b-abde-cf1c40d127e2n%40googlegroups.com.
> 
>> 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "weewx-user" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to weewx-user+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/441af783-906b-4497-a023-733da7ec6cc3n%40googlegroups.com.

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

Re: [weewx-user] Questions about weewx-loopdata 1.3.x

Yep, you’ll need to make your changes to switch to appTemp.  That’s both a 
change in index.html.tmpl and in the realtime_updater.inc file.

A new day accumulator gets created at midnight, so I am very interested in that 
loopdata crash.  Do you have a stacktrace in the log?  Please send what you 
have.  If it’s not descriptive enough, I’ll update loopdata to provide more 
info on that crash.

> On Jul 6, 2020, at 8:20 AM, geni08...@gmail.com  
> wrote:
> 
> 
> I have replaced the index.html.tmpl with an old version! However, the appTemp 
> is not yet running. Loopdate also crashed at midnight, so watch that today.
> 
> jo...@johnkline.com schrieb am Montag, 6. Juli 2020 um 15:50:11 UTC+2:
>> Now that I’m up for the morning, I went to look at your WeatherBoard page to 
>> see what the JavaScript error was, but I see that it is up and runnning!
>> 
 On Jul 6, 2020, at 3:44 AM, John Kline  wrote:
 
>>> 
>> 
>>> Send realtime_updater.inc and weewx.conf.
>>> The JavaScript is broken. I’ll have a look.
>>> 
> On Jul 5, 2020, at 10:35 PM, geni08...@gmail.com  
> wrote:
> 
 I have weewx-loopdata 1.1.13, only the default km_per_hour definition -> 
 the loop-data.txt is OK.
 Why is my WeatherBoard not working? Only time is running.
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 "weewx-user" group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to weewx-user+...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/weewx-user/b24a6c1c-9b40-4c1b-abde-cf1c40d127e2n%40googlegroups.com.
 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "weewx-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to weewx-user+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/441af783-906b-4497-a023-733da7ec6cc3n%40googlegroups.com.

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/5130C817-F921-4DA1-9BCE-5BE33B92235E%40johnkline.com.

Re: [weewx-user] Questions about weewx-loopdata 1.3.x

2020-07-06 Thread geni08...@gmail.com

 I have replaced the index.html.tmpl with an old version! However, the 
appTemp is not yet running. Loopdate also crashed at midnight, so watch 
that today.

jo...@johnkline.com schrieb am Montag, 6. Juli 2020 um 15:50:11 UTC+2:

> Now that I’m up for the morning, I went to look at your WeatherBoard page 
> to see what the JavaScript error was, but I see that it is up and runnning!
>
> On Jul 6, 2020, at 3:44 AM, John Kline  wrote:
>
> 
>
> Send realtime_updater.inc and weewx.conf.
> The JavaScript is broken. I’ll have a look.
>
> On Jul 5, 2020, at 10:35 PM, geni08...@gmail.com  
> wrote:
>
> I have weewx-loopdata 1.1.13, only the default km_per_hour definition -> 
> the loop-data.txt is OK.
> Why is my WeatherBoard not working? Only time is running.
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "weewx-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to weewx-user+...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/b24a6c1c-9b40-4c1b-abde-cf1c40d127e2n%40googlegroups.com
>  
> 
> .
> 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/441af783-906b-4497-a023-733da7ec6cc3n%40googlegroups.com.

Re: [weewx-user] Questions about weewx-loopdata 1.3.x

Now that I’m up for the morning, I went to look at your WeatherBoard page to 
see what the JavaScript error was, but I see that it is up and runnning!

> On Jul 6, 2020, at 3:44 AM, John Kline  wrote:
> 
> 
> Send realtime_updater.inc and weewx.conf.
> The JavaScript is broken. I’ll have a look.
> 
>>> On Jul 5, 2020, at 10:35 PM, geni08...@gmail.com  
>>> wrote:
>>> 
>> I have weewx-loopdata 1.1.13, only the default km_per_hour definition -> 
>> the loop-data.txt is OK.
>> Why is my WeatherBoard not working? Only time is running.
>> 
>> -- 
>> 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/b24a6c1c-9b40-4c1b-abde-cf1c40d127e2n%40googlegroups.com.
>> 

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/242F361C-7CE7-4A21-9E26-6686C7EA5DA2%40johnkline.com.

Re: [weewx-user] Questions about weewx-loopdata 1.3.x

Send realtime_updater.inc and weewx.conf.
The JavaScript is broken. I’ll have a look.

> On Jul 5, 2020, at 10:35 PM, geni08...@gmail.com  
> wrote:
> 
> I have weewx-loopdata 1.1.13, only the default km_per_hour definition -> the 
> loop-data.txt is OK.
> Why is my WeatherBoard not working? Only time is running.
> 
> -- 
> 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/b24a6c1c-9b40-4c1b-abde-cf1c40d127e2n%40googlegroups.com.
> 

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/A1F8DFE5-DF0D-4E4A-96C4-7268811B719F%40johnkline.com.

Re: [weewx-user] Questions about weewx-loopdata 1.3.x

2020-07-05 Thread geni08...@gmail.com

I have weewx-loopdata 1.1.13, only the default km_per_hour definition -> 
the loop-data.txt is OK.
Why is my WeatherBoard not working? Only time is running.

-- 
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/b24a6c1c-9b40-4c1b-abde-cf1c40d127e2n%40googlegroups.com.
## Copyright (C)2020 by John A Kline (j...@johnkline.com)
## Distributed under the terms of the GNU Public License (GPLv3)
## See LICENSE for your rights.
#errorCatcher Echo
#encoding UTF-8


  



#if $Extras.has_key('meta_title')
  $Extras.meta_title
#else
  WeatherBoard$station.location
#end if


  #centered {
width:100%;
margin: auto;
  }

  
  
#include "analytics.inc"
#include "realtime_updater.inc"

  

  
#if $Extras.has_key('logo') and $Extras.logo != ''
  

  
#else
  
  
#end if

  
#if $Extras.has_key('title')
  $Extras.title
#else
  WeatherBoard
#end if
  
  
#if $Extras.has_key('subtitle')
  $Extras.subtitle
#else
  Updated continuously.
#end if
  


  

  

  



  

  


  
  

  
$current.outTemp$current.appTemp
  
  
$current.windSpeed
 $current.windDir.ordinal_compass
  
  


  
  
$day.rain.sum$current.rainRate
  

  

  

#include "footer.inc"

Re: [weewx-user] Questions about weewx-loopdata 1.3.x

1.3.9 has been pushed.

I would appreciate it if you would remove the lines I asked you to add so that 
you can test that this is no longer needed.
>>> 
>>> [[[Units]]]
>>> Labels
>>> km_per_hour = " km/h"


>> On Jul 5, 2020, at 7:08 AM, John Kline  wrote:
> 
> OK, I see what I need to do.  1.3.9 will fix this.  Life calls at present, 
> but I’ll fix and push within a few hours.  In the meantime, the change below 
> will get you get you km/h will tide you over.
> 
> BTW, thank you for trying this extension.  You have identified quite a few 
> problems and I appreciate that.
> 
>>> On Jul 5, 2020, at 6:31 AM, John Kline  wrote:
>> 
>> Not too interesting.  I see it on the WeatherBoard report here:
>> https://affolter.familyds.net/wetter/weatherboard/
>> 
>> You no longer are producing it, but the JavaScript is happily fetching the 
>> latest values.
>> 
>> As for why you don’t see km/h, I obviously am not managing the dictionaries 
>> correctly.  I will have to fix that, but in the meantime, please verify that 
>> it works if you add the following under SeasonsReport.
>> 
 [[[Units]]]
 Labels
 km_per_hour = " km/h"
>> 
>> 
 On Jul 5, 2020, at 6:11 AM, Geni 0815  wrote:
>>> 
>>> Now it gets interesting, where do you see kph on my season page?
>>> 
>>> Am Sonntag, 5. Juli 2020 14:18:00 UTC+2 schrieb John Kline:
 
 That’s great that you are up and running.  I had a look at your 
 WeatherBoard report and indeed I see kph.
 
 I just tried this myself.  I targeted SeasonsReport (since that is what 
 you did) and added the km/h and it’s working for me.  Let’s compare our 
 SeasonsReport entries.
 
 I have the following.  Note the Labels entry with km/h in quotes with a 
 leading space.
 Please send what you have for this section.
 
 [[SeasonsReport]]
 # The SeasonsReport uses the 'Seasons' skin, which contains the
 # images, templates and plots for the report.
 skin = Seasons
 enable = true
 [[[Units]]]
 StringFormats
 mile_per_hour = %.1f
 degree_C = %.1f
 km_per_hour = %.1f
 degree_F = %.1f
 Labels
 km_per_hour = " km/h"
 
>> On Jul 5, 2020, at 4:58 AM, Geni 0815  wrote:
> 
> @John: I have new installed the weewx-loopdata here my settings in 
> weewx.conf. In my SeasonsReport the field km_per_hour is correctly 
> displayed with km/h.
> appended a loop_data.txt and kph is still in it.
> 
> How does your built-in tests for conversions and formatting work?
> 
> [LoopData]
> [[FileSpec]]
> loop_data_dir = /home/pi/wetter/loop-data
> filename = loop-data.txt
> [[Formatting]]
> target_report = SeasonsReport
> [[RsyncSpec]]
> enable = false
> remote_server = www.foobar.com
> remote_user = root
> remote_dir = /home/weewx/loop-data
> compress = false
> log_success = false
> ssh_options = -o ConnectTimeout=1
> timeout = 1
> skip_if_older_than = 3
> [[Include]]
> fields = dateTime, windSpeed, COMPASS_windDir, 
> DESC_barometerRate, FMT_barometer, FMT_SUM_rain, FMT_dewpoint, 
> FMT_heatindex, FMT_outHumidity, FMT_outTemp, FMT_rain, FMT_rainRate, 
> FMT_windchill, FMT_windSpeed, FMT_HI_windGust, FMT_10mMaxGust, FMT_appTemp
> [[Rename]]
> 
> -- 
> 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...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/34cc8d8a-4be6-48d6-9503-505d399d10ceo%40googlegroups.com.
> 
>>> 
>>> -- 
>>> You received this message because you are subscribed to the Google Groups 
>>> "weewx-user" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>> email to weewx-user+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/weewx-user/9d702cab-41cf-4e8b-9e8f-f3f6464f9f50o%40googlegroups.com.
>>> 

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/0E24277C-5143-4DDD-AE53-157D17D8F065%40johnkline.com.

Re: [weewx-user] Questions about weewx-loopdata 1.3.x

OK, I see what I need to do.  1.3.9 will fix this.  Life calls at present, but 
I’ll fix and push within a few hours.  In the meantime, the change below will 
get you get you km/h will tide you over.

BTW, thank you for trying this extension.  You have identified quite a few 
problems and I appreciate that.

> On Jul 5, 2020, at 6:31 AM, John Kline  wrote:
> 
> 
> Not too interesting.  I see it on the WeatherBoard report here:
> https://affolter.familyds.net/wetter/weatherboard/
> 
> You no longer are producing it, but the JavaScript is happily fetching the 
> latest values.
> 
> As for why you don’t see km/h, I obviously am not managing the dictionaries 
> correctly.  I will have to fix that, but in the meantime, please verify that 
> it works if you add the following under SeasonsReport.
> 
>>> [[[Units]]]
>>> Labels
>>> km_per_hour = " km/h"
> 
> 
>>> On Jul 5, 2020, at 6:11 AM, Geni 0815  wrote:
>>> 
>> 
>> Now it gets interesting, where do you see kph on my season page?
>> 
>> Am Sonntag, 5. Juli 2020 14:18:00 UTC+2 schrieb John Kline:
>>> 
>>> That’s great that you are up and running.  I had a look at your 
>>> WeatherBoard report and indeed I see kph.
>>> 
>>> I just tried this myself.  I targeted SeasonsReport (since that is what you 
>>> did) and added the km/h and it’s working for me.  Let’s compare our 
>>> SeasonsReport entries.
>>> 
>>> I have the following.  Note the Labels entry with km/h in quotes with a 
>>> leading space.
>>> Please send what you have for this section.
>>> 
>>> [[SeasonsReport]]
>>> # The SeasonsReport uses the 'Seasons' skin, which contains the
>>> # images, templates and plots for the report.
>>> skin = Seasons
>>> enable = true
>>> [[[Units]]]
>>> StringFormats
>>> mile_per_hour = %.1f
>>> degree_C = %.1f
>>> km_per_hour = %.1f
>>> degree_F = %.1f
>>> Labels
>>> km_per_hour = " km/h"
>>> 
> On Jul 5, 2020, at 4:58 AM, Geni 0815  wrote:
> 
 
 @John: I have new installed the weewx-loopdata here my settings in 
 weewx.conf. In my SeasonsReport the field km_per_hour is correctly 
 displayed with km/h.
 appended a loop_data.txt and kph is still in it.
 
 How does your built-in tests for conversions and formatting work?
 
 [LoopData]
 [[FileSpec]]
 loop_data_dir = /home/pi/wetter/loop-data
 filename = loop-data.txt
 [[Formatting]]
 target_report = SeasonsReport
 [[RsyncSpec]]
 enable = false
 remote_server = www.foobar.com
 remote_user = root
 remote_dir = /home/weewx/loop-data
 compress = false
 log_success = false
 ssh_options = -o ConnectTimeout=1
 timeout = 1
 skip_if_older_than = 3
 [[Include]]
 fields = dateTime, windSpeed, COMPASS_windDir, DESC_barometerRate, 
 FMT_barometer, FMT_SUM_rain, FMT_dewpoint, FMT_heatindex, FMT_outHumidity, 
 FMT_outTemp, FMT_rain, FMT_rainRate, FMT_windchill, FMT_windSpeed, 
 FMT_HI_windGust, FMT_10mMaxGust, FMT_appTemp
 [[Rename]]
 
 -- 
 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...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/weewx-user/34cc8d8a-4be6-48d6-9503-505d399d10ceo%40googlegroups.com.
 
>> 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "weewx-user" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to weewx-user+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/9d702cab-41cf-4e8b-9e8f-f3f6464f9f50o%40googlegroups.com.
>> 

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/2C744CAA-BEFC-493A-957A-25C4B8270C45%40johnkline.com.

Re: [weewx-user] Questions about weewx-loopdata 1.3.x

Not too interesting.  I see it on the WeatherBoard report here:
https://affolter.familyds.net/wetter/weatherboard/

You no longer are producing it, but the JavaScript is happily fetching the 
latest values.

As for why you don’t see km/h, I obviously am not managing the dictionaries 
correctly.  I will have to fix that, but in the meantime, please verify that it 
works if you add the following under SeasonsReport.

>> [[[Units]]]
>> Labels
>> km_per_hour = " km/h"


> On Jul 5, 2020, at 6:11 AM, Geni 0815  wrote:
> 
> 
> Now it gets interesting, where do you see kph on my season page?
> 
> Am Sonntag, 5. Juli 2020 14:18:00 UTC+2 schrieb John Kline:
>> 
>> That’s great that you are up and running.  I had a look at your WeatherBoard 
>> report and indeed I see kph.
>> 
>> I just tried this myself.  I targeted SeasonsReport (since that is what you 
>> did) and added the km/h and it’s working for me.  Let’s compare our 
>> SeasonsReport entries.
>> 
>> I have the following.  Note the Labels entry with km/h in quotes with a 
>> leading space.
>> Please send what you have for this section.
>> 
>> [[SeasonsReport]]
>> # The SeasonsReport uses the 'Seasons' skin, which contains the
>> # images, templates and plots for the report.
>> skin = Seasons
>> enable = true
>> [[[Units]]]
>> StringFormats
>> mile_per_hour = %.1f
>> degree_C = %.1f
>> km_per_hour = %.1f
>> degree_F = %.1f
>> Labels
>> km_per_hour = " km/h"
>> 
 On Jul 5, 2020, at 4:58 AM, Geni 0815  wrote:
 
>>> 
>>> @John: I have new installed the weewx-loopdata here my settings in 
>>> weewx.conf. In my SeasonsReport the field km_per_hour is correctly 
>>> displayed with km/h.
>>> appended a loop_data.txt and kph is still in it.
>>> 
>>> How does your built-in tests for conversions and formatting work?
>>> 
>>> [LoopData]
>>> [[FileSpec]]
>>> loop_data_dir = /home/pi/wetter/loop-data
>>> filename = loop-data.txt
>>> [[Formatting]]
>>> target_report = SeasonsReport
>>> [[RsyncSpec]]
>>> enable = false
>>> remote_server = www.foobar.com
>>> remote_user = root
>>> remote_dir = /home/weewx/loop-data
>>> compress = false
>>> log_success = false
>>> ssh_options = -o ConnectTimeout=1
>>> timeout = 1
>>> skip_if_older_than = 3
>>> [[Include]]
>>> fields = dateTime, windSpeed, COMPASS_windDir, DESC_barometerRate, 
>>> FMT_barometer, FMT_SUM_rain, FMT_dewpoint, FMT_heatindex, FMT_outHumidity, 
>>> FMT_outTemp, FMT_rain, FMT_rainRate, FMT_windchill, FMT_windSpeed, 
>>> FMT_HI_windGust, FMT_10mMaxGust, FMT_appTemp
>>> [[Rename]]
>>> 
>>> -- 
>>> 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...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/weewx-user/34cc8d8a-4be6-48d6-9503-505d399d10ceo%40googlegroups.com.
>>> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "weewx-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to weewx-user+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/9d702cab-41cf-4e8b-9e8f-f3f6464f9f50o%40googlegroups.com.
> 

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/27471A72-D2AC-4E03-8FFB-8B631767EC23%40johnkline.com.

Re: [weewx-user] Questions about weewx-loopdata 1.3.x

2020-07-05 Thread Geni 0815

Now it gets interesting, where do you see kph on my season page?

Am Sonntag, 5. Juli 2020 14:18:00 UTC+2 schrieb John Kline:
>
> That’s great that you are up and running.  I had a look at your 
> WeatherBoard report and indeed I see kph.
>
> I just tried this myself.  I targeted SeasonsReport (since that is what 
> you did) and added the km/h and it’s working for me.  Let’s compare our 
> SeasonsReport entries.
>
> I have the following.  Note the Labels entry with km/h in quotes with a 
> leading space.
> Please send what you have for this section.
>
> [[SeasonsReport]]
> # The SeasonsReport uses the 'Seasons' skin, which contains the
> # images, templates and plots for the report.
> skin = Seasons
> enable = true
> [[[Units]]]
> StringFormats
> mile_per_hour = %.1f
> degree_C = %.1f
> km_per_hour = %.1f
> degree_F = %.1f
> Labels
> km_per_hour = " km/h"
>
> On Jul 5, 2020, at 4:58 AM, Geni 0815 > 
> wrote:
>
> 
> @John: I have new installed the weewx-loopdata here my settings in 
> weewx.conf. In my SeasonsReport 
> the field 
> *km_per_hour 
> *is correctly displayed with km/h.
> appended a loop_data.txt and kph is still in it.
>
> How does your built-in tests for conversions and formatting work?
>
> [LoopData]
> [[FileSpec]]
> loop_data_dir = /home/pi/wetter/loop-data
> filename = loop-data.txt
> [[Formatting]]
> target_report = SeasonsReport
> [[RsyncSpec]]
> enable = false
> remote_server = www.foobar.com
> remote_user = root
> remote_dir = /home/weewx/loop-data
> compress = false
> log_success = false
> ssh_options = -o ConnectTimeout=1
> timeout = 1
> skip_if_older_than = 3
> [[Include]]
> fields = dateTime, windSpeed, COMPASS_windDir, DESC_barometerRate, 
> FMT_barometer, FMT_SUM_rain, FMT_dewpoint, FMT_heatindex, FMT_outHumidity, 
> FMT_outTemp, FMT_rain, FMT_rainRate, FMT_windchill, FMT_windSpeed, 
> FMT_HI_windGust, FMT_10mMaxGust, FMT_appTemp
> [[Rename]]
>
> -- 
> 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...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/34cc8d8a-4be6-48d6-9503-505d399d10ceo%40googlegroups.com
>  
> 
> .
> 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/9d702cab-41cf-4e8b-9e8f-f3f6464f9f50o%40googlegroups.com.
# WEEWX CONFIGURATION FILE
# modify ea 26.12.2019 MariaDB 10 aktivieren mit DB weewx
# 27.12.2019 Wechsel Raspi-HW zu 3+
# 29.12.2019 
# Copyright (c) 2009-2019 Tom Keffer 
# See the file LICENSE.txt for your rights.
# 17.06.2020 Belchertown Skin
# 05.07.2020 HTML_ROOT = /home/pi/wetter als default dadurch ist kein FTP mehr 
notwendig
# 05.06.2020 loop-data, weatherboard
##

# This section is for general configuration information.

# Set to 1 for extra debug info, otherwise comment it out or set to zero
debug = 0

# Root directory of the weewx data file hierarchy for this station
WEEWX_ROOT = /

# Whether to log successful operations
log_success = False

# Whether to log unsuccessful operations
log_failure = True

# How long to wait before timing out a socket (FTP, HTTP) connection
socket_timeout = 20

# Do not modify this. It is used when installing and updating weewx.
version = 4.1.1

##

#   This section is for information about the station.

[Station]

# Description of the station location
location = "Wetterstation Buttwil, Schweiz"

# Latitude and longitude in decimal degrees
latitude = 47.2667
longitude = 8.3078

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

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

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

# The start of the rain year (1=January; 10=October, etc.). This is
# downloaded from

Re: [weewx-user] Questions about weewx-loopdata 1.3.x