gt;>> 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.
>>>
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 back
red, 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 itse
t 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.
>
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
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
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 wi
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
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 fil
;
>> 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 p
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
W
#x27;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.
>>>>>>>&
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
>>>>>>> h
appy 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 ch
ne 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
n 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
>>&g
. 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, De
g 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
>> tim
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
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 i
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).
Micha
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 schrie
ase, 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 ha
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
ning 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" da
y. 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 c
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 f
able. 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
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 se
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
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 addin
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 e
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 (mos
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 appende
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
[[[da
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.
Bu
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
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
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. S
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 wundergroun
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
[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.wx
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 serv
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]
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
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 je
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
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
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 t
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
e 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
>
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 i
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,
> reinstalli
> 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
>
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
ing. 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
wer 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
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
58 matches
Mail list logo
