[zoro84]

Buongiorno,
fino ad un mese fa ho usato il mio rpi per domotizzare le luci in modo da poterle usare sia dai pulsanti di casa che davano un input al rpi che a sua volta dava un input a dei relay, sia tramite homebridge e comandati dall'App Casa di iPhone tutto senza alcun problema, se non qualche rarissima accensione automatica di una luce che molto raramente soffriva di interferenza dal frigorifero. Ed avevo 3 DHT22 per avere la temperatura e l'umidità esterna, e di 2 stanze di casa.

Ora mi sono trasferito e sto rimontando tutto nella nuova casa, dove però non mi bastano i gpio integrati e comunque non mi passano tutti i cavi necessari nel corrugato finale dove ho messo il rpi, quindi ho deciso di ampliare il sistema tramite MCP23017 che erano già in mio possesso.

So già che il protocollo i2c teoricamente soffre della distanza, ma nel mio caso non sembra essere quello il problema, poiché finché il sistema lo uso solo tramite homebridge tutto è stabile, quando invece avvio lo script che attiva i tasti, o comunque basta che avvio un file che contenga un ciclo "while:" i 16 pin del mcp cominciano a cambiare stato e livello senza una logica, passano da input ad outpup e da high a low casualmente e senza motivo. Ho controllato questa cosa anche dall'interfaccia grafica di WebIOPi, i gpio del rpi restano stabili, quelli del mcp impazziscono. Come interrompo l'esecuzione di quello script tutto torna stabile.

All'inizio avevo pensato che le resistenze interne del mcp non riuscissero a tenere alti i pin, ho messo le resistenze di pull-up in maniera fisica da 1 KOhm pensando che riuscissero a tenere stabili i pin del mcp ma non cambia nulla.
Nello script dei tasti ho impostato di non accettare input sotto un certo tempo, (una specie di antirimbalzo via software) e sembrava avessi risolto, ma poi mi sono reso conto che all'inizio impazziscono solo i 4 pin dei tasti, e con l'antirimbalzo non fanno scattare i relay, ma dopo qualche minuto anche gli altri 12 pin impostati come output in fase di avvio del rpi cominciano a variare casualmente.

La cosa assurda è che e nonostante di quel mcp io uso solamente 8 pin, 4 input e 4 output, gli altri 8 gpio impostati in avvio come output e che non vengono proprio menzionati in quello script, anche loro variano di stato e livello casualmente.

Ho usato tutti cavi per allarme, quindi altamente schermati e con lo shield del cavo posto a massa.

Ho provato anche a fare un file di test con un ciclo while solamente che legge lo stato di un tasto (sempre con antirimbalzo) e se lo rileva premuto mi scrive luce accesa, senza far scattare relay ne altro, e nonostante questo dopo qualche minuto tutti e 16 i gpio impazziscono e le luci diventano casuali.

Qualcuno di voi ha mai avuto problemi del genere? Non posso nel caso in cui mi vengono ospiti a casa fargli comandare la luce del bagno solo a voce o dal cel, oppure avere le luci delle stanze che si accendono e spengono casualmente tipo albero di Natale 

Ringrazio tutti coloro che mi aiuteranno!

[ippogrifo]

Sembrerebbe un problema connesso all'alimentazione dell' IC o allo stesso circuito integrato. Non conosco homebridge ma il fatto che i carichi possano essere controllati senza problemi (quindi solo in output) tramite il protocollo può non garantire l'immunità ad eventuali disturbi di natura elettrica che si evidenziano quando vengono attivati gli input. Da come scrivi (non disponibilità di spazio dentro il corrugato) credo che l'MCP23017 sia distante dal raspberry e dall'alimentatore ed a questi collegato tramite cavi bipolari. All'MCP23017 in input sono collegati i vari interruttori/pulsanti tramite cavetti (bipolari ?) schermati. Per prima cosa prova a sostituire l'IC, poi avvicina lo stesso al raspberry (cavi corti il più possibile) ed attiva il test di input, verifica cosa succede. Se tutto regolare il problema è dovuto alla lunghezza dei cavi di collegamento raspberry-MCP23017 (prova quindi a schermarli). Se no (parto dal presupposto che il cablaggio/montaggio dell'MCP23017 sia corretto come da data sheet) prova ad inserire tra i pin di input e massa dei piccoli condensatori ceramici da qualche centinaio di picofarad (eventualmente anche realizzare un filtrino integratore aggiungendo in serie al pin una resistenza di qualche koms). Se anche così ci fossero dei problemi prova ad invertire il senso di input: resistenza da 1 Koms (verifica sul data sheet dell'IC la max corrente in uscita erogabile dal pin in out per poter ridurre questo valore) verso massa, interruttore verso il positivo dell'alimentazione. In questo modo un segnale perturbante dovrà far circolare una corrente di qualche mA affinchè il pin lo possa vedere come un "1" (si veda sul data sheet per il valore di tensione minimo). Se anche così non si risolve, servirebbe un buon oscilloscopio per vedere cosa succede.
Parto dal presupposto che il codice sia corretto.

[zoro84]

Ciao Ippogrifo e grazie per la tua risposta,
L’mcp è a 5 metri dal rpi collegato con un cavo qudripolare per allarme 2x0,5 VCC e GND e 2x0,25 SDA e SCL. Il cavo essendo per antifurto ha la schermatura in metallo che ho collegato a GND.

Avevo già fatto prove avvicinando l’mcp al raspberry ed anche ad usare il pull-down invece che pull-up con resistenze esterne perché internamente l’mcp ha solo pull-up ed anche a staccare i carichi, dando solo a video la scritta dei comandi che eseguiva, ma l’unico cambiamento è stato che “impazziva” dopo un tempo maggiore.

Lo stesso vale se aumento o diminuisco il baudrate del rpi, a 40.000 impazzisce dopo 6 ore, a 100.000 dopo un’ora, a 400.000 praticamente subito.

Il fatto che con cavi più corti o con velocità ridotta duri di più prima di impazzire mi da l’idea che sia un problema di “saturazione” che dopo tot tempo l’mcp non riesce più a comunicare con il rpi e quindi non sa ogni pin che funzione ha e comincia a muovere i segnali a caso.

Mi studio come funzionano i pin di interrupt e vedo se con quelli risolvo!

[ippogrifo]

Sei certo della "pulizia" dell'alimentazione del raspberry ed IC ? Le resistenze di pull-down erano di basso valore ? (idealmente, solo per test, sarebbe da porre gli input a massa, ma visto che la configurazione cambia da in ad out non è una soluzione perseguibile). Se pensi che vi sia un problema di saturazione nella comunicazione, prova ad inserire nel ciclo del while un delay di diverse decine di ms fra le interrogazioni e vedi che succede (alcuni anni fa ho utilizzato questa soluzione in una comunicazione seriale - UART - a 116 Kbit tra il raspberry e la periferica; il raspberry non riusciva a comunicare correttamente, molto probabilmente i dati non venivano caricati correttamente nel buffer) . Tieni conto, nell'uso degli interrupt, che raspbian non è un SO in tempo reale e quindi potrebbe non rispondere immediatamente alla richiesta di un servizio di interrupt.

[zoro84]

L’alimentatore era ok, ne ho messo uno stabilizzato 5V 5A che pilota tutto, sia l’rpi sia l’mcp sia i relay.
Comunque ho risolto con l’interrupt! Il problema era proprio la saturazione!

Ho collegato il pin di interrupt dell’mcp ad un pin del rpi programmato come input e pull-up.
Poi ho programmato l’mcp in modo che nel caso uno qualunque dei 4 tasti viene premuto il pin di interrupt cade in basso finché non viene letto il registro di interrupt.

Allo stesso tempo il pin del rpi è programmato come wait_for_edge falling e ricevendo l’impulso dall’interrupt legge il registro dell’mcp svolgendo 2 funzioni, la prima è rilasciare il pin di interrupt che avendo la resistenza di pull-up torna in attesa, la seconda funzione è che leggendo il registro di interrupt sa quale dei 4 tasti è stato premuto e di conseguenza fa scattare il relay corretto.

C’è un solo difetto che non so per quale motivo a volte il pin di interrupt dopo tante volte che viene “chiamato”, non viene stranamente più rilasciato, nonostante il programma esegue la sua funzione in quanto fa scattare correttamente il relay giusto, ma ovviamente qualunque pressione successiva di qualunque tasto non viene più rilevata perché il pin di interrupt è già down.
Ma ho risolto anche questo almeno in maniera temporanea, facendo un file che legge solamente il registro di interrupt e quindi fa rilasciare il pin di interrupt e tramite crontab viene eseguito ogni minuto, tanto di solito non mi metto a giocare con i tasti che me ne servono a decine in meno di un minuto! Nel frattempo cerco una soluzione definitiva!