Eh, prima o poi magari lo farà, deve però ancora entrare nel mood… quando poi inizia a scrivere codice la devo fermare con le minacce…
La tabella l'ho fatta, la ri-analizzo per bene e poi la pubblico.
Ho previsto l'uso di relè ad impulsi a due canali, uno dei quali usato per mandare il segnale a Controllino per fargli sapere sempre la posizione del relè. Ciò per quei relè che possono stare attivi per giorni. Negli altri casi ho messo relè NA, per stati che durano o devono durare poco e correnti che possono essere superiori alla metà di quella ammessa dai relè di Controllino.
Previa interposizione di un convertitore seriale TTL -> RS485
Sì, prima di fare qualsiasi connessione verifico per bene tutto ciò che occorre
Ho provato a fare leggere ad Arduino Mega un sensore DHT, facendo scrivere a Copilot il codice, senza successo. Fa errori continui. Chiesto a Gemini, ci sono riuscito con solo 3 tentativi, facendogli accendere un LED tra i 20 e i 21 gradi.
Quando passerò a Controllino farò test anche con quel PLC, con attenzione alle uscite/entrate per usare i nomi giusti
Grazie per la dettagliata spiegazione sui tempi. I dati VE.Direct posso anche non leggerli, se creano problemi, quelli del BMS in qualche modo sono sufficienti. O potrei pensare di farli leggere all’ESP, ma avrei solo la porta USB libera. Vedrò più avanti se farlo o meno
Quindi (ho chiesto a una IA che mi ha confermato la fattibilità, benché sia conscio della difficoltà) potrei usare il BLE dell’ESP per leggere i dati inviati ad es. dallo SmartShunt 500A, e visualizzarli da remoto, giusto?
Non mi servirebbe mandarli a Controllino, che può agire autonomamente coi dati del BMS
Si, se trovi documentazione. Se devi solo leggere dati, fai ricerca se tuoi dispositivi fanno BLE advertising. Quanto so, Victron non e' troppo tirchio con suoi protocolli.
Per leggere broadcast, non necessita proprio accoppiamento / connessione. Per esempio io vedo stato di batteria di spazzolino elettrico di mio vicino...
Non ho ben capito per quale ragione, ma l'uso del BLE è tra le cose che creano più ansia negli utenti dell'ecosistema Arduino
Scherzi a parte, considerato il background, sono certo che la tua compagna saprà districarsi senza problemi.
Tenete conto inoltre che usando sia il WiFi che il BLE, le dimensioni del firmware aumentano e lo schema di partizione della flash usato di default da Arduino, con tutta probabilità non andrà bene perché c'è poco spazio riservato per il firmware.
Tra le opzioni di configurazione della board troverete una lista da cui selezionare diversi schemi.
Ho trovato questo progetto che potrebbe essere un buon punto di partenza (anche se non mi piace proprio come hanno organizzato il progetto a livello di file).
C'è scritto che va bene per M5StickCPlus o simili (prodotti che di base usano ESP32-D4), ma non è un problema in quanto a voi interessano solo i dettagli necessari per comprendere i dati inviati in broadcast dal dispositivo e lo stack BLE è sostanzialmente lo stesso.
Sto vedendo la tabella delle connessioni (senza prendere la vacca per le palle e considerare i D… come possibili input ).
Scrivevo più su che per i casi in cui un relè deve restare collegato anche per giorni, pensavo di usare un relè ad impulsi doppio canale, con un canale usato per avere un feedback sulla posizione. Questo implicherebbe usare un D… per alimentare la bobina (o un relè) per farlo scambiare, e un A… per il segnale. Così saturerei quasi tutti gli input (ho altri ingressi di controllo).
Alternativa sarebbero i relè elettronici ad impulsi, ma con segnale di set e reset tipo il Finder 13.12.0.012.0000. Sarebbero simili ad un bistabile, userei due D… e lascerei libero un A… per ogni relè.
A livello di logica per Arduino penso cambi poco, sulla base della vostra esperienza vedete controindicazioni alla seconda ipotesi?
Finder sembra che voglia nascondere certi suoi prodotti.
Ci sono i relè bistabili 41.61.6.012.4016 trovati su Conrad a 5,99 eur.
Lo zoccolo per questi relè è il 95.95.3, sempre Conrad a 4,79 eur, la mollettina costa 0,45 eur.
Correggo ciò che ho scritto poco fa. Quello zoccolo ha due pin lato coil, almeno dalla foto, quindi non va bene.
Quindi a meno di non modificarlo saldando un cavo al pin centrale del relè, pare che Finder non produca zoccoli per i suoi relé bistabili
Dopo una lunga pausa natalizia (buon anno a tutti), le attività riprendono
Ho avuto un po' di problemi ad installare la board ESP32-S3 nella IDE, ricevendo sempre il messaggio di errore:
Downloading packages
esp32:esp32-arduino-libs@idf-release_v5.5-9bb7aa84-v2
Failed to install platform: 'esp32:esp32:3.3.5'.
Error: 4 DEADLINE_EXCEEDED: net/http: request canceled (Client.Timeout or context cancellation while reading body)
Provato su due PC connessi in wifi, senza successo.
La AI alla fine mi ha suggerito di usare l'installazione offline, poi stamattina ho provato usando il cellulare come hotspot, tutto è stato molto veloce ed ha funzionato. Non è possibile modificare il timeout della IDE, quindi occorre solo una connessione veloce.
Oggi se BRT non ritarda, arriva anche Controllino , (EDIT: è arrivato) e la Signora inizierà a lavorare su MOИKontrol, nome dato al progetto (il camper lo avevamo chiamato MOИK).
Ha detto che sarebbe pure possibile, con un segnale GPS, avere l'ora del tramonto e dell'alba, per disattivare il relé che accende l'MPPT quando è buio...
Sto lavorando alla logica, ho impegnato per ora 12 relè, 14 uscite, 14 ingressi e alcuni relè esterni, bistabili o NA. Mano a mano che la scrivo, qualcosa potrebbe cambiare.
Ho cercato un po' di informazioni su come fare il cavo per la connessione RS485 tra le due schede, credo di aver compreso che con una distanza di pochi cm (Controllino e ESP32 saranno affiancati), bastano una coppia di fili "normali", non occorre schermatura.
O è meglio avere la schermatura messa a massa?
In questo caso è più importante che i due circuiti abbiano la stessa alimentazione (masse in comune) e non siano alimentati da due alimentatori differenti: l' RS485 richiede non solo due fili per i dati, ma anche un riferimento comune -massa- tra le unità.
A proposito... è un buon momento per misurare quanto assorbe Controllino di base una volta solo alimentato, senza relé o uscite attive. È un dato che non ho trovato scritto da nessuna parte.
Condivido.
Sebbene il riferimento in comune non è un requisito essenziale per la comunicazione, si usa di solito abbinato a cavi schermati quando la differenza di potenziale tra i due GND dei dispositivi è "importante" (cavi molto lunghi, elevato rumore ambientale etc etc), ma considerata la descrizione del sistema e del cablaggio direi che non è questo il caso.
Mi era sfuggito questo dettaglio nei post precedenti, ma se si tratta di pochi cm e quindi in sostanza dello stesso "rack" non servirebbe nemmeno usare l'interfaccia RS485, cosa che renderebbe più snella la comunicazione: si tratta infatti di un'interfaccia seriale asincrona half-duplex in cui solo un dispositivo per volta può impegnare il bus e va quindi gestito l'accesso concorrenziale (per questo si adotta quasi sempre un'architettura master/slave).
C'è da considerare però che la RS485 la useresti anche per gli altri device del camper e se procedi come si era detto con il controllino che fa da slave "stupido" ha più senso avere un solo bus comune con l'ESP32 che fa da master piuttosto che gestire la varie comunicazioni in modo separato.
Insomma le variabili sono molte... va messo tutto sulla bilancia e valutato con attenzione i pro ed i contro di ognuna delle soluzioni possibili.
La sola EBL del camper se accesa consuma circa 400mA. Tra luci, riscaldamento, frigo, caricabatterie e sistemi di sicurezza il consumo quando il mezzo è in uso varia tra 1,6 e 11A (limite estremo se accendo tutte le luci, interne ed esterne, cosa che non accade praticamente mai). Il consumo di Controllino è tollerabile.
La questione alimentazione: Controllino accetta max 15V per la sua alimentazione, la batteria ha una tensione nominale di 13,2V, quando è sotto carica sale a quasi 13,8V. Quindi vado diretto dalla batteria.
I segnali in ingresso high level però sono indicati max 13,2V, devo immagino limitarli con una resistenza (300ohm o giù di lì).
L'ESP32 va alimentato a 5V, quindi per forza occorre uno stepdown che ho già previsto per avere i 5V per alcune utenze.
L'idea è proprio quella dello slave stupido (poverino... ) che operi anche autonomamente, senza bisogno dell'ESP32 che può dormire finché l'app non lo sveglia o Controllino gli dice di mandare una notifica all'app.
Quale altra connessione potrei usare che non sia l'RS485?
Allora non può essere uno slave stupido... Se deve operare in autonomia, dovrà essere lui il master o quantomeno adottare un approccio ibrido.
Il problema è che è complesso implementare un approccio multi master affidabile su un bus half-duplex come RS485.
A questo punto forse conviene valutare l'opzione del doppio canale di comunicazione:
bus di campo "deterministico" RS485 con cui gestire dispositivi vari, ingressi ed uscite
bus dati per supervisione Controllino <-> ESP32, attivo solo quando necessario.
I due dispositivi sono attaccati, potresti anche pensare di usare una semplice connessione UART 0-5V.
Il Controllino ne ha 4 hardware, devi solo verificare su quale dei 4 connetti X1, X2, X3 ed X4 sono esposti i relativi pin. Per quanto riguarda l'ESP32 Waveshare, vedo nell'immagine che espone i GPIO1 e GPIO2 e potresti usare quelli, magari usando un level shifter per evitare di entrare con i 5V del Controllino sul pin RX dell'ESP32 (che lavora a 3.3V e non è 5V tolerant).
Per qualche test rapido da banco, può anche bastare una resistenza messa in serie in modo da sfruttare il diodo di clamping che protegge tutti i GPIO, meglio ancora sarebbe un partitore di tensione (tanto il problema si presenta solo nella direzione Controllino -> ESP32).
Con un level shifter però saresti più tranquillo nel lungo periodo.
Controllino nell'idea che mi sono fatto opera in autonomia con logiche davvero semplici, tutte basate su valori/presenza o meno di segnali in ingresso o funzione del tempo (es. l'accensione del caricabatterie della batteria motore avviene una volta alla settimana per 8h se il camper è attaccato all'alimentazione 230V, la pompa acqua si disattiva se il livello acqua è < di x litri ecc).
L'ESP32 fa da "interfaccia" con l'app per leggere valori che Controllino gli passa e accendere o spengere alcuni dei suoi relè (EDIT: se glielo dico io da app, sennò agisce secondo logica).
Ci sono solo 5 variabili che Controllino deve considerare e che gli vengono passate dall'ESP32 con necessità di essere memorizzate e valide anche in caso di reset o mancanza temporanea di corrente (evento rarissimo, sarà collegato alla batteria), ma con una logica intelligente le posso ridurre a 2. Gli altri parametri che passo dall'app (7 o 8) non hanno questa esigenza.
*|BACK_HOME|Indica che sono in viaggio per tornare al rimessaggio o collegato fisso alla 230V|*
*|ON_HOLIDAY|Indica che sono in vacanza, è in uso normale|*
*|IN_GARAGE|Indica che il camper è in rimessaggio con gli allarmi accesi|*
*|SOC_MAX|% massima di State of Charge|*
*|SOC_MIN|% minima di State of Charge|*
Le prime tre possono essere un numero, 1, 2 o 3 col quale identifico uno dei tre stati di funzionamento.
Le ultime due possono essere il valore SOC-MAX e semplicemente fisso il SOC_MIN=SOC_MAX-10.
Una volta che Controllino sa in che stato è, ed il numero del SOC_MAX, opera con le semplici logiche che sto scrivendo.
Sono logiche a livello di if then else di Excel o poco più.
Lo scambio di dati quindi tra ESP32 e Controllino avverrebbe quando apro l'app o per ricevere saltuariamente notifiche dall'ESP32 (es. il SOC è sotto un livello critico per qualche ragione).
Non ho preclusioni sull'adottare uno solo o due canali di comunicazione, la mia perplessità è solo legata alle dimensioni lillipuziane del microspinottino per il collegamento dei pin GPIO1 e 2 dell'ESP32. Il camper VIBRA (le strade statali italiane sono terribili), e mi fido di più di una connessione su cavi di sezione più corposa serrati con viti.
).
, (EDIT: è arrivato) e la Signora inizierà a lavorare su MOИKontrol, nome dato al progetto (il camper lo avevamo chiamato MOИK).
) che operi anche autonomamente, senza bisogno dell'ESP32 che può dormire finché l'app non lo sveglia o Controllino gli dice di mandare una notifica all'app.
