GianCann

Noi useremo l'ESP8266 che ha questa tabella dei "consumi": L'ESP32, in effetti, consuma di più (fino a 240 mA). Sicuramente, per gli eventi, in cui i treni girano di continuo, saranno necessarie le batterie ricaricabili oppure, come è mia intenzione fare, realizzare un "pick up" dai binari 9v.

...se non ci fosse Amazon, come farei? La maschera è per un regalo che devo consegnare domani, e di cui mi son ricordato solo ieri sera. È già nelle mie mani... il resto l'ho ordinato oggi, verso le 17.30: domani già ci posso 'lavorare' sopra... Va bene cercare di aiutare il negozio di vicinato (sempre meno presenti, perché la società sta cambiando per 100.000 motivi diversi), ma senza Amazon, io non saprei come fare... anche solo per il tempo di dover andare a cercare in giro cose che non troverei mai

In che ambito lo utilizzi, @sky7176? Una delle cose sulle quali dobbiamo ragionare, relativamente alla sezione MQTT è la composizione dei topic. Ad esempio, c'è bisogno di un topic per il discovery dei dispositivi (utili a verificare che tutti siano 'connessi' al broker) e poi c'è bisogno dei topic relativi a sensori ed attuatori. Ad esempio: ITS/Discovery/(device) search dove 'device' può essere: Sensori/Treni/PL/Scambi, al quale i singoli dispositivi interpellati rispondono con topic contenente un payload Json contenente nome/IP/Tipo: ITS/Info/(device) payload_json Un meccanismo del genere, permetterebbe di cercare ed identificare tutti i dispositivi connessi al broker e per avere delle informazioni minimali per la configurazione del workfkow. Cosa ne pensi? Ti viene in mente qualche altra idea?

Immaginavo, @alf, che te avresti colto subito i vantaggi di questa implementazione. Uso MQTT e gli ESP8266 per altri progetti, anche se da relativamente poco tempo, e subito ho pensato che fossero idonei per semplificare al massimo il discorso dell'automazione, in unione a Node Red. Questo, è un altro esempio di Workflow, "disegnato" velocemente... Descrive la logica di due treni che viaggiano, contemporaneamente e nella stessa direzione, sullo stesso tracciato. In una situazione reale, prima o poi, i due treni si avvicineranno tra di loro, per via della differenza di resa dei motori, del peso del treno, dell'efficienza delle batterie. Partono, all'85% della loro velocità massima, a distanza di 5 secondi uno d'altro. (il secondo treno, immaginiamolo inizialmente posizionato su un binario secondario che si innesta al circuito principale) Lungo tutto il tracciato, a distanza di circa 50cm l'uno d'altro, sono posizionati i checkpoint (cosa sono i checkpoint, nella pratica, lo vedremo in un prossimo post). Ogni treno conteggia i checkpoint a partire dal punto di partenza. Il primo treno (A), gira per conto suo, senza interessarsi di altro... Per il secondo treno (B) la logica calcola la differenza tra il conteggio dei checkpoint, facendo in modo che sia possibilmente vicino a 3 (1,5 metri di distanza). Se questa differenza diminuisce, il treno B viene rallentato... se la differenza aumenta, il treno B viene spinto più velocemente... nella pratica, i due treni viaggeranno 'all'infinito' sul circuito senza mai 'toccarsi', mantenendo tra loro una distanza ben precisa... Insomma, anche se sono giusto delle bozze di workflow, spero sia chiaro quanto sia potente e flessibile questo sistema...

Apro questo nuovo topic per introdurvi ad un progetto che abbiamo iniziato a sviluppare unitamente a @Valter1966 e @pivan e al quale ci piacerebbe coinvolgere altri AFOL di ItLUG e non solo. Penso ad esempio a persone come @alf, @fonderiadigitale, @bricksnspace ma sono sicuro che tra noi ci sono molti altri che potrebbero essere interessati ad avere una parte attiva nel progetto, ognuno con le proprie competenze, idee ed esperienze. Scopo del progetto è quello di colmare una lacuna di LEGO in tema di 'automazione/programmazione' di un diorama/circuito ferroviario. Nonostante il neonato Powered Up abbia introdotto il protocollo Bluetooth (che elimina una parte dei problemi del precedente sistema IR), non è in grado di soddisfare le esigenze di noi AFOL che vogliamo rendere più dinamici i nostri circuiti ferroviari. Sia chiaro: il nostro progetto non è certo una novità nel panorama AFOL. Sono stati moltissimi coloro che negli anni si sono ingegnati nell'automatizzare i diorami, soprattutto grazie alla facilità di programmazione offerta dalle ben note schede Arduino, ma ancora prima con gli RCX/NXT. La caratteristica principale del nostro progetto è la comunicazione Wireless tra i singoli elementi del sistema, rendendo più semplice implementare l'automazione anche su circuiti di grandi dimensioni senza la necessità di dover passare metri e metri di cavi per collegare sensori ed attuatori alla 'Control Unit' (capire meglio più avanti cos'è...) A questa caratteristica, si aggiunge lo sviluppo di componenti elettronici specifici, a basso impatto visivo, integrabili con i normali elementi LEGO. Ovviamente, per quanto cercheremo di sviluppare una cosa molto semplice da realizzare sul piano pratico (documentando passo per passo), non potrà comunque essere paragonato alla semplicità di accendere due dispositivi e fare il pairing tra loro (come il Powered Up, per intenderci...). Del resto, o ci si accontenta di usare un telecomando per fare andare un treno avanti/indietro regolandone la velocità, oppure ci si ingegna un pochino più del necessario per avere 2, 3 o 4 treni che circolano su un tracciato articolato, effettuando fermate programmate, azionando le barriere dei passaggi a livello primo del loro transito o attivando scambi per modificare il tracciato da percorrere. Questo nuovo topic nasce come prosecuzione di un discorso già avviato tempo fa e che vi invito a leggere come "background" informativo sui concetti relativi ad un automatismo ferroviario in ambito LEGO, benchè alcuni passaggi sono superati (soprattutto nella parte harware). ITS è fondamentalmente composto da sensori, attuatori e da una Control Unit. Sensori e attuatori parleranno con la Control Unit usando il protocollo MQTT per mezzo di un Broker MQTT (un sofware che agisce da centro di smistamento messaggio). Il protocollo MQTT è un protocollo di comunicazione molto diffuso in ambito IoT (Internet of Things). (Nota: non fatevi 'impressionare' da sigle/acronimi. È molto, molto più semplice di quanto vi possa apparire in una prima lettura.) Questo vuol dire che la Control Unit può essere realizzata i modi diversi ed integrarsi a sistemi già esistenti tipo ArduTrain (nel caso l'ideatore Luca Bellan decidesse di evolvere il suo sistema di controllo ferroviario implementando l'MQTT) anziché utilizzare componenti di terze tipo SBrick, EV3, NXT. Ricordate: lo scopo del progetto ITS è quello di sviluppare un sistema flessibile e facile da implementare, che offra un po' di dinamismo ad un diorama ferroviario LEGO, permettendo di espandersi con facilità verso "nuove frontiere". Come hardware di base per la Control Unit ci baseremo sulla scheda Raspberry 3B+ per il suo basso costo, le sue dimensioni, le sue caratteristiche (ecc. ecc.) tra cui il WiFi integrato (con la possibilità di funzionare da Access Point) e il Bluetooth (per parlare direttamente con i nuovi treni LEGO Powered UP, SBrick, Smartphone). L'hardware utilizzato per far girare la Control Unit non è in realtà così importante: in alternativa potrà essere utilizzato un qualsiasi PC portatile, purché ci sia un Access Point WiFi che faccia da "infrastruttura di rete". I software che useremo per questo progetto sono tutti Open Source e sono comunque sostituibili con altri simili, dato che si basano su protocolli e standard a loro volta aperti e largamente diffusi. Insomma: niente di proprietario/chiuso. Anche laddove scriveremo il nostro firmware specifico per l'harware sul quale svilupperemo i sensori/attuatori, il codice sarà comunque messo a disposizione di tutti anche perché, con il contributo di altri AFOL-Maker, potrà essere sicuramente migliorato/evoluto. Sensori ed attuatori, come già detto, dialogheranno con il protocollo MQTT su infrastruttura WiFI. Il cuore di questi dispositivi sarà il chip ESP8266 della EspressIf, diventato oramai molto diffuso, soprattutto nell'ambito della domotica. Il primo dispositivo che abbiamo avviato alla prototipizzazione è il sensore di prossimità che avrà il compito di rilevare il passaggio del treno davanti ai Check Point comunicandone tale passaggio alla Control Unit. Sarà quest'ultima, sulla base delle impostazioni impartite per lo specifico tracciato, ad inviare i comandi verso gli altri dispositivi che agiranno sui passaggi a livello, sugli scambi e sul motore del treno. Come primo attuatore, invece, partiremo dal controller del motore PF (hardware+software) e, parallelamente da quello per l'HUB Powered Up (software). Da quanto ho potuto vedere documentandomi sulla Rete, non sarà troppo difficile integrarsi anche con i dispositivi SBrick, BuWizz e PFx Brick. Avendo sotto mano un SBrick (grazie @ZioTitanok ) proverò inizialmente ad interfacciarmi con questo primo componente di terze parti, ma solo dopo aver sviluppato un prototipo del nostro attuatore (ad un costo nettamente inferiore rispetto ai vari "intelligent brick" già disponibili sul mercato). Sensori ed attuatori, da soli, non servono sostanzialmente a nulla se in mezzo a loro non c'è un 'cervello' ovvero il centro di controllo, quello che finora ho nominato com 'Control Unit', nell'ecosistema ITS - ItLUG Train System. La parte software che rappresenterà la C.U. potrà essere realizzata con qualsiasi linguaggio/piattaforma che sia in grado di interfacciarsi con un broker MQTT (praticamente tutti). Per semplicità e flessibilità, noi useremo Node Red (basato su Node.js, ovvero JavaScript), un ambiente di sviluppo visuale che ci permetterà di creare dei 'flussi' di messaggi, disegnando (nel vero senso della parola) la logica di controllo per i nostri circuiti ferroviari e potendola adattare 'all'istante', senza troppe complicazioni e con una rappresentazione chiara. Per farvi comprendere meglio, vi farò un esempio pratico, usando come base un circuito molto semplice: Su questo circuito sono posizionati 4 check point che identificano l'approssimarsi a dei punti 'nevralgici' del circuito. 1) La stazione/punto di partenza/punto di stop 2) e 3) Passaggi a livello 4) Scambio Il sensore che identifica questi check point è posizionato a bordo del treno (immaginiamolo all'inizio del convoglio). Il treno parte sempre da un punto prestabilito (la stazione) ed inizia a passare tra i vari check point... ad ogni passaggio, invia un messaggio MQTT che non fa altro che comunicare 'Sono transitato su un check point'.... Nient'altro! A bordo del treno, ovviamente, ci sarà anche un dispositivo 'attuatore' ovvero quello che, nella pratica, agirà sul motore. Cosa ci facciamo con i messaggi trasmessi dal treno ad ogni passaggio per un check point? Ecco che vi presento l'interfaccia della Control Unit, basata su Node Red: Quello rappresentato nell'immagine è un Workflow di messaggi. Ho separato il workflow in 3 aree: le prime due in alto, sono semplicissime: inviano un messaggio al treno, rispettivamente per avviare il motore e per fermarlo. L'invio del messaggio è determinato dal click sull'interfaccia grafica (il quadratino azzurrino, sul lato sx del primo box, per essere chiaro) ma può tranquillamente essere scatenato da un trigger esterno (un pulsante sullo smartphone, il caso più semplice). Il resto, rappresenta la logica vera e propria: Il primo box ('Sensore treno A') riceve il messaggio e lo passa a 'Conta Check Point', una funziona che non fa altro che contare in modo sequenziale il passaggio dei check point, resettando il contatore ogni volta che arriva al valore 4. Il 'Conta Check Point' passa il messaggio (contenente il numero del check point sul quale il treno è in transito) al blocco 'Smista Check Point': questo non fa altro che, in funzione del valore, smistare il flusso verso ulteriori blocchi... ognuno di questi ha un propria sotto-logica che, fondamentalmente, determina l'azione da intraprendere: azionare l'attuatore del passaggio a livello, anzichè dello scambio... oppure intervenire sull'attuatore che controlla il treno, fermando la corsa e facendola riprendere dopo 10 secondi... Nei prossimi giorni, entreremo nel dettaglio dei singoli componenti... (Nota: Tutto l'ambiente software relativo al Raspberry verrà messo a disposizione come 'file immagine' da replicare sulla vostra microSD, in modo da avere tutto già pronto, senza dover conoscenere i minimi dettagli della configurazione, benché gli stessi saranno comunque messi tutti a disposizione).

Dato che su Conrad le spese di spedizione costano 8 euro, ne approfitto per prendere un po' di materiale per i miei progetti Arduino/Raspy così ammortizzo le spese per prendere 5 pacchetti da 5 metri l'uno. Eventualmente li porto a Verona, se @mincia e @Arrow ci siete

Trovato!!! https://www.conrad.it/p/beli-beco-l-2105-sw-cavo-per-cablaggi-2-x-008-mm-nero-5-m-1437317 L' AWG28 è 0,081 mm quadrati. 1,99 euro x 5 metri 29,99 x 100 metri

Ho dato un'occhiata e sono troppo grandi rispetto all'originale. Inizialmente avevo pensato anch'io alle piattine audio, visto che ho alcune vecchie cuffie che usano appunto questo tipo di piattina rispetto al più diffuso cavo bipolare+schermatura. Ma io risultato è evidentemente diverso, rispetto al cavo originale. Probabilmente, la soluzione più veloce ed economica è l'8871, con la dovuta attenzione nel separare le due coppie.

In realtà, una risposta di @RenMarz, su un gruppo Facebook dedicato ad Arduino che seguiamo entrambi, mi ha fatto "accendere la lampadina"! Si potrebbe infatti utilizzare il cavetto PF prolunganda 50cm (codice 8871) che costa 4,69 euro. È un 4 poli, ma dovrebbe essere abbastanza semplice separarlo in due cavi da 2 poli, ognuno lungo 50 cm. Non è proprio 69 stud, ma 62... Ne ho parecchi, e domani provo l'operazione di "sostituzione"

Ok, ti confermo che è un 28 AWG. Visto che mi servono anche per un altro progetto, ho messo due rotoli nel carrello (sono da 7,5 metri l'uno) e questo è il conto, con la spedizione dagli states: Non male, considerando che costano quando un solo rotolo preso su Amazon.it, con gli stessi tempi di consegna. Però, mentre ero in fase di check-out, mi son detto "è impossibile che non ci sia un cavetto simile da usare nel modellismo ferroviario...." ed ho quindi cambiato chiave di ricerca, approdando su questo sito: https://www.conrad.it/o/piattine-e-cavi-multipolari-2510118 Devo studiare meglio i diametri, perchè probabilmente c'è quello che fa al caso nostro, spendendo qualcosa di meno dei 42 euro per quei 15 metri di cavetto

Infatti! Ho trovato a casa un 20 AWG come quello che hai indicato te, ed ecco qui la differenza: Domani prendo il calibro dal garage e lo misuro con precisione. Nel caso fosse il 28 AWG potremmo valutare di acquistare questo: https://miniatronics.com/collections/wire/products/28-ga-ultra-flex-stranded-wire-2-conductor-25-ft-black

Non ho un calibro a portata di mano per effettuare una misurazione precisaz ma io dico che è un 28 AWG quello che serve a noi...

Grazie @Arrow ma non mi piace per il fatto che c'è la banda bianca. Tra l'altro, non sono sicuro che vada bene... mi sembra troppo grosso, se è lo stesso usato per gli alimentatori.

@Arrow indicalo anche a me, che ho un ordine aperto e devo concluderlo

Per riparare quello dei treni, uso il cavo di altri 5306 'classici'. In alternativa, questo qui dovrebbe andare bene: https://www.amazon.it/2-Conductor-Flat-Mini-Black-Gauge/dp/B0006O94P2

In pubblico... in privato sono più colorito

Sono d'accordo, 535 euro al mq, per una scrivania dove ci gioco con i LEGO, è comunque assurdo. Neanche fosse Castrignano a fare l'interior designer della nostra LEGO Room

... spendere 450 euro per un tavolo 120x70, sinceramente mi sembra una follia considerato il nostro scopo.

Ecco i due cavi a confronto. Si nota benissimo quello con la guaina 'gommosa' che tende a sbriciolarsi (lo sto riparando) e quello che, nonostante il tempo, è sempre in ottima forma. Ricordavo male: quello a guaina gommosa è visibilmente più grosso, mentre ero convinto del contrario.

Credo non sia più in produzione...

Purtroppo questi cavi sono stati realizzati con due guaine differenti, di cui questa che si indurisce e sbriciola nel tempo. La differenza tra le due guaine è che una è più piatta/flessibile (quella che hai te) ed ha un aspetto nero opaco, mentre l'altra è più rotondeggiante, leggermente più rigida e di aspetto nero lucido. Dubito che tu possa ripristinare questo tipo di cavo... ti conviene acquistarne uno nuovo oppure sostituire io filo elettrico, con uno simile.

@Valter1966 Pin definition: The ESP2866 doesn't actually have any hardware I2C pins - those labeled on the Thing are the default, but you can actually use any two pins as SDA and SCL. Calling Wire.begin() will assume pins 2 and 14 are SDA and SCL, but you can manually set them to any other pin by calling Wire.begin([SDA], [SCL]). In pratica, si dovrebbe poter usare anche GPIO0 e GPIO2, benché GPIO0 è la GPIO che determina il tipo boot dell'8266 (Flash boot/Programming Boot)

Ritengo che sia più comodo lavorare a 'livello" Arduino per via della moltitudine di materiale/librerie pronte all'uso, senza la necessità di dover mettersi a studiare datasheet/protocolli. Alla fine, non serve un sistema ad altissima precisione/velocità. All'inizio ero partito con MakeCode/Micro:Bit più che altro per coinvolgere mio figlio di 13 anni che a scuola usano (direi raramente) Scratch. Poi, visto che al momento ha altri interessi, ed io altre necessità, sono passato all'ESP8266 e Arduino. (Off Topic: sto seguendo lo sviluppo del firmware Tasmota, per ESP8266. Ieri sono arrivati a 3 milioni di download dei sorgenti... Se già non lo conosci, dagli un'occhiata. Ho anche chiesto un paio di banali implementazioni per un supporto migliore alla comunicazione seriale, per usare i display 'intelligenti' Nextion).

@Valter1966 ho visto la tua email. Appena possibile ci sentiamo via telefono. Considera che non ho pensato di dirti che potremmo usare l'ESP-01, che è più stretto, visto che espone meno pin di I/O dell'8266. Ho solo il dubbio dubbio che si possano rimappare SDA/SCL sulle 4 GPIO esposte. @pivan ho messo mano sull'8266 (e, più in generale sull'atmega328P) da un paio di mesi, e sto rinfrescando le nozioni di elettronica risalenti al 1990 Sto usando gli 8266 (è un bel "gioiellino") più che altro per semplici attività di domotica 'wireless' ed ho pensato che si possano sfruttare anche nell'ambito dell'automazione dei treni LEGO, impattando il meno possibile sui diorami. Il massima, sarebbe quello di riuscire a realizzare un sensore WiFi che possa entrare nel brick 2x4 di un sensore di luce LEGO (maledizione: ne avrò 5-6, ma non riesco a trovarne uno per smontarlo e vedere gli ingombri. Ora mi leggo gli articoli che mi hai indicato...

@Valter1966 mi daresti una mano a disegnare una PCB compatta per questo sensore-attuatore-WiFi?