weird: just copied and pasted your script, chmod it and it works fine.
But I found another thread where a refresh issue was mentioned:
I just tested weatherwatcher with online data and it works. Please, try the following configuration:
you're right, the data I posted (and the man page I wrote) refers to the standard output of the AAG Solo weather station, while on the other hand, Ekos needs the parameters you listed.
The driver is quite flexible though: you can feed in the Ekos parameters any key/value coming from any weather station. For example you can feed 'rain' into 'temperature' (just doesn't make sense).
My suggestion was to put at first numeric value only: no 'forecast= Stormy, much rain' as it could break the parser.
A further example of this 'flexibility': my weather station doesn't provide forecast values, so I feed in the 'forecast' (ekos side) the 'safe' (0|1) key/value from my weather station and set thresholds accordingly. Thus when the weather is unsafe it triggers obs shutdown.
I do not know which among all parameters the 'Weather' (in the weather tab) is linked to. It could be 'forecast'.
the graphic tab doesn't refresh; but the values in the WeatherWatcher driver main tab are regularly updated?
if this is the case I would say is an issue of communication between the driver and the weather tab else it is the driver that fails reading the data from file.
To rule out any data format issue, can you try using the exact format provided in the driver manual (e.g. safe as numeric)?
If this doesn't help, sending the log file could help to understand the cause.
in my experience it depends on network latency and bandwidth. If you separate the client from the server on different PCs, then all communication has to go through the network.
So, when guiding, all pulses travel back and forth and tracking could be affected by high latency; when focusing all images have to be send to the client consuming bandwidth etc.
If it's a LAN or a fast internet connection first option could work just fine.
In a remote location where only satellite network works the only way is connecting through a remote session on a local computer.
I switched from first option to the second when I moved my telescope from a 100Mb/s observatory to a remote one where connection speed (shared!) is 3Mb/s at best.
If the roof controller is a custom one, you will have to write your own indi driver to manage it from ekos. As an alternative I suggest to use the Dome scripting gateway driver that only requires custom scripts (in any language) as interface to the dome.
Sometime you'll have to restart all devices if needed. Have you considered power hubs like Pegasus upb, ip controlled plug (eg EZoutlet) or observatory controllers like Lunatico Dragonfly?
Given the equipment you listed I would say you are already an experienced remote user but just a couple of question to better focus any advice or tip.
By remote you mean the equipment is located in your backyard and managed from inside your house or the telescope is hosted in some remote farm?
Is your observatory already remote and you are migrating to INDI/Ekos or is the very first time managing a telescope from remote?
(if your message was referring to my post)
really like this new feature.
The terrain fits perfectly into the stellarium view, it feels almost real.
Thank you Hy!
As of today Ekos calculates HFR, Eccentricity, Mean background value and number of stars for each frame but these values are not saved in the fits header.
Having such information stored in the fits file itself is useful for frame selection, benchmarking and processing.
I wrote a simple python command line script that parses the .analyze log file, where these keywords are stored and save them to the matching fits file.
It is hosted on github: github.com/fenriques/astro_tools
Just download the fits_header_import.py file and launch it from a terminal window: python fits_header_import.py
Tested on Linux only, Win/Mac could have directory path issues.
As soon as Ekos will write these keywords directly into fits files, this script will be useless.
Please send feedback if you test it.
Glad to hear that it works.
There's a locking safety switch in Telescope and Dome Tabs:
In Telescope Tab-> Options->Dome locks: This prevents the mount from unparking when dome is parked.
And in Dome Tab->Options->Mount locks: This prevents the dome from parking when mount is unparked.
In my remote hosting facility they provided a device for additional security: two magnet switches fixed on the RA of the mount and connected directly to the roof hardware controller.
In park position the switches close a circuit so that there's a physical check on the mount position and not just rely on software controls. More or less the same as the laser trigger you're thinking of.
Rain / bad weather. You need to connect your rain gauge or meteo station to Ekos through an INDI driver and set safety conditions.
Then Ekos itself manages shutdown (park mount, park dome etc) if weather is not safe.
To connect your device to Ekos you can think of using a standard INDI driver or write your own.
If your rain gauge can output a text file via LAN or Serial port to your Ekos PC, as a first approach I suggest Weather Watcher driver that just need such a text file with proper information.