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 [email protected] 
>>> 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 [email protected] 
>>>>> 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 <
>>>>>>>> [email protected]> 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 [email protected].
>>>>>>>>> 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&utm_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 [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/38e8999b-b877-45d0-acfe-dce66177bab1n%40googlegroups.com.

Reply via email to