consumo/produzione dati invertiti

[leo66]

Non si vede se hai tolto il # ad inizio riga

screen originale, senza nessun ritaglio

[Flane]

Ho paura che il problema sia di fastweb che blocca il server NTP che dovrebbe aggiornare l'orario del raspberry.
Ci sono in rete divese discussioni a riguardo
NTP servers irraggiungibili

Se non erro anche Dolam ha più volte discusso il problema sul forum di EA, ed impostava a mano lui data e ora.

Ho avuto anch'io problemi con l'ora del raspberry quando sono passato da ADSL Telecom ad un provider wifi, ma ho risolto con il mio provider che mi ha permesso l'accesso ad un suo server NTP che ho aggiunto nel file di configurazione del raspberry.

Certo Leo che sei incappato proprio in tutti i problemi possibili ....
dopo l'elettricista ... ora anche fastweb ed i server NTP ....

In serata vedo di darti qualche dritta che mi sono appuntato su un file che ho sul PC a casa (e che ora non posso raggiungere) per testare il funzionamento e la raggiungibilità dei server NTP dal raspberry.

[leo66]

Ho paura che il problema sia di fastweb che blocca il server NTP che dovrebbe aggiornare l'orario del raspberry.
Ci sono in rete divese discussioni a riguardo
NTP servers irraggiungibili

Se non erro anche Dolam ha più volte discusso il problema sul forum di EA, ed impostava a mano lui data e ora.

Ho avuto anch'io problemi con l'ora del raspberry quando sono passato da ADSL Telecom ad un provider wifi, ma ho risolto con il mio provider che mi ha permesso l'accesso ad un suo server NTP che ho aggiunto nel file di configurazione del raspberry.

Certo Leo che sei incappato proprio in tutti i problemi possibili ....
dopo l'elettricista ... ora anche fastweb ed i server NTP ....

In serata vedo di darti qualche dritta che mi sono appuntato su un file che ho sul PC a casa (e che ora non posso raggiungere) per testare il funzionamento e la raggiungibilità dei server NTP dal raspberry.

ok,grazie flane
attendo le tue "dritte"...

[Walter62]

Io in passato avevo un abbonamento Fastweb ma non ho mai avuto problemi di aggiornamento dell'ora, tra l'altro, da quello che ho capito non è che l'ora sia sbagliata, è sempre diversa di due ore, sintomo di fuso orario differente

[leo66]

Il picco è un bug individuato da Jack qualche giorno fà:
viewtopic.php?f=4&t=1889&p=3229#p3229

Il problema si presenta solo su sistemi nuovi con la scrittura del primo csv, ma poi sballa tutti i dati. (ecco perchè a me non è mai capitato)
E' comunque facilmente risolvibile editando il file /var/www/comapps/pool123s.php

Fai quando di seguito:
- fermi metern
- cancelli tutti i file .csv nella cartella /var/www/metern/data
- editi il file /var/www/comapps/pool123s.php e alla riga 56 trovi:

Codice: Seleziona tutto

if ($xdays > 1) {

e deve essere modificata come di seguito:

Codice: Seleziona tutto

if ($xdays > 0) {

- salvi il file e riavvii metern

Ora dovrebbe tutto funzionare per benino.

questo dovrebbe essere sistemato: il picco che si vedeva gli altri giorni alle 7(che poi erano le 9..) stamattina non c'e' piu'

[Flane]

Per il discorso dell'ora verifichiamo se i server NTP ripondono.

Da terminale esegui:

Codice: Seleziona tutto

ntpq -pn

Dovresti vedere una tabellina con le risposte tipo:

Codice: Seleziona tutto

root@raspberrypi:~# ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+192.168.3.1     158.58.170.253   4 u  722 1024  377    0.656    1.133   1.109
+158.58.170.253  37.247.53.178    3 u 1005 1024  377   15.353    1.785   2.690
*94.23.66.89     37.247.53.178    3 u  356 1024  377   16.269    0.739   5.625
+212.45.144.88   37.247.53.178    3 u  693 1024  377   18.516   -0.176   1.795
+212.45.144.206  37.247.53.178    3 u  580 1024  377   14.834    1.631   1.894
+193.234.225.237 37.247.53.178    3 u  463 1024  377   14.701    0.228   1.274


Sarà diversa dalla mia, perchè io ho aggiunto dei server, ma l'importante è che vedi i dati di riposta.
Prova e posta il risultato.

PS: Leo NON AGGIORNARE NIENTE Ho visto su EA che stai tentando di aggiornare. Le nuove versioni hanno dei problemi.
Qualcuno un giorno mi spiegherà perchè avete sempre questa smania di aggiornare......
STAI FERMO !!! cerchiamo di far funzionare tutto prima di creare ulteriori problemi.

[leo66]

eseguiro' stasera quando torno a casa.
per l'aggiornamento,ho gia' desistito.grazie comunque per il consiglio

[leo66]

riguardo il discorso dell'orario falsato, ho chiesto nel forum fastweb al riguardo.ho cercato di spiegare quale sia il problema e a cosa serve il raspberry
incollo la risposta di un' utente che asserisce:

non è che fastweb "blocchi" l'accesso a server ntp le cose stanno in un altro modo,
ovvero se sei dietro nat (ovvero non hai ip pubblico sulla wan e anche se non lo hai specificato deduco che sia il tuo caso...) ciò che succede è che sono gli ntp server interrogati che non rispondono (qui non mi dilungo sulle motivazioni tecniche, se ne è parlato già in altri thread, puoi ritrovarli con la funzione "cerca" del forum).
La soluzione è appunto chiedere ip pubblico e vedrai che potrai tranquillamente utilizzare qualsivoglia ntp server (io sul mio router/firewall ne ho impostati 8 in pool).
In cima ti consiglio per ovvi motivi di impostarne uno appartenente alla rete fastweb, ad esempio: 10.16.0.62[i]

ho risposto di avere l'ip pubblico e lui ha scritto:

[i] i server ntp impostati sul router servono al router stesso come riferimento temporale per i log e le eventuali regole schedulate a tempo,
ciò che devi controllare è invece le impostazioni sul client, ovvero nel tuo caso sul raspberry (che avrà, nella sua applicazione, un suo client ntp che andrà a interrogare un server ntp predefinito se non ne hai impostato uno tu),
però, ripeto, se vedi che l'orario è esattamente sincronizzato (minuti e secondi) ma sfalsato esattamente di 2 ore è fuor di dubbio che non c'entra nulla l'ntp (che evidentemente se l'orario è sincronizzato funziona) ma invece il settaggio (ovviamente sul raspberry) sia del "time zone" (per l'Europa centrale inclusa l'Italia +1h rispetto a UTC) che dei parametri ora legale/solare (detto DST).

Tieni presente, lo riscrivo, che un server NTP fornisce sempre il riferimento temperale assoluto (UTC) e non l'ora locale (che tiene invece conto del fuso e delle regole DST) il cui computo è sempre demandato al client.

Se poi noti che, nonostante le impostazioni sul raspberry, l'orario è "esatto" ma sempre esattamente sfalsato nonostante le impostazioni della zone (ma nel software implementato sul raspberry è prevista anche la regolazione DTS?...) allora sta certo che il problema è tutto lato applicazione e non c'entra nulla l'ntp.

Ricordo, tempo fa, un problema di orario sfalsato su una telecamera ip che prevedeva la programmazione manuale dell'inizio/fine dell'ora solare/legale ma nonostante questo non c'era verso di avere l'ora allineata al passaggio della regola, è poi uscito fuori che era un baco del firmware (sviluppato in Cina) ed evidentemente poco o nulla testato da questo punto di vista (in Cina non esiste l'ora legale).

[Walter62]

Per caso avete l'wifi sul raspderry?

[leo66]

Per caso avete l'wifi sul raspderry?

si ,il mio e' connesso in wifi