[albertopolino]

Non necessariamente un cavo di rete rappresenta la miglior soluzione per applicazioni diverse da quelle LAN/WAN. Il fatto che il problema si ripresenti dopo alcune ore indica che vi è ancora qualcosa che disturba il sensore.
Ogni quanto tempo il SW interroga ciclicamente i sensori?  Hai possibilità di aumentare nel SW il tempo di pausa tra una interrogazione e la successiva (aumentando così la possibilità di risposta dai vari sensori)? Ho cercato a lungo questa possibilità che esiste per Arduino ma non per il Raspberry
Se ti è possibile scollega il sensore diventato "dormiente" dalla sua posizione e ricollegalo al master con un cavo corto per vedere se si "risveglia" e riprende a comunicare correttamente.
Prova a collegare un condensatore elettolitico da 200 uF + uno ceramico da 10 nF in parallelo ai pin di ingresso alimentazione del sensore (+ e -) lato sensore o lato raspi? Scusa se ti chiedo dettgli che potrei desumere con prove pratiche ma, come sai, quando hai molte variabili che interferiscono tra di loro, è molto difficile dirimere quelle influenti da quelle ininfluenti. 

[ippogrifo]

Per la coppia di condensatori: lato sensore, possibilmente sui reofori dello stesso. Per quanto riguarda le temporizzazioni, il codice è scritto in quale linguaggio ?

[albertopolino]

Per la coppia di condensatori: lato sensore, possibilmente sui reofori dello stesso. Per quanto riguarda le temporizzazioni, il codice è scritto in quale linguaggio ?

Domani mi procuro il materiale e faccio le prove. Poiché i sensori sono protetti da una guaina impermeabile, i condensatori potrò metterli a non meno di 3 metri.

non so in quale linguaggio sia scritto il codice. Io per l'instalazione ho seguito questo esempio:
http://www.iz0kba.it/raspberry/DS18B20.html

[ippogrifo]

L'esempio riportato è scritto in Python. Vi sono due temporizzazioni ( time.sleep(0.2) - time.sleep(1) ), la prima nella funzione " def read_temp() " e la seconda nel ciclo principale del while. Di fatto i sensori vengono interrogati ogni secondo ma la risposta è soggetta al ciclo while nella funzione read_temp(). Prova ad aumentare in questa il tempo di sleep da 0,2 a 0,5 e vedi cosa avviene.

[Zzed]

Ma anche 1 sec..e variazioni di temperatura non sono così repentine.

Inviato dal mio A0001 utilizzando Tapatalk

[ippogrifo]

Vero, interrogazioni a 1 sec nella realtà non sono necessari, a meno che non si parli di generatori di calore a combustibile ed applicazioni connesse. Come strutturato l'esempio, però, il punto "critico" in cui si attende che il messaggio si valido ("YES") è correlato al time.sleep(0,2) della funzione. Quando risolta la validità del messaggio viene stampato il risultato e così via. Poichè il tutto si basa sulla scrittura dei dati su un file, riaperura dello stesso in lettura, successiva chiusura, elaborazione dell'informazioni in un tempo di 0,2 sec, allungare il tutto a 0,5 sec è un primo passo per verificare se vi sono ritardi nella comunicazione master-slave, rappresentando solo una variabile.

[albertopolino]

Effettuate le modifiche hw e sw suggerite. Funzionamento regolare. Grazie!

[ippogrifo]

bene, ma vediamo nelle prossime ore

[albertopolino]

bene, ma vediamo nelle prossime ore

Profetico: ha funzionato bene sino alle 3,50 per poi bloccarsi ( non erano visti neppure gli altri due sensori che di solito non danno problemi e riprendere a funzionare alle 8,25. Ora va bene.

[ippogrifo]

Ha ripreso autonomamente insieme agli altri due? Se dovesse succedere ancora, verifica con un tester digitale la tensione presente ai capi della resistenza da 4,7K: un livello costantemente basso impedisce la comunicazione sul bus dati. In questo caso scollega uno alla volta i sensori per individuare quale dei tre crea il problema. Modifica il valore del tempo di interrogazione da 1 sec a 5 -10 sec. La lettura sequenziale dei tre sensori come avviene e ogni quanto tempo?