Software > WeeWX

weewx[9954] DEBUG user.interceptor: empty queue

<< < (2/2)

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


--- Citar ---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
--- Fin de la cita ---

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

Navegación

[0] Índice de Mensajes

[*] Página Anterior

Ir a la versión completa