hi Wolfgang,
the behavior is exactly the same as reported in this thread: 
indilib.org/forum/ekos/10807-scheduler-w...ck-policy.html#78185
In this case it's a different mount (CEM70) so it's not likely a 10micron driver issue.
But I can build and debug the 10 micron driver if needed.
​​​​​​ bestFerrante

Read More...

I found the same issue some time ago and reported here:
indilib.org/forum/mounts/10549-10micron-...-or-indi-driver.html
As to his answer, Wolfgang is looking into it. Hope that will be fixed in the next release.
In the meantime I added a magnetic sensor to the mount and connected it to the roof circuit so that it stops the roof if the mount is not parked.

Ferrante

Read More...

hi Andres,
I had to configure a roof with dome scripting gateway some weeks ago and ran in similar issues.
Did you set the folder containing the scripts as relative path? try to enter the full path.
And if you have any includes in the script itself, check the paths.
Check if it's not executed as a python2 script .

ferrante

Read More...

Hi Wolgang,
issuing the Park command from the Mount Tab works as expected:
From Mount Tab:2021-10-16T09:07:21: [INFO] Mount is parked. 
2021-10-16T09:07:21: [INFO] Gstat changed from 2 to 5 
2021-10-16T09:07:13: [INFO] Gstat changed from 0 to 2 
2021-10-16T09:07:12: [INFO] Parking. From parking to parked is 9 secs only because the mount was close to parking position.
With the same configuration I checked from the Scheduler:

2021-10-16T11:20:27 Dome parking failed. Restarting operation...
2021-10-16T11:19:54 Parking dome...
2021-10-16T11:19:53 Mount parked.
2021-10-16T11:19:52 Parking mount in progress...
2021-10-16T11:19:51 Cap parked.
2021-10-16T11:19:49 Parking Cap...
2021-10-16T11:19:48 Warming up CCD...
2021-10-16T11:19:48 No jobs left in the scheduler queue.
2021-10-16T11:19:47 Job 'NGC 4960' is complete.
2021-10-16T11:19:38 Job 'NGC 4960' capture is in progress...
2021-10-16T11:19:38 Job 'NGC 4960' slew is complete.
2021-10-16T11:19:37 Job 'NGC 4960' is slewing to target.
2021-10-16T11:19:36 Mount unparked.
2021-10-16T11:19:32 INDI devices connected.
2021-10-16T11:19:29 Scheduler started.
2021-10-16T11:19:29 Scheduler is awake.

The parking distance was the same as the previous test. But here the Parked status is immediately after the Parking command.
(the 2hrs time offset between the 2 tests is due to the mount working in UTC and Ekos using local time)

Thanks
Ferrante

Read More...

: I found that when using the scheduler shutdown procedure to park the mount, the mount switches to 'parked' status as soon as it gets moving. I mean, it doesn't wait to be actually parked; that's quite dangerous as you have the roof start closing before the mount is in parking position.Scheduler log:At 16:59:46 the park command is issued and just 1 sec after (16:59:47) the mount is in 'parked' status (while it was still moving). Btw the 16:59:47 'Mount parked' message is not just an info message because the roof is allowed to move.Further tests don't show the same behavior:1- If keeping the same configuration but the 10Micron driver is switched to Telescope Simulator: the mount 'parked' status is correctly shown when the mount actually is parked.2- If the 'park' command is issued by the INDI driver (10Micron_lx200) interface tab, 10Micron driver log:Also here the 15:01:11 'Mount is parked' is shown only when the mount is physically parked (ok only 4 secs later, but was quite close to parking position in this test).I'm not sure if it's a 10Micron INDI driver issue as suggested by test 1 because switching to a different driver solves. Or a Kstars Scheduler issue as test 2 would suggest because two different Kstars tabs show different behaviour using the same driver.Tested on Kstars 3.5.4 / indi 1.9.2Ferrante

PS: Originally posted on invent.kde.org/education/kstars/-/issues/136 but can be relevant for this forum too.
 

Read More...

After a while I'm testing again the Dome Scripting Gateway to control a roll off roof.
I've been adding all the python scripts to manage the roof (open.py, close.py, status.py etc) and tested the script by executing them from shell.
But Ekos doesn't read the status and doesn't execute any further command.
From the log (see below)  it seems to fail to read a tmp file indi_dome_script_status_PKfoTu that was not needed in previous version of the driver. All the information were stored in /tmp/indi-status.
Moreover I don't understand the python errors. Python is installed and working fine on my system.

Does anyone have a suggestion how to fix this?
Thanks
Ferrante

LOG:
[2021-09-28T12:22:39.395 CEST DEBG ][           org.kde.kstars.indi] - Dome Scripting Gateway : "[DEBUG] execvp('/home/ferrante/scripts/status.py', 'status.py', '/tmp/indi_dome_script_status_PKfoTu', nullptr) "
[2021-09-28T12:22:39.397 CEST DEBG ][           org.kde.kstars.indi] - INDI Server:  "2021-09-28T10:22:39: Driver indi_script_dome: /home/ferrante/scripts/status.py: 10: import: not found"
[2021-09-28T12:22:39.397 CEST DEBG ][           org.kde.kstars.indi] - INDI Server:  "2021-09-28T10:22:39: Driver indi_script_dome: /home/ferrante/scripts/status.py: 12: sys.argv[1]: not found"
[2021-09-28T12:22:39.397 CEST DEBG ][           org.kde.kstars.indi] - INDI Server:  ""
[2021-09-28T12:22:39.397 CEST DEBG ][           org.kde.kstars.indi] - INDI Server:  "2021-09-28T10:22:39: Driver indi_script_dome: /home/ferrante/scripts/status.py: 13: path: not found"
[2021-09-28T12:22:39.397 CEST DEBG ][           org.kde.kstars.indi] - INDI Server:  "2021-09-28T10:22:39: Driver indi_script_dome: /home/ferrante/scripts/status.py: 15: Syntax error: \"(\" unexpected"
[2021-09-28T12:22:39.397 CEST DEBG ][           org.kde.kstars.indi] - INDI Server:  ""
[2021-09-28T12:22:39.398 CEST DEBG ][           org.kde.kstars.indi] - Dome Scripting Gateway : "[DEBUG] Script status.py returned 512 "
[2021-09-28T12:22:39.399 CEST INFO ][           org.kde.kstars.indi] - Dome Scripting Gateway :  "[ERROR] Failed to read status "
 

Read More...

hi Frank,
the Analyze module (www.indilib.org/forum/general/7597-new-k...e-analyze.html#58946) already writes all those data to a log file. Moreover it allows to load the log and analyze the session afterwards.

Else, there's a python script i wrote some times ago that reads data from fits headers and writes to a SQLite database: github.com/fenriques/AstroDomIt's not a .txt file but you can easily adapt the script 

Ferrante
 

Read More...

weird: just copied and pasted your script, chmod it and it works fine.

But I found another thread where a refresh issue was mentioned:
indilib.org/forum/general/9699-is-weathe...r-working.html#71436

 

Read More...

I just tested weatherwatcher with online data and it works. Please, try the following configuration:
 



The 'file' is: aagsolo.lunatico.es:10800/cgi-bin/cgiLastData  provided by Lunatico itself, data are regularly refreshed.
Then 'set' on both fields, 'save' and restart Kstars.
You should see something like:
I just tested weatherwatcher with online data and it works. Please, try the following configuration:
 

The 'file' is: aagsolo.lunatico.es:10800/cgi-bin/cgiLastData  provided by Lunatico itself, data are regularly refreshed.
Then 'set' on both fields, 'save' and restart Kstars.
You should see something like:
  

This should work for you too. Then move step by step to your target configuration.
Btw I see all data in Weather tab too:
I just tested weatherwatcher with online data and it works. Please, try the following configuration:
 

The 'file' is: aagsolo.lunatico.es:10800/cgi-bin/cgiLastData  provided by Lunatico itself, data are regularly refreshed.
Then 'set' on both fields, 'save' and restart Kstars.
You should see something like:
I just tested weatherwatcher with online data and it works. Please, try the following configuration:
 

The 'file' is: aagsolo.lunatico.es:10800/cgi-bin/cgiLastData  provided by Lunatico itself, data are regularly refreshed.
Then 'set' on both fields, 'save' and restart Kstars.
You should see something like:


This should work for you too. Then move step by step to your target configuration.

Btw I see all data in Weather tab too. well, not the chart but the values:


Read More...