Open angelagonzalez opened 10 years ago
He comprobado los logs de esas dos noches y al RTI llegaron las peticiones de interrupción correctamente, éste las mandó a RTS2 pero RTS2 siempre contestaba: "system not in ON state, and ignore_day in EXECutor is not set - not changing the target". Es decir, el sistema no estaba encendido (hecho coherente con la cúpula cerrada) y por tanto el target de gloria no puede entrar.
Jan me acaba de confirmar que hubo mal tiempo los dos días.
Sí, pero según tengo entendido, en este caso no debería mostrarse la llave inglesa al usuario y "problema en telescopio", sino la alerta de mal tiempo en la flecha naranja de la derecha.
Según comenta Jan, cuando el mal tiempo se produce desde el principio de la noche, no conectan el sistema. Se puede implementar que devuelva la razón por la que no está conectado. Actualmente cuando esto ocurre el mensaje devuelto es "problema en telescopio". Habría que cambiarlo por algo del tipo "Telescopio no operativo por mal tiempo".
Al parecer, no es un tema de RTI sino de una capa de más alto nivel. Por favor Mari Carmen, ¿puedes confirmarlo y asignarlo a quien corresponda? Gracias.
NOTA: esta issue es importante, los usuarios nos han dado dos 1 sobre 10 a causa de esto (porque creen que el telescopio falla).
Why don't we start from the basis: create a database table (somewhere) where every 5 minutes the status parameters of "all" telescopes are collected. The interface only needs to read from it and add the appropriate info next to each telescope. If the information are old, then a warning is added. What does not make sense in this? I am speaking about the ABC of a "network". What I see is instead a "collection" of devices each one independent from the others. Of course this could be a task of the scheduler, that must be able also to recognise/flag interactive telescopes. But still I do not see the point of starting an independent process for each single process. We want to manage a network and therefore we must reason keeping this always in mind, also for interactive telescopes. As I said, each telescope listed needs an informational tab where (as minimum) there must be: status, local-time, weather. Of course also the "famous" telescope+instrument info should be visible on request. And these are also supposed to be stored in database tables. When will this DB be setup?
El RTI solo sabe que no ha podido entrar, no el motivo. Entiendo que la modificación del mensaje teniendo en cuenta el estado del tiempo es de Fernando.
Asigno la issue a Fernando.
Esta incidencia continúa junto con ésta: https://github.com/GLORIA-project/reservations-interface/issues/20
Cuando en la página de reservas pendientes se muestra que el tiempo es CLEAR, significa que justo tras hacer click en la reserva ningún dispositivo meteorológico estaba en alarma. Si uno de ellos lo está, el texto que se muestra es ALARM. La única forma que tiene GLORIA de saber cómo está el tiempo atmosférico en el telescopio es preguntando al RTI. Esto por un lado.
Por otro lado, y de forma independiente a la lectura del estado del tiempo, cuando hay una reserva y se intenta interrumpir al RTI para la teleoperación, podemos recibir dos respuestas: sí o no. Si es que no (llavecita inglesa), puede ser por N cosas diferentes (una de las tareas que tenemos es analizar el texto y mostrar un mensaje más adeacuado), siendo una de ellas la alarma por mal tiempo (supongo).
Si el escenario es que el RTI dice que no hay alarma (CLEAR) y a la vez no te deja entrar por un supuesto mal tiempo, lo que percibe el usuario es un mal funcionamiento. Se le muestra CLEAR y la llavecita.
Lo coherente es que si hay mal tiempo salga la llavecita (contexto de experimento en error) y el panel del estado actual informe del mal tiempo. Toda esta información es proporcionada por los RTI.
Lo que nos preguntamos es si puede ser que lo que ocurriese es que Jan desconectase el ejecutor manualmente porque le pareció que hacía mal tiempo o en previsión de, pero los sensores dijesen lo contrario. Ahora mismo no se nos ocurre otra razón lógica, pero lo que creemos que está claro es que el problema está en el contexto del RTS2 con el RTI.
Hola Fernando, es correcto todo lo que comentas. Mª Carmen está trabajando en ello, pero esto no es prioritario para la futura rueda de prensa. Un saludo.
Esta incidencia está relacionada con ésta: https://github.com/GLORIA-project/gloria-soap/issues/8
I summarize here the current messages shown to users when there is a problem accessing the telescope due to BAD WEATHER:
I will complete this list with other telescopes and reasons to be down as they occur.
BOOTES-2 estuvo cerrado por mal tiempo el 01-07-2014 en la reserva de las 21:30 UT y 21:45 UT y mostró CORRECTAMENTE el estado climatológico del telescopio: Montura PARKED Cúpula CLOSED Tiempo ALARM. (La alarma probablemente se debía a nubes).
Posteriormente la cúpula se abrió ( a las 22:15 UT estaba abierta), probablemente porque se despejaron las nubes, y funcionó correctamente.
Hoy (02-07-2014 21UT) D50 y BART están cerrados por mal tiempo (se ve en su web). Pero en ambos se muestra: Montura PARKED Cúpula CLOSED Tiempo CLEAR
En D50 suele mostrar correctamente el estado del tiempo como ALARM, salvo cuando se sabe con antelación que va a hacer mal tiempo, y los operadores de los telescopios desconectan el sistema y al parecer se pierde la comunicación con RTI. El operador de estos telescopios propuso crear una propiedad para que RTI detecte esto.
No se pudo entrar a BART ni el 4 ni el 5 de Junio.
El día 5 hacía mal tiempo y la cúpula estaba cerrada, pero aun así, aparecía la llave inglesa roja y "problema en telescopio", en la parte de la izquierda de la lista de reservas, en lugar de aparecer en la derecha la alerta por mal tiempo.
Esto hace pensar que el motivo de no acceder a la reserva puede no tener nada que ver con el mal tiempo.
Por favor, que se compruebe. Gracias.