Risoluzione problemi delle stazioni Davis
Stabilire la connettività
Se non sei in grado di ottenere dati da Weewx, controlla prima di avere la connettività alla tua stazione meteorologica. Per le stazioni Davis, puoi utilizzare un terminale per eseguire un semplice test. Impostalo per comunicare utilizzando la porta e il baudrate appropriati. NdA: mi piace minicom perché può essere eseguito tramite una semplice connessione TTY. Anche l'utilità screen funziona bene. Per esempio:
minicom -b 19200 -D /dev/ttyUSB0
oppure, utilizzando screen:
screen /dev/ttyUSB0 19200
Per prima cosa, premi Invio alcune volte, per riattivare la console. Quindi digita TEST, tutto in maiuscolo. I caratteri non verranno riecheggiati. Quindi premi Invio ancora una volta. La Davis dovrebbe mostrare TEST.
Se funziona, allora hai stabilito la connessione con la Davis e il problema deve risiedere altrove.
Problemi al convertitore Davis CP2101
È noto che il convertitore USB utilizzato nel Davis VantagePro presenta alcuni problemi di "rumore". Il sintomo è che il kernel Linux si disconnetterà dalla tua vecchia porta USB reclamando "rumore EMI", e si ricollegherà a una nuova e diversa porta, dove Weewx non riesce a trovarlo. Ecco un tipico output di log:
Nov 29 10:40:21 hummingbird kernel: [6661624.786792] hub 2-0:1.0: port 3 disabled by hub (EMI?) re-enabling... Nov 29 10:40:21 hummingbird kernel: [6661624.786871] usb 2-3: USB disconnect, address 2 Nov 29 10:40:21 hummingbird kernel: [6661624.795778] cp2101 2-3:1.0: device disconnected Nov 29 10:40:21 hummingbird weewx[25808]: VantagePro: Max retries exceeded while getting LOOP packets ... (messages elided) Nov 29 10:40:22 hummingbird kernel: [6661625.352340] cp2101 2-3:1.0: cp2101 converter detected Nov 29 10:40:22 hummingbird kernel: [6661625.528107] usb 2-3: reset full speed USB device using ohci_hcd and address 3 Nov 29 10:40:22 hummingbird kernel: [6661625.735497] usb 2-3: cp2101 converter now attached to ttyUSB1
In questo esempio, VantagePro era connesso a /dev/ttyUSB0, ma poi si è riconnesso a /dev/ttyUSB1.
Se posizioni bobine di ferrite sulla connessione USB, eliminerai il 90% di questo problema.
Tuttavia, c'è un ultimo passaggio che puoi compiere per rafforzare davvero il tuo sistema: installa un udevscript che creerà un collegamento simbolico alla porta USB di VantagePro, qualunque essa sia. Con questo approccio, se la porta salta da ttyUSB0 a ttyUSB1, il collegamento simbolico la seguirà. Basta specificare la porta /dev/vpro nel file di configurazione weewx.conf
Installazione di uno script udev
Utilizzare una regola udev per garantire che un dispositivo USB appaia sempre nella stessa posizione, ad esempio /dev/vpro, anziché in una posizione specifica, ad esempio /dev/ttyUSB0.
NdA: Ad esempio, per la mia stazione meteorologica VantagePro2, ho installato un file /etc/udev/rules.d/vpro.rules sul mio fit-PC che assomiglia a questo:
# Automount the VantagePro2 to port /dev/vpro.
# Install in /etc/udev/rules.d/vpro.rules
#
ACTION=="add", ATTRS{interface}=="CP2102 USB to UART Bridge Controller", SYMLINK+="vpro"
Questa regola dice che quando la porta USB è collegata (action add) e ha un attributo con il nome interface uguale a CP2102 to UART Bridge Controller, aggiunge un collegamento simbolico per la sua porta fisica a /dev/vpro.
Ecco una regola che funziona per il cavo da seriale a USB, prodotto da "YC Cable USA". Non solo aggiunge un collegamento simbolico vpro, ma imposta anche i permessi chmod su 666, consentendo a qualsiasi utente di leggere o scrivere su di esso.
# Automount Serial-to-USB cable to port /dev/vpro
# Install in /etc/udev/rules.d/cable.rules
#
ACTION=="add",ATTRS{idVendor}=="05ad",ATTRS{idProduct}=="0fba",MODE="0666",SYMLINK+="vpro"
I tuoi dispositivi potrebbero, e probabilmente avranno, identificatori diversi! Posso consigliare questo articolo, Scrivere regole udev (In Inglese), su come trovare e scrivere una regola udev appropriata per il tuo controller. (Si noti, tuttavia, che questo articolo utilizza il vecchio comando udevinfo, piuttosto che il comando udevadm più recente). In particolare, eseguire il comando:
udevadm info --attribute-walk --path $(udevadm info --query=path --name=/dev/ttyUSB0)
dov'è nell'esempio /dev/ttyUSB0 la porta (sostituisci la tua vera porta USB) a cui è collegata la stazione meteorologica. Stamperà vari identificatori che possono essere utili per identificare la tua stazione meteorologica in udev. Mentre il primo script di esempio sopra utilizzava una regola che corrispondeva all'interfaccia dell'attributo, altri sono possibili. Nel secondo esempio, per il cavo da seriale a USB, ha scelto di far corrispondere l'attributo product.
Dopo aver installato la tua regola udev, puoi quindi impostare port=/dev/vpro in weewx.conf, sicuro che punterà sempre alla tua stazione meteorologica, indipendentemente dalla porta USB a cui è effettivamente collegata!
Weewx genera pagine HTML, ma non le aggiorna
Se noti che tutto sembra normale, ovvero i file immagine e HTML vengono generati (guarda nel log per essere sicuro) e inviati al tuo server web (se hai configurato FTP o rsync), ma i valori nelle pagine web non vengono aggiornati, potrebbe essere dovuto alla memoria della stazione danneggiata o da un orario errato.
Memoria della stazione danneggiata
Se hai una stazione Vantage, il problema potrebbe essere dovuto al fatto che i dati della tua console si siano danneggiati. Il modo in cui funziona la serie Davis Vantage è che il software (Weewx in questo caso) chiede alla console tutti i dati di archivio "da" qualche tempo. La console quindi scarica i record uno alla volta. Dopo essere arrivato all'ultimo, la memoria si avvolge e il timestamp salterà improvvisamente indietro nel tempo di un paio di settimane: è così che il software sa di aver scaricato l'ultimo record e quindi si ferma.
Tuttavia, se la memoria interna è danneggiata, la console restituirà immediatamente gli archivi nel passato, quindi sembra che i timestamp siano diminuiti di valore e Weewx pensa che sia così: non ci sono più dati. Ecco come appare tipicamente il registro (con debug=1):
Nov 26 14:20:15 raspberrypi weewx[3849]: vantage: Getting archive packets since 2016-11-25 19:55:00 CET (1480100100) Nov 26 14:20:15 raspberrypi weewx[3849]: vantage: gentle wake up of console successful Nov 26 14:20:15 raspberrypi weewx[3849]: vantage: Retrieving 45 page(s); starting index= 1 Nov 26 14:20:15 raspberrypi weewx[3849]: vantage: DMPAFT complete: page timestamp 2016-11-02 19:25:00 CET (1478111100) less than final timestamp 2016-11-25 19:55:00 CET (1480100100) Nov 26 14:20:15 raspberrypi weewx[3849]: vantage: Catch up complete. Nov 26 14:20:15 raspberrypi weewx[3849]: reportengine: Running reports for latest time in the database. Nov 26 14:20:15 raspberrypi weewx[3849]: reportengine: Running report StandardReport Nov 26 14:20:15 raspberrypi weewx[3849]: vantage: Requesting 200 LOOP packets. Nov 26 14:20:15 raspberrypi weewx[3849]: reportengine: Found configuration file /etc/weewx/skins/Standard/skin.conf for report StandardReport Nov 26 14:20:15 raspberrypi weewx[3849]: cheetahgenerator: using search list ['weewx.cheetahgenerator.Almanac', 'weewx.cheetahgenerator.Station', 'weewx.cheetahgenerator.Stats', 'weewx.cheetahgenerator.UnitInfo', 'weewx.cheetahgenerator.Extras'] Nov 26 14:20:15 raspberrypi weewx[3849]: vantage: gentle wake up of console successful Nov 26 14:20:19 raspberrypi weewx[3849]: cheetahgenerator: Generated 14 files for report StandardReport in 4.16 seconds Nov 26 14:20:20 raspberrypi weewx[3849]: genimages: Generated 12 images for StandardReport in 0.62 seconds Nov 26 14:20:20 raspberrypi weewx[3849]: reportengine: copied 9 files to /var/www/html/weewx Nov 26 14:20:20 raspberrypi weewx[3849]: reportengine: Running report FTP Nov 26 14:20:20 raspberrypi weewx[3849]: reportengine: Found configuration file /etc/weewx/skins/Ftp/skin.conf for report FTP
Nota come Weewx ha eseguito un comando DMPAFT ("Getting archive packets since 2016-11-25 19:55:00"). La console ha risposto che ha molti record dopo quell'ora ("Retrieving 45 page(s); starting index= 1"), ma quando Weewx prova effettivamente a recuperarli, sono tutti prima dell'ora richiesta.
Sembra che ci siano diverse correzioni:
-
• Scollega la console, estrai le batterie e attendi un minuto o due. Ciò causerà il riavvio interno del software della console. In un caso questo ha risolto il problema senza perdita di dati.
-
• Se non funziona, arresta Weewx se è in esecuzione, quindi usa l'utilità wee_device per scaricare prima tutti i dati utili nel logger, quindi cancellare la memoria.
wee_device --dump wee_device --clear-memory
Si noti che il comando --dump può generare molti errori di "chiave primaria duplicata". Questi possono essere ignorati.
-
• Se l'opzione --clear-memory fallisce, allora la memoria di archivio del tuo data logger potrebbe essersi danneggiata. Potrebbe essere necessario sostituire l'hardware del data logger. Come soluzione alternativa, puoi disabilitare l'utilizzo dell'archivio impostando l'opzione record_generation su software nel file di configurazione weewx.conf:
[StdArchive] ... record_generation = software
Orario errato
Se il database contiene un record con timestamp (campo dateTime) nel futuro, i record della stazione più vecchi di quella data verranno ignorati. Come può il database contenere record del futuro? A volte l'orologio del computer non è impostato correttamente. Ad esempio, il Raspberry Pi non ha un orologio, quindi se Weewx salva i dati prima che il Raspberry abbia sincronizzato il suo orologio con i server dell'ora di Internet, i record avranno timestamp errati, alcuni dei quali potrebbero essere nel futuro.
La soluzione è eliminare tutti i record con timestamp nel futuro. Per un database SQLite, la procedura è simile a questa:
cp /home/weewx/archive/weewx.sdb /home/weewx/archive/weewx.sdb.backup sqlite3 /home/weewx/archive/weewx.sdb sqlite> delete from archive where dateTime > X; sqlite> .exit
Il timestamp X è l'ora corrente in unix epoch time (numero di secondi dal 1° gennaio 1970). Il sito Web www.epochconverter.com è utile per determinare l'attuale orario dell'epoca unix.
Connettori di terze parti
Questa sezione è per coloro che utilizzano un connettore homebrew o di terze parti per una console Davis Vantage che non contiene un logger, come l' interfaccia seriale DSI-01. Cioè, è una pura connessione seriale alla console, senza memoria integrata.
Per queste interfacce, è necessario impostare la generazione di record su software. Senza queste informazioni, Weewx non è in grado di rilevare l'assenza di memoria integrata. Se non si esegue questa operazione, nel registro di sistema verranno visualizzati errori simili ai seguenti:
Nov 27 20:30:21 rpi weewx[5607]: reportengine: Caught unrecoverable exception in generator weewx.filegenerator.FileGenerator Nov 27 20:30:21 rpi weewx[5607]: **** 'NoneType' object has no attribute '__getitem__' Nov 27 20:30:21 rpi weewx[5607]: **** Traceback (most recent call last): Nov 27 20:30:21 rpi weewx[5607]: **** File "/home/weewx/bin/weewx/reportengine.py", line 132, in run Nov 27 20:30:21 rpi weewx[5607]: **** obj.start() Nov 27 20:30:21 rpi weewx[5607]: **** File "/home/weewx/bin/weewx/reportengine.py", line 259, in start Nov 27 20:30:21 rpi weewx[5607]: **** self.run() Nov 27 20:30:21 rpi weewx[5607]: **** File "/home/weewx/bin/weewx/filegenerator.py", line 41, in run Nov 27 20:30:21 rpi weewx[5607]: **** self.setup() Nov 27 20:30:21 rpi weewx[5607]: **** File "/home/weewx/bin/weewx/filegenerator.py", line 52, in setup Nov 27 20:30:21 rpi weewx[5607]: **** self.initAlmanac(self.gen_ts) Nov 27 20:30:21 rpi weewx[5607]: **** File "/home/weewx/bin/weewx/filegenerator.py", line 87, in initAlmanac Nov 27 20:30:21 rpi weewx[5607]: **** rec = self.getRecord(archivedb, celestial_ts) Nov 27 20:30:21 rpi weewx[5607]: **** File "/home/weewx/bin/weewx/filegenerator.py", line 115, in getRecord Nov 27 20:30:21 rpi weewx[5607]: **** record_dict_vt = weewx.units.dictFromStd(record_dict) Nov 27 20:30:21 rpi weewx[5607]: **** File "/home/weewx/bin/weewx/units.py", line 892, in dictFromStd Nov 27 20:30:21 rpi weewx[5607]: **** std_unit_system = d['usUnits'] Nov 27 20:30:21 rpi weewx[5607]: **** TypeError: 'NoneType' object has no attribute '__getitem__' Nov 27 20:30:21 rpi weewx[5607]: **** Generator terminated... Nov 27 20:30:23 rpi weewx[5607]: genimages: Generated 11 images in 2.53 seconds See the section on option record_generation.
Molti errori di lettura LOOP
Il sintomo sono molti errori LOOP e il download inaffidabile dei record di archivio. Il tuo registro potrebbe assomigliare a questo:
Jan 18 20:38:52 rpi weewx[6024]: VantagePro: Opened up serial port /dev/ttyUSB0, baudrate 19200 Jan 18 20:38:53 rpi weewx[5977]: VantagePro: LOOP #12; read error. Try #1 Jan 18 20:38:53 rpi weewx[5977]: **** Expected to read 99 chars; got 0 instead Jan 18 20:38:58 rpi weewx[7543]: VantagePro: LOOP #13; read error. Try #1 Jan 18 20:38:58 rpi weewx[7543]: **** Expected to read 99 chars; got 4 instead Jan 18 20:39:03 rpi weewx[7543]: VantagePro: LOOP #14; read error. Try #2 Jan 18 20:39:03 rpi weewx[7543]: **** Expected to read 99 chars; got 0 instead Jan 18 20:39:03 rpi weewx[5977]: VantagePro: LOOP #13; read error. Try #2 Jan 18 20:39:03 rpi weewx[5977]: **** Expected to read 99 chars; got 4 instead Jan 18 20:39:08 rpi weewx[7543]: VantagePro: LOOP #15; read error. Try #3 Jan 18 20:39:08 rpi weewx[7543]: **** Expected to read 99 chars; got 4 instead Jan 18 20:39:09 rpi weewx[5977]: VantagePro: LOOP #14; read error. Try #3 Jan 18 20:39:09 rpi weewx[5977]: **** Expected to read 99 chars; got 2 instead Jan 18 20:39:14 rpi weewx[5977]: VantagePro: LOOP #15; read error. Try #4 Jan 18 20:39:14 rpi weewx[5977]: **** Expected to read 99 chars; got 2 instead</pre>
Se osservi attentamente il registro sopra, vedrai che ci sono più istanze di Weewx in esecuzione contemporaneamente (ID processo 5977, 6024, e 7543). Sono in competizione tra loro per il controllo della console, con conseguente perdita di pacchetti e record.
La cura è semplice: terminarli tutti tranne uno. O, meglio ancora, terminarli tutti e poi riavviare Weewx.
Console in modalità configurazione
Assicurati che la console VantagePro2 non sia in modalità di configurazione!
A volte dopo aver spento e riacceso la console, rimane in modalità di configurazione fino a quando non si preme a lungo il pulsante "Done". Mentre la console è in modalità di configurazione, Weewx può ottenere informazioni sulla stazione (ad esempio, wee_device --info) e può persino cancellare la memoria della stazione (wee_device --clear-memory). Ma fintanto che la console è in modalità di configurazione, quando Weewx tenta di ottenere dati fallirà, riportando messaggi come questi:
Mar 17 16:39:43 sailing weewx[25608]: engine: Starting main packet loop. Mar 17 16:39:48 sailing weewx[25608]: vantage: LOOP try #1; error: Expected to read 99 chars; got 0 instead Mar 17 16:39:53 sailing weewx[25608]: vantage: LOOP try #2; error: Expected to read 99 chars; got 0 instead Mar 17 16:39:58 sailing weewx[25608]: vantage: LOOP try #3; error: Expected to read 99 chars; got 0 instead Mar 17 16:40:03 sailing weewx[25608]: vantage: LOOP try #4; error: Expected to read 99 chars; got 0 instead Mar 17 16:40:03 sailing weewx[25608]: vantage: LOOP max tries (4) exceeded. Mar 17 16:40:03 sailing weewx[25608]: engine: Caught WeeWxIOError: Max tries exceeded while getting LOOP data. Mar 17 16:40:03 sailing weewx[25608]: **** Waiting 60 seconds then retrying...