Dovendo installare nuovamente weeWX sul mio RaspberryPi ho provato a tradurre il manuale ufficiale e visto che il lavoro è già fatto lo pubblico su internet. Magari ci sono molti errori di traduzione, soprattutto nella parte tecnica, ma è comunque un buon inizio. 
Eventuali suggerimenti sono graditi. 

Guida in Italiano per il sistema meteo weeWX

Questa è la guida completa per installare, configurare e risolvere i problemi di weeWX.

Cos’è weeWX

WeeWX è un software, scritto in Python, che interagisce con una stazione meteo per produrre grafici, tabelle e pagine HTML. Può aggiornare le tabelle in un Web server remoto e pubblicare i dati presso servizi meteo come WeatherUnderground, CWOP, o PWSweather.com.

Lo sviluppo inzia nell’inverno 2008-2009, con la prima release in 2009.

Il codice sorgente è pubblicato su GitHub, mentre il download è disponibile in weewx.com/downloads.

WeeWX è di circa 13,000 linee di codice, più altre 13,000 per i driver per tutti i tipi degli hardware supportati.

Requisiti di sistema.

 

Stazione

WeeWX supporta molte stazioni meteo. In aggiunta al supporto hardware, weeWX fornisce un simulatore, utile per test e sviluppo.

La tabella dei driver compatibili nella parte hardware della guida ha un dettaglio con la lista dei produttori e dei modelli supportati dai driver che funzionano con weeWX. Se non vedi la tua stazione guarda la lista hardware supportati; la figura può aiutarti ad identificare il produttore e/o il modello. Compatibilità per alcune stazioni sono fornite da driver di terze parti, disponibili nel Wiki. Alla fine, cerca comparazioni hardware per vedere se la tua stazione è conosciuta ma non supportata.

Se alla fine non trovi la tua stazione, scrivi all’User’s Group per un aiuto.

Computer hardware

WeeWX è scritta in Python, così è abbastanza veloce con tutti gli hardware. Può girare tranquillamente dal MacBook al router!

Io uso weeWX su un piccolo PC con un processore a 500 MHz AMD Geode e 512 MB di memoria. Utilizza il 5% del CPU, 100 MB di memoria virtuale, e 20 MB di memoria reale.

WeeWX gira alla grande sul Raspberry Pi, anche se la generazione dei report richiederà più tempo. Ad esempio, i 12 template impiegano circa 5,1 secondi sul RPi, rispetto ai 3,0 secondi del mio Fit-PC e solo 0,9 secondi sul mio vintage Dell Optiplex 745.

Data

Dovresti usare il demone NTP sul tuo server per essere sicuro che è sincronizzato con l’ora corretta.

Con questo riduci di molto gli errori specialmente se invii i dati ai servizi come Weather Underground. L’ora di alcune stazioni è automaticamente sincronizzata con il server weeWX normlmente ogni quattro ore. La frequenza di sincronizzazione può essere aggiustata con la configurazione di weeWX.

Python

È richiesto Python 2.5, 2.6, o 2.7. Con Python 3 non funziona. Vedi le note riguardo a Python 2.5 e Python 2.6

Autorizzazioni

Ci sono dei punti in cui le autotizzazioni influiscono su weeWX:

• Installazione/Configuratione. L’utente che vuole installare deve avere i permessi di scrittura. Allo stesso modo, l’utente che vuole modificare i file di configurazione e gli skin deve avere permessi di scrittura per i file e le cartelle. Le cartelle specifiche dipendono dal metodo di installazione e sono elencate di seguito.
• Funzionamento. La maggior parte degli USB e device seriali richiedono la password di amministrazione (root). Salvo che il device è stato configurato per permettere l’accesso ad utenti non-root, i comandi di weeWX devono essere da utenti root o temporanemente autorizzati con sudo.

Normalmente weeWX è installato con i permessi di amministrazione (root). Comunque, non è raro installare e utilizzare weeWX con un generico utente non-root user, o persino un utente creato specificatamente per utilizzare weeWX.

Installare weeWX

 

Requisiti

Nel mondo del software hobbistico, weeWX è facile da installare e configurare. Non ci sono molte dipendenze da pacchetti, la configurazione è semplice e le guida include istruzioni dettagliate. Ci sono migliaia che l’hanno installato con successo. Comunque non è un interfaccia clicca e installa, così hai delle configurazioni manuali da fare.

Devi avere le seguenti abilità:

• La pazienza di leggere e seguire questa guida;
• Buona volontà e abilità per editare il file di configurazione;
• Una familiarità con Linux o altre derivate Unix;
• L’abilità di fare dei semplici task Unix per cambiare i permessi e dare comandi;
• Non è richiesta esperienza di programmazione a meno che tu non voglia estendere . In questo caso dovresti essere in grado di programmare in Python.

Se rimani bloccato, c’è un gruppo di utenti molto attivo per aiutarti, ma, per favore, prova a risolvere il problema tu stesso prima di postare.

Panoramica

Questa è una descrizione del processo di installazione, configurazione ed esecuzione di weeWX:

1. Leggi le caratteristiche hardware della tua stazione. Questo ti permetterà di conoscere qualsiasi caratteristica, limitazione o stranezza del tuo hardware.
2. Installa weeWX. Usa le istruzioni passo-passo in uno dei metodi di installazione di seguito.
3. Configura l’hardware. Questo coinvolge il settaggio di cose quali l’intervallo degli archivi, grandezza del pluviometro, etc. Devi seguire le impostazioni date dal produttore del tuo hardware, oppure essere in grado di usare l’utility wee_device.
4. Lancia il programma weewxd. Può essere lanciato come demone, o direttamente dalla riga di comando.
5. Regola l’installazione. Normalmente viene fatto cambiando le configurazioni nel file weewx.conf.
6. Personalizza l’installazione. Questo è un capitolo avanzato, che ti permette di ottenere da weeWX esattamente quello che ti piace!

Metodi di installazione

Weewx può essere installato da un pacchetto DEB (Debian) o RPM (Redhat, SUSE), o può essere installato usando l’utilità standard di Python setup.py.

Il pacchetto DEB o RPM ha un approccio semplice ed è raccomandato per i principianti. Comunque, richiede i privilegi di root, e installa le parti di weeWX nelle partizioni del sistema operativo standard attraverso il file system anziché in una singola directory. L’effetto finale è che i file di configurazione, i modelli e il codice verranno installati in posizioni separate, la maggior parte delle quali richiederà i privilegi di root da modificare.

L’installazione mediante setup.py è il metodo consigliato per coloro che pianificano di scrivere servizi e report personalizzati per weeWX. Metterà tutto in un’unica directory, specificata dal parametro home nel file setup.cfg, rendendo più semplice la modifica di weeWX. Questo file non è utilizzato dagli altri metodi di installazione. Se l’utente che installa weeWX ha il permesso di scrivere nella directory, i privilegi di root non saranno richiesti per installare, eseguire o modificare weeWX.

Installare dal pacchetto DEB

Per i sistemi operativi Debian, Ubuntu, Mint, e Raspbian, segui le istruzioni per sistemi Debian-based.

Installare dal pacchetto Redhat RPM

Per i sistemi operativi Redhat, CentOS, Fedora, segui le istruzioni per sistemi Redhat-based.

Installare da pacchetto SuSE RPM

Per i sistemi operativi SuSE e OpenSUSE, segui le istruzioni per sistemi SuSE-based.

Installare sul MacOS

Per il MacOS, segui le istruzioni per sistemi MacOS.

Installare usando il tool di Python setup.py

Per tutti gli altri sistemi operativi, segui le istruzioni setup.py. Questo metodo può essere usato anche su sistemi operativi Debian-, Redhat-, e SUSE-based al meglio, e può essere la migliore scelta se tu intendi personalizzare fortemente il tuo weeWX.

Dove trovare le cose

Qui c’è una tabella con i differenti metodi di installazione, insieme ai nomi simbolici usati per ogni tipo. Questi nomi sono usati in tutta la documentazione.

Tabella per le applicazioni usando il pacchetto DEB
Applicazione	Nome simbolico	Allocazione
cartella principale weeWX	WEEWX_ROOT	/
Eseguibili	BIN_ROOT	/usr/share/weewx/
Cartella configurazioni	CONFIG_ROOT	/etc/weewx/
Skin e templates	SKIN_ROOT	/etc/weewx/skins/
Database SQLite	SQLITE_ROOT	/var/lib/weewx/
Pagine Web	HTML_ROOT	/var/www/html/weewx/
Documentazione	DOC_ROOT	/usr/share/doc/weewx/
Esempi	EXAMPLE_ROOT	/usr/share/doc/weewx/examples/
File PID		/var/run/weewx.pid
File Log		/var/log/syslog

Esecuzione di weeWX

WeeWX può essere eseguito direttamente o come demone. Quando si prova weeWX per la prima volta, è preferibile eseguirlo direttamente perché sarà possibile vedere l’output del sensore e la diagnostica, nonché i messaggi di registro. Una volta che tutto funziona correttamente, eseguilo come demone.

Eseguirlo direttamente

Per eseguire weeWX direttamente, lancia il programma, weewxd, lanciando il file di configurazione con un solo parametro:

sudo weewxd weewx.conf

Dovrebbe partire il download di tutti i dati della tua stazione meteo (se la stazione ha dei dati da trasmettere) nell’archivio del database. Per alcune stazioni, come la Davis Vantage con centinaia di dati, potrebbero occorrere un minuto o due. Ho trovato questo processo particolarmente lento con SuSE per alcune ragioni.

WeeWX attiverà il monitoraggio dei dati dei sensori (indicato anche come dati LOOP), stampando una piccola parte dei dati ricevuti sul terminal, aggiornadoli ogni due secondi per la stazione Vantage, oppure con tempi più lunghi per alcune altre stazioni.

Puoi dire a un’istanza in esecuzione di weeWX di rileggere il suo file di configurazione inviandogli il segnale HUP. Per prima cosa eseguire ps per scoprire il numero di ID del processo (PID) dell’istanza, quindi inviare il segnale HUP:

ps -a          # Note the PID of the weewxd process
kill -HUP pid  # Send it a HUP signal

Considera che questo legge that this solo il file di configurazione. Non aggiornerà nessun codice.

Esecuzione come demone

Per operazioni non presidiate è meglio avere weeWX eseguito come demone, avviato automaticamente quando il server viene riavviato.

Se tu usi il pacchetto di installazione DEB o RPM, questo viene fatto automaticamente. Puoi ignorare questa sezione.

Avvia selezionando l’appropriato comando dello script. Il sorgente può essere trovato nella cartella sotto util/init.d/.

Debian/Ubuntu/Mint:	util/init.d/weewx.debian
Redhat/CentOS/Mint:	util/init.d/weewx.redhat
SuSE:	util/init.d/weewx.suse

 

Controlla che lo script scelto per la variabile WEEWX_ROOT sia sttato per la proprio directory root della tua installazione weeWX (dovrebbe essere settata coorettamente in modo automatico dal processo di installazione, ma non è male controllare).

 

Copialo nella propria cartella del tuo sistema:

Debian/Ubuntu/Mint:	cp util/init.d/weewx.debian /etc/init.d/weewx
Redhat/CentOS/Fedora:	cp util/init.d/weewx.redhat /etc/rc.d/init.d/weewx
SuSE:	cp util/init.d/weewx.suse /etc/init.d/weewx

 

Rendi lo script eseguibile:

Debian/Ubuntu/Mint:	chmod +x /etc/init.d/weewx
Redhat/CentOS/Fedora:	chmod +x /etc/init.d/rc.d/weewx
SuSE:	chmod +x /etc/init.d/weewx

 

Crea un link simbolico:

Debian/Ubuntu/Mint:	update-rc.d weewx defaults 98
Redhat/CentOS/Fedora:	chkconfig weewx on
SuSE:	/usr/lib/lsb/install_initd /etc/init.d/weewx

 

WeeWX si avvierà ora automaticamente all’avvio. Tu puoi anche avviare, fermare e riavviare manualmente il demone weeWX con il comando:

sudo /etc/init.d/weewx start
sudo /etc/init.d/weewx stop
sudo /etc/init.d/weewx restart

Di default, lo script è creato per avere weeWX avviato ai livelli 2, 3, 4 e 5. Per inciso, uno strumento utile per impostare i livelli di esecuzione con i sistemi Debian (Ubuntu, Mint) è sysv-rc-conf. Usa un’interfaccia per permetterti di cambiare facilmente a quale livello di esecuzione si esegue uno dei tuoi demoni. C’è uno strumento simile su SuSE. Dal menu di avvio, eseguire YAST Control Center, quindi cercare Servizi di sistema (Runlevel). Seleziona la modalità “Esperto” per vedere i livelli di esecuzione.

Puoi anche dire a weeWX di rileggere il suo file di configurazione senza fermarsi usando l’opzione ‘ricarica’:

sudo /etc/init.d/weewx reload

Monitorare weeWX

WeeWX registra molti eventi nel system log. Sui sistemi Debian, si trova in /var/log/syslog, su SuSE, /var/log/messages. Il tuo sistema potrebbe usare un altro posto. In caso di problemi sii sicuro di trovarlo!

tail -f /var/log/syslog

Configura l’opzione debug in weewx.conf per generare molti altri controlli e informazioni. Questo può essere utile per diagnosi di problemi.

debug = 1

Integrazione con un web server

 

Se il server è nella stessa macchina

Le tabelle generate da weeWX possono essere al servizio di un web server attivo sullo stesso computer di weeWX. Queste sono le istruzioni per rendere disponibili le tabelle di weeWX su un web server Apache. Questo processo è similare a quelle per altri web server quali nginx o lighthttpd.

1. Installa il web server Apache sul computer dove gira weeWX. Per esempio, con sistemi Debian:sudo apt-get install apache2
2. Configura Apache per vedere le tabelle weeWX.
   • se weeWX è stato installato da pacchetti DEB o RPM, nessuna configurazione dovrebbe essere necessaria per il fatto che le tabelle sono inviate alla directory /var/www/html/weewx, la quale è nella DocumentRoot directory di Apache /var/www/html
   • Se weeWX è stato installato usando setup.py, devi dire ad Apache dove trovare le tabelle weeWX. Un metodo è installare un frammento di configurazione Apache:

     sudo cp util/apache/conf.d/weewx.conf /etc/apache2/conf.d

     Accertati che la path nella configurazione del frammento di Apache corrisponda con l’HTML_ROOT definito nel file di configurazione di weeWX. Per esempio, la path di default per una installazione setup.py dovrebbe essere come questa:

     Alias /weewx /home/weewx/public_html
     <Directory /home/weewx/public_html>
         Options FollowSymlinks
         AllowOverride None
     </Directory>

     Riavvia Apache per rendere effettivi i cambiamenti:

     sudo /etc/init.d/apache2 restart

3. Apri la URL di weeWX URL in un browser:http://localhost/weewx

Se il server è in una macchina differente

Usa FTP o RSYNC per trasferire i file generati da weeWX al tuo server remoto. In weeWX, FTP e RSYNC sono implementati come report. Sono configurati nella sezione [StdReport] del file di configurazinìone di weeWX.

Per esempio, la seguente configurazione usa RSYNC per copiare i file html e le immagini dalla cartella /var/www/html/weewx sul server wx.example.com:

[StdReport]
    [[RSYNC]]
        skin = Rsync
        server = wx.example.com
        path = /var/www/html/weewx
        user = wxuser

La seguente configurazione usa FTP per copiare i file html e le immagini:

[StdReport]
    [[FTP]]
        skin = Ftp
        server = wx.example.com
        path = /var/www/html/weewx
        user = wxuser
        password = wxpass

Vedi la documentazione alla sezione [[FTP]] e [[RSYNC]] del file di configurazione weewx.conf per i dettagli e le opzioni.

Fare dei backup

Per copiare una installazione di weeWX, hai bisogno di fare una copia di

• informazioni di configurazione;
• skin e template;
• ogni personalizzazione o estensione che hai installato;
• il database di weeWX.

Non è necessario copiare le immagini generate, i file HTML, o i report NOAA dato che weeWX li creerà facilmente di nuovo.

Seguono istruzioni individuali.

Configurazioni

Salva il file weewx.conf.

setup.py:	/home/weewx/weewx.conf
DEB/RPM:	/etc/weewx/weewx.conf

Skin e template

Salva il contenuto della cartella skins se hai modificato lo skin di default o se hai aggiunto un nuovo skin o dei file di template.

setup.py:	/home/weewx/skins
DEB/RPM:	/etc/weewx/skins

Personalizzazioni o estensioni

Salva il contenuto della cartella user se hai modificato lo schema del database oppure hai aggiunto delle estensioni. Se le estensioni salvano i dati nel database dovresti salvare il database al meglio.

setup.py:	/home/weewx/bin/user
DEB/RPM:	/usr/share/weewx/user

Database

Alla fine, hai bisogno di fare un backup del database.

Per configurazioni SQLite, fai una copia del file weewx.sdb.

setup.py:	/home/weewx/archive/weewx.sdb
DEB/RPM:	/var/lib/weewx/weewx.sdb

Non fare una copia del database SQLite mentre è nel mezzo di una transazione! Schedula un backup immediatemente dopo che un record è registrato, e poi sii sicuro che il backup di completato prima che un nuovo record arrivi. Alternativamente, ferma weeWX, fai il backup, poi riavvia weeWX.

Per una configurazione MySQL, salva il dump del database.

Recupera dal backup

Per recuperare da un backup, fai una nuova installazione di weeWX, rimetti i file di default con quelli del backup, poi avvia weeWX.

Configurare MySQL

Questa sezione riguarda solo coloro che vogliono usare il database MySQL, invece del database di default SQLite.

Prima, verifica che il pacchetto Python MySQLdb sia installato:

python -c "import MySQLdb"

Se Python restituisce un errore di import

ImportError: No module named MySQLdb

allora installa il pacchetto MySQLdb. Per esempio, sui sistemi Debian:

sudo apt-get install python-mysqldb

Successivamente, cambia la configurazione di weeWX configuration per usare MySQL invece di SQLite. Nel file di configurazione di weeWX, cambia la sezione [[wx_binding]] per puntare il database MySQL, archive_mysql, invece di SQLite database archive_sqlite.

Dopo i cambiamenti, dovrebbe essere come questo (evidenziati i cambiamenti):

    [[wx_binding]]
        # The database should match one of the sections in [Databases]
        database = archive_mysql
        # The name of the table within the database
        table_name = archive
        # The class to manage the database
        manager = weewx.wxmanager.WXDaySummaryManager
        # The schema defines to structure of the database contents
        schema = schemas.wview.schema

Assumendo che tu voglia usare le configurazioni del database di default database, la sezione [[MySQL]] dovrebbe essere come questa:

    [[MySQL]]
        driver = weedb.mysql
        host = localhost
        user = weewx
        password = weewx

Questo considera che lo user weewx ha la password weewx. È necessario cambiarla.

Dovrai dare i permessi necessari per abilitare gli user weewx , di default weewx, ad usare il database MySQL che hai scelto, by default. Qui sono i permessi minimi necessari:

mysql> CREATE USER 'weewx'@'localhost' IDENTIFIED BY 'weewx';
mysql> GRANT select, update, create, delete, insert, drop ON weewx.* TO weewx@localhost;

Compatibilità con wview

 

sqlite3

L’archivio database SQLite usato da weeWX (denominato, weewx.sdb) è completamente compatibile con il database usato da wview (normalmemte chiamato called wview-archive.sdb), almeno per la versione 5.2.X di wview. Lo schema, e la sua semantica, è identico.

Se hai dei dati da wview, tu puoi importarli in weeWX semplicemente copiando il file del database SQLite. Assumendo che i dati wview sono nel file /var/wview/archive/wview-archive.sdb,

sudo /etc/init.d/weewx stop
cd SQLITE_ROOT
mv weewx.sdb weewx.sdb.bak
cp /var/wview/archive/wview-archive.sdb weewx.sdb
sudo /etc/init.d/weewx start

All’interno del database weewx.sdb, weeWX mantiene anche un “riepilogo giornaliero” di tutte le statistiche. Questo è fatto per motivi di prestazioni. Il riepilogo giornaliero verrà automaticamente creato al primo avvio. Questo potrebbe richiedere alcuni minuti se l’archivio di wview contiene più di un mese o due di dati.

Sul mio modesto PC Slim Fit da 500 MHz con 512 MB di memoria ci sono voluti poco più di 4 minuti per un anno e mezzo (25 MB) di dati.

 

MySQL

L’archivio del database di MySQL usato da wview è “piuttosto” compatibile con weeWX. L’unica differenza è che in wview, la colonna interval è denominata arcInt (presumibilmente perché è una keyword in MySQL, comunque può essere circostanziata usando la parola con le backquotes).

Per cambiare il nome della colonna con quello che usa weeWX, namely interval, usa l’utility mysql con il comando:

mysql> ALTER TABLE your-wview-archive-name CHANGE arcInt `interval` INTEGER NOT NULL;

dove your-wview-archive-name è il nome del tuo database MySQL di wview. Nota che la parola interval è circostanziata da backquotes.

Poi nella sezione [Databases] di weewx.conf, rinomina sil nome del database con quello che la tua installazione di wview ha usato your-wview-archive-name:

[[archive_mysql]]
    database_type = MySQL
    database_name = your-wview-archive-name

La configurazione del file weewx.conf

La configurazione del file weewx.conf è un lungo testo che mantiene tutte le informazione di configurazione della tua installazione di weeWX. Questo include cose tipo:

• Il modello della tua stazione;
• Il nome della tua stazione;
• Che tipo di database usi e dove è localizzato;
• Come raccogliere osservazioni esterne, etc.

La posizione del file weewx.conf dipende dal tuo metodo di installazione e dal sistema operativo. Per esempio, se hai usato il metofo setup.py, allora la posizione è in /home/weewx, e così il tuo file di configurazione sarà /home/weewx/weewx.conf. Per altre configurationi, consulta l’application layout table nella sezione ‘metodi di Installazione.

C’è un altro file di configurazione, skin.conf, per particolari opzioni di presentazione. È descritto nella Guida di Personalizzazione, sotto la sezione The Standard skin.conf.

La seguente sezione è la guida definitiva delle molte opzioni di configurazione disponibili in weewx.conf. Contiene molte più opzioni di quanto ne abbia bisogno! — puoi tranquillamente ignorare la maggior parte di esse. Le sole importanti, sono quelle che servono per personalizzare la tua stazione, sono evidenziate.

I valori di default servono per molte opzioni, il cui significato non è del tutto elencato nel file di configurazione, weeWX sceglierà i valori sensibili. Quando la documentazione che segue dice “default value”, valori di default, questo è quello che significa.

Cosa seguire è organizzato da differenti sezioni del file di configurazione.

Generale

L’opzione dichiarata sopra non è attualmente parte di nessuna sezione.

debug

Impostare a 1 per avere dei controlli extra del programma, come ad esempio delle informazioni nel file di log. È fortemente raccomandato se stai avendo dei problemi. Altrimenti, 0. Il valore di default è 0 (nessun debug).

WEEWX_ROOT

Imposta la directory root di weeWX per questa stazione. Normalmente, questa è impostata automaticamente dal processo di installazione. Richiesta. Nessun default.

socket_timeout

Impostare quanto a lungo vuoi aspettare dichiarando il socket time out. Questa è usata quando usi FTP per inviare i dati al web server o quando inviare i dati al servizio Weather Underground. Venti (20) secondi è ragionevole. Il valore di default è 20.

gc_interval

Imposta quanto spesso la pulizia della memoria (garbage collection) deve essere avviata dal runtime di Python. Il valore di default è ogni 10,800 secondi (3 ore).

loop_on_init

Normalmente, se i driver dell’hardware falliscono l’invio, weewx si chiude. L’assunto è che ci sia qualche problema di configurazione e quindi i dati sono inutili. Comunque, in alcuni casi, i driver possono fallire a causa di intermittenze, come ad esempio un problema di rete. In questi casi, sarebbe utile avere weewx che riprovi. Impostando questa opzione a 1 weewx si riavvierà indefinitamente.

[Station] Stazione

Questa sezione serve ad impostare le opzioni relative alla tua stazione meteo.

location

La località della stazione deve essere una stringa UTF-8 che descrive il luogo geografico dove la tua stazione è posizionata. Richiesta. No default.

location = "Un piccolo centro del Sannio"
latitude

 

longitude

I dati di latitudine e longitudine devono essere in gradi decimali, negativi per l’emisfero sud ed ovest, rispettivamente. Richiesti. No default.

latitude = 38.8977
longitude = -77.0366

 

altitude

Normalmente l’altitudine della stazione è scaricata dal tuo hardware, ma non tutte le stazioni supportano questa funzione. Impostare l’altitudine della stazione e l’unità viene usata.

Ad esempio:

altitude = 700, foot

Ad esempio in metri:

altitude = 320, meter
station_type

Impostare il tipo di hardware che stai usando.

station_type = Simulator

Qualunque opzione tu scegli, tu devi avere una corrispodenza nel tuo file di configurazione. Per esempio, se scegli station_type = Simulator, allora hai bisogno della sezione [Simulator]. Quando fai questo manualmente, è tedioso e facile all’errore. La strada migliore è aggiungere i dati usando l’utility wee_config con l’opzione –reconfigure. Se la sezione richiesta è mancante, questa utility la compilerà automaticamente nel file di configurazione.

Le opzioni valide includono:

Opzione	Descrizione
Simulator	Una stazione meteo in simulazione. Utile per test e sviluppo.
AcuRite	Stazione AcuRite 5-in-1 con interfaccia USB
CC3000	RainWise CC3000 data logger
FineOffsetUSB	Stazioni Fine Offset 10xx, 20xx, e 30xx
TE923	Stazione Hideki TE923
Ultimeter	Stazione PeetBros Ultimeter
Vantage	Stazione meteo Davis Vantage
WMR100	Stazione meteo serie Oregon Scientific WMR100
WMR200	Stazione meteo serie Oregon Scientific WMR200
WMR300	Stazione meteo serie Oregon Scientific WMR300
WMR9x8	Stazione meteo serie Oregon Scientific WMR-918/968
WS1	Stazione Argent Data Systems WS1
WS23xx	Stazione La Crosse 23xx
WS28xx	Stazione La Crosse 28xx

 

station_url

Se hai un sito web, puoi impostare uno specifico URL per questo server HTML. Includerà anche un file RSS generato da weeWX e, se tu scegli di iscriverti registro delle stazioni station registry, verrà anche inclusa nella mappa delle stazioni weexk map of weewx stations.

Example:

station_url = http://www.mywebsite.com

 

rain_year_start

Normalmente l’inizio dell’anno è ricavato dal tuo hardware, ma non tutte le stazioni supportano questo. Imposta l’inizio dell’anno pioggia, per esempio, 10, se il tuo anno di pioggia inizia in Octobre (come il mio). Default è 1.

rain_year_start = 1

 

week_start

Inizio della settimana. 0=Monday, 1= Tuesday, … , 6 = Sunday. Default is 6 (Domenica)

week_start = 0

[Simulator] Simulatore

Questa sezione è per le opzioni relative al software meteo di simulazione di weeWX.

loop_interval

Il tempo (in secondi) fra l’invio dei dati. Default è 2.5

mode

Uno a scelta fra simulator o generator. Default è simulator.

simulator	Simulatore in Real-time. Si ferma fra l’invio dei pacchetti.
generator	Invia i pacchetti con la velocità che vuoi. Utile per i test.

start

L’ora locale di partenza per il generatore è nel formato AAAA-mm-ggTHH:MM.Un esempio è 2012-03-30T18:30. Questo codice significa 30-Marzo-2012, alle 18:30, ora locale. Opzionale. Default è l’ora di adesso.

[AcuRite]

Questa è la sezione per le opzioni relative alla stazione meteo AcuRite serie 5-in-1 con connettori USB.

model

Imposta il modello della stazione. Per esempio, “AcuRite 01035”, “AcuRite 01036”, o “02032C”

use_constants

Alcune stazioni (01035, 01036) usa il sensore HP038, il quale contiene delle costanti che definisce come la pressione e la temperatura devono essere interpretati. Altre stazioni (02032, 02064) usano il sensore MS5607, il quale richiede un calcolo differente per calcolare la pressione e la temperatura dal sensore. Quando use_constants è vero ‘True’, il driver usa le costanti per determinare quale tipo di sensore c’è nella stazione e aggiusterà il calcolo. Un valore falso ‘False’ dice al driver di usare un’approssimazione lineare, indipendentemente dal tipo di sensore. Il default è True.

[CC3000]

Questa sezione è per le opzioni relative alla stazione meteo RainWise Mark III ed il data logger CC3000.

port

La porta seriale, per es., /dev/ttyS0. Quando usi un convertitore USB-Serial, la porta sarà qualcosa simile a questo /dev/ttyUSB0. Default è /dev/ttyUSB0

polling_interval

L’intervallo di tempo ‘polling_interval’ determina quanto spesso weeWX prenderà i dati dalla stazione. Il default è 1 secondo.

sensor_map

Questa opzione definisce la mappatura tra i valori della temperatura nel database e nel sensore remoto. Due sensori di temperatura addizionali sono supportati.

Per esempio, questo associa extraTemp1 con il secondo sensore di temperatura opzionale:

[[sensor_map]]
    extraTemp1 = TEMP 2

Vedi la Hardware Guide per una lista completa di nomi di sensori e dei campi di default del database per ogni sensore.

[FineOffsetUSB]

Questa sezione è per le opzioni relative alla serie di stazioni meteo Fine Offset con i connettori USB.

I seguenti settaggi sono altamente raccomandati per le stazioni Fine Offset. Usando la generazione hardware dei dati ha maggiori possibilità di errori a causa di interruzione di comunicazione della USB. Usando la generazione hardware dei dati può causare ritardi nella generazione dei report.

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

 

model

Imposta il modello di stazione. Per esempio, WH1080, WS2080, WH3081, etc.

polling_mode

Uno tra PERIODIC o ADAPTIVE. In PERIODIC, weeWX interroga la console ad intervalli regolari determinati dal polling_interval. In modo ADAPTIVE, weeWX attende che la console sia ferma e non stia leggendo i dati dai sensori o scrivendo i dati nella memoria. Vedi alla sezione Polling Mode and the Polling Interval per i dettagli. Il valore di default è PERIODIC.

polling_interval

La frequenza, in secondi, di quando weeWX prende i dati dalla console. Default è 60. Questo settaggio si applica solo quando il polling_mode è PERIODIC.

data_format

Ci sono due classi di hardware, la console 10xx/20xx e la console 30xx. A differenza delle console 10xx/20xx, la console 30xx registra luminosità ed UV, così sia ha un formato di dati differente. Usa il formato dati ‘data_format’ per indicare che tipo di hardware hai. I valori consentiti sono 1080 (per le console 10xx e 20xx) e 3080 (per le console 30xx). Default è 1080.

[TE923]

Questa sezione è per le opzioni relative alla serie di stazioni meteo Hideki TE923.

model

Imposta il modello della stazione. Per esempio, Meade TE923W o TFA Nexus. Default è “TE923”.

sensor_map

Questa opzione definisce la mappatura tra i valori di temperatura e umidità nel database e nel sensore remoto. Fino a 5 sensori remoti sono supportati. Uno switch per ogni sensore determina quale dei 5 canali il sensore usa. Per esempio, se lo switch sui sensori è impostato su 3, la temperatura da quel sensore sarà t_3 e l’umidità sarà h_3.

Per esempio, questo associa outTemp e outHumidity con il sensore 4:

[[sensor_map]]
    outTemp = t_4
    outHumidity = h_4

Vedi la Hardware Guide per una lista completa dei nomi dei sensori e il campo di default del database per ogni sensore.

[Ultimeter]

Questa sezione è per le opzioni relative alle stazione meteo PeetBros Ultimeter.

port

La porta seriale, per es., /dev/ttyS0. Quando usi un convertitore USB-Serial, la porta sarà simile a questa /dev/ttyUSB0. Default è /dev/ttyUSB0

model

Imposta il modello della stazione. Per esempio, Ultimeter 2000 o Ultimeter 800. Default è “Ultimeter”.

[Vantage]

Questa sezione è relativa alla serie di stazioni con hardware Davis Vantage (VantagePro, VantagePro2 o VantageVue).

type

Imposta uno tra serial, per seriale o USB alla VantagePro (di gran lunga il più comune), o ad ethernet per la WeatherLinkIP. No default.

port

Se scegli la porta seriale, per tipo, allora devi impostare il nome della porta seriale usata dalla stazione. Per esempio, /dev/ttyUSB0 è per l’uso della porta USB, /dev/ttyS0 per la porta seriale. Altrimenti, non richiesta. No default.

host

Se scegli ethernet, allora specifica l’indirizzo IP address (p.es., 192.168.0.1) o l’hostname (p.es, console.mydomain.com) della console. Altrimenti, non richiesto. No default.

baudrate

Imposta il baudate della stazione. Il default è 19200.

tcp_port

La porta dove WeatherLinkIP comunica. Default è 22222.

tcp_send_delay

Quanto a lungo sosta dopo l’invio dei pacchetti dalla WeatherLinkIP. Default è 1 second.

iss_id

Imposta il numero ID dell’ISS (Integrated Sensor Suite). Questo è usato per calcolare la qualità della connessione wireless della statione. Default è 1.

timeout

Quanti secondi deve aspettare la risposta dalla stazione all’accensione. Default è 5 secondi.

wait_before_retry

Quanti secondi deve aspettare al riavvio. Salvo che tua abbia una buona ragione per cambiarlo, questo valore deve essere lasciato di default, dato che è abbastanza lungo che la stazione offra nuovi dati, ma non così tanto da entrare in un nuovo pacchetto di loop (che arriva ogni 2 secondi). Default è 1.2 secondi.

max_tries

Quante volte deve riprovare prima di avviarsi. Default è 4.

[WMR100]

Questa sezione per le opzioni relative alla serie di stazioni Oregon Scientific WMR100 con connettori USB.

model

Imposta il modello della stazione. Per esempio, WMR100 o WMRS200.

sensor_map

Questa opzione definisce il mapping tra le osservazione del sensore remoto e i campi del database.

Per esempio, questo associa extraTemp1 con il sensore T/H sul canale 5:

[[sensor_map]]
    extraTemp1 = temperature_5

Vedi alla parte Hardware Guide per una lista completa dei nomi dei sensori ed i campi di default del database per ogni sensore.

[WMR200]

Questa sezione è per le stazione meteo della serie Oregon Scientific WMR200 con il connettore USB.

model

Imposta il modello della stazione. Per esempio, WMR200 o WMR200A.

use_pc_time

Se vero ‘True’, usa l’ora del computer, altrimenti l’ora della stazione. Default è True.

archive_interval

Imposta l’intervallo di archivio della wmr200 in secondi. Default è 60 secondi.

L’hardware wmr200 registra i dati in archivio ad un non mutabile tempo di 60 secondi. Questo campo può essere impostato ad un valore più alto abilitando il motore weeWX di ricevere i pacchetti. Comunque, quando la wmr200 non è connessa al sistema via USB o se il software weeWX non è avviato, la console wmr200 continuerà a incamerare i dati nella console ad un tempo fisso di 60 secondi.

erase_archive

Se vero ‘True’, cancella la memoria ad ogni riavvio. Default è Falso ‘False’.

archive_startup

Quando When recuperi i dati archiviati dalla memoria della console wmr200, non c’è una esplicita indicazione che tutti i dati siano stati drenati. Questo campo specifica quando si passa da archive mode a live mode. Questa transazione occorre quando non ci sono dati in archivio tra il tempo di intgervallo. Default è 120 secondi.

archive_threshold

Occasionalmente quando recuperi i pacchetti dalla memoria della console wmr200 dei pacchetti obsoleti possono essere rilevati. L’archivio dei pacchetti sono presentati in ordine sequenziale datati ogni 60 secondi. Comunque non c’è garanzia che i pacchetti di archio siano ogni 60 secondi esatti. Se la datazione del pacchetto di dati di archivio in arrivo supera il precedente pacchetto di dati di archivio, l’importo in questo campo verrà eliminato. L’impostazione predefinita è 1512000 secondi (1 settimana).

sensor_status

Se vero ‘True’, invia errori e guasti al log. Default è True.

sensor_map

Questa opzione definisce la mappatura tra i sensori remoti e i campi del database.

Per esempio, questo associa extraTemp1 con il sensore remoto T/H sul canale 5:

[[sensor_map]]
    extraTemp1 = temperature_5

Vedi la Hardware Guide per una completa lista dei nomi dei sensori e i campi di default del database per ogni sensore.

[WMR300]

Questa sezione è per le opzioni della serie di stazioni Oregon Scientific WMR300 con i connettori USB.

model

Imposta il modello della stazione. Per esempio, WMR300 or WMR300A.

sensor_map

Questa opzione definisce la mappatura tra i valori di temperatura/umidità nel database e i sensori remoti. Sono supportati fino a 8 sensori remoti.

Per esempio, questo vuole associare outTemp e outHumidity con il sensore 4:

[[sensor_map]]
    outTemp = temperature_4
    outHumidity = humidity_4

Vedi alla Hardware Guide per una lista completa dei nomi dei sensori e i campi del database per ogni sensore.

[WMR9x8]

Questa sezione è per la serie di stazioni meteo Oregon Scientific WMR-918/968 con i connettori seriali.

type

Per il momento, solo il seriale è supportato.

port

Insieme all’opzione seriale di cui sopra, è necessario impostare il nome della porta seriale utilizzata dalla stazione. Ad esempio, /dev/ttyUSB0 è una posizione comune per le porte USB, /dev/ttyS0 per le porte seriali. Nessun valore predefinito.

model

Imposta il nome della stazione. Per esempio, WMR968 o WMR918.

sensor_map

Questa opzione definisce la mappatura tra i sensori remoti e i campi del database.

Per esempio, questo associa extraTemp1 con il sensore remoto T/H sul canale 5:

[[sensor_map]]
    extraTemp1 = temperature_5
    extraHumid1 = humidity_5

Vedi alla Hardware Guide per una lista completa dei nomi dei sensori e i campi del database per ogni sensore.

 

[WS1]

Questa sezione è per le opzioni relative alle stazioni meteo Argent Data Systems WS1.

port

La porta seriale, p.es., /dev/ttyS0. Quando usi un convertitore USB-Serial, la porta deve essere qualcosa come questo /dev/ttyUSB0. Default è /dev/ttyUSB0

polling_interval

L’intervallo di tempo ‘polling_interval’ determina quanto spesso weeWX interroga la stazione per i dati. Il default è 1 secondo.

 

[WS23xx]

Questa sezione è per le opzioni della serie di stazioni meteo La Crosse WS-23xx (Technoline).

port

La porta seriale, p.es., /dev/ttyS0. Quando usi un convertitore USB-Serial, la porta deve essere qualcosa di simile /dev/ttyUSB0. Default è /dev/ttyUSB0

model

Imposta il modello della stazione. Per esempio, WS-2315, LaCrosse WS2317, etc. Default è “LaCrosse WS23xx”.

polling_interval

L’intervallo di tempo ‘polling_interval’ determina quanto spesso weeWX interroga la stazione per i dati. Se non è specificato il polling_interval (il default), weeWX userà un polling interval basato sul tipo di connessione tra la stazione e i sensori (cablati o wireless). Quando è connessa con il cavo, la console aggiorna i dati ogni 8 secondi. Quando è connessa con il wireless, la console aggiorna da 16 a 128 secondi, in base all’attività del sensore.

[WS28xx]

Questa sezione è per le opzioni relative alla serie di stazioni meteo La Crosse WS-28xx.

transceiver_frequency

radio frequenza per le trasmissioni tra la porta USB e la console. Specifica una tra US o EU. US usa 915 MHz, EU usa 868.3 MHz. Default è US.

model

Imposta il modello della stazione. Per esempio, LaCrosse WS2810, TFA Primus, etc. Default è “LaCrosse WS28xx”.

[StdRESTful]

Questa sezione è per le configurazioni dei servizi StdRESTful, che semplicemente aggiorna i server RESTful su Weather Underground, PWSweather.com, o CWOP.

[[StationRegistry]]

Un registro di stazioni meteo weeWX è mantenuto su weewx.com. Le stazioni sono mostrate su una mappa e una lista a http://weewx.com/stations.html

Come il registro lavora? Ogni stazione meteo periodicamente contatta il registro. Ogni stazione prevede una URL per identificarla, più altre informazione quali il tipo di stazione e la versione di weeWX. Nessuna informazione personale, se non i dati meteorologici, sono inviati.

Per aggiungere la tua stazione meteo in questa lista, devi fare due cose:

1. Abilita il registro delle stazioni ‘StationRegistry’ in weewx.conf settando l’opzione ‘register_this_station’ a vero ‘True’. La tua stazione contatterà il registro ogni settimana. Se la tua stazione non contatta il registro per un mese verrà rimossa dal registro.
2. Indica l’URL della stazione ‘station_url’, o nella sezione [Station], o nella sezione [[StationRegistry]].

Il registro stazioni ‘station_url’ è usato per identificare unicamente ogni stazione, così segli con calma prima di impostare la tua stazione ‘register_this_station’ a vero ‘True’.

[StdRestful]
    [[StationRegistry]]
        register_this_station = True

 

register_this_station

Imposta a vero ‘True’ per registrare la stazione meteo.

description

Una descrizione della stazione. Se nessuna descrizione è specificata, viene usata la location della sezione [Station].

station_url

L’indirizzo URL della stazione meteo. Se nessun URL è specificato, verrà usata la sezione station_url della sezione [Station].

log_success

In caso di successo, scrive un messaggio nel log di sistema. Il predefinito è vero ‘True’.

log_failure

In caso di insuccesso, scrive un messaggio nel log di sistema. Il predefinito è vero ‘True’.

[[AWEKAS]]

WeeWX può inviare i tuoi dati al Automatisches Wetterkarten System (AWEKAS). Se vuoi fare questo, imposta l’opzione ‘enable’ a ‘true’, poi imposta le username e password appropriate. Quando hai fatto, sarà qualcosa come questo

[StdRestful]
    [[AWEKAS]]
        enable = true
        username = joeuser
        password = XXX

 

enable

Imposta a vero ‘true’ per abilitare l’invio ad AWEKAS. Opzionale. Predefinito è falso ‘false’.

username

Imposta il tuo username AWEKAS (p.es., joeuser). Richiesto.

password

Imposta la tua password AWEKAS. Richiesto.

language

Imposta la tua lingua preferita. Predefinito è en.

log_success

In caso di successo, scrive una nota nel log di sistema. Il predefinito è True.

log_failure

In caso di insuccesso, scrive una nota nel log di sistema. Il predefinito è True.

retry_login

Quanto tempo aspetta in secondi prima di riprovare dopo un errato login. Predefinito è 3600 secondi (un’ora).

 

[[CWOP]]

WeeWX può inviare i tuoi dati al Citizen Weather Observer Program. Se vuoi fare questo, imposta l’opzione ‘enable’ a ‘true’, poi imposta le opzioni delle stazione con il tuo codice stazione CWOP. Se la tua stazione è una stazione radio amatoriale APRS, devi impostare il passcode al meglio. Quando hai finito, sarà qualcosa di simile a questo

[StdRestful]
    [[CWOP]]
        enable = true
        station = CW1234
        passcode = XXX    # Replace with your passcode (APRS stations only)
        post_interval = 600

 

enable

Imposta a ‘true’ per abilitare l’invio a CWOP. Opzionale. Predefinito è false.

station

Imposta il tuo ID della stazione su CWOP (p.es., CW1234) o radio amatore (APRS). Richiesto.

passcode

Questo è usato solo per le stazioni APRS (radio amatore). Imposta la tua passcode dato dall’operatore CWOP. Richiesto per le opzioni APRS, ignorato per gli altri.

post_interval

L’intervallo in secondi fra fli invii. Poichè CWOP è altamente usata, gli operatori scoraggiano post molto frequesnti. Ogni 5 minuti (300 secondi) è bene, ma loro preferiscono ogni 10 minuti (600 s) o più lunghi. Impostare questo valore a zero causerà che ogni archivio verrà postato. Opzionale. Predefinito è ogni 600 secondi.

stale

Quanto deve essere vecchio un record prima che non venga usato per la cattura. CWOP non usa la datazione ‘timestamp’ sui dati postati. Invece, loro usano una finestra di tempo per prenderli. Questo significa che se la tua stazione è offline per un lungo periodo di tempo, quando poi weeWX si collega, i vecchi dati possono essere interpretati come condizioni correnti. Opzionale. Predefinito è 600 secondi.

server_list

Una lista di server delimitati da virgola ‘,’ utilizzati per inviare i dati. Opzionale. Predefinito è: cwop.aprs.net:14580, cwop.aprs.net:23

log_success

In caso di successo, scrive una nota nel log di sistema. Il predefinito è True.

log_failure

In caso di insuccesso, scrive una nota nel log di sistema. Predefinito è True.

 

[[PWSweather]]

WeeWX può inviare i dati al servizio PWSweather.com. Se vuoi fare questo, imposta l’opzione ‘enable’ a ‘true’, poi imposta le opzioni della stazione e la password appropriate. Quando tu hai fatto, sarà qualcosa di simile a questo

[StdRestful]
    [[PWSweather]]
        enable = true
        station = BOISE
        password = XXX

 

enable

Imposta a ‘true’ per abilitare ‘enable’ l’invio al servizio PWSweather. Opzionale. Predefinito è false.

station

Imposta l’ID della tua stazione PWSweather (p.es., BOISE). Richiesto.

password

Imposta la tua password PWSweather. Richiesto.

log_success

In caso di successo, scrive una nota nel log di sistema. Il predefinito è True.

log_failure

In caso di insuccesso, scrive una nota nel log di sistema. Il predefinito è True.

retry_login

Quando tempo deve aspettare in secondi prima di riprovare con una login errata. Predefinito è ogni 3600 secondi (un’ora).

 

[[WOW]]

WeeWX può inviare i tuoi dati correnti al servizio British Weather Observations Website (WOW). Se vuoi fare questo, imposta l’opzione abilita ‘enable’ a ‘true’, poi imposta le opzioni della stazione e la password appropriate. Leggi Importing Weather Data into WOW su come trovare il tuo username e come impostare la password per il tuo sito. Quando avrai fatto, saraà simile a questo

[StdRestful]
    [[WOW]]
        enable = true
        station = 12345678
        password = XXX

enable

Imposta a true per abilitare l’invio a WOW. Opzionale. Predefinito è false.

station

Imposta il tuo ID della stazione su WOW (p.es., 12345678). Richiesto.

password

Imposta la tua password WOW. Richiesto.

log_success

In caso di successo, scrive una nota nel log di sistema. Il predefinito è True.

log_failure

In caso di insuccesso, scrive una nota nel log di sistema. Il predefinito è True.

retry_login

Quando tempo deve aspettare in secondi prima di riprovare con una login errata. Predefinito è ogni 3600 secondi (un’ora).

 

[[Wunderground]]

WeeWX può inviare i tuoi dati correnti a Weather Underground. Se vuoi fare questo, imposta l’opzione enable a true, poi imposta le opzioni appropriate della stazione e la password. Quando hai finito, sarà simile a questo

[StdRestful]
    [[Wunderground]]
        enable = true
        station = KCASANFRA11
        password = XXX
        rapidfire = False

 

enable

Imposta a ‘true’ per l’invio dei dati a Weather Underground. Opzionale. Predefinito è false.

station

Imposta il tuo ID della stazione su Weather Underground (p.es., KCASANFRA11). Richiesto.

password

Imposta la tua password su Weather Underground. Richiesto.

rapidfire

Imposta a True affinchè weeWX invii i dati al Weather Underground’s “Rapidfire” protocol. Questo invierà i dati al servizio WU ogni pacchetto completo, che potrebbe essere più spesso di ogni 2.5 secondi in caso di stazioni Vantage. Non tutti le stazioni supportano questo. Opzionale. Predefinito è False.

archive_post

Questa opzione dice a weeWX a postare ogni dato in archivio, come il modo normale “PWS” per il Underground. Siccome loro preferiscono che tu usi il protocollo “Rapidfire”, o il loro modo PWS, ma non insieme, il predefinito per questa opzione è l’opposto di quello che hai scelto per l’opzione rapidfire. Comunque, se per alcune ragioni tuoi usarli entrambi, allora puoi impostare entrambi su True.

log_success

In caso di successo, scrive una nota nel log di sistema. Il predefinito è False per il modo Rapidfire, True per il modo PWS.

log_failure

In caso di insuccesso, scrive una nota nel log di sistema. Il predefinito è False per il modo Rapidfire, True per il modo PWS.

retry_login

Quanto tempo in secondi deve aspettare dopo una login fallita. Predefinito è ogni 3600 secondi (un’ora).

 

[StdReport]

Questa sezione è per configurare il servizio StdReport, che controlla quali dati vengono generati. Siccome possono essere altamente personalizzati per la tua situazione personale, questa documentazione descrive la sezione in una distribuzione standard.

Ogni report è rappresentato da una sub-section, contrassegnata da una doppia parentesi (p.es., [[MyReport]]). Tutti i report dovrebbero messi sotto queste. Il servizio di report standard andrà attraverso tutte le sezioni, creando ogni report in ordine. Quindi, normalmente il report [[StandardReport]] verrà creato per primo, poi il report [[FTP]] (che in pratica consente di caricare i risultati su un server Web remoto). Dettagli per come personalizzare i report sono nella sezione Customizing reports, nella Customization Guide.

SKIN_ROOT

La directory dove risiede lo skin. Il percorso è relativo al WEEWX_ROOT.

HTML_ROOT

la cartella dei file generati. Il percorso è relativo al WEEWX_ROOT. I file generati e le immagini sono postate qui.

data_binding

I dati sorgente sono usati per i report. Deve corrispondere al legame dato nella sezione [DataBindings] di seguito. Il legame può essere sovrascritto nei report individuali. Opzionale. Predefinito è wx_binding.

report_timing

Questo parametro usa una sintassi cronologica che determina quando un report viene creato. Le impostazioni possono essere sovrascritte nei report individuali, così è possibile creare ogni report con una differente catalogazione. Riferimento alla sezione Customizing the report generation time nella Customization Guide per dettagli. Opzionale. Il valore predefinito risulta in ogni report creato o in ogni intervallo di archivio.

[[StandardReport]]

Questo è lo standard report che viene creato ogni intervallo di archivio. Usa lo skin “Standard”, che genera quattro pagine HTML (osservazioni “day”, “week”, “month”, and “year”), grafici, un feed RSS, e i report NOAA mensili e annuali. La configurazione prefedinita usa le unità US e posta i risultati public_html e le subdirectory in public_html/NOAA.

[[FTP]]

Mentre questo “report” non genera qualcosa, il programma invia i file dalla directory HTML_ROOT al server web remoto. È un update incrementale di ogni file che viene modificato, risparmiando la banda della tua connessione internet.

Se non usi questo tipo si server, commenta con # le prime quattro opzioni di seguito.

user

Imposta la username che usi per la tua connessione FTP al tuo server. Richiesto. No default.

password

Imposta la password che usi per la connessione FTP al tuo server. Richiesto. No default.

server

Imposta il nome del tuo web server (p.es., www.meteopaupisi.it, nel mio caso). Richiesto. No default

path

Imposta il percorso dove i dati meteo devono essere salvati sul tuo webserver (p.es., /meteo). NB: alcuni server FTP richiedono una slash (‘/’), alcuni no. Richiesto. No default.

secure_ftp

Imposta a True per usare FTP (FTPS) attraverso TLS. Questa è una estensione del protocollo FTP che usa un protocollo Secure Socket Layer (SSL), da non confondere con SFTP, che usa una Secure Socket Shell protocol. Non tutti i server FTP supportano questo. In particolare, il server FTP di Microsoft sembra faccia un cattivo lavoro di questo. Richiesto Python V2.7. Non funziona con le vecchie versioni di Python. Opzionale. Default è False

port

Imposta la porta ID del tuo server FTP. Default è 21.

passive

Imposta a 1 per usare un più moderno, FTP passivo, 0 se vuoi usare il modo attivo. Il modo passivo generalmente lavora meglio attraverso i firewall, ma non tutti i server FTP lo supportano. Vedi Active FTP vs. Passive FTP, a Definitive Explanation per una buona spiegazione delle differenze. Default è 1 (modo passivo).

max_tries

WeeWX Proverà tante volte as inviare i file con FTP al tuo server, poi passerà oltre. Default è 3.

 

[[RSYNC]]

Mentre questo “report” non genera qualcosa, il programma invia i dati della directory HTML_ROOT ad un server remoto. Genera un update incrementale, sincronizzando solo i file che sono cambiati, risparmiando la banda della tua connessione internet.

Se non usi questo tipo di servizio, commenta le opzioni seguenti.

server

Imposta il nome del tuo web server (p.es., www.meteopaupisi.it, nel mio caso). Richiesto. No default

user

Imposta la username ssh che usi per per la connessione rsync per il tuo web server. L’utente locale che weeWX usa ha semplice password configurata per user@server. Richiesto. No default.

path

Imposta il percorso dove i dati devono essere postati sul tuo webserver (p.es.., /meteo). Richiesto. No default.

delete

I file che non esistono sulla cartella locale verranno rimossi dalla cartella remota. USA CON CAUTELA: se commetti un errore impostando la path, questo può cancellare i file sul server remoto. I valori validi sono 1 per abilitare e 0 per disabilitare. Richiesto. Default è 0.

[StdConvert]

Questa sezione è per configurare il servizio StdConvert. Questo servizio funge come un filtro, convertendo i dati che arrivano dal tuo hardware nella cartella di output. Tutti i dati che sono scaricati, inclusi gli archivi, saranno convertiti. Quindi, i tuoi dati saranno archiviati nel database usando le unità di sistema che tu hai specificato qui.

Una volta scelto, non può essere cambiato! WeeWX non permette che tu mischi le unità nel database. Devi scegliere un sistema e piantarla lì. Questo significa che gli user che provengono da wview (i quali usano personalizzazioni US) non devono cambiare i setting di default. Detto questo, c’è una strada per riconfigurare il database ad usare un’altra unità di sistema. Vedi la sezione Changing the unit system nella guida personalizzazione.

Note!
Questo servizio influisce solo le unità usate nel databases. In particolare, non fa niente con le unità che sono mostrate nei grafici o i file. Queste unità sono specificate nel file di configurazione dello skin, skin.conf, come descritto nella Customization Guide, nella sezione Changing options. A causa di questo, salvo che tu abbia uno speciale scopo, non ci sono buone ragioni per cambiare dal default, che è in unità US.

Attenzione!
Se, nonostante queste precauzioni, tu decidi di cambiare le unità archiviate nel database, sii sicuro di leggere le sezioni [StdCalibrate] e [StdQC], e cambia le unità come vuoi!

target_unit

Imposta una tra US, METRICWX, o METRIC. La differenza tra METRICWX, e METRIC è che il primo usa mm invece di cm per la pioggia, e m/s invece di km/hr per la velocità del vento. Vedi l’appendice Units nella guida di personalizzazione per le esatte differenze tra le tre scelte. Default è US.

 

[StdCalibrate]

Questa sezione è per configurare il servizio StdCalibrate. Questo servizio offre una opportunità di correggere alcuni errori di calibrazione nei tuoi strumenti. È molto comune e flessibile.

Affinchè questo servizio sia normalmente in funzione dopo lo StdConvert, le unità usate devono essere le stesse devono essere le stesse usate nello StdConvert. È anche importante che questo servizio sia in funzione prima del servizio di archivio StdArchive, affinché i dati corretti siano archiviati.

Nella configurazione di default, le calibrazioni sono applicatare alle osservaiozne dell’hardware. Non sono applicate ai calcoli derivati dal servizio quando il servizio StdWXCalculate gira dopo lo StdCalibrate.

 

[[Corrections]]

In questa sezione tu trovi tutti i fattori di correzione. Per esempio, dici che sai che il tuo termometro esterno legge una temperatura più alta di 0.2°F. Puoi aggiungere l’espressione:

outTemp = outTemp – 0.2

Forse hai bisogno di una correzione lineare intorno alla temperatura di 68°F:

outTemp = outTemp + (outTemp-68) * 0.02

È persino possibile fare delle correzioni che coinvolgono più di una variabile. Supposto tu abbia un barometro sensibile alla temepratura:

barometer = barometer + (outTemp-32) * 0.0091

Tutte le correzioni vengono eseguite nell’ordine indicato.

Entrambi i dati verranno corretti.

Se stai usando una stazione Davis Vantage e tu necessiti una semplice correzione compensata, questo può essere fatto nell’hardware. Leggi il tuo manuale per le istruzioni.

[StdQC]

Questa sezione è per configurare il servizio StdQC. Questo servizio offre un controllo di qualità ‘Quality Control‘ molto semplice che controlla che i valori siano entro un range minimo e massimo.

Affinché questo servizio sia in funzione normalmemte dopo lo StdConvert, le unità usate devono essere le stesse di quelle usate nello StdConvert. È anche importante che giri dopo il servizio di calibrazione, StdCalibrate e prima del servizio di archiviazione StdArchive, in modo che i dati calibrati e corretti siano archiviati.

In una configurazione di default, i controlli di qualità sono applicati alle osservazioni dell’hardware. Non sono applicate ai calcoli derivati dal servizio StdWXCalculate dopo il controllo di qualità.

[[MinMax]]

In questa sezione puoi inserire i tipi di osservazione che desideri controllare, insieme ai loro valori minimi e massimi. Se non specificato, le unità devono essere nello stesso sistema di unità specificato nella sezione StdConvert.

For example,

[[MinMax]]
    outTemp = -40, 120
    barometer = 28, 32.5
    outHumidity = 0, 100

Con target_unit = US (di default), se una temperatura va oltre il range di -40 °F fino a 120 °F, allora metterà il valore null, Nessuno, e ignorato. In un modo simile, i valori accettabili per la pressione barometrica saranno da 28 a 32.5 inHg, per l’umidità da 0 a 100%.

Tu puoi anche specificare le unità.

Per esempio,

[[MinMax]]
    outTemp = -40, 60, degree_C
    barometer = 28, 32.5, inHg

In questo esempio, se una temperatura va oltre il range di -40 °C fino a 60 °C, allora verrà indicata come valore null, nessuno, e ignorata. In un modo simile, i valori accettati per la pressione barometrica sono da 28 a 32.5 inHg. Da quando queste unità sono specificate, questi valori non si applicano a prescindere dal target_unit.

Entrambi, LOOP e archivio saranno controllati.

Conoscendo i dettagli del tuo hardware codifica gli aiuti per minimizzare il numero di osservazioni che devi correggere. Per esempio, il VP2 dedica solo un byte per archiviare la velocità del vento storica, e anche se 0xff è dedicato ad un valore errato, così il solo possibile valore che potrebbe apparire è da 0 fino a 126 mph, un ragionevole range. Così, per la VP2, non c’è una reale indicazione misurando la velocità del vento.

[StdWXCalculate]

Il servizio di calcolo, genera una quantità di dati derivati quali il punto di rugiada, la temperatura percepita e l’indice di calore.

Alcuni hardware forniscono le quantità derivate, altri solo le informazioni grezze. Il servizio di calcolo fornisce i dati derivati per hardware che non li forniscono, e sono noti algoritmi per hardware che forniscono calcoli irreali o antiquati.

La sezione [StdWXCalculate] consiste di un gruppo di opzioni generali, seguite da una sub sezione [[Calculations]] che specifica la strategia di calcolo da usare per ogni calcolo derivato.

ignore_zero_wind

Indica se la direzione del vento deve essere indefinita quando la velocità del vento è zero. Il valore di default è True: la direzione del vento sarà indefinita quando la velocità del vento è zero.

Per segnalare la direzione della banderuola anche quando non c’è la velocità del vento, cambiala in False:

[StdWXCalculate]
    ...
    ignore_zero_wind = False

 

[[Calculations]]

Questa sub sezione specifica quale strategia è usata per fornire i valori derivati. Il servizio può calcolare i seguenti valori:

• pressione
• barometro
• altimetria
• temperatura percepita
• indice di calore
• punto di rugiada
• Punto di rugiada interno
• indice di pioggia
• radiazioni solari max
• nuvolosità
• umidità
• temperatura apparente
• ET
• velocità del vento

Nelle sue configurazione, il servizio calcola i valori solo se non sono forniti dall’hardware o i driver. Queste sono le configurazioni di default:

[StdWXCalculate]
    [[Calculations]]
        pressure = prefer_hardware
        barometer = prefer_hardware
        altimeter = prefer_hardware
        windchill = prefer_hardware
        heatindex = prefer_hardware
        dewpoint = prefer_hardware
        inDewpoint = prefer_hardware
        rainRate = prefer_hardware

Le opzioni per ogni valore sono hardware, software, or prefer_hardware

 

hardware	Non calcolare mai il valore.
software	Calcola sempre il valore.
prefer_hardware	Calcolare il valore se non è fornito dall’hardware.

Per esempio, se la tua stazione meteo calcola la temperatura percepita usando un algoritmo pre-2001, e tu preferisci avere il calcolo di weeWX ottienilo specificando come segue:

[StdWXCalculate]
    ...
    [[Calculations]]
        ...
        windchill = software

[StdArchive]

Questa sezione è per configurare lo StdArchive, il servizio che salva gli archivi nel database.

archive_interval

Se l’hardware della tua stazione supporta il data logging allora l’intervallo di archivio verrà preso dalla stazione. Altrimenti, lo devi specificare qui in secondi. Opzionale. Default è 300 secondi.

archive_delay

Quanto tempo devi aspettare in secondi dopo aver preso dei dati dalla stazione per i nuovi dati. Per esempio, se il tuo archive interval è di 5 minuti e archive_delay è impostato a 15, allora deve essere impostato 00:00:15, 00:05:15, 00:10:15, etc. Questo ritardo da alla stazione pochi secondi per archiviare i dati internamente, e nel caso il tuo server abbia altri valori da archiviare. Default è 15 secondi.

record_generation

Imposta che i valori meteo devono essere scaricati dall’hardware (raccomndato), o generati dal software. Se è impostato ad hardware, allora weeWX prova a scaricare i dati in archivio dalla tua stazione. Comunque, non tutti i tipi di stazioni supportano questo, in questo caso weeWX torna alla generazione dal software. Una impostazione hardware funzionerà per la maggior parte degli utenti. Una notevole eccezione sono gli utenti che hanno messo insieme delle interfacce autoprodotte per le stazioni Vantage che non includono memoria per archiviare. In questi casi imposta queste opzioni a software, forzando la generazione dei dati. Default è hardware.

record_augmentation

Quando si esegue la generazione dei dati hardware, questa opzione tenterà di aumentare il dato con qualsiasi dato aggiuntivo che possa estrarre dai pacchetti LOOP. Default is True.

 

loop_hilo

Imposta a True per avere i dati LOOP e i dati di archivio per essere usati per alte/basse statistiche. Imposta a False per usare solo i dati in archivio. Se il tuo sensore emette dati molto spinosi, impostare a falso potrebbe aiutare. Default è True.

data_binding

I dati obbligatori sono usati per archiviare i dati. Questo sceglie uno dei dati obbligatori nella sezione [DataBindings], di seguito. Opzionale. Default è wx_binding.

[StdTimeSynch]

Questa sezione è per configurare StdTymeSynch, un servizio che sincronizza l’orologio della stazione con il tuo computer. Non tutte le stazioni meteo supportano questo.

clock_check

Quanto spesso deve controllare l’orologio della stazione meteo in secondi. Default è 14400 secondi (ogni 4 ore)

max_drift

L’ammontare massimo della differenza di tempo da tollerare, in secondi, prima di resettare l’orologio. Default è 5.

[DataBindings]

Un “dato obbligatorio” associa le caratteristiche di archiviazione con uno specifico database. Ogni dato obbligatorio contiene un database dal sezione del [Databases] più parametri quali schema, table name, e mechanism per i dati aggregati.

[[wx_binding]]

Questi sono i vincoli normalmente usati per i dati meteo. Una tipica sezione [[wx_binding]] dovrebbe essere uguale a questa:

[[wx_binding]]
    database = archive_sqlite
    table_name = archive
    manager = weewx.wxmanager.WXDaySummaryManager
    schema = schemas.wview.schema

Quello che segue sono le informazioni molto più dettagliate circa le opzioni di vincolo.

database

Il database usato — deve corrispondere con quello ella sezione in [Databases]. Se decidi di usare un database MySQL, invece del database SQLite, questo è il posto per cambiarlo. Vedi alla sezione Configuring MySQL per i dettagli. Richiesto.

table_name

Internamente, i dati sono archiviati in una, lunga, flessibile tavola. Questo è il nome di quella tavola. Normalmente questo non ha bisogno di essere cambiato. Opzionale. Default è archive

manager

Il nome delle classi usate per modificare la tavola. Optional. Default è class weewx.wxmanager.WXDaySummaryManager. Questa classe archivia i dati giornalieri nelle tabelle del database, e pochi caratteri, come giorni caldi e freddi, appropriati per il meteo. Normalmente, questo non ha bisogno di essere cambiato.

schema

Una lista Python mantiene la struttura dello schema per essere usata per inizializzare il database. Dopo l’iniziazione, non viene usata. Opzionale. Default è schemas.wview.schema, lo schema è usato dal sistema meteo wview.

 

[Databases]

Questa sezione elenca l’attuale databases. Il nome di ogni database è dato in doppie parentesi, per esempio, [[archive_sqlite]]. Ogni sezione del database contiene i parametri necessari per creare e mantenere il database. Il numero dei parametri varia dipendendo dal tipo di database.

[[archive_sqlite]]

Questa definizione usa il database SQLite engine per archiviare i dati. SQLite è open-source, semplice, leggero, altamente versatile ed efficiente in memoria. Per la maggior parte degli scopi serve bene.

database_type

Imposta a SQLite per impostare che questo è il database SQLite.

database_name

Il percorso del file SQLite dipende dall’opzione in SQLITE_ROOT. Default è weewx.sdb.

[[archive_mysql]]

Questa definizione usa il motore del database MySQL per archiviare i dati. È libero, altamente scalabile, ma molto complicato da amministrare.

database_type

Imposta MySQL per segnare che il database è MySQL.

database_name

Il nome del database. Default è weewx. Richiesto.

 

[DatabaseTypes] Tipo di database

Questa sezione definisce i valori predefiniti per i vari tipi di database.

[[SQLite]]

Questa sezione definisce i valori predefiniti per il database SQLite. Può essere sovrascritta da un proprio database.

driver

Il nome del driver sqlite. Richiesto.

SQLITE_ROOT

La posizione delle directory del database SQLite. Per le installazioni setup.py, la predefinita è WEEWX_ROOT/archive. Per installazioni DEB o RPM, è /var/lib/weewx.

timeout

Quando il database è aperto da accessi multipli e uno di questi modifica il database, il database SQLite è chiuso fino a quando questa operazione non è completata. L’opzione timeout specifica quando tempo gli altri accessi devono aspettare prima di andare avanti. Il default è di 5 secondi.

isolation_level

Imposta il corrente livello di isolamento. Vedi alla documentazione di pysqlite su isolation levels per altre informazioni. Non c’è ragione di cambiare questo valore, ma è previsto per completezza. Default è nessuno ‘None’ (autocommit).

[[MySQL]]

Questa sezione definisce i valori di default per il daabase MySQL. Può essere sovrascritto da un database personale.

Suppongo che se hai scelto il database MySQL, sai anche come amministrarlo. In particolare, tu hai da impostare un utente e modificare i privilegi.

driver

Il nome del driver MySQL. Richiesto.

host

Il nome del server dove il database è posizionato. Default è localhost.

user

Il nome dell’utente per accedere al server. Richiesto.

password

La password. Richiesta.

port

Il numero di porta che deve essere usata. Opzionale. Default è 3306.

engine

Il tipo di motore di MySQL da usare. Non deve essere cambiato senza una buona ragione. Default è INNODB.

[Engine]

Questa sezione è usata per configurare il motore interno in weeWX. È per una personalizzazione avanzata. Dettagli su come fare questo può essere trovata nella sezione Customizing the weeWX service engine della Customization Guide.

[[Services]]

Internamente, weeWX consiste di molti servizi, ognuno è responsabile di alcuni aspetti della funzionalità del programma. Dopo che un evento accade, come l’arrivo di un nuovo pacchetto LOOP, qualsiasi servizio interessato ha la possibilità di svolgere un lavoro utile sull’evento. Per esempio, un servizio potrebbe manipolare il pacchetto, stamparlo, archiviarlo in un database, ecc. Questa sezione controlla quali servizi sono caricati e in quale ordine ottengono la loro opportunità di fare quel lavoro. Prima di weeWX v2.6, questa sezione conteneva una opzione lenta denominata service_list, che conteneva i nomi di tutti i servizi che dovevano essere eseguiti. Da allora, questo elenco è stato suddiviso in cinque liste più piccole, riportate di seguito. Vengono eseguite nell’ordine indicato di seguito.

prep_services

Questi servizi vengono chiamati prima di ogni altro. In genere vengono utilizzati per preparare la console. Ad esempio, il servizio weewx.wxengine.StdTimeSynch, che è responsabile per assicurarsi che l’orologio della console sia aggiornato, è un membro di questo gruppo.

process_services

I servizi di questo gruppo tendono a elaborare tutti i dati in arrivo. In genere fanno cose come controllo qualità, conversione unità o calibrazione del sensore.

archive_services

Una volta che i dati sono stati elaborati, i servizi in questo gruppo li archiviano.

restful_services

I RESTful services, come il Weather Underground o CWOP, sono in questo gruppo. Hanno bisogno di dati elaborati che sono stati archiviati, quindi vengono eseguiti dopo i gruppi precedenti.

 

report_services

Vari servizi di report vengono eseguiti in questo gruppo, incluso il motore di report standard.

Per riferimento, ecco l’insieme standard di servizi che vengono eseguiti con la distribuzione predefinita.

prep_services    = weewx.engine.StdTimeSynch
process_services = weewx.engine.StdConvert, weewx.engine.StdCalibrate,\
  weewx.engine.StdQC, weewx.wxservices.StdWXCalculate
archive_services = weewx.engine.StdArchive
restful_services = weewx.restx.StdStationRegistry, weewx.restx.StdWunderground,\
  weewx.restx.StdPWSweather, weewx.restx.StdCWOP, weewx.restx.StdWOW,\
  weewx.restx.StdAWEKAS
report_services  = weewx.engine.StdPrint, weewx.engine.StdReport

Se sei il tipo a cui piace pulire il bagagliaio della tua auto dopo ogni utilizzo, allora potresti anche essere il tipo che vuole ridurlo al minimo. Tuttavia, ciò farà solo una leggera differenza nella velocità di esecuzione e nell’uso della memoria.

Risoluzione dei problemi

Questa sezione elenca alcuni problemi comuni durante l’installazione e l’esecuzione di weeWX. Se sei bloccato, assicurati di fare:

• Imposta l’opzione debug su 1 in weewx.conf. Questo metterà molte più informazioni nel file di log, che può essere molto utile per la risoluzione dei problemi e il debugging!debug = 1
• Guarda il file di registro. Siamo sempre felici di fare domande, ma la prima cosa che qualcuno chiederà è: “Hai visto il file di registro?”sudo tail -f /var/log/syslog
• Esegui weewxd direttamente dalla riga di comando, piuttosto che come demone. Generalmente, weeWX rileverà e registrerà eventuali eccezioni irreversibili. Ma se stai ottenendo risultati strani, vale la pena correre direttamente e cercare qualche indizio.sudo weewxd weewx.conf

Se sei ancora bloccato, invia il tuo problema al gruppo di utenti weewx. Il Wiki ha alcune linee guida su come fare un post efficace.

Problemi Hardware

Suggerimenti per rendere un sistema affidabile

Se hai problemi a mantenere la tua stazione meteo per lunghi periodi di tempo, ecco alcuni suggerimenti, in ordine decrescente di importanza:

Bobine di ferrite su un Davis Envoy. Ci sono due bobine, una sulla connessione USB (filo superiore) e una sull’alimentatore. Entrambi hanno loop

• Esegui su un hardware dedicato. Se si utilizza il server per altre attività, in particolare per la macchina desktop, si avranno problemi di affidabilità. Se lo stai usando come server di stampa o di rete, probabilmente starai bene.
• Sii semplice. I moderni sistemi grafici sono estremamente complessi. Con l’aggiunta di nuove funzionalità, i test delle suite non sempre recuperano. Il tuo sistema sarà molto più affidabile se lo usi senza un sistema di finestre (X Windows, nel caso di Linux).
• Utilizzare un gruppo di continuità (UPS). La stragrande maggioranza dei problemi di potenzasono di breve durata – solo un secondo o due – quindi non è necessario uno grande. L’unità 425VA che uso per proteggere il mio fit-PC costa meno di 50 Euro.
• Se acquisti una Davis VantagePro e il tuo computer ha una porta seriale obsoleta, procurati VantagePro con una connessione seriale, non con una connessione USB. Vedere la sezione sui problemi del convertitore di Davis cp2101 per i dettagli.
• Se si utilizza una connessione USB, inserire una bobina di ferrite su ciascuna estremità del cavo sulla console. Se hai abbastanza lunghezza e la bobina di ferrite è abbastanza grande, crea un anello in modo che attraversi la bobina due volte.

Stabilire una connessione

Se non riesci a ottenere nulla da weeWX prima controlla di avere una connessione alla tua stazione meteo. Per le stazioni Davis, è possibile utilizzare un emulatore di terminale per eseguire un semplice test. Impostalo per comunicare usando la porta e il baud rate appropriati. Mi piace Minicom perché può essere eseguito da una semplice connessione TTY. Anche lo schermo di utilità funziona bene. Per esempio:

minicom -b 19200 -D /dev/ttyUSB0

o, usando screen:

screen /dev/ttyUSB0 19200

Quindi digitare TEST, tutto in lettere maiuscole. Non stamperà i caratteri. Quindi premi il tasto <invio>. Dovrebbe tornare indietro TEST.

Se funziona, hai stabilito una connessione con la Davis e il problema deve trovarsi altrove.

Problemi porta USB con Davis cp2101

Il convertitore USB utilizzato in Davis VantagePro è noto per avere alcuni problemi di “rumore”. Il sintomo è che il kernel di Linux si disconnetterà dalla vecchia porta USB reclamando “rumore EMI” e si riconnetterà a una nuova e diversa porta, dove weeWX non riesce a trovarlo. Ecco un tipico output di registro:

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, la VantagePro era connessa a /dev/ttyUSB0, ma poi si è riconnessa a /dev/ttyUSB1.

Se metti una capsula di ferrite sul cavo USB, avrai eliminato il 90% di questi problemi. Ho fatto questo circa 3 anni fa e non ho problemi da allora.

Comunque, c’è un ultimo passaggio che è possibile eseguire per rendere davvero più rigido il sistema: installare uno script udev che creerà un collegamento simbolico alla porta USB di VantagePro, qualunque esso sia. Con questo approccio, se la porta passa da ttyUSB0 a ttyUSB1, il collegamento simbolico lo seguirà. Basta specificare la porta /dev/vpro nel file di configurazione weewx.conf e farlo.

Installare lo script udev

Usa una regola udev per essere sicuro che il device USB appare sempre nella stessa posizione come /dev/vpro invece di /dev/ttyUSB2

Per esempio, per la stazione meteo VantagePro2, I ho creato un file /etc/udev/rules.d/vpro.rules sul fit-PC che funziona così:

# 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), ed ha un attributo con un nome di interfaccia che è uguale a CP2102 a UART Bridge Controller, poi aggiunge un link simbolico per la sua porta a /dev/vpro.

Questa è la regola che funziona per il mio cavo Serial-to-USB, prodotto da “Y.C. Cable USA”. Non solo aggiunge un link simbolico vpro, ma setta anche i permessi chmod a 666, autorizzando tutti gli user a leggere o scrivere a 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"

Il tuo device potrebbe avere, e probabilmente avrà, identificativi differenti!! I posso raccomandare questo articolo, “Writing udev rules,” per come fare a trovare e scrivere una regola appropriata per il tuo controller. (Nota, comunque, che questo articolo usa il vecchio comando udevinfo, piuttosto che il più recente comando udevadm.) In particolare, esegui il comando

udevadm info –attribute-walk –path $(udevadm info –query=path –name=/dev/ttyUSB0)

dove /dev/ttyUSB0 è la porta (sostituire la tua vera porta USB) dove la stazione meteo è attaccata. Stamperà vari identificatori che possono essere utili per identificare la tua stazione meteorologica su udev. Mentre il primo script di esempio sopra utilizzava una regola che corrispondeva all’interfaccia di attributo, altri sono possibili. Ad esempio, il secondo esempio, per il cavo da seriale a USB, ha scelto di abbinare il prodotto attributo.

Una volta installata la regola di udev, puoi impostare port=/dev/vpro in weewx.conf, fiducioso che indicherà sempre la tua stazione meteo, indipendentemente dalla porta USB a cui è effettivamente collegata!

Ho provato questo sistema molte volte. Puoi estrarre la porta USB dalla macchina e quindi ricollegarla mentre estrai la connessione di rete nel mezzo di un caricamento FTP: weeWX si ripristinerà.

O, almeno, dovrebbe!

WeeWX genera le pagine HTML, ma non le aggiorna

Se hai un sintomo che tutto sembra normale, che le immagini e i file HTML sono generati (controlla il log per essere sicuri) e inviate al tuo your webserver (se hai configurato FTP o rsync), ma i valori nella pagina web non sono aggiornati, potrebbe essere dovuto a disallineamento dell’orologio o memoria della stazione corrotta.

Disallineamento dell’orologio

Se il database contiene dei valori con una data futura (il campo dateTime), allora i dati dalla stazione sono più vecchi dell’ultima data sul database e quindi vengono ignorati. Come mai il database contiene record a data futura? Talvolta l’orologio del computer non è impostato correttamente. Per esempio, il raspberry pi non ha orologio, così se weeWX salva la data prima che il pi abbia sincronizzato l’orologio con il time server su intrnet, i dati avranno una data non corretta, alcuni di essi possono essere a data futura.

La soluzione è di cancellare tutti i dati con data futura. Per il database sqlite, la procedura potrebbe essere come 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 field timestamp X è la data corrente in formato unix (numero dei secondi dal 1 Gennaio 1970). Questo sito è utile per determinare la data in formato unix.

Memoria stazione corrotta

Se tu hai una stazione Vantage, il problema potrebbe essere che i dati della memoria della stazione si sono ingarbugliati. La serie Davis Vantage lavora in modo che il software (weeWX in questo caso) chiede alla stazione tutti gli archivi “da” un certo tempo. La stazione allora scarica i dati. Dopo che è arrivato all’ultimo, la memoria si avvolge, e il field timestamp avanzerà all’improvviso di un paio di settimane, è questo il modo in cui il software sa di aver scaricato l’ultimo record e così si ferma.

Comunque, se la memoria interna si ingarbuglia, la stazione restituirà immediatamente gli archivi con data passata, e quindi sembra che i field timestamp siano diminuiti di valore e quindi i dati di weeWX sono: non ci sono più dati. Ecco come appare il log (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 da in commando DMPAFT (“Prendo gli archivi da 2016-11-25 19:55:00”). La stazione risponde che ha dati dopo quella data, ma quando weeWX prova a recuperali, sono tutti precedenti alla data richiesta.

Questo sembra avere due soluzioni:

1. Scollega la console, togli le batterie e aspetta un minuto o due. In questo modo il software interno della console si riavvia. In questo caso hai risolto il problema senza perdita di dati.
2. Se non hai risolto il problema, dovrai pulire la memoria della console usando l’utility wee_device. Potrebbe causare una perdita di dati, ma di solito funziona. Imposta il corretto percorso se necessario:

wee_device --clear-memory

Vedi anche la sezione Dumping the logger memory, che ti potrebbe aiutare ad evitare perdite di dati.

Connettori Vantage no originali

Questa sezione è per coloro che usano connettori autocostruiti o non originali per la console Davis Vantage che non contiene un logger, come la DSI-01 serial interface. Questa è una pura connessione seriale con la console senza memoria interna.

Per queste interfacce, dovrai impostare la generazione dei dati a software. Senza questa informazione, weeWX non è in grado di rilevare l’assenza di memoria integrata. Se non fai questo avrai un errore simile a questo ne tuo syslog:

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

Vedi alla sezione sulle opzioni record_generation.

Raspberry Pi

WeeWX funziona molto bene sui Raspberry Pi, dal primo Model A e Model B, fino agli ultimi modelli. Comunque, the Pi ha alcune stranezze, come i problemi con l’alimentazione USB e la mancanza di un orologio.

Vai al Wiki per informazioni aggiornate su Running weeWX on a Raspberry Pi.

Blocchi USB Fine Offset

La serie di stazione meteo Fine Offset e le loro derivate sono di buon valore e lavorano ragionevolmente, ma hanno un problema che è difficile da aggirare: la USB può improvvisamente chiudersi, rendendo impossibile comunicare con la console. Il sintomo è che il log mostri qualcosa simile a 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

L’errore esatto può variare, ma la cosa da cercare è il messaggio “could not detach kernel from interface“. Sfortunatamente, non abbiamo trovato una cura software per questo. Invece, è necessario spegnere e riaccendere l’unità. Rimuovere le batterie e scollegare l’USB, quindi rimetterlo insieme. Non è necessario riavviare weeWX.

Maggiori dettagli circa Fine Offset lockups possono essere trovati nel Wiki.

Intervallo di archiviazione

La maggior parte degli hardware con il data-logging include un parametro per specificare l’intervallo di archiviazione usato. Se l’hardware e il driver lo supportano, weeWX userà questo intervallo come archive_interval. Se invece no, weeWX userà l’archive_interval specificato in [StdArchive]. Il valore di default è 300 secondi (5 minuti).

Se l’intervallo dell’hardware è più grande, ci vorrà un lungo tempo prima che qualcosa sia mostrato nei report di weeWX. Per esempio, le stazioni LaCrosse Technoline WS23xx inviano con un intervallo di 60 minuti, e le stazioni Fine Offset inviano con un intervallo di 30 minuti. Se tu usi weeWX con una stazione WS23xx con le configurazioni di fabbrica, ci vorranno 60 minuti prima che il primo aggiornamento sia mostrato e poi altri 60 minuti per il successivo, e così via.

Da quando i report sono generati fino a quando i nuovi report arrivano, un largo intervallo di archivio significa per i report saranno generati poco frequentemente.

Se vuoi i tuoi report più vicini al tempo reale, usa l’utility wee_device Per cambiare l’intervallo.

Problemi di software

Questa sezione risolve alcuni frequenti problemi di configurazione software.

Niente nel file

Quando in funzione, weeWX invia periodicamente informazioni sullo stato, disconnessioni, e altre cose al log. Tipicamente viene mostrato come questo:

-DATE- --TIME-- HOST weewx[-PID-]: LOG_MESSAGE

Jan  1 09:46:32 saga weewx[15292]: wxengine: Initializing weewx version 2.5.1
Jan  1 09:46:32 saga weewx[15292]: wxengine: Using Python 2.6.6 (r266:84292, Dec 27 2010, 21:57:32) #012[GCC 4.4.5 20100902 (prerelease)]
Jan  1 09:46:32 saga weewx[15292]: wxengine: pid file is /var/run/weewx.pid

La location di questo log varia da sistema a sistema, ma è generalmente in /var/log/syslog, o qualcosa di simile.

Comunque, alcuni sistemi di default salvano solo i warning o le informazioni critiche, così i messaggi da weeWX potrebbero non apparire. Se questo succede anche a te, controlla le tue configurazioni log di sistema. Sui sistemi Debian, guarda in /etc/rsyslog.conf. Sui sistemi Redhat, guarda in /etc/syslog.conf.

Errori di configobj

Questi sono errori nel file di configurazione. Due sono molto comuni. Casualmente, questi errori sono più facili da trovare quando weeWX è avviato direttamente di quando è avviato come demone.

configobj.DuplicateError exception

Questo errore è causato quando si usano più una identità nel file di configurazione. Per esempio, se tu hai inavvertitamente inserito il tuo server FTP due volte:

[Reports]
    [[FTP]]
        ... (details elided)
        user = fred
        server = ftp.myhost.com
        password = mypassword
        server = ftp.myhost.com # OOPS! Inserito due volte!
        path = /weather
...

Generalmente, se tu incorri in questo errore, il file log ti darà il numero di linea dove trova l’errore:

Apr 24 12:09:15 raven weewx[11480]: wxengine: Error while parsing configuration file /home/weewx/weewx.conf
Apr 24 12:09:15 raven weewx[11480]: wxengine: Unable to initialize main loop:
Apr 24 12:09:15 raven weewx[11480]: **** Duplicate keyword name at line 254.
Apr 24 12:09:15 raven weewx[11480]: **** Exiting.

configobj.NestingError exception

È un errore molto simile, ed è causato da nidificazione si sezione errate. Per esempio:

[Reports] [[FTP]]] … (dettagli omessi)

Nota la parentesi di chiusura in più della subsezione FTP.

No barometer data

Se tutto sembra normale, tranne che non hai i dati della pressione, il problema potrebbe essere la mancata corrispondenza tra l’unità di sistema usata per il servizio StdConvert e l’unità di sistema usata dal servizio StdQC. Per esempio:

[StdConvert]
    target_unit = METRIC
    ...

[StdQC]
    [[MinMax]]
        barometer = 28, 32.5

Il problema è che stu stai chiedendo i dati del barometro tra 28 e 32.5, ma il l’unità di sistema è impostata a METRIC, il range del dato dovrà essere 990 e 1050!

La soluzione è cambiare i valori per corrispondere con l’unità in StdConvert, o specificare le unità in MinMax, indipendemente dalle unità in StdConvert. Per esempio:

[StdConvert]
    target_unit = US
    ...

[StdQC]
    [[MinMax]]
        barometer = 950, 1100, mbar

Cheetah.NameMapper.NotFound errors

Se hai degli errori di questo tipo:

Apr 12 05:12:32 raven reportengine[3074]: filegenerator: Caught exception "<class 'NameMapper.NotFound'>"
Apr 12 05:12:32 raven reportengine[3074]: **** Message: "cannot find 'fubar' in template /home/weewx/skins/Standard/index.html.tmpl"
Apr 12 05:12:32 raven reportengine[3074]: **** Ignoring template and continuing.

Hai impostato un template che weeWX trova. In questo esempio, è il tag $fubar nel template /home/weewx/skins/Standard/index.html.tmpl.

Molti errori di LOOP con Davis Vantage

Il sintomo che ci siano molti errori di LOOP e download di archivi non realizzabili. Il tuo log potrebbe essere come 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

Se il tuo log è molto vicino a quello sopra, vedrai che ci sono delle istanze multiple di weeWX aperte simultaneamente (process IDs 5977, 6024, and 7543). Si stanno contendendo tra loro per il controllo della console, con conseguente perdita di pacchetti e record.

Il rimedio è semplice: killa tutti i processi tranne uno. O, meglio, killa tutti, allora avvia weeWX.

Dots in the plots – Punti nelle trame

Se vedi i punti al posto delle linee nei grafici giornalieri, dovresti cambiare le opzioni del grafico o regolare l’intervallo di archiviazione della stazione.

Nelle configurazioni di default, un intervallo di tempo più grande dell’1% del periodo di tempo visualizzato è considerato un gap nei dati. Pertanto, quando l’intervallo tra i punti dati è superiore a circa 10 minuti, i grafici giornalieri mostrano punti invece di punti collegati.

Cambia l’opzione line_gap_fraction in skin.conf per controllare quanto tempo è considerato una interruzione nei dati.

Come per l’intervallo di archiviazione, controlla il file di log per vedere ogni quanto tempo arriva il flusso in entrata dopo l’avvio di weeWX:

Dec 30 10:54:17 saga weewx[10035]: wxengine: The archive interval in the configuration file (300) does not match the station hardware interval (1800).
Dec 30 10:54:17 saga weewx[10035]: wxengine: Using archive interval of 1800

In questo esempio, l’intervallo in weewx.conf è 5 minuti, ma l’intervallo della stazione è 30 minutei. Quando l’intervallo in weewx.conf non combacia con l’intervallo della stazione hardware, weeWX rimanda all’intervallo della stazione.

Usa l’utility wee_device per cambiare l’intervallo della stazione.

Spikes in the graphs – picchi nei grafici

Occasionalmente potrai avere delle letture anomale, tipicamente manifestate come dei picchi nei grafici. La fonte potrebbe essere una cattiva connessione serial/USB, radio o altre interferenze, un adattatore USB-Serial economico, bassa qualità dei sensori, o semplicemente una anomalia nelle letture.

Questioni di qualità dei sensori. Non è insolito per alcuni hardware economici riportare occasionalmente dei dati sballati (ogni pochi giorni). Alcuni sensori, quali i sensori di radiazioni solari/UV, hanno una vita breve di circa 5 anni. Il sensore di umidità (analogico) sulle vecchie stazioni Vantage si potrebbe deteriorare dopo pochi anni in ambienti umidi.

Se vedi frequentemente delle anomalie nei dati, per prima cosa controlla l’hardware.

To keep bad data from the database, add a quality control (QC) rule such as Min/Max bounds. See the QC section for details.

Per rimuovere i dati errati dal database, dovrai dare dei comandi SQL. Per esempio, diciamo che la stazione emetteva temperature e velocità del vento molto elevate per una o due letture. Questo è come rimuoverle:

1. Ferma weeWX
2. Fai una copia dell’archivio database

   cp weewx.sdb weewx-YYMMDD.sdb

3. Verifica i dati errati dove tu creda essi siano

   sqlite3 weewx.sdb
   sqlite> select dateTime,outTemp from archive where outTemp > 1000;

4. Controlla se i dati errati di temperatura e di vento si siano verificati nello stesso momento

   sqlite> select dateTime,outTemp,windSpeed from archive where outTemp > 1000;

5. Rimuovi i dati errati settandoli a NULL

   sqlite> update archive set windSpeed=NULL where outTemp > 1000;
   sqlite> update archive set outTemp=NULL where outTemp > 1000;

6. Cancella le statistiche aggregate in modo che weeWX possa rigenerarli senza le anomalie

   sudo wee_database --drop-daily

7. start weeWX

‘Database is locked’ errore

Questo sembra sia un problema con il Raspberry Pi, quando ai usa SQLite. Non ci sono problemi anloghi con i database MySQL. Potrai vedere gli errori di log come questi:

Feb 12 07:11:06 rpi weewx[20930]: ****    File "/usr/share/weewx/weewx/archive.py", line 118, in lastGoodStamp
Feb 12 07:11:06 rpi weewx[20930]: ****      _row = self.getSql("SELECT MAX(dateTime) FROM %s" % self.table)
Feb 12 07:11:06 rpi weewx[20930]: ****    File "/usr/share/weewx/weewx/archive.py", line 250, in getSql
Feb 12 07:11:06 rpi weewx[20930]: ****    File "/usr/share/weewx/weedb/sqlite.py", line 120, in execute
Feb 12 07:11:06 rpi weewx[20930]: ****      raise weedb.OperationalError(e)
Feb 12 07:11:06 rpi weewx[20930]: ****  OperationalError: database is locked
Feb 12 07:11:06 rpi weewx[20930]: ****      _cursor.execute(sql, sqlargs)
Feb 12 07:11:06 rpi weewx[20930]: ****    File "/usr/share/weewx/weedb/sqlite.py", line 120, in execute
Feb 12 07:11:06 rpi weewx[20930]: ****      raise weedb.OperationalError(e)
Feb 12 07:11:06 rpi weewx[20930]: ****  OperationalError: database is locked

Stiamo provando a decifrare esattamente qual è il problema, ma sembra che (molti? La maggior parte? tutti?) implementazioni delle librerie di SQLite ‘C’ sul RPi si fermano per alcuni secondi se trova il database bloccato. Questo da ad esso solo cinque chances entro il periodo di timeout di 5 secondi prima che venga sollevata un’eccezione.

Non tutti i Raspberry Pi hanno questo problema. Sembra che sia molto acuto quando si fanno girare grandi template con un sacco di query, quali le estensioni meteo.

Ci sono pochi possibili aggiustamenti:

• Incrementa le timeout option.
• Usa un’alta qualità di carta SD nel tuo RPi. Sembra ci siano prove che una carta SD più veloce sia immune da questo problema.
• Taglia la grandezza del tuo template per minimizzare il numero delle query necessarie.

Nessuno di questi ‘aggiustamenti’ sono molto soddisfacenti quando stiamo provando a far girare una robusta soluzione.

Stringhe nel database

Se modifichi il tuo archivio SQLite usando uno strumento di modifica, occasionalmente le strinche strings will get incorporate in esso, provocando che weeWX sollevi delle eccezioni. Questo è solo un problema con SQLite. Non ci sono problemi analoghi con i database MySQL. Potrai vedere nel log di sistema qualcosa simile a questo:

Dec 31 17:01:06 arm weewx[18141]: **** File "/usr/share/weewx/weewx/wxengine.py", line 432, in __init__
Dec 31 17:01:06 arm weewx[18141]: **** self.setupStatsDatabase(config_dict)
Dec 31 17:01:06 arm weewx[18141]: **** File "/usr/share/weewx/weewx/wxengine.py", line 543, in setupStatsDatabase
Dec 31 17:01:06 arm weewx[18141]: **** self.statsDb.backfillFrom(self.archive)
Dec 31 17:01:06 arm weewx[18141]: **** File "/usr/share/weewx/weewx/stats.py", line 461, in backfillFrom
Dec 31 17:01:06 arm weewx[18141]: **** _statsDict.addRecord(_rec)
Dec 31 17:01:06 arm weewx[18141]: **** File "/usr/share/weewx/weewx/accum.py", line 305, in addRecord
Dec 31 17:01:06 arm weewx[18141]: **** self._add_value(record[obs_type], obs_type, record['dateTime'], add_hilo)
Dec 31 17:01:06 arm weewx[18141]: **** File "/usr/share/weewx/weewx/accum.py", line 264, in _add_value
Dec 31 17:01:06 arm weewx[18141]: **** self[obs_type].addSum(val)
Dec 31 17:01:06 arm weewx[18141]: **** File "/usr/share/weewx/weewx/accum.py", line 81, in addSum
Dec 31 17:01:06 arm weewx[18141]: **** self.sum += val
Dec 31 17:01:06 arm weewx[18141]: **** TypeError: unsupported operand type(s) for +=: 'float' and 'unicode'
Dec 31 17:01:06 arm weewx[18141]: **** Exiting.

Il problema è che la stringa unicode null deve stare NULL deve essere. L’utility wee_database può aggiustare questo. Falla girare con l’opzione –check-strings per cercare queste stringhe incorporate. Aggiugi l’optione –fix-strings per avere l’utility che ripari queste:

wee_database weewx.conf --check-strings --fix-strings

Python 2.5

WeeWX deve girare con Python versione 2.5, ma necessita di qualche aggiustamento.

La versione di pysqlite che deriva da Python 2.5 non supporta la dichiarazione “with”, la quale è richiesta da weeWX. Sfortunatamente, la più moderna versione di pysqlite da lungo non supporta Python 2.5, così dovrai installare la versione “intermediate”. Ho trovato la versione 2.5.6, la quale può essere scaricata da PyPI, lavora bene. Scaricala, spacchetta il tarball, poi usa l’incluso file setup.py per installarlo.

Dovrai probabilmente installare PIL, il quale può essere fatto usando apt-get, o più facilmente easy_install

Varie possibili complicazioni:

• Se il tuo hardware richiede PySerial (controlla Hardware Guide), tu devi avere la giusta versione. Sfortunatamente, la versione corrente del PySerial, e quella ottenuta di default da 3.x, non supporta Python 2.5 (o 2.6 per questa questione). Tu hai da installare PySerial V2.7, che potrai ottenre da SourceForge.
• Dovrai installare lo sviluppo di SQLite in modo da ottenere pysqlite da installare. Questo funziona nel mio sistema:

  apt-get install libsqlite3-dev

  Poi riavvia l’installazione di pysqlite.

• Quando avvii weeWX, tu potrai ottenere un errore come questo

  File "/usr/lib/python2.5/site-packages/PIL-1.1.7-py2.5-linux-x86_64.egg/ImageFont.py", line 218, in truetype
       return FreeTypeFont(filename, size, index, encoding)
  File "/usr/lib/python2.5/site-packages/PIL-1.1.7-py2.5-linux-x86_64.egg/ImageFont.py", line 134, in __init__
       self.font = core.getfont(file, size, index, encoding)
  File "/usr/lib/python2.5/site-packages/PIL-1.1.7-py2.5-linux-x86_64.egg/ImageFont.py", line 34, in __getattr__
       raise ImportError("The _imagingft C module is not installed")
  ImportError: The _imagingft C module is not installed

  Questo è perché la tua versione installata di PIL è stata compilata senza libfreetype, la quale è necessaria per i font FreeType usati nelle immagini generate. Tu puoi, o cambiare il font type (quarda nel file skin.conf), o fornisci la libreria mancante. Nota: se manca la libreria freetype, potresti perdere le altre. Questo è quello che ha funzionato con il mio sistema. YMMV.

  # Install the Freetype library:
  sudo apt-get install libfreetype6-dev
  # Make sure it, and the zlib library, are visible to easy_install
  sudo ln -s /usr/lib/x86_64-linux-gnu/libfreetype.so /usr/lib
  sudo ln -s /usr/lib/x86_64-linux-gnu/libz.so /usr/lib
  # Remove the PIL paths
  sudo easy_install -m PIL
  # Remove PIL itself:
  sudo rm -r /usr/lib/python2.5/site-packages/PIL*
  # Now rebuild PIL, this time with the right libraries
  sudo easy_install PIL

  Potrebbe essere necessario armeggiare con il percorso esatto utilizzato nel collegamento simbolico. Uno strumento utile è lo strumento Unix find. Ad esempio, la seguente scoperta dove si nascondeva la mia libreria freetype:

  find /usr/lib -name "libfreetype*" -print

Python 2.6

See the note about PySerial that can be found under the secton on Python 2.5 above.

FreeBSD

L’user Fabian riporta che la seguente operazione deve essere fatta per utilizzare la VantagePro2 sotto FreeBSD:

I needed the uslcom Driver for the usb/rs232 Adapter used by my vantage. Also I had to reset the memory of the weatherstation.
Loading the Driver:
Put uslcom_load="YES" in /boot/loader.conf (to load it as module).
Which gives here an output like:
uslcom0: <CP2102 USB to UART Bridge Controller> on usbus1
And put in weewx.conf:
port = /dev/cuaU0

Strani simboli nei grafici

Se i tuoi grafici hanno dei strani simboli come unità, come i gradi Fahrenheit (°F), che mostrano qualcosa uguale a questo:

Poi il problema potrebbe essere che ti mancano dei font specifici per l’opzione unit_label_font_path nel tuo file skin.conf e, invece, weeWX sta sostituendo il font di default, il quale non è supportato dai caratteri UTF-8 necessari per creare i grafici. Guarda nella sezione [ImageGenerator] per una linea uguale a questa:

unit_label_font_path = /usr/share/fonts/truetype/freefont/FreeMonoBold.ttf

Sii sicuro che il percorso specificato (/usr/share/fonts/truetype/freefont/FreeMonoBold.ttf in questo caso) esista veramente. Se no, sui sistemi operativi Debian (come Ubuntu), dovresti installare i font necessari:

sudo apt-get install fonts-freefont-ttf
sudo fc-cache -f -v

(Sui vecchi sistemi, il pacchetto fonts-freefont-ttf potrebbe essere chiamato ttf-freefont). Il primo comando installa il font “Truetype”, il secondo ricostruisce la font cache. Se il tuo sistema non ha il comando fc-cache, allora installa il pacchetto fontconfig:

sudo apt-get install fontconfig

Se nessuno di questi funziona, o se sei su un sistema operativo differente, poi dovrai cambiare l’opzione unit_label_font_path per fare in modo che il tuo sistema operativo supporti i caratteri UTF-8.

UnicodeEncodeError

Questo problema è fortemente connesso con il problema dei “Funky symbols” di cui sopra. In questo caso, potrai vedere gli errori nel log come mostrato:

May 14 13:35:23 web weewx[5633]: cheetahgenerator: Generated 14 files for report StandardReport in 1.27 seconds
May 14 13:35:23 web weewx[5633]: reportengine: Caught unrecoverable exception in generator weewx.imagegenerator.ImageGenerator
May 14 13:35:23 web weewx[5633]:         ****  'ascii' codec can't encode character u'\xe8' in position 5: ordinal not in range(128)
May 14 13:35:23 web weewx[5633]:         ****  Traceback (most recent call last):
May 14 13:35:23 web weewx[5633]:         ****    File "/usr/share/weewx/weewx/reportengine.py", line 139, in run
May 14 13:35:23 web weewx[5633]:         ****      obj.start()
May 14 13:35:23 web weewx[5633]:         ****    File "/usr/share/weewx/weewx/reportengine.py", line 170, in start
May 14 13:35:23 web weewx[5633]:         ****      self.run()
May 14 13:35:23 web weewx[5633]:         ****    File "/usr/share/weewx/weewx/imagegenerator.py", line 36, in run
May 14 13:35:23 web weewx[5633]:         ****      self.genImages(self.gen_ts)
May 14 13:35:23 web weewx[5633]:         ****    File "/usr/share/weewx/weewx/imagegenerator.py", line 220, in genImages
May 14 13:35:23 web weewx[5633]:         ****      image = plot.render()
May 14 13:35:23 web weewx[5633]:         ****    File "/usr/share/weewx/weeplot/genplot.py", line 175, in render
May 14 13:35:23 web weewx[5633]:         ****      self._renderTopBand(draw)
May 14 13:35:23 web weewx[5633]:         ****    File "/usr/share/weewx/weeplot/genplot.py", line 390, in _renderTopBand
May 14 13:35:23 web weewx[5633]:         ****      top_label_size = draw.textsize(top_label, font=top_label_font)
May 14 13:35:23 web weewx[5633]:         ****    File "/usr/lib/python2.7/dist-packages/PIL/ImageDraw.py", line 278, in textsize
May 14 13:35:23 web weewx[5633]:         ****      return font.getsize(text)
May 14 13:35:23 web weewx[5633]:         ****  UnicodeEncodeError: 'ascii' codec can't encode character u'\xe8' in position 5: ordinal not in range(128)
May 14 13:35:23 web weewx[5633]:         ****  Generator terminated...

Questo è frequentemente causato dai necessari font Truetype non installati sul tuo computer e, invece, un font di default è stato sostituito dai caratteri ASCII. La cura è come la precedente: installa il font.

I dati sono archiviati ma alcuni/tutti i report non funzionano

Se weeWX sembra girare normalmente ma alcuni report sembra non funzionano, sempre o periodicamente, il problema potrebbe essere un uso inavvertito o delle impostazioni non corrette delle opzioni report_timing in weewx.conf. L’opzione report_timing abilita l’user a specificare quando alcuni o tutti report girano (vedi Customizing the report generation time). Di default l’opzione report_timing è disabilitata e tutti i report girano ad ogni periodo di archivio.

Per vedere l’opzione report_timing sta causando il salto dell’opzione log file. Ogni report che è saltata può essere mostrata nel log come di seguito:

Apr 29 09:30:17 rosella weewx[3319]: reportengine: Report StandardReport skipped due to report_timing setting

Se i report vengono saltati in modo errato a causa di report_timing, quindi modificare weewx.conf e verificare la presenza dell’opzione report_timing in [StdReport]. Rimuovere tutte le occorrenze di report_timing per eseguire tutti i report ogni periodo di archiviazione o confermare l’uso e l’impostazione corrette dell’opzione report_timing.

I report errati vengono saltati da report_timing

Se viene utilizzata l’opzione report_timing e i risultati non sono come previsto, potrebbe esserci un errore nell’opzione report_timing. Se ci sono errori nel parametro report_timing, il report verrà eseguito su ciascun intervallo di archivio. Innanzitutto controlla i parametri dell’opzione report_timing per assicurarti che siano validi e non ci siano spazi aggiuntivi o altri caratteri indesiderati. Quindi verificare che i parametri siano impostati correttamente per i tempi di generazione del rapporto desiderati. Ad esempio, se è corretto il numero del giorno della settimana utilizzato se si limita il parametro del giorno della settimana. Vedi la Customizing the report generation time.

Controlla il log file per eventuali voci relative alle segnalazioni interessate. Errori nei parametri report_timing e i rapporti saltati vengono registrati solo quando debug=1 in weewx.conf.

Problemi Meteorologici

La pressione reportata da weeWX non coincide con la pressione della console

Sii sicuro che stai comparando i valori giusti. Ci sono tre differenti tipi di pressione:

Station Pressure

La Pressione della Stazione (SP), che è la pressione assoluta grezza misurata dalla stazione. Questa è la pressione nei pacchetti weeWX e nei registri degli archivi.

Sea Level Pressure

La Pressure al livello del mare (SLP) è ottenuta dalla connessione della pressione della stazione, dall’altitudine e dalla temperatura. Questa è barometer nel pacchetto weeWX packets e nei dati archiviati+.

Altimeter

The Impostazioni dell’altimetro (AS) è ottenuto dalla connessione della Pressione della stazione con l’altitudine. Questo è il pacchetto altimeter in weeWX e i dati archiviati.

Tutte le stazioni potrebbero richiedere una calibrazione. Per alcuni hardware, questo può essere fatto sulla console della stazione meteo. In alternativa, utilizzare la sezione StdCalibrate per applicare un offset.

Se la tua stazione è significativamente sopra (o sotto) il livello del mare, assicurati che l’altitudine della stazione sia specificata correttamente. Inoltre, assicurati che qualsiasi calibrazione porti a una pressione di stazione e/o a una pressione barometrica corrispondente a quella riportata da altre stazioni nella propria area.

Calibrando il barometro non cambia la pressione mostrata da weeWX

Sii sicuro che la calibrazione sia applicata alla quantità corretta.

Le correzioni nella sezione StdCalibrate si applica solo ai valori grezzi dall’hardware; le correzioni non sono applicate alle quantità derivate.

L’hardware della stazione è importante. Alcune stazioni riportano la pressione relativa (pressione) mentre altre stazioni riportano la pressione a livello del mare (barometro). Ad esempio, se l’hardware è una stazione Vantage, la correzione deve essere applicata al barometro poiché la stazione Vantage segnala il barometro e weeWX calcola la pressione. Tuttavia, se l’hardware è una stazione FineOffset, la correzione deve essere applicata alla pressione poiché le stazioni FineOffset riportano la pressione e weeWX calcola il barometro.

La pioggia e/o l’intensità di pioggia riportata da weeWX non corrisponde alla console

Prima di tutto, assicurati di confrontare le quantità giuste. Il valore pioggia è la quantità di pioggia osservata in un periodo di tempo. Il periodo di tempo potrebbe essere un intervallo LOOP, nel qual caso la pioggia è la quantità di pioggia dall’ultimo pacchetto LOOP. Oppure il periodo di tempo potrebbe essere un intervallo di archivio, nel qual caso la pioggia è il totale di pioggia riportato in ogni pacchetto LOOP dall’ultimo record di archivio.

Alcuni report della console riportano la pioggia nell’ultima ora, o la somma della pioggia dalla mezzanotte.

L’intensità di pioggia è una quantità derivata. Alcune stazioni misurano l’intensità di pioggia, ma alcune non lo fanno, così weeWX calcolerà l’intensità di pioggia.

Sii sicuro che le unità siano corrette.

Infine, fai attenzione ai fattori di calibrazione specifici dell’hardware. Ad esempio, il tipo di benna su una stazione Vantage deve essere specificato quando si imposta la stazione meteorologica. Se modifichi il secchio pioggia con un’area di raccolta più ampia, dovrai aggiungere un moltiplicatore nella sezione StdCalibrate.

Per diagnosticare problemi di pioggia, esegui direttamente weeWX in modo da poter vedere ogni pacchetto LOOP e record dell’archivio REC. Inclina il pluviometro per verificare che ogni movimento sia rilevato e segnalato da weeWX. Verificare che ogni movimento della benna sia convertita nella quantità di pioggia corretta. Quindi controllare il database per verificare che i valori siano aggiunti e registrati correttamente.

Non c’è direzione del vento quando il vendo è zero

Questo è da progetto – se non c’è vento, allora la direzione del vento è indefinita. Un valore indefinito è rappresentato da un valore NULL nel database o None in Python. Questa pratica è forzata dal servizo StdWXCalculate. Se necessario, può essere sovrascritto. Vedi all sezione StdWXCalculate per le istruzioni.

WeeWX distingue tra un valore zero e nessun valore (NULL or None). Comunque, alcuni servizi non fanno distinzione e rimettono un valore NULL o None con un valore chiaramente non valido come -999.