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

[xces]

Can anybody give feedback on my post/questions?

I will update the source code,

Can you make sure there is only '1' version of the source code online? I currently see a few mentioned in comments from other users, but there is one in the start post which does not seem to be in sync with the wiki. Which is leading?

By the way, i think there is an error in the Lua script (on the wiki)

Code: Select all

if tonumber(otherdevices_svalues['Lux'])+round(weightedLux,0)>0   -- No update if Lux is already 0. So lastUpdate of the sensor switch will keep the time of day when Lux has reached 0. (Kind of timeofday['SunsetInMinutes'])
  then
    ...
  end

Maybe the best solution would be to just do this; which will ONLY update if the lux value is different then the current device value, right?

Code: Select all

if tonumber(otherdevices_svalues['Lux']) ~= round(weightedLux,0)
then
  ...
end

[jmleglise]

@xces,

Thank you very much for publishing the comparison of fibaro sensor / this script as It's the first time that I can benchmark the script with a "real sensor".

First comments :
I am positively surprised to see that curves are also close. Did you set up the ogimet station and at what is distance between the station and your home ? (because the graphic shows that there wasn't any cloud all the day long...). I am interested to see other graph comparisons in particular of one day when clouds alternate with periods of sun.

And a tip for everyone : the choice of the ogimet station is important. In my case, I have several stations in my region. I choose the one that is before my home in, the "usual" direction of the wind. Thus, the cloud that the station detects, arrives above my home when the script get the data.

* For the x10 difference : Is your fibaro sensor exposed outside in the sun with the sensor oriented in front of the sky (and not under a porch) ? The professionnals Lux sensors are oriented right to the sky.

* Sorry, I don't use blockly. So I suggest you to start learning LUA
For your question about waiting 600 seconds, you will find the answer in this page : http://www.domoticz.com/wiki/Events . Search 'On AFTER 10' in it.

* The interest of a device is that you have graph of history of data. If you don't need it, of course you can modify the script to use uservariables instead.

* The most up to date and "official" source code is in the wiki. The version number is written in the source code , AND it's written in the first post of this thread...

* and no, there is no error in the logic to update the value. In your proposal the value will not be updated if it doesn't change (aka no update during the day for the same value). While I only want to not update the value by night to be able to detect sunset and sunrise. It's explained in the script and wiki.

[ArnaudStrasbourg]

Hi all,

Could someone answer me ?

Thanks a lot.

Domoticz can't read my location.

This is my parametres in Lua :

local wuAPIkey = "0xxxxxxx719956f9" -- code hide
local latitude = 48.575875
local longitude = 7.731194
local altitude = 141
local city = "Strasbourg"
local countryCode="FR"

Domoticz return : 2016-10-25 11:45:00.228 Error: EventSystem: in C:\Program Files\Domoticz\scripts\lua\script_time_SolarSensor.lua: ...m Files\Domoticz\scripts\lua\script_time_SolarSensor.lua:80: attempt to index local 'jsonLocation' (a nil value)

So I thought that it can't read my datas. I tried in my browser : http://api.wunderground.com/api/0xxxxxx ... bourg.json

That was ok. Return to me :


{
"response": {
"version":"0.1",
"termsofService":"http://www.wunderground.com/weather/api/d/terms.html",
"features": {
"conditions": 1
}
}
, "current_observation": {
"image": {
"url":"http://icons.wxug.com/graphics/wu2/logo_130x80.png",
"title":"Weather Underground",
"link":"http://www.wunderground.com"
},
"display_location": {
"full":"Strasbourg, France",
"city":"Strasbourg",
"state":"67",
"state_name":"France",
"country":"FR",
"country_iso3166":"FR",
"zip":"00000",
"magic":"1",
"wmo":"07190",
"latitude":"48.54999924",
"longitude":"7.63000011",
"elevation":"153.0"

Etc...

So, I add a line in lua to see the data.

local location = config:read('*all')
print (location) <---- This line
config:close()

And the result is :

2016-10-25 11:55:00.885 LUA:

EMPTY !!!

Does anyone could tell me where is my mistake ? Thank you so much in advance.
I'm on the Domoticz windows version (V3.5818)

@rn0

[deennoo]

80 is the line where is the error double check yours and original.

[xces]

I am positively surprised to see that curves are also close. Did you set up the ogimet station and at what is distance between the station and your home ? (because the graphic shows that there wasn't any cloud all the day long...). I am interested to see other graph comparisons in particular of one day when clouds alternate with periods of sun.

The 'station' i used before was 0377, now i use 0370 which is in the same city as where i live.

For the x10 difference : Is your fibaro sensor exposed outside in the sun with the sensor oriented in front of the sky (and not under a porch) ? The professionnals Lux sensors are oriented right to the sky.

No it was under a porch, pointing downwards... Hence probably the difference.

and no, there is no error in the logic to update the value. In your proposal the value will not be updated if it doesn't change (aka no update during the day for the same value). While I only want to not update the value by night to be able to detect sunset and sunrise. It's explained in the script and wiki.

Ok thanx, updated that.

So I suggest you to start learning LUA

Good one, being a PHP,Java and C# developer that should be possible. First attempt is to clean up the script and make sure you don't have to set ANY variables (in lua) but rather as user variables.

For example, you could get the lat/long from the domoticz config by doing this;

Code: Select all

--  TEST CODE
   json = (loadfile "/volume1/@appstore/domoticz/scripts/lua/json.lua")()  -- For Linux
   local configRequest=assert(io.popen('curl "'..domoticzBaseUrl..'/json.htm?type=command&param=getconfig"'))
   local config = configRequest:read('*all')
   configRequest:close()
   local jsonConfig = json:decode(config)
   print(jsonConfig.Latitude)
   print(jsonConfig.Longitude)
   --  TEST CODE

And it would also be possible to get the country and city from that. Idea that i have is not to run that always, but ONLY if the script detected that some user variables are not yet filled for example. Next to that i think that "Sun Azimuth" and "Sun Altitude" could also be variables, right?

[xces]

Ok, so i got a little offended by the mention that i should learn Lua and decided to rewrite the script to MY liking (as in; if you don't want to use this that is fine, but it works for me). This is my first attempt to write Lua, but nevertheless i think the script improved a lot.

script_time_SolarSensor-v1.5.txt

Rename extension to .lua

(18.2 KiB) Downloaded 241 times

Improvements i made on the v1.4 version;

• Almost complete cleanup/refactoring of the script
• Moved the 'run only once every 5 minutes check' upwards so LUA does not have to declare variables etc.
• Added 'setup instructions'
• Moved all 'to be filled in by user' variables from this script towards uservariables; so changes to the script are limited to the JSON lib location (do everything else with variables).
• Changed SolarAzimuth from a 'device' to a 'user variable' (script will generate user variables if these do not yet exist)
• Changed SolarAltitude from a 'device' to a 'user variable' (script will generate user variables if these do not yet exist)
• Commented out variables 'SolarAzimuth' and 'SolarAltitude' (and updates to them) since they are not used.
• More fool proof Octa retreival: the script requests information to ogimet website based on the UTC time. UTC time is calculated based on your local time and timezone. The ogimet website provides data for the next hour after 15 – 20 minutes into the next hour. That’s why some modifications are done to make sure script does not crash when no data is received yet, this also made the octa variable more robust in my tests.

So what you should do is just put this file in your script directory and it should work. The ONLY thing you will probably need to change is the path to the JSON.lua file because i run Domoticz on my Synology (line 43 of the script).

(and off course you need the virtual sensor)

Code: Select all

Virtual sensor LUX : sensor type "Lux", name "<WhatEverYouWant>".  (see below about the name).

Then you'll see this in your Logs:


Basically all you need to do now is follow this instruction and add the URL to your user variables.


Then the next time the script runs (every 5 minutes) it will create some user variables for you.


Then after 5 more minutes (writing this down i am thinking about reducing the wait) the script created all variables it needs for you, but you have to fill in some details. Go to Setup > More options > User variables and fill in the required fields.



The contents of these fields are explained by the next error message in the log (appearing 5 minutes after creation of the variables):



So follow the steps above and your user variables should look like this:


That is it! If you set "SolarSensor-Debug" to 1 you'll see that it works.


And the updated virtual sensor is the proof.

[deennoo]

Great ! Nice way to use info already on system and reduce problème!

[jmleglise]

Hi xces,

Not bad for your first try of LUA I'm impressed ! And I saw you meet our little friend "¶m" in your journey This made me crazy myself in my time.

So, here is my feedback of your great job :
- Almost complete cleanup/refactoring of the script
=> Yep , better.

- Moved all 'to uservariables;
=> You will see in the script of other people that this is a "personal choice". And up to now, mine was to keep the variables into my scripts.

- Changed SolarAzimuth from a 'device' to a 'user variable' (script will generate user variables if these do not yet exist)
- Commented out variables 'SolarAzimuth' and 'SolarAltitude' (and updates to them) since they are not used.
=> I prefer to display this data. Personal choice.
=> And I use Altitude and azimuth to move my blinds according to the sun. So I need these data. My house have a roof in glass with a roller shutter.

- More fool proof Octa retreival:
=> excellent. Thank you !

Why don't you automatically set up the latitude and longitude like you explain in your prewiews post ?

[dutchdevil83]

Hi xces,

i am using your script version but i am getting this error:

EventSystem: in C:\Program Files (x86)\Domoticz\scripts\lua\script_time_SolarSensor-v1.5.lua: ...6)\Domoticz\scripts\lua\script_time_SolarSensor-v1.5.lua:169: attempt to index local 'jsonLocation' (a nil value)

Can you help me out to figure out what i am doing wrong?

[xces]

Not bad for your first try of LUA I'm impressed ! And I saw you meet our little friend "¶m" in your journey This made me crazy myself in my time.

Yeah that is why i moved the &param to the front of the URL query (it is not yet in your scripts by the way)

I prefer to display this data. Personal choice.
=> And I use Altitude and azimuth to move my blinds according to the sun. So I need these data. My house have a roof in glass with a roller shutter.

Nice, can you tell me your triggers, e.g. WHEN do you decide to close them / open them?

Why don't you automatically set up the latitude and longitude like you explain in your prewiews post ?

This could be done, but if i did that i got a lot of 'script has been running for more then 10 seconds' in the Domoticz error logs; so suggestions are welcome here. Also although i was able to get the config AND the results from Google Geolocation service, i could not parse the results (insufficient knowledge on the JSON.Lua and not able to dump the parsed JSON to the logs so i could see what i was doing wrong).

i am using your script version but i am getting this error:
EventSystem: in C:\Program Files (x86)\Domoticz\scripts\lua\script_time_SolarSensor-v1.5.lua: ...6)\Domoticz\scripts\lua\script_time_SolarSensor-v1.5.lua:169: attempt to index local 'jsonLocation' (a nil value)

Did you fill in the user variables SolarSensor-WeatherUndergroundApiKey / SolarSensor-City and SolarSensor-CountryCode variables?

p.s. here is a snippet of today

[jmleglise]

@Xces,

Are you sure that your configuration of ogimet is Good ? Not even a cloud all the day long ? Where do you live ?!?

For Paris/france, this is a common graph :

[xces]

i have no idea i live in Eindhoven the Netherlands. Weather station i am using is from the local airport so it should be fine. I will switch back to 06377 instead of 06370 and see what the difference is.

[dutchdevil83]

i am using your script version but i am getting this error:
EventSystem: in C:\Program Files (x86)\Domoticz\scripts\lua\script_time_SolarSensor-v1.5.lua: ...6)\Domoticz\scripts\lua\script_time_SolarSensor-v1.5.lua:169: attempt to index local 'jsonLocation' (a nil value)

Did you fill in the user variables SolarSensor-WeatherUndergroundApiKey / SolarSensor-City and SolarSensor-CountryCode variables?

I did, otherwise the scripts shows error message right?

SolarSensor-City = `s-Hertogenbosch
SolarSensor-CountryCode = NL

[xces]

You probably need to URL-encode or escape that character. Can you try this?
"%27s-Hertogenbosch"

The URL i tested succesfully was:
http://api.wunderground.com/api/<YOURAP ... bosch.json

[dutchdevil83]

You probably need to URL-encode or escape that character. Can you try this?
"%27s-Hertogenbosch"

The URL i tested succesfully was:
http://api.wunderground.com/api/<YOURAP ... bosch.json

I tried but when i type it in user variable it changes automatically. I set the user variable to "Eindhoven"' to test it but this doesn`t work either...

Can i change some lines in the LUA script to force the location to get my exact location without using the user variables? I am a newbie in LUA script so need some help...

[xces]

Hmm well there is an API call which weatherunderground supports which is this:
https://www.wunderground.com/weather/ap ... /geolookup

We could not only use it to map lat/long to a city and country; but it also gives back the nearest station (and WMOID) if you pass in lat/long like this:
http://api.wunderground.com/api/<KEY>/g ... 95234.json

We could then change the original (current) call in the script to this:
http://api.wunderground.com/api/<KEY>/c ... TION>.json

Which is undocumented, but works!

So for Den Bosch it would become:
http://api.wunderground.com/api/<KEY>/c ... BR196.json

[dutchdevil83]

Thnx, it is working now!

[manu663]

Hello all,

First of all, I would like to thank you all for the awesome work done with that script.
A special thank to Xces which made a fool proof 1.5 version (I was struggling with the previous versions when by checking again this thread I discovered that one!)

I feel a bit ashame to post here my question because I'm a kind of newbie with domoticz (started only 1month ago) and I feel like I set my target a bit too far for this attempt.

So I have installed this script on my raspberry and modified the path to the JSON file.
I've created the associated virtual sensor


Once I had the log file with the "solar sensor error" message I filled all the required data in the user variables.
Later on, I have been more than happy to see the log reflecting all the calculation done :



During the day, the above values in red are higher and the result is realistic with what I see outside.

But the virtual sensor always stay at 0


I' ve ckecked again and again the sensor name, erased it and created a new one unsuccessfully...
The problem clearly come from my side with that bloody dummy sensor.



Can someone can explain me step by step the process to create and associate this virtual sensor pls ?
(Sorry to bring this discussion to a so low level but believe me, before coming here to cry for mom, I've read many pages and instruction with no joy.)

Thank you for your kind help.

Manu

[Toulon7559]

Creation of Virtual Device:
1. Go to tab 'Dashboard' or 'Setup' and next 'Hardware'
2. Look for line 'Dummy' and click field 'Create Virtual Device'
3. Fill-in as required. For type selection look in the first part of the script what is advised: usually 'Custom Sensor' is the choice you want.
A wrong choice may cause later head-scratching ....
4. After 'OK' a message will flash that the device is visible under tab Dashboard/Devices, and (for this script) under tab 'Weather' or 'Miscellaneous' the device will show in a Window with a certain name.

If you want a quick&thorough check of the relation between the IDX, the Window-name and the used Variable, then go to Setup/More options/Events/Show current states, which produces a table of all IDXes and the names of the related Windows/Variables.
An open door, but if misssmatch exists in naming between the script and the above list, then the script will not work as expected, e.g. by Windows refusing to have content and staying red ......

Remark1 Some confusion may have been caused, because you have selected the title "Lux(calculated)" when you created the Dummy-line under 'Hardware' (see the upper screenshot with line 8 which you included in your message), and repeated that same title later for the Dummy which produces a Device and Window. Then it becomes difficult to recognize the difference ....
Remark2 From which tab did you 'cut' the display-lines as seen in the screenshot at the bottom of your message?

[xces]

The bottom one seems to be the virtual sensors, but i agree with Toulon7559.

This is my "Hardware tab" (step 1 from above) notice MY name (Virtual Sensors):


Then follow step 2.