Re: [weewx-user] Re: Problem during fixing of potential corrupt database

['Michael Waldor' via weewx-user]

Finally I could resolve my problem: Following Oscar's hint from 
https://groups.google.com/g/weewx-user/c/PJuWj35o8TM I could rebuild my 
database. Since I did the sqlite3 runs on my linux laptop with a local SSD, 
the runtime for 5years of data was ~1h. Additionally I did optimize the DB 
by applying VACUUM;. Even my merge with some data from one week ago was 
successful.

Anotherr hint: I also checked the versions of sqlite3 @raspberry and @linux 
laptop/tumbleweed. There are differences, but the different versions are 
not related with my problem.

And now I (hopefully) have again a clean weewx.sdb

Thanks for your quick help, Michael

Michael Waldor schrieb am Mittwoch, 20. März 2024 um 15:46:04 UTC+1:

> That's my mystery: There are no bad datetime entries at all.
>
> But after .recover I get many bad entries with completely wrong datetimes 
> (only a handfull) and with binary content. Thus .recover seems to have 
> failed.
>
> Currently I'm trying to rebuild the database using the description from 
> Oscar (see previous post above). It runs for ~1h and creates an sdb twice 
> the size of the original one, but without defect data. But I wonder, why 
> its size has increased by ~2. I could fix that by the sqlite3 command 
> VACUUM;
>
> Next step will be to merge some data (my original plan), and after ~1h or 
> so I'll know more.
> michael.k...@gmx.at schrieb am Mittwoch, 20. März 2024 um 14:21:01 UTC+1:
>
>> How many obvious bad timestamp values do you have? If there are only few, 
>> remove the lines from the database and see if you get along with it.
>>
>> Michael Waldor schrieb am Mittwoch, 20. März 2024 um 14:13:54 UTC+1:
>>
>>> Yes, I do have backups. But which one to use? I do not know WHEN the 
>>> potential error might have occured. I even don't know IF there is an error. 
>>> As I wrote, weewxd can happily append data.
>>>
>>> I "only" encounter problems when I try to manually run sqlite3 commands. 
>>> And those indicate that the error might have been introduced in 2018 just 
>>> after 2months of runtime. If that's true I might safely start a fresh DB:-(
>>>
>>> Tom Keffer schrieb am Mittwoch, 20. März 2024 um 14:04:37 UTC+1:
>>>
>>>> If you say the problem is in the database and the database cannot be 
>>>> recovered, I'm not sure there is anything we can offer. What are you 
>>>> looking for from the group?
>>>>
>>>> Hopefully you have a backup database.
>>>>
>>>> On Wed, Mar 20, 2024 at 5:55 AM 'Michael Waldor' via weewx-user <
>>>> weewx...@googlegroups.com> wrote:
>>>>
>>>>> weewx itself works without problems - it can add new entries into 
>>>>> weewx.sdb, and it'S running  right now.
>>>>>
>>>>> But when trying to manually tweak weewx.sdb using sqlite3 commands, 
>>>>> sqlite3 complains. Using .recover seems to make it worse - its sql output 
>>>>> contains some completely broken lines with datetime being 7 or 74 or 
>>>>> unprintable bnary data. Clearly weewxd rejects to use that "recovered" 
>>>>> weewx.sdb.
>>>>>
>>>>> Currently I try to follow 
>>>>> https://groups.google.com/g/weewx-user/c/PJuWj35o8TM
>>>>> Luckily the transformation process should run for ~30min (data is 
>>>>> stored on a SSD).
>>>>>
>>>>> But howto identify the location of a broken weewx.sdb? E.g. if I try 
>>>>> to run the sqlite3 command
>>>>> select date(datetime, 'unixepoch', 'localtime') from archive;
>>>>> It outputs data till 2018-03-31. And then there is an sqlite3 error 
>>>>> message. Only the date conversion seems to fail. If I stay with integer 
>>>>> datetime all data seems to be accessible.
>>>>>
>>>>> Tom Keffer schrieb am Mittwoch, 20. März 2024 um 13:28:57 UTC+1:
>>>>>
>>>>>> This could be anything. We will need to see more of the log to tell. 
>>>>>> For example, you could be asking for a date one month after January 30.
>>>>>>
>>>>>> Set debug=1, restart weewxd, post the log from startup through the 
>>>>>> error.
>>>>>>
>>>>>> On Wed, Mar 20, 2024 at 3:57 AM 'Michael Waldor' via weewx-user <
>>>>>> weewx...@googlegroups.com> wrote:
>>>>>>
>>>>>>> Sadly those mysterious rows only appear AFTER .recover,  they appear 
>>>>>>> within weewx.sql.
>>

Re: [weewx-user] Re: Problem during fixing of potential corrupt database

['Michael Waldor' via weewx-user]

That's my mystery: There are no bad datetime entries at all.

But after .recover I get many bad entries with completely wrong datetimes 
(only a handfull) and with binary content. Thus .recover seems to have 
failed.

Currently I'm trying to rebuild the database using the description from 
Oscar (see previous post above). It runs for ~1h and creates an sdb twice 
the size of the original one, but without defect data. But I wonder, why 
its size has increased by ~2. I could fix that by the sqlite3 command 
VACUUM;

Next step will be to merge some data (my original plan), and after ~1h or 
so I'll know more.
michael.k...@gmx.at schrieb am Mittwoch, 20. März 2024 um 14:21:01 UTC+1:

> How many obvious bad timestamp values do you have? If there are only few, 
> remove the lines from the database and see if you get along with it.
>
> Michael Waldor schrieb am Mittwoch, 20. März 2024 um 14:13:54 UTC+1:
>
>> Yes, I do have backups. But which one to use? I do not know WHEN the 
>> potential error might have occured. I even don't know IF there is an error. 
>> As I wrote, weewxd can happily append data.
>>
>> I "only" encounter problems when I try to manually run sqlite3 commands. 
>> And those indicate that the error might have been introduced in 2018 just 
>> after 2months of runtime. If that's true I might safely start a fresh DB:-(
>>
>> Tom Keffer schrieb am Mittwoch, 20. März 2024 um 14:04:37 UTC+1:
>>
>>> If you say the problem is in the database and the database cannot be 
>>> recovered, I'm not sure there is anything we can offer. What are you 
>>> looking for from the group?
>>>
>>> Hopefully you have a backup database.
>>>
>>> On Wed, Mar 20, 2024 at 5:55 AM 'Michael Waldor' via weewx-user <
>>> weewx...@googlegroups.com> wrote:
>>>
>>>> weewx itself works without problems - it can add new entries into 
>>>> weewx.sdb, and it'S running  right now.
>>>>
>>>> But when trying to manually tweak weewx.sdb using sqlite3 commands, 
>>>> sqlite3 complains. Using .recover seems to make it worse - its sql output 
>>>> contains some completely broken lines with datetime being 7 or 74 or 
>>>> unprintable bnary data. Clearly weewxd rejects to use that "recovered" 
>>>> weewx.sdb.
>>>>
>>>> Currently I try to follow 
>>>> https://groups.google.com/g/weewx-user/c/PJuWj35o8TM
>>>> Luckily the transformation process should run for ~30min (data is 
>>>> stored on a SSD).
>>>>
>>>> But howto identify the location of a broken weewx.sdb? E.g. if I try to 
>>>> run the sqlite3 command
>>>> select date(datetime, 'unixepoch', 'localtime') from archive;
>>>> It outputs data till 2018-03-31. And then there is an sqlite3 error 
>>>> message. Only the date conversion seems to fail. If I stay with integer 
>>>> datetime all data seems to be accessible.
>>>>
>>>> Tom Keffer schrieb am Mittwoch, 20. März 2024 um 13:28:57 UTC+1:
>>>>
>>>>> This could be anything. We will need to see more of the log to tell. 
>>>>> For example, you could be asking for a date one month after January 30.
>>>>>
>>>>> Set debug=1, restart weewxd, post the log from startup through the 
>>>>> error.
>>>>>
>>>>> On Wed, Mar 20, 2024 at 3:57 AM 'Michael Waldor' via weewx-user <
>>>>> weewx...@googlegroups.com> wrote:
>>>>>
>>>>>> Sadly those mysterious rows only appear AFTER .recover,  they appear 
>>>>>> within weewx.sql.
>>>>>> The failing command is
>>>>>>
>>>>>> SELECT count(*)
>>>>>> FROM archive
>>>>>> WHERE
>>>>>>   date(datetime, 'unixepoch', 'localtime')
>>>>>>   between '2024-03-15' and '2024-03-15';
>>>>>>
>>>>>> But that command works fine AFTER .recover.
>>>>>>
>>>>>> The error message from weewxd clearly indicates wrong datetime:
>>>>>>
>>>>>> Mär 20 11:34:37 imurr9 weewxd[15172]: CRITICAL __main__:  
>>>>>>  last_d = datetime.date.fromtimestamp(weeutil.weeutil.startOfArchiveDay(
>>>>>> Mär 20 11:34:37 imurr9 weewxd[15172]: time_dt = 
>>>>>> datetime.datetime.fromtimestamp(time_ts)
>>>>>> Mär 20 11:34:37 imurr9 weewxd[15172]: OverflowError: timestamp out of 
>>>>>> range for platform tim

Re: [weewx-user] Re: Problem during fixing of potential corrupt database

['Michael Waldor' via weewx-user]

Yes, I do have backups. But which one to use? I do not know WHEN the 
potential error might have occured. I even don't know IF there is an error. 
As I wrote, weewxd can happily append data.

I "only" encounter problems when I try to manually run sqlite3 commands. 
And those indicate that the error might have been introduced in 2018 just 
after 2months of runtime. If that's true I might safely start a fresh DB:-(

Tom Keffer schrieb am Mittwoch, 20. März 2024 um 14:04:37 UTC+1:

> If you say the problem is in the database and the database cannot be 
> recovered, I'm not sure there is anything we can offer. What are you 
> looking for from the group?
>
> Hopefully you have a backup database.
>
> On Wed, Mar 20, 2024 at 5:55 AM 'Michael Waldor' via weewx-user <
> weewx...@googlegroups.com> wrote:
>
>> weewx itself works without problems - it can add new entries into 
>> weewx.sdb, and it'S running  right now.
>>
>> But when trying to manually tweak weewx.sdb using sqlite3 commands, 
>> sqlite3 complains. Using .recover seems to make it worse - its sql output 
>> contains some completely broken lines with datetime being 7 or 74 or 
>> unprintable bnary data. Clearly weewxd rejects to use that "recovered" 
>> weewx.sdb.
>>
>> Currently I try to follow 
>> https://groups.google.com/g/weewx-user/c/PJuWj35o8TM
>> Luckily the transformation process should run for ~30min (data is stored 
>> on a SSD).
>>
>> But howto identify the location of a broken weewx.sdb? E.g. if I try to 
>> run the sqlite3 command
>> select date(datetime, 'unixepoch', 'localtime') from archive;
>> It outputs data till 2018-03-31. And then there is an sqlite3 error 
>> message. Only the date conversion seems to fail. If I stay with integer 
>> datetime all data seems to be accessible.
>>
>> Tom Keffer schrieb am Mittwoch, 20. März 2024 um 13:28:57 UTC+1:
>>
>>> This could be anything. We will need to see more of the log to tell. For 
>>> example, you could be asking for a date one month after January 30.
>>>
>>> Set debug=1, restart weewxd, post the log from startup through the error.
>>>
>>> On Wed, Mar 20, 2024 at 3:57 AM 'Michael Waldor' via weewx-user <
>>> weewx...@googlegroups.com> wrote:
>>>
>>>> Sadly those mysterious rows only appear AFTER .recover,  they appear 
>>>> within weewx.sql.
>>>> The failing command is
>>>>
>>>> SELECT count(*)
>>>> FROM archive
>>>> WHERE
>>>>   date(datetime, 'unixepoch', 'localtime')
>>>>   between '2024-03-15' and '2024-03-15';
>>>>
>>>> But that command works fine AFTER .recover.
>>>>
>>>> The error message from weewxd clearly indicates wrong datetime:
>>>>
>>>> Mär 20 11:34:37 imurr9 weewxd[15172]: CRITICAL __main__:  
>>>>  last_d = datetime.date.fromtimestamp(weeutil.weeutil.startOfArchiveDay(
>>>> Mär 20 11:34:37 imurr9 weewxd[15172]: time_dt = 
>>>> datetime.datetime.fromtimestamp(time_ts)
>>>> Mär 20 11:34:37 imurr9 weewxd[15172]: OverflowError: timestamp out of 
>>>> range for platform time_t
>>>> Mär 20 11:34:37 imurr9 weewxd[15172]: CRITICAL __main__:    
>>>>  File "/usr/share/weewx/weeutil/weeutil.py", line 1196, in 
>>>> startOfArchiveDay
>>>> Mär 20 11:34:37 imurr9 weewxd[15172]: CRITICAL __main__:          
>>>>  time_dt = datetime.datetime.fromtimestamp(time_ts)
>>>> Mär 20 11:34:37 imurr9 weewxd[15172]: CRITICAL __main__:  
>>>>  OverflowError: timestamp out of range for platform time_t
>>>> Mär 20 11:34:37 imurr9 weewxd[15172]: CRITICAL __main__:  
>>>>  Exiting
>>>> Michael Waldor schrieb am Mittwoch, 20. März 2024 um 10:43:13 UTC+1:
>>>>
>>>>> I do have a first idea: There are entries within weewx.sdb where 
>>>>> datetime is 0 or 7. Those values clearly are no valid timestamps.
>>>>> I'll proceed in that direction ...
>>>>>
>>>>> Michael Waldor schrieb am Mittwoch, 20. März 2024 um 10:04:57 UTC+1:
>>>>>
>>>>>> Some days ago I've stopped weewx for roughly one day (I did change 
>>>>>> the GPIO connections of my raspberry pi4). Now I wanted to insert some 
>>>>>> data 
>>>>>> into my weewx.sdb from that timespan.
>>>>>>
>>>>>> When trying some sqlite3 commands (on a local copy of weewx.sdb - as 
&g

Re: [weewx-user] Re: Problem during fixing of potential corrupt database

['Michael Waldor' via weewx-user]

weewx itself works without problems - it can add new entries into 
weewx.sdb, and it'S running  right now.

But when trying to manually tweak weewx.sdb using sqlite3 commands, sqlite3 
complains. Using .recover seems to make it worse - its sql output contains 
some completely broken lines with datetime being 7 or 74 or unprintable 
bnary data. Clearly weewxd rejects to use that "recovered" weewx.sdb.

Currently I try to follow 
https://groups.google.com/g/weewx-user/c/PJuWj35o8TM
Luckily the transformation process should run for ~30min (data is stored on 
a SSD).

But howto identify the location of a broken weewx.sdb? E.g. if I try to run 
the sqlite3 command
select date(datetime, 'unixepoch', 'localtime') from archive;
It outputs data till 2018-03-31. And then there is an sqlite3 error 
message. Only the date conversion seems to fail. If I stay with integer 
datetime all data seems to be accessible.

Tom Keffer schrieb am Mittwoch, 20. März 2024 um 13:28:57 UTC+1:

> This could be anything. We will need to see more of the log to tell. For 
> example, you could be asking for a date one month after January 30.
>
> Set debug=1, restart weewxd, post the log from startup through the error.
>
> On Wed, Mar 20, 2024 at 3:57 AM 'Michael Waldor' via weewx-user <
> weewx...@googlegroups.com> wrote:
>
>> Sadly those mysterious rows only appear AFTER .recover,  they appear 
>> within weewx.sql.
>> The failing command is
>>
>> SELECT count(*)
>> FROM archive
>> WHERE
>>   date(datetime, 'unixepoch', 'localtime')
>>   between '2024-03-15' and '2024-03-15';
>>
>> But that command works fine AFTER .recover.
>>
>> The error message from weewxd clearly indicates wrong datetime:
>>
>> Mär 20 11:34:37 imurr9 weewxd[15172]: CRITICAL __main__:  
>>  last_d = datetime.date.fromtimestamp(weeutil.weeutil.startOfArchiveDay(
>> Mär 20 11:34:37 imurr9 weewxd[15172]: time_dt = 
>> datetime.datetime.fromtimestamp(time_ts)
>> Mär 20 11:34:37 imurr9 weewxd[15172]: OverflowError: timestamp out of 
>> range for platform time_t
>> Mär 20 11:34:37 imurr9 weewxd[15172]: CRITICAL __main__: File 
>> "/usr/share/weewx/weeutil/weeutil.py", line 1196, in startOfArchiveDay
>> Mär 20 11:34:37 imurr9 weewxd[15172]: CRITICAL __main__:  
>>  time_dt = datetime.datetime.fromtimestamp(time_ts)
>> Mär 20 11:34:37 imurr9 weewxd[15172]: CRITICAL __main__:  
>>  OverflowError: timestamp out of range for platform time_t
>> Mär 20 11:34:37 imurr9 weewxd[15172]: CRITICAL __main__:   Exiting
>> Michael Waldor schrieb am Mittwoch, 20. März 2024 um 10:43:13 UTC+1:
>>
>>> I do have a first idea: There are entries within weewx.sdb where 
>>> datetime is 0 or 7. Those values clearly are no valid timestamps.
>>> I'll proceed in that direction ...
>>>
>>> Michael Waldor schrieb am Mittwoch, 20. März 2024 um 10:04:57 UTC+1:
>>>
>>>> Some days ago I've stopped weewx for roughly one day (I did change the 
>>>> GPIO connections of my raspberry pi4). Now I wanted to insert some data 
>>>> into my weewx.sdb from that timespan.
>>>>
>>>> When trying some sqlite3 commands (on a local copy of weewx.sdb - as an 
>>>> exercise a simple count) sqlite3 failed with corrupt database. OK, can 
>>>> imagine that that might have happened sometimes during the last 5 years. 
>>>> Thus I tried to rebuild my database by
>>>>
>>>> mv weewx.sdb weewx_corrupt.sdb
>>>> sqlite3 weewx_corrupt.sdb .recover > weewx.sql
>>>> sqlite3 weewx.sdb < weewx.sql
>>>>
>>>> Now my sqlite3 commands worked as expected, i.e. the newly created 
>>>> weewx.sdb seemed to be fixed. Keep in mind that I did not modify 
>>>> weewx.sql. 
>>>> Thus a potential error might still have "survived" within the newly 
>>>> created 
>>>> weewx.sdb.
>>>>
>>>> I then checked the modified weewx.sdb copied into /var/lib/weewx (weewx 
>>>> itself was NOT running) with
>>>>
>>>> weectl database check
>>>>
>>>> and got no error messages. But weewxd did not like that modified 
>>>> weewx.sdb. It reports "OverflowError: timestamp out of range for ..." when 
>>>> starting weewx.
>>>>
>>>> To me it's difficult to tell
>>>> 1. whether my original weewx.sdb is corrupt at all (weewxd works fine)
>>>> 2. if it's corrupt howto fix it.
>>>>
>>>> Hope somebody might have a suggestion

[weewx-user] Re: Problem during fixing of potential corrupt database

['Michael Waldor' via weewx-user]

Sadly those mysterious rows only appear AFTER .recover,  they appear within 
weewx.sql.
The failing command is

SELECT count(*)
FROM archive
WHERE
  date(datetime, 'unixepoch', 'localtime')
  between '2024-03-15' and '2024-03-15';

But that command works fine AFTER .recover.

The error message from weewxd clearly indicates wrong datetime:

Mär 20 11:34:37 imurr9 weewxd[15172]: CRITICAL __main__:  
 last_d = datetime.date.fromtimestamp(weeutil.weeutil.startOfArchiveDay(
Mär 20 11:34:37 imurr9 weewxd[15172]: time_dt = 
datetime.datetime.fromtimestamp(time_ts)
Mär 20 11:34:37 imurr9 weewxd[15172]: OverflowError: timestamp out of range 
for platform time_t
Mär 20 11:34:37 imurr9 weewxd[15172]: CRITICAL __main__: File 
"/usr/share/weewx/weeutil/weeutil.py", line 1196, in startOfArchiveDay
Mär 20 11:34:37 imurr9 weewxd[15172]: CRITICAL __main__:  
 time_dt = datetime.datetime.fromtimestamp(time_ts)
Mär 20 11:34:37 imurr9 weewxd[15172]: CRITICAL __main__:  
 OverflowError: timestamp out of range for platform time_t
Mär 20 11:34:37 imurr9 weewxd[15172]: CRITICAL __main__:   Exiting
Michael Waldor schrieb am Mittwoch, 20. März 2024 um 10:43:13 UTC+1:

> I do have a first idea: There are entries within weewx.sdb where datetime 
> is 0 or 7. Those values clearly are no valid timestamps.
> I'll proceed in that direction ...
>
> Michael Waldor schrieb am Mittwoch, 20. März 2024 um 10:04:57 UTC+1:
>
>> Some days ago I've stopped weewx for roughly one day (I did change the 
>> GPIO connections of my raspberry pi4). Now I wanted to insert some data 
>> into my weewx.sdb from that timespan.
>>
>> When trying some sqlite3 commands (on a local copy of weewx.sdb - as an 
>> exercise a simple count) sqlite3 failed with corrupt database. OK, can 
>> imagine that that might have happened sometimes during the last 5 years. 
>> Thus I tried to rebuild my database by
>>
>> mv weewx.sdb weewx_corrupt.sdb
>> sqlite3 weewx_corrupt.sdb .recover > weewx.sql
>> sqlite3 weewx.sdb < weewx.sql
>>
>> Now my sqlite3 commands worked as expected, i.e. the newly created 
>> weewx.sdb seemed to be fixed. Keep in mind that I did not modify weewx.sql. 
>> Thus a potential error might still have "survived" within the newly created 
>> weewx.sdb.
>>
>> I then checked the modified weewx.sdb copied into /var/lib/weewx (weewx 
>> itself was NOT running) with
>>
>> weectl database check
>>
>> and got no error messages. But weewxd did not like that modified 
>> weewx.sdb. It reports "OverflowError: timestamp out of range for ..." when 
>> starting weewx.
>>
>> To me it's difficult to tell
>> 1. whether my original weewx.sdb is corrupt at all (weewxd works fine)
>> 2. if it's corrupt howto fix it.
>>
>> Hope somebody might have a suggestion, Michael
>>
>>

-- 
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/b00628cf-ebf4-4fc2-a8bb-a193447e9476n%40googlegroups.com.

[weewx-user] Re: Problem during fixing of potential corrupt database

['Michael Waldor' via weewx-user]

I do have a first idea: There are entries within weewx.sdb where datetime 
is 0 or 7. Those values clearly are no valid timestamps.
I'll proceed in that direction ...

Michael Waldor schrieb am Mittwoch, 20. März 2024 um 10:04:57 UTC+1:

> Some days ago I've stopped weewx for roughly one day (I did change the 
> GPIO connections of my raspberry pi4). Now I wanted to insert some data 
> into my weewx.sdb from that timespan.
>
> When trying some sqlite3 commands (on a local copy of weewx.sdb - as an 
> exercise a simple count) sqlite3 failed with corrupt database. OK, can 
> imagine that that might have happened sometimes during the last 5 years. 
> Thus I tried to rebuild my database by
>
> mv weewx.sdb weewx_corrupt.sdb
> sqlite3 weewx_corrupt.sdb .recover > weewx.sql
> sqlite3 weewx.sdb < weewx.sql
>
> Now my sqlite3 commands worked as expected, i.e. the newly created 
> weewx.sdb seemed to be fixed. Keep in mind that I did not modify weewx.sql. 
> Thus a potential error might still have "survived" within the newly created 
> weewx.sdb.
>
> I then checked the modified weewx.sdb copied into /var/lib/weewx (weewx 
> itself was NOT running) with
>
> weectl database check
>
> and got no error messages. But weewxd did not like that modified 
> weewx.sdb. It reports "OverflowError: timestamp out of range for ..." when 
> starting weewx.
>
> To me it's difficult to tell
> 1. whether my original weewx.sdb is corrupt at all (weewxd works fine)
> 2. if it's corrupt howto fix it.
>
> Hope somebody might have a suggestion, Michael
>
>

-- 
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/15fe0dac-b6a3-4090-ad0d-5f02dd6c50fan%40googlegroups.com.

[weewx-user] Problem during fixing of potential corrupt database

['Michael Waldor' via weewx-user]

Some days ago I've stopped weewx for roughly one day (I did change the GPIO 
connections of my raspberry pi4). Now I wanted to insert some data into my 
weewx.sdb from that timespan.

When trying some sqlite3 commands (on a local copy of weewx.sdb - as an 
exercise a simple count) sqlite3 failed with corrupt database. OK, can 
imagine that that might have happened sometimes during the last 5 years. 
Thus I tried to rebuild my database by

mv weewx.sdb weewx_corrupt.sdb
sqlite3 weewx_corrupt.sdb .recover > weewx.sql
sqlite3 weewx.sdb < weewx.sql

Now my sqlite3 commands worked as expected, i.e. the newly created 
weewx.sdb seemed to be fixed. Keep in mind that I did not modify weewx.sql. 
Thus a potential error might still have "survived" within the newly created 
weewx.sdb.

I then checked the modified weewx.sdb copied into /var/lib/weewx (weewx 
itself was NOT running) with

weectl database check

and got no error messages. But weewxd did not like that modified weewx.sdb. 
It reports "OverflowError: timestamp out of range for ..." when starting 
weewx.

To me it's difficult to tell
1. whether my original weewx.sdb is corrupt at all (weewxd works fine)
2. if it's corrupt howto fix it.

Hope somebody might have a suggestion, Michael

-- 
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/849d550f-6561-4862-a919-0f673459dc02n%40googlegroups.com.

[weewx-user] successful update to weewx 5.0.1 for driver WH23xx

['Michael Waldor' via weewx-user]

Today I could successfully update my weewx 4.x installation to the new 
weewx version  5.0.1 on a raspberry pi 4 running OSMC 2024-02 (kodi 20.3).

Don't know why but I had to manually update the weewx gpg key. Otherwise 
apt update failed.

There was one major flaw in using the driver WH23xx - the access onto USB 
connection was refused (to be expected due to the permission changes). 
Sadly WH23xx is no longer officially supported, but the driver from 
weewx-4.x works fine. One has to add one udev rule to grant weewx access. I 
added the file /etc/udev/rules.d/900-weewx-wh23xx.rules containing the 
single line:

SUBSYSTEM=="usb",ATTRS{idVendor}=="10c4",ATTRS{idProduct}=="8468",MODE="0664",GROUP="weewx"

BTW, I've seen "private" udev rules wihin /etc/weewx/udev. I assume that 
those rules are only for reference, but not used directly. Of course I've 
used them as a pattern for my solution.

Regarding installation: Before running the update on my target raspberry 
pi4 I tried a "vanilla" installation on another platform -  Suse 
tumbleweed. That, too, failed first. This time the URL of the weewx 
repository was not accessible. I manipulated it to point onto .../suse15. 
As a consequence the validation failed, but I simply ignored that and could 
finally install weewx under tumbleweed. I only wanted to get some files in 
advance before doing the real raspberry installation. I do NOT use weewx 
under tumbleweed.

Regards, Michael

-- 
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/706d5b92-ed91-477e-8c68-091fea0da6f4n%40googlegroups.com.

Re: [weewx-user] WEEWX_ROOT partly failing

['Michael Waldor' via weewx-user]

That's fine to me - I only was irritated by the maybe old comment within 
distributed weewx.conf.dist. The behaviour is clear and fine.

Regards, Michael

Tom Keffer schrieb am Samstag, 6. Januar 2024 um 15:31:30 UTC+1:

> Exactly. That's just path dynamics. I don't think we want to turn 
> weewx.conf into a tutorial on paths.
>
> On Sat, Jan 6, 2024 at 5:50 AM 'Cameron D' via weewx-user <
> weewx...@googlegroups.com> wrote:
>
>> The current docs for V4.10 as well as 5.0 say that "a *relative *path" 
>> for HTML_ROOT or SKIN_ROOT is below WEEWX_ROOT.  
>> If you define either as an *absolute* path (i.e. beginning with a "/"), 
>> then WEEWX_ROOT is ignored.
>>
>> On Saturday 6 January 2024 at 6:53:06 pm UTC+10 Michael Waldor wrote:
>>
>>> Maybe best is to illustrate my setup with the Linux commands to create 
>>> it (in reality I didi it somehow different because differen hosts are 
>>> involved):
>>> WEEWX_ROOT=~/weewx-debug
>>> mkdir $WEEWX_ROOT
>>> cd $WEEWX_ROOT
>>> (cd /; tar zcvf - usr/share/weewx)|tar zxvf -
>>> (cd /; tar zcvf - etc/weewx)|tar zxvf -
>>> mkdir -p var/www/html/weewx
>>> mkdir -p var/lib/weewx
>>> cp /var/lib/weewx/*.sdb var/lib/weewx
>>>
>>> Within etc/weewx/weewx.conf I modified
>>> WEEWX_ROOT = /home/MyHome/weewx-debug
>>> ...
>>> SQLITE_ROOT = /home/MyHome/weewx-debug/var/lib/weewx
>>>
>>> I enabled debug = 1 
>>> I did NOT change SKIN_ROOT and HTML_ROOT since the (maybe outdated) 
>>> comments from weewx.conf say
>>>
>>> # Where the skins reside, relative to WEEWX_ROOT
>>> SKIN_ROOT = /etc/weewx/skins
>>> 
>>> # Where the generated reports should go, relative to WEEWX_ROOT
>>> HTML_ROOT = /var/www/html/weewx
>>>
>>> Maybe simply those comments are misleading? For my debugging I simply 
>>> created symbolic links for skins and www. Probabely I should have changed 
>>> SKIN_ROOT and HTML_ROOT instead? Just tested it right now - and YES it 
>>> worked. Thus only the comments are wrong. Setting
>>> SKIN_ROOT = /home/MyHome/weewx-debug/etc/weewx/skins
>>> HTML_ROOT = /home/MyHome/weewx-debug/var/www/html/weewx
>>> works fine without additional symbolic links!
>>>
>>> From my perspective this is better as compared to the (hidden) use of 
>>> WEEWX_ROOT. Thus maybe one only should correct the misleading comments 
>>> within default weewx.conf?
>>>
>>> Regards, Michael
>>>
>>> Tom Hogland schrieb am Samstag, 6. Januar 2024 um 02:35:53 UTC+1:
>>>
>>>> Michael - 
>>>>
>>>> WEEWX_ROOT is the root folder under which all the other folders live 
>>>> (such as HTML_ROOT or SKIN_ROOT). My WEEWX_ROOT is /, SKIN_ROOT is 
>>>> /etc/weewx/skins and HTML_ROOT is /var/www/html/weewx. Your skins would be 
>>>> in WEEWX_ROOT/SKIN_ROOT and your weather files will generate into 
>>>> WEEWX_ROOT/HTML_ROOT.
>>>>
>>>> What do you have SKIN_ROOT and HTML_ROOT set to? And do those folders 
>>>> exist within the WEEWX_ROOT folder you created?
>>>>
>>>> Tom
>>>>
>>>> On Friday, January 5, 2024 at 2:56:29 PM UTC-9 Tom Keffer wrote:
>>>>
>>>>> Could you try again? I don't understand the point you are making. 
>>>>>
>>>>> On Fri, Jan 5, 2024 at 7:59 AM 'Michael Waldor' via weewx-user <
>>>>> weewx...@googlegroups.com> wrote:
>>>>>
>>>>>> Maybe my understanding of WEEWX_ROOT is wrong. But partly it worked 
>>>>>> thus I assume it is not working everywhere. I did set WEEWX_ROOT within 
>>>>>> weewx.conf onto some directory and copied a full weewx 4.6.2 
>>>>>> installation 
>>>>>> over there. But the following folders were not found
>>>>>>
>>>>>> WEEWX_ROOT/etc/weewx/skins
>>>>>> WEEWX_ROOT/var/www/html/weewx
>>>>>>
>>>>>> I could fix that by introducing proper links like e.g.
>>>>>> mkdir /etc/weewx
>>>>>> cd !$
>>>>>> ln -s WEEWX_ROOT/etc/weewx/skin
>>>>>> cd /var
>>>>>> ln -s WEEWX_ROOT/var/www
>>>>>>
>>>>>> It's really a minor issue, but maybe it should be fixed sometimes.
>>>>>>
>>>>>> Regards, Michael
>>>>>>
&g

Re: [weewx-user] WEEWX_ROOT partly failing

['Michael Waldor' via weewx-user]

Maybe best is to illustrate my setup with the Linux commands to create it 
(in reality I didi it somehow different because differen hosts are 
involved):
WEEWX_ROOT=~/weewx-debug
mkdir $WEEWX_ROOT
cd $WEEWX_ROOT
(cd /; tar zcvf - usr/share/weewx)|tar zxvf -
(cd /; tar zcvf - etc/weewx)|tar zxvf -
mkdir -p var/www/html/weewx
mkdir -p var/lib/weewx
cp /var/lib/weewx/*.sdb var/lib/weewx

Within etc/weewx/weewx.conf I modified
WEEWX_ROOT = /home/MyHome/weewx-debug
...
SQLITE_ROOT = /home/MyHome/weewx-debug/var/lib/weewx

I enabled debug = 1 
I did NOT change SKIN_ROOT and HTML_ROOT since the (maybe outdated) 
comments from weewx.conf say

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

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

Maybe simply those comments are misleading? For my debugging I simply 
created symbolic links for skins and www. Probabely I should have changed 
SKIN_ROOT and HTML_ROOT instead? Just tested it right now - and YES it 
worked. Thus only the comments are wrong. Setting
SKIN_ROOT = /home/MyHome/weewx-debug/etc/weewx/skins
HTML_ROOT = /home/MyHome/weewx-debug/var/www/html/weewx
works fine without additional symbolic links!

>From my perspective this is better as compared to the (hidden) use of 
WEEWX_ROOT. Thus maybe one only should correct the misleading comments 
within default weewx.conf?

Regards, Michael

Tom Hogland schrieb am Samstag, 6. Januar 2024 um 02:35:53 UTC+1:

> Michael - 
>
> WEEWX_ROOT is the root folder under which all the other folders live (such 
> as HTML_ROOT or SKIN_ROOT). My WEEWX_ROOT is /, SKIN_ROOT is 
> /etc/weewx/skins and HTML_ROOT is /var/www/html/weewx. Your skins would be 
> in WEEWX_ROOT/SKIN_ROOT and your weather files will generate into 
> WEEWX_ROOT/HTML_ROOT.
>
> What do you have SKIN_ROOT and HTML_ROOT set to? And do those folders 
> exist within the WEEWX_ROOT folder you created?
>
> Tom
>
> On Friday, January 5, 2024 at 2:56:29 PM UTC-9 Tom Keffer wrote:
>
>> Could you try again? I don't understand the point you are making. 
>>
>> On Fri, Jan 5, 2024 at 7:59 AM 'Michael Waldor' via weewx-user <
>> weewx...@googlegroups.com> wrote:
>>
>>> Maybe my understanding of WEEWX_ROOT is wrong. But partly it worked thus 
>>> I assume it is not working everywhere. I did set WEEWX_ROOT within 
>>> weewx.conf onto some directory and copied a full weewx 4.6.2 installation 
>>> over there. But the following folders were not found
>>>
>>> WEEWX_ROOT/etc/weewx/skins
>>> WEEWX_ROOT/var/www/html/weewx
>>>
>>> I could fix that by introducing proper links like e.g.
>>> mkdir /etc/weewx
>>> cd !$
>>> ln -s WEEWX_ROOT/etc/weewx/skin
>>> cd /var
>>> ln -s WEEWX_ROOT/var/www
>>>
>>> It's really a minor issue, but maybe it should be fixed sometimes.
>>>
>>> Regards, Michael
>>>
>>> -- 
>>> 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/d6931dc9-214c-4a75-b1ae-b2bd063b2ca5n%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/weewx-user/d6931dc9-214c-4a75-b1ae-b2bd063b2ca5n%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>>

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

[weewx-user] WEEWX_ROOT partly failing

['Michael Waldor' via weewx-user]

Maybe my understanding of WEEWX_ROOT is wrong. But partly it worked thus I 
assume it is not working everywhere. I did set WEEWX_ROOT within weewx.conf 
onto some directory and copied a full weewx 4.6.2 installation over there. 
But the following folders were not found

WEEWX_ROOT/etc/weewx/skins
WEEWX_ROOT/var/www/html/weewx

I could fix that by introducing proper links like e.g.
mkdir /etc/weewx
cd !$
ln -s WEEWX_ROOT/etc/weewx/skin
cd /var
ln -s WEEWX_ROOT/var/www

It's really a minor issue, but maybe it should be fixed sometimes.

Regards, Michael

-- 
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/d6931dc9-214c-4a75-b1ae-b2bd063b2ca5n%40googlegroups.com.

Re: [weewx-user] Re: empty week images due to end of year?

['Michael Waldor' via weewx-user]

I could idenify the main reason for my problem. If the right border of the 
timeline has already reached the new year 2024 while the current date (last 
database entry) is still in 2023 that line is intentionally skipped 
triggered by skip_if_empty - see the the debugging of imagegenerator.py 
within the program "wee_reports   --date 2023-12-31 --time=15:00"

-> if skip:
(Pdb) print(line_name)
outHumidity
(Pdb) print(x_domain)
[2023-12-22 00:00:00 CET (1703199600) -> 2024-01-02 00:00:00 CET 
(170415)]  < as intended by my change
(Pdb) print(skip)
True
(Pdb) print(binding)
wx_binding
(Pdb) print(db_manager)

(Pdb) print(check_domain)
[2024-01-01 00:00:00 CET (1704063600) -> 2025-01-01 00:00:00 CET 
(1735686000)]<-- unexpectedly checking the "wrong" year
(Pdb) exit

The x_domain correctly starts in 2023 and ends in 2024. But the 
check_domain only looks into 2024 - of course without data at end of 2023.

There is a workaround in setting skip_if_empty to false within skin.conf. 
By default within Seasons it is set to year.

But setting skip_if_empty to false triggers another problem for many 
observables like e.g. extTemp4. wee_reports crashes with the error message:
Using configuration file etc/weewx/weewx.conf
Traceback (most recent call last):
  File 
"/shared/purzel/miwaldor/weewx-debug/usr/share/weewx/weewx/reportengine.py", 
line 197, in run
obj.start()
  File 
"/shared/purzel/miwaldor/weewx-debug/usr/share/weewx/weewx/reportengine.py", 
line 385, in start
self.run()
  File 
"/shared/purzel/miwaldor/weewx-debug/usr/share/weewx/weewx/imagegenerator.py", 
line 42, in run
self.gen_images(self.gen_ts)
  File 
"/shared/purzel/miwaldor/weewx-debug/usr/share/weewx/weewx/imagegenerator.py", 
line 107, in gen_images
plot = self.gen_plot(plotgen_ts,
   ^
  File 
"/shared/purzel/miwaldor/weewx-debug/usr/share/weewx/weewx/imagegenerator.py", 
line 250, in gen_plot
start_vec_t, stop_vec_t, data_vec_t = weewx.xtypes.get_series(
  
  File 
"/shared/purzel/miwaldor/weewx-debug/usr/share/weewx/weewx/xtypes.py", line 
116, in get_series
raise weewx.UnknownType(msg)
weewx.UnknownType: extraTemp4

The same error occurs for all those observables (really many, e.g. all 
extTemp? > 3) which are not within the weewx.sdb database. Maybe that's an 
ommission from my side. I'm using weewx for the last ~5 years and never did 
any database migration (except those maybe enforced by the apt 
installation).

Conclusion: I now have a working solution. I will drop all failing (and 
from me not used) observables and set check_if_empt to false. But maybe two 
changes should be applied to weewx-4.10.2 to resolve those problems for 
other users (did not investigate the upcoming 5.0 version of weewx).

Regards, Michael


Michael Waldor schrieb am Freitag, 5. Januar 2024 um 14:15:58 UTC+1:

> Thanks a lot for this hint - I wasn't aware that there are such complex 
> dependencies among python versions  - its extensions - and weewx. Since I'm 
> on tumbleweed, too, I couldn't simply switch the pillow version. After 
> tweaking genplot.py I also had to manipulate utilities.py as described here 
> https://groups.google.com/g/weewx-user/c/pOOAfh6ct-I
> But now I have a working wee_reports within my test environment AND can 
> reproduce my problem. Thus now I will start to debug ...
>
> Regards, Michael
>
>
> michael.k...@gmx.at schrieb am Donnerstag, 4. Januar 2024 um 18:49:36 
> UTC+1:
>
>> https://groups.google.com/g/weewx-user/search?q=pil%20attribute%20error
>> Michael Waldor schrieb am Donnerstag, 4. Januar 2024 um 17:42:34 UTC+1:
>>
>>> I'm trying to setup my linux laptop as a degugging station for my weewx 
>>> issue. I've copied all relevant files into my homedirectory resembling the 
>>> weewx directory structure. Did the same for /var and the like. I enabled 
>>> python3.11 to be /usr/bin/python. I also installed some python tools not 
>>> commonly available within my linux distribution (e.g. pillow or cheetha). 
>>> Finally my call to wee_reports is working nearly (and creates some files 
>>> within var/www/html/weewx, but no images):
>>>
>>> PYTHONPATH=MYROOT/weewx-debug/usr/share/weewx 
>>> MYROOT/weewx-debug/usr/share/weewx/wee_reports --
>>> config etc/weewx/weewx.conf --date 2023-12-10 --time=15:00
>>>
>>> But I encounter the error
>>>
>>> Traceback (most recent call last):
>>>   File "MYROOT/weewx-debug/usr/share/weewx/weewx/reportengine.py", line 
>>> 197, in run
>>> obj.start()
>>>   File "MYROOT/weewx-debug/usr/share/weewx/weewx/reportengine.py"

Re: [weewx-user] Re: empty week images due to end of year?

['Michael Waldor' via weewx-user]

Thanks a lot for this hint - I wasn't aware that there are such complex 
dependencies among python versions  - its extensions - and weewx. Since I'm 
on tumbleweed, too, I couldn't simply switch the pillow version. After 
tweaking genplot.py I also had to manipulate utilities.py as described here 
https://groups.google.com/g/weewx-user/c/pOOAfh6ct-I
But now I have a working wee_reports within my test environment AND can 
reproduce my problem. Thus now I will start to debug ...

Regards, Michael


michael.k...@gmx.at schrieb am Donnerstag, 4. Januar 2024 um 18:49:36 UTC+1:

> https://groups.google.com/g/weewx-user/search?q=pil%20attribute%20error
> Michael Waldor schrieb am Donnerstag, 4. Januar 2024 um 17:42:34 UTC+1:
>
>> I'm trying to setup my linux laptop as a degugging station for my weewx 
>> issue. I've copied all relevant files into my homedirectory resembling the 
>> weewx directory structure. Did the same for /var and the like. I enabled 
>> python3.11 to be /usr/bin/python. I also installed some python tools not 
>> commonly available within my linux distribution (e.g. pillow or cheetha). 
>> Finally my call to wee_reports is working nearly (and creates some files 
>> within var/www/html/weewx, but no images):
>>
>> PYTHONPATH=MYROOT/weewx-debug/usr/share/weewx 
>> MYROOT/weewx-debug/usr/share/weewx/wee_reports --
>> config etc/weewx/weewx.conf --date 2023-12-10 --time=15:00
>>
>> But I encounter the error
>>
>> Traceback (most recent call last):
>>   File "MYROOT/weewx-debug/usr/share/weewx/weewx/reportengine.py", line 
>> 197, in run
>> obj.start()
>>   File "MYROOT/weewx-debug/usr/share/weewx/weewx/reportengine.py", line 
>> 385, in start
>> self.run()
>>   File "MYROOT/weewx-debug/usr/share/weewx/weewx/imagegenerator.py", line 
>> 42, in run
>> self.gen_images(self.gen_ts)
>>   File "MYROOT/weewx-debug/usr/share/weewx/weewx/imagegenerator.py", line 
>> 114, in gen_images
>> image = plot.render()
>> ^
>>   File "MYROOT/weewx-debug/usr/share/weewx/weeplot/genplot.py", line 212, 
>> in render
>> self._renderBottom(draw)
>>   File "MYROOT/weewx-debug/usr/share/weewx/weeplot/genplot.py", line 404, 
>> in _renderBottom
>> bottom_label_size = draw.textsize(self.bottom_label, 
>> font=bottom_label_font)
>> 
>> 
>>   File "MYROOT/weewx-debug/usr/share/weewx/weeplot/genplot.py", line 646, 
>> in textsize
>> return ImageDraw.ImageDraw.textsize(self, string, **options)
>>
>> AttributeError: type object 'ImageDraw' has no attribute 'textsize'
>> Generating for requested time 2023-12-31 15:00:00 CET (1704031200)
>> Using configuration file etc/weewx/weewx.conf
>>
>> I modified WEEWXROOT to point onto MYROOT.
>>
>> I admit my current approach is a little bit unconventionally, but I seem 
>> to be near to a working debugging environment.
>>
>> Any hint w.r.t. the above python error?
>>
>>
>> Regards, Michael
>>
>> Michael Waldor schrieb am Dienstag, 2. Januar 2024 um 07:47:44 UTC+1:
>>
>>> Thanks for your intrest in my problem. I do have two major changes 
>>> within section [imagegenerator]. I've increased the image_width from 500 to 
>>> 600. And I've added a second line within some images to include forcast 
>>> data from a different database like e.g.
>>> [[[daybarometer]]]
>>> barometer
>>> forecast_barometer
>>> data_type = barometer
>>> data_binding = dwd_binding
>>> label = ' '
>>> color = blue
>>> And to draw that forecast data I use my new option "time_offset = 36000 
>>>  # 10 hours". It's intention is to use the additional 100pixel to be filled 
>>> by forecast.
>>> See my full skin.conf appended here.
>>>
>>> Regards, Michael
>>>
>>>
>>> gjr80 schrieb am Montag, 1. Januar 2024 um 21:46:42 UTC+1:
>>>
>>>> Thank you, so that is the code, just need the plot definition. In fact, 
>>>> the entire [ImageGenerator] stanza from the config file in use would 
>>>> be best.
>>>>
>>>> Gary
>>>>
>>>> On Monday 1 January 2024 at 23:19:52 UTC+10 miwa...@googlemail.com 
>>>> wrote:
>>>>
>>>>> My code is available as a (reject

Re: [weewx-user] Re: empty week images due to end of year?

['Michael Waldor' via weewx-user]

I'm trying to setup my linux laptop as a degugging station for my weewx 
issue. I've copied all relevant files into my homedirectory resembling the 
weewx directory structure. Did the same for /var and the like. I enabled 
python3.11 to be /usr/bin/python. I also installed some python tools not 
commonly available within my linux distribution (e.g. pillow or cheetha). 
Finally my call to wee_reports is working nearly (and creates some files 
within var/www/html/weewx, but no images):

PYTHONPATH=MYROOT/weewx-debug/usr/share/weewx 
MYROOT/weewx-debug/usr/share/weewx/wee_reports --
config etc/weewx/weewx.conf --date 2023-12-10 --time=15:00

But I encounter the error

Traceback (most recent call last):
  File "MYROOT/weewx-debug/usr/share/weewx/weewx/reportengine.py", line 
197, in run
obj.start()
  File "MYROOT/weewx-debug/usr/share/weewx/weewx/reportengine.py", line 
385, in start
self.run()
  File "MYROOT/weewx-debug/usr/share/weewx/weewx/imagegenerator.py", line 
42, in run
self.gen_images(self.gen_ts)
  File "MYROOT/weewx-debug/usr/share/weewx/weewx/imagegenerator.py", line 
114, in gen_images
image = plot.render()
^
  File "MYROOT/weewx-debug/usr/share/weewx/weeplot/genplot.py", line 212, 
in render
self._renderBottom(draw)
  File "MYROOT/weewx-debug/usr/share/weewx/weeplot/genplot.py", line 404, 
in _renderBottom
bottom_label_size = draw.textsize(self.bottom_label, 
font=bottom_label_font)


  File "MYROOT/weewx-debug/usr/share/weewx/weeplot/genplot.py", line 646, 
in textsize
return ImageDraw.ImageDraw.textsize(self, string, **options)
   
AttributeError: type object 'ImageDraw' has no attribute 'textsize'
Generating for requested time 2023-12-31 15:00:00 CET (1704031200)
Using configuration file etc/weewx/weewx.conf

I modified WEEWXROOT to point onto MYROOT.

I admit my current approach is a little bit unconventionally, but I seem to 
be near to a working debugging environment.

Any hint w.r.t. the above python error?


Regards, Michael

Michael Waldor schrieb am Dienstag, 2. Januar 2024 um 07:47:44 UTC+1:

> Thanks for your intrest in my problem. I do have two major changes within 
> section [imagegenerator]. I've increased the image_width from 500 to 600. 
> And I've added a second line within some images to include forcast data 
> from a different database like e.g.
> [[[daybarometer]]]
> barometer
> forecast_barometer
> data_type = barometer
> data_binding = dwd_binding
> label = ' '
> color = blue
> And to draw that forecast data I use my new option "time_offset = 36000  # 
> 10 hours". It's intention is to use the additional 100pixel to be filled by 
> forecast.
> See my full skin.conf appended here.
>
> Regards, Michael
>
>
> gjr80 schrieb am Montag, 1. Januar 2024 um 21:46:42 UTC+1:
>
>> Thank you, so that is the code, just need the plot definition. In fact, 
>> the entire [ImageGenerator] stanza from the config file in use would be 
>> best.
>>
>> Gary
>>
>> On Monday 1 January 2024 at 23:19:52 UTC+10 miwa...@googlemail.com wrote:
>>
>>> My code is available as a (rejected) pull request 
>>> https://github.com/weewx/weewx/pull/906 - but the code itself works 
>>> fine. It enhances the timescale some days into the future to plot forecast 
>>> data. See my first post for a sample (only forecast data is plotted, 
>>> measurement data are missing). I assume that my change has a sideeffect 
>>> when weewx checks if there is data to be drawn. But I have no idea why my 
>>> problem only arise for the measurement data. From the sample you clearly 
>>> see that the forecast data contains data from 2023 and 2024, and is 
>>> plotted. The measuretdata of course only contains data from the past. And 
>>> even images where no forecast data is to be plotted (e. g dayUV) are 
>>> missing completely, as soon as the timescale has parts in 2024 and current 
>>> time is 2023.
>>>
>>> And the problem is difficult to reproduce - as soon as the measurement 
>>> data has reached 2024, even images generated for old times are fine. 
>>>
>>> gjr80 schrieb am Montag, 1. Januar 2024 um 11:19:42 UTC+1:
>>>
>>>> I suspect you will not get too much feedback of value until you post 
>>>> the exact code you are using along with the plot definition from 
>>>> skin.conf. 
>>>> The post you linked is very general in nature and it's not clear if the 
>>>> code you are using is

Re: [weewx-user] Re: empty week images due to end of year?

['Michael Waldor' via weewx-user]

Thanks for your intrest in my problem. I do have two major changes within 
section [imagegenerator]. I've increased the image_width from 500 to 600. 
And I've added a second line within some images to include forcast data 
from a different database like e.g.
[[[daybarometer]]]
barometer
forecast_barometer
data_type = barometer
data_binding = dwd_binding
label = ' '
color = blue
And to draw that forecast data I use my new option "time_offset = 36000  # 
10 hours". It's intention is to use the additional 100pixel to be filled by 
forecast.
See my full skin.conf appended here.

Regards, Michael


gjr80 schrieb am Montag, 1. Januar 2024 um 21:46:42 UTC+1:

> Thank you, so that is the code, just need the plot definition. In fact, 
> the entire [ImageGenerator] stanza from the config file in use would be 
> best.
>
> Gary
>
> On Monday 1 January 2024 at 23:19:52 UTC+10 miwa...@googlemail.com wrote:
>
>> My code is available as a (rejected) pull request 
>> https://github.com/weewx/weewx/pull/906 - but the code itself works 
>> fine. It enhances the timescale some days into the future to plot forecast 
>> data. See my first post for a sample (only forecast data is plotted, 
>> measurement data are missing). I assume that my change has a sideeffect 
>> when weewx checks if there is data to be drawn. But I have no idea why my 
>> problem only arise for the measurement data. From the sample you clearly 
>> see that the forecast data contains data from 2023 and 2024, and is 
>> plotted. The measuretdata of course only contains data from the past. And 
>> even images where no forecast data is to be plotted (e. g dayUV) are 
>> missing completely, as soon as the timescale has parts in 2024 and current 
>> time is 2023.
>>
>> And the problem is difficult to reproduce - as soon as the measurement 
>> data has reached 2024, even images generated for old times are fine. 
>>
>> gjr80 schrieb am Montag, 1. Januar 2024 um 11:19:42 UTC+1:
>>
>>> I suspect you will not get too much feedback of value until you post the 
>>> exact code you are using along with the plot definition from skin.conf. The 
>>> post you linked is very general in nature and it's not clear if the code 
>>> you are using is that same as the PRs you submitted or otherwise. I am 
>>> happy to have a look through your code but I don't want to be chasing my 
>>> tail or going down the wrong path.
>>>
>>> Gary
>>> On Monday 1 January 2024 at 18:10:10 UTC+10 miwa...@googlemail.com 
>>> wrote:
>>>
>>>> As expected all images are fine as soon as current time has reached the 
>>>> new year 2024. To be more precise - it has to be 5 min past midnight 
>>>> before 
>>>> the images are fine.
>>>>
>>>> I've  tried to understand the logic within imagegenerator.py near its 
>>>> call of scaletime. Since the x-axis is labelled fine & day/night rendering 
>>>> works I assume that x_domain is calculated correctly. 
>>>> There is a loop over all line_name - it might miss the entry for 
>>>> measured data. Here I should debug, but:
>>>>
>>>> I've tried to reproduce my problems using e.g.
>>>>
>>>> sudo wee_reports --date=2023-12-31 --time=22:00
>>>>
>>>> Now it is generated perfectly as expected. Of course I do no longer 
>>>> have the same input data - the measurement data now is available for times 
>>>> within 2024, and the forecast data is more recent. Thus it's more 
>>>> difficult 
>>>> to reproduce the problem - I've to use older weewx.sdb (luckily I do have 
>>>> a 
>>>> recent backup)
>>>>
>>>> BTW Happy new year, Michael
>>>>
>>>> Michael Waldor schrieb am Sonntag, 31. Dezember 2023 um 20:05:58 UTC+1:
>>>>
>>>>> I would agree, but why is the forecast data drawn fine and only the 
>>>>> measured data not? My change to scaletime only calculates the time range 
>>>>> - 
>>>>> and that looks fine to me (see the included image within my first post). 
>>>>> scaletime does return a triple of data - start, stop, and stepwidth. 
>>>>> Works 
>>>>> fine for forecast. AND works fine if there is no change of the year. I 
>>>>> assume furthermore that scaletime does not use any global variables. But 
>>>>> your program is very clean designed, thus I do not expect, that scaletime 
>>>>

Re: [weewx-user] Re: empty week images due to end of year?

['Michael Waldor' via weewx-user]

My code is available as a (rejected) pull request 
https://github.com/weewx/weewx/pull/906 - but the code itself works fine. 
It enhances the timescale some days into the future to plot forecast data. 
See my first post for a sample (only forecast data is plotted, measurement 
data are missing). I assume that my change has a sideeffect when weewx 
checks if there is data to be drawn. But I have no idea why my problem only 
arise for the measurement data. From the sample you clearly see that the 
forecast data contains data from 2023 and 2024, and is plotted. The 
measuretdata of course only contains data from the past. And even images 
where no forecast data is to be plotted (e. g dayUV) are missing 
completely, as soon as the timescale has parts in 2024 and current time is 
2023.

And the problem is difficult to reproduce - as soon as the measurement data 
has reached 2024, even images generated for old times are fine. 

gjr80 schrieb am Montag, 1. Januar 2024 um 11:19:42 UTC+1:

> I suspect you will not get too much feedback of value until you post the 
> exact code you are using along with the plot definition from skin.conf. The 
> post you linked is very general in nature and it's not clear if the code 
> you are using is that same as the PRs you submitted or otherwise. I am 
> happy to have a look through your code but I don't want to be chasing my 
> tail or going down the wrong path.
>
> Gary
> On Monday 1 January 2024 at 18:10:10 UTC+10 miwa...@googlemail.com wrote:
>
>> As expected all images are fine as soon as current time has reached the 
>> new year 2024. To be more precise - it has to be 5 min past midnight before 
>> the images are fine.
>>
>> I've  tried to understand the logic within imagegenerator.py near its 
>> call of scaletime. Since the x-axis is labelled fine & day/night rendering 
>> works I assume that x_domain is calculated correctly. 
>> There is a loop over all line_name - it might miss the entry for measured 
>> data. Here I should debug, but:
>>
>> I've tried to reproduce my problems using e.g.
>>
>> sudo wee_reports --date=2023-12-31 --time=22:00
>>
>> Now it is generated perfectly as expected. Of course I do no longer have 
>> the same input data - the measurement data now is available for times 
>> within 2024, and the forecast data is more recent. Thus it's more difficult 
>> to reproduce the problem - I've to use older weewx.sdb (luckily I do have a 
>> recent backup)
>>
>> BTW Happy new year, Michael
>>
>> Michael Waldor schrieb am Sonntag, 31. Dezember 2023 um 20:05:58 UTC+1:
>>
>>> I would agree, but why is the forecast data drawn fine and only the 
>>> measured data not? My change to scaletime only calculates the time range - 
>>> and that looks fine to me (see the included image within my first post). 
>>> scaletime does return a triple of data - start, stop, and stepwidth. Works 
>>> fine for forecast. AND works fine if there is no change of the year. I 
>>> assume furthermore that scaletime does not use any global variables. But 
>>> your program is very clean designed, thus I do not expect, that scaletime 
>>> could create sideeffects. Tomorrow I'll know more... 
>>>
>>> Tom Keffer schrieb am Sonntag, 31. Dezember 2023 um 16:40:55 UTC+1:
>>>
>>>> Your modified version of scaletime() is surely causing the problem. Its 
>>>> semantics were never clear to me, and now it appears we're discovering the 
>>>> side effects. 
>>>>
>>>> If you have a debugger, use it to step through running wee_reports. It 
>>>> will probably become evident what the problem is.
>>>>
>>>> On Sun, Dec 31, 2023 at 7:17 AM 'Michael Waldor' via weewx-user <
>>>> weewx...@googlegroups.com> wrote:
>>>>
>>>>> And since now I encounter the same problem with my day images. And the 
>>>>> timescale is extended into the first hours of next year. Thus I'm quite 
>>>>> confident that my problems will disappear as soon as the next year 
>>>>> starts. 
>>>>>
>>>>> To me it looks as if the access to weewx.sdb searches at a wrong time. 
>>>>> Sadly I can't look deeper to debug that. There are no error messages 
>>>>> within 
>>>>> journalctl.
>>>>>
>>>>> I'm using two sqlite DBs - the original weewx.sdb of course and a 
>>>>> second one with forecast data. Maybe if the border of a year is crossed 
>>>>> the 
>>>>> weewx.sdb becomes unavailable? I can even report the time - it happens 
>>>>

Re: [weewx-user] Re: empty week images due to end of year?

['Michael Waldor' via weewx-user]

As expected all images are fine as soon as current time has reached the new 
year 2024. To be more precise - it has to be 5 min past midnight before the 
images are fine.

I've  tried to understand the logic within imagegenerator.py near its call 
of scaletime. Since the x-axis is labelled fine & day/night rendering works 
I assume that x_domain is calculated correctly. 
There is a loop over all line_name - it might miss the entry for measured 
data. Here I should debug, but:

I've tried to reproduce my problems using e.g.

sudo wee_reports --date=2023-12-31 --time=22:00

Now it is generated perfectly as expected. Of course I do no longer have 
the same input data - the measurement data now is available for times 
within 2024, and the forecast data is more recent. Thus it's more difficult 
to reproduce the problem - I've to use older weewx.sdb (luckily I do have a 
recent backup)

BTW Happy new year, Michael

Michael Waldor schrieb am Sonntag, 31. Dezember 2023 um 20:05:58 UTC+1:

> I would agree, but why is the forecast data drawn fine and only the 
> measured data not? My change to scaletime only calculates the time range - 
> and that looks fine to me (see the included image within my first post). 
> scaletime does return a triple of data - start, stop, and stepwidth. Works 
> fine for forecast. AND works fine if there is no change of the year. I 
> assume furthermore that scaletime does not use any global variables. But 
> your program is very clean designed, thus I do not expect, that scaletime 
> could create sideeffects. Tomorrow I'll know more... 
>
> Tom Keffer schrieb am Sonntag, 31. Dezember 2023 um 16:40:55 UTC+1:
>
>> Your modified version of scaletime() is surely causing the problem. Its 
>> semantics were never clear to me, and now it appears we're discovering the 
>> side effects. 
>>
>> If you have a debugger, use it to step through running wee_reports. It 
>> will probably become evident what the problem is.
>>
>> On Sun, Dec 31, 2023 at 7:17 AM 'Michael Waldor' via weewx-user <
>> weewx...@googlegroups.com> wrote:
>>
>>> And since now I encounter the same problem with my day images. And the 
>>> timescale is extended into the first hours of next year. Thus I'm quite 
>>> confident that my problems will disappear as soon as the next year starts. 
>>>
>>> To me it looks as if the access to weewx.sdb searches at a wrong time. 
>>> Sadly I can't look deeper to debug that. There are no error messages within 
>>> journalctl.
>>>
>>> I'm using two sqlite DBs - the original weewx.sdb of course and a second 
>>> one with forecast data. Maybe if the border of a year is crossed the 
>>> weewx.sdb becomes unavailable? I can even report the time - it happens 
>>> exactly at 14:00. Afterwards the timeaxis starts to go  till 3 o'clock in 
>>> the night (till 14:00 it goes till midnight). And only forecast data is 
>>> drawn (but containing data from today and tomorrow - no problem with year 
>>> boundary). Even dayUV is no longer updated despite not using forecast data 
>>> at all (but with the same timeaxis crossing the year boundary). 
>>>
>>> Michael Waldor schrieb am Samstag, 30. Dezember 2023 um 10:20:05 UTC+1:
>>>
>>>> Since (today?) all week images contain no measured data, only the 
>>>> forecast data are visible.
>>>> [image: weektempdew.png]
>>>> I have to admit that I've patched utilities.py to shift the right 
>>>> border of the timescale into the "future". It works fine all over the 
>>>> year. 
>>>> To my surprise all (measured) data is missing. If I drop my shift the data 
>>>> re-appears. But - as you see from the image above - the timescale looks 
>>>> fine and is exactly as intended. I've even debugged my modification for 
>>>> the 
>>>> current date, and everythind works as intended. But why are there no data 
>>>> from the past? Even from the above image one can see that 
>>>> imagegenerator.py 
>>>> can cross the year boundary perfectly.
>>>>
>>>> And there IS data available within the past (I've checked this by 
>>>> dropping my change, and I've got a plot between 23. and 31.).
>>>>
>>>> Why does weewx don't see the missing data? Images without forecast data 
>>>> aren't generated at all, e.g. weekUV.
>>>>
>>>> For more details on my patch see 
>>>> https://groups.google.com/g/weewx-user/c/76qdbSy3bbQ/m/oIlk3sKrBgAJ
>>>>
>>>> Regards, Michael
>>>>
>>>> -- 
>>> You rece

Re: [weewx-user] Re: empty week images due to end of year?

['Michael Waldor' via weewx-user]

I would agree, but why is the forecast data drawn fine and only the 
measured data not? My change to scaletime only calculates the time range - 
and that looks fine to me (see the included image within my first post). 
scaletime does return a triple of data - start, stop, and stepwidth. Works 
fine for forecast. AND works fine if there is no change of the year. I 
assume furthermore that scaletime does not use any global variables. But 
your program is very clean designed, thus I do not expect, that scaletime 
could create sideeffects. Tomorrow I'll know more... 

Tom Keffer schrieb am Sonntag, 31. Dezember 2023 um 16:40:55 UTC+1:

> Your modified version of scaletime() is surely causing the problem. Its 
> semantics were never clear to me, and now it appears we're discovering the 
> side effects. 
>
> If you have a debugger, use it to step through running wee_reports. It 
> will probably become evident what the problem is.
>
> On Sun, Dec 31, 2023 at 7:17 AM 'Michael Waldor' via weewx-user <
> weewx...@googlegroups.com> wrote:
>
>> And since now I encounter the same problem with my day images. And the 
>> timescale is extended into the first hours of next year. Thus I'm quite 
>> confident that my problems will disappear as soon as the next year starts. 
>>
>> To me it looks as if the access to weewx.sdb searches at a wrong time. 
>> Sadly I can't look deeper to debug that. There are no error messages within 
>> journalctl.
>>
>> I'm using two sqlite DBs - the original weewx.sdb of course and a second 
>> one with forecast data. Maybe if the border of a year is crossed the 
>> weewx.sdb becomes unavailable? I can even report the time - it happens 
>> exactly at 14:00. Afterwards the timeaxis starts to go  till 3 o'clock in 
>> the night (till 14:00 it goes till midnight). And only forecast data is 
>> drawn (but containing data from today and tomorrow - no problem with year 
>> boundary). Even dayUV is no longer updated despite not using forecast data 
>> at all (but with the same timeaxis crossing the year boundary). 
>>
>> Michael Waldor schrieb am Samstag, 30. Dezember 2023 um 10:20:05 UTC+1:
>>
>>> Since (today?) all week images contain no measured data, only the 
>>> forecast data are visible.
>>> [image: weektempdew.png]
>>> I have to admit that I've patched utilities.py to shift the right border 
>>> of the timescale into the "future". It works fine all over the year. To my 
>>> surprise all (measured) data is missing. If I drop my shift the data 
>>> re-appears. But - as you see from the image above - the timescale looks 
>>> fine and is exactly as intended. I've even debugged my modification for the 
>>> current date, and everythind works as intended. But why are there no data 
>>> from the past? Even from the above image one can see that imagegenerator.py 
>>> can cross the year boundary perfectly.
>>>
>>> And there IS data available within the past (I've checked this by 
>>> dropping my change, and I've got a plot between 23. and 31.).
>>>
>>> Why does weewx don't see the missing data? Images without forecast data 
>>> aren't generated at all, e.g. weekUV.
>>>
>>> For more details on my patch see 
>>> https://groups.google.com/g/weewx-user/c/76qdbSy3bbQ/m/oIlk3sKrBgAJ
>>>
>>> Regards, Michael
>>>
>>> -- 
>> 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/b4d802ee-c929-4ebb-aee9-e52c040a24c0n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/weewx-user/b4d802ee-c929-4ebb-aee9-e52c040a24c0n%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/2f363b20-7d08-4db2-9a0b-b890d0e962dcn%40googlegroups.com.

[weewx-user] Re: empty week images due to end of year?

['Michael Waldor' via weewx-user]

And since now I encounter the same problem with my day images. And the 
timescale is extended into the first hours of next year. Thus I'm quite 
confident that my problems will disappear as soon as the next year starts. 

To me it looks as if the access to weewx.sdb searches at a wrong time. 
Sadly I can't look deeper to debug that. There are no error messages within 
journalctl.

I'm using two sqlite DBs - the original weewx.sdb of course and a second 
one with forecast data. Maybe if the border of a year is crossed the 
weewx.sdb becomes unavailable? I can even report the time - it happens 
exactly at 14:00. Afterwards the timeaxis starts to go  till 3 o'clock in 
the night (till 14:00 it goes till midnight). And only forecast data is 
drawn (but containing data from today and tomorrow - no problem with year 
boundary). Even dayUV is no longer updated despite not using forecast data 
at all (but with the same timeaxis crossing the year boundary). 

Michael Waldor schrieb am Samstag, 30. Dezember 2023 um 10:20:05 UTC+1:

> Since (today?) all week images contain no measured data, only the forecast 
> data are visible.
> [image: weektempdew.png]
> I have to admit that I've patched utilities.py to shift the right border 
> of the timescale into the "future". It works fine all over the year. To my 
> surprise all (measured) data is missing. If I drop my shift the data 
> re-appears. But - as you see from the image above - the timescale looks 
> fine and is exactly as intended. I've even debugged my modification for the 
> current date, and everythind works as intended. But why are there no data 
> from the past? Even from the above image one can see that imagegenerator.py 
> can cross the year boundary perfectly.
>
> And there IS data available within the past (I've checked this by dropping 
> my change, and I've got a plot between 23. and 31.).
>
> Why does weewx don't see the missing data? Images without forecast data 
> aren't generated at all, e.g. weekUV.
>
> For more details on my patch see 
> https://groups.google.com/g/weewx-user/c/76qdbSy3bbQ/m/oIlk3sKrBgAJ
>
> Regards, Michael
>
>

-- 
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/b4d802ee-c929-4ebb-aee9-e52c040a24c0n%40googlegroups.com.

[weewx-user] empty week images due to end of year?

['Michael Waldor' via weewx-user]

Since (today?) all week images contain no measured data, only the forecast 
data are visible.
[image: weektempdew.png]
I have to admit that I've patched utilities.py to shift the right border of 
the timescale into the "future". It works fine all over the year. To my 
surprise all (measured) data is missing. If I drop my shift the data 
re-appears. But - as you see from the image above - the timescale looks 
fine and is exactly as intended. I've even debugged my modification for the 
current date, and everythind works as intended. But why are there no data 
from the past? Even from the above image one can see that imagegenerator.py 
can cross the year boundary perfectly.

And there IS data available within the past (I've checked this by dropping 
my change, and I've got a plot between 23. and 31.).

Why does weewx don't see the missing data? Images without forecast data 
aren't generated at all, e.g. weekUV.

For more details on my patch see 
https://groups.google.com/g/weewx-user/c/76qdbSy3bbQ/m/oIlk3sKrBgAJ

Regards, Michael

-- 
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/4d414da7-f81f-476f-8fbd-9b81da25b86en%40googlegroups.com.

Re: [weewx-user] Unrecoverable error "no such table: forecast_day_wind"

['Michael Waldor' via weewx-user]

Just as a final conclusion - during this night the weekwindvec diagram has 
been created also at 3:00 as expected (no longer error messages within 
journalctl).
[image: weekwindvec.png]
Its timestamp 03:00:00 proves it (to be compared with 23:00:00 some posts 
ago without the xtypes.py fix).

Michael Waldor schrieb am Samstag, 18. November 2023 um 07:54:22 UTC+1:

> Heureka - your fix within xtypes.py did the trick. I no longer get errors 
> during the night. Sadly, I forgot to store nightly copies of the weewx HTML 
> output, thus I currently can't confirm if the weekwindvec is really 
> created. But I'm quite sure:-) 
>
> Thank you very much, Michael
>
>
> Karen K schrieb am Freitag, 17. November 2023 um 18:23:55 UTC+1:
>
>> Tom Keffer schrieb am Freitag, 17. November 2023 um 14:43:37 UTC+1:
>>
>> I don't know why this is working for Karen, but not Michael.
>>
>> In any case, try this version of xtypes.py. It explicitly tests whether a 
>> daily summary is available when calculating wind vectors.
>>
>>
>> I guess, because I do not plot wind vectors or because I do not mix 
>> measurements with forecast data.
>>  
>>
>

-- 
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/493467cf-f365-45eb-be9b-cfb6db44959fn%40googlegroups.com.

Re: [weewx-user] Unrecoverable error "no such table: forecast_day_wind"

['Michael Waldor' via weewx-user]

Heureka - your fix within xtypes.py did the trick. I no longer get errors 
during the night. Sadly, I forgot to store nightly copies of the weewx HTML 
output, thus I currently can't confirm if the weekwindvec is really 
created. But I'm quite sure:-) 

Thank you very much, Michael


Karen K schrieb am Freitag, 17. November 2023 um 18:23:55 UTC+1:

> Tom Keffer schrieb am Freitag, 17. November 2023 um 14:43:37 UTC+1:
>
> I don't know why this is working for Karen, but not Michael.
>
> In any case, try this version of xtypes.py. It explicitly tests whether a 
> daily summary is available when calculating wind vectors.
>
>
> I guess, because I do not plot wind vectors or because I do not mix 
> measurements with forecast data.
>  
>

-- 
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/69ba2945-c6b5-41d3-b0be-ef6694692f34n%40googlegroups.com.

Re: [weewx-user] Unrecoverable error "no such table: forecast_day_wind"

['Michael Waldor' via weewx-user]

Thanks for your fix. It's now activated within my environment (I did 
restart weewx afterwards).
Tomorrow I'll report back...

Tom Keffer schrieb am Freitag, 17. November 2023 um 14:43:37 UTC+1:

> I don't know why this is working for Karen, but not Michael.
>
> In any case, try this version of xtypes.py. It explicitly tests whether a 
> daily summary is available when calculating wind vectors.
>
> -tk
>
> On Thu, Nov 16, 2023 at 10:54 PM 'Michael Waldor' via weewx-user <
> weewx...@googlegroups.com> wrote:
>
>> I have to admit that I do not understand the details howto setup sqlite 
>> databases within weewx - I've tried to follow the recipe for DWD forecasts 
>> as given within https://github.com/roe-dl/weewx-DWD , and I did retain 
>> all database settings as given by standard delivery weewx.conf (I do a 
>> manual diff with my private copy of weewx.conf each time when I update 
>> weewx to a new release).
>>
>> Here the full part w.r.t. sqlite from my weewx.conf (comments dropped)
>> [DataBindings]
>>  [[wx_binding]]
>>  database = archive_sqlite
>>  table_name = archive
>>  manager = weewx.manager.DaySummaryManager
>>  schema = schemas.wview_extended.schema
>>
>> [[dwd_binding]]
>> database = dwd_sqlite
>> table_name = forecast
>> manager = weewx.manager.Manager
>> schema = schemas.dwd.schema
>>
>> [Databases]
>> [[archive_sqlite]]
>> database_name = weewx.sdb
>> database_type = SQLite
>>
>> [[dwd_sqlite]]
>> database_name = dwd-forecast-K2714.sdb
>> database_type = SQLite
>> 
>> And the forecast schema /usr/share/weewx/schemas/dwd.py contains
>> schema = [('dateTime','INTEGER NOT NULL PRIMARY KEY'),
>>   ('usUnits','INTEGER NOT NULL'),
>>   ('interval','INTEGER NOT NULL')]
>>
>> The sqlite DB itself is stored at /var/lib/weewx/dwd-forecast-K2714.sdb 
>> side by side with weewx.sdb
>> echo .schema | sqlite3 /var/lib/weewx/dwd-forecast-K2714.sdb  returns
>>
>> CREATE TABLE forecast (dateTime INTEGER NOT NULL PRIMARY KEY,usUnits 
>> INTEGER NOT
>> NULL,interval INTEGER NOT NULL,hour INTEGER,outTemp REAL,dewpoint 
>> REAL,outHumid
>> ity REAL,windchill REAL,heatindex REAL,windDir REAL,windSpeed 
>> REAL,windGust REAL
>> ,pop REAL,cloudcover REAL,barometer REAL,rain REAL,rainDur 
>> REAL,sunshineDur REAL
>> ,visibility REAL,ww INTEGER);
>>
>>
>> Tom Keffer schrieb am Donnerstag, 16. November 2023 um 23:52:17 UTC+1:
>>
>>> First weewx.conf:
>>>> [[dwd_binding]]
>>>> database = dwd_sqlite
>>>> table_name = forecast
>>>> manager = weewx.manager.Manager
>>>> schema = schemas.dwd.schema
>>>>
>>>
>>> You are using the database manager weewx.manager.Manager for the 
>>> "forecast" table. That manager will not include daily summaries, which is 
>>> why you are getting the error that the daily summary table 
>>> forecast_day_wind is missing. Is this intentional?
>>>
>>> Nevertheless, it should be possible to calculate the wind vectors 
>>> without the daily summaries. It would be frightfully slow, but it would 
>>> work. 
>>>
>>> Two questions:
>>>
>>> 1. What does the schema schemas.dwd.schema look like?
>>> 2. What is the actual schema used in the database used by forecast? You 
>>> didn't give enough information for me to determine the path to the actual 
>>> database, so you'll have to do that.
>>>
>>> echo .schema | sqlite3 path-to-the-forecast-database
>>>
>>> -tk
>>>
>>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "weewx-user" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to weewx-user+...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/7c1b30f5-638f-4d17-96e9-3a60e0559b03n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/weewx-user/7c1b30f5-638f-4d17-96e9-3a60e0559b03n%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

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

Re: [weewx-user] Unrecoverable error "no such table: forecast_day_wind"

['Michael Waldor' via weewx-user]

I have to admit that I do not understand the details howto setup sqlite 
databases within weewx - I've tried to follow the recipe for DWD forecasts 
as given within https://github.com/roe-dl/weewx-DWD , and I did retain all 
database settings as given by standard delivery weewx.conf (I do a manual 
diff with my private copy of weewx.conf each time when I update weewx to a 
new release).

Here the full part w.r.t. sqlite from my weewx.conf (comments dropped)
[DataBindings]
 [[wx_binding]]
 database = archive_sqlite
 table_name = archive
 manager = weewx.manager.DaySummaryManager
 schema = schemas.wview_extended.schema

[[dwd_binding]]
database = dwd_sqlite
table_name = forecast
manager = weewx.manager.Manager
schema = schemas.dwd.schema

[Databases]
[[archive_sqlite]]
database_name = weewx.sdb
database_type = SQLite

[[dwd_sqlite]]
database_name = dwd-forecast-K2714.sdb
database_type = SQLite

And the forecast schema /usr/share/weewx/schemas/dwd.py contains
schema = [('dateTime','INTEGER NOT NULL PRIMARY KEY'),
  ('usUnits','INTEGER NOT NULL'),
  ('interval','INTEGER NOT NULL')]

The sqlite DB itself is stored at /var/lib/weewx/dwd-forecast-K2714.sdb 
side by side with weewx.sdb
echo .schema | sqlite3 /var/lib/weewx/dwd-forecast-K2714.sdb  returns

CREATE TABLE forecast (dateTime INTEGER NOT NULL PRIMARY KEY,usUnits 
INTEGER NOT
NULL,interval INTEGER NOT NULL,hour INTEGER,outTemp REAL,dewpoint 
REAL,outHumid
ity REAL,windchill REAL,heatindex REAL,windDir REAL,windSpeed REAL,windGust 
REAL
,pop REAL,cloudcover REAL,barometer REAL,rain REAL,rainDur REAL,sunshineDur 
REAL
,visibility REAL,ww INTEGER);


Tom Keffer schrieb am Donnerstag, 16. November 2023 um 23:52:17 UTC+1:

> First weewx.conf:
>> [[dwd_binding]]
>> database = dwd_sqlite
>> table_name = forecast
>> manager = weewx.manager.Manager
>> schema = schemas.dwd.schema
>>
>
> You are using the database manager weewx.manager.Manager for the 
> "forecast" table. That manager will not include daily summaries, which is 
> why you are getting the error that the daily summary table 
> forecast_day_wind is missing. Is this intentional?
>
> Nevertheless, it should be possible to calculate the wind vectors without 
> the daily summaries. It would be frightfully slow, but it would work. 
>
> Two questions:
>
> 1. What does the schema schemas.dwd.schema look like?
> 2. What is the actual schema used in the database used by forecast? You 
> didn't give enough information for me to determine the path to the actual 
> database, so you'll have to do that.
>
> echo .schema | sqlite3 path-to-the-forecast-database
>
> -tk
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/7c1b30f5-638f-4d17-96e9-3a60e0559b03n%40googlegroups.com.

Re: [weewx-user] Unrecoverable error "no such table: forecast_day_wind"

['Michael Waldor' via weewx-user]

I believe that your item (1) can't be my problem because all diagrams have 
the correct (and current) timestamp below their time axis. Within my 
failing sample diagram in my previous post you can see the timestamp 23:00 
where it should be 03:00. And of course after 5:15 even that diagram is 
updated and marked with the correct and current timestamp. To enforce 
recreation of monrh/year diagrams I intentonally cleared all diagrams 
within /var/www/html/weewx, and weewx creatwd all diagrams during next 
report generation cycle. 

Graham Eddy schrieb am Donnerstag, 16. November 2023 um 09:55:39 UTC+1:

> suggestions:
>  (1) maybe the weekly graph is only being calculated in your 0-5 daily 
> hour interval → really failing all the time. try hourly or daily graph to 
> verify it works during those & other hours
>  (2) maybe another deeper exception is happening which happens to be 
> percolated up as sqlError that reports the last sqlite error not this error
> *⊣GE⊢*
>
> On 16 Nov 2023, at 5:49 pm, 'Michael Waldor' via weewx-user <
> weewx...@googlegroups.com> wrote:
>
> Normally, it uses the "wx_binding" database binding to do this, which is 
> normally pointed at the "archive" table. For whatever reason, your 
> installation is attempting to do this with the "forecast" table. It could 
> be that you are using the wrong binding, or it could be that the wx_binding 
> is pointing to the "forecast" table.
>
>
>

-- 
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/6912d5ab-5ff5-4230-a41b-a768257cb8cen%40googlegroups.com.

Re: [weewx-user] Unrecoverable error "no such table: forecast_day_wind"

['Michael Waldor' via weewx-user]

One additional hint: I've checked if there is forecast info available at 
the right border of my timeline. Sadly, it is - the forcast roughly covers 
10 days into the future w.r.t. current date. And most other week diagrams 
are rendered correctly when weekwindvec is failing.



Michael Waldor schrieb am Donnerstag, 16. November 2023 um 07:49:38 UTC+1:

> During this night I did save the weewx HTML output from 3 o'clock. And now 
> I know what images are not updated - the weekwindvec diagram (and all week 
> diagrams being rendered "afterwards").
>
> The time axis of all diagrams are fine, i.e. my tweak of utilities.py 
> seems NOT to be the cause of my problem.
>
> Since the rendering of even the weekwindvec diagram  works fine if the 
> current time is later then 5:15 I guess that there might be a hidden bug 
> within imagegenerator.py itself. I have no idea howto debug that. I only 
> know that imagegenerator fails for weekwindvec if the current time is 
> between 0:00 and 5:15 - exactly during that time the forecast DB contains 
> data from the previous day. But that doesn't disturb creation of daywindvec 
> being fine at 3:00.
>
> As a starter I give here the most relevant parts of the involved 
> configuration files.
> First weewx.conf:
> [[dwd_binding]]
> database = dwd_sqlite
> table_name = forecast
> manager = weewx.manager.Manager
> schema = schemas.dwd.schema
>
> Next my skin.conf:
> [[[weekwindvec]]]
> windvec
> plot_type = vector
> forecast_windvec
> data_type = windvec
> data_binding = dwd_binding
> plot_type = vector
> label = ' '
> color = blue
>
> BTW, within the original Seasons skin for week/month/year [[[wind]]] is 
> used and should be replaced by [[[windDir]]]
>
> And below you see the not updated diagram itself - it has timestamp 23:00, 
> but should be 3:00. Here you also see my intention of merging data from two 
> DBs - the "real" life data are in Seasons blue, and the forecast data are 
> in dark blue. Keep in mind current date is 11-14, and you see data till 
> 11-18 from forecast. There is a small overlap (not visible here) since the 
> forecast data contains "old outdated" data of some hours - but I like that 
> to compare outdated forecast with real data.
> [image: weekwindvec.png]
> Tom Keffer schrieb am Mittwoch, 15. November 2023 um 16:24:52 UTC+1:
>
>> Hard to say. Plots are regenerated only as often as their aggregation 
>> interval. Perhaps it is the "year" windvec plot that is failing: it would 
>> be regenerated only once a day.
>>
>> Just guessing. You have a complicated configuration and we haven't seen 
>> your configuration files.
>>
>> On Wed, Nov 15, 2023 at 7:10 AM 'Michael Waldor' via weewx-user <
>> weewx...@googlegroups.com> wrote:
>>
>>> Thanks for your quick reply. But why does my setup work fine after 5:15 
>>> all over the day? From my perspective a wrong configuration should fail 
>>> always. 
>>>
>>> Tom Keffer schrieb am Mittwoch, 15. November 2023 um 14:12:31 UTC+1:
>>>
>>>> Imagegenerator is trying to calculate a wind vector. This typically 
>>>> happens for a plot with a spec that looks something like this:
>>>>
>>>>
>>>>
>>>> *[[[weekwindvec]]]windvecplot_type = vector*
>>>>
>>>> Normally, it uses the "wx_binding" database binding to do this, which 
>>>> is normally pointed at the "archive" table. For whatever reason, your 
>>>> installation is attempting to do this with the "forecast" table. It could 
>>>> be that you are using the wrong binding, or it could be that the 
>>>> wx_binding 
>>>> is pointing to the "forecast" table.
>>>>
>>>>
>>>>
>>>> On Wed, Nov 15, 2023 at 1:12 AM 'Michael Waldor' via weewx-user <
>>>> weewx...@googlegroups.com> wrote:
>>>>
>>>>> I seem to have a very specific problem due to my complex changes 
>>>>> within weewx. First I'll shortly describe my problem, then I'll explain 
>>>>> my 
>>>>> weewx environment:
>>>>>
>>>>> My problem: weewx 4.10.2 is working fine during daytimes, but 
>>>>> imagegenerator fails daily between 0:00 and 5:15 all 5min with the same 
>>>>> set 
>>>>> of error messages, e.g.
>>>>>
>>>>> N

Re: [weewx-user] Unrecoverable error "no such table: forecast_day_wind"

['Michael Waldor' via weewx-user]

During this night I did save the weewx HTML output from 3 o'clock. And now 
I know what images are not updated - the weekwindvec diagram (and all week 
diagrams being rendered "afterwards").

The time axis of all diagrams are fine, i.e. my tweak of utilities.py seems 
NOT to be the cause of my problem.

Since the rendering of even the weekwindvec diagram  works fine if the 
current time is later then 5:15 I guess that there might be a hidden bug 
within imagegenerator.py itself. I have no idea howto debug that. I only 
know that imagegenerator fails for weekwindvec if the current time is 
between 0:00 and 5:15 - exactly during that time the forecast DB contains 
data from the previous day. But that doesn't disturb creation of daywindvec 
being fine at 3:00.

As a starter I give here the most relevant parts of the involved 
configuration files.
First weewx.conf:
[[dwd_binding]]
database = dwd_sqlite
table_name = forecast
manager = weewx.manager.Manager
schema = schemas.dwd.schema

Next my skin.conf:
[[[weekwindvec]]]
windvec
plot_type = vector
forecast_windvec
data_type = windvec
data_binding = dwd_binding
plot_type = vector
label = ' '
color = blue

BTW, within the original Seasons skin for week/month/year [[[wind]]] is 
used and should be replaced by [[[windDir]]]

And below you see the not updated diagram itself - it has timestamp 23:00, 
but should be 3:00. Here you also see my intention of merging data from two 
DBs - the "real" life data are in Seasons blue, and the forecast data are 
in dark blue. Keep in mind current date is 11-14, and you see data till 
11-18 from forecast. There is a small overlap (not visible here) since the 
forecast data contains "old outdated" data of some hours - but I like that 
to compare outdated forecast with real data.
[image: weekwindvec.png]
Tom Keffer schrieb am Mittwoch, 15. November 2023 um 16:24:52 UTC+1:

> Hard to say. Plots are regenerated only as often as their aggregation 
> interval. Perhaps it is the "year" windvec plot that is failing: it would 
> be regenerated only once a day.
>
> Just guessing. You have a complicated configuration and we haven't seen 
> your configuration files.
>
> On Wed, Nov 15, 2023 at 7:10 AM 'Michael Waldor' via weewx-user <
> weewx...@googlegroups.com> wrote:
>
>> Thanks for your quick reply. But why does my setup work fine after 5:15 
>> all over the day? From my perspective a wrong configuration should fail 
>> always. 
>>
>> Tom Keffer schrieb am Mittwoch, 15. November 2023 um 14:12:31 UTC+1:
>>
>>> Imagegenerator is trying to calculate a wind vector. This typically 
>>> happens for a plot with a spec that looks something like this:
>>>
>>>
>>>
>>> *[[[weekwindvec]]]windvecplot_type = vector*
>>>
>>> Normally, it uses the "wx_binding" database binding to do this, which is 
>>> normally pointed at the "archive" table. For whatever reason, your 
>>> installation is attempting to do this with the "forecast" table. It could 
>>> be that you are using the wrong binding, or it could be that the wx_binding 
>>> is pointing to the "forecast" table.
>>>
>>>
>>>
>>> On Wed, Nov 15, 2023 at 1:12 AM 'Michael Waldor' via weewx-user <
>>> weewx...@googlegroups.com> wrote:
>>>
>>>> I seem to have a very specific problem due to my complex changes within 
>>>> weewx. First I'll shortly describe my problem, then I'll explain my weewx 
>>>> environment:
>>>>
>>>> My problem: weewx 4.10.2 is working fine during daytimes, but 
>>>> imagegenerator fails daily between 0:00 and 5:15 all 5min with the same 
>>>> set 
>>>> of error messages, e.g.
>>>>
>>>> Nov 13 00:00:33 imurr9 python3[579]: weewx[579] ERROR 
>>>> weewx.reportengine: Caught unrecoverable exception in generator 
>>>> 'weewx.imagegenerator.ImageGenerator'
>>>> Nov 13 00:00:33 imurr9 python3[579]: weewx[579] ERROR 
>>>> weewx.reportengine:   no such table: forecast_day_wind
>>>> Nov 13 00:00:33 imurr9 python3[579]: weewx[579] ERROR 
>>>> weewx.reportengine:   Traceback (most recent call last):
>>>> Nov 13 00:00:33 imurr9 python3[579]: weewx[579] ERROR 
>>>> weewx.reportengine: File 
>>>> "/usr/share/weewx/weedb/sqlite.py", line 39, in guarded_fn
>>>> Nov 13 00:00:33 imurr9 python3[579]: weewx[579] ERROR 
>>>>

Re: [weewx-user] Unrecoverable error "no such table: forecast_day_wind"

['Michael Waldor' via weewx-user]

Thanks for your quick reply. But why does my setup work fine after 5:15 all 
over the day? From my perspective a wrong configuration should fail always. 

Tom Keffer schrieb am Mittwoch, 15. November 2023 um 14:12:31 UTC+1:

> Imagegenerator is trying to calculate a wind vector. This typically 
> happens for a plot with a spec that looks something like this:
>
>
>
> *[[[weekwindvec]]]windvecplot_type = vector*
>
> Normally, it uses the "wx_binding" database binding to do this, which is 
> normally pointed at the "archive" table. For whatever reason, your 
> installation is attempting to do this with the "forecast" table. It could 
> be that you are using the wrong binding, or it could be that the wx_binding 
> is pointing to the "forecast" table.
>
>
>
> On Wed, Nov 15, 2023 at 1:12 AM 'Michael Waldor' via weewx-user <
> weewx...@googlegroups.com> wrote:
>
>> I seem to have a very specific problem due to my complex changes within 
>> weewx. First I'll shortly describe my problem, then I'll explain my weewx 
>> environment:
>>
>> My problem: weewx 4.10.2 is working fine during daytimes, but 
>> imagegenerator fails daily between 0:00 and 5:15 all 5min with the same set 
>> of error messages, e.g.
>>
>> Nov 13 00:00:33 imurr9 python3[579]: weewx[579] ERROR weewx.reportengine: 
>> Caught unrecoverable exception in generator 
>> 'weewx.imagegenerator.ImageGenerator'
>> Nov 13 00:00:33 imurr9 python3[579]: weewx[579] ERROR weewx.reportengine: 
>>   no such table: forecast_day_wind
>> Nov 13 00:00:33 imurr9 python3[579]: weewx[579] ERROR weewx.reportengine: 
>>   Traceback (most recent call last):
>> Nov 13 00:00:33 imurr9 python3[579]: weewx[579] ERROR weewx.reportengine: 
>> File "/usr/share/weewx/weedb/sqlite.py", line 39, in 
>> guarded_fn
>> Nov 13 00:00:33 imurr9 python3[579]: weewx[579] ERROR weewx.reportengine: 
>>   return fn(*args, **kwargs)
>> Nov 13 00:00:33 imurr9 python3[579]: weewx[579] ERROR weewx.reportengine: 
>> File "/usr/share/weewx/weedb/sqlite.py", line 233, in 
>> execute
>> Nov 13 00:00:33 imurr9 python3[579]: weewx[579] ERROR weewx.reportengine: 
>>   return sqlite3.Cursor.execute(self, *args, **kwargs)
>> Nov 13 00:00:33 imurr9 python3[579]: weewx[579] ERROR weewx.reportengine: 
>>   sqlite3.OperationalError: no such table: forecast_day_wind
>> Nov 13 00:00:33 imurr9 python3[579]: weewx[579] ERROR weewx.reportengine: 
>> 
>> Nov 13 00:00:33 imurr9 python3[579]: weewx[579] ERROR weewx.reportengine: 
>>   During handling of the above exception, another exception 
>> occurred:
>> Nov 13 00:00:33 imurr9 python3[579]: weewx[579] ERROR weewx.reportengine: 
>> 
>> Nov 13 00:00:33 imurr9 python3[579]: weewx[579] ERROR weewx.reportengine: 
>>   Traceback (most recent call last):
>> Nov 13 00:00:33 imurr9 python3[579]: weewx[579] ERROR weewx.reportengine: 
>> File "/usr/share/weewx/weewx/reportengine.py", line 197, in 
>> run
>> Nov 13 00:00:33 imurr9 python3[579]: weewx[579] ERROR weewx.reportengine: 
>>   obj.start()
>> Nov 13 00:00:33 imurr9 python3[579]: weewx[579] ERROR weewx.reportengine: 
>> File "/usr/share/weewx/weewx/reportengine.py", line 385, in 
>> start
>> Nov 13 00:00:33 imurr9 python3[579]: weewx[579] ERROR weewx.reportengine: 
>>   self.run()
>> Nov 13 00:00:33 imurr9 python3[579]: weewx[579] ERROR weewx.reportengine: 
>> File "/usr/share/weewx/weewx/imagegenerator.py", line 44, 
>> in run
>> Nov 13 00:00:33 imurr9 python3[579]: weewx[579] ERROR weewx.reportengine: 
>>   self.gen_images(self.gen_ts)
>> Nov 13 00:00:33 imurr9 python3[579]: weewx[579] ERROR weewx.reportengine: 
>> File "/usr/share/weewx/weewx/imagegenerator.py", line 109, 
>> in gen_images
>> Nov 13 00:00:33 imurr9 python3[579]: weewx[579] ERROR weewx.reportengine: 
>>   plot = self.gen_plot(plotgen_ts,
>> Nov 13 00:00:33 imurr9 python3[579]: weewx[579] ERROR weewx.reportengine: 
>> File "/usr/share/weewx/weewx/imagegenerator.py", line 248, 
>> in gen_plot
>> Nov 13 00:00:33 imurr9 python3[579]: weewx[579] ERROR weewx.reportengine: 
>>   start_vec_t, stop_vec_t, data_vec_t = 
>> weewx.xtypes.get_series(
>> Nov 13 00:00:33 imurr9 python3[

[weewx-user] Unrecoverable error "no such table: forecast_day_wind"

['Michael Waldor' via weewx-user]

I seem to have a very specific problem due to my complex changes within 
weewx. First I'll shortly describe my problem, then I'll explain my weewx 
environment:

My problem: weewx 4.10.2 is working fine during daytimes, but 
imagegenerator fails daily between 0:00 and 5:15 all 5min with the same set 
of error messages, e.g.

Nov 13 00:00:33 imurr9 python3[579]: weewx[579] ERROR weewx.reportengine: 
Caught unrecoverable exception in generator 
'weewx.imagegenerator.ImageGenerator'
Nov 13 00:00:33 imurr9 python3[579]: weewx[579] ERROR weewx.reportengine:   
    no such table: forecast_day_wind
Nov 13 00:00:33 imurr9 python3[579]: weewx[579] ERROR weewx.reportengine:   
    Traceback (most recent call last):
Nov 13 00:00:33 imurr9 python3[579]: weewx[579] ERROR weewx.reportengine:   
  File "/usr/share/weewx/weedb/sqlite.py", line 39, in 
guarded_fn
Nov 13 00:00:33 imurr9 python3[579]: weewx[579] ERROR weewx.reportengine:   
    return fn(*args, **kwargs)
Nov 13 00:00:33 imurr9 python3[579]: weewx[579] ERROR weewx.reportengine:   
  File "/usr/share/weewx/weedb/sqlite.py", line 233, in execute
Nov 13 00:00:33 imurr9 python3[579]: weewx[579] ERROR weewx.reportengine:   
    return sqlite3.Cursor.execute(self, *args, **kwargs)
Nov 13 00:00:33 imurr9 python3[579]: weewx[579] ERROR weewx.reportengine:   
    sqlite3.OperationalError: no such table: forecast_day_wind
Nov 13 00:00:33 imurr9 python3[579]: weewx[579] ERROR weewx.reportengine:   
  
Nov 13 00:00:33 imurr9 python3[579]: weewx[579] ERROR weewx.reportengine:   
    During handling of the above exception, another exception 
occurred:
Nov 13 00:00:33 imurr9 python3[579]: weewx[579] ERROR weewx.reportengine:   
  
Nov 13 00:00:33 imurr9 python3[579]: weewx[579] ERROR weewx.reportengine:   
    Traceback (most recent call last):
Nov 13 00:00:33 imurr9 python3[579]: weewx[579] ERROR weewx.reportengine:   
  File "/usr/share/weewx/weewx/reportengine.py", line 197, in 
run
Nov 13 00:00:33 imurr9 python3[579]: weewx[579] ERROR weewx.reportengine:   
    obj.start()
Nov 13 00:00:33 imurr9 python3[579]: weewx[579] ERROR weewx.reportengine:   
  File "/usr/share/weewx/weewx/reportengine.py", line 385, in 
start
Nov 13 00:00:33 imurr9 python3[579]: weewx[579] ERROR weewx.reportengine:   
    self.run()
Nov 13 00:00:33 imurr9 python3[579]: weewx[579] ERROR weewx.reportengine:   
  File "/usr/share/weewx/weewx/imagegenerator.py", line 44, in 
run
Nov 13 00:00:33 imurr9 python3[579]: weewx[579] ERROR weewx.reportengine:   
    self.gen_images(self.gen_ts)
Nov 13 00:00:33 imurr9 python3[579]: weewx[579] ERROR weewx.reportengine:   
  File "/usr/share/weewx/weewx/imagegenerator.py", line 109, in 
gen_images
Nov 13 00:00:33 imurr9 python3[579]: weewx[579] ERROR weewx.reportengine:   
    plot = self.gen_plot(plotgen_ts,
Nov 13 00:00:33 imurr9 python3[579]: weewx[579] ERROR weewx.reportengine:   
  File "/usr/share/weewx/weewx/imagegenerator.py", line 248, in 
gen_plot
Nov 13 00:00:33 imurr9 python3[579]: weewx[579] ERROR weewx.reportengine:   
    start_vec_t, stop_vec_t, data_vec_t = 
weewx.xtypes.get_series(
Nov 13 00:00:33 imurr9 python3[579]: weewx[579] ERROR weewx.reportengine:   
  File "/usr/share/weewx/weewx/xtypes.py", line 100, in 
get_series
Nov 13 00:00:33 imurr9 python3[579]: weewx[579] ERROR weewx.reportengine:   
    return xtype.get_series(obs_type, timespan, db_manager, 
aggregate_type,
Nov 13 00:00:33 imurr9 python3[579]: weewx[579] ERROR weewx.reportengine:   
  File "/usr/share/weewx/weewx/xtypes.py", line 920, in 
get_series
Nov 13 00:00:33 imurr9 python3[579]: weewx[579] ERROR weewx.reportengine:   
    return ArchiveTable.get_series(obs_type, timespan, 
db_manager, aggregate_type,
Nov 13 00:00:33 imurr9 python3[579]: weewx[579] ERROR weewx.reportengine:   
  File "/usr/share/weewx/weewx/xtypes.py", line 167, in 
get_series
Nov 13 00:00:33 imurr9 python3[579]: weewx[579] ERROR weewx.reportengine:   
    agg_vt = get_aggregate(obs_type, stamp, do_aggregate, 
db_manager)
Nov 13 00:00:33 imurr9 python3[579]: weewx[579] ERROR weewx.reportengine:   
  File "/usr/share/weewx/weewx/xtypes.py", line 127, in 
get_aggregate
Nov 13 00:00:33 imurr9 python3[579]: weewx[579] ERROR weewx.reportengine:   
    return xtype.get_aggregate(obs_type, timespan, 
aggregate_type, db_manager,
Nov 13 00:00:33 imurr9 python3[579]: weewx[579] ERROR weewx.reportengine:   
  File "/usr/share/weewx/weewx/xtypes.py", line 1102, in 
get_aggregate
Nov 13 00:00:33 imurr9 python3[579]: weewx[579] ERROR weewx.reportengine:   
    row = db_manager.getSql(sql, timespan)
Nov 13 00:00:33 imurr9 python3[579]: weewx[579] ERROR weewx.reportengine:   
 

[weewx-user] Re: Increasing image size within Seasons skin

['Michael Waldor' via weewx-user]

Adding a second change will correct the bottom_label if I'm using my new 
time_offest - simply subtract the offset in line 175 from plotgin_ts:
# Get a suitable bottom label:
bottom_label_format = plot_options.get('bottom_label_format', 
'%m/%d/%y %H:%M')
bottom_label = time.strftime(bottom_label_format, time.localtime(
plotgen_ts - int(plot_options.get('time_offset', 0
plot.setBottomLabel(bottom_label)

Not a very elegant approach (to have this calculation at 2 places within 
the code), but it works fine.

Regards, Michael


Michael Waldor schrieb am Samstag, 11. März 2023 um 17:29:34 UTC+1:

> I've digged a little bit within source code of weewx - especially 
> bin/weewx/imagegenerator.py
>
> My goal is to shift the timeline by an offset so that I can render data 
> from the "future" (from the DWD forecast). And to my surprise it's really 
> simple to introduce the new option time_offset by adding only one line of 
> code into imagegenerator.py
> ...
> # Calculate a suitable min, max time for the requested time.
>
> plotgen_ts = plotgen_ts + int(plot_options.get('time_offset', 0))
>
> minstamp, maxstamp, timeinc = weeplot.utilities.scaletime(
> plotgen_ts - int(plot_options.get('time_length', 86400)), 
> plotgen_ts)
> x_domain = weeutil.weeutil.TimeSpan(minstamp, maxstamp)
> ...
> Within skin.conf I've added this "new" option time_offset = 259200 (3 
> days), and I get the intended shift of the timeline by 3 days (see appended 
> image).
>
> The only disadvantage is that the timestamp printed below the image is 
> shifted, too. But I think that is by design (same for wee_report with 
> timestamp option).
>
> My suggestion: Please include my small change within the next release of 
> weewx.
>
> Regards, Michael
>
>
> Michael Waldor schrieb am Mittwoch, 8. März 2023 um 16:45:07 UTC+1:
>
>> I've done more experiments w.r.t. time_enght - if I increase its value by 
>> 1s from the default 27h I get an imagecoverring 48h (instead of 27h plus 
>> 1s). Thus the value 97200 is kind of magic to deliver the expected 27h, but 
>> it's not possible to increase the value even a little bit. See my appended 
>> picture with time_length = 97201.
>>
>> Michael Waldor schrieb am Mittwoch, 8. März 2023 um 15:46:06 UTC+1:
>>
>>> Another experiment with the (new) DWD SQlite database - sadly failing:
>>>
>>> From weewx customization guide I've learned that one might use (simple 
>>> SQL) expressions to calculate new data within image generation. I gave it a 
>>> try to calculate the windChill from the available SQL data like
>>> [[[daytempfeel]]]
>>> windchill
>>> heatindex
>>> forecast_windchill]]]]
>>> data_type = windchillMetric(outTemp, windSpeed)
>>> data_binding = dwd_binding
>>> label = ' '
>>> color = red
>>> That stopped the image generator from further processing. Is this 
>>> somehow possible?
>>> Michael Waldor schrieb am Mittwoch, 8. März 2023 um 14:01:05 UTC+1:
>>>
>>>> Thanks for that hint - currently I'm still experimenting with this new 
>>>> functionality.
>>>>
>>>> In the meantime I could resolve my problem with seasons.css - it was a 
>>>> problem with caching within firefox. Even after deletion of 
>>>> /var/www/htmp/weew/seasons.css firefox did render it after reload/refresh. 
>>>> But when new images have been generated the missing seasons.css become 
>>>> obvious, and a new seasons.css will be used. Thus one problem solved!
>>>>
>>>>
>>>> Cameron D schrieb am Mittwoch, 8. März 2023 um 13:50:40 UTC+1:
>>>>
>>>>> I do the image size change at the top level, so that all images are 
>>>>> the same size.  I am not sure what happens if only one image is larger.
>>>>>
>>>>> I tested with Firefox (windows x64) and Apache server.
>>>>>
>>>>> Use F12 and inspect where the size directive is coming from, if you 
>>>>> feel brave.
>>>>>
>>>>> On Wednesday, 8 March 2023 at 10:42:40 pm UTC+10 Michael Waldor wrote:
>>>>>
>>>>>>
>>>>>> Thanks for your quich reply. Changing the image size works fine in 
>>>>>> skin.conf, but modifing seasons.css (for testing purpose at 
>>>>>> /var/www/html/weewx being served by nginx) had no effect. Mayby c

[weewx-user] Re: Increasing image size within Seasons skin

['Michael Waldor' via weewx-user]

I've digged a little bit within source code of weewx - especially 
bin/weewx/imagegenerator.py

My goal is to shift the timeline by an offset so that I can render data 
from the "future" (from the DWD forecast). And to my surprise it's really 
simple to introduce the new option time_offset by adding only one line of 
code into imagegenerator.py
...
# Calculate a suitable min, max time for the requested time.

plotgen_ts = plotgen_ts + int(plot_options.get('time_offset', 0))

minstamp, maxstamp, timeinc = weeplot.utilities.scaletime(
plotgen_ts - int(plot_options.get('time_length', 86400)), 
plotgen_ts)
x_domain = weeutil.weeutil.TimeSpan(minstamp, maxstamp)
...
Within skin.conf I've added this "new" option time_offset = 259200 (3 
days), and I get the intended shift of the timeline by 3 days (see appended 
image).

The only disadvantage is that the timestamp printed below the image is 
shifted, too. But I think that is by design (same for wee_report with 
timestamp option).

My suggestion: Please include my small change within the next release of 
weewx.

Regards, Michael


Michael Waldor schrieb am Mittwoch, 8. März 2023 um 16:45:07 UTC+1:

> I've done more experiments w.r.t. time_enght - if I increase its value by 
> 1s from the default 27h I get an imagecoverring 48h (instead of 27h plus 
> 1s). Thus the value 97200 is kind of magic to deliver the expected 27h, but 
> it's not possible to increase the value even a little bit. See my appended 
> picture with time_length = 97201.
>
> Michael Waldor schrieb am Mittwoch, 8. März 2023 um 15:46:06 UTC+1:
>
>> Another experiment with the (new) DWD SQlite database - sadly failing:
>>
>> From weewx customization guide I've learned that one might use (simple 
>> SQL) expressions to calculate new data within image generation. I gave it a 
>> try to calculate the windChill from the available SQL data like
>> [[[daytempfeel]]]
>> windchill
>> heatindex
>> forecast_windchill
>> data_type = windchillMetric(outTemp, windSpeed)
>> data_binding = dwd_binding
>> label = ' '
>> color = red
>> That stopped the image generator from further processing. Is this somehow 
>> possible?
>> Michael Waldor schrieb am Mittwoch, 8. März 2023 um 14:01:05 UTC+1:
>>
>>> Thanks for that hint - currently I'm still experimenting with this new 
>>> functionality.
>>>
>>> In the meantime I could resolve my problem with seasons.css - it was a 
>>> problem with caching within firefox. Even after deletion of 
>>> /var/www/htmp/weew/seasons.css firefox did render it after reload/refresh. 
>>> But when new images have been generated the missing seasons.css become 
>>> obvious, and a new seasons.css will be used. Thus one problem solved!
>>>
>>>
>>> Cameron D schrieb am Mittwoch, 8. März 2023 um 13:50:40 UTC+1:
>>>
>>>> I do the image size change at the top level, so that all images are the 
>>>> same size.  I am not sure what happens if only one image is larger.
>>>>
>>>> I tested with Firefox (windows x64) and Apache server.
>>>>
>>>> Use F12 and inspect where the size directive is coming from, if you 
>>>> feel brave.
>>>>
>>>> On Wednesday, 8 March 2023 at 10:42:40 pm UTC+10 Michael Waldor wrote:
>>>>
>>>>>
>>>>> Thanks for your quich reply. Changing the image size works fine in 
>>>>> skin.conf, but modifing seasons.css (for testing purpose at 
>>>>> /var/www/html/weewx being served by nginx) had no effect. Mayby cached 
>>>>> within firefox dspite reload?
>>>>>
>>>>> This is my current (testing) status within skin.conf - image sizes 
>>>>> currently intentionally commented:
>>>>>
>>>>> [[[daytempdew]]]   
>>>>>  
>>>>> # image_width = 600   
>>>>>   
>>>>> #image_height = 180   
>>>>>  
>>>>> outTemp   
>>>>>  
>>>>> data_type = outTemp  
>>>>> data_binding = wx_binding
>>>>> dewpoint  
>>>>> da

Re: [weewx-user] weedb.OperationalError: no such function: RADIANS

['Michael Waldor' via weewx-user]

Sorry, my fault: I've modified skin.conf for weekly created images. And 
I've used windDir instead of wind within weekwinddir - I've assumed 
aspelling error (naming the image ...winddir but using  wind as 
observation. Mysterious (to me) why that triggered failure of wee_report. 
After fixing my error wee_report runs fine.


Michael Waldor schrieb am Donnerstag, 9. März 2023 um 08:57:42 UTC+1:

> I'm encountering the very same problem within weewx 4.10.2.
>
> I've downloaded your modified sqlite.py, but it is identical to the 
> released version.
>
> If running wee_report I get the error
> Generating as of last timestamp in the database. 
> Using configuration file /etc/weewx/weewx.conf 
> Traceback (most recent call last): 
>  File "/usr/share/weewx/weedb/sqlite.py", line 39, in guarded_fn 
>return fn(*args, **kwargs) 
>  File "/usr/share/weewx/weedb/sqlite.py", line 233, in execute 
>return sqlite3.Cursor.execute(self, *args, **kwargs) 
> sqlite3.OperationalError: no such function: RADIANS 
>
> weewx is running on a raspberry pi3 using bullseye, i.e linux 5.10.78-7
>
>
>
> Chris Nelson schrieb am Freitag, 25. November 2022 um 04:48:12 UTC+1:
>
>> Thanks Tom.
>>
>> As you suspected...
>>
>> $ python -c "import sqlite3; sqlite3.connect(':memory:').execute('SELECT 
>> RADIANS(1.0)')"
>> Traceback (most recent call last):
>>   File "", line 1, in 
>>
>> sqlite3.OperationalError: no such function: RADIANS
>> $ python3 -c "import sqlite3; sqlite3.connect(':memory:').execute('SELECT 
>> RADIANS(1.0)')"
>> Traceback (most recent call last):
>>   File "", line 1, in 
>>
>> sqlite3.OperationalError: no such function: RADIANS
>>
>> I replaced sqlite.py with your modified one and all is well.  I also 
>> deleted the sqlite.pyc file at the same location and cleared the Firefox 
>> cache.
>>
>> A beautiful day in Phoenix today...  https://cjnaz.duckdns.org/weewx/
>> Thank you,
>> cjn
>>
>> On Thursday, November 24, 2022 at 12:42:07 PM UTC-7 tke...@gmail.com 
>> wrote:
>>
>>> I've had the same problem on the Mac. Apparently, there are modern 
>>> sqlite3 libraries out there that were not compiled with 
>>> the DSQLITE_ENABLE_MATH_FUNCTIONS option.
>>>
>>> To test, run this:
>>>
>>> *python -c "import sqlite3; sqlite3.connect(':memory:').execute('SELECT 
>>> RADIANS(1.0)')"*
>>>
>>>
>>> If you get the error
>>>
>>> sqlite3.OperationalError: no such function: RADIANS
>>>
>>>
>>> then your library was not compiled with the flag.
>>>
>>> I've changed to code to explicitly test for the math functions rather 
>>> than rely on a version number. Replace your copy of weedb/sqlite.py 
>>> (usually found in /usr/share/weewx/weedb/sqlite.py) with this one. 
>>> <https://raw.githubusercontent.com/weewx/weewx/cbd8b570cfa0488721db5739c73a26c4fd2fe78b/bin/weedb/sqlite.py>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Nov 24, 2022 at 11:25 AM Chris Nelson  wrote:
>>>
>>>> Hum...  I still have the problem.  I've read the 
>>>> <https://groups.google.com/g/weewx-user/c/VMUPd4l5H_w/m/o0cl7EJEBQAJ>Version
>>>>  
>>>> 4.9.0 available 
>>>> <https://groups.google.com/g/weewx-user/c/VMUPd4l5H_w/m/o0cl7EJEBQAJ> 
>>>> and  weedb.OperationalError: no such function: RADIANS 
>>>> <https://groups.google.com/g/weewx-user/c/WQAUCUAKe18/m/fjsbwJSWBQAJ> 
>>>> threads, and the issue was to be fixed in 4.9.1.  I had updated from 4.8.0 
>>>> to 4.9.1 on Nov 11 and have the problem since then.  Hints please.  Thank 
>>>> you. 
>>>>
>>>> The report generator seems to crash when generating the Month page.  
>>>> Day and Week pages update as expected.  It appears that weewx is still 
>>>> trying to use the RADIANS function in sqlite3. 
>>>>
>>>> I'm on Centos 7 with weewx running the official (ancient) Python3 
>>>> install, and running via systemd. 
>>>>
>>>> $ yum info weewx
>>>> ...
>>>> Installed Packages
>>>> Name : weewx
>>>> Arch : noarch
>>>> Version : 4.9.1
>>>> Release : 1.el7
>>>> Size : 5.5 M
>>>> Repo : installed
>>>> From repo : weewx
>>>> Summary : weather software
>>>> URL : http://www.w

Re: [weewx-user] weedb.OperationalError: no such function: RADIANS

['Michael Waldor' via weewx-user]

I'm encountering the very same problem within weewx 4.10.2.

I've downloaded your modified sqlite.py, but it is identical to the 
released version.

If running wee_report I get the error
Generating as of last timestamp in the database. 
Using configuration file /etc/weewx/weewx.conf 
Traceback (most recent call last): 
 File "/usr/share/weewx/weedb/sqlite.py", line 39, in guarded_fn 
   return fn(*args, **kwargs) 
 File "/usr/share/weewx/weedb/sqlite.py", line 233, in execute 
   return sqlite3.Cursor.execute(self, *args, **kwargs) 
sqlite3.OperationalError: no such function: RADIANS 

weewx is running on a raspberry pi3 using bullseye, i.e linux 5.10.78-7



Chris Nelson schrieb am Freitag, 25. November 2022 um 04:48:12 UTC+1:

> Thanks Tom.
>
> As you suspected...
>
> $ python -c "import sqlite3; sqlite3.connect(':memory:').execute('SELECT 
> RADIANS(1.0)')"
> Traceback (most recent call last):
>   File "", line 1, in 
>
> sqlite3.OperationalError: no such function: RADIANS
> $ python3 -c "import sqlite3; sqlite3.connect(':memory:').execute('SELECT 
> RADIANS(1.0)')"
> Traceback (most recent call last):
>   File "", line 1, in 
>
> sqlite3.OperationalError: no such function: RADIANS
>
> I replaced sqlite.py with your modified one and all is well.  I also 
> deleted the sqlite.pyc file at the same location and cleared the Firefox 
> cache.
>
> A beautiful day in Phoenix today...  https://cjnaz.duckdns.org/weewx/
> Thank you,
> cjn
>
> On Thursday, November 24, 2022 at 12:42:07 PM UTC-7 tke...@gmail.com 
> wrote:
>
>> I've had the same problem on the Mac. Apparently, there are modern 
>> sqlite3 libraries out there that were not compiled with 
>> the DSQLITE_ENABLE_MATH_FUNCTIONS option.
>>
>> To test, run this:
>>
>> *python -c "import sqlite3; sqlite3.connect(':memory:').execute('SELECT 
>> RADIANS(1.0)')"*
>>
>>
>> If you get the error
>>
>> sqlite3.OperationalError: no such function: RADIANS
>>
>>
>> then your library was not compiled with the flag.
>>
>> I've changed to code to explicitly test for the math functions rather 
>> than rely on a version number. Replace your copy of weedb/sqlite.py 
>> (usually found in /usr/share/weewx/weedb/sqlite.py) with this one. 
>> 
>>
>>
>>
>>
>>
>>
>> On Thu, Nov 24, 2022 at 11:25 AM Chris Nelson  wrote:
>>
>>> Hum...  I still have the problem.  I've read the 
>>> Version
>>>  
>>> 4.9.0 available 
>>>  
>>> and  weedb.OperationalError: no such function: RADIANS 
>>>  
>>> threads, and the issue was to be fixed in 4.9.1.  I had updated from 4.8.0 
>>> to 4.9.1 on Nov 11 and have the problem since then.  Hints please.  Thank 
>>> you. 
>>>
>>> The report generator seems to crash when generating the Month page.  Day 
>>> and Week pages update as expected.  It appears that weewx is still trying 
>>> to use the RADIANS function in sqlite3. 
>>>
>>> I'm on Centos 7 with weewx running the official (ancient) Python3 
>>> install, and running via systemd. 
>>>
>>> $ yum info weewx
>>> ...
>>> Installed Packages
>>> Name : weewx
>>> Arch : noarch
>>> Version : 4.9.1
>>> Release : 1.el7
>>> Size : 5.5 M
>>> Repo : installed
>>> From repo : weewx
>>> Summary : weather software
>>> URL : http://www.weewx.com
>>>
>>> The webpage displays 
>>> About this station ♦ 
>>>
>>> Hardware 
>>> AcuRite 01035 
>>> Latitude 
>>> 33° 16.92' N 
>>> Longitude 
>>> 111° 44.39' W 
>>> Altitude 
>>> 1285 feet 
>>> Server uptime 
>>> 0 days, 0 hours, 28 minutes 
>>> WeeWX uptime 
>>> 0 days, 0 hours, 28 minutes 
>>> WeeWX version 
>>> 4.9.1 
>>> Skin 
>>> Seasons 4.9.1
>>>
>>> The systemd unit file has...
>>> [Service]
>>> ExecStart=/usr/bin/python3 /usr/share/weewx/weewxd --daemon 
>>> --pidfile=/var/run/weewx.pid /etc/weewx/weewx.conf
>>>
>>> Python3 (ancient) version...
>>> $ python3 -V
>>> Python 3.6.8
>>>
>>> The sqlite3 version is (ancient) per the base os...
>>> $ python3 -c "import sqlite3; print(sqlite3.sqlite_version)"
>>> 3.7.17
>>>
>>> Attached is the log...
>>>
>>>
>>>
>>> On Friday, October 28, 2022 at 2:34:56 AM UTC-7 kac...@gmail.com wrote:
>>>
 Tnx. I didn't know that this is connected :-)

>>> -- 
>>>
>> 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/fa146277-2a97-46c7-b8db-ee380e74998an%40googlegroups.com
>>>  
>>> 
>>> .
>>>
>>

-- 
You received this 

[weewx-user] Re: Increasing image size within Seasons skin

['Michael Waldor' via weewx-user]

I've done more experiments w.r.t. time_enght - if I increase its value by 
1s from the default 27h I get an imagecoverring 48h (instead of 27h plus 
1s). Thus the value 97200 is kind of magic to deliver the expected 27h, but 
it's not possible to increase the value even a little bit. See my appended 
picture with time_length = 97201.

Michael Waldor schrieb am Mittwoch, 8. März 2023 um 15:46:06 UTC+1:

> Another experiment with the (new) DWD SQlite database - sadly failing:
>
> From weewx customization guide I've learned that one might use (simple 
> SQL) expressions to calculate new data within image generation. I gave it a 
> try to calculate the windChill from the available SQL data like
> [[[daytempfeel]]]
> windchill
> heatindex
> forecast_windchill
> data_type = windchillMetric(outTemp, windSpeed)
> data_binding = dwd_binding
> label = ' '
> color = red
> That stopped the image generator from further processing. Is this somehow 
> possible?
> Michael Waldor schrieb am Mittwoch, 8. März 2023 um 14:01:05 UTC+1:
>
>> Thanks for that hint - currently I'm still experimenting with this new 
>> functionality.
>>
>> In the meantime I could resolve my problem with seasons.css - it was a 
>> problem with caching within firefox. Even after deletion of 
>> /var/www/htmp/weew/seasons.css firefox did render it after reload/refresh. 
>> But when new images have been generated the missing seasons.css become 
>> obvious, and a new seasons.css will be used. Thus one problem solved!
>>
>>
>> Cameron D schrieb am Mittwoch, 8. März 2023 um 13:50:40 UTC+1:
>>
>>> I do the image size change at the top level, so that all images are the 
>>> same size.  I am not sure what happens if only one image is larger.
>>>
>>> I tested with Firefox (windows x64) and Apache server.
>>>
>>> Use F12 and inspect where the size directive is coming from, if you feel 
>>> brave.
>>>
>>> On Wednesday, 8 March 2023 at 10:42:40 pm UTC+10 Michael Waldor wrote:
>>>
>>>>
>>>> Thanks for your quich reply. Changing the image size works fine in 
>>>> skin.conf, but modifing seasons.css (for testing purpose at 
>>>> /var/www/html/weewx being served by nginx) had no effect. Mayby cached 
>>>> within firefox dspite reload?
>>>>
>>>> This is my current (testing) status within skin.conf - image sizes 
>>>> currently intentionally commented:
>>>>
>>>> [[[daytempdew]]]   
>>>>  
>>>> # image_width = 600 
>>>> 
>>>> #image_height = 180 
>>>>
>>>> outTemp 
>>>>
>>>> data_type = outTemp  
>>>> data_binding = wx_binding
>>>> dewpoint  
>>>> data_type = dewpoint  
>>>> data_binding = wx_binding 
>>>> forecast_outTemp 
>>>> data_type = outTemp  
>>>> label = ' ' 
>>>> 
>>>> data_binding = dwd_binding
>>>> color = blue   
>>>>
>>>> forecast_dewpoint 
>>>> data_type = dewpoint  
>>>>         label = ' ' 
>>>> data_binding = dwd_binding 
>>>> color = red 
>>>> 
>>>> Cameron D schrieb am Mittwoch, 8. März 2023 um 13:33:09 UTC+1:
>>>>
>>>>> 1. edit the width in skin.conf
>>>>> 2. edit the value in seasons.css for #history_widget  (where it says 
>>>>> to match the skin.conf value)
>>>>> 3. copy the css file into place (I forgot that!)
>>>>> 4. ctrl-refresh to get full reload.
>>>>>
>>>>> On Wednesday, 8 March 2023 at 8:52:17 pm UTC+10 Michael Waldor wrote:
>>>>>
>>>>> ...
>>>>>
>>>>> Next I wanted to increase the image siz

[weewx-user] Re: Increasing image size within Seasons skin

['Michael Waldor' via weewx-user]

Another experiment with the (new) DWD SQlite database - sadly failing:

>From weewx customization guide I've learned that one might use (simple SQL) 
expressions to calculate new data within image generation. I gave it a try 
to calculate the windChill from the available SQL data like
[[[daytempfeel]]]
windchill
heatindex
forecast_windchill
data_type = windchillMetric(outTemp, windSpeed)
data_binding = dwd_binding
label = ' '
color = red
That stopped the image generator from further processing. Is this somehow 
possible?
Michael Waldor schrieb am Mittwoch, 8. März 2023 um 14:01:05 UTC+1:

> Thanks for that hint - currently I'm still experimenting with this new 
> functionality.
>
> In the meantime I could resolve my problem with seasons.css - it was a 
> problem with caching within firefox. Even after deletion of 
> /var/www/htmp/weew/seasons.css firefox did render it after reload/refresh. 
> But when new images have been generated the missing seasons.css become 
> obvious, and a new seasons.css will be used. Thus one problem solved!
>
>
> Cameron D schrieb am Mittwoch, 8. März 2023 um 13:50:40 UTC+1:
>
>> I do the image size change at the top level, so that all images are the 
>> same size.  I am not sure what happens if only one image is larger.
>>
>> I tested with Firefox (windows x64) and Apache server.
>>
>> Use F12 and inspect where the size directive is coming from, if you feel 
>> brave.
>>
>> On Wednesday, 8 March 2023 at 10:42:40 pm UTC+10 Michael Waldor wrote:
>>
>>>
>>> Thanks for your quich reply. Changing the image size works fine in 
>>> skin.conf, but modifing seasons.css (for testing purpose at 
>>> /var/www/html/weewx being served by nginx) had no effect. Mayby cached 
>>> within firefox dspite reload?
>>>
>>> This is my current (testing) status within skin.conf - image sizes 
>>> currently intentionally commented:
>>>
>>> [[[daytempdew]]] 
>>>
>>> # image_width = 600 
>>> 
>>> #image_height = 180 
>>>
>>> outTemp 
>>>
>>> data_type = outTemp  
>>> data_binding = wx_binding
>>> dewpoint  
>>> data_type = dewpoint  
>>> data_binding = wx_binding 
>>> forecast_outTemp 
>>> data_type = outTemp  
>>> label = ' ' 
>>> 
>>> data_binding = dwd_binding
>>> color = blue 
>>>  
>>> forecast_dewpoint 
>>> data_type = dewpoint  
>>> label = ' ' 
>>> data_binding = dwd_binding 
>>> color = red         
>>> 
>>> Cameron D schrieb am Mittwoch, 8. März 2023 um 13:33:09 UTC+1:
>>>
>>>> 1. edit the width in skin.conf
>>>> 2. edit the value in seasons.css for #history_widget  (where it says to 
>>>> match the skin.conf value)
>>>> 3. copy the css file into place (I forgot that!)
>>>> 4. ctrl-refresh to get full reload.
>>>>
>>>> On Wednesday, 8 March 2023 at 8:52:17 pm UTC+10 Michael Waldor wrote:
>>>>
>>>> ...
>>>>
>>>> Next I wanted to increase the image size form the default 500px to 
>>>> 600px. Again trivial by adding image_width within some image in skin.conf. 
>>>> Works fine, the created image has the requested width of 600. But it is 
>>>> shrunk to 500px probadely by seasons.css. I tried to modify seasons.css 
>>>> within history_widget (from 500px to 600px). Modifing the css seems to 
>>>> have 
>>>> no effect on the rendering (tried to reload the web page after changing 
>>>> css 
>>>> at server location).
>>>>
>>>> ...
>>>>
>>>>

-- 
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/52dfcef6-547f-4a62-a429-fb41d19d6051n%40googlegroups.com.

[weewx-user] Re: Increasing image size within Seasons skin

['Michael Waldor' via weewx-user]

Thanks for that hint - currently I'm still experimenting with this new 
functionality.

In the meantime I could resolve my problem with seasons.css - it was a 
problem with caching within firefox. Even after deletion of 
/var/www/htmp/weew/seasons.css firefox did render it after reload/refresh. 
But when new images have been generated the missing seasons.css become 
obvious, and a new seasons.css will be used. Thus one problem solved!


Cameron D schrieb am Mittwoch, 8. März 2023 um 13:50:40 UTC+1:

> I do the image size change at the top level, so that all images are the 
> same size.  I am not sure what happens if only one image is larger.
>
> I tested with Firefox (windows x64) and Apache server.
>
> Use F12 and inspect where the size directive is coming from, if you feel 
> brave.
>
> On Wednesday, 8 March 2023 at 10:42:40 pm UTC+10 Michael Waldor wrote:
>
>>
>> Thanks for your quich reply. Changing the image size works fine in 
>> skin.conf, but modifing seasons.css (for testing purpose at 
>> /var/www/html/weewx being served by nginx) had no effect. Mayby cached 
>> within firefox dspite reload?
>>
>> This is my current (testing) status within skin.conf - image sizes 
>> currently intentionally commented:
>>
>> [[[daytempdew]]] 
>>
>> # image_width = 600   
>>   
>> #image_height = 180   
>>  
>> outTemp   
>>  
>> data_type = outTemp  
>> data_binding = wx_binding
>> dewpoint  
>> data_type = dewpoint  
>> data_binding = wx_binding 
>> forecast_outTemp 
>> data_type = outTemp  
>> label = ' '   
>>   
>> data_binding = dwd_binding
>> color = blue 
>>  
>> forecast_dewpoint 
>> data_type = dewpoint  
>> label = ' ' 
>> data_binding = dwd_binding 
>> color = red   
>>   
>> Cameron D schrieb am Mittwoch, 8. März 2023 um 13:33:09 UTC+1:
>>
>>> 1. edit the width in skin.conf
>>> 2. edit the value in seasons.css for #history_widget  (where it says to 
>>> match the skin.conf value)
>>> 3. copy the css file into place (I forgot that!)
>>> 4. ctrl-refresh to get full reload.
>>>
>>> On Wednesday, 8 March 2023 at 8:52:17 pm UTC+10 Michael Waldor wrote:
>>>
>>> ...
>>>
>>> Next I wanted to increase the image size form the default 500px to 
>>> 600px. Again trivial by adding image_width within some image in skin.conf. 
>>> Works fine, the created image has the requested width of 600. But it is 
>>> shrunk to 500px probadely by seasons.css. I tried to modify seasons.css 
>>> within history_widget (from 500px to 600px). Modifing the css seems to have 
>>> no effect on the rendering (tried to reload the web page after changing css 
>>> at server location).
>>>
>>> ...
>>>
>>>

-- 
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/b4d26433-53d2-439c-ae11-dd19285a4719n%40googlegroups.com.

[weewx-user] Re: Increasing image size within Seasons skin

['Michael Waldor' via weewx-user]

Thanks for your quich reply. Changing the image size works fine in 
skin.conf, but modifing seasons.css (for testing purpose at 
/var/www/html/weewx being served by nginx) had no effect. Mayby cached 
within firefox dspite reload?

This is my current (testing) status within skin.conf - image sizes 
currently intentionally commented:

[[[daytempdew]]]   
 
# image_width = 600 

#image_height = 180 
   
outTemp 
   
data_type = outTemp  
data_binding = wx_binding
dewpoint  
data_type = dewpoint  
data_binding = wx_binding 
forecast_outTemp 
data_type = outTemp  
label = ' ' 

data_binding = dwd_binding
color = blue   
   
forecast_dewpoint 
data_type = dewpoint  
label = ' ' 
data_binding = dwd_binding 
color = red 

Cameron D schrieb am Mittwoch, 8. März 2023 um 13:33:09 UTC+1:

> 1. edit the width in skin.conf
> 2. edit the value in seasons.css for #history_widget  (where it says to 
> match the skin.conf value)
> 3. copy the css file into place (I forgot that!)
> 4. ctrl-refresh to get full reload.
>
> On Wednesday, 8 March 2023 at 8:52:17 pm UTC+10 Michael Waldor wrote:
>
> ...
>
> Next I wanted to increase the image size form the default 500px to 600px. 
> Again trivial by adding image_width within some image in skin.conf. Works 
> fine, the created image has the requested width of 600. But it is shrunk to 
> 500px probadely by seasons.css. I tried to modify seasons.css within 
> history_widget (from 500px to 600px). Modifing the css seems to have no 
> effect on the rendering (tried to reload the web page after changing css at 
> server location).
>
> ...
>
>

-- 
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/35b16da4-4a22-4685-8f2a-4dc677a21015n%40googlegroups.com.

[weewx-user] Increasing image size within Seasons skin

['Michael Waldor' via weewx-user]

I'm trying to adapt the Seasons skin so that all plots include forecast 
data from DWD (being available as a separate SQlite database within weewx). 
I'm using the Seasons skin withn current weewx 4.10.2 (I have augmented 
Seasons already to display some additional DWD forecast informations).

The from my perspective most complicated aspect is working flawlessly - 
mixing data from different databases within the same image.

But I'm stuck with changing the image size:

First, I'd like to extend the displayed timeline from 27h (default for one 
day) to 30h. That should be straightforward by modifing time_length to 
108000. This change has an effect, but I get 48h instead. I've tried many 
other values, but the displayed time period is either 27h or 48h (and 
more). Howto get only 3 additional hours?

Next I wanted to increase the image size form the default 500px to 600px. 
Again trivial by adding image_width within some image in skin.conf. Works 
fine, the created image has the requested width of 600. But it is shrunk to 
500px probadely by seasons.css. I tried to modify seasons.css within 
history_widget (from 500px to 600px). Modifing the css seems to have no 
effect on the rendering (tried to reload the web page after changing css at 
server location).

My third problem in reaching my goal (to draw forecast values) is howto 
restrict the forecast data onto the future? Currently the forecast database 
contains some old values from the past, and those values should be ignored 
and not pltted.

I myselve have tried for some hours, but I've to admit that I've no 
knowledge on webdesign - these are my first steps.

Regards, Michael

-- 
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/4c25a737-625f-4eab-8ba5-4b0e1cf0de0dn%40googlegroups.com.

[weewx-user] Re: Posting data towards wunderground fails after migration to bullseye

['Michael Waldor' via weewx-user]

Sorry for my posting - the data is sent, received, and displayed by 
wunderground. I was confused by the first fields from wunderground even 
claiming that my station is offline. Guess that's a cookie problem with the 
wunderground page.

Regards, Michael


Michael Waldor schrieb am Dienstag, 20. September 2022 um 16:11:37 UTC+2:

> Yesterday I've upgraded my raspberry pi3 to use the current bullseye. Thus 
> I had to reinstall all my programs including weewx. Now weewx is using the 
> current release 4.8.0 (formerly I was on 4.7.0) with the patched version of 
> wh23xx driver. Everything is working, but my posts towards wunderground are 
> not received. There is no error message within my logs (journalctl), even 
> if checking with debug=2. I see the usual message 
>
> Sep 19 13:51:31 imurr9 python3[561]: weewx[561] INFO weewx.restx: 
> Wunderground-P
> WS: Data for station IMURR9 will be posted
> ...
> Sep 20 15:50:28 imurr9 python3[5876]: weewx[5876] DEBUG weewx.restx: 
> Ambient: ur
> l: 
> https://weatherstation.wunderground.com/weatherstation/updateweatherstation.p
>
> hp?action=updateraw=IMURR9=XXX=weewx-4.8.0=30.2
>
> 43=2022-09-20%2013%3A50%3A00=0.00=45.7=0.00
>
> midity=054=62.6=318.22=3.25=244=3.1&
> windspeedmph=1.8
>
> But since I did the update ,no data are received by wunderground. Of 
> course I've set the "correct" password/API-key from wunderground (working 
> within buster & weewx-4.7.0).
>
> I can even sent the given URL from above using firefox (with proper 
> password), get a success, but no data are visible within wunderground.
>
> Any indeas?
>
> Regards, Michael
>

-- 
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/e3b7c392-780f-46fa-8a88-c36f92d9577an%40googlegroups.com.

[weewx-user] Posting data towards wunderground fails after migration to bullseye

['Michael Waldor' via weewx-user]

Yesterday I've upgraded my raspberry pi3 to use the current bullseye. Thus 
I had to reinstall all my programs including weewx. Now weewx is using the 
current release 4.8.0 (formerly I was on 4.7.0) with the patched version of 
wh23xx driver. Everything is working, but my posts towards wunderground are 
not received. There is no error message within my logs (journalctl), even 
if checking with debug=2. I see the usual message 

Sep 19 13:51:31 imurr9 python3[561]: weewx[561] INFO weewx.restx: 
Wunderground-P
WS: Data for station IMURR9 will be posted
...
Sep 20 15:50:28 imurr9 python3[5876]: weewx[5876] DEBUG weewx.restx: 
Ambient: ur
l: 
https://weatherstation.wunderground.com/weatherstation/updateweatherstation.p
hp?action=updateraw=IMURR9=XXX=weewx-4.8.0=30.2
43=2022-09-20%2013%3A50%3A00=0.00=45.7=0.00
midity=054=62.6=318.22=3.25=244=3.1&
windspeedmph=1.8

But since I did the update ,no data are received by wunderground. Of course 
I've set the "correct" password/API-key from wunderground (working within 
buster & weewx-4.7.0).

I can even sent the given URL from above using firefox (with proper 
password), get a success, but no data are visible within wunderground.

Any indeas?

Regards, Michael

-- 
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/5d95a977-b03c-468e-a264-af96abff6755n%40googlegroups.com.

[weewx-user] Re: Weewx 4.7.0 with wh23xx driver fails

['Michael Waldor' via weewx-user]

Problem solved - your hint was extremely helpful. Really, the Engine part 
was corrupt. My previous post of Engine was an excerpt from my BACKUP copy 
of weewx.conf (taken before uninstall). Due to my uninstall the entry 
archive_services was completely corrupt into

archive_services = w, e, e, w, x, ., e, n, g, i, n, e, ., S, t, d, 
A, r, c, h, i, v, e

Now weewx 4.7.0 is up an running. Of course I did a comparision of "my" 
weewx.conf with the new one from 4.7.0, but based on my BACKUP copy.

Thank you very much, Michael

Michael Waldor schrieb am Mittwoch, 9. März 2022 um 09:37:12 UTC+1:

> [Engine]
>
> # The following section specifies which services should be run and in 
> what order.
> [[Services]]
> prep_services = weewx.engine.StdTimeSynch
> data_services = ,
> process_services = weewx.engine.StdConvert, 
> weewx.engine.StdCalibrate, weewx.engine.StdQC, 
> weewx.wxservices.StdWXCalculate
> xtype_services = weewx.wxxtypes.StdWXXTypes, 
> weewx.wxxtypes.StdPressureCooker, weewx.wxxtypes.StdRainRater, 
> weewx.wxxtypes.StdDelta
> archive_services = weewx.engine.StdArchive
> restful_services = weewx.restx.StdStationRegistry, 
> weewx.restx.StdWunderground, weewx.restx.StdPWSweather, 
> weewx.restx.StdCWOP, weewx.restx.StdWOW, weewx.restx.StdAWEKAS
> report_services = weewx.engine.StdPrint, weewx.engine.StdReport
>
> [The weewx.conf in use is the one running successfully for weewx 4.5.1 but 
> with forecast removed. Sadly I did NOT check if weewx 4.5.1 would start 
> after uninstalling forecast. Thus maybe this uninstall is the rooot cause 
> of my problem?]
>
> Regards, Michael
>
> gjr80 schrieb am Mittwoch, 9. März 2022 um 09:24:13 UTC+1:
>
>> Please post a copy of the [Engine] stanza from weewx.conf.
>>
>> Gary
>>
>> On Wednesday, 9 March 2022 at 18:19:36 UTC+10 miwa...@googlemail.com 
>> wrote:
>>
>>> Setting debug=1  within weewx.conf enhances the amount of messages, but 
>>> still a crash:
>>>
>>> Mär 09 09:14:43 imurr9 python3[859]: weewx[859] INFO weewx.wxservices: 
>>> StdWXCalculate will use data binding wx_binding
>>> Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: 
>>> Finished loading service weewx.wxservices.StdWXCalculate
>>> Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: 
>>> Loading service weewx.wxxtypes.StdWXXTypes
>>> Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: 
>>> Finished loading service weewx.wxxtypes.StdWXXTypes
>>> Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: 
>>> Loading service weewx.wxxtypes.StdPressureCooker
>>> Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: 
>>> Finished loading service weewx.wxxtypes.StdPressureCooker
>>> Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: 
>>> Loading service weewx.wxxtypes.StdRainRater
>>> Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: 
>>> Finished loading service weewx.wxxtypes.StdRainRater
>>> Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: 
>>> Loading service weewx.wxxtypes.StdDelta
>>> Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: 
>>> Finished loading service weewx.wxxtypes.StdDelta
>>> Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: 
>>> Loading service w
>>> Mär 09 09:14:43 imurr9 python3[859]: weewx[859] CRITICAL __main__: 
>>> Caught unrecoverable exception:
>>> Mär 09 09:14:43 imurr9 python3[859]: weewx[859] CRITICAL __main__: 
>>>   Empty module name
>>>
>>> The logging seems to be interrupted by that hard error - see the 
>>> incomplete last DEBUG message.
>>>
>>> Regards, Michael
>>> Michael Waldor schrieb am Mittwoch, 9. März 2022 um 09:02:39 UTC+1:
>>>
>>>> I've now compared the log messages from the successful start of weewx 
>>>> 4.5.1 with the current one - the difference occures with data binding 
>>>> wx_binding:
>>>>
>>>> Feb 13 09:08:36 imurr9 python3[500]: weewx[500] INFO weewx.engine: 
>>>> StdConvert target unit is 0x1
>>>> Feb 13 09:08:36 imurr9 python3[500]: weewx[500] INFO weewx.engine: 
>>>> Archive will use data binding wx_binding
>>>> Feb 13 09:08:36 imurr9 python3[500]: weewx[500] INFO weewx.engine: 
>>>> Record generation will be attempted in 'hardware'
>>>> Feb 13 09:08:36 imurr9 python3[500]: weewx[500] INFO weewx.engine: 
>>>&

[weewx-user] Re: Weewx 4.7.0 with wh23xx driver fails

['Michael Waldor' via weewx-user]

[Engine]

# The following section specifies which services should be run and in 
what order.
[[Services]]
prep_services = weewx.engine.StdTimeSynch
data_services = ,
process_services = weewx.engine.StdConvert, 
weewx.engine.StdCalibrate, weewx.engine.StdQC, 
weewx.wxservices.StdWXCalculate
xtype_services = weewx.wxxtypes.StdWXXTypes, 
weewx.wxxtypes.StdPressureCooker, weewx.wxxtypes.StdRainRater, 
weewx.wxxtypes.StdDelta
archive_services = weewx.engine.StdArchive
restful_services = weewx.restx.StdStationRegistry, 
weewx.restx.StdWunderground, weewx.restx.StdPWSweather, 
weewx.restx.StdCWOP, weewx.restx.StdWOW, weewx.restx.StdAWEKAS
report_services = weewx.engine.StdPrint, weewx.engine.StdReport

[The weewx.conf in use is the one running successfully for weewx 4.5.1 but 
with forecast removed. Sadly I did NOT check if weewx 4.5.1 would start 
after uninstalling forecast. Thus maybe this uninstall is the rooot cause 
of my problem?]

Regards, Michael

gjr80 schrieb am Mittwoch, 9. März 2022 um 09:24:13 UTC+1:

> Please post a copy of the [Engine] stanza from weewx.conf.
>
> Gary
>
> On Wednesday, 9 March 2022 at 18:19:36 UTC+10 miwa...@googlemail.com 
> wrote:
>
>> Setting debug=1  within weewx.conf enhances the amount of messages, but 
>> still a crash:
>>
>> Mär 09 09:14:43 imurr9 python3[859]: weewx[859] INFO weewx.wxservices: 
>> StdWXCalculate will use data binding wx_binding
>> Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: 
>> Finished loading service weewx.wxservices.StdWXCalculate
>> Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: 
>> Loading service weewx.wxxtypes.StdWXXTypes
>> Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: 
>> Finished loading service weewx.wxxtypes.StdWXXTypes
>> Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: 
>> Loading service weewx.wxxtypes.StdPressureCooker
>> Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: 
>> Finished loading service weewx.wxxtypes.StdPressureCooker
>> Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: 
>> Loading service weewx.wxxtypes.StdRainRater
>> Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: 
>> Finished loading service weewx.wxxtypes.StdRainRater
>> Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: 
>> Loading service weewx.wxxtypes.StdDelta
>> Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: 
>> Finished loading service weewx.wxxtypes.StdDelta
>> Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: 
>> Loading service w
>> Mär 09 09:14:43 imurr9 python3[859]: weewx[859] CRITICAL __main__: Caught 
>> unrecoverable exception:
>> Mär 09 09:14:43 imurr9 python3[859]: weewx[859] CRITICAL __main__: 
>>   Empty module name
>>
>> The logging seems to be interrupted by that hard error - see the 
>> incomplete last DEBUG message.
>>
>> Regards, Michael
>> Michael Waldor schrieb am Mittwoch, 9. März 2022 um 09:02:39 UTC+1:
>>
>>> I've now compared the log messages from the successful start of weewx 
>>> 4.5.1 with the current one - the difference occures with data binding 
>>> wx_binding:
>>>
>>> Feb 13 09:08:36 imurr9 python3[500]: weewx[500] INFO weewx.engine: 
>>> StdConvert target unit is 0x1
>>> Feb 13 09:08:36 imurr9 python3[500]: weewx[500] INFO weewx.engine: 
>>> Archive will use data binding wx_binding
>>> Feb 13 09:08:36 imurr9 python3[500]: weewx[500] INFO weewx.engine: 
>>> Record generation will be attempted in 'hardware'
>>> Feb 13 09:08:36 imurr9 python3[500]: weewx[500] INFO weewx.engine: Using 
>>> archive interval of 300 seconds (specified in weewx configuration)
>>>
>>> I did read the weewx upgrade guide before upgrading - but there are no 
>>> hints for potential risks.
>>>
>>> Regards, Michael
>>> Michael Waldor schrieb am Mittwoch, 9. März 2022 um 08:43:55 UTC+1:
>>>
>>>> I'm using a patched version of wh23xx driver successfully with weewx 
>>>> 4.5. After upgrade to 4.7.0 weewx crashes on startup:
>>>>
>>>> Mär 09 08:03:34 imurr9 python3[21370]: weewx[21370] INFO weewx.engine: 
>>>> Loading station type WH23xx (user.wh23xx)
>>>> Mär 09 08:03:34 imurr9 weewx[21356]: Starting weewx weather system: 
>>>> weewx.
>>>> Mär 09 08:03:34 imurr9 systemd[1]: Started LSB: weewx weather system.
>>>> Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] INFO weewx.engine: 
&

[weewx-user] Re: Weewx 4.7.0 with wh23xx driver fails

['Michael Waldor' via weewx-user]

Setting debug=1  within weewx.conf enhances the amount of messages, but 
still a crash:

Mär 09 09:14:43 imurr9 python3[859]: weewx[859] INFO weewx.wxservices: 
StdWXCalculate will use data binding wx_binding
Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: 
Finished loading service weewx.wxservices.StdWXCalculate
Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: Loading 
service weewx.wxxtypes.StdWXXTypes
Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: 
Finished loading service weewx.wxxtypes.StdWXXTypes
Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: Loading 
service weewx.wxxtypes.StdPressureCooker
Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: 
Finished loading service weewx.wxxtypes.StdPressureCooker
Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: Loading 
service weewx.wxxtypes.StdRainRater
Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: 
Finished loading service weewx.wxxtypes.StdRainRater
Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: Loading 
service weewx.wxxtypes.StdDelta
Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: 
Finished loading service weewx.wxxtypes.StdDelta
Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: Loading 
service w
Mär 09 09:14:43 imurr9 python3[859]: weewx[859] CRITICAL __main__: Caught 
unrecoverable exception:
Mär 09 09:14:43 imurr9 python3[859]: weewx[859] CRITICAL __main__:  
 Empty module name

The logging seems to be interrupted by that hard error - see the incomplete 
last DEBUG message.

Regards, Michael
Michael Waldor schrieb am Mittwoch, 9. März 2022 um 09:02:39 UTC+1:

> I've now compared the log messages from the successful start of weewx 
> 4.5.1 with the current one - the difference occures with data binding 
> wx_binding:
>
> Feb 13 09:08:36 imurr9 python3[500]: weewx[500] INFO weewx.engine: 
> StdConvert target unit is 0x1
> Feb 13 09:08:36 imurr9 python3[500]: weewx[500] INFO weewx.engine: Archive 
> will use data binding wx_binding
> Feb 13 09:08:36 imurr9 python3[500]: weewx[500] INFO weewx.engine: Record 
> generation will be attempted in 'hardware'
> Feb 13 09:08:36 imurr9 python3[500]: weewx[500] INFO weewx.engine: Using 
> archive interval of 300 seconds (specified in weewx configuration)
>
> I did read the weewx upgrade guide before upgrading - but there are no 
> hints for potential risks.
>
> Regards, Michael
> Michael Waldor schrieb am Mittwoch, 9. März 2022 um 08:43:55 UTC+1:
>
>> I'm using a patched version of wh23xx driver successfully with weewx 4.5. 
>> After upgrade to 4.7.0 weewx crashes on startup:
>>
>> Mär 09 08:03:34 imurr9 python3[21370]: weewx[21370] INFO weewx.engine: 
>> Loading station type WH23xx (user.wh23xx)
>> Mär 09 08:03:34 imurr9 weewx[21356]: Starting weewx weather system: weewx.
>> Mär 09 08:03:34 imurr9 systemd[1]: Started LSB: weewx weather system.
>> Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] INFO weewx.engine: 
>> StdConvert target unit is 0x1
>> Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] INFO 
>> weewx.wxservices: StdWXCalculate will use data binding wx_binding
>> Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] CRITICAL __main__: 
>> Caught unrecoverable exception:
>> Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] CRITICAL __main__:   
>>     Empty module name
>> Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] CRITICAL __main__:   
>>     Traceback (most recent call last):
>> Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] CRITICAL __main__:   
>>   File "/usr/share/weewx/weewxd", line 147, in main
>> Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] CRITICAL __main__:   
>>     engine = weewx.engine.StdEngine(config_dict)
>> Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] CRITICAL __main__:   
>>   File "/usr/share/weewx/weewx/engine.py", line 93, in __init__
>> Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] CRITICAL __main__:   
>>     self.loadServices(config_dict)
>> Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] CRITICAL __main__:   
>>   File "/usr/share/weewx/weewx/engine.py", line 161, in loadServices
>> Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] CRITICAL __main__:   
>>     obj = weeutil.weeutil.get_object(svc)(self, config_dict)
>> Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] CRITICAL __main__:   
>>   File "/usr/share/weewx/weeutil/weeutil.py", line 1150, in 
>> get_object
>> Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] CRITICAL __main__:   
>>     mod = __import_

[weewx-user] Re: Weewx 4.7.0 with wh23xx driver fails

['Michael Waldor' via weewx-user]

I've now compared the log messages from the successful start of weewx 4.5.1 
with the current one - the difference occures with data binding wx_binding:

Feb 13 09:08:36 imurr9 python3[500]: weewx[500] INFO weewx.engine: 
StdConvert target unit is 0x1
Feb 13 09:08:36 imurr9 python3[500]: weewx[500] INFO weewx.engine: Archive 
will use data binding wx_binding
Feb 13 09:08:36 imurr9 python3[500]: weewx[500] INFO weewx.engine: Record 
generation will be attempted in 'hardware'
Feb 13 09:08:36 imurr9 python3[500]: weewx[500] INFO weewx.engine: Using 
archive interval of 300 seconds (specified in weewx configuration)

I did read the weewx upgrade guide before upgrading - but there are no 
hints for potential risks.

Regards, Michael
Michael Waldor schrieb am Mittwoch, 9. März 2022 um 08:43:55 UTC+1:

> I'm using a patched version of wh23xx driver successfully with weewx 4.5. 
> After upgrade to 4.7.0 weewx crashes on startup:
>
> Mär 09 08:03:34 imurr9 python3[21370]: weewx[21370] INFO weewx.engine: 
> Loading station type WH23xx (user.wh23xx)
> Mär 09 08:03:34 imurr9 weewx[21356]: Starting weewx weather system: weewx.
> Mär 09 08:03:34 imurr9 systemd[1]: Started LSB: weewx weather system.
> Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] INFO weewx.engine: 
> StdConvert target unit is 0x1
> Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] INFO weewx.wxservices: 
> StdWXCalculate will use data binding wx_binding
> Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] CRITICAL __main__: 
> Caught unrecoverable exception:
> Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] CRITICAL __main__: 
>   Empty module name
> Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] CRITICAL __main__: 
>   Traceback (most recent call last):
> Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] CRITICAL __main__: 
> File "/usr/share/weewx/weewxd", line 147, in main
> Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] CRITICAL __main__: 
>   engine = weewx.engine.StdEngine(config_dict)
> Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] CRITICAL __main__: 
> File "/usr/share/weewx/weewx/engine.py", line 93, in __init__
> Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] CRITICAL __main__: 
>   self.loadServices(config_dict)
> Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] CRITICAL __main__: 
> File "/usr/share/weewx/weewx/engine.py", line 161, in loadServices
> Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] CRITICAL __main__: 
>   obj = weeutil.weeutil.get_object(svc)(self, config_dict)
> Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] CRITICAL __main__: 
> File "/usr/share/weewx/weeutil/weeutil.py", line 1150, in get_object
> Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] CRITICAL __main__: 
>   mod = __import__(module)
> Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] CRITICAL __main__: 
>   ValueError: Empty module name
> Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] CRITICAL __main__: 
>   Exiting.
>
> But I have to admit - before updating I did deinstall the old forecast 
> module using wee_extension --uninstall=forecast
>
> I tried to exchange my old wh23xx.py by the patched one from neighbouring 
> thread <https://groups.google.com/g/weewx-user/c/OHum8GwHfhI>
>
> But I guess that I have a different problem. any ideas?
>
>
> Regards, Michael
>
>

-- 
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/23e17f2b-49cd-4b1e-9c79-c6e7f8754583n%40googlegroups.com.

[weewx-user] Weewx 4.7.0 with wh23xx driver fails

['Michael Waldor' via weewx-user]

I'm using a patched version of wh23xx driver successfully with weewx 4.5. 
After upgrade to 4.7.0 weewx crashes on startup:

Mär 09 08:03:34 imurr9 python3[21370]: weewx[21370] INFO weewx.engine: 
Loading station type WH23xx (user.wh23xx)
Mär 09 08:03:34 imurr9 weewx[21356]: Starting weewx weather system: weewx.
Mär 09 08:03:34 imurr9 systemd[1]: Started LSB: weewx weather system.
Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] INFO weewx.engine: 
StdConvert target unit is 0x1
Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] INFO weewx.wxservices: 
StdWXCalculate will use data binding wx_binding
Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] CRITICAL __main__: 
Caught unrecoverable exception:
Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] CRITICAL __main__: 
  Empty module name
Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] CRITICAL __main__: 
  Traceback (most recent call last):
Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] CRITICAL __main__: 
File "/usr/share/weewx/weewxd", line 147, in main
Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] CRITICAL __main__: 
  engine = weewx.engine.StdEngine(config_dict)
Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] CRITICAL __main__: 
File "/usr/share/weewx/weewx/engine.py", line 93, in __init__
Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] CRITICAL __main__: 
  self.loadServices(config_dict)
Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] CRITICAL __main__: 
File "/usr/share/weewx/weewx/engine.py", line 161, in loadServices
Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] CRITICAL __main__: 
  obj = weeutil.weeutil.get_object(svc)(self, config_dict)
Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] CRITICAL __main__: 
File "/usr/share/weewx/weeutil/weeutil.py", line 1150, in get_object
Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] CRITICAL __main__: 
  mod = __import__(module)
Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] CRITICAL __main__: 
  ValueError: Empty module name
Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] CRITICAL __main__: 
  Exiting.

But I have to admit - before updating I did deinstall the old forecast 
module using wee_extension --uninstall=forecast

I tried to exchange my old wh23xx.py by the patched one from neighbouring 
thread 

But I guess that I have a different problem. any ideas?


Regards, Michael

-- 
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/726d3427-9752-456c-81c7-e9da5fb9de49n%40googlegroups.com.

[weewx-user] Re: Weather Forecast from Deutscher Wetterdienst (DWD)

['Michael Waldor' via weewx-user]

Das pre ist wirklich zu "streng" - damit werden die Zeilen "einzeilig" 
komplett ohne Umbruch ausgegeben. Das style-Attribut ist aber "schwächer", 
es erhält die originalen Linefeeds, bricht aber trotzdem automatisch 
sinnvoll  um (vgl. mein Screenshot weiter oben - die Textblöcke sind im 
Input jeweils eine Zeile). Mein Ansatz funktioniert auch nur, weil der DWD 
im Input zusammengehörigen Text als je eine ultralange Zeile ausgibt (oder 
- dann in GROSSBUCHSTABEN - als Art Überschrift). 

Grüßle, Michael 

kk44...@gmail.com schrieb am Donnerstag, 3. Februar 2022 um 21:15:23 UTC+1:

> miwa...@googlemail.com schrieb am Donnerstag, 3. Februar 2022 um 17:25:18 
> UTC+1:
>
>> Noch ein Nachtrag bzgl. : Stattdessen sollte man besser eine 
>> style-Anpassung machen, etwa
>> 
>> um die Zeilenumbrüche zu erhalten. So habe ich das jetzt für mich gelöst.
>>
>> Ich nutze es so, daß die Zeilenumbrüche gerade *nicht* erhalten bleiben 
> sollen. Vielmehr soll der Text vom Browser entsprechend der Breite des 
> Bildschirms neu umgebrochen werden. Deshalb entfernt html2ent.ansi  
> und , das ansonsten bewirken würde, daß die Zeilenumbrüche erhalten 
> bleiben.
>
>

-- 
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/3af2a829-e655-4f2b-b583-b950d3a12cdan%40googlegroups.com.

[weewx-user] Re: Weather Forecast from Deutscher Wetterdienst (DWD)

['Michael Waldor' via weewx-user]

Noch ein Nachtrag bzgl. : Stattdessen sollte man besser eine 
style-Anpassung machen, etwa

um die Zeilenumbrüche zu erhalten. So habe ich das jetzt für mich gelöst.

Grüßle, Michael


Michael Waldor schrieb am Donnerstag, 3. Februar 2022 um 08:27:16 UTC+1:

> Vielen Dank für dieses Modul.
>
> Ich habe bislang das forecast-Modul von mwall genutzt mit Vorhersagedaten 
> von Wunderground. Aber für Deutschland ist eine Vorhersage vom DWD wohl 
> angemessener. Da mir der Seasons-Skin gut gefällt, habe ich das DWD-Modul 
> in Seasons integriert - ging problemlos. Ich zeige z.B. in der linken 
> Spalte von Seasons die textuelle Vorhersage und die DWD-Warnungen an. Dazu 
> habe ich allerdings html2ent.ansi angepaßt, so daß die Zeilenumbrüche in 
> der Original-Meldung vom DWD durch  ersetzt werden:
> [image: dwd.png]
> Das klappt gut, da alle zusammengehörigen Texte vom DWD in einer Zeile 
> ausgegeben werden. Dazu habe ich die nachfolgende Erweiterungen eingefügt:
> sed -e 's/\r//' \
> -e '1{/^$/d}' \
> ...
> -e 's/$/\/'
>
> Das erste Pattern entfernt das DOS-artige Return, das zweite eine ggf. 
> vorhandene Leerzeile am Dateianfang, das dritte (abschließende) hängt das 
> HTML break an alle Zeilen.
>
> Und wo ich schon poste - in dwd-cap-warnings ist wohl ein Typo drin: in 
> Zeile 79 ist bestimmt Rheinland-Pfalz gemeint.
>
>
> Grüßle, Michael
>
> mh081...@gmail.com schrieb am Montag, 31. Januar 2022 um 16:07:51 UTC+1:
>
>> Alles klar Danke für die Mühe. Werde mal schauen ob ich das mache.
>>
>> kk44...@gmail.com schrieb am Montag, 31. Januar 2022 um 15:52:08 UTC+1:
>>
>>> Das teste ich gerade bei mir. Es erfordert Eingriffe in 
>>> js/belchertown.js.tmpl und index.html.tmpl.
>>>
>>> Zunächst brauchen Sie eine zusätzliche Datei, siehe Anhang. Dann muß in 
>>> belchertown.js.tmpl zweimal (!) die folgende Zeile eingefügt werden:
>>>
>>> ajaxdwdalert().then(show_dwd_forecast_alert);
>>>
>>> und zwar am Ende der Funktionen update_weewx_data und in 
>>> update_current_wx am Ende des Abschnittes "interval_minute". Ganz ans 
>>> Ende der Datei kommt noch:
>>>
>>> #include "js/woellsdorf.inc.txt"
>>>
>>> In index.html.tmpl muß das #if-Statement auskommentiert werden, das die 
>>> Variable forecast_enabled abfragt, also sowohl die Zeile mit #if als 
>>> auch die zugehörige mit #end if.
>>> Aber ich kann keine Gewähr geben, daß es schon reibungsfrei funktioniert.
>>>
>>

-- 
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/0eda104c-1ddd-4d94-ba51-3e8b92048d9an%40googlegroups.com.

[weewx-user] Re: Weather Forecast from Deutscher Wetterdienst (DWD)

['Michael Waldor' via weewx-user]

Vielen Dank für dieses Modul.

Ich habe bislang das forecast-Modul von mwall genutzt mit Vorhersagedaten 
von Wunderground. Aber für Deutschland ist eine Vorhersage vom DWD wohl 
angemessener. Da mir der Seasons-Skin gut gefällt, habe ich das DWD-Modul 
in Seasons integriert - ging problemlos. Ich zeige z.B. in der linken 
Spalte von Seasons die textuelle Vorhersage und die DWD-Warnungen an. Dazu 
habe ich allerdings html2ent.ansi angepaßt, so daß die Zeilenumbrüche in 
der Original-Meldung vom DWD durch  ersetzt werden:
[image: dwd.png]
Das klappt gut, da alle zusammengehörigen Texte vom DWD in einer Zeile 
ausgegeben werden. Dazu habe ich die nachfolgende Erweiterungen eingefügt:
sed -e 's/\r//' \
-e '1{/^$/d}' \
...
-e 's/$/\/'

Das erste Pattern entfernt das DOS-artige Return, das zweite eine ggf. 
vorhandene Leerzeile am Dateianfang, das dritte (abschließende) hängt das 
HTML break an alle Zeilen.

Und wo ich schon poste - in dwd-cap-warnings ist wohl ein Typo drin: in 
Zeile 79 ist bestimmt Rheinland-Pfalz gemeint.


Grüßle, Michael

mh081...@gmail.com schrieb am Montag, 31. Januar 2022 um 16:07:51 UTC+1:

> Alles klar Danke für die Mühe. Werde mal schauen ob ich das mache.
>
> kk44...@gmail.com schrieb am Montag, 31. Januar 2022 um 15:52:08 UTC+1:
>
>> Das teste ich gerade bei mir. Es erfordert Eingriffe in 
>> js/belchertown.js.tmpl und index.html.tmpl.
>>
>> Zunächst brauchen Sie eine zusätzliche Datei, siehe Anhang. Dann muß in 
>> belchertown.js.tmpl zweimal (!) die folgende Zeile eingefügt werden:
>>
>> ajaxdwdalert().then(show_dwd_forecast_alert);
>>
>> und zwar am Ende der Funktionen update_weewx_data und in 
>> update_current_wx am Ende des Abschnittes "interval_minute". Ganz ans 
>> Ende der Datei kommt noch:
>>
>> #include "js/woellsdorf.inc.txt"
>>
>> In index.html.tmpl muß das #if-Statement auskommentiert werden, das die 
>> Variable forecast_enabled abfragt, also sowohl die Zeile mit #if als 
>> auch die zugehörige mit #end if.
>> Aber ich kann keine Gewähr geben, daß es schon reibungsfrei funktioniert.
>>
>

-- 
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/21a996b9-aac5-4137-926c-fae066372240n%40googlegroups.com.

Re: [weewx-user] spurious gaps within weather data - wh23xx on raspberry pi 3

['Michael Waldor' via weewx-user]

My watchdog is a very simple minded one - it regularly (once per minute 
using cron) searches /var/log/messages for USB messages. If it detects some 
the raspi will be automatically rebooted.

Sadly currently I've no access to my scripts - drop me a note if you still 
need it. Then I'll look into that ...

To be honest I do not know why my USB problems were solved. But besides 
updating involved software versions, I also started new services (e.g. 
Kodi), added an USB diskdrive, and a USB rs232 interface. For that I 
changed the USB ports (to avoid cable cluttering:-). Maybe your problem is 
simply solved by using another USB port? Or improving contacts by 
unplug/plugging?


Regards, Michael
Michael Waldor schrieb am Dienstag, 9. Februar 2021 um 10:34:06 UTC+1:

> In the meantime all my problems seem to be resolved - probabely due to 
> recent software updates:
>
> 1. No longer any USB problem after upgrading to recent raspbian (buster 
> 5.4.72-v7+).
> Previously, I encountered USB problems after some weeks. To detect them I 
> wrote a simple watchdog and rebooted my raspberry automatically. After 
> reboot USB always did recover. Additionally I did a reboot once per day. 
> Now these problems are gone, and my raspberry  is up since 38 days (the 
> day when I did the upgrade onto buster).
>
> 2. I've updated to weewx 4.x based with python 3.
> Beware, to use python 3 you have to use ANOTHER repository (see the 
> corresponding weewx documentation). If you don't switch the repository you 
> will stay with python 2. AND you must use special releases of the wh23xx 
> driver (NOT the official one, it's still at pyhton 2 as far as I know) and 
> for forecast.
>
> Concluding: After all these changes all my problems with that kind of 
> weather station are gone. Maybe one exception: If there is very heavy rain, 
> the base station will loose its contact with the sensor array despite the 
> short distance (only some meters). But of course that's not a weewx problem.
>
> I even use the same raspberry to run FHEM smart home and kodi multimedia.
> holger...@gmail.com schrieb am Montag, 8. Februar 2021 um 17:53:00 UTC+1:
>
>> Hi there,
>>
>> same thing here.
>>
>>
>>- WH2315 (Renkforce from Conrad)
>>- RaspberryPi 3B
>>- weewx 4.3.0
>>- Python 3.7
>>- SofaskinCW9009
>>- driver: wh23xx (EdwinGH fork)
>>
>> I'm also experiencing data gaps / lockups at random intervals (> once per 
>> day). I suspected RFI -> put RF chokes on all cables to an from the pi 
>> (snap ferrites and ferrite rings), shielded the USB cable with aluminum 
>> foil: problem persists.
>>
>> Of course I also changed the batteries in the outdoor unit: problem 
>> pesists.
>>
>> Here's the log:
>>
>> Feb  8 17:39:31 raspberrypi weewx[623] INFO weewx.cheetahgenerator: 
>> Generated 8 files for report SeasonsReport in 1.85 seconds
>> Feb  8 17:39:31 raspberrypi weewx[623] DEBUG weewx.manager: Daily summary 
>> version is 3.0
>> Feb  8 17:39:33 raspberrypi weewx[623] INFO weewx.imagegenerator: 
>> Generated 15 images for report SeasonsReport in 1.66 seconds
>> Feb  8 17:39:33 raspberrypi weewx[623] INFO weewx.reportengine: Copied 0 
>> files to /var/www/html
>> Feb  8 17:39:33 raspberrypi weewx[623] DEBUG weewx.reportengine: Running 
>> report 'SmartphoneReport'
>> Feb  8 17:39:33 raspberrypi weewx[623] DEBUG weewx.reportengine: Found 
>> configuration file /etc/weewx/skins/Smartphone/skin.conf for report 
>> 'SmartphoneReport'
>> Feb  8 17:39:33 raspberrypi weewx[623] DEBUG weewx.cheetahgenerator: 
>> Using search list ['weewx.cheetahgenerator.Almanac', 
>> 'weewx.cheetahgenerator.Station', 'weewx.cheetahgenerator.Current', 
>> 'weewx.cheetahgenerator.Stats', 'weewx.cheetahgenerator.UnitInfo', 
>> 'weewx.cheetahgenerator.Extras']
>> Feb  8 17:39:33 raspberrypi weewx[623] DEBUG weewx.manager: Daily summary 
>> version is 3.0
>> Feb  8 17:39:33 raspberrypi weewx[623] INFO weewx.cheetahgenerator: 
>> Generated 6 files for report SmartphoneReport in 0.11 seconds
>> Feb  8 17:39:33 raspberrypi weewx[623] DEBUG weewx.manager: Daily summary 
>> version is 3.0
>> Feb  8 17:39:33 raspberrypi weewx[623] INFO weewx.imagegenerator: 
>> Generated 6 images for report SmartphoneReport in 0.61 seconds
>> Feb  8 17:39:33 raspberrypi weewx[623] INFO weewx.reportengine: Copied 0 
>> files to /var/www/html/weewx/smartphone
>> Feb  8 17:39:33 raspberrypi weewx[623] DEBUG weewx.reportengine: Running 
>> report 'MobileReport'
>> Feb  8 17:39:34 raspberrypi weewx[623] DEBUG weewx.reportengine: Found 
>> configuration file /etc/weewx/skins/Mobile/sk

Re: [weewx-user] spurious gaps within weather data - wh23xx on raspberry pi 3

['Michael Waldor' via weewx-user]

00 00 00 00 10 00 00 00 2a 11 00 00 00 2a 12 00 00 01 
> 14 13 00 00 02 82 14 00 00 02 82 15 00 00 00 00 16 00 00 17 00 (len=74) 
> chksum_pkt=e4 chksum=0xe4
> Feb  8 17:40:14 raspberrypi /weewxd: wh23xx: raw data: [1, 2, 100, 2, 1, 
> 165, 3, 1, 154, 4, 1, 165, 5, 1, 165, 6, 51, 7, 93, 8, 37, 55, 9, 38, 251, 
> 10, 0, 45, 11, 0, 0, 12, 0, 0, 14, 0, 0, 0, 0, 16, 0, 0, 0, 42, 17, 0, 0, 
> 0, 42, 18, 0, 0, 1, 20, 19, 0, 0, 2, 130, 20, 0, 0, 2, 130, 21, 0, 0, 0, 0, 
> 22, 0, 0, 23, 0]
> Feb  8 17:40:14 raspberrypi /weewxd: wh23xx: in_temp: {'value': 
> 21.203} (0x01 0x01)
> Feb  8 17:40:14 raspberrypi /weewxd: wh23xx: out_temp: {'value': 
> 2.1014} (0x02 0x02)
> Feb  8 17:40:14 raspberrypi /weewxd: wh23xx: dewpoint: {'value': 1.0} 
> (0x03 0x03)
> Feb  8 17:40:14 raspberrypi /weewxd: wh23xx: windchill: {'value': 
> 2.1014} (0x04 0x04)
> Feb  8 17:40:14 raspberrypi /weewxd: wh23xx: heatindex: {'value': 
> 2.1014} (0x05 0x05)
> Feb  8 17:40:14 raspberrypi /weewxd: wh23xx: in_humidity: {'value': 51} 
> (0x06 0x06)
> Feb  8 17:40:14 raspberrypi /weewxd: wh23xx: out_humidity: {'value': 93} 
> (0x07 0x07)
> Feb  8 17:40:14 raspberrypi /weewxd: wh23xx: abs_baro: {'value': 952.7} 
> (0x08 0x08)
> Feb  8 17:40:14 raspberrypi /weewxd: wh23xx: rel_baro: {'value': 997.9} 
> (0x09 0x09)
> Feb  8 17:40:14 raspberrypi /weewxd: wh23xx: wind_dir: {'value': 45} (0x0a 
> 0x0a)
> Feb  8 17:40:14 raspberrypi /weewxd: wh23xx: wind_speed: {'value': 0.0} 
> (0x0b 0x0b)
> Feb  8 17:40:14 raspberrypi /weewxd: wh23xx: gust_speed: {'value': 0.0} 
> (0x0c 0x0c)
> Feb  8 17:40:14 raspberrypi /weewxd: wh23xx: rain_rate: {'value': 0.0} 
> (0x0e 0x0e)
> Feb  8 17:40:14 raspberrypi /weewxd: wh23xx: rain_day: {'value': 4.2} 
> (0x10 0x10)
> Feb  8 17:40:14 raspberrypi /weewxd: wh23xx: rain_week: {'value': 4.2} 
> (0x11 0x11)
> Feb  8 17:40:14 raspberrypi /weewxd: wh23xx: rain_month: {'value': 27.6} 
> (0x12 0x12)
> Feb  8 17:40:14 raspberrypi /weewxd: wh23xx: rain_year: {'value': 64.2} 
> (0x13 0x13)
> Feb  8 17:40:14 raspberrypi /weewxd: wh23xx: rain_totals: {'value': 64.2} 
> (0x14 0x14)
> Feb  8 17:40:14 raspberrypi /weewxd: wh23xx: light: {'value': 0.0} (0x15 
> 0x15)
> Feb  8 17:40:14 raspberrypi /weewxd: wh23xx: uv: {'value': 0} (0x16 0x16)
> Feb  8 17:40:14 raspberrypi /weewxd: wh23xx: uvi: {'value': 0} (0x17 0x17)
> Feb  8 17:40:14 raspberrypi /weewxd: wh23xx: decoded data: {'in_temp': 
> {'value': 21.203}, 'out_temp': {'value': 2.1014}, 
> 'dewpoint': {'value': 1.0}, 'windchill': {'value': 2.1014}, 
> 'heatindex': {'value': 2.1014}, 'in_humidity': {'value': 51}, 
> 'out_humidity': {'value': 93}, 'abs_baro': {'value': 952.7}, 'rel_baro': 
> {'value': 997.9}, 'wind_dir': {'value': 45}, 'wind_speed': {'value': 0.0}, 
> 'gust_speed': {'value': 0.0}, 'rain_rate': {'value': 0.0}, 'rain_day': 
> {'value': 4.2}, 'rain_week': {'value': 4.2}, 'rain_month': {'value': 27.6}, 
> 'rain_year': {'value': 64.2}, 'rain_totals': {'value': 64.2}, 'light': 
> {'value': 0.0}, 'uv': {'value': 0}, 'uvi': {'value': 0}}
> Feb  8 17:40:14 raspberrypi /weewxd: wh23xx: packet: {'dateTime': 
> 1612802415, 'usUnits': 17, 'windDir': 45, 'windSpeed': 0.0, 'windGust': 
> 0.0, 'inHumidity': 51, 'outHumidity': 93, 'inTemp': 21.203, 
> 'outTemp': 2.1014, 'pressure': 952.7, 'luminosity': 0.0, 
> 'uv_raw': 0, 'UV': 0, 'rain': 0.0, 'radiation': 0.0}
> Feb  8 17:40:14 raspberrypi weewx[623] INFO weewx.manager: Added record 
> 2021-02-08 17:40:00 CET (1612802400) to database 'weewx.sdb'
> Feb  8 17:40:14 raspberrypi weewx[623] INFO weewx.manager: Added record 
> 2021-02-08 17:40:00 CET (1612802400) to daily summary in 'weewx.sdb'
> Feb  8 17:40:15 raspberrypi weewx[623] DEBUG weewx.restx: StationRegistry: 
> wait interval (3060 < 604800) has not passed for record 2021-02-08 17:40:00 
> CET (1612802400)
> Feb  8 17:40:15 raspberrypi weewx[623] DEBUG weewx.reportengine: Running 
> reports for latest time in the database.
> Feb  8 17:40:15 raspberrypi /weewxd: wh23xx: read_record: write: 02 02 04 
> 04 (len=4)
> Feb  8 17:40:15 raspberrypi weewx[623] DEBUG weewx.reportengine: Running 
> report 'SeasonsReport'
> Feb  8 17:40:15 raspberrypi /weewxd: wh23xx: read_record: buf: 01 3b 04 4a 
> 01 02 64 02 01 a5 03 01 9a 04 01 a5 05 01 a5 06 33 07 5d 08 25 37 09 26 fb 
> 0a 00 2d 0b 00 00 0c 00 00 0e 00 00 00 00 10 00 00 00 2a 11 00 00 00 2a 12 
> 00 00 01 14 13 00 00 (len=61)
> Feb  8 17:40:15 raspberrypi /weewxd: wh23xx: read_record: record_size: 74
> Feb  8 17:40:15 raspberrypi weewx[623] DEBUG weewx.reportengine: Found 
> configuration file /etc/weewx/skins/Seasons/skin.conf for report 
> 'SeasonsReport'
>
>

Re: [weewx-user] forcast wunderground for weewx 4.2.x using python 3

['Michael Waldor' via weewx-user]

I've pulled your change and waited for some days: Now the temperatures 
shown look much better. No longer constant values. And the values match 
with our weather

Thanks for your support, 

Michael 

jo...@johnkline.com schrieb am Dienstag, 1. Dezember 2020 um 15:47:50 UTC+1:

> This is now released as 3.4.0b11:
> https://github.com/chaunceygardiner/weewx-forecast/releases/tag/v3.4.0b11
>
> On Nov 30, 2020, at 3:23 PM, John Kline  wrote:
>
> 
>
> Thanks, I was just looking for you to confirm that you were seeing the 
> issue in the forecast skin itself.
>
> I looked at forecast_compact.inc.  It is looking for temperatureMin and 
> temperatureMax (which are in the beginning section of the WU forecast). 
>  Furthermore, when I looked at the tempMin and tempMax columns in the 
> database, they were wrong.  There was a bug in parsing for these values. 
>  I’ve fixed that now.
>
> Please pull forecast.py at head and give it a try.  Copy it to 
> /bin/user.
>
> You’ll need to wait for a new WU forecast to download and then for a 
> report to generate.  This download may take some time.  If you’re 
> comfortable mucking with the database, you could delete the latest WU 
> forecast.  If you’re not comfortable doing that, and you don’t want to 
> wait, you could simply delete the forecast.db file and then restart weewx 
> (which you have to restart anyway after you copy over the new forecast.py 
> file).
>
> On Nov 30, 2020, at 8:20 AM, 'Michael Waldor' via weewx-user <
> weewx...@googlegroups.com> wrote:
>
> Regarding missing icon... I already copied it from your zip, and it's 
> working fine. I just thought that the missing icon might be a hint that 
> some important code might be missing, too. But probably not. 
>
> I did use the original forcast skin creating the subfolder forecast within 
> HTML area. And it, too, contains the "wrong" temperature values. Identical 
> to those values as been shown within my usecase of forecast_compact. 
>
> Yesterday I've validated that forcast.sdb contains the "correct" forecast 
> temperatures within the SQL database field temperature (there are 12entries 
> per timestamp for 6days). Hopefully my forecast.sdb.txt posted yesterday is 
> still a valid binary SQL database, then you can inspect it e. g. using 
> sqlbrowser. 
>
> Thus I assume that somewhere within weewx/forecast the wrong data are 
> forwarded into HTML output. 
>
> jo...@johnkline.com schrieb am Montag, 30. November 2020 um 16:15:24 
> UTC+1:
>
>> frzngdrzl.png was added to the repository after the b10 release.  If you 
>> want it, you’ll have to download the repository at head.
>>
>> I cannot decipher from your reply if the compact forecast is correct in 
>> the forecast skin.  Is it?
>>
>> On Nov 30, 2020, at 12:10 AM, Michael Waldor  wrote:
>>
>> 
>>
>> Yes, I did diff both - they are identical. But there is a minor issue: 
>> You did update install.py to include frzgrain.png. This is still missing 
>> within your  
>> https://github.com/chaunceygardiner/weewx-forecast/releases/tag/v3.4.0b10 
>> - the png is include but it will not be installed. Is there any other 
>> important change maybe missing within your last zip release?
>>
>> Of course that does not explain the wrong temperature numbers. I've 
>> checked also the foreground skin. The data are in sync with my change 
>> within Seasons skin. But the data do not contain the values from 
>> temperature field within forecast.sdb.
>>
>> Don't know the internal flow of weewx/forecast. I assume that first you 
>> fetch json contents from WU. Then that data is uploaded into forecast.sdb. 
>> Afterwards during creation of HTML output the data from forecast.sdb is 
>> read and added into the HTML templates by forecast.py. If my assumption is 
>> correct there might be a problem during the step from forecast.sdg into the 
>> HTML output.
>>
>>
>> jo...@johnkline.com schrieb am Sonntag, 29. November 2020 um 14:36:07 
>> UTC+1:
>>
>>> > Maybe I'm using the wrong forecast_compact.inc (see my included file)? 
>>> And see als my forecast.sdb and 5day.json with the presumably correct temp 
>>> values, but not shown within the rendered window.
>>>
>>> Did you diff forecast_compact.inc with the like named file in the latest 
>>> forecast extension?  Are they identical?  If not, please provide the diff.
>>>
>>> Does the compact forecast in the *forecast skin* have the correct 
>>> values?
>>>
>>> On Nov 29, 2020, at 1:27 AM, Michael Waldor  wrote:
>>>
>>> Sorry for postin

Re: [weewx-user] forcast wunderground for weewx 4.2.x using python 3

['Michael Waldor' via weewx-user]

Regarding missing icon... I already copied it from your zip, and it's 
working fine. I just thought that the missing icon might be a hint that 
some important code might be missing, too. But probably not. 

I did use the original forcast skin creating the subfolder forecast within 
HTML area. And it, too, contains the "wrong" temperature values. Identical 
to those values as been shown within my usecase of forecast_compact. 

Yesterday I've validated that forcast.sdb contains the "correct" forecast 
temperatures within the SQL database field temperature (there are 12entries 
per timestamp for 6days). Hopefully my forecast.sdb.txt posted yesterday is 
still a valid binary SQL database, then you can inspect it e. g. using 
sqlbrowser. 

Thus I assume that somewhere within weewx/forecast the wrong data are 
forwarded into HTML output. 

jo...@johnkline.com schrieb am Montag, 30. November 2020 um 16:15:24 UTC+1:

> frzngdrzl.png was added to the repository after the b10 release.  If you 
> want it, you’ll have to download the repository at head.
>
> I cannot decipher from your reply if the compact forecast is correct in 
> the forecast skin.  Is it?
>
> On Nov 30, 2020, at 12:10 AM, Michael Waldor  wrote:
>
> 
>
> Yes, I did diff both - they are identical. But there is a minor issue: You 
> did update install.py to include frzgrain.png. This is still missing within 
> your  
> https://github.com/chaunceygardiner/weewx-forecast/releases/tag/v3.4.0b10 
> - the png is include but it will not be installed. Is there any other 
> important change maybe missing within your last zip release?
>
> Of course that does not explain the wrong temperature numbers. I've 
> checked also the foreground skin. The data are in sync with my change 
> within Seasons skin. But the data do not contain the values from 
> temperature field within forecast.sdb.
>
> Don't know the internal flow of weewx/forecast. I assume that first you 
> fetch json contents from WU. Then that data is uploaded into forecast.sdb. 
> Afterwards during creation of HTML output the data from forecast.sdb is 
> read and added into the HTML templates by forecast.py. If my assumption is 
> correct there might be a problem during the step from forecast.sdg into the 
> HTML output.
>
>
> jo...@johnkline.com schrieb am Sonntag, 29. November 2020 um 14:36:07 
> UTC+1:
>
>> > Maybe I'm using the wrong forecast_compact.inc (see my included file)? 
>> And see als my forecast.sdb and 5day.json with the presumably correct temp 
>> values, but not shown within the rendered window.
>>
>> Did you diff forecast_compact.inc with the like named file in the latest 
>> forecast extension?  Are they identical?  If not, please provide the diff.
>>
>> Does the compact forecast in the *forecast skin* have the correct values?
>>
>> On Nov 29, 2020, at 1:27 AM, Michael Waldor  wrote:
>>
>> Sorry for posting multiple times - but google did abort any post if 
>> containing *.json or *.inc files:-(
>>
>>
>>
>> Michael Waldor schrieb am Sonntag, 29. November 2020 um 10:26:00 UTC+1:
>>
>>> Tried to rename forecast.sdb into forecast.sdb.txt 
>>>
>>> Michael Waldor schrieb am Sonntag, 29. November 2020 um 10:23:34 UTC+1:
>>>
>>>> Sorry, but google doesn't allow me to append the data. Thus I try again 
>>>> ...
>>>>
>>>> -- 
>> 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/23bc8b05-639e-4a2b-9860-0e9b92ca6e8cn%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/weewx-user/23bc8b05-639e-4a2b-9860-0e9b92ca6e8cn%40googlegroups.com?utm_medium=email_source=footer>
>> .
>> 
>>
>> -- 
> You received this message because you are subscribed to the Google Groups 
> "weewx-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to weewx-user+...@googlegroups.com.
>
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/86d6d50c-6653-41fb-ac02-ece43c399a0bn%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/weewx-user/86d6d50c-6653-41fb-ac02-ece43c399a0bn%40googlegroups.com?utm_medium=email_source=footer>
> .
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/85ee7fca-1645-4f35-9d65-7665c978a59en%40googlegroups.com.

Re: [weewx-user] forcast wunderground for weewx 4.2.x using python 3

[Michael Waldor]

Yes, I did diff both - they are identical. But there is a minor issue: You 
did update install.py to include frzgrain.png. This is still missing within 
your  
https://github.com/chaunceygardiner/weewx-forecast/releases/tag/v3.4.0b10 - 
the png is include but it will not be installed. Is there any other 
important change maybe missing within your last zip release?

Of course that does not explain the wrong temperature numbers. I've checked 
also the foreground skin. The data are in sync with my change within 
Seasons skin. But the data do not contain the values from temperature field 
within forecast.sdb.

Don't know the internal flow of weewx/forecast. I assume that first you 
fetch json contents from WU. Then that data is uploaded into forecast.sdb. 
Afterwards during creation of HTML output the data from forecast.sdb is 
read and added into the HTML templates by forecast.py. If my assumption is 
correct there might be a problem during the step from forecast.sdg into the 
HTML output.


jo...@johnkline.com schrieb am Sonntag, 29. November 2020 um 14:36:07 UTC+1:

> > Maybe I'm using the wrong forecast_compact.inc (see my included file)? 
> And see als my forecast.sdb and 5day.json with the presumably correct temp 
> values, but not shown within the rendered window.
>
> Did you diff forecast_compact.inc with the like named file in the latest 
> forecast extension?  Are they identical?  If not, please provide the diff.
>
> Does the compact forecast in the *forecast skin* have the correct values?
>
> On Nov 29, 2020, at 1:27 AM, Michael Waldor  wrote:
>
> Sorry for posting multiple times - but google did abort any post if 
> containing *.json or *.inc files:-(
>
>
>
> Michael Waldor schrieb am Sonntag, 29. November 2020 um 10:26:00 UTC+1:
>
>> Tried to rename forecast.sdb into forecast.sdb.txt 
>>
>> Michael Waldor schrieb am Sonntag, 29. November 2020 um 10:23:34 UTC+1:
>>
>>> Sorry, but google doesn't allow me to append the data. Thus I try again 
>>> ...
>>>
>>> -- 
> 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/23bc8b05-639e-4a2b-9860-0e9b92ca6e8cn%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/weewx-user/23bc8b05-639e-4a2b-9860-0e9b92ca6e8cn%40googlegroups.com?utm_medium=email_source=footer>
> .
> 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/86d6d50c-6653-41fb-ac02-ece43c399a0bn%40googlegroups.com.

Re: [weewx-user] forcast wunderground for weewx 4.2.x using python 3

[Michael Waldor]

Sorry for posting multiple times - but google did abort any post if 
containing *.json or *.inc files:-(

Michael Waldor schrieb am Sonntag, 29. November 2020 um 10:26:00 UTC+1:

> Tried to rename forecast.sdb into forecast.sdb.txt 
>
> Michael Waldor schrieb am Sonntag, 29. November 2020 um 10:23:34 UTC+1:
>
>> Sorry, but google doesn't allow me to append the data. Thus I try again 
>> ...
>>
>>

-- 
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/23bc8b05-639e-4a2b-9860-0e9b92ca6e8cn%40googlegroups.com.
## forecast compact - Copyright 2016 Matthew Wall
## $Id: forecast_compact.inc 1745 2017-09-21 03:54:21Z mwall $
#set $forecast_compact_version = 0.1
##
## Include this file to display forecast data.  This file uses icons from the
## forecast icon set.
##
## To override the default settings in this file, use the following syntax in
## skin.conf or weewx.conf:
##
## [forecast_compact_settings]
## source = NWS
## num_days = 7
## show_wind = 1
## show_pop = 1
## show_precip = 1
## show_obvis = 1



#if $varExists('forecast')

#import time
#set $t0 = time.time()

## Which forecast should be displayed?
#set $forecast_source = 'WU'

## How many days should be considered?
#set $num_days = 6

## Which data should be displayed?
#set $show_wind = 1
#set $show_pop = 1
#set $show_precip = 1
#set $show_obvis = 1

#set $local_settings = dict()

## First look for values from skin.conf or weewx.conf
#if $varExists('Extras') and $varExists('Extras.forecast_compact_settings')
  #for $sv in $Extras.forecast_compact_settings.keys()
#set $local_settings[$sv] = $Extras.forecast_compact_settings[$sv]
  #end for
#end if

## Look for overrides defined by any template that includes this file
#if $varExists('forecast_compact_settings')
  #for $sv in $forecast_compact_settings.keys()
#set $local_settings[$sv] = $forecast_compact_settings[$sv]
  #end for
#end if

## Now assign the values that will actually be used
#set $forecast_source = $local_settings.get('source', $forecast_source)
#set $num_days = int($local_settings.get('num_days', $num_days))
#set $show_wind = int($local_settings.get('show_wind', $show_wind))
#set $show_pop = int($local_settings.get('show_pop', $show_pop))
#set $show_precip = int($local_settings.get('show_precip', $show_precip))
#set $show_obvis = int($local_settings.get('show_obvis', $show_obvis))

## pre-calculate the periods
#set $num_periods = $num_days * 24
#set $periods = $forecast.weather_periods($forecast_source, 
max_events=$num_periods)

#if len($periods)
#set $start_ts = $t0


  

  
  
  
Max
Min
  
  Wind
#if $show_pop
  PoP
#end if

#for $d in range($num_days)
#set $summary = $forecast.weather_summary($forecast_source, $start_ts + $d * 
24*3600, periods=$periods)

  
$summary.event_ts.format('%a')
  
  
#if $summary.clouds is not None
#set $simg = 'icons/' + $summary.clouds + '.png'

#end if
  
  
$summary.tempMax.nolabel('%.0f')
$summary.tempMin.nolabel('%.0f')
  
#if $show_wind
  
$summary.windSpeed.nolabel('%.1f')
  
#end if
#if $show_pop
  
$summary.pop.nolabel('%.0f')
  
#end if
#if $show_precip
  
  #for $k in $summary.precip
#set $precip_img = 'icons/' + $k + '.png'
  
  #end for
  
#end if
#if $show_obvis
  
  #for $k in $summary.obvis
#set $obvis_img = 'icons/' + $k + '.png'
  
  #end for
  
#end if

#end for

  
  
  
$unit.label.outTemp
$unit.label.outTemp
  
  
$unit.label.windSpeed
  
#if $show_pop
  %
#end if

  



#else

No forecast data for $forecast_source

#end if

#set $t1 = time.time()
#set $elapsed = "%.3f" % ($t1 - $t0)


#else

forecast_iconic: forecast search list extension is not installed

#end if

Re: [weewx-user] forcast wunderground for weewx 4.2.x using python 3

[Michael Waldor]

Tried to rename forecast.sdb into forecast.sdb.txt 

Michael Waldor schrieb am Sonntag, 29. November 2020 um 10:23:34 UTC+1:

> Sorry, but google doesn't allow me to append the data. Thus I try again ...
>
>

-- 
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/2c5554f8-6ccd-4133-b77d-10ed297b1675n%40googlegroups.com.
SQLite format 3

@  


.0:

`
`‡

ŽtablearchivearchiveCREATE
 TABLE archive (`method` VARCHAR(10) NOT NULL, `usUnits` INTEGER NOT NULL, 
`dateTime` INTEGER NOT NULL, `issued_ts` INTEGER NOT NULL, `event_ts` INTEGER 
NOT NULL, `duration` INTEGER, `location` VARCHAR(64), `desc` VARCHAR(256), 
`zcode` CHAR(1), `hour` INTEGER, `tempMin` REAL, `tempMax` REAL, `temp` REAL, 
`dewpoint` REAL, `humidity` REAL, `windDir` VARCHAR(3), `windSpeed` REAL, 
`windGust` REAL, `windChar` VARCHAR(2), `clouds` VARCHAR(2), `pop` REAL, `qpf` 
VARCHAR(8), `qsf` VARCHAR(5), `rain` VARCHAR(2), `rainshwrs` VARCHAR(2), 
`tstms` VARCHAR(2), `drizzle` VARCHAR(2), `snow` VARCHAR(2), `snowshwrs` 
VARCHAR(2), `flurries` VARCHAR(2), `sleet` VARCHAR(2), `frzngrain` VARCHAR(2), 
`frzngdrzl` VARCHAR(2), `hail` VARCHAR(2), `obvis` VARCHAR(3), `windChill` 
REAL, `heatIndex` REAL, `uvIndex` INTEGER, `airQuality` INTEGER, `hilo` 
CHAR(1), `offset` REAL, `waveheight` REAL, `waveperiod` REAL)

¹

Re: [weewx-user] forcast wunderground for weewx 4.2.x using python 3

[Michael Waldor]

I still have trouble with the data displayed from WU forecast. The 
displayed values for temperature max/min are constant for the current week 
at 4/-3 °C. Thus I've analyzed the data within /var/lib/forecast.sdb. And 
here there are the 4/-3 values stored at fields tempMax/tempMin as 
40.0/26.0 °F. As you wrote the forecust extension does NOT use 
tempMin/tempMax, and the values stored within the DB field temp look great 
- the temperatures are not constant, and their values are more plausible 
for our area. And they match the json data for field temperature. But those 
values are NOT shown within the rendered nginx Seasons window.

Maybe I'm using the wrong forecast_compact.inc (see my included file)? And 
see als my forecast.sdb and 5day.json with the presumably correct temp 
values, but not shown within the rendered window.

-- 
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/5c0e9b4a-fdb2-4dc6-bdec-4296cb1d1f9dn%40googlegroups.com.

[weewx-user] Re: Installing WH23xx driver

['Michael Waldor' via weewx-user]

I'm using the WH23xx with Python 3, but one has to use a beta version from
https://github.com/EdwinGH/weewx-wh23xx

See also my post some threads before... Just in case you also want to use 
forecast. 

harri@gmail.com schrieb am Sonntag, 22. November 2020 um 15:29:22 UTC+1:

> Hi,
> reinstalling the weewx on a Raspberry Pi 1B is not running at all. 
> Following all guide lines for installing weewx on an Debian based linux as 
> well as Matthew Wall´s guide line on Github - it is just not working. 
> One point I am puzzled is that the driver WH23xx is not presented in the 
> driver menue shown in wee_config. In weewx.con there is not section for 
> WH23xx. Unfortuantely I lost the config file of my older installation.
> OS = Raspian OS lite
> Python 3.7
>
> Some advice?
> Greetings
> Harry
>

-- 
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/baef8365-fb9b-4372-956b-60ec31bb6647n%40googlegroups.com.

Re: [weewx-user] forcast wunderground for weewx 4.2.x using python 3

['Michael Waldor' via weewx-user]

Thanks for you deeper investigation of my forecast problem. Thus everything 
is fine within the forcast module. I myself did now increase the number of 
forecast days to 6 since there is free rendering space on generated HTML 
page anyway.

And I could resolve my weewx startup issue. I simply re-worked all setup 
files starting from original 4.2 files and merged in only those changes 
really needed. And then everything works as expected.

jo...@johnkline.com schrieb am Samstag, 21. November 2020 um 19:14:00 UTC+1:

> You’ll need to ask about your new issues, unrelated to the forecast 
> extension, on a new thread.
>
> As for what you are seeing in the forecast, the way the extension was 
> written, the two 12 hour periods are reported and the high and low come 
> from that data (NOT the temperatureMin and temperatureMax fields.
>
> I ran your forecast and got:
>
> "daypartName":[null,"Tonight","Tomorrow","Tomorrow night","Monday","Monday 
> night","Tuesday","Tuesday night","Wednesday","Wednesday 
> night","Thursday","Thursday night"]
>
> "temperature":[null,-2,8,2,7,2,9,1,10,1,11,2],
>
> Reformatted for the discussion as:
>
> Null :  Null, Tonight: -2
>
> Tomorrow :  8   , Tomorrow Night :  2
>
> Monday   :  7   , Monday Night   :  2
>
> Tuesday  :  9   , Tuesday Night  :  1
>
> Wednesday: 10   , Wednesday Night:  1
>
> Thursday : 11   , Thursday Night :  2
>
> The extension uses the day temp for high and the night temp for low.  Thus:
>
> Day H/L
>
> Tonight  : -2/-2 (There is no longer a day as it has passed.)
>
> Tomorrow :  8/2
>
> Monday   :  7/2
>
> Tuesday  :  9/1
>
> Wednesday: 10/1
>
> Thursday : 11/2
>
> This matches your report, save for the low tomorrow (which differs by one 
> degree); but that is likely because the forecast used in the report was older 
> than when you got the forecast in your browser (they are only requested 
> periodically, not on every reporting cycle).
>
> On Nov 21, 2020, at 9:18 AM, 'Michael Waldor' via weewx-user <
> weewx...@googlegroups.com> wrote:
>
> 
>
> Sorry for my late response. My problem is still there. Just now I've run 
> weewx-4.2.0 using "original" weewx.conf/original skins (as they are after 
> fresh installation) - only changes are my 2 API keys for wunderground. 
> Still I feel that the data look wrong if compared with direct JSON output. 
> I've appended both.
> The rendered forecast says
> Max -2 8 7 9 °C
> Min -2 3 2 1  "C
> while the json says
> "temperatureMax":[null,8,7,9,10,11],
> "temperatureMin":[-2,3,1,1,1,2],
>
> Currently I'm trying to merge "my" old weewx.conf with the one from my 
> fresh weex-4.2.0 installation. Here, too, I encounter spurious behaviour. 
> Both work, but as soon as I merge in all new things from original 4.s.0 
> into my weewx.conf aftrewards weewx silently dies during start. From my 
> perspective the only changes are whitespace (I know that python is crucial 
> with indentation) and some added units. Ok, within my weewx.conf I want to 
> disable as much logging as possible. These are the kind of changes, e.g.
> NEW: group_distance = km   # Options 
> are 'mile' or 'km'
> SPURIOUS:  [DegreeDays] and [Trend] looses one level 
> of brackets (I've tried both - no improvement)
> NEW: many prefer_hardware entries
> NEW:xtype_services = weewx.wxxtypes.StdWXXTypes, 
> weewx.wxxtypes.StdPressureCooker, weewx.wxxtypes.StdRainRater (I've tried 
> with and without this line - no improvement)
> Currently I've no clue why my settings and the original both work, while 
> their merge not.
>
> To get more information I've also tried debug=1 - no additional message, 
> silent death.
> But guess that's another topic that I have to check on my own. I just 
> report it for completeness.
>
> Hope you can reproduce my forecast problem. And thanks for your support,
>
> Michael
>
>
>
>
>
> jo...@johnkline.com schrieb am Samstag, 21. November 2020 um 03:53:50 
> UTC+1:
>
>> This is my repository and that is the latest release.  I recall that I 
>> had to remove a column because it was not available in the new WU forecast 
>> (the old API no longer exists).  You don’t mention the column removed; but 
>> if you research it, I think you’ll find it’s not in the forecast returned. 
>>  If not, let me know (and please do mention the column you are referring 
>> to).
>>
>> If you want to give me a reproducible case fo

Re: [weewx-user] forcast wunderground for weewx 4.2.x using python 3

['Michael Waldor' via weewx-user]

Sorry for my late response. My problem is still there. Just now I've run 
weewx-4.2.0 using "original" weewx.conf/original skins (as they are after 
fresh installation) - only changes are my 2 API keys for wunderground. 
Still I feel that the data look wrong if compared with direct JSON output. 
I've appended both.
The rendered forecast says
Max -2 8 7 9 °C
Min -2 3 2 1  "C
while the json says
"temperatureMax":[null,8,7,9,10,11],
"temperatureMin":[-2,3,1,1,1,2],

Currently I'm trying to merge "my" old weewx.conf with the one from my 
fresh weex-4.2.0 installation. Here, too, I encounter spurious behaviour. 
Both work, but as soon as I merge in all new things from original 4.s.0 
into my weewx.conf aftrewards weewx silently dies during start. From my 
perspective the only changes are whitespace (I know that python is crucial 
with indentation) and some added units. Ok, within my weewx.conf I want to 
disable as much logging as possible. These are the kind of changes, e.g.
NEW: group_distance = km   # Options 
are 'mile' or 'km'
SPURIOUS:  [DegreeDays] and [Trend] looses one level of 
brackets (I've tried both - no improvement)
NEW: many prefer_hardware entries
NEW:xtype_services = weewx.wxxtypes.StdWXXTypes, 
weewx.wxxtypes.StdPressureCooker, weewx.wxxtypes.StdRainRater (I've tried 
with and without this line - no improvement)
Currently I've no clue why my settings and the original both work, while 
their merge not.

To get more information I've also tried debug=1 - no additional message, 
silent death.
But guess that's another topic that I have to check on my own. I just 
report it for completeness.

Hope you can reproduce my forecast problem. And thanks for your support,

Michael





jo...@johnkline.com schrieb am Samstag, 21. November 2020 um 03:53:50 UTC+1:

> This is my repository and that is the latest release.  I recall that I had 
> to remove a column because it was not available in the new WU forecast (the 
> old API no longer exists).  You don’t mention the column removed; but if 
> you research it, I think you’ll find it’s not in the forecast returned.  If 
> not, let me know (and please do mention the column you are referring to).
>
> If you want to give me a reproducible case for the lows; using just the 
> forecast pages (i.e., not copying files to seasons) and tell me what page 
> is wrong; I will look at it.  I already have your lat long; so it will be 
> able to reproduce here.
>
> On Nov 20, 2020, at 7:46 AM, 'Michael Waldor' via weewx-user <
> weewx...@googlegroups.com> wrote:
>
> 
>
> As I wrote in the original post I did re-install the forecast module using 
> wee_extension. But I use it as part of Seasons skin within the left area 
> below "Current conditions". To get that I had to copy forecast_compact.css, 
> forecast_compact.inc, and the icons into Seasons skin. I only skipped the 
> update of these skin files for my new weewx 4 environment. Now I've 
> compared forecast_compact.* from weewx 3.x with their new successors from 
> weeewx 4 - css is unchanged while there are many changes within inc. Thus I 
> now use that updated forecast_compact.inc. Now the compact forecast 
> contains only 4 instead of 5 columns, but with unchanged data (column 
> Tuesday is missing).
>
> I've re-engaged the forecast skin to get "raw" forecast without Seasons 
> skin. It, too, contains the wrong data with 4 columns (instead of 5) and 
> with "wrong" data.
>
> But to me it's still unclear if I'm using the "correct" recent forecast 
> module weewx-forecast-3.4.0b10.zip
>  (
> https://github.com/chaunceygardiner/weewx-forecast/releases/tag/v3.4.0b10). 
> Is this the correct one?
>
>
> jo...@johnkline.com schrieb am Freitag, 20. November 2020 um 16:12:08 
> UTC+1:
>
>> > but as is from weewx 3.x - no update of skin skin files)
>>
>> You are going to need to install this extension, not just copy over the 
>> python file, so we can compare apples to apples here.  I know I had to make 
>> more changes than just the python file to get this working.  Please do a 
>> proper install and report back.
>>
>> On Nov 20, 2020, at 7:00 AM, 'Michael Waldor' via weewx-user <
>> weewx...@googlegroups.com> wrote:
>>
>> 
>>
>> Disclaimer: This is my first usage of google groups - hope the answer 
>> reaches this thread.
>>
>> Ok, from json I get (using my api_key):
>> "temperatureMax":[null,7,9,8,9,11],"temperatureMin":[-3,-1,4,2,1,4]
>> which sounds reasonable for my location (see my original post).
>>
>> Within forecast seasons I see the appended kind of table (I use 
&g

Re: [weewx-user] forcast wunderground for weewx 4.2.x using python 3

['Michael Waldor' via weewx-user]

As I wrote in the original post I did re-install the forecast module using 
wee_extension. But I use it as part of Seasons skin within the left area 
below "Current conditions". To get that I had to copy forecast_compact.css, 
forecast_compact.inc, and the icons into Seasons skin. I only skipped the 
update of these skin files for my new weewx 4 environment. Now I've 
compared forecast_compact.* from weewx 3.x with their new successors from 
weeewx 4 - css is unchanged while there are many changes within inc. Thus I 
now use that updated forecast_compact.inc. Now the compact forecast 
contains only 4 instead of 5 columns, but with unchanged data (column 
Tuesday is missing).

I've re-engaged the forecast skin to get "raw" forecast without Seasons 
skin. It, too, contains the wrong data with 4 columns (instead of 5) and 
with "wrong" data.

But to me it's still unclear if I'm using the "correct" recent forecast 
module weewx-forecast-3.4.0b10.zip
 (https://github.com/chaunceygardiner/weewx-forecast/releases/tag/v3.4.0b10). 
Is this the correct one?


jo...@johnkline.com schrieb am Freitag, 20. November 2020 um 16:12:08 UTC+1:

> > but as is from weewx 3.x - no update of skin skin files)
>
> You are going to need to install this extension, not just copy over the 
> python file, so we can compare apples to apples here.  I know I had to make 
> more changes than just the python file to get this working.  Please do a 
> proper install and report back.
>
> On Nov 20, 2020, at 7:00 AM, 'Michael Waldor' via weewx-user <
> weewx...@googlegroups.com> wrote:
>
> 
>
> Disclaimer: This is my first usage of google groups - hope the answer 
> reaches this thread.
>
> Ok, from json I get (using my api_key):
> "temperatureMax":[null,7,9,8,9,11],"temperatureMin":[-3,-1,4,2,1,4]
> which sounds reasonable for my location (see my original post).
>
> Within forecast seasons I see the appended kind of table (I use 
> forecast_compact.css 
> within seasons, but as is from weewx 3.x - no update of skin skin files) 
> - part from /var/www/html/weewx/index.html with the forecast table. To 
> compare the HTML more easily I've extracted the relevant part from my 
> rendered weather page :
>
> Fr FW -2 -2 6,4 10
> Sa SC  7 -1 7,2 10
> So OV  9 -1 6,4 10
> Mo OV  8 -1 6,4 20
> Di SC  9 -1 8,0 10
>
> As you see the (rendered) temperatureMin is -2,-1,-1,-1,-1
>
>
> jo...@johnkline.com schrieb am Freitag, 20. November 2020 um 14:20:43 
> UTC+1:
>
>> Would you please get specific about what you think is wrong?  Include the 
>> WU output when you use the URL directly.
>>
>> Let’s concentrate on temperature, since you’ve called that out.  You’ll 
>> see something like this in the output:
>>
>> "temperatureMax":[7,7,9,8,9,11],"temperatureMin":[-3,-1,4,2,1,4],
>>
>> Please include that line and the numbers you are seeing in the forecast. 
>>  The code is grabbing the high for the daytime 12-hour period and the low 
>> form the nighttime 12-hour period.  That probably needs to change as, for 
>> example, the low for the day could be lower than the low for the nighttime 
>> period.  Let’s see your specific numbers to determine if that is the issue.
>>
>> On Nov 20, 2020, at 1:16 AM, 'Michael Waldor' via weewx-user <
>> weewx...@googlegroups.com> wrote:
>>
>> 
>>
>> Just some days ago I've upgraded my raspberry pi 3 installation of weewx 
>> from 3.x to 4.x (forced to because my SD card seemed to be corrupted).
>>
>> Since I had to reinstall everything I decided to go with the most recent 
>> versions - i.e. upgrade raspian from stretch to buster, upgrade weewx from 
>> 3.x to 4.x, switch from python 2 to python 3.
>>
>> Getting weewx 4.x was not straightforward to me (I read my own 
>> documentation when I did my first install more then 2 years back and the 
>> current upgrade instructions) - by my fault I installed the python 2 weewx 
>> by apt-get, but finally I discovered the current apt-get repository, and 
>> now weewx-4.2.0 using python 3 is up and running.
>>
>> I had an additional problem. My weather station is the Renkforce WH2300 
>> using the wh23xx extension. As far as I understand this extension is as of 
>> now not fully ported to python 3. But I discovered a fork an github 
>> https://github.com/EdwinGH/weewx-wh23xx
>> That's running smooth but (being beta) floods the logs - thus I've 
>> changed its function logmsg to to nothing (python command pass).
>>
>> And now finally to my remaining problem: I also use the forcast extension 
>> with wunderground. Here, too, I'm using a tempo

Re: [weewx-user] forcast wunderground for weewx 4.2.x using python 3

['Michael Waldor' via weewx-user]

Disclaimer: This is my first usage of google groups - hope the answer 
reaches this thread.

Ok, from json I get (using my api_key):
"temperatureMax":[null,7,9,8,9,11],"temperatureMin":[-3,-1,4,2,1,4]
which sounds reasonable for my location (see my original post).

Within forecast seasons I see the appended kind of table (I use 
forecast_compact.css 
within seasons, but as is from weewx 3.x - no update of skin skin files) - 
part from /var/www/html/weewx/index.html with the forecast table. To 
compare the HTML more easily I've extracted the relevant part from my 
rendered weather page :

Fr FW -2 -2 6,4 10
Sa SC  7 -1 7,2 10
So OV  9 -1 6,4 10
Mo OV  8 -1 6,4 20
Di SC  9 -1 8,0 10

As you see the (rendered) temperatureMin is -2,-1,-1,-1,-1


jo...@johnkline.com schrieb am Freitag, 20. November 2020 um 14:20:43 UTC+1:

> Would you please get specific about what you think is wrong?  Include the 
> WU output when you use the URL directly.
>
> Let’s concentrate on temperature, since you’ve called that out.  You’ll 
> see something like this in the output:
>
> "temperatureMax":[7,7,9,8,9,11],"temperatureMin":[-3,-1,4,2,1,4],
>
> Please include that line and the numbers you are seeing in the forecast. 
>  The code is grabbing the high for the daytime 12-hour period and the low 
> form the nighttime 12-hour period.  That probably needs to change as, for 
> example, the low for the day could be lower than the low for the nighttime 
> period.  Let’s see your specific numbers to determine if that is the issue.
>
> On Nov 20, 2020, at 1:16 AM, 'Michael Waldor' via weewx-user <
> weewx...@googlegroups.com> wrote:
>
> 
>
> Just some days ago I've upgraded my raspberry pi 3 installation of weewx 
> from 3.x to 4.x (forced to because my SD card seemed to be corrupted).
>
> Since I had to reinstall everything I decided to go with the most recent 
> versions - i.e. upgrade raspian from stretch to buster, upgrade weewx from 
> 3.x to 4.x, switch from python 2 to python 3.
>
> Getting weewx 4.x was not straightforward to me (I read my own 
> documentation when I did my first install more then 2 years back and the 
> current upgrade instructions) - by my fault I installed the python 2 weewx 
> by apt-get, but finally I discovered the current apt-get repository, and 
> now weewx-4.2.0 using python 3 is up and running.
>
> I had an additional problem. My weather station is the Renkforce WH2300 
> using the wh23xx extension. As far as I understand this extension is as of 
> now not fully ported to python 3. But I discovered a fork an github 
> https://github.com/EdwinGH/weewx-wh23xx
> That's running smooth but (being beta) floods the logs - thus I've changed 
> its function logmsg to to nothing (python command pass).
>
> And now finally to my remaining problem: I also use the forcast extension 
> with wunderground. Here, too, I'm using a temporary version from 
> https://github.com/chaunceygardiner/weewx-forecast to get early python 3 
> support. It seems to work - I get forcast messages. But the data shown seem 
> to be partly off. If I do a direct WU query using json like
>
>
> https://api.weather.com/v3/wx/forecast/daily/5day?geocode=48.959678,9.25629=json=m=en-US=XXx
>
> I get different max/min temperatures compared with the data shown within 
> the seasons skin. Especially the forcast for the current day looks always 
> bad. Did I make a mistake within weewx.conf - it contains only the WU 
> api_key (no separate location)?
>
> -- 
> 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/5cacd1fa-51c2-4ad6-b995-5d12d7aa5a7dn%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/weewx-user/5cacd1fa-51c2-4ad6-b995-5d12d7aa5a7dn%40googlegroups.com?utm_medium=email_source=footer>
> .
>
>

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

  

   
  
  
Max
Min
  
  Wind
  PoP


  
Fr
  
  

  
  
-2
-2
  
  
6,4
  
  
10
  
  
  
  
  


  
Sa
  
  

[weewx-user] forcast wunderground for weewx 4.2.x using python 3

['Michael Waldor' via weewx-user]

Just some days ago I've upgraded my raspberry pi 3 installation of weewx 
from 3.x to 4.x (forced to because my SD card seemed to be corrupted).

Since I had to reinstall everything I decided to go with the most recent 
versions - i.e. upgrade raspian from stretch to buster, upgrade weewx from 
3.x to 4.x, switch from python 2 to python 3.

Getting weewx 4.x was not straightforward to me (I read my own 
documentation when I did my first install more then 2 years back and the 
current upgrade instructions) - by my fault I installed the python 2 weewx 
by apt-get, but finally I discovered the current apt-get repository, and 
now weewx-4.2.0 using python 3 is up and running.

I had an additional problem. My weather station is the Renkforce WH2300 
using the wh23xx extension. As far as I understand this extension is as of 
now not fully ported to python 3. But I discovered a fork an github 
https://github.com/EdwinGH/weewx-wh23xx
That's running smooth but (being beta) floods the logs - thus I've changed 
its function logmsg to to nothing (python command pass).

And now finally to my remaining problem: I also use the forcast extension 
with wunderground. Here, too, I'm using a temporary version from 
https://github.com/chaunceygardiner/weewx-forecast to get early python 3 
support. It seems to work - I get forcast messages. But the data shown seem 
to be partly off. If I do a direct WU query using json like

https://api.weather.com/v3/wx/forecast/daily/5day?geocode=48.959678,9.25629=json=m=en-US=XXx

I get different max/min temperatures compared with the data shown within 
the seasons skin. Especially the forcast for the current day looks always 
bad. Did I make a mistake within weewx.conf - it contains only the WU 
api_key (no separate location)?

-- 
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/5cacd1fa-51c2-4ad6-b995-5d12d7aa5a7dn%40googlegroups.com.

[weewx-user] Re: OWM & PoP

[Michael Waldor]

In the meantime I can answer my questions myself (and post it here if 
others encounter the same problems):

OWM does not report PoP data (I've checked the downloaded data within 
forecast.sdb).

Wunderground (WU) still provides forecast to PWS owners for free using a 
new API. One has to request an API key within WU preference web page. The 
new API key works fine as one can validate by requesting the "raw" JSON 
output. But as of forecast-3.3.2 this new API is not supported. Thus the 
new WU forecast data won't show up within weewx.

Now I'll wait till Matt will update his forcast modul.


Regards, Michael

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

[weewx-user] OWM & PoP

[Michael Waldor]

Hello!

Due to the API change from wonderground I no longer get weather forcast 
from WU. Thus I switchet to OWM. It works fine, but I do not get rain data, 
i.e. the PoP field is always N/A.
Does OWM provide PoP data at all? And does it also provide them for Germany?

Or is there an alternative to still get forcast data from WU without a paid 
license key?


I'm running the most recent weewx 3.9.1 (Seasons skin) with the most recent 
forecast 3.3.2 on a raspberry pi (just updated today to the most recent 
raspbian 9, linux 4.14.98-v7+).

But I had the problem with missing PoP data already with the previous 
versions.


Regards, Michael

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

[weewx-user] Re: WH4000 (WH3080) changes transmitter ID when it starts to Rain

[Michael Waldor]

I, too, have the same problem.

My guess is that due to heavy rain the radio signal is attenuated too much. 
I use a raspberry to log the data, 10cm next to the weather station. 2 
weeks ago I've switched from wifi to LAN connection thus reducing radio 
interference somehow. Till now I did not loose the outdoor sensors even 
during rain.

But I suffer under two other problems:
1. UV sensor has died after 6months - its data degraded end of July over 
some days till it was zero continuously.
2. I sometimes have USB connection problems being solved by rebooting my 
raspberry - I use a watchdog now to reboot automatically.

Am Donnerstag, 13. Dezember 2018 20:11:04 UTC+1 schrieb Kalli:
>
>  Bei mir ist das auch so.
> nur die ID vom UV sensor bleibt.
>

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