Real-time solar data : azimuth, Altitude, Lux sensor... [closed]

[Derik]

Try this one to make working...

I do have the lua script in the lua directory
I do have 2 [ to start ] dummy sensors
1 uv [ idx i now]
1 custom [ idx i now ]
1 account by Wu [ apikey check ]
station in my area [ INIJMEGE14 NL]

Still get error:

Code: Select all

lua:56: attempt to call a nil value

I did changed this settings...: [ changed my Api for this forum ]

Code: Select all

-- Variables to customize ------------------------------------------------
       local city = "INIJMEGE14"            -- Your city for Wunderground API
       local countryCode = "NL"            -- Your country code for Wunderground API
       local idxLux ='4750'            -- Your virtual Lux Device ID
       local idxSolarAzimuth ='4694'       -- Your virtual Azimuth Device ID
       local idxSolarAltitude ='84'       -- Your virtual Solar Altitude Device ID
       local idxUserVarOcta='2'           -- Your user variable ID , named octa
       local wuAPIkey = "daa398aba1133366d7a" -- Your Weather Underground API Key
       local latitude = 51.862277       -- your home
       local longitude = 4.866366      -- your home
       local altitude = 27              -- Your home altitude : run once in debug = 1 to found your altitude in Log and write it here
       local WMOID = '07145'    -- Your nearest SYNOP Station for ogimet (to get Cloud layer). Run once with debug=1 to get it in the log. (or, better, choose it there : http://www.ogimet.com/gsynop_nav.phtml.en )
       local DEBUG = 0             -- 0 , 1 for domoticz log , 2 for file log
       -- and customize the URL of api.wunderground around line 104 according to your country.
 

Please help..

And the hings i do really not understand:
local idxUserVarOcta='2' -- Your user variable ID , named octa [ What must i do? ]
local altitude = 27 -
local WMOID = '07145' -
local DEBUG = 0 -- 0 , 1 for domoticz log , 2 for file log

[qwerk]

I think the original script is working fine, but ogimet is not getting/receiving the newest data.
an hour ago the newset data was from 15:00 and now is 19:00. station 06275

[jmleglise]

@Derik,

You must adapt all the parameters.

- Do you know what an "uservariable" is ? The script require one uservariable that you must create.
- You must create too the 3 virtual sensor as shown here : http://www.domoticz.com/wiki/Real-time_ ... structions

- As writen in the comments, run the script once with "local DEBUG = 1" (instead of "local DEBUG = 0") to parameter altitude and WMOID. Read the value in the log

[Derik]

[quote="jmleglise"]@Derik,
- As writen in the comments, run the script once with /quote]
How can i do this...
The degrees sensor:

ScreenShot159.jpg (18.97 KiB) Viewed 3346 times

And the uservariable:

ScreenShot160.jpg (45.82 KiB) Viewed 3346 times

And i do real not understand the:

Code: Select all

  local WMOID = '07145'    -- Your nearest SYNOP Station for ogimet (to get Cloud layer). Run once with debug=1 to get it in the log. (or, better, choose it there : http://www.ogimet.com/gsynop_nav.phtml.en 

part.

If you have a lot of time...
Thanks

[jmleglise]

And i do real not understand the:

Code: Select all

  local WMOID = '07145'    -- Your nearest SYNOP Station for ogimet (to get Cloud layer). Run once with debug=1 to get it in the log. (or, better, choose it there : http://www.ogimet.com/gsynop_nav.phtml.en 

part.

If you have a lot of time...
Thanks

Just go to http://www.ogimet.com/gsynop_nav.phtml.en click the map to choose the nearest Weather station to your home. Get the ID of this station and report it to the script.

[jmleglise]

@all,

You can see at ogimet web site, that sometimes, there is no data available.
Column : Daily weather summary

For example, for my nearest station : http://www.ogimet.com/cgi-bin/gsynres?l ... 0&ndays=30

[Derik]

Still have them almost all..
1 Lux [ set the IDX an copy the name]
1 Azimuth [ set the IDX an copy the name]
1 Altitude [ set the IDX an copy the name]
1 WU Api [ copy/paste ]
1 WU city and country
1 octa like the wiki says
1 WMOID
Set the debug for 1

Code: Select all

local city = "INIJMEGE66"            -- Your city for Wunderground API
       local countryCode = "NL"            -- Your country code for Wunderground API
       local idxLux ='4750'            -- Your virtual Lux Device ID
       local idxSolarAzimuth ='4694'       -- Your virtual Azimuth Device ID
       local idxSolarAltitude ='4790'       -- Your virtual Solar Altitude Device ID
       local idxUserVarOcta='2'           -- Your user variable ID , named octa
       local wuAPIkey = "daa398axxx1166d7a" -- Your Weather Underground API Key
       local latitude = 55.862277       -- your home
       local longitude = 4.866366      -- your home
       local altitude = 27              -- Your home altitude : run once in debug = 1 to found your altitude in Log and write it here
       local WMOID = '06375'    -- Your nearest SYNOP Station for ogimet (to get Cloud layer). Run once with debug=1 to get it in the log. (or, better, choose it there : http://www.ogimet.com/gsynop_nav.phtml.en )
       local DEBUG = 1             -- 0 , 1 for domoticz log , 2 for file log

I cannot get the Local altitude???

Code: Select all

local altitude = 27              -- Your home altitude : run once in debug = 1 to found your altitude in Log and write it here

And still get the error:

Code: Select all

2016-08-10 20:40:01.100 Error: EventSystem: in /home/linaro/domoticz/scripts/lua/script_time_SolarSensor.lua: .../linaro/domoticz/scripts/lua/script_time_SolarSensor.lua:56: attempt to call a nil value

ScreenShot163.jpg (62.51 KiB) Viewed 3319 times

[Toulon7559]

@jmleglise

Here no sun today but rain was reason to look at your script to get information on lightlevel .....

Got the script running, nice results!
Based on this fresh experience perhaps a few remarks (no critics, just meant as positive suggestions, e.g. as a response to Derik's questions!):
1. In a forum-message it is mentioned, but in Wiki also to be told that lines 57 and 58 should be set according to the operating system in use.
With a warning in the WiKi that the mentioned file json.lua should be put in the designated directory!
2. Puzzled by the use of local variables related to the WUnderground-API-call in line 64.
If lines 15, 16 and 21 have correct filling, then the API-call in line 64 [ > local config=assert(io.popen('curl http://api.w ..... ] should result in a response, without need for customization.
Getting error-reports on this API-call, I simplified the script by replacing line 76 ('making' the relative pressure) by a local read-out for barometric pressure.
Using other information in the local variables you can completely avoid/delete that API-call to Wunderground:
your latitude, longtude and altitude is easy to find by means of Google Maps
3. Likewise contents for the local variable WMOID can easily be found in the most right column at https://www.wunderground.com/about/faq/ ... s.asp?MR=1
Line 143 (calling WMOID from jsonlocation) then is not needed and can be disabled.
4. What is/was the intended application of " local idxUserVarOcta='2' -- Your user variable ID , named octa" ?
Later in the script (approx. lines 145 ~160) the parameter octa is directly/dynamically called from ogimet, and it is stored as uservariable.
But the scriptline applying the local variable idxUserVarOcta has been disabled [?]

[jmleglise]

Hi,

No worry, this is a "collaborative script" from several great guys.

1. feel free to complete the wiki with your experience ! In particular the install section that is very light.

2. You are right. Depending of your system, you can optimize the script and avoid the call to this api.

3. The ogimet list is more complete than the one from WU.
My nearest station "07145", is not in the list of WU.

4. No. The uservariable is usefull. If there are no cloud layer data available from ogimet , then the script use the last value available stored in the uservariable.
with line : Octa = uservariables['octa']

[Toulon7559]

@jmleglise

Perhaps a brainwave, but would it be feasible to extend your script with a calculation for (aprroximated) UV-level?

[jmleglise]

UV index seems to be : the radiation / 25000. If so, it's easy. Do it outside the script.

https://en.wikipedia.org/wiki/Ultraviol ... definition

[Toulon7559]

@jmleglise

Thanks for the hint.
Because of the neglect of the wavelength-effects taking (weightedLux)/25000 seems a gross & very brute simplication to estimate UVIndex, but I will experimentally insert in my own adapted version of the script and check what Domoticz shows in the log and on the UV-meter + graph.
Must only find how to make the added tostring-sequence for 'uploading' the UV-value, because the UV-idx apparently expects an extra 0 in the tostring (and no script-examples given in the wiki): any hints/examples?

[jmleglise]

Sorry, I dont understand what you mean.

Create a new custom sensor "uv Index"

In the script add something Like that:



commandArray[indexArray] = {['UpdateDevice'] = idxUVindex..'|0|'..tostring( totalRadiation/25000 )}
indexArray=indexArray+1

[Toulon7559]

@jmleglise

Created a scriptline to calculate a UV-value:
weightedUV = weightedLux / 25000
Made a virtual device with related idxUV, type UV
Inserted 2 extra scriptlines almost identical to those you suggest.
When it failed (= on the Domoticz Dashboard for Weather, the 'UV_meter' went blank), then I looked around and detected in the Wiki that in the JSON-call for UV there is an exception mentioned relative to other JSON-calls:
see https://www.domoticz.com/wiki/Domoticz_ ... N_URL's#UV relative to https://www.domoticz.com/wiki/Domoticz_ ... _URL's#Lux
Checking in Domotics under Events/ Show Current States, before the UV-meter went corrupt, for the UV_idx/svalue I saw the value 0;0
After the corruption it was a single 0
Corrupt virtual UV-device meanwhile replaced.
Therefore I suspect that in the lua-script for setting of the UV_dummy 'something extra' must be inserted at the end of the first extra scriptline.
Was expecting a related example approx. halfway in section 3 in this wiki-section:
https://www.domoticz.com/wiki/Events#By ... ion_folder
Lines for temp, humidity and barometer are shown, but unfortunately no specific example related to UV.
The example for TempHum may be an indication, but not sure, because no reaction on scriptlines like

commandArray[indexArray] = {['UpdateDevice'] = idxUV..'|0|'..tostring(round(weightedUV,0))..';'..'|0|'}
indexArray=indexArray+1

No errorreport in Domoticz' log (= above scriptlines are 'legal'?), but also no change to the virtual UV-meter, not even a change in time-last-seen.

Some thinking & searching & experiment required, unless a hint or example from somewhere else ......

[jmleglise]

If you use The same device type as the Lux device and the same updatedevice Line as the script, then there is no reason that didnt work.
Sorry, I m not at home to write you the correct script.

And by the way, according to the formulae of Wikipedia, it is the radiation you must divide. Not the lux.

[Toulon7559]

Fell in a trap misunderstanding the selection of the virtual device for UV: looked obvious to select type = UV
Working solution:
for UV do not create a Virtual Device of type UV or type Lux, but select type Custom/General.
Then your 2 added scriptlines are generally applicable without problems
commandArray[indexArray] = {['UpdateDevice'] = idxUVindex..'|0|'..tostring( weightedLux/25000 )}
indexArray=indexArray+1

Reasons that I applied weightedLux as input for the UVI-calculation, instead of totalRadiation:
- UnweightedLux is directly proportional to totalRadiation, which is therefore OK as starting input for UV-calculation
- UVI is dependent on the level of cloudcover, and (in my opinion) therefore Kc should be included => weightedLux ultimately includes that factor
- UVI should have a value between 0 and 10, and with totalRadiation seldom being > 1000W/m^2, the division of totalRadiation by 25000 does not produce suitable values.
- WeightedLux generally is 126* higher due to the previous division of the radiation-value by 0,0079, and that (pragmatically) results in UVI-values coming in the desired range 0 - 10, for radiation-values which justify the UVI-values.

But looking back at the article in Wikipedia we probably have to reread more carefully, and have to reconsider the 'DUV-division-factor'.
According to that text, the DUV-inventors divided a midday value of 264mW/m^2 by 25mW/m^2 to get UVI=10.6
But 264mW/m^2 is not a midday value out of the calculation model which produces UVI=10 in Europe: that calculation model produces high radiation values in the order of > 1000W/m^2.
Something is 'lost in translation' between the text in Wikipedia and the selection of the 'conversion-factor', but what?

[Toulon7559]

Past few days I checked the UV-report made by WUnderground for my WS7000-setup.
For that setup I uploaded the data for solar radiation resulting from the model. No upload of an estimated UVI, but let WUnderground do it's own job.
WUnderground then reports an integer UV-value close to integer[(solar radiation)/100)], although not sure about their method of calculation.
Location Bilthoven is not location Hengelo, but nevertheless on a bright day with blue sky like today that value (of max. 6) is reasonably close to the max. value (of approx. 5.3) as reported by RIVM at http://www.buienradar.nl/nederland/zon- ... nkracht-uv
The simplification of WeightedLux/25000 reaches to approx. half that value.

Some more work to be done to get a workable simple formula to derive UVIndex from Solar Radiation .............

[vmb]

I managed to implement this very nice script in my Domoticz. All went right.
Script is working well.

Only one thing is strange. My total amount of lux is between 56000-70000 lux on this reasonable licht cloudy summersday.
What do you folks think: is this lux correct or is something going wrong?
Will give it a day or two, but what do you think?

[Derik]

I managed to implement this very nice script in my Domoticz. All went right.
Script is working well.

Only one thing is strange. My total amount of lux is between 56000-70000 lux on this reasonable licht cloudy summersday.
What do you folks think: is this lux correct or is something going wrong?
Will give it a day or two, but what do you think?

Please VMB will you help me...
Look @ a few topic before... my setup is not working...

[Toulon7559]

The last 3 days for the conditions in Twenthe the model had a peak-output reaching above 80000 lux which is equivalent to approx. 600W/m^2
That radiation-level is possible in the Netherlands on a bright & sunny summerday ......

But I have to wait until those BH1750-sensors arrive from China to make a measuring setup for validation.