lesto:
l'mportante è che aggiorni la versione nel primo post, è lì che la magior parte della gente andrà a cercare
ps. ora ci butto un occhio
Già fatto, ma grazie per avermelo ricordato 
lesto:
uhmm il codicemi pare buono, non ho trovato cose ottimizzabili al volo. Do qualche consiglio, liberi di fare ciò che volete:
- formattate meglio il codice
- dividete il codice in vari file, meglio se uno per sensore.
- il main rimane come semplice logica pura, che legge i dati da un'array di strutture (in questo modo lastruttura può essere "alimentata" da eeeprom, SD, seriale, LCD+tastierino... insomma qualsiasi cosa)
- Hai ragione, ma la formattazione quando si usa un’editor esterno è abbastanza ostica ed in uno sketch così lungo l’IDE attuale di Arduino complica la vita, stiamo usando Notepad++, che però usa tabulazioni e spazi in modo diverso dall’IDE ufficiale, aggiungi che ci mettiamo le mani in più persone ed ecco che la formattazione salta, ma mi impegnerò per migliorarla o almeno uniformarla.
- So che è possibile farlo, ma non so come si fa, imparerò anche questo perché effettivamente sarebbe meglio.
- Questa sarebbe la conseguenza della divisione in file dello sketch? Non sarebbe male!
lesto:
4. la Wire, in caso di errore, è bloccante. tempo fa la riscrissi in modo non bloccante, ma in rete ce ne sono varie implementazioni già pesantemente testate
5. riducete al minimo le tipologie differenti di standard, per occupare meno spazio e avere meno codice possibilimente in errore. Io starei su sensori i2c. un altro test è staccare "al volo" i componenti, vedere se il tutto supporta il problema, riattaccarli, e vedere se riparte. Sono casi rari disturbi elettromagentici così forti, ma considerado che il vostro progetto è fatto per restare acceso 24h su 24h per 365gg all'anno...
- Non sapevo di questa cosa, ma mi documenterò.
- Hai ragione, usare sempre lo stesso standard sarebbe meglio, ma sto cercando dei compromessi adatti anche a principianti come me, non è un caso se tutto il progetto è fatto con cose molto basic, io ho iniziato da zero e vorrei che tutto fosse di facile approccio, ad esempio i sensori di temperatura sono one-wire, comodi ma con una libreria pesantuccia ed allo stesso tempo gli unici digitali che si trovano già in formato water-proof, una valida alternativa potrebbero essere i TI TMP100 TMP100 data sheet, product information and support | TI.com o altri della stessa famiglia, ma non esistono water-proof ed il formato non è certo per principianti, sempre della TI Leouz a trovato quest’altro chip che è fighissimo LMP91200 data sheet, product information and support | TI.com , ma sti formati uno terra terra come me come li usa e soprattutto, saprei farli funzionare??? Ci sono infinite soluzioni, ma il mio livello attuale è troppo basso
lesto:
6. attenzione agli overfglow dei timer, anche della millis()per esempio riga 129 (dallealtre parti sembrerebbe ok):
if (ArrayVariabiliTasti[Indice].ValoreTasto == true && (((millis() >= (ArrayVariabiliTasti[Indice].TempoTasto + 250))) || ((millis() >= (ArrayVariabiliTasti[Indice].TempoTasto + 10)) && ArrayVariabiliTasti[Indice].TastoPremuto == false)))andrà in errore all'overflow, con imprevedibili risltati sistemala con
if (ArrayVariabiliTasti[Indice].ValoreTasto == true &&
(
millis()-ArrayVariabiliTasti[Indice].TempoTasto >= 250
||
(
millis()-ArrayVariabiliTasti[Indice].TempoTasto >= 10
&& ArrayVariabiliTasti[Indice].TastoPremuto == false
)
)
)
La parte della lettura dei tasti è da rivedere meglio, grazie per la tua segnalazione, provo subito il tuo codice, ma intendo rivedere meglio tutta la cosa, nel senso che attualmente con la IOexp, sembra che il bus I2C sia spazzolato in continuazione in attesa che venga premuto un tasto, quando in effetti i PCF8574 hanno un piedino INT che segnala appunto le variazioni sui piedini di I/O, leggendo quello, con la wire posso leggere il PCF solo quando serve effettivamente, a breve quindi farò questa modifica...
lesto:
7. per la gestione plafo, non è più semplice creare una funzione lineare (y = m*x+q) con valori settabili? dove x è il numero di minuti a partire dalla data di accensione/spegnimento, e y il valore delle luci. Trovare m e q è semplice sopratutto considerando che molto probabilmente avrete sempre q=0.(q è il valore minimo delle luci), in questo modo conservate la data di inizio, magari in secondi dal 1970 (timestamp, che spesso gli RTC calconano tranquillamente), che quindi occupa solo 4 byte (chiamiamola S), e 2 byte (un intero usigned è sufficiente per 65536 secondi, pari a 18 ore) per memorizzare la durata del fading in secondi (chiamiamola D), più un byte per valore fading iniziale a S e valore di fading finale a D, che poi il priomo byte si può risparmiare essendo il vecchio valore di D: infatti il fading è un array ciclico.
quindi a partire da S avrete X=0 e y= valore attuale delle luci (accese o spente), e a S+D avrete x = D e y= valore finale delle luci
Credo di aver capito cosa intendi, ma abbiamo visto ed anche provato a buttare giù altre funzioni simili, il risultato però e che la stessa funzione eseguita in background per tutte tre le linee diventa troppo impegnativa per Arduino che contemporaneamente fa anche altre cose, è per questa ragione che attualmente le luci vengono gestite con due procedure, la prima “Statoluci()”, serve a riallineare Arduino con la gestione delle luci in caso di variazione dei dati o di mancanza di corrente, quando le linee sono in modalità automatica, mentre “GestioneLuci()” che invece cicla continuamente in background, grazie appunto ai dati che eventualmente gli passa “Statoluci()” fa funzionare le luci eseguendo semplici confronti sugli orari e su millis().
lesto:
8. al posto di controllare ad ogni ciclo l'RTC, potete impostarlo come "sveglia". Potreste fare che ogni azione da eseguire è shedulata in un apposita struttura con timestamp di esecuzione e comando/funzione da richiamare. In questo modo, viene semplice calcolare il numero di secondi per eseguire la prossima operazione, impostare la sveglia sull'RTC, e mandare il micro "a nanna". ovvio che il pin di risveglio sarà collegato anche alla tastiera (magari però su un pin diverso, non so se si può ascoltare più pin). Così risparmiate un sacco di batteria, e analizzando lo scheduler vi accorgete se qualche istruzione và "fuori posto"!magari butto giù qualcosa io, ma non avendo un RTC dovrete darmi supporto.
Ecco qui non so se ho capito bene cosa intendi e se anche fosse non saprei nemmeno da dove cominciare, in più cosa intendi per risparmiare batteria, il controller è alimentato dalla rete domestica…
In ogni caso grazie per il tuo interessamento e per l’offerta di collaborazione, io sono disponibilissimo con il mio RTC.
Grazie Lesto