Sunshine Database

624 views
Skip to first unread message

Meteo Oberwallis

unread,
Jun 1, 2022, 8:33:17 AM6/1/22
to weewx-user
Hello, everyone.
I have a question. Would it be possible to create a separate database for sunshine time? The reason is actually that if the recording interval is set to 10 minutes, the hours of sunshine are then only recorded at intervals of 10 minutes. More precisely, if the solar value is too low in minute 10 or 20 etc., but the value was higher during 8 minutes, then it automatically takes the whole 10 minutes as no sunshine. But if you query the solar value every minute via weewx and compare it with the "Sunshine Time", you would have a much better record. If there was a separate sql for the sunshine time, like e.g. the air quality sensor. In order to make the whole thing even gentler, one could solve it in such a way that the "automation" only becomes active as soon as the solar sensor delivers a value. Is there any of that already? The graphics etc. can then be uploaded normally every 5 or 10 minutes. But I would just like to have my own .sql for the hours of sunshine, which reads the value every minute. The script "https://github.com/Jterrettaz/sunduration" already exists.

Thank you for your feedback

Tom Keffer

unread,
Jun 1, 2022, 9:50:47 AM6/1/22
to weewx-user
My apologies, but I don't fully understand the problem. If the type you are trying to record is literally the amount of time the sun was out during the archive interval, then, in your example, why would no sunshine be recorded for the full 10 minutes? Wouldn't it be something less, but greater than zero. Say 8 minutes of sunshine?

What, exactly, is the type that you are trying to put in the database? There is no type 'sunshine' within WeeWX. 



--
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/8ba76e85-40d0-4e20-84ea-a33b38120e3bn%40googlegroups.com.

Peter Fletcher

unread,
Jun 2, 2022, 9:27:51 AM6/2/22
to weewx-user
I think that this is a sensor issue. If the sensor returns only a binary (sun/no sun) value, which appears to be the case for this computed 'sensor', then sampling it every 10 minutes will give results with a granularity of 10 minutes, as the OP describes; if the sensor returns the minutes (or seconds) of sunshine within the archive interval (similarly to the way the Vantage Rain sensor works), then it doesn't matter (within reason) how frequently or infrequently you sample it - the total will be valid. For a Davis setup and this sort of computed 'sensor', the 'sensor' will probably need to be sampled for each LOOP packet and the results accumulated internally and the totals saved in each archive record.

Tom Keffer

unread,
Jun 2, 2022, 11:57:13 AM6/2/22
to weewx-user
That would make sense.

I've had this same problem with pulse counters. Assuming that the sensor returns 0 or 1, one resolution is to use an accumulator that extracts the sum of values (rather than the default average). Then at the end of the archive interval, multiply the sum by the loop interval. The result will be the amount of time the sensor returned 1 during the archive interval, which should be the amount of time the sun was out.



Peter Fletcher

unread,
Jun 2, 2022, 5:54:11 PM6/2/22
to weewx-user
Well, sort of! I had been wanting to look at sunshine hours for a while, but it is decidedly non-trivial unless you actually have a sensor that can tell when the sun is out (they exist, and use the fact that the sun casts shadows when it is out, but they are very expensive). The approach used by the OP looks promising as a good approximation if you only have the standard VP 2 sensors. What I am doing with it is averaging the LOOP radiation readings over 30 seconds (15 LOOP packets), running the average through the algorithm he uses to get a binary indication of the sun being out during that period, and adding 30 (seconds) to a local variable for 'sun' and 0 for 'no sun'. The archive interval process simply stores the contents of the local variable in the appropriate archive record and then clears the local variable. I still have to work on summarizing and displaying the data.

Meteo Oberwallis

unread,
Jun 3, 2022, 2:17:00 PM6/3/22
to weewx-user
Hello folks.

I don't know if you understood me properly. With the help of the solar sensor of the Davis, the possibility of sunshine can be determined via script and the coordinates. That works fine so far.
But what I would like to do is, if the interval of Weewx and the data logger is set to 10 minutes, I would have liked to read the value of the solar sensor every minute and then write it into a separate .sdb database as possible sunshine. With this you can prevent that you can not measure the sunshine in the interval of 10 minutes, but every minute. That would be my goal. Since the data logger of the Davis is full within 8 days with an interval of 5 minutes, an increase to a 10-minute storage interval could increase it to a whopping 16 days. But if I set the interval to 10 minutes, then the possible sunshine is only recorded every 10 minutes. Not everything in between. If the solar value is then high enough at the measuring point, the full 10 minutes are registered as sunshine. With a minute interval, this could be obtained even more precisely


Thank you for your feedback

Peter Fletcher

unread,
Jun 3, 2022, 2:56:00 PM6/3/22
to weewx-user
I do understand what the script is doing. It's not perfect, or at least it almost certainly won't perfectly agree with other definitions of whether the sun is shining or not - based (e.g.) on the presence or absence of shadows under marginal conditiions - but it should be pretty reliable for most reasonable circumstances, and I had been thinking of 'home-brewing' a similar approach. I assume (perhaps incorrectly) that you are primarily interested in getting as precisely as possible a measurement of total sunshine time during a period of interest - rather than being able to say whether it was sunny at precisely 14:05 local time two days ago. My approach will do what (I think) you want - the sunny/not sunny decision is made every 30 seconds, and the archive records contain the number of seconds in the archive period during which it was sunny, with 30 second precision and granularity. You could save the LOOP radiation values in a separate database and get down to 2 second precision, but I am not sure why you would want to.

I will post the code here when I am sure that it is working properly.

vince

unread,
Jun 3, 2022, 3:24:23 PM6/3/22
to weewx-user
On Friday, June 3, 2022 at 11:17:00 AM UTC-7 Meteo Oberwallis wrote:
 if the interval of Weewx and the data logger is set to 10 minutes, I would have liked to read the value of the solar sensor every minute and then write it into a separate .sdb database as possible sunshine.

Personally I'd use an external program called via cron and posting a message to a MQTT topic.  Have weewx subscribe to that topic to get the data into your db.

This is how I used to get my DS18b20 temperature sensor data into weewx.

Peter Fletcher

unread,
Jun 3, 2022, 3:59:36 PM6/3/22
to weewx-user
That makes some sense when you are getting data from an 'external' sensor, though there are (IMHO) simpler ways of doing it. weewx already has access to the LOOP radiation data from the VP2, so handling the processing and data storage within weewx makes more sense to me in this case.

jterr...@gmail.com

unread,
Jun 4, 2022, 12:41:08 PM6/4/22
to weewx-user
It is a very good idea to calculate the sunshine duration for each LOOP packet and sum these values to make the final archive sunshine duration.  I have modified my script accordingly :  https://github.com/Jterrettaz/sunduration.
The logic is the following :  for each received LOOP packet, the radiation is compared to a calculated threshold. If the radiation is above the threshold value, the sunshine time for the LOOP packet is equal to the time elapsed between the  previous loop packet and this packet (most of the time 2 seconds with a Vantage Davis Pro).
The final archive sunshine duration is the sum of all the LOOP value within the archive period.

Peter Fletcher

unread,
Jun 5, 2022, 12:02:42 PM6/5/22
to weewx-user
I chose to average the LOOP radiation readings and only to do the threshold calculation and make the sun/no sun determination every 30 seconds because I thought doing it on every LOOP might overload LOOP processing (I am running weewx on a Pi 3B, which is also doing a few other things which use the CPU). If this is an unnecessary concern, as it may very well be, your modified code is much cleaner than mine.

Jacques Terrettaz

unread,
Jun 5, 2022, 12:33:47 PM6/5/22
to weewx...@googlegroups.com
I think it is also OK to do an average for every 30 seconds.  It depends also on the weather station used.
For  instance, a Davis Vantage Pro 2 ISS transmits an updated  solar radiation value every 50 to 60 seconds. So with this weather station, even a 1 minute average would not be very different  since anyway the solar radiation values of the LOOP packet are the same for at least 50 seconds.!

--
You received this message because you are subscribed to a topic in the Google Groups "weewx-user" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/weewx-user/19ylVTRqbh4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to weewx-user+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/0e631671-0a74-4963-9f1c-e5f81bc7c366n%40googlegroups.com.

Peter Fletcher

unread,
Jun 5, 2022, 1:40:39 PM6/5/22
to weewx-user
I am using a Vantage Pro 2, and I had forgotten (if I ever knew!) that the solar radiation value had a slower update rate than most other weather values, but it is certainly another reason not to worry about processing every LOOP value separately. You could even argue that (for this hardware) the LOOP code should accumulate time until the reported radiation value actually changes (or until an appropriately set  maximum time elapses) before processing the previous period's values.

Peter Fletcher

unread,
Jun 9, 2022, 4:26:53 PM6/9/22
to weewx-user
After some experimentation, I found that the radiation value in the VP2 LOOP packets does, indeed, normally change every 50-52 seconds, but, perhaps about a fifth of the 'gaps' are a multiple of that time - most often 100+ or 150+ seconds, but occasionally more than that (I saw one 250+ second 'gap'). I saw this under conditions of variable sunshine and clouds when it seemed unlikely that the actual radiation value would have been precisely constant for that length of time, so I am not sure exactly what is going on. In any event, I am revising the code I am using on the basis of doing the threshold calculation when the radiation level changes, but at least every minute, if it remains constant for more than the normal 50-52 seconds..

On Sunday, June 5, 2022 at 12:33:47 PM UTC-4 jterr...@gmail.com wrote:

Jacques Terrettaz

unread,
Jun 10, 2022, 3:29:40 AM6/10/22
to weewx...@googlegroups.com
On my side, I have looked at the CPU utilization on my raspberry Pi 3B+. I have the mqtt  service service installed, so at each loop all data of the packet are sent to the mqtt broker.

With mqtt and when calculations of the sunshine threshold is done for each loop packet, the total CPU utilization of python3 is about 0.75%
With mqtt and without calculation of sunshine threshold : 0.5% of total CPU.

So one can estimate that 0.25 % of total CPU is needed for the calculation of the threshold value for each LOOP packet.


Peter Fletcher

unread,
Jun 29, 2022, 5:23:16 PM6/29/22
to weewx-user
Have you had any odd weewx errors or crashes related to the sunshine calculations? I ask because I hadn't, but I decided to try to 'backfill' my database with sunshine times, based on the 5-minute radiation values, and I ran into a bizarre bug. I used the code shown below (on a copy of my live weewx database). As you will see, the threshold calculation code is essentially identical to yours, except that it has been converted to a regular function (no 'self' parameter) and my station's latitude and longitude are hard coded in it. When the code is run under Python 3.9.2 on my Pi, it initially runs without problems, but crashes after 8,000+ records have been processed with a ValueError on the MaxThreshold vs threshold comparison, reporting that it can't compare a complex with a float! If I intercept and log the errors, it turns out that, for a few specific values of dateTime, the function returns a complex number! Even more bizarrely, it only seems to do that in the context of the running code. If I manually run through all the operations from the function code at the Python command line, using the value of dateTime that produces the first crash, all the intermediate results and the final result are sane floats.
There appears to be a second issue, possibly related to my reading and writing the database at relatively high frequency, which stalls the process after about 18,000 records have been processed, but removing the database writes allows it to run to completion without abolishing the consistent, albeit infrequent, ValueErrors.

[backfill.py]
import sqlite3
from datetime import datetime
import time
from math import sin, cos, pi, asin

def sunshineThreshold(mydatetime):
    coeff = 0.9  # change to calibrate with your sensor
    utcdate = datetime.utcfromtimestamp(mydatetime)
    dayofyear = int(time.strftime("%j", time.gmtime(mydatetime)))
    theta = 360 * dayofyear / 365
    equatemps = 0.0172 + 0.4281 * cos((pi / 180) * theta) - 7.3515 * sin(
        (pi / 180) * theta) - 3.3495 * cos(2 * (pi / 180) * theta) - 9.3619 * sin(
        2 * (pi / 180) * theta)

    latitude = 43.0346213
    longitude = -78.689362

    corrtemps = longitude * 4
    declinaison = asin(0.006918 - 0.399912 * cos((pi / 180) * theta) + 0.070257 * sin(
        (pi / 180) * theta) - 0.006758 * cos(2 * (pi / 180) * theta) + 0.000908 * sin(
        2 * (pi / 180) * theta)) * (180 / pi)
    minutesjour = utcdate.hour * 60 + utcdate.minute
    tempsolaire = (minutesjour + corrtemps + equatemps) / 60
    angle_horaire = (tempsolaire - 12) * 15
    hauteur_soleil = asin(sin((pi / 180) * latitude) * sin((pi / 180) * declinaison) + cos(
        (pi / 180) * latitude) * cos((pi / 180) * declinaison) * cos((pi / 180) * angle_horaire)) * (180 / pi)
    seuil = (0.73 + 0.06 * cos((pi / 180) * 360 * dayofyear / 365)) * 1080 * pow(
        (sin(pi / 180) * hauteur_soleil), 1.25) * coeff
    return seuil


database = 'weewx.sdb'

maxThreshold=0
count=0
conn=sqlite3.connect(database)
cur=conn.execute("SELECT dateTime, Radiation from archive")
for row in cur:
    count += 1
    if (row[1] is not None) and (row[1] > 20):
    threshold = sunshineThreshold(row[0])
    if threshold > maxThreshold:
        maxThreshold = threshold
    if row[1] > threshold:
        conn.execute("UPDATE archive set SunshineTime = 5 WHERE dateTime = " + str(row[0]))
    if count % 1000 == 0:
        print(count, 'Max Threshold', maxThreshold)
conn.close
[/backfill.py]

jterr...@gmail.com

unread,
Jun 30, 2022, 3:55:49 AM6/30/22
to weewx-user
No, I never had weewx  crashes related to the sunshine calculations. 

What are the dateTime values that trigger the error ?

Peter Fletcher

unread,
Jun 30, 2022, 8:34:01 AM6/30/22
to weewx-user
1592614500
1632611100
1632611400
1647688800

I can't see a pattern or any common features.

Jacques Terrettaz

unread,
Jun 30, 2022, 8:59:48 AM6/30/22
to weewx...@googlegroups.com
If you exclude the first one,1592614500 , with a query like "SELECT dateTime, Radiation from archive where dateTime <> 1592614500", will the script stop at 1592614800 ( the next dateTime) or will it continue and stop at 1632611100 ?

Peter Fletcher

unread,
Jun 30, 2022, 1:51:46 PM6/30/22
to weewx-user
It did as it seems you predicted - passed 1592614800 and stopped at 1632611100. You obviously have a clue as to what is going on. Please explain!

Karen K

unread,
Jun 30, 2022, 3:00:21 PM6/30/22
to weewx-user
I would try to include a try-except clause around that comparison like that:

    try:
        if threshold > maxThreshold:
            maxThreshold = threshold
    except ValueError:
        print(threshold,maxThreshold)

and see what the values are. May be one of them is None or NaN.


Jacques Terrettaz

unread,
Jun 30, 2022, 3:07:38 PM6/30/22
to weewx...@googlegroups.com
The only clue I have is that the problem is not due to an « overloading » of your raspberry pi, but seems to occur with specific dateTime values.
You can try to run your script only with a « bad » dateTime :

"SELECT dateTime, Radiation from archive where dateTime = 1592614500 »

Does the error occurs ? If yes, you can try to add debugging print commands inside the sunshineThreshold function to try to understand.



Peter Fletcher

unread,
Jun 30, 2022, 4:52:28 PM6/30/22
to weewx-user
That was going to be my next step! In fact, iterating through a list of the dateTime values that produce the errors in the real code and passing each value to the function confirms that it is the specific dateTime values that are causing the function to misbehave. The returned results are all complex numbers with negative and numerically identical (for a given dateTime) real and imaginary components. It does seem to be a bug in the function. I assume that hauteur_soleil should always be >=0. It appears that, for my latitude and longitude and for the given specific values of dateTime, it becomes negative. The last step in the calculation then involves raising a negative number to a non-integral power, which is guaranteed to produce interesting results! The really odd thing is that math.pow is not returning a ValueError, which the docs say is what should happen under these circumstances, but apparently trying to return a (possibly) valid complex result.

Jacques Terrettaz

unread,
Jul 1, 2022, 2:45:42 AM7/1/22
to weewx...@googlegroups.com
OK.  What I don't understand is that my code had always a test 

if hauteur_soleil > 3:  (according to Météo France)

or more recently

 if hauteur_soleil > 0: 

in the function, and this test is not on your function.

It should be :

 hauteur_soleil = asin(sin((pi / 180) * latitude) * sin((pi / 180) * declinaison) + cos(
        (pi / 180) * latitude) * cos((pi / 180) * declinaison) * cos((pi / 180) * angle_horaire)) * (180 / pi)
 If hauteur_soleil > 0:

  seuil = (0.73 + 0.06 * cos((pi / 180) * 360 * dayofyear / 365)) * 1080 * pow(
         (sin(pi / 180) * hauteur_soleil), 1.25) * coeff
  else :
seuil = 0
 return seuil

Peter Fletcher

unread,
Jul 1, 2022, 10:19:08 AM7/1/22
to weewx-user
Something like that is obviously needed. I don't know how my copy of the code omitted the test for hauteur_soleil being > 0. There are a number of sources from which I may have copied it, and I didn't keep links to all of them, but I can't imagine why I would have deleted the test if my source had included it. I will obviously add it to my working code.

Jacques Terrettaz

unread,
Jul 1, 2022, 10:47:43 AM7/1/22
to weewx...@googlegroups.com
OK. 
The variable "hauteur_soleil is the elevation of the sun, in degree.
From sunset to sunrise, this value will be negative (i.e. sun below the horizon).  
The formula developed by Metro France was validated to be effective only if sun elevation is > 3°.

In my own implantation of this algorithm, I decided to start the calculation of the sun threshold as soon as the sun elevation was > 0° and that the global radiation as measured by the Davis pyranometer was greeter than 20 W/m2.

I suspect that the few dateTime that trigger your  errors were in a situation in which sun elevation was just below zero and that the measured radiation was just higher than 20 W/m2

Peter Fletcher

unread,
Jul 1, 2022, 1:37:54 PM7/1/22
to weewx-user
I'm sure you are right about the triggering circumstances. The code in my weewx User routines was correct (using the Meteo France limit), but I had put in some modifications around the hauteur_soleil test in connection with the method I am using to average and 'normalize' the observations for the archive reports. I suspect that, in taking out those modifications for the archive update code, I inadvertently also removed the original test.

Meteo Oberwallis

unread,
Jul 16, 2022, 6:18:05 AM7/16/22
to weewx-user
Hello, everyone.
I eagerly await your experiences. It's very interesting what you can do. Now I wanted to ask you if there is already a finished code that you can use? Did I understand correctly that with these calculations you can measure the hours of sunshine by minutes and not just by the interval of the data logger?
Can you use it to fill up past values? So e.g. from the year 2019 or something?

Best regards
Stefan

Jacques Terrettaz

unread,
Jul 16, 2022, 7:19:44 AM7/16/22
to weewx...@googlegroups.com
Hello,

The final code is here : https://github.com/Jterrettaz/sunduration.  The calculation of sunshine time is done for every loop packet (every 2 seconds) and the sum of all these individual loop values within an archive interval  will be the archive sunshine time.
The Davis Vantage ISS is updating the solar radiation every 50 to 60 seconds, so the final archive sunshine time is rounded to the minute.

As I am writing this message, I have for instance right now a sunshine duration of 5h 18 min for today. (http://meteo-sciez.fr ).

For past values, LOOP packet are not stored in the weewx database, so it will not be possible the recalculate them by minutes. If you have missing sunshine duration in your database, you can use the approach described above by Peter Fletcher, but in that case the sunshine time, if any, will be equal to the archive interval

Best Regards

Jacques. 

Peter Fletcher

unread,
Jul 16, 2022, 11:01:34 AM7/16/22
to weewx-user

The code I am using is pasted below. The main threshold calculation is a copy of the original Meto-France code used by Jacques, but the calculation is only done when the radiation value changes or (approximately) every minute, if it has not changed. Also included is code to store Davis’s ‘Storm Rain’ value in the archive database. The stored value for sunshine time has more apparent precision than is given by Jacques's code, but it is probably neither more nor less accurate, since its accuracy is limited by the relatively slow 'response' of the Davis sensor.import syslog
from math import sin,cos,pi,asin


from datetime import datetime
import time

import weewx
from weewx.wxengine import StdService

import weewx.units
weewx.units.obs_group_dict['sunshine_time'] = 'group_sunshine'
weewx.units.USUnits['group_sunshine'] = 'minute'
weewx.units.MetricUnits['group_sunshine'] = 'minute'
weewx.units.MetricWXUnits['group_sunshine'] = 'minute'
weewx.units.default_unit_format_dict['minute'] = '%.0f'
weewx.units.default_unit_label_dict['minute'] = 'min'

weewx.units.obs_group_dict['stormRain'] = 'group_rain'

packet_count = 0
avg_radiation = 0
last_radiation = 0
last_calc_time = 0
cum_sunshine = 0
cum_time = 0
last_stormRain = 0

class LoopSunshineDuration(StdService):
    def __init__(self, engine, config_dict):
        super(LoopSunshineDuration, self).__init__(engine, config_dict)
        self.bind(weewx.NEW_LOOP_PACKET,self.newLoopRecord)

    def newLoopRecord(self, event):
        global packet_count, last_radiation, cum_sunshine, cum_time, last_calc_time, last_stormRain
        # The VP 2 radiation value normally only changes ~ every 50 seconds (or multiple thereof)
        pkt_radiation = event.packet.get('radiation')
        last_stormRain = event.packet.get('stormRain')
        if (pkt_radiation is None) or (pkt_radiation<=0):
            pass
        elif (packet_count < 29) and (pkt_radiation == last_radiation):
            packet_count += 1
        else:
            radiation = last_radiation
            last_radiation = pkt_radiation
            packet_count = 0
            timestamp = event.packet.get('dateTime')
            # Process the last value
            duration = timestamp - last_calc_time
            last_calc_time = timestamp
            seuil = 0
            coeff = 0.9
            if radiation > 0:
                utcdate = datetime.utcfromtimestamp(event.packet.get('dateTime'))
                dayofyear = int(time.strftime("%j",time.gmtime(event.packet.get('dateTime'))))


                theta = 360 * dayofyear / 365
                equatemps = 0.0172 + 0.4281 * cos((pi / 180) * theta) - 7.3515 * sin(
                    (pi / 180) * theta) - 3.3495 * cos(2 * (pi / 180) * theta) - 9.3619 * sin(
                    2 * (pi / 180) * theta)

                latitude= float(self.config_dict["Station"]["latitude"])
                longitude = float(self.config_dict["Station"]["longitude"])


                corrtemps = longitude * 4
                declinaison = asin(0.006918 - 0.399912 * cos((pi / 180) * theta) + 0.070257 * sin(
                    (pi / 180) * theta) - 0.006758 * cos(2 * (pi / 180) * theta) + 0.000908 * sin(
                    2 * (pi / 180) * theta)) * (180 / pi)

                minutesjour = utcdate.hour*60 + utcdate.minute


                tempsolaire = (minutesjour + corrtemps + equatemps) / 60
                angle_horaire = (tempsolaire - 12) * 15
                hauteur_soleil = asin(sin((pi / 180) * latitude) * sin((pi / 180) * declinaison) + cos(
                    (pi / 180) * latitude) * cos((pi / 180) * declinaison) * cos((pi / 180) * angle_horaire)) * (180 / pi)

                if hauteur_soleil > 3:
                    seuil = (0.73 + 0.06 * cos((pi / 180) * 360 * dayofyear / 365)) *1080 * pow((sin(pi / 180) * hauteur_soleil), 1.25) * coeff
                    if radiation > seuil:
                        cum_sunshine += duration
            cum_time += duration

class ArchSunshineDuration(StdService):
    def __init__(self, engine, config_dict):
        super(ArchSunshineDuration, self).__init__(engine, config_dict)

        # Start intercepting events:
        self.bind(weewx.NEW_ARCHIVE_RECORD, self.newArchiveRecord)

    def newArchiveRecord(self, event):
        global cum_sunshine, cum_time, last_stormRain
        event.record['stormRain'] = last_stormRain
        # for various reasons cum_sunshine does not necessarily contain exactly <archive interval> seconds of data
        if cum_time > 0: # do not divide by zero!
            event.record['sunshine_time'] = cum_sunshine / cum_time * event.record['interval'] # converted to minutes of sunshine
        else:
            event.record['sunshine_time'] = 0
        cum_sunshine = 0
        cum_time = 0

        syslog.syslog(syslog.LOG_DEBUG, "Calculated sunshine_time = %f" % event.record['sunshine_time'])

Meteo Oberwallis

unread,
Jul 16, 2022, 11:08:36 AM7/16/22
to weewx-user
Hello.

I have under the Version 3.9.2 this Problem:

Jul 16 17:04:44 Wetter systemd[1]: Starting LSB: weewx weather system...
Jul 16 17:05:15 Wetter weewx[3751]: engine: Initializing weewx version 3.9.2
Jul 16 17:05:15 Wetter weewx[3751]: engine: Using Python 2.7.16 (default, Oct 10 2019, 22:02:15) #012[GCC 8.3.0]
Jul 16 17:05:15 Wetter weewx[3751]: engine: Platform Linux-5.4.72-v7+-armv7l-with-debian-10.6
Jul 16 17:05:15 Wetter weewx[3751]: engine: Locale is 'de_CH.UTF-8'
Jul 16 17:05:15 Wetter weewx[3751]: engine: pid file is /var/run/weewx.pid
Jul 16 17:05:15 Wetter weewx[3677]: Starting weewx weather system: weewx.
Jul 16 17:05:15 Wetter systemd[1]: Started LSB: weewx weather system.
Jul 16 17:05:15 Wetter weewx[3755]: engine: Using configuration file /etc/weewx/weewx.conf
Jul 16 17:05:15 Wetter weewx[3755]: engine: Debug is 1
Jul 16 17:05:15 Wetter weewx[3755]: engine: Initializing engine
Jul 16 17:05:15 Wetter weewx[3755]: engine: Loading station type Vantage (weewx.drivers.vantage)
Jul 16 17:05:15 Wetter weewx[3755]: vantage: Driver version is 3.1.1
Jul 16 17:05:15 Wetter weewx[3755]: vantage: Opened up serial port /dev/ttyUSB0; baud 19200; timeout 4.00
Jul 16 17:05:15 Wetter weewx[3755]: vantage: Gentle wake up of console successful
Jul 16 17:05:15 Wetter weewx[3755]: vantage: Hardware type is 16
Jul 16 17:05:15 Wetter weewx[3755]: vantage: ISS ID is 1
Jul 16 17:05:15 Wetter weewx[3755]: vantage: Hardware name: Vantage Pro2
Jul 16 17:05:15 Wetter weewx[3755]: engine: Loading service weewx.engine.StdTimeSynch
Jul 16 17:05:15 Wetter weewx[3755]: engine: Finished loading service weewx.engine.StdTimeSynch
Jul 16 17:05:15 Wetter weewx[3755]: engine: Loading service user.cputemp.AddCpuTemp
Jul 16 17:05:15 Wetter weewx[3755]: engine: Finished loading service user.cputemp.AddCpuTemp
Jul 16 17:05:15 Wetter weewx[3755]: engine: Loading service weewx.engine.StdConvert
Jul 16 17:05:15 Wetter weewx[3755]: engine: StdConvert target unit is 0x1
Jul 16 17:05:15 Wetter weewx[3755]: engine: Finished loading service weewx.engine.StdConvert
Jul 16 17:05:15 Wetter weewx[3755]: engine: Loading service weewx.engine.StdCalibrate
Jul 16 17:05:15 Wetter weewx[3755]: engine: Finished loading service weewx.engine.StdCalibrate
Jul 16 17:05:15 Wetter weewx[3755]: engine: Loading service weewx.engine.StdQC
Jul 16 17:05:15 Wetter weewx[3755]: engine: Finished loading service weewx.engine.StdQC
Jul 16 17:05:15 Wetter weewx[3755]: engine: Loading service weewx.wxservices.StdWXCalculate
Jul 16 17:05:15 Wetter weewx[3755]: wxcalculate: The following values will be calculated: barometer=prefer_hardware, windchill=prefer_hardware, dewpoint=prefer_hardware, appTemp=prefer_hardware, rainRate=prefer_hardware, windrun=prefer_hardware, heatindex=prefer_hardware, maxSolarRad=prefer_hardware, humidex=prefer_hardware, pressure=prefer_hardware, inDewpoint=prefer_hardware, ET=prefer_hardware, altimeter=prefer_hardware, cloudbase=prefer_hardware
Jul 16 17:05:15 Wetter weewx[3755]: wxcalculate: The following algorithms will be used for calculations: altimeter=aaNOAA, maxSolarRad=RS
Jul 16 17:05:15 Wetter weewx[3755]: engine: Finished loading service weewx.wxservices.StdWXCalculate
Jul 16 17:05:15 Wetter weewx[3755]: engine: Loading service user.radiationhours.RadiationHours
Jul 16 17:05:15 Wetter weewx[3755]: engine: Caught unrecoverable exception in engine:
Jul 16 17:05:15 Wetter weewx[3755]:     ****  Module 'user.radiationhours' has no attribute 'RadiationHours' when searching for 'user.radiationhours.RadiationHours'
Jul 16 17:05:15 Wetter weewx[3755]:     ****  Traceback (most recent call last):
Jul 16 17:05:15 Wetter weewx[3755]:     ****    File "/usr/share/weewx/weewx/engine.py", line 888, in main
Jul 16 17:05:15 Wetter weewx[3755]:     ****      engine = engine_class(config_dict)
Jul 16 17:05:15 Wetter weewx[3755]:     ****    File "/usr/share/weewx/weewx/engine.py", line 78, in __init__
Jul 16 17:05:15 Wetter weewx[3755]:     ****      self.loadServices(config_dict)
Jul 16 17:05:15 Wetter weewx[3755]:     ****    File "/usr/share/weewx/weewx/engine.py", line 142, in loadServices
Jul 16 17:05:15 Wetter weewx[3755]:     ****      self.service_obj.append(weeutil.weeutil._get_object(svc)(self, config_dict))
Jul 16 17:05:15 Wetter weewx[3755]:     ****    File "/usr/share/weewx/weeutil/weeutil.py", line 1116, in _get_object
Jul 16 17:05:15 Wetter weewx[3755]:     ****      "Module '%s' has no attribute '%s' when searching for '%s'" % (mod.__name__, part, module_class))
Jul 16 17:05:15 Wetter weewx[3755]:     ****  AttributeError: Module 'user.radiationhours' has no attribute 'RadiationHours' when searching for 'user.radiationhours.RadiationHours'
Jul 16 17:05:15 Wetter weewx[3755]:     ****  Exiting.

Can you Help me?

Many Thanks

Jacques Terrettaz

unread,
Jul 16, 2022, 11:34:07 AM7/16/22
to weewx...@googlegroups.com
Peter,

Don't forget the fact that if for any reason Weewx is stopped, it will, during restart, read from the datalogger memory any "missed" archive packets that were not captured during the interruption period.  In that case, no loop data are available for these archive records, and you have to add code in your  newArchiveRecord() function to calculate, over the archive interval, the sunshine duration on the basis of the archive radiation value. Otherwise, the sunshine duration of these imported records will be always 0!

Even if Weewx interruption is short enough so that there is no missed records to import from the datalogger memory, the LOOP packets received after startup will not cover the full period of  the first archive record captured , and sunshine duration calculated from the LOOP data will be underestimated. In my code, I detect also this situation and the sunshine duration of the first captured archive record  will be also calculated from the archive radiation value over the archive interval.


Le 16 juil. 2022 à 17:01, 'Peter Fletcher' via weewx-user <weewx...@googlegroups.com> a écrit :

The code I am using is pasted below. The main threshold calculation is a copy of the original Meto-France code used by Jacques, but the calculation is only done when the radiation value changes or (approximately) every minute, if it has not changed. Also included is code to store Davis’s ‘Storm Rain’ value in the archive database. The stored value for sunshine time has more apparent precision than is given by Jacques's code, but it is probably neither more nor less accurate, since its accuracy is limited by the relatively slow 'response' of the Davis sensor.


-- 
You received this message because you are subscribed to a topic in the Google Groups "weewx-user" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/weewx-user/19ylVTRqbh4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to weewx-user+...@googlegroups.com.

Peter Fletcher

unread,
Jul 16, 2022, 11:35:20 AM7/16/22
to weewx-user
I don't know whose code you are using - neither of us uses 'radiationhours' (with any capitalization) as a module or variable name. It looks, however, as if you have not defined a parameter correctly in the code in radiationhours.py in the user subdirectory, which you have loaded as a weewx service.

Peter Fletcher

unread,
Jul 16, 2022, 12:34:56 PM7/16/22
to weewx-user
My apparently ignoring the situations you highlight was a decision, rather than an omission! I run weewx on my 'workhorse' Pi, which is (at least by intention) up 24/7/365. I do reboot it occasionally after updates, but otherwise there should be no interruptions. The way I do the calculations for the archive values automatically corrects for 'short' archive intervals, and I would handle longer interruptions (if there were any) by running my update code on the database after the interruption.

Jacques Terrettaz

unread,
Jul 16, 2022, 2:45:16 PM7/16/22
to weewx...@googlegroups.com
You are right! 

I added the rounding to the nearest minute because I was surprised that from time to time, I had a sunshine duration slightly higher that the archive interval, due probably to the delay needed by weewx to process the archive records. Initially, I thought it was not logical  to have a sunshine duration higher than the nominal archive interval, but it is not... In that situation, the additional few seconds in excess attributed to one archive records will imply that the next record will have have its sunshine duration diminished by the same amount.

The important point is to have the best estimation of the sunshine duration for each day,  so I removed the rounding in my code.

Jacques Terrettaz

unread,
Jul 17, 2022, 5:12:51 AM7/17/22
to weewx...@googlegroups.com
Hello,

If you share with us the code of your radiationhours.py script; it would be more easy to help you. 

-- 
You received this message because you are subscribed to a topic in the Google Groups "weewx-user" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/weewx-user/19ylVTRqbh4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to weewx-user+...@googlegroups.com.

Jon B

unread,
Jul 18, 2022, 9:43:43 AM7/18/22
to weewx-user
Sorry for piggybacking on this conversation, but it seemed like an appropriate place to ask this.

I'm trying to install the sunshine duration extension (https://github.com/Jterrettaz/sunduration) but I'm getting an error when trying to create the new database. I've followed the installation instructions as follows:

- Saved sunduration.py to /usr/share/weewx/user/
- Added user.sunduration.SunshineDuration to the process_services list
- Changed the wx_binding schema to user.sunduration.schema_with_sunshine_time
- Stopped weewx and ran wee_database weewx.conf --reconfigure

This gives the following error:

Using configuration file weewx.conf
Using database binding 'wx_binding', which is bound to database 'archive_sqlite'

Traceback (most recent call last):
  File "/usr/share/weewx/weeutil/weeutil.py", line 1155, in get_object
    mod = getattr(mod, part)
AttributeError: module 'user.sunduration' has no attribute 'schema_with_sunshine_time'

During handling of the above exception, another exception occurred:


Traceback (most recent call last):
  File "/usr/share/weewx/wee_database", line 1170, in <module>
    main()
  File "/usr/share/weewx/wee_database", line 216, in main
    reconfigMainDatabase(config_dict, db_binding)
  File "/usr/share/weewx/wee_database", line 439, in reconfigMainDatabase
    manager_dict = weewx.manager.get_manager_dict_from_config(config_dict,
  File "/usr/share/weewx/weewx/manager.py", line 727, in get_manager_dict_from_config
    manager_dict['schema'] = weeutil.weeutil.get_object(schema_name)
  File "/usr/share/weewx/weeutil/weeutil.py", line 1158, in get_object
    raise AttributeError(
AttributeError: Module 'user.sunduration' has no attribute 'schema_with_sunshine_time' when searching for 'user.sunduration.schema_with_sunshine_time'

Jacques Terrettaz

unread,
Jul 18, 2022, 9:59:20 AM7/18/22
to weewx...@googlegroups.com
Hi,

Please verify that the last line of the sunduration.py script is

  schema_with_sunshine_time = schemas.wview.schema + [('sunshine_time', 'REAL')]


--
You received this message because you are subscribed to a topic in the Google Groups "weewx-user" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/weewx-user/19ylVTRqbh4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to weewx-user+...@googlegroups.com.

Peter Fletcher

unread,
Jul 18, 2022, 10:29:43 AM7/18/22
to weewx-user
@Jacques: I initially had the same error (or a very similar one) as Jon B and had to comment out that last line. I had already manually added the sunshine_time field (as well as some others, previously) to my weewx database, so it didn't seem to be necessary or useful. My installation also did not seem to understand the schema assignment. Do you have a non-default extension loaded that enables this?

Jacques Terrettaz

unread,
Jul 18, 2022, 10:30:26 AM7/18/22
to weewx...@googlegroups.com
I looked at the code in my GitHub, and it appeared that the last line 

schema_with_sunshine_time = schemas.wview.schema + [('sunshine_time', 'REAL')]

had a wrong indentation.

This is corrected now.   Sorry !

Le 18 juil. 2022 à 15:43, Jon B <jonbe...@gmail.com> a écrit :

Jacques Terrettaz

unread,
Jul 18, 2022, 10:35:03 AM7/18/22
to weewx...@googlegroups.com
@Peter : if one want to update the database using wee_database, the new updated schema with the new field is needed.  Otherwise, in case of a manual update of the database structure, the new schema is not needed.

Le 18 juil. 2022 à 16:29, 'Peter Fletcher' via weewx-user <weewx...@googlegroups.com> a écrit :

@Jacques: I initially had the same error (or a very similar one) as Jon B and had to comment out that last line. I had already manually added the sunshine_time field (as well as some others, previously) to my weewx database, so it didn't seem to be necessary or useful. My installation also did not seem to understand the schema assignment. Do you have a non-default extension loaded that enables this?


You received this message because you are subscribed to a topic in the Google Groups "weewx-user" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/weewx-user/19ylVTRqbh4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to weewx-user+...@googlegroups.com.

Peter Fletcher

unread,
Jul 18, 2022, 3:43:22 PM7/18/22
to weewx-user
I have never explicitly used the schema management system, but my understanding is that it is only relevant if you want to create a whole new blank database using wee_database --create or --reconfigure. You don't appear to need it if you use other wee_database options to (e.g.) add, drop, or rename columns.

Jacques Terrettaz

unread,
Jul 18, 2022, 4:12:11 PM7/18/22
to weewx...@googlegroups.com
According to the weewx documentation :

Action --reconfigure

This action is useful for changing the schema or unit system in your database.

It creates a new database with the same name as the old, except with the suffix _new attached at the end (nominally, weewx.sdb_new if you are using SQLite, weewx_new if you are using MySQL). It then initializes it with the schema specified in weewx.conf. Finally, it copies over the data from your old database into the new database.


I followed several years ago this method to add new fields in my weewx database, and it works perfectly. 

That said,I checked the documentation andI agree that the wee_database --add-column (this option was not available before February 2021...) will do the same, without having to rename the database.

I will verify and if OK update the procedure described in my Github.

Thanks



--
You received this message because you are subscribed to a topic in the Google Groups "weewx-user" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/weewx-user/19ylVTRqbh4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to weewx-user+...@googlegroups.com.

Jon B

unread,
Jul 22, 2022, 5:48:10 AM7/22/22
to weewx-user
Thanks for the fix! It's working now for me.

A couple of other questions about this:

- How can I change it so that the units are hours, rather than minutes?
- How can I add a total daily sunshine duration field, rather than displaying the total sunshine within the last archive period?

Thanks!

Jacques Terrettaz

unread,
Jul 22, 2022, 7:34:08 AM7/22/22
to weewx...@googlegroups.com
@Jon B 

If you are retrieving the values using weewx tags, you can have the daily total sunshine duration, in hours with the following tag : $day.sunshine_time.sum.hour

You can do the same with different aggregation periods , for instance :
$yesterday.sunshine_time.sum.hour
$week.sunshine_time.sum.hour
$month.sunshine_time.sum.hour
$year.sunshine_time.sum.hour
$alltime.sunshine_time.sum.hour




Jon B

unread,
Jul 22, 2022, 10:35:09 AM7/22/22
to weewx-user
Thanks. I'm using the Belchertown skin so I think things may be set up slightly differently. Within this skin, a new observation type is defined for rain (rainTotal), which aggregates the total rain across the observation period. I've defined an equivalent for sunshine time, which I've called "sunshineTotal" so I now have the total number of minutes of sun for a given day/month etc. According to the documentation for that skin I should just be able to define the "unit" within the graphs.conf file, but adding "unit = hour" doesn't seem to make any difference. Perhaps this is something I need to ask on the Belchertown github page...

Jacques Terrettaz

unread,
Jul 22, 2022, 12:12:35 PM7/22/22
to weewx...@googlegroups.com
Did you try to add group_interval = hour   in  the [[Defaults]] [[[Units]]] [[[[Groups]]]] section of weewx.conf ?

Jon B

unread,
Jul 22, 2022, 12:45:46 PM7/22/22
to weewx-user
I didn't and that's done the trick, thanks!
Message has been deleted

Meteo Oberwallis

unread,
Jul 31, 2022, 12:49:00 AM7/31/22
to weewx-user
Hello.
I have a Problem, wenn weewx stop an ih restart, can not read the Datalogger from Update to weewx. I have this for logging the sunshine time -> https://github.com/Jterrettaz/sunduration/blob/master/sunduration.py
I have the Version weewx 4.8.0

Jul 31 06:31:03 Wetter systemd[1]: Started LSB: weewx weather system.
Jul 31 06:31:07 Wetter weewx[5077] DEBUG weewx.drivers.vantage: Retry #0 failed
Jul 31 06:31:09 Wetter weewx[5077] DEBUG weewx.drivers.vantage: Gentle wake up of console successful
Jul 31 06:31:09 Wetter weewx[5077] DEBUG weewx.drivers.vantage: Hardware type is 16
Jul 31 06:31:09 Wetter weewx[5077] DEBUG weewx.drivers.vantage: ISS ID is 1
Jul 31 06:31:09 Wetter weewx[5077] DEBUG weewx.drivers.vantage: Hardware name: Vantage Pro2
Jul 31 06:31:09 Wetter weewx[5077] DEBUG weewx.engine: Loading service weewx.engine.StdTimeSynch
Jul 31 06:31:09 Wetter weewx[5077] DEBUG weewx.engine: Finished loading service weewx.engine.StdTimeSynch
Jul 31 06:31:09 Wetter weewx[5077] DEBUG weewx.engine: Loading service user.cputemp.AddCpuTemp
Jul 31 06:31:09 Wetter weewx[5077] DEBUG weewx.engine: Finished loading service user.cputemp.AddCpuTemp
Jul 31 06:31:09 Wetter weewx[5077] DEBUG weewx.engine: Loading service user.sunduration.SunshineDuration
Jul 31 06:31:09 Wetter weewx[5077] DEBUG weewx.engine: Finished loading service user.sunduration.SunshineDuration
Jul 31 06:31:09 Wetter weewx[5077] DEBUG weewx.engine: Loading service weewx.engine.StdConvert
Jul 31 06:31:09 Wetter weewx[5077] INFO weewx.engine: StdConvert target unit is 0x1
Jul 31 06:31:09 Wetter weewx[5077] DEBUG weewx.engine: Finished loading service weewx.engine.StdConvert
Jul 31 06:31:09 Wetter weewx[5077] DEBUG weewx.engine: Loading service weewx.engine.StdCalibrate
Jul 31 06:31:09 Wetter weewx[5077] DEBUG weewx.engine: Finished loading service weewx.engine.StdCalibrate
Jul 31 06:31:09 Wetter weewx[5077] DEBUG weewx.engine: Loading service weewx.engine.StdQC
Jul 31 06:31:09 Wetter weewx[5077] DEBUG weewx.engine: Finished loading service weewx.engine.StdQC
Jul 31 06:31:09 Wetter weewx[5077] DEBUG weewx.engine: Loading service weewx.wxservices.StdWXCalculate
Jul 31 06:31:09 Wetter weewx[5077] INFO weewx.wxservices: StdWXCalculate will use data binding wx_binding
Jul 31 06:31:09 Wetter weewx[5077] DEBUG weewx.manager: Daily summary version is 4.0
Jul 31 06:31:09 Wetter weewx[5077] DEBUG weewx.engine: Finished loading service weewx.wxservices.StdWXCalculate
Jul 31 06:31:09 Wetter weewx[5077] DEBUG weewx.engine: Loading service weewx.wxxtypes.StdWXXTypes
Jul 31 06:31:09 Wetter weewx[5077] DEBUG weewx.engine: Finished loading service weewx.wxxtypes.StdWXXTypes
Jul 31 06:31:09 Wetter weewx[5077] DEBUG weewx.engine: Loading service weewx.wxxtypes.StdPressureCooker
Jul 31 06:31:09 Wetter weewx[5077] DEBUG weewx.engine: Finished loading service weewx.wxxtypes.StdPressureCooker
Jul 31 06:31:09 Wetter weewx[5077] DEBUG weewx.engine: Loading service weewx.wxxtypes.StdRainRater
Jul 31 06:31:09 Wetter weewx[5077] DEBUG weewx.engine: Finished loading service weewx.wxxtypes.StdRainRater
Jul 31 06:31:09 Wetter weewx[5077] DEBUG weewx.engine: Loading service weewx.wxxtypes.StdDelta
Jul 31 06:31:09 Wetter weewx[5077] DEBUG weewx.engine: Finished loading service weewx.wxxtypes.StdDelta
Jul 31 06:31:09 Wetter weewx[5077] DEBUG weewx.engine: Loading service weewx.engine.StdArchive
Jul 31 06:31:09 Wetter weewx[5077] INFO weewx.engine: Archive will use data binding wx_binding
Jul 31 06:31:09 Wetter weewx[5077] INFO weewx.engine: Record generation will be attempted in 'hardware'
Jul 31 06:31:09 Wetter weewx[5077] ERROR weewx.engine: The archive interval in the configuration file (300) does not match the station hardware interval (600).
Jul 31 06:31:09 Wetter weewx[5077] INFO weewx.engine: Using archive interval of 600 seconds (specified by hardware)
Jul 31 06:31:09 Wetter weewx[5077] DEBUG weewx.engine: Use LOOP data in hi/low calculations: 1
Jul 31 06:31:09 Wetter weewx[5077] DEBUG weewx.engine: Finished loading service weewx.engine.StdArchive
Jul 31 06:31:09 Wetter weewx[5077] DEBUG weewx.engine: Loading service weewx.restx.StdStationRegistry
Jul 31 06:31:09 Wetter weewx[5077] INFO weewx.restx: StationRegistry: Registration not requested.
Jul 31 06:31:09 Wetter weewx[5077] DEBUG weewx.engine: Finished loading service weewx.restx.StdStationRegistry
Jul 31 06:31:09 Wetter weewx[5077] DEBUG weewx.engine: Loading service weewx.restx.StdWunderground
Jul 31 06:31:09 Wetter weewx[5077] INFO weewx.restx: Wunderground: Posting not enabled.
Jul 31 06:31:09 Wetter weewx[5077] DEBUG weewx.engine: Finished loading service weewx.restx.StdWunderground
Jul 31 06:31:09 Wetter weewx[5077] DEBUG weewx.engine: Loading service weewx.restx.StdPWSweather
Jul 31 06:31:09 Wetter weewx[5077] INFO weewx.restx: PWSweather: Posting not enabled.
Jul 31 06:31:09 Wetter weewx[5077] DEBUG weewx.engine: Finished loading service weewx.restx.StdPWSweather
Jul 31 06:31:09 Wetter weewx[5077] DEBUG weewx.engine: Loading service weewx.restx.StdCWOP
Jul 31 06:31:09 Wetter weewx[5077] INFO weewx.restx: CWOP: Posting not enabled.
Jul 31 06:31:09 Wetter weewx[5077] DEBUG weewx.engine: Finished loading service weewx.restx.StdCWOP
Jul 31 06:31:09 Wetter weewx[5077] DEBUG weewx.engine: Loading service weewx.restx.StdWOW
Jul 31 06:31:09 Wetter weewx[5077] INFO weewx.restx: WOW: Posting not enabled.
Jul 31 06:31:09 Wetter weewx[5077] DEBUG weewx.engine: Finished loading service weewx.restx.StdWOW
Jul 31 06:31:09 Wetter weewx[5077] DEBUG weewx.engine: Loading service weewx.restx.StdAWEKAS
Jul 31 06:31:09 Wetter weewx[5077] INFO weewx.restx: AWEKAS: Posting not enabled.
Jul 31 06:31:09 Wetter weewx[5077] DEBUG weewx.engine: Finished loading service weewx.restx.StdAWEKAS
Jul 31 06:31:09 Wetter weewx[5077] DEBUG weewx.engine: Loading service user.mqtt.MQTT
Jul 31 06:31:09 Wetter weewxd: restx: MQTT: service version is 0.19
Jul 31 06:31:09 Wetter weewxd: restx: MQTT: binding to [u'archive', u'loop']
Jul 31 06:31:09 Wetter weewxd: restx: MQTT: topic is weather/mittelallalin
Jul 31 06:31:09 Wetter weewxd: restx: MQTT: desired unit system is METRIC
Jul 31 06:31:09 Wetter weewxd: restx: MQTT: data will be uploaded to mqtt://mosquitto:xxx@
Jul 31 06:31:09 Wetter weewx[5077] DEBUG weewx.engine: Finished loading service user.mqtt.MQTT
Jul 31 06:31:09 Wetter weewx[5077] DEBUG weewx.engine: Loading service weewx.engine.StdPrint
Jul 31 06:31:09 Wetter weewx[5077] DEBUG weewx.engine: Finished loading service weewx.engine.StdPrint
Jul 31 06:31:09 Wetter weewx[5077] DEBUG weewx.engine: Loading service weewx.engine.StdReport
Jul 31 06:31:09 Wetter weewx[5077] INFO weewx.engine: 'pyephem' not detected, extended almanac data is not available
Jul 31 06:31:09 Wetter weewx[5077] DEBUG weewx.engine: Finished loading service weewx.engine.StdReport
Jul 31 06:31:09 Wetter weewx[5077] INFO __main__: Starting up weewx version 4.8.0
Jul 31 06:31:09 Wetter weewx[5077] DEBUG weewx.drivers.vantage: Gentle wake up of console successful
Jul 31 06:31:09 Wetter weewx[5077] INFO weewx.engine: Clock error is 4.42 seconds (positive is fast)
Jul 31 06:31:09 Wetter weewx[5077] INFO weewx.engine: Using binding 'wx_binding' to database 'weewx.sdb_new'
Jul 31 06:31:09 Wetter weewx[5077] INFO weewx.manager: Starting backfill of daily summaries
Jul 31 06:31:09 Wetter weewx[5077] INFO weewx.manager: Daily summaries up to date
Jul 31 06:31:09 Wetter weewx[5077] DEBUG weewx.drivers.vantage: Getting archive packets since 2022-07-30 16:40:00 CEST (1659192000)
Jul 31 06:31:09 Wetter weewx[5077] DEBUG weewx.manager: Daily summary version is 4.0
Jul 31 06:31:09 Wetter weewx[5077] DEBUG weewx.drivers.vantage: Gentle wake up of console successful
Jul 31 06:31:09 Wetter weewx[5077] DEBUG weewx.drivers.vantage: Retrieving 18 page(s); starting index= 3
Jul 31 06:31:09 Wetter weewx[5077] INFO weewx.engine: Main loop exiting. Shutting engine down.
Jul 31 06:31:09 Wetter weewx[5077] DEBUG weewx.restx: Shut down MQTT thread.
Jul 31 06:31:09 Wetter weewx[5077] CRITICAL __main__: Caught unrecoverable exception:
Jul 31 06:31:09 Wetter weewx[5077] CRITICAL __main__:     ****  'radiation'
Jul 31 06:31:09 Wetter weewx[5077] CRITICAL __main__:     ****  Traceback (most recent call last):
Jul 31 06:31:09 Wetter weewx[5077] CRITICAL __main__:     ****    File "/usr/share/weewx/weewxd", line 153, in main
Jul 31 06:31:09 Wetter weewx[5077] CRITICAL __main__:     ****      engine.run()
Jul 31 06:31:09 Wetter weewx[5077] CRITICAL __main__:     ****    File "/usr/share/weewx/weewx/engine.py", line 178, in run
Jul 31 06:31:09 Wetter weewx[5077] CRITICAL __main__:     ****      self.dispatchEvent(weewx.Event(weewx.STARTUP))
Jul 31 06:31:09 Wetter weewx[5077] CRITICAL __main__:     ****    File "/usr/share/weewx/weewx/engine.py", line 245, in dispatchEvent
Jul 31 06:31:09 Wetter weewx[5077] CRITICAL __main__:     ****      callback(event)
Jul 31 06:31:09 Wetter weewx[5077] CRITICAL __main__:     ****    File "/usr/share/weewx/weewx/engine.py", line 584, in startup
Jul 31 06:31:09 Wetter weewx[5077] CRITICAL __main__:     ****      self._catchup(self.engine.console.genStartupRecords)
Jul 31 06:31:09 Wetter weewx[5077] CRITICAL __main__:     ****    File "/usr/share/weewx/weewx/engine.py", line 702, in _catchup
Jul 31 06:31:09 Wetter weewx[5077] CRITICAL __main__:     ****      origin='hardware'))
Jul 31 06:31:09 Wetter weewx[5077] CRITICAL __main__:     ****    File "/usr/share/weewx/weewx/engine.py", line 245, in dispatchEvent
Jul 31 06:31:09 Wetter weewx[5077] CRITICAL __main__:     ****      callback(event)
Jul 31 06:31:09 Wetter weewx[5077] CRITICAL __main__:     ****    File "/usr/share/weewx/user/sunduration.py", line 92, in newArchiveRecord
Jul 31 06:31:09 Wetter weewx[5077] CRITICAL __main__:     ****      event.record['sunshine_hours'], event.record['radiation'], self.lastSeuil))
Jul 31 06:31:09 Wetter weewx[5077] CRITICAL __main__:     ****  KeyError: 'radiation'
Jul 31 06:31:09 Wetter weewx[5077] CRITICAL __main__:     ****  Exiting.

Can i Help me?
Thanks

Jacques Terrettaz

unread,
Jul 31, 2022, 2:16:44 AM7/31/22
to weewx...@googlegroups.com
Hello,

It seems that radiation values are missing for some archive records.   Line 92 of sunduration.py had a wrong indentation.  This is now corrected in my Github repository.

Le 31 juil. 2022 à 06:45, Meteo Oberwallis <sschn...@bluewin.ch> a écrit :

Hello. 
Jul 31 06:31:09 Wetter weewxd: restx: MQTT: data will be uploaded to mqtt://mosquitto:xxx@185.160.244.35:1883/

Meteo Oberwallis

unread,
Aug 6, 2022, 3:01:04 PM8/6/22
to weewx-user
Hello
Thx for Help. I have the new Code in my sunduration.py and i have this fault:

Aug  6 20:59:46 Wetter weewx[11829] DEBUG weewx.engine: Loading service user.sunduration.SunshineDuration
Aug  6 20:59:46 Wetter weewx[11829] CRITICAL __main__: Caught unrecoverable exception:
Aug  6 20:59:46 Wetter weewx[11829] CRITICAL __main__:     ****  invalid syntax (sunduration.py, line 101)
Aug  6 20:59:46 Wetter weewx[11829] CRITICAL __main__:     ****  Traceback (most recent call last):
Aug  6 20:59:46 Wetter weewx[11829] CRITICAL __main__:     ****    File "/usr/share/weewx/weewxd", line 147, in main
Aug  6 20:59:46 Wetter weewx[11829] CRITICAL __main__:     ****      engine = weewx.engine.StdEngine(config_dict)
Aug  6 20:59:46 Wetter weewx[11829] CRITICAL __main__:     ****    File "/usr/share/weewx/weewx/engine.py", line 93, in __init__
Aug  6 20:59:46 Wetter weewx[11829] CRITICAL __main__:     ****      self.loadServices(config_dict)
Aug  6 20:59:46 Wetter weewx[11829] CRITICAL __main__:     ****    File "/usr/share/weewx/weewx/engine.py", line 161, in loadServices
Aug  6 20:59:46 Wetter weewx[11829] CRITICAL __main__:     ****      obj = weeutil.weeutil.get_object(svc)(self, config_dict)
Aug  6 20:59:46 Wetter weewx[11829] CRITICAL __main__:     ****    File "/usr/share/weewx/weeutil/weeutil.py", line 1150, in get_object
Aug  6 20:59:46 Wetter weewx[11829] CRITICAL __main__:     ****      mod = __import__(module)
Aug  6 20:59:46 Wetter weewx[11829] CRITICAL __main__:     ****    File "/usr/share/weewx/user/sunduration.py", line 101
Aug  6 20:59:46 Wetter weewx[11829] CRITICAL __main__:     ****      self.sunshineSeconds = 0
Aug  6 20:59:46 Wetter weewx[11829] CRITICAL __main__:     ****         ^
Aug  6 20:59:46 Wetter weewx[11829] CRITICAL __main__:     ****  SyntaxError: invalid syntax
Aug  6 20:59:46 Wetter weewx[11829] CRITICAL __main__:     ****  Exiting.

Jacques Terrettaz

unread,
Aug 7, 2022, 1:29:25 AM8/7/22
to weewx...@googlegroups.com
Hello,

Please double check the line before line 101 - missing parenthesis or something like that.

Reply all
Reply to author
Forward
0 new messages