Sunshine Duration

[Karen K]

I bought a sunshine duration sensor from Weerhuisje. When integrating it in WeeWX I wondered how to call the observation type. There is nothing appropriate in the standard schema. I found 2 extensions regarding sunshine duration. One of them calls the observation type "sunshine_hours", the other one "sunshine_time". 

I would guess it is not generally a good idea to include an underscore in the observation type name, as the underscore is used to separate the unit from the observation type in the widely used MQTT extension.

And I guess it would be better to have the same name irrespective of the data source, which extension or hardware is used.

Another thing is the unit group. I would allocate the sunshine duration to group_deltatime, as the output would be something like "8 hours, 45 minutes, 10 seconds" or so. group_interval would be less appropriate, as sunshine duration is not exactly an interval but rather a time period.

After all I am not sure.

[an oldman]

I'm doing some thing like that from lux reading and using 'group_elapsed' for the unit and obs name measuredlight.

[Tom Keffer]

You definitely don't want sunshine_hours (or sunshineHours) because that implies a unit. I would suggest "daylight".

As for which unit group, the almanac uses group_deltatime for length of day. It's normally measured in seconds.

--
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/e8adff2f-8552-4c1e-8cdd-74d2c15dd514n%40googlegroups.com.

[Karen K]

Thank you very much for your comments.

That is the sensor kit. The sensor itself is the part in the middle of the wire coil.

[Meteo Oberwallis]

Hello.

I have a problem. I'm using https://github.com/Jterrettaz/sunduration and that works so far. I can also set the value via $current.sunshine_time and then get 5.0 minutes. However, the whole thing doesn't work for the daytime sunshine time with $day.sunshine_time. I built this for my XML file. This looks like this:

<solar>

<solar value="$current.radiation.formatted"/>

<solar_max value="$day.radiation.max.formatted"/>

<solar_max_time value="$day.radiation.maxtime.format("%H:%M")""/>

<sun_last value="$current.sunshine_time"/>

<sun_last value="$day.sunshine_time"/>

</solar>

Now I get an error that the day.sunshine_time cannot be read. Anyone have an idea why?

Thanks very much

tke...@gmail.com schrieb am Donnerstag, 24. März 2022 um 22:15:05 UTC+1:

[Karen K]

You need sunshine_time in your database. Is it there? If not, you may want to use the wee_database tool to insert it.

[Schnidrig Stefan]

Hey.

Yes. Is in the weewx.sdb. The current sunshine time works. The day sunshine time not. 

Holen Sie sich Outlook für Android

[Karen K]

Now I see it: There is "sum" missing at the end:

$day.sunshine_time.sum

[Ton vanN]

Looking for a 'proven' calculation for sunshineduration as element of WeeWX, see https://github.com/Jterrettaz/sunduration
Shown solution linked to Davis Vantage_Pro.
Different sensors may induce difference in results:
any experiences if linked to Weatherflow_Tempest?

Op zaterdag 26 maart 2022 om 19:41:50 UTC+1 schreef Karen K:

[Werner Krenn]

see my extension sunrainduration.py on 

https://github.com/WernerKr/weewx-weatherlinkliveudp/tree/master/bin/user

Supports rain_duration too (and for two stations like Davis VantagePro and Davis VUE) 

Based on Jterrettaz extension 

[jterr...@gmail.com]

Yes, different sensors will induce difference in results. 

The formula used in my extension has been validated for the Davis radiation sensor with the following specifications : https://cdn.shopify.com/s/files/1/0515/5992/3873/files/6450_SS.pdf

As far as I know, the Weatherflow Tempest has a light sensor that measure illuminance (in lux)  and not irradiance ( in W/m2).  

Even if one can find various formulas to attempt to convert illuminance measurement ( in lux) to irradiance values(in W/m2) - see for exemple https://www.researchgate.net/publication/347362859_A_conversion_guide_solar_irradiance_and_lux_illuminance - the formula of the sunduration extension will have to be modified , if possible, to support illuminance measurements

[n7uv...@gmail.com]

When I hear "sunshine duration", I'm not sure whether that means the duration that the scary fiery (I live in PHX %^) ball of plasma is at and above the horizon (which is already provided under the Celestial tab) 

or something about the total energy delivered to a square meter of the ground over the period of a day. 

If it's the latter, then I'm interested in that. Cumulative watt-hours per sq meter means that I can a priori have a good model of how much energy I can get from a solar panel (yeah, cosines and panel efficiency). My Davis wx station reports radiation in w/m^2, there's a report every minute, so, if that's watts x 1 minute gives me watt minutes. Add up the 60 reports in the hour and divide by 60 to get me cumulative watt-hours for that hour. Ideally I'd have a graph of w-hr for each hour, and a sum that is watt-hours cumulative for the day. 

I have access to an 8760 model tool, and it'd be interesting to compare how well the model fits my real world. My location is is on the west side of a ridge that blocks from the sun until it's around 20 degrees above eastern horizon (winter solstice) and 34 degrees (summer solstice). I think i could get the tool to model a horizon like mine, but haven't played with it.

Cheers - Jon N7UV

[Jacques Terrettaz]

The "sunduration" extension is calculating the total time in a day when there is no clouds between the sun and the Davis radiation sensor.  With clouds, the incoming radiation energy is much lower. 

The formula used in this extension calculates a threshold radiation value that depends on the date, time and geographic location (latitude and longitude) of the sensor. For each measurement (i.e. each LOOP) if the value reported  by the radiation sensor is higher than the threshold value, it is considered that at this time the sun is shining ( no clouds)  .

So for each day the "sunshine duration" could be between  a minimum value of 0 if  the weather of the day was 100% cloudy  up to a maximal value corresponding to the total daylight if the sky was 100% clear and with no obstacle (ridge, tree )

Le 2 mai 2024 à 01:01, n7uv...@gmail.com <n7uv...@gmail.com> a écrit :

When I hear "sunshine duration", I'm not sure whether that means the duration that the scary fiery (I live in PHX %^) ball of plasma is at and above the horizon (which is already provided under the Celestial tab) 

-- 
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/JUd55LCTtDE/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/e2d9a876-6bb7-435f-9ead-bc6c359801c2n%40googlegroups.com.
<Screenshot 2024-05-01 155959.png>

[jterr...@gmail.com]

Jon,

If you are interested at  the theoretical maximum solar radiation, Weewx provides this value : MaxSolarRad   . See https://weewx.com/docs/5.0/reference/weewx-options/stdwxcalculate/#maxsolarrad 

[Karen K]

n7uv...@gmail.com schrieb am Donnerstag, 2. Mai 2024 um 01:01:52 UTC+2:

When I hear "sunshine duration", I'm not sure whether that means the duration that the scary fiery (I live in PHX %^) ball of plasma is at and above the horizon (which is already provided under the Celestial tab) 

or something about the total energy delivered to a square meter of the ground over the period of a day. 

Sunshine duration means the time the sun is really seen in the sky and typically casts a shadow. The standard instrument to measure sunshine duration is the Campbell-Stokes sunshine recorder. 

Sunshine duration is not total daylight time.

If a cloud is situated before the sun, this is considered no sunshine. If clouds are elsewhere in the sky it does not matter.

[geni08...@gmail.com]

I would like to get the attribute sunshine yes/no or a value in the MQTT stream to control my shutters if I already have a Davis Pro.
I can only find the value of "maxSolarRad_Wpm2". Please give me some advice on how I could evaluate this, or how could the sunshine value per minute be entered in MQTT?

[Jacques Terrettaz]

I have added a new field in my extension : is_sunshine

At each record generation,, the is_sunshine value will be 1 if there is sunshine, otherwise it will be 0.

This field is also published in the MQTT stream.

See https://github.com/Jterrettaz/sunduration/tree/master

[n7uv...@gmail.com]

Hi Karen -

I went and read the paper that is referenced for the sunshine duration method. It describes an empirical approach to estimating whether or not the sun is "shining". To me, as you suggest, if I have a crisp, well-defined shadow, then there is indeed a 6000 K point source in the sky. If I meausre in a low humidity, low atmospheric turbidity environment, with low atmospheric particulate count, that shadow should indeed be crisp and well defined. If I measure in a location where the sun is clearly above the horizon, but the shadow is less well defined due to those confounding factors and others, I can still assert that it is sunny, yet it is a degree less sunny than at the former location. 

If one looks at brewster76/

• util-archer
• /user

/radiationhours.py 

there is an arbitrary value (to be inserted by the user) on what constitutes full sunlight. 

_____________________________________________

Adds a new observation field to weewx: [sunshine_hours]

If the radiation observed during an interval of time exceeds 120 W/m2, then the interval is considered sunny,
and [sunshine_hours] is set the length of the time interval.

When [sunshine_hours] is summed over a day, the result is the number of hours during the day when radiation
exceeded 120 W/m2, or 'hours of sunshine'.

The threshold of 120 W/m2 can be overwritten in weewx.conf:

    [RadiationDays]
        min_sunshine = 120

_______________________________________________

so, for Brewster76, 120 w/m^2 is the threshold. This is more or less consistent with the original paper, which attempts to get the necessary fudge factors on atmospheric clarity via long--term empirical observations vs the theoretical value for the insolation at that minute at that location. It by no means is a measure of the shadow, or just how crisp it might be.

Various places in the USA all claim to have the most sunshine. I always wondered how they measured that, and what constituted sunshine. If indeed it is via models like what is presented in the paper and the subsequent code examples, it is just a marketing term.

If there is a measuring device, I call it the umbrameter, that can actually measure the depth of shadow cast, and quantitatively show that indeed it is a sunny minute, that would be a cool instrument. I think a quality video camera or other 2D sensor could inspect the image of the sun and, through sufficient training, could say that "this image is within x% of the expected image of the sun taken above the atmosphere, that would be a useful instrument.

Sunny days and sunshine duration appear to be a matter of opinion.

Cheers - Jon N7UV

[Karen K]

Hi Jon,

I am not sure I know which paper you referenced, but I agree with you that the 120 w/m^2 threshold is a little bit arbitrary. To my experience, in a sunny morning the radiation is less than those 120 w/m^2. Unfortunately, instruments that can really distinguish between the direct sun light and the diffusive radiation from the sky are very expensive. Most people only have a general radiation sensor, which cannot know whether the sun is shining or the sky is bright. Light is light. You cannot fill in the lack of information by calculation.

After considering this all I bought a sunshine duration sensor from Instromet. This device is expensive, too, but still achievable to normal people. It uses a shadow bar. If the radiation differs between before and behind the bar, this is considered sunshine. A well-defined shadow is not necessary here.

Karen

[Anton vanNwnhzn@GMail]

WMO (World Meteorological Organization ) defines sunshine-duration as the accumulating time each day that direct sunshine-radiation exceeds a level of 120 W/m2
That definition is simple enough, and many PWSes calculate along that setup, but 'devil is in the details'.
Perhaps puristic approach, but Sunshine might be very fluctuating in level and will meet your sensor from different angles with different wavelengths.
'Problem0' is that you need a form of calibration for your sensor, to be sure that you have correct threshold for the calulation.
'Problem1' then is that a computerized PWS takes periodic samples => you never have the really actual coverage, unless with high frequency sampling.
'Problem2' is related aspect that you have to cope with dips while filling your database for the daily accumulation => the opposite of Problem1.
The combination of those 'problems' is more the hurdle to be solved in a sturdy algorithm to get a sensible, practical result.

Op 3-5-2024 om 1:23 schreef n7uv...@gmail.com:

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

To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/254b9f95-a013-48e4-bc48-a61346d38276n%40googlegroups.com.

-- 

===============================================================
Contactinfo voor Anton van Nieuwenhuijzen:
Email    = ton...@gmail.com   
===============================================================
Deze E-mail en eventuele aanhangende files zijn 
alleen bestemd voor de geadresseerde(n). 
Als je deze E-mail ten onrechte hebt ontvangen, 
dan aub verwijderen en de afzender informeren.

[n7uv...@gmail.com]

Hi Anton -

As you point out, this method is fraught with issues, rendering a result that at best is a guesstimate. It is not Karen's "shadow" aspiration. It certainly does not fit my definition of "sunshine". 

I live in Phoenix Arizona. A day with full, honest-to-goodness (by my definition) sunshine looks like this at my Davis wx station:

This undeniably represents "sunshine". (The missing bit in the early morning is due to the mountain ridge immediately east of my station.)

Here's a screen shot of the past 7 days of sunshine:

I can promise you that on both 26 and 27 April the sky was BKN, and using Karen's approach of casting a shadow, both of those days had significant periods during the day where no obvious shadow was cast. BUT, while I don't have the evidence at the same temporal resolution as the previous two graphs for those days, I can all but guarantee that the insolation didn't drop below 200 w/m^2. 

So, according to the WHO definition, days 26 and 27 were also days of full sunlight. That's bogus. Yet, For Phoenix boosterism, they can claim even the days 26 and 27 as days of sunshine. 

In fact, even during the months of July and August, when we enter the monsoon, with full overcast and infrequent rain, rarely does the sensor drop below 200 w/m^2. Only when a T-storm cell passes directly over the station does it fall to 100 w/m^2 or less. 

My point is that "sunshine" is an ambiguous and arbitrary term, with the definition and the methods for determining situational and motivated not by observation, but by interpretation. Unless we all agree to set our sensors in a specific way, and to use the same arbitrary threshold values, one cannot directly compare one station's estimate of sunshine with another station's estimate.

I look forward to seeing how Karen's new instrument behaves. I think I understand the principle, yet it too makes a boatload of assumptions to generate its result. And for that instrument, as the sun approaches zenith (here it gets to 80 deg at the summer solstice), the data from that sensor becomes even more ambiguous.

Cheers - Jon N7UV

[Jacques Terrettaz]

The WMO definition (threshold at 120 W/m2) is applicable only for  the measurements of direct solar irradiance, using pyrheliometric sensors that are all the day moving to point always directly toward the sun position, with the surface of the sensor always perpendicular to the axis sun-sensor.

Pyrometer sensors, such as the Davis radiation sensor, are measuring mostly  global  irradiance. These sensors are not moving to follow the sun, and the surface of the sensor is parallel to the ground. And not pointed toward the sun  With this type of sensors, the measured radiation ( even in absence of clouds) is highly dependent on the sun elevation.

 see https://library.wmo.int/viewer/68695/?offset=#page=333&viewer=picture&o=bookmark&n=0&q= 

[n7uv...@gmail.com]

This I understand, Jacques -

What is "direct solar irradiance"? Is there someone at the sensor deciding that it's direct? That they confirm that a solar disk is visible? That, given a decent scope, that sun spots are resolvable? Nah, I don't think so.

 

They're PYROheliometers, measuring heat energy. Again, that becomes an arbitrary value of what is "sunshine". This is an artifice, and does not measure "sunshine" in the manner that Karen describes. It does not measure shadow, or even quality of shadow. It does not suit my local needs for "sunshine", as I've already said that on a OVC day here in KPHX it's still above 200 w/m^2. It's just a measure of "whether or not my location has received xx% of the theoretical insolation available". That's a poor estimate of "sunshine". We need an umbrameter. I submit that that is a quasi-2d sensor that measures the "quality" of an umbra cast by a sphere onto a concave spherical surface opposite to the sky, is better than what we have now. Or, using the idea of an "extended point source", it stares relentlessly into the sky and adjudicates the quality of the visible disk of the sun. Either of those is far superior to the "sunshine" concept. 

I grew up in Los Angeles CA, when it was leaving the worst of its smoggy phase. There were so many days described as "hazy", "very hazy", "mostly sunny", or "sunny". I live in Phoenix AZ now, where there isn't as strong as an inversion layer or effect. Little moisture in the atmosphere, either. My personal rule's not perfect, but I recognize a sunny day as a day where the sky is a certain shade of blue. All empirical. I've been in Paris, Rome, Madrid, London, Brussels, Oslo, Hong Kong, Beijing, Seoul, Tokyo, Sydney etc., where "yeah, it's kinda sunny (i.e., not obvious clouds between me and the sun), but it's more diffuse than it is direct. I choose not to call those "sunny days".

OMG - too many "". YMMV %^)

Cheers - Jon N7UV

[geni08...@gmail.com]

I can't find “is_sunshine” in the MQTT stream.
I have replaced the “sunduration.py” and restarted weewx
Do I have to enter this somewhere?

[Jacques Terrettaz]

Verify that you have downloaded te Release V1.4 of the extension.

Do you have "radiation_Wpm2" in your MQTT stream ?  

Please note that  the "is-sunshine" is generated only at each archive period ( i.e.. when the "interval_minute" is also generated)   and is currently not generated for each loop.

It is be possible to generate it for each loop period, but this would imply that depending  on the conditions ( very few clouds or scattered clouds moving relatively rapidly) , the "is_sunshine" may switch quite often between 1 and 0 ( a loop is about 2.5 seconds with a Davis Pro) . Not sure you would be happy to have your shutters going up several time in a few minutes under these conditions !

Let me know

--
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/JUd55LCTtDE/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/25b158d2-31c2-4713-b43c-ce355343db99n%40googlegroups.com.

[Karen K]

n7uv...@gmail.com schrieb am Samstag, 4. Mai 2024 um 05:12:04 UTC+2:

What is "direct solar irradiance"? Is there someone at the sensor deciding that it's direct? 

As Jaques wrote, this is a sensor that sees a very small angle of the sky (approximately half a degree) and it is moving and always looking at the position, where the sun should be seen.

[Ton vanN]

Rereading this thread come to understand that definition/semantics is a critical aspect in this discussion.
Bluntly summarized:
- Sunshine = seeing difference between lighted area and shadowed area.

Like KarenK's device is doing

- Lightlevel = level of undirected solar radiation, not/hardly differentating on wavelength.
Like most light sensors in 'private' PWSes will provide.
- Duration = derivative time-value of one of above, considering the time that a specfied threshold level is exceeded, with result expressed as accumulating time/day

Correct understanding?

If correct, more attention seems needed that nomenclature of variables is properly tuned;
otherwise obvious confusion.

Op zaterdag 4 mei 2024 om 18:17:18 UTC+2 schreef Karen K:

[Karen K]

Ton vanN schrieb am Dienstag, 7. Mai 2024 um 11:02:33 UTC+2:

Rereading this thread come to understand that definition/semantics is a critical aspect in this discussion.
Bluntly summarized:
- Sunshine = seeing difference between lighted area and shadowed area.

Like KarenK's device is doing

- Lightlevel = level of undirected solar radiation, not/hardly differentating on wavelength.
Like most light sensors in 'private' PWSes will provide.

There is a third device, the pyrheliometer. It is mounted on a solar tracker. See also direct insolation (please note the character o in the middle of the word, not u).

I am not sure, if "lightlevel" is the appropriate name for that kind of observation type. See global tilted irradiance (GTI).

 

[Jacques Terrettaz]

Yes, correct understanding !

 

The term "sunshine" and  "sunshine duration" is the one used by  WMO - see https://library.wmo.int/viewer/68695/?offset=#page=331&viewer=picture&o=bookmark&n=0&q= .

Why should we use another nomenclature ?

[Anton vanNwnhzn@GMail]

Jacques,

Agreed that we should not use different nomenclature than WMO (because it will only increase confusion),
but trying to reduce ambiguity is always useful.

Op 7-5-2024 om 13:06 schreef Jacques Terrettaz:

--
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/C8F02CF4-EFF5-47B2-84EB-4AF6D2BB1638%40gmail.com.

[Karen K]

Jacques Terrettaz schrieb am Dienstag, 7. Mai 2024 um 13:07:08 UTC+2:

The term "sunshine" and  "sunshine duration" is the one used by  WMO - see https://library.wmo.int/viewer/68695/?offset=#page=331&viewer=picture&o=bookmark&n=0&q= .

And this link reads: "According to WMO (2010), sunshine duration during a given period is defined as the sum of the time for which the direct solar irradiance exceeds 120 W/m^2." 

Note the word "direct".

The sensor, most private weather stations use, measures the global irradiance, that is from the sun as well as from the sky. So there the threshold of 120 W/m^2 does not apply. Nevertheless, people use it that way.

The pyrheliometer can measure the direct solar irradiance, only. And I hope, that shadow device can be (and is) calibrated precisely enough.

[Jacques Terrettaz]

Yes... some people use that way... but wrongly !  May be also  because even the software developed by Davis (Weatherlink)  to capture Davis Vantage data is proposing  the use of a 120 W/m2 threshold for their global irradiance sensor !!!

The  use of global irradiance sensors is largely discussed in the WMO document concerning the measurement of sunshine duration, and  2 differents formulas are proposed in appendix 8A and 8B to calculate the threshold value for global irradiance sensors

My extension is using the formula of appendix 8B, and I can say that at least with a Davis radiation sensor, it is working very well , after many years of utilisation!

Karen, except your  Weerhuilje sunhours sensor, do you have with your weather station any global solar irradiance sensor ?  If yes, you could try an alternate calculation of sunshine duration and compare.

[Karen K]

Jacques Terrettaz schrieb am Dienstag, 7. Mai 2024 um 15:26:49 UTC+2:

Karen, except your  Weerhuilje sunhours sensor, do you have with your weather station any global solar irradiance sensor ?  If yes, you could try an alternate calculation of sunshine duration and compare.

Unfortunately I cannot do the calculation actually due to lack of time. But I can provide the raw data for you to do it yourself. The columns of the table within the attached file are:

• localTime: timestamp of the end of the measuring interval in local time as text for reference
• dateTime: timestamp of the end of the measuring interval in seconds since 1.1.1970 0:0:0 UTC (Unix time)
• radiation: readings of the global irradiance sensor of the Davis weather station in Watt per squared meter
• sunshineDur: readings of the Weerhuisje/Instromet sunshine duration sensor in seconds per 5 minutes
• solarAzimuth: solar azimuth in degrees
• solarAltitude: solar altitude in degrees

[jterr...@gmail.com]

Karen, thanks. 

I will do the calculation, and let you know. It will be interesting to have a comparison , but I need some more information , particularly the  latitude and longitude of the place where your sensors are installed. I will send you a private email .

[Karen K]

jterr...@gmail.com schrieb am Freitag, 10. Mai 2024 um 19:49:06 UTC+2:

Karen, thanks. 

I will do the calculation, and let you know. It will be interesting to have a comparison , but I need some more information , particularly the  latitude and longitude of the place where your sensors are installed. I will send you a private email .

I included the actual solar altitude in the file. So you can use it within the calculation.

[jterr...@gmail.com]

OK with the solar altitude.

One more question : in your csv file,  the maximum values of the sunshine duration measured by the Weerhuisje/Instromet sunshine duration sensor , for a period of 5 minutes, are 324 seconds , higher than the 300 seconds interval. 

How should we interpret all these values ? Scale them proportionally so that a value of 324 correspond to a 300 second sunshine ?

[Karen K]

jterr...@gmail.com schrieb am Freitag, 10. Mai 2024 um 20:35:20 UTC+2:

One more question : in your csv file,  the maximum values of the sunshine duration measured by the Weerhuisje/Instromet sunshine duration sensor , for a period of 5 minutes, are 324 seconds , higher than the 300 seconds interval. 

How should we interpret all these values ? Scale them proportionally so that a value of 324 correspond to a 300 second sunshine ?

The sensor sends a pulse every 36 seconds if the sun shines. 8 pulses are 288 seconds, 9 pulses are 324 seconds. If the sun shines continuously, sometimes you get 8 pulses within one archive interval and sometimes 9. That is the reason for those values. So you may add those additional 24 seconds to the previous or next archive interval.

[Jacques Terrettaz]

OK, thanks. 

A good "offline" comparison of your sunshine sensor with the formula will be difficult, since with your archive data the fomula will produce only one estimation for a 5 min period, based of the archive radiation measurement , which is the mean radiation measured over of archive period .

When used "online", as an installed weewx extension, the evaluation is done on the basis of the instantaneous radiation LOOP data, and is updated as soon as a new radiation value is sent by the Davis radiation sensor (about every 50 seconds). 

[Karen K]

Jacques Terrettaz schrieb am Montag, 13. Mai 2024 um 09:29:49 UTC+2:

.. only one estimation for a 5 min period, based of the archive radiation measurement , which is the mean radiation measured over of archive period .

Unfortunately I cannot provide the raw sensor readings. We do not save them. We do only save the mean over the archive interval.

[Jacques Terrettaz]

OK.  So I did the calculations based on the mean radiation value for a 5 minute period.  

Globally  the data derived from the formula give a higher sunshine duration.  

But  I am not sure if your sunshine duration sensor is located at the same place or near the Davis radiation sensor . If it is not the case , any comparison will be useless !

For example, here is  a chart of your data, with the area showing your  Davis radiation sensor values, the bars showing your sunshine sensor measurements, and the curve showing the formula threshold calculation for august 18 and 19 2023 :

Most the absence of sunshine  with your sensor measurements for these two days between 12h00 and 16h00 are  difficult to correlate  with the radiation measurement  (except a small drop on 18 august at about 14h00) .

Or  in 7  or 8 august 2022:

You can "browse" your data here , with the "ticks" calculates bye the formula :  http://meteo-sciez.fr/site/graph_frame_karen.php  and by choosing the date of interest, and clicking at  the legend of each series to show  or hide .

--
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/JUd55LCTtDE/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/6889d2d1-739a-43e0-a0b0-5ade06443a96n%40googlegroups.com.

[Karen K]

Oh, that are very interesting data. 

Jacques Terrettaz schrieb am Montag, 13. Mai 2024 um 18:36:27 UTC+2:

Globally  the data derived from the formula give a higher sunshine duration.  

We cannot expect to get the same values from that different measurement principles, I guess. Nevertheless, I find it useful to compare and to discuss about it.

 

But  I am not sure if your sunshine duration sensor is located at the same place or near the Davis radiation sensor . If it is not the case , any comparison will be useless !

No, it is not at same place. The Davis weather station (and with it the radiation sensor) is located at 2 meters above the ground, as the rules say. There is some shadow from a tree at about 15:00 o'clock in winter. The sunshine duration sensor is mounted on a mast at about 10 meters above the ground (near the wind sensor). No shadow is around there.

 

You can "browse" your data here , with the "ticks" calculates bye the formula :  http://meteo-sciez.fr/site/graph_frame_karen.php  and by choosing the date of interest, and clicking at  the legend of each series to show  or hide .

I will have a look at it. 

 

I guess, we should validate the measurements by checking sunshine manually at different points of the day and the sunshine condition. Actually the sky is blue, and no cloud is to be seen. So we have to wait for clouds to get some useful data.

[Karen K]

@Jacques: I now added your extension to the configuration. The calculated values will be stored to the database. After some time I will publish the readings here.

[Michael Green]

Hello Jaques,
I use your extension successfully on my weewx-installation. But it would be nice to have the possibility to fine tune the script because some local issues of sensor-installation. 
Which constant in your script can be manipulated for the sensitivity / threshold value for sunshine in order to adapt to local characteristics? 
Many thanks for your tip, 

best regards Michael

[Jacques Terrettaz]

Hello Michael,

I have modified the extension (release v1.5)  to expose two coefficients used for the calculation. : https://github.com/Jterrettaz/sunduration/tree/v1.5

With this new version , you will have to add this stanza in weewx.conf :

[Sunduration]

        global_coeff = 1.0

        B_coeff = 0.06

By default, the coefficients of the formula used to calculate the radiation threshold are the one validated for a latitude of 44° in the south of France (global_coeff = 1 and B_coeff = 0.06). 

If, for your location and your solar sensor, the threshold is too low or too high, you can adjust globallty the value of the parameter global_coeff.

For instance, a value of global_coeff = 1.05 will globally increase the thresholf value by 5% A value of global_coeff = 0.95 will globally decrease the threshold value by 5%

The B_coeff can be changed if you observe that the threshold needs to be adjusted only for winter or summer period.

For instance, a value of B_coeff = 0.08 will increase the threshold value by about 3% in winter, and will decrease the threshold value by about 3% in summer. A value of B_coeff = 0.04 will decrease the threshold value by about 3% in winter, and will increase the threshold value by about 3% in summer.

Best Regards

Jacques

[Geni]

What value should global_coeff have for latitude 47°?

[Jacques Terrettaz]

If you are using a Davis pyranometer, you can keep global_coeff to 1.  My Davis weather station is at latitude 46.34 N and I use this value.

If you have another solar or light sensor, you will have to adjust the value of global_coeff, and possibly the B_coeff, until  you have good results - i.e  when the formula will reporting sunshine when shadows are visible, and no sunshine when there  is no shadows.