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
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.