weewx[9954] DEBUG user.interceptor: empty queue

[salguerodejuarros]

Buenas tardes:
Después de intentar durante varias horas encontrar alguna solución en Google sin encontrarla, recurro al foro, para ver si alguién me puede ayudar.
Desde el reinicio de mi Raspberry en esta madrugada, los datos de mi estación no se actualizan.
En /var/log/weewx.log, el error que creo que define lo que quiera que esté pasando es el del asunto, o sea "weewx[9954] DEBUG user.interceptor: empty queue".
¿Alguna idea?

Versión SO = "Raspbian GNU/Linux 10 (buster)"
Modelo = Raspberry Pi 3 Model B Rev 1.2
Python 3.7.3

Gracias anticipadas.

[salguerodejuarros]

Me contesto yo solo:
Después de enredar durante varias horas, no conseguí nada y por eso solicité vuestra ayuda.
Pero...
Esta mañana, después del reinicio de cada día, el software ha vuelto a funcionar.
Naturalmente, ayer detuve y reinicié varias veces el software y reinicié varias veces la Raspberry.
Meigas no hay, pero no sé lo que le ocurría ni por qué se ha arreglado.
Gracias de todos modos, por estar en este foro, donde sé que puedo pedir ayuda.

[salguerodejuarros]

Rectifico:
Para ser más exactos, la Raspberry ha vuelto a recibir datos de la estación sobre la 1:30 de la madrugada y a esa hora no se produjo (que yo sepa) ningún reinicio.
El reinicio diario no lo hago hasta las 5:30.
¿Qué paso???

[salguerodejuarros]

Hoy, desde las 5:30 (hora de reinicio de mi Raspberry), no actualiza los datos.
El mensaje en el log vuelve a ser el de "DEBUG user.interceptor: empty queue"
¿Podrá ser que la estación no emite, por ejemplo, porque la batería se haya agotado?
¿Si fuera ese el caso, como lo puedo comprobar?
He reiniciado varias veces la Raspberry y el "weewx" y persiste el error: empty queue.

[salguerodejuarros]

Buenos días a todos:
Vuelvo a la misma situación que en el mensaje anterior. Hoy, desde el reinicio de mi raspberry, (a la que ayer no le hice absolutamente nada), mi estación devuelve el mensaje de error: user.interceptor; empty queue.
Naturalmente la he reiniciado, o he parado el servicio y todo sigue igual.
Miro en el github del interceptor y no encuentro nada que me ayude.
¿Alguien sabe algo?
Gracias.

[jantoni]

Bueno.....la verdad es que no sé que decir para ayudar......

Y lo digo porque en Meteoclimatic dice que la estación es una Froggit WH3000SE, que si no me confundo es una consola WS2900

Pero en Ecowitt dice que es una GW1000, algo totalmente diferente.

Bueno....al lío.....

1º Si quieres probar si es el driver, debes hacerlo en el modo test del driver. En la documentación del driver te indica como hacerlo.

2º No obstante, no es el driver, porque la estación replica más o menos las misma faltas de datos en ecowitt.net

3º Si es una GW1000 lo lógico sería abandonar el driver interceptor e instalar el driver GW1000. Bueno, ahora le han cambiado el nombre y se llama Ecowitt Gateway Driver

4º No es un problema de batería de la unidad exterior, porque en ecowitt.net también te quedas sin datos de presión, que no depende de los sensores de exterior.

5º No es un problema de Weewx porque este no envía los datos a ecowitt.net

Pero centrándonos en el error de Weewx, faltan datos para valorar.

Podría ser una falta de alimentación de la consola o gateway (ya dirás que es).

Podría ser un problema de direcciones IP en el que entren en conflicto la WS2900 y la GW1000 si las tienes a ambas funcionando de forma simultánea y tiren abajo la red.

Podría ser cualquier cosa, pero falta mucha información al respecto. Por ejemplo, no facilitas información de como tienes configurada la app WSView+ para el envío de datos desde la consola/gateway a Weewx (ese error es conocido por mala configuración del envío de datos con protocolo Ecowitt)

[jantoni]

Pero.....dándole una pensada.....si la consola o gateway no envía datos a ecowitt, tampoco lo hará a weewx

Y si lo que hace es enviar datos en blanco, pues entonces, el fallo de empty queue es lógico, ya que el paquete de datos irá vacio.

Ahora bien, no se me ocurre ningún motivo para que se produzca ese comportamiento, salvo que la gateway o consola se esté volviendo loca.

De todos modos, si quieres pillar el problema, te va a tocar estar comprobando la situación "en directo"

[jantoni]

Por si lo quieres hacer, estas son las instrucciones para ejecutar el driver en modo test

How to run the driver directly

The driver can be run directly for diagnostic purposes.  This can be useful
when setting up the capture pipeline or for determining the sensor identifiers.

For example, to run in sniff mode, looking for acurite bridge sensor data:

PYTHONPATH=bin python bin/user/interceptor.py --device=acurite-bridge --mode=sniff --iface=eth0 --filter="src 192.168.0.4 and dst port 80"

To run in listen mode, looking for LW302 sensor data on port 9000:

PYTHONPATH=bin python bin/user/interceptor.py --device=lw30x --mode=listen --port=9000

Specify help for a full list of options:

PYTHONPATH=bin python bin/user/interceptor.py --help

Yo lo usé hace muchos muchos años, pero en el momento que salió el driver GW1000 lo abandoné porque es un driver muy complejo al recoger miles de posibilidades de configuración diferentes  de mil estaciones diferentes.

[salguerodejuarros]

Gracias jantoni por estar siempre ahí dispuesto a ayudar.
Creo que he descubierto que el problema se produce ocasionalmente y la causa es que, por problemas puntuales con los reinicios de mi router y mis repetidores, (los reinicio todos los días), alguna vez la estación no es capaz de conectarse a la red.
Por eso me sucedía que el problema desaparecía él solo al cabo de unas horas o al día siguiente, o sea, cuando se volvían a reiniciar mis dispositivos de red.
Para comprobarlo, en la última incidencia de este tipo que me ha ocurrido, simplemente he reiniciado el repetidor TP-Link al que se conecta mi estación e inmediatamente ha comenzado a trajinarse todos los datos correctamente.

[jantoni]

Y al final.....

¿Es una WS2900 o una GW1000? 

Que me has dejado con la intriga