Please can you tell me how to set up the synop binding?
I installed it, but what do i have to do next? Where do i get the synop station number?
And which wunderground binding? Is this the WeatherUnderground Binding from the market?
I have another idea to get a virtual solar sensor, can someone help me with this?
I have photovoltaic panels on my roof. So now i have the radiation value from astro-binding and the powervalue from the photovoltaic-power-meter.
Can i calculate something with this two values? Maybe if radiation should be high, but there is only very small power output, then the chance is high, that it is a cloudy day?
But i don´t have an idea, how i can calculate this???
The WeatherUnderground Binding is indeed the one from the Eclipse marketplace. I expect it will be merged in openHAB in the future. It works perfectly as is though.
You can look for a WOID here or here. Look for a location that is close and upstream from the main wind direction. Not all locations update every hour, so pick one with regular updates.
I do use photovoltaic power as a trigger to switch off some lights myself. It is just a question of finding the right power level to switch off. I don’t even think you need the radiation as an input for that. You could try graphing radiation, octa, photovoltaic power and cloudiness for a while and look for a correlation. The advantage of this is that it definitely correlates to the light level at your specific location.
Ok, i made some new items and a chart to get the info in the next few days.
I also wanted to make an average calculation to prevent my blinds to open on every little cloud on the sky.
I now have this items:
solar-power
radiation
calculation-item --> (solar-power / radiation)
10min average of calculation-item
The calculation-item is to get better values on morning and evening.
Which average would be a good value for automatic stop of the shading? I think 10 minutes is to low?
I think your rule with the data from a weatherstation is not accurate enough. Next weather station is 25km away from my home. And i only get data in a 1 hour interval. Not good for partly cloudy days.
When i have all this information, the bigger part will begin… Include inside temperatur, azimuth/elevation, window directions, time (clock), time (season), opened windows and current sun-radiation/brightness into a rule.
Hi,
Thanks @Mherwege for the rules. As I have OpenHab 1.8, it didn’t run properly so I had to adapt it a bit. It works well, meaning there is data recorded, but I am not sure if the result is the one expected:
The green curve shown in the graph above is the results from your rules during a sunny day with clouds appearing occasionally.
From the rules, there is a formula to determine the total radiation depending on sun altitude. I understand that this causes a disruption in the value of the total radiation at sunrise and sunset (just before 22:00 and just after 6:00 in the graph above).
My question is: is such a disruption from 40 klux to less than 1000 lux at sunrise and sunset expected? Or did I mess up when I adapted the rules to my version of OpenHab?
Cheers,
Ludovic
@lolu I don’t have the original version of the rule running anymore. I use the simpler version using data from the Astro and Weather Undeground bindings, see above. This does not correct for pressure anymore, but that effect was minimal anyway. Even with these formulas, I see a very similar difference, but the break is not as abrupt. Note that in my case the radiation is taken from the Astro binding and the break for sun below 1 degrees is therefore in the binding code.
I copied the formulas from the Domoticz ones and left the comment about accuracy around the break point in. You might want to see what happens if you remove the break and just put it at 0 when sun is below -7 degrees. Your curve might be smoother. Also, try plotting the sun elevation. My rules assume this to be updated by the Astro binding. If this is not frquent enough, it may also rxplain the abrupt break.
Hi @Mherwege,
Sorry for the late reply (I just saw your post) and thanks for your answer.
I will try to remove the break for the sun between -1 ° and -7 °.
Also, I will plot the sun elevation. In the mean time, I reduced the refresh period of the sun elevation from 600 s to 35 s.
Cheers,
Ludovic
Sorry to take up this old tread - but this is just a fun exercise, and I might be able to use it to adapt my own scene lightning.
However, that Kc formula seems weird. I used an hour or two trying to google the effect of cloud cover on sun radiation, and came up with very little. I did find a use or two of the above formula but with no references to its source. This is probably because clouds comes in all kinds of forms with each their on influence on the radiation, so no simple formula is really useful.
But still, you do not have to google much before finding tables like:
Cloudless: 100.000 lux
Overcast: 1.500 lux
That goes quite well with my own subjective experience - it really gets a lot darker when overcast 
and the formula above does not at all reflect that.
I will try some experiments with an adapted formula: 1 - 0.95 * cloudPct^1.6
Also, I am getting a cloudPct from OpenWeathermap.
I will write again if I think my formula seems useful after some weeks, but anyway I suggest you think twice before using the original formula
Hi,
Thanks for the information. I would be happy to have an update.
The rule I use is now broken. I don’t I have time to try to find out why unfortunately.
So now I am just looking at the time of the day to switch on the lights.
Do you plan to compare the results of your adapted equation to the one given in this thread? That would be very interesting.
Cheers,
Ludovic
Will do. It will probably take some weeks to see anything interesting, as we are having some sunny days here right now 
I can however already see that the radiation based lux by it self is quite good to get an rough idea of when it is dark’ish or not, so I’ll see if it can be better with adjustments for clouds.
I don’t like to much automation for my lights, but I am going to try it out for adjusting some ambient lights in my light scene setup.
I’ll be back 
Hi,
I never thought I would say something like this: too bad you have sunny days…
As opposed to you, I like the light automation, especially in the living room. When my rule was not broken, the light used to come up gradually starting latest at the sunset time for a sunny day and earliest 2 hours before for a day with heavy clouds. As you would guess, it was mainly occurring in between.
I found it to be the most useful automation as we always had enough luminosity in the living room at the end of the afternoon without doing anything.
On the other hand, I think that it would be quite challenging to regulate the ambient light brightness according to the outside luminosity when it is based on a virtual sensor. But it is fun to embrace such a challenge and I would be very interested to know how you come up with it.
Cheers,
Ludovic
The approach seems to work well!
The original formula is not as bad as I thought, and the formula I tried seems to underestimate the amount of light.
I will try with 1 - 0.85 * cloudPct^2
This is my new rule:
// adapted from https://community.openhab.org/t/virtual-solar-sensor/24705/10
rule "Calculate outside light"
when
Item Weather2_Now_Cloudiness changed or // from OpenWeatherMap binding
Item Astro_Sun_TotalRadiation changed // from Astro binding
then
// Factor of mitigation for the cloud layer
// a "common" formula is 1 - 0.75 * cloudPct^3.4, which is used in the referenced openhab community article
// however, it is also common to see a table with 100.000 lux on cloudless day and 1.500 lux on overcast days - that goes with my own subjective experience
// I use an adapted formula dreamt up by my self: 1 - 0.95 * cloudPct^1.6
var double Kc = 1 - 0.85 * Math.pow(((Weather2_Now_Cloudiness.state as DecimalType).intValue)/100.0, 2)
var double Kc2 = 1 - 0.75 * Math.pow(((Weather2_Now_Cloudiness.state as DecimalType).intValue)/100.0, 3.4)
//logInfo("Light", "Kc {}", Kc)
// Radiation in Lux. 1 Lux = 0.0079 W/m²
var double vLux = (Astro_Sun_TotalRadiation.state as DecimalType).doubleValue / 0.0079
// radiation of the Sun with the cloud layer
var double vWeightedLux = vLux * Kc
var double vWeightedLux2 = vLux * Kc2
Astro_Sun_Lux.postUpdate(vLux)
Weather2_Sun_Lux.postUpdate(vWeightedLux)
Weather2_Sun_Lux2.postUpdate(vWeightedLux2)
//logInfo("Light", "Lux {}", vLux)
//logInfo("Light", "WeightedLux {}", vWeightedLux)
end
I have chosen to only turn on my main lights manually. But I turn on some ambient additionally lights based on the sun weighted lux. Depending on the placement in the house I turn them on at lux values ranging from 18K (the darkest parts of the house) to 5K. It works quite well
This is amazing formula could be very useful I’m a bit of a newbie I don’t understand the basic wording of this language yet mostly go by trying and see what happen. I Had this particular code working on my side but had to bring the following change to it, no sure why! Converting to DecimalType was’t working I had to use QuantityType unsure why. And the postUpdate wasn’t doing anything so I changed it to sendCommand and it start showing in BasicUI here’s you code wuth the change to make it work on my side.
Blockquote
// adapted from Virtual solar sensor - #10 by Mherwege
rule “Calculate outside light”
when
Item localCurrentCloudiness changed or // from OpenWeatherMap binding
Item Total_Radiation changed // from Astro binding
then
// Factor of mitigation for the cloud layer
// a "common" formula is 1 - 0.75 * cloudPct^3.4, which is used in the referenced openhab community article
// however, it is also common to see a table with 100.000 lux on cloudless day and 1.500 lux on overcast days - that goes with my own subjective experience
// I use an adapted formula dreamt up by my self: 1 - 0.95 * cloudPct^1.6
var double Kc = 1 - 0.85 * Math.pow(((localCurrentCloudiness.state as QuantityType<Number>).intValue)/100.0, 2)
var double Kc2 = 1 - 0.75 * Math.pow(((localCurrentCloudiness.state as QuantityType<Number>).intValue)/100.0, 3.4)
logInfo("Light", "Kc {}", Kc)
// Radiation in Lux. 1 Lux = 0.0079 W/m²
var double vLux = (Total_Radiation.state as QuantityType<Number>).doubleValue / 0.0079
// radiation of the Sun with the cloud layer
var double vWeightedLux = vLux * Kc
var double vWeightedLux2 = vLux * Kc2
Astro_Sun_Lux.sendCommand(vLux)
Weather2_Sun_Lux.sendCommand(vWeightedLux)
Weather2_Sun_Lux2.sendCommand(vWeightedLux2)
logInfo("Light", "Lux {}", vLux)
logInfo("Light", "WeightedLux {}", vWeightedLux)
end
I tried this rule but it is soooooo slow. I think its because of the Math.pow() argument.
Can someone help me?
I use OH 3
and I get this error:
2021-01-29 19:10:26.736 [ERROR] [internal.handler.ScriptActionHandler] - Script execution of rule with UID ‘shutters-1’ failed: An error occurred during the script execution: null in shutters
As I’m preparing to move on to OH3 I tried porting the rule to jython, it seems to be working though it’s not thoroughly tested and probably not scientifically correct but here is my attempt (use at your own risk )
see updated version below.
Are you aware that direct, scattered and total radiation are already provided by the Astro binding ?
To be honest, no, this is just a very quick attempt to port the scripts I use over to jython. It would definitely cleanup the script quite a lot! thanks for the hint
Updated to use radiation information provided by Astro. It looks like Astro doesn’t calculate radiation if sun altitude is below 3 degrees. I re-added ArbitraryTwilight to compensate for this. Probably not scientifically correct but it works to control my garden lights
Edit: Fixed negative lux values.
oh_vlux3.py.txt (4.6 KB)
1 Like
Hey hey,
allthough all my indoor motion sensors have a brightness sensor, I want to have an absolute value for determining if it’s dark or not indipendent if my indoor lights are on or not.
My ambient light turns on either if it’s night (Astro sunset/sunrise) or if it’s dark based on this rule.
I adapted it to the new JS rule engine.
configuration: {}
triggers:
- id: "2"
configuration:
itemName: System_Sonnendaten_Nacht_Gesamtstrahlung
type: core.ItemStateChangeTrigger
- id: "3"
configuration:
itemName: System_Wetter_Bewoelkung
type: core.ItemStateChangeTrigger
conditions: []
actions:
- inputs: {}
id: "1"
configuration:
type: application/javascript;version=ECMAScript-2021
script: >-
// https://community.openhab.org/t/virtual-solar-sensor/24705/22
console.log("RULE System_Wetter_Aussenhelligkeit")
var Bewoelkung = items.getItem("System_Wetter_Bewoelkung").rawState
var Strahlung = items.getItem("System_Sonnendaten_Nacht_Gesamtstrahlung").rawState
//Limit
if (Bewoelkung < 0.0) Bewoelkung = 0.0
if (Bewoelkung > 100.0) Bewoelkung = 100.0
if (Strahlung < 0.0) Strahlung = 0.0
if (Strahlung > 1500.0) Strahlung = 1500.0
// Factor of mitigation for the cloud layer
// a "common" formula is 1 - 0.75 * cloudPct^3.4, which is used in the referenced openhab community article
// however, it is also common to see a table with 100.000 lux on cloudless day and 1.500 lux on overcast days - that goes with my own subjective experience
// I use an adapted formula dreamt up by my self: 1 - 0.85 * cloudPct^2
// wolframalpha.com/input?i=plot+1-+0.85*x%5E2+from+0+to+1
var Kc = 1 - 0.85 * Math.pow(Bewoelkung/100.0, 2)
var Kc2 = 1 - 0.75 * Math.pow(Bewoelkung/100.0, 3.4)
//logInfo("Light", "Kc {}", Kc)
// Radiation in Lux. 1 Lux = 0.0079 W/m²
var Lux = Strahlung / 0.0079
// radiation of the Sun with the cloud layer
var WeightedLux = Lux * Kc
var WeightedLux2 = Lux * Kc2
items.getItem("System_Wetter_Aussenhelligkeit_unveraendert").postUpdate(Lux)
items.getItem("System_Wetter_Aussenhelligkeit").postUpdate(WeightedLux)
items.getItem("System_Wetter_Aussenhelligkeit_Alternativ").postUpdate(WeightedLux2)
//logInfo("Light", "Lux {}", vLux)
//logInfo("Light", "WeightedLux {}", vWeightedLux)
type: script.ScriptAction
Have fun.
1 Like
I didn’t see this post before posting mine, but it looks like we both had the same idea. I create a rule template using javascript for the original formula. You can find it here. That should make it straightforward to configure this.
1 Like