Blocco delle stazioni FineOffSet

Introduzione

È noto che le stazioni Fine Offset interrompano periodicamente la comunicazione tramite USB. La console della stazione meteorologica continua a comunicare con i sensori e i dati meteorologici vengono visualizzati correttamente sulla console della stazione meteorologica. Tuttavia, qualsiasi comunicazione tramite USB si interrompe. Poiché il blocco avviene nel firmware della stazione, nessun software meteo è immune. Succede con Weewx, Cumulus, pywws, WView, EasyWeather, ecc.

Jim Easterbrook (autore di pywws) ipotizza che il blocco avvenga quando un computer tenta di comunicare con la stazione mentre la stazione sta leggendo i dati dai sensori (ogni 48 o 60 secondi) o scrivendo nella memoria della console (ad ogni intervallo di archiviazione).

È possibile che il blocco sia dovuto alla configurazione hardware. Alcune persone sperimentano il blocco con determinati computer ma non con altri, alcuni segnalano meno blocchi dopo il passaggio a un hub alimentato o a un cavo USB diverso.

Sembrerebbe essere un problema con le stazioni prodotte dopo il 2010 circa; le stazioni più vecchie sembrano essere immuni. Potrebbe coincidere con un cambiamento nei protocolli di comunicazione radio tra console e sensori.

I blocchi USB sono stati notati per la prima volta nel 2011.

Esempio

Quando si verifica il blocco, vedrai una lacuna nei dati meteorologici. Nel registro di Weewx vedrai messaggi come questo:

Jun  7 21:50:33 localhost weewx[2460]: fousb: get archive interval failed 
attempt 1 of 3: could not detach kernel driver from interface 0: No data available

Il messaggio "could not detach kernel driver from interface ... No data available" è il segno di un blocco.

Come risolvere

L'unico modo per riprendere il funzionamento regolare è spegnere e riaccendere la stazione. Ciò significa rimuovere le batterie, scollegare la connessione USB, quindi reinstallare le batterie e ricollegare l'USB.

Non è necessario riavviare Weewx.

Poiché la stazione riceve alimentazione da USB, la rimozione delle batterie senza scollegare l'USB non spegnerà e riaccenderà la stazione.

Soluzioni alternative per il funzionamento non presidiato

Ovviamente questo bug del firmware rende le stazioni FineOffset inadatte al funzionamento non presidiato. Tuttavia, esistono alcune soluzioni alternative:

Usare le impostazioni corrette

Le impostazioni migliori per una stazione Fine Offset che utilizza Weewx 2.6.x e versioni precedenti sono:

[FineOffsetUSB]
    polling_mode = PERIODIC
    polling_interval = 60
[StdArchive]
    archive_interval = 300
    record_generation = software

Inoltre, imposta l'intervallo di archiviazione della stazione su 5 minuti (300 secondi):

sudo wee_device --set-interval=5

Queste impostazioni non sono una garanzia contro i blocchi, ma ne ridurranno la possibilità.

Con weewx 2.6.x e versioni precedenti, l'utilizzo di polling_mode = ADAPTIVE o record_generation = hardware aumenterà la possibilità di un blocco.

Usare un hub commutato

Collegare la stazione, senza batterie, a un hub USB con commutazione per porta. Quando viene rilevato un blocco, spegne e riaccende la stazione spegnendo/accendendo l'alimentazione nell'hub USB.

Questa funzionalità è inclusa nel driver fousb.py in Weewx a partire da r2225 o Weewx 2.6.4. Quando rileva un blocco, comunica all'hub USB di spegnere e riaccendere la stazione.

Per abilitare questa funzione, aggiungi quanto segue a weewx.conf:

[FineOffsetUSB]
    power_cycle_hub = 001:016
    power_cycle_port = 1

power_cycle_port indica la porta a cui è collegata la stazione. Su un hub a quattro porte questo sarà 1, 2, 3 o 4. Si noti che il numero di porta potrebbe non essere lo stesso del numero di socket. Questo è un problema noto con il DUB-H7. Dovrai sperimentare per trovare il numero di porta giusto.

power_cycle_hub identifica in modo univoco l'hub a cui è collegata la stazione. Ha il formato XXX:YYY dove XXX è il bus e YYY è il dispositivo, ad esempio 001:016. Usa lsusb per determinare questi numeri. Ad esempio, nel seguente output, il Linksys USB2HUB4 si trova a 001:016:

% lsusb
Bus 001 Device 026: ID 1941:8021 Dream Link WH1080 Weather Station / USB Missile Launcher
Bus 001 Device 021: ID 0557:2008 ATEN International Co., Ltd UC-232A Serial Port [pl2303]
Bus 001 Device 019: ID 1130:6801 Tenx Technology, Inc. 
Bus 001 Device 016: ID 0409:0058 NEC Corp. HighSpeed Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Fai attenzione che molti hub potrebbero affermare di supportare la commutazione dell'alimentazione per porta quando, in realtà, non lo fanno. Ciò è spesso dovuto al fatto che il chip del controller supporta la commutazione per porta, ma il produttore dell'hub USB non ha collegato i pin che forniscono effettivamente l'alimentazione.

Usa uno strumento come usb_control.py per vedere se un hub funziona davvero.

http://lancet.mit.edu/mwall/projects/weather/releases/usb_control-0.6.py

Ad esempio, questo spegnerà l'indicatore luminoso per la porta 3:

sudo ./usb_control.py --hub 001:016 --port 3 --indicator 0

Questo disattiverà l'alimentazione per la porta 3:

sudo ./usb_control.py --hub 001:016 --port 3 --power 0

Hub noti per funzionare:

  • LINKSYS USB2HUB4 (Hub ad alta velocità NEC Corp.)
  • D-Link Corp. DUB-H7 Hub USB 2.0 a 7 porte (versione precedente grigio/argento)
  • D-Link Corp. DUB-H4 Hub USB 2.0 a 4 porte (ver. H/W: D1)

Hub noti per non funzionare:

  • Hub USB a 7 porte rosewill (TERMINUS TECHNOLOGY INC.)
  • Hub USB a 12 porte satechi (TERMINUS TECHNOLOGY INC.)
  • Hub USB ceruleo a 7 porte (Genesys Logic, Inc. USB-2.0 HUB a 4 porte)
  • D-Link DUB-H7BL Hub USB 2.0 a 7 porte (Action Star Enterprise Co., Ltd. nuova versione nera)
  • Hub USB 2.0 D-Link DUB-H4 (Hub USB 2.0 Genesys Logic, Inc., eccetto versione HW D1)

Un altro approccio, un po' più brutale

NdA: Ho costruito un timer watchdog (fondamentalmente un 555 bistabile con un transistor short-me-out che viene espulso ogni tanto da un GPIO sul Pi. Posso fornire il circuito e i file Gerber per un PCB a chiunque sia interessato. Il periodo watchdog è di circa 5-10 minuti che dà al sistema il tempo di avviarsi.

Non ho batterie nel modulo sensore - fallo funzionare a 3V. Fondamentalmente alimento il tutto da un adattatore 12 V che si imbatte in due buckies: uno che dà 5 V e l'altro 3 V. Quindi, quando ciclo il 12V, ciclo tutto.

Non sarebbe poi così difficile fare in modo che il watchdog cicli solo il WS invece di tutto.

Comunque funziona tutto con un paio di programmi relativamente semplici - lanciati all'avvio:

pat-wdog.py attiva un pin GPIO ogni paio di minuti per ripristinare il watchdog.

e uno script di shell...

while True tail /var/log/syslog > logf read-the-log.py che cerca il messaggio "I have gone" e se lo trova esegue os.system ('sudo shutdown -h now'), spegne il Raspberry in modo regolare pochi minuti dopo il watchdog spegne e riaccende l'alimentazione. Non preoccuparti di interrompere qualcosa come la scrittura della scheda SD ecc. Perché il Raspberry è in standby per 120 secondi

Attenzione ai ripristini di fabbrica casuali

Alcune console ripristinano in modo casuale alcune o tutte le loro impostazioni ai valori predefiniti di fabbrica. Sembra che accada quando la console viene spenta e riaccesa, ma non accade sempre e in tutte le console. Quando ciò accade, l'intervallo di archiviazione della stazione cambierà in 1800 secondi (30 minuti). Vedrai messaggi di registro come questo:

wxengine: The archive interval in the configuration file (300) does not match the station hardware interval (1800).

Utilizzare wee_device per modificare l'intervallo di archiviazione della stazione in modo che corrisponda a quanto specificato in weewx.conf.

Riferimenti

Discussione al forum Cumulus sugli effetti della potenza/tensione:

http://sandaysoft.com/forum/viewtopic.php?f=16&t=10510

Descrizione del problema nel forum di Cumulus:

http://sandaysoft.com/forum/viewtopic.php?f=13&t=8870

Autore: Matthew Wall