dzVents version of the Solar Data Script [SOLVED]

[BakSeeDaa]

Seems to work. Need to let it run a few times

Edit: Spoke too soon:

2017-09-04 20:21:00.655 Error: dzVents: Error: SOLAR 2.0.4: An error occured when calling event handler Solar Data
2017-09-04 20:21:00.655 Error: dzVents: Error: SOLAR 2.0.4: ...icz/var/scripts/dzVents/generated_scripts/Solar Data.lua:142: attempt to call a nil value

It's hard for me to say what's the problem because I have very little information to go on.

• If You look at the code, what does line 142 look like?
• Do you have a file named DOMODIR/scripts/lua/JSON.lua ? (Where DOMODIR is the directory where Domoticz is installed on your machine)
• If you activate logging for the script (level = domoticz.LOG_DEBUG), do you see any more related information when the error happens?

Thanks!

[BakSeeDaa]

I'm actually still thinking it's not necessary to fetch the Ogimet Data more than once an hour.

The single piece of information that we need from that request is the Okta value. All other information is discarded. While the query may produce different results for a single hour the Okta value seems to remain the same during the whole hour.

From what I've seen so far, every change of Okta occurs when the hour shifts. I believe is that the Okta value will remain the same during an whole hour. (All hours with a number of 10 will have 8 in my example)

I'm currently debugging to see if I ever get 2 different Okta values for a single hour. I'd need some help testing this for more locations.

Looking for someone/a few persons willing to test this. It's easy.

Before:

Code: Select all

			local rslt = split(synopCode,',')

Insert:

Code: Select all

			-- TEMPORARY LOGGING OF OKTA FOR ANALYSIS
			local myOkta = string.sub(split(split(synopCode, ',')[7], ' ')[5], 1, 1)
			local logDebug = os.date("%H:%M", os.time())..' '..split(synopCode, ',')[5]..' '.. myOkta
			os.execute('echo '..logDebug..' >>'..tmpLogFile)

Now, logging will occur to a file that you've set in your config (e.g. tmpLogFile = 'tmp/logSun.txt')
That file will look something like:

Code: Select all

pi@raspberrypi:/tmp $ sudo cat logSun.txt
12:21 09 7
12:26 10 8 
12:31 10 8 
12:36 10 8

The first column is the time stamp when the request to the Ogimet server is made. The second column is the UTC hour for the data that is returned. The third column is the Okta value. Please let me know the results if you help me testing.

[bimse]

I am on test carriage and will show the results tomorrow

[BakSeeDaa]

I am on test carriage and will show the results tomorrow

Thank you. I appreciate that a lot!

[EdwinK]

Seems to work. Need to let it run a few times

Edit: Spoke too soon:

2017-09-04 20:21:00.655 Error: dzVents: Error: SOLAR 2.0.4: An error occured when calling event handler Solar Data
2017-09-04 20:21:00.655 Error: dzVents: Error: SOLAR 2.0.4: ...icz/var/scripts/dzVents/generated_scripts/Solar Data.lua:142: attempt to call a nil value

It's hard for me to say what's the problem because I have very little information to go on.

• If You look at the code, what does line 142 look like?
• Do you have a file named DOMODIR/scripts/lua/JSON.lua ? (Where DOMODIR is the directory where Domoticz is installed on your machine)
• If you activate logging for the script (level = domoticz.LOG_DEBUG), do you see any more related information when the error happens?

Thanks!

This is line 142

Code: Select all

				local JSON = (loadfile './scripts/lua/JSON.lua')() -- For Linux

I've got logging enabled, but can't find the log file. JSON.lua is locate in root@DiskStation:/volume3/@appstore/domoticz/var/scripts/lua#

I think parts of this need to be rewritten for Synology use.

[BakSeeDaa]

This is line 142

Code: Select all

				local JSON = (loadfile './scripts/lua/JSON.lua')() -- For Linux

I've got logging enabled, but can't find the log file. JSON.lua is locate in root@DiskStation:/volume3/@appstore/domoticz/var/scripts/lua#

I think parts of this need to be rewritten for Synology use.

It's using the Domoticz logging. Setup>-LOG.

We now know what the problem is. You need to tell the script where to find the JSON file.

Code: Select all

				local JSON = (loadfile './scripts/lua/JSON.lua')() -- For Linux

Is obviously wrong. Synology seems to have a different "working directory" than Raspberry pi. Never mind we can solve that too.

So what if you try

Code: Select all

				local JSON = (loadfile '/volume3/@appstore/domoticz/var/scripts/lua/JSON.lua')() -- For Synology

Is that working?

[EdwinK]

Have been lookng at all the wrong places ..

Seems to be working, for real now

017-09-05 19:04:00.475 dzVents: Info: SOLAR 2.0.4: ------ Start internal script: Solar Data:, trigger: every minute
2017-09-05 19:04:00.551 dzVents: Info: SOLAR 2.0.4: ------ Finished Solar Data
2017-09-05 19:04:46.744 User: Admin initiated a switch command (201/Telefoon Edwin/On)
2017-09-05 19:05:00.414 dzVents: Info: SOLAR 2.0.4: ------ Start internal script: Solar Data:, trigger: every minute
2017-09-05 19:05:00.415 dzVents: Info: SOLAR 2.0.4: Calling Wunderground API using URL: http://api.wunderground.com/api/17318c1 ... Rhoon.json
2017-09-05 19:05:00.423 dzVents: Info: SOLAR 2.0.4: Get synopCode message from Ogimet web site using URL: http://www.ogimet.com/cgi-bin/getsynop? ... 1709051600
2017-09-05 19:05:00.561 dzVents: Info: SOLAR 2.0.4: ------ Finished Solar Data
2017-09-05 19:06:00.451 dzVents: Info: SOLAR 2.0.4: ------ Start internal script: Solar Data:, trigger: every minute
2017-09-05 19:06:00.512 dzVents: Info: SOLAR 2.0.4: Wunderground API json data file has been read
2017-09-05 19:06:00.525 dzVents: Info: SOLAR 2.0.4:
2017-09-05 19:06:00.525 dzVents: Info: SOLAR 2.0.4: ============== SUN LOG ==================
2017-09-05 19:06:00.525 dzVents: Info: SOLAR 2.0.4: Rhoon, latitude: 51.851585, longitude: 4.421574
2017-09-05 19:06:00.525 dzVents: Info: SOLAR 2.0.4: WU Location WMO = 06343
2017-09-05 19:06:00.525 dzVents: Info: SOLAR 2.0.4: Altitude of the sun = 10.896208359867°
2017-09-05 19:06:00.525 dzVents: Info: SOLAR 2.0.4: Azimuth of the sun = 267.03586491812°
2017-09-05 19:06:00.526 dzVents: Info: SOLAR 2.0.4:
2017-09-05 19:06:00.526 dzVents: Info: SOLAR 2.0.4: Ogimet data file has been read
2017-09-05 19:06:00.527 dzVents: Info: SOLAR 2.0.4: SYNOP Station = 06340
2017-09-05 19:06:00.527 dzVents: Info: SOLAR 2.0.4: Okta = 8
2017-09-05 19:06:00.527 dzVents: Info: SOLAR 2.0.4: Direct Radiation = 18 W/m²
2017-09-05 19:06:00.527 dzVents: Info: SOLAR 2.0.4: Total weighted lux = 2576.24 Lux
2017-09-05 19:06:00.632 dzVents: Info: SOLAR 2.0.4: ------ Finished Solar Data

[BakSeeDaa]

Have been lookng at all the wrong places ..

Seems to be working, for real now

I'm happy to hear that!

[EddyG]

OKTA debug code is in place. I will let you know.

[bimse]

here are my opsavations at station WMOID = '06135'
Thank you for your work with a useful version.
I only use the Lux section.

[BakSeeDaa]

here are my opsavations at station WMOID = '06135'
Thank you for your work with a useful version.
I only use the Lux section.

Thanks a lot!

I believe you should use another WMOID because that station reports "/" which means it has no information about the cloud layer to report. (It has been reporting in the past, but not the latest days)

[EddyG]

Below my logging from WMOID = '06260'
I also use only the Lux data.
I leave it running, because we got a lot of clouds these days.

SolarSensor.txt

(1.76 KiB) Downloaded 107 times

It looks to me that the reporting is not on the hour.

[BakSeeDaa]

Below my logging from WMOID = '06260'
I also use only the Lux data.
I leave it running, because we got a lot of clouds these days.
SolarSensor.txt
It looks to me that the reporting is not on the hour.

Thanks! Your file clearly demonstrates that a change of Okta only occurs at the change of hour.

[EddyG]

I cannot explain the time 02:21 and 03:26, can you? (65 min.)
It might be a change on UTC hour but not on the real time.

[bimse]

BakKeDal, now I have found a station with cloud information. Thanks for the help.
Is it possible to integration a check of this without having to insert your little program.

[BakSeeDaa]

BakKeDal, now I have found a station with cloud information. Thanks for the help.
Is it possible to integration a check of this without having to insert your little program.

Great!

Yeah, I can put a warning in the log if there has been no cloud information data for some time.

[BakSeeDaa]

Version 2.0.6 is released.

Please read the Change Log and Release Notices.

[Bishop]

Version 2.0.6 is released.

Please read the Change Log and Release Notices.

Thankyou for all your work, it's appreciated!

[EdwinK]

Thanks Working like a charm

[EddyG]

Perfect, 2.0.6 is running. Tnx.
I wonder if this data could be incorporated in the script to get a better fine tuning of the graph?
8NCCC -- Cloud type information
Especially the: N -- Amount of low clouds covering sky, if no low clouds, the amount of the middle clouds
This might be used to get a float for Octa.
This SYNOP information comes from http://weather.unisys.com/wxp/Appendice ... SYNOP.html
And my station 06260 supports this.