Curiosità su aggiornamento valori sensori durante controllo remoto

International Italiano Generale
#1

Ciao ragazzi,
al momento,quando verifico i sensori collegati ad arduino mega da remoto, in pratica viene fatta una fotografia della situazione antecedente la chiamata, ovvero durante la chiamata arduino non rileva più nulla (non aggiorna il display ad esempio cosi come i giri dell’anemometro) e non rileva cosa succede intorno a lui, salvo poi riaggiornarsi quando la chiamata finisce… faccio alcuni esempi:

un countdown che prima della chiamata si ferma a 50 secondi, dopo la fine della chiamata segna 50 meno i secondi della chiamata

il sensore che uso per temp/umidità e pressione è il bme 280 e questo mi si ferma alla lettura prima della chiamata e successivamente ad essa sistematicamente legge meno di quanto era prima, come se nei secondi della chiamata non leggesse più… ma invece di rimanere dello stesso valore dimiuisce.

durante il loop controllo e aggiorno delle variabili che mi danno l’andamento nel tempo della temperatura ( ogni 5 minuti) e quindi questo perdere decimali ad ogni chiamata da remoto non mi garba molto… mi sepreste dire il perchè succede questo e come ovviare?

pensavo durante la chiamata da remoto di lcontinuare tra un’aggiornamento e l’altro della pagina web la lettura del sensore di temperatura… è corretto? ovviamente al momento lo faccio solo nel loop che da quello che ho capito viene sospeso quando avvio la comunicazione da remoto.

grazie

#2

Ciao.
Senza informazioni sul hardware che usi per il collegamento da remoto e lo sketch che é caricato sul Arduino possiamo solo prendere conoscenza del Tua problema.
Ciao Uwe

#3

Ciao uwe,
allego il codice in allegato, su questo pc l’unico modo che ho è con un file .txt

Ho già ricevuto innumerevoli commenti di come sia penoso il codice scritto e poco chiaro, ho aggiunto dei commenti che spero possano essere d’aiuto…

Uso un’esp 8266 per la connessione ad internet e come detto un’arduino mega.

Ciao e grazie

140221.txt (130 KB)

#4

Le variabili non inizializzate sono "indefinite"... Comunque evidentemente la gestione remota risulta bloccante per qualche motivo.

Devi accertarti che non sia una insita nel "concetto" e non un tuo problema...

#5

Secondo me il fatto che arduino non si aggiorni più durante la chiamata è corretto per via del while che c'e' all'interno di void inviodati... quello che secondo me è strano è che non leggendo di fatto il sensore in quei 10/15 secondi nel quale la pagina web si aggiorna, il bme280 perde dei decimali xome raffrendandosi...boh nn saprei... mi sarei aspettato che rimanesse dello stesso valore di inzio chiamata... proverò a inserire delle letture all'interno del ciclo while per vedere cosa succede e per imparare qualcosa di nuovo...

#6

133 kbyte di sorgente Arduino??? Ma chi l’ha scritto, Dante Alighieri? :wink: Mi aspettavo che finisse con “…e uscimmo a riveder le stelle!”.

Scherzi a parte, tralasciando il tuo problema (la cui causa mi pare legata appunto all’uso di while, ma sinveramente tremilaseicento righe sono troppe per me…), ti dò solo alcuni piccolissimi consigli.

Primo, va bene rendere autoesplicativi i nomi delle variabili, ma qui si esagera! Per dire, “tempoTotSvolgiTendaGRANDECENTRO” si può anche un poco ridurre, mantenendo comunque la leggibilità (tanto più se, come hai fatto, hai dei commenti che la descrivono).

Secondo, devi imparare a gestire gli array, non è possibile fare sbrodolate di decine e decine di variabili con nomi diversi (oltre che chilometrici) per tutte le possibili combinazioni! E questo vale pure per le #define, ad esempio se tu vuoi impostare i 47 pin inutilizzati creati un array di byte invece di 47 righe #define, ti basta definirli tutti con UNA sola riga:

const byte sensore[47] = {55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,2,11,12,13,16,17,18,24,25, ...eccetera...};

A quel punto nel codice per inizializzare i pin invece di altre 47 righe ti basta fare un ciclo for, ossia DUE righe:

...
  //imposto i pin inutilizzati con pullup interna
  for (int i=0; i<47;++i)
    pinMode(sensore[i], INPUT_PULLUP);
...

Poi una cosa analoga per altre cose, come i flag di attivazione, srotolamento, arrotolamento, reset.

Per finire, quando hai un codice abbastanza grande, non dico di fare programmazione ad oggetti (che non sarebbe affatto male, ma tralasciamo…) ma dividilo almeno in file *.h nei quali metterai variabili e funzioni coerenti (ossia nello stesso file “cose” che riguardano e gestiscono una stessa funzionalità), che includerai nel modulo principale con #include.

Tutto questo serve non solo per rendere più “snello” il codice e quindi più facile da comprendere (soprattutto per le altre persone, come noi, che magari vogliono aiutarti ma di fronte a quasi 4.000 righe uno o si prende mezza giornata di ferie o rinuncia…:wink: ), ma anche per consentire a te stesso di fare debug, ossia tracciare la logica del programma ed identificare dove possa essere il problema.

Capisco che ora mettere mano a questo codice sia un calvario, per cui prendi questi spunti quantomeno per i prossimi progetti… :wink:

#7

Capisco che ora mettere mano a questo codice sia un calvario, per cui prendi questi spunti quantomeno per i prossimi progetti... ;)

Ciao Doc Doc,

eh si, tutte sante verità considerando però che questo è stato il mio primo progetto partendo non da zero ma da -10... e onestamente parliamo di 4000 righe sudate e sofferte per arrivare ad oggi con un codice funzionante da almeno 3 anni e che ancora oggi mi piace ottimizzare o (peggiorare) direte voi aggiungendo delle nuove righe...

Parecchie volte sono stato tentato di rifarlo da capo ma purtoppo non ho il tempo di studiare e mi sono avvicinato ad Arduino e alla programmazione troppo tardi e per quanto mi affiscini non ho il tempo di dedicarmici se non per diletto il sabato pomeriggio con i figli che mi ronzano intorno e che mi toccano tutta la breadboard... mi ci sarei dovuto avvicinate 15/20 anni fa...

grazie cmq per il modo gentile con il quale mi hai detto la solita cosa già detta da molti e che alla fine è sempre quella :smiley:

questo WE proverò a mettere una pezza facendo qualche prova e chissà se magari tra qualche anno( se non cambio casa nel frattempo) con mio figlio riscriviamo tutto il codice da capo!!! :stuck_out_tongue:

ciaooo

#8

ho fatto una prova facile facile e non ha dato esito positivo... ho messo la lettura del sensore temp appena entro nel while di inviodati al centro e alla fine... e notavo anche che mi perde decimali anche solo quando accendo il wifi e l'esp si collega ad esso.... l'ordine di grandezza che mi perse oscilla da 0,02 a 0,07 gradi.... so anche però che la precisione del BME è +o- 1 grado... mi sa che sto pretendendo troppo...

mi chiedevo se poteva essere un problema di libreria... al momento uso questa: Seeed_BME280.h", nel WE provo a usarne un'altra...

#9

Se anche con il test semplice, ci sono "blocchi" allora avevo ragione: "Devi accertarti che non sia una cosa insita nel "concetto" e non un tuo problema..."

#10

Ma veramente tu credi di poter apprezzare i centesimi di grado con un BME280 ? ? ? :o :o :o

Ti va bene se misuri +/- mezzo grado, il resto sono fluttuazioni interne al chip (... che dovresti ignorare visto che NON ha senso leggere con una precisione superiore a quella indicata nel DS) e la libreria NON ha nulla a che vedere ... i dati sono digitali e non è che cambia molto leggerli con una libreria o con un altra eh !

Guglielmo

#11

Infatti Guglielmo credo proprio di stare a pretendere troppo dal sensore....

#12

simosere:
Infatti Guglielmo credo proprio di stare a pretendere troppo dal sensore....

... no, guarda, non stai pretendendo troppo, stai commettendo un errore così grave che, quando facevo fisica, se facevo una cosa del genere all'esame, mi cacciavano direttamente via ! :confused:

Come pretendi di misurare i centimetri se hai una stecca graduata in decimetri? O pesare i grammi con una bilancia che indica solo i chili? Al massimo leggerai i decimetri o i chili, il resto è solo ERRORE matematico :wink:

La stessa cosa si applica a qualsiasi misura :slight_smile:

Guglielmo

#13

Quindi il "problemma bloccante" si é risolto?

#14

Concordo con te....ho rivisto ieri il datasheet del sensore e mi si è accesa la lampadina... :confused:

#15

E’ un po’ che non lavoro con il BME280 per cui la memoria può perdere colpi, ma tu quante volte lo leggi ad ogni giro di loop?
Non è che ad ogni bme280.getTemperature() viene interrogato il sensore?
Un accesso così costante potrebbe leggermente surriscaldarlo.

In alcuni punti ho visto cose tipo:

void estateinverno() { // con tenda SX e CENTRO chiuse setto la variavile Set_Time in funzione della temp esterna 
  if (reset_timerGRANDESX == true || reset_timerGRANDECENTRO == true) {
    if (bme280.getTemperature() - 2 <= 14.00) {
      Set_Time = 1;
    }
    if (bme280.getTemperature() - 2 >= 14.01 && bme280.getTemperature() - 2 <= 18.00) {
      Set_Time = 2;
    }
    if (bme280.getTemperature() - 2 >= 18.01 && bme280.getTemperature() - 2 <= 21.00) {
      Set_Time = 3;
    }
    if (bme280.getTemperature() - 2 >= 21.01 && bme280.getTemperature() - 2 <= 25.00) {
      Set_Time = 4;
    }
    if (bme280.getTemperature() - 2 >= 25.01) {
      Set_Time = 5;
    }
  }
}

Il mio consiglio è di fare una sola lettura dentro al loop e magari anche cadenzata con millis per non farla proprio ad ogni giro e poi tutti i test farli su una variabile dove hai memorizzato la lettura.

Ok, stiamo parlando di decimi che sono sotto la precisione del sensore, però potrebbero essere significativi comunque di un potenziale problema.

Diciamo che il consiglio sarebbe valido a prescindere.
Questo sarebbe da fare di prassi un po’ su tutto.

Poi avrei anche qualche altro consiglio sul come ristrutturare il codice, ma visto che sono le solite cose che ti hanno ripetuto in tanti, non infierisco ulteriormente.

Maurizio

#16

maubarzi:
... Ok, stiamo parlando di decimi che sono sotto la precisione del sensore, però potrebbero essere significativi comunque di un potenziale problema.

Misure che non hanno molto senso, oltre tutto, continuo a dire, che stato usando un senosre di pressione ed umidità per misurare la temperatura che è una misura che il BME280 fa solo come cosa accessoria e che è fortemente influenzata dalla temperatura interna del chip (che varia in continuazione in funzione dell'uso):

Temperature measured by the internal temperature sensor: This temperature value depends on the PCB temperature, sensor element self-heating and ambient temperature and is typically above ambient temperature.

Guglielmo

#17

>simosere: se vuoi fare una cosa fatta BENE e con una buona precisione, devi usare il BME280 per umidità e pressione ed affiancargli un buon sensore dedicato per la temperatura. :wink:

Guglielmo

#18

gpb01:
Misure che non hanno molto senso, oltre tutto, continuo a dire, che stato usando un senosre di pressione ed umidità per misurare la temperatura che è una misura che il BME280 fa solo come cosa accessoria e che è fortemente influenzata dalla temperatura interna del chip (che varia in continuazione in funzione dell'uso):
Guglielmo

Allora, la misura rilevata trova il tempo che trova, e su questo siamo d'accordo.

Se la misura è inaffidabile, il delta può comunque essere significativo, perchè la lettura, per quanto sbarellata, seguono comunque le leggi della fisica e quindi l'analisi delle variazioni può essere significativa a prescindere dai valori assoluti letti con risultati sbarellati.

Il fatto che faccia letture a raffica può incidere ulteriormente scaldando il sensore e sfalsando ulteriormente la lettura, e questo era il punto del mio intervento. La lettura, sbarellata viene ulteriormente peggiorata dal surriscaldamento interno. Infatti, se si blocca tutto per qualche secondo, il sensore si raffredda e alla successiva lettura legge un pelo più freddo.
Quadra tutto con i sintomi indicati e li spiega.

Io, sono d'accordo con te che cambiare sensore per prenderne uno più sensato è la soluzione definitiva al problema, ma anche risistemare il software per evitare tutte le letture a raffica non è cosa sbagliata.
E comunque, almeno si è capito il perchè del comportamento segnalato.

Maurizio

#19

Ciao Maurbarzi,

ho fatto varie prove facendo letture ad intervalli a 1 secondo, 4 secondi e 8 secondi, in tutti e in tutti e tre i casi quando faccio la chiamata da remoto il sensore cala tra 0,02°C a 0,06°C finita la chiamata…

non ho notato miglioramenti tra 1 sec e 8 sec… in realtà il calo è simile ad effettuare le letture continuamente nel loop…

sono d’accordo con la logica di non leggere continuamente il sensore, cosi come sono d’accordo con Guglielmo che il sensore non è adatto a questo tipo di precisione… ma giusto per “didattica” diciamo che non ha portato alla risoluzione del “problema”. grazie mille cmq per lo spunto, applicherò il tuo approccio perchè in effetti più corretto.

#20

Dimenticavo... un sensore di temp i2c consigliabile?