Ciao a tutti! Mi chiamo Nicola e sono felice di partecipare a questo forum con uno spirito un po' diverso da quello che avevo qualche anno fa quando mi ci sono avvicinato per la prima volta!
E' stato infatti grazie a voi che ho potuto scoprire un modo alternativo di leggere e registrare i dati dalla mia WH1080, relegata quasi a soprammobile a causa della ...ehm... "qualità" della sua console, ed ora che ho imparato qualcosina di più volevo proprio ringraziarvi tutti, a partire dall'immenso Tony.
Grazie a lui, ma anche a tutti voi: con le vostre domande, risposte e proposte ho imparato qualcosina ravanando con la mia RaspberryPi ed il mio modulino RFM01, con i suoi pregi e pure con i suoi difetti.

Ora vorrei proprio contraccambiare, e lo faccio informandovi che da qualche giorno il progetto open source rtl_433 (che forse alcuni di voi conoscono) integra il modulo per la decodifica dei dati della stazione meteo Fine Offset WH1080. Non solo i dati meteo, ma anche i segnali di tempo DCF77 che la stazione trasmette all'inizio delle ore pari.
Per chi non lo conosce, 'rtl_433' è un programma open source gratuito a struttura modulare in continuo sviluppo, e di tanto in tanto vi viene aggiunto dagli appassionati un nuovo modulo per la decodifica di nuovi tipi di sensore. Io vi ho aggiunto, ad esempio, quello per la decodifica della WH1080.
Più in generale, 'rtl_433' riesce a decodificare diversi sensori di temperatura/umidità tra cui alcuni Oregon Scientific, alcuni modelli di apparecchi LaCrosse, sensori di consumo energetico, sensori di livello di gasolio all'interno di cisterne... Tutti operanti negli spettri di frequenza 433Mhz, 868Mhz, 915Mhz e tutti ricevibili collegando al pc una chiavetta USB nata per ricevere i normali programmi TV dal costo irrisorio, la si trova molto facilmente anche attorno ai 10 Euro su Ebay.
Attenzione però: Non una chiavetta TV qualsiasi! Deve essere basata sul chipset Realtek RTL2832U, con tuner Rafael Micro R820T oppure R820T2.

Poiché la stazione PCE-FWS 20 che molti di voi posseggono sembrerebbe essere un rebranding (una ri-marchiatura per così dire) della Fine Offset WH1080, ci sono buone speranze che sia possibile leggere i dati provenienti dai suoi sensori wireless utilizzando una Raspberry e la chiavetta USB, anzichè l'RFM01 che a volte (almeno per mia esperienza) è un po' capricciosetto.

Questo offre indubbiamente nuovi potenziali orizzonti anche a Sint Wind PI (a patto naturalmente di riscrivere parte del codice che lo compone):
innanzitutto la migliore sensibilità, efficienza e stabilità della soluzione rtl_433 + chiavetta USB. Ad esempio la mia WH1080 tende a slittare in frequenza con gli sbalzi di temperatura, ed il modulo RFM01 era un po' schizzinoso con tali slittamenti.
Ora il problema è risolto: ogni 48 secondi, puntuale, arriva l'aggiornamento dalla WH1080.
Poi l'output di rtl_433 che può essere impostato in formato json, e tramite piping può 'iniettare al volo' direttamente in uno script python i dati ricevuti affinché li processi.
Ciò significa allungare la durata della SDcard in modo significativo rispetto all'attuale metodo di scambio dati tramite scrittura e riscrittura di un file.
Inoltre sarebbe possibile sincronizzare data ed ora della Raspberry con quella dell'orologio atomico di Francoforte (Germania) grazie alla decodifica dei segnali di tempo DCF77, la stessa usata da milioni di radiosveglie in tutta Europa. Può tornare utile nei casi di mancanza di connessione dati o di errore di un eventuale modulo RealTime Clock!
Infine il processo di decodifica utilizza poca CPU: ho rilevato che il processo rtl_433 si attesta attorno al 15% in una 'vecchia' Raspberry model B.

Ma c'è di più: dopo aver creato il modulo WH1080 per rtl_433, già che c'ero ho pensato di 'confezionarne' a fini di test una versione particolare, specifica per RaspberryPi e per BananaPi (quest'ultima parte spero farà la gioia di chi in un altro post sta cercando di cavarne fuori qualcosa ). In poche parole ho incorporato in rtl_433 del codice per la lettura dei dati del sensore barometrico BMP085 (o BMP180), ottenendo così un programma in grado di ricevere i dati dalla WH1080 e contemporaneamente leggere quelli del sensore barometrico, collegato alla Raspberry/Bananapi come di consueto, presentandoli tutti assieme nell'output (anche in json).

Funziona perfettamente e ininterrottamente da qualche settimana, testato sia su RaspberryPi model B che su model B+, e con una minuscola modifica del codice (un carattere) anche su BananaPi M1. DOVREBBE funzionare pure su RaspberryPi 2.
Se vi va di provarlo e doveste riscontrare anomalie potremo vedere assieme, tempo permettendo, cosa si può fare per risolverle.

Di seguito un esempio dell'output del programma mentre è in esecuzione su BananaPi M1 (l'output è comunque identico su Raspberry):


2016-02-24 14:07:37 : Fine Offset WH1080 weather station
Msg type: 0
StationID: 0005
Temperature: 12.6 C
Humidity: 41 %
Pressure: 1015.41 hPa
Wind string: NNE
Wind degrees: 23
Wind avg speed: 11.02
Wind gust: 19.58
Total rainfall: 255.0
Internal temp.: 18.0 C
2016-02-24 14:08:26 : Fine Offset WH1080 weather station
Msg type: 0
StationID: 0005
Temperature: 12.6 C
Humidity: 41 %
Pressure: 1015.43 hPa
Wind string: E
Wind degrees: 90
Wind avg speed: 8.57
Wind gust: 15.91
Total rainfall: 255.0
Internal temp.: 18.0 C


Questo invece è l'output per i segnali di tempo. Come già detto si ricevono all'inizio delle ore pari (in questo caso le 14).
Notare il "Msg type" che nei dati meteo era '0', mentre in quelli di tempo è '1':



2016-02-24 14:05:14 : Fine Offset WH1080 weather station
Msg type: 1
StationID: 0005
Hours: 14
Minutes: 05
Seconds: 13
Year: 2016
Month: 02
Day: 24
2016-02-24 14:06:01 : Fine Offset WH1080 weather station
Msg type: 1
StationID: 0005
Hours: 14
Minutes: 06
Seconds: 01
Year: 2016
Month: 02
Day: 24
2016-02-24 14:06:50 : Fine Offset WH1080 weather station
Msg type: 1
StationID: 0005
Hours: 14
Minutes: 06
Seconds: 49
Year: 2016
Month: 02
Day: 24


Si può ben vedere che il clock interno della BananaPi era avanti di un secondo rispetto al tempo DCF77 rilevato dalla WH1080.

Ecco infine come si presenta l'output json. Questo è estremamente utile perchè fornisce i dati già suddivisi per 'campi', pronti per l'elaborazione tramite (ad esempio) python:


{"time" : "2016-02-24 14:20:25", "model" : "Fine Offset WH1080 weather station", "msg_type" : 0, "id" : 5, "temperature_C" : 12.600000, "humidity" : 41, "pressure" : 1015.483215, "direction_str" : "SE", "direction_deg" : "135", "speed" : 8.568000, "gust" : 12.240000, "rain" : 255.000015, "int_temp" : 18.000000}


{"time" : "2016-02-24 14:20:26", "model" : "Fine Offset WH1080 weather station", "msg_type" : 0, "id" : 5, "temperature_C" : 12.600000, "humidity" : 41, "pressure" : 1015.423157, "direction_str" : "SE", "direction_deg" : "135", "speed" : 8.568000, "gust" : 12.240000, "rain" : 255.000015, "int_temp" : 18.000000}


{"time" : "2016-02-24 16:03:38", "model" : "Fine Offset WH1080 weather station", "msg_type" : 1, "id" : 5, "the_hours" : 16, "the_minutes" : 3, "the_seconds" : 37, "the_year" : 16, "the_month" : 2, "the_day" : 24}


{"time" : "2016-02-24 16:04:25", "model" : "Fine Offset WH1080 weather station", "msg_type" : 1, "id" : 5, "the_hours" : 16, "the_minutes" : 4, "the_seconds" : 25, "the_year" : 16, "the_month" : 2, "the_day" : 24}


{"time" : "2016-02-24 16:05:14", "model" : "Fine Offset WH1080 weather station", "msg_type" : 1, "id" : 5, "the_hours" : 16, "the_minutes" : 5, "the_seconds" : 13, "the_year" : 16, "the_month" : 2, "the_day" : 24}



Concludo questo lungo post (scusatemi) con i link al progetto rtl_433 ed alla mia 'special edition', che si chiama 'raspberry_rtl_wh1080'.
Per entrambi la documentazione è in inglese. In caso di difficoltà con la lingua, nei limiti del possibile, sono qua.
I programmi ed i sorgenti sono liberi e gratuiti (sotto licenza GNU-GPL), buon divertimento a chi ci vorrà smanettare


rtl_433: https://github.com/merbanan/rtl_433

raspberry_rtl_wh1080: https://github.com/ovrheat/raspberry_rtl_wh1080



Grazie a tutti ed un saluto.
Nik


P.S.: Tony, se vuoi ora sì che c'hai da divertirti!...

Tony, invece per la sezione dedicata alla pce che sembra irraggiungibile qual è la situazione? Si riesce a risolvere?

@Tony: Grazie ancora a te, davvero! Desolatissimo per la PCE... Povera, cosa le è successo?

@Ale: Grazie anche a te! Un articolo sul tuo tuo blog è stato uno dei trampolini di partenza qualche tempo fa quando sono partito a caccia di informazioni sul protocollo e sul modo di decodificarlo.
Prova la chiavetta con il progetto rtl_433 , al quale ho contribuito con il 'driver' per la PCE/WH1080 e da cui deriva il mio, vedrai che ti diverti!

Ho appena dato un'occhiata alle offerte di oggi e ce ne sono di buone, tuttavia non so se posso postare qua i link per la famosa questione della pubblicità... Sostanzialmente la chiavetta deve essere basata sul chip Realtek RTL2832U (che è l'interfaccia USB della chiavetta stessa) e sul tuner R820T che è ovviamente il chip usato come sintonizzatore. Meglio ancora se il tuner è R820T2, che è più recente e sensibile. La chiavetta è nera, guarda qui , o azzurra nel caso di quelle contenenti l'R820T2 ( eccola qui ). I prezzi più convenienti (ne ho appena viste in vendita a meno di 8 euro cad.) li trovi dai venditori cinesi, ma i tempi di arrivo in Italia possono essere anche di 40-50 giorni. Meglio un venditore UK, costa leggermente di più ma arriva prima Se c'è un modo di mandarti un PM ti invio i link delle offerte migliori.

Tu non immagini nemmeno cosa non si può fare con quella chiavetta...

A presto Ale

Buongiorno a tutto il forum,
usare la chiavetta /ricevitore realteck RTL è un' ottima idea perchè casualmente avevo a suo tempo acquistato il ricevitore per altri esperimenti che per il momento avrei abbandonato.
Questa opportunità che propone Seven è una grande possibilità per poter liberare la console dal raspberry e portarla in giro per la casa.
La mia esperienza si utilizzo linux/raspberry è molto scarsa e avrei una certa difficoltà a seguire tutti i passaggi per poter inserire il codice relativo all'interno della mirosd del raspberry.
Chiederei per cortesia a Seven se potesse postare da qualche parte una iso completa per il raspberry B+ per poter testare questo suo interessante lavoro.

Grazie Alegrechi per avermi risposto, allora aspetto ulteriori sviluppi del driver cosi invece di lasciare la console in soffitta me la porto in appartamento per vedere i dati in diretta.Buona serata

Ciao a tutti!
Grande Ale, non avevo dubbi che saresti riuscito a farlo funzionare
Lo script che uso io è 'svincolato' da SWPI, nel senso che non necessitando delle fantastiche opzioni di quest'ultimo ho optato per il salvataggio diretto dei dati su server MySQL anziché FTP per le successive statistiche. Tuttavia non credo sarà un problema creare qualcosa ad hoc, seguendo poi le indicazioni di Tony per provare magari ad integrarlo successivamente in SWPI. Dammi qualche giorno che mi organizzo e poi ti girerò già qualcosina con cui giocare.
Intanto (OT...) a proposito di giocare con la chiavetta dai un'occhiata qui:
http://diarioradio.blogspot.it/2014/04/installazione-dongle-rtl-sdr-con-il.html


@linxis: volentieri per l'ISO, tranquillo che presto sistemiamo tutto.

Onoratissimo di essere citato nel tuo seguitissimo blog! Grazie ale!
Sto già scervellandomi anch'io su come implementare l'ambaradan in SWPI. Come plugin non sarebbe male effettivamente. Però (senza ancora aver approfondito la parte tecnica) penso che sarebbe utile "spegnere" il processo wh1080_rf (che a quel punto sarebbe inutile) e mi chiedo se da plugin questo è possibile. Altrimenti occorrerà creare un nuovo driver, diciamo così, da poter selezionare e che escluda completamente il RFM01 e relativi processi... Pensiamoci un po', e sotto con gli smanettamenti
Ottimo anche l'approccio NodeJs, mi farai vedere se vuoi. Io avrei pensato addirittura anche a MQTT... Avere i dati in json offre un mare di possibilità!

Ho cominciato a giocare con rtl433 ed ho provato ad inserire altri parametri, calcolati e non. Questo è il mio attuale output
X seven ...
ho notato un problema in fase di compilazione modificando l'altezza, se inserisco 430 da un errore al primo tentativo e va a buon fine al secondo.

In queste condizioni la pressione non corrisponde a quella di swpi, se invece inserisco come valore dell'altezza 0.430 non ho errore in compilazione e la pressione è coerente. Qualcuno ha notato questa cosa?

Roberto, ottimo lavoro direi! Bella l'aggiunta dei campi!
Grazie al tuo feedback ho trovato (e spero corretto) la magagna. Ora in github c'è il codice riveduto e corretto, ma se vuoi aggiornare la tua copia per evitare di perdere le modifiche che hai fatto basta che cambi queste due righe in fineoffset_wh1080.c :

La riga nella quale va indicata l'altitudine cambiala da

a

(naturalmente sostituisci '10' con la tua altitudine);



Infine sostituisci la riga (mi pare sia la n.324):

con



Ora dovrebbe andare, altrimenti vediamo cosa c'è da fare.

Nel frattempo sto provando ad implementare il driver per SWPI.....

Ciaoo!

Ciao Seven, in effetti avevo già risolto, forse in maniera un po' più spartana
Mi pare ci siano anche problemi con la pressione quella che invia non è l'assoluta ma la relativa.
Comunque puoi scaricare il file qui www.iw1pur.com/download/fineoffset_wh1080.zip
e darci un'occhiata.
Ci sono anche altri campi
Ovviamente chiunque può scaricarlo e testarlo

Spettacolo ragazzi, grazie per i vostri contributi, c'è sempre qualcosa da imparare. Non vedo l'ora di darci un'occhiata!
@Ale: tranquillo, preparati a far presto da cavia
@Roberto: si la pressione è calcolata sulla base dell'altitudine della stazione. Se desideri quella 'grezza' in hPa così come rilevata dal sensore devi modificare la già citata riga n.324 (EX 324... Con la modifica di oggi è diventata la n.323 in GitHub) sostituendola con:

Seven ... Scarica il file
Ciao

Bello, bello!! Potremmo farne una special-edition
Forse c'è qualcosa da ricontrollare nella sezione lettura della pressione relativa (hPr), che nelle mie prove mi esce un inquietante 1075.7, ma sono sicuro che sarà una sciocchezzuola, via.
Come hai già visto non ci vuole poi molto ad aggiungere ulteriori moduli e personalizzazioni. In questi giorni stavo pensando addirittura ad un sensore luminosità e/o UV da connettere alla Rasp, li ho visti su Ebay ma non li ho ancora provati. Candidamente ammetto di non aver mai approfondito se sia già stato per caso implementato da Tony in SWPI, nel qual caso sarebbe come reinventare la ruota...
Non credo comunque che sarebbe una missione impossibile, è più che altro una questione di avere del tempo libero...
Devo anche provare lo script di Ale, che mi incuriosisce assai.

Certamente Ale per quanto riguarda il merge dei sensori, me ne sto rendendo conto in questi giorni di "vivisezione" di swpi. Avete fatto fatto un ottimo lavorone!
A proposito ho praticamente finito l'interfacciamento al template del nuovo driver RTL_433, ora mi manca la parte "esecutiva". Vorrei però evitare se possibile il metodo di wh1080_rf del "file di scambio dati", preferirei riuscirci con un piping diretto. Prima possibile farò qualche prova e poi giù di beta-testing!

Per il sensore di pressione confermo che in sua assenza (o malconfigurazione) il raspberry_rtl_wh1080 crasha senza restituire alcunché; questo perché si tratta di una soluzione che ne prevede espressamente la presenza. Se desideri fare qualche esperimento in assenza del sensore ti conviene provare direttamente rtl_433 , da cui il mio progetto deriva. Il driver che riconosce la WH1080 è lo stesso, gli manca solo la parte barometrica. Avvialo con

-R 32 è il protocollo (driver) Fine Offset WH1080.

Buongiorno a tutti,
come sempre complimenti per il lavoro che fate!

Da utilizzatore volevo portarvi alcune considerazioni:

Avendo un raspberry pi2, non potevo installare il modulo RFM01 perché non ancora supportato. Di conseguenza dovevo tenere la consolle sempre collegata al raspberry.

Bene, questo a cosa comportava?
Essendo insista nel sint la sincronizzazione a 1 minuto, veniva forzata la ricezione dati ad 1 minuto (da mantenere tale per evitare problemi di stabilità).

Tuttavia, così facendo, la mole di dati era davvero cospicua ed ero molto soggetto a dati sballati (aumentando la quantità di dati mi espongo di più ad errori) che ogni volta dovevo eliminare da cumulus.
Non solo, il software free "easywheater" in dotazione alla stazione, dal quale si settava la ricezione dati (con minimo 2 minuti), dopo che la consolle veniva staccata dal raspberry e attaccata a pc per scaricare, non rispondeva più e occorrevano diversi tentativi per farlo ripartire.

Quindi, a malincuore, mi crollava tutto proprio per l'RFM01 o comunque per l'impossibilità di tenere la consolle libera. Per me sarebbe molto importante separare le cose: ossia sfruttare la consolle per la raccolta e rielaborazione dati e sfruttare questo sistema o l'RFM01 o altro per l'invio al raspberry e la pubblicazione sul web.

Ora con questa nuova possibilità si riaprono le porte!

Credo che altri utilizzatori fossero bloccati come me per questo problema, quindi rinnovo i complimenti per il grandissimo lavoro che state facendo e, curioso, resto in attesa di novità

Grazie Giacomo!
E' grazie a quelli che di solito si definiscono 'semplici utenti' che si va avanti e si prova a fare qualcosa di utile. Senza il vostro feedback non ci sarebbe modo di migliorare le funzionalità, correggere le magagne ed allo stesso tempo affinare le proprie conoscenze. E' un prezioso dare-avere che va a beneficio di tutti.
Presto ci sarà bisogno di provare nuove funzioni, se lo desideri tieniti pronto
Ciao!

ciao a tutti, premetto che non utilizzo sint-windpi in quanto sto realizzando ua cosa particolare e non ho necessità del software completo ma devo solamente ricevere i dati. Possiedo una PCE-PSW20, che funziona correttamente tramite la sua consolle, ho installato sulla mia raspberry PI 2 il modulo in oggetto, tutto sembra andato a buon fine, non ho ricevuto errori in fase di compilazione, ma quando lancio il comando:

rtl_433 -f 868300000 (oppure 868400000 o 86820000) -F son -l 0

non ricevo alcun output!
Però se lancio il comando:

rtl_433 -f 868300000 -a -t

Registering protocol "Fine Offset WH1080 Weather Station"
Found 1 device(s):
0: Realtek, RTL2838UHIDIR, SN: 00000001

Using device 0: Generic RTL2832U OEM
Found Rafael Micro R820T tuner
Exact sample rate is: 250000.000414 Hz
[R82XX] PLL not locked!
Sample rate set to 250000.
Bit detection level set to 8000.
Tuner gain set to Auto.
Reading samples in async mode...
Tuned to 868400000 Hz.
*** signal_start = 6332186, signal_end = 6450516
signal_len = 118330, pulses = 174
Iteration 1. t: 243 min: 121 (62) max: 365 (112) delta 10
Iteration 2. t: 243 min: 121 (62) max: 365 (112) delta 0
Pulse coding: Short pulse length 121 - Long pulse length 365

Short distance: 243, long distance: 244, packet distance: 7750

p_limit: 243
bitbuffer:: Number of rows: 2
[00] {87} 00 be fa 81 a5 fb f9 ff ff e6 b8
[01] {87} 00 be fa 81 a5 fb f9 ff ff e6 b8
signal_bszie = 262144 - sg_index = 524288
start_pos = 55974 - buffer_size = 3145728
*** Saving signal to file gfile001.data
*** Writing data from 55974, len 262144

ricevo "qualcosa", e mi crea i file gfile00x.data, se provo ad aprirli:

rtl_433 -R 01 -r gfile001.data

Registering protocol "Fine Offset WH1080 Weather Station"
Test mode active. Reading samples from file: gfile001.data
Input format: uint8
Test mode file issued 2 packets

non ci sono i dati della stazione meteo , può essere la mancanza del modulo bmp810 che non possiedo?

grazie.

ho provato ad installare il driver generico rtl_433 (non modificato per la gestione del sensore di pressione), ma non ricevo ugualmente i dati.
Cercando in rete il problema sembra che i dati che ricevo non corrispondono a quelli del Registering protocol "Fine Offset WH1080 Weather Station", questa è la stringa che ricevo con rtl_433 -f 868300000 -a:

[00] {87} 00 be fa 81 a5 fb f9 ff ff e6 b8
[01] {87} 00 be fa 81 a5 fb f9 ff ff e6 b8

mi confermate che dovrebbe esserci un 88 al posto di 87, qualcuno riesce a fare la prova con la sua stazione?

Confermo che la consolle riceve correttamente i dati da tutti i sensori, non so più dove sbattere la testa, l'unica cosa che non avevo collegato era il pannello solare che ricarica le batterie, se provo a collegarlo la consolle non riceve più alcun dato. In teoria non bi dovrebbe essere alcun sensore all'interno del pannellino solare, dovrebbe servire solamente a ricaricare le batterie è corretto?

grazie.