HomePLC.Linux, situazione 2017

[del_user_56966]

ma dai.. non era difficile...

 

 

 

 

 

[lnx]

Ciao Smooth 

 

16 hours ago, smoothhands said:

avevo tentato tempo fa... anche la strada della cross-compilazione ma l'ambiente

dell HomePLC.Linux non è completo, mancano librerie e alcune sono datate.

Comunque ho riprovato adesso con la versione ARMv7, l'ho inserita sul linux ma

non c'è verso di farla avviare. Probabilmente il modo in cui è stata compilata

non è compatibile con l'hardware/software.

 

Peccato, forse potremmo chiedere alla NBA, magari riusciamo a convincerli... 

Anche perché con pacchetti datati mi viene in mente anche l'aspetto sicurezza, SSH per esempio...

 

 

16 hours ago, smoothhands said:

la gestione ad eventi te la devi costruire tu con un linguaggio di quelli supportati.

Le varie librerie native ufficiali hanno istruzioni solo per leggere registri e per scriverli.

 

Visto che non è possibile installare qualsiasi cosa, possiamo affermare che in entrambi i casi (linguaggi supportati e librerie native) la scelta sia solamente fra C, Java, PHP, Python e QT?

 

 

16 hours ago, smoothhands said:

Il pacchetto completo è liberamente utilizzabile. Si può scaricare dal file manager della Net.

Dei sorgenti, invece, ammetto di essere un pò geloso... anche se mi rendo conto che non

sia proprio in linea con la filosofia opensource.

Certamente... io, al tempo, ho fatto qualche test con CoAP.

 

Non ho ancora l'accesso al File Manager, sono ancora un utente in attesa di attivazione. 

Comunque, se non ho capito male ci trovo sia il binding OpenHAB che la libreria Java/C modificata? Oppure sono tutt'uno in un singolo pacchetto?

 

Capisco la gelosia per i sorgenti... ma così mi fai morire di curiosità! 

 

 

On 8/29/2014 at 10:27 AM, smoothhands said:

ho messo mano alla libreria nativa aggiungendo un ciclo a polling di basso livello (scritto in c) che poi passa a java gli eventi così generati.

 

Ma come passi la codifica homeplc="QX:9.1" fra il processo HomePLC e il processo OpenHAB (e viceversa)? A che livello comunicano, socket? Sono entrambi in locale giusto? (forse all'inizio avevi OpenHAB su un embedded esterno perché parlavi di comunicazione ethernet fra i due...)

 

 

Grazie di nuovo!

[del_user_56966]

Quote

Visto che non è possibile installare qualsiasi cosa, possiamo affermare che in entrambi i casi (linguaggi supportati e librerie native) la scelta sia solamente fra C, Java, PHP, Python e QT?

 

Non sono entrato nel merito ma penso che sia uno sviluppo più lato IDE che lato libreria nativa,

le interfacce operano tutte sulla stessa libreria già presente... in teoria non c'è un limite di implementazione di altri linguaggi e solo che serve saperlo fare...

 

 

 

 

[lnx]

È che non avendo modo di provare con mano, prima di fare l'acquisto, vorrei capire se riuscirò a farci quello che vorrei... 

[smoothhands]

Quote

mi viene in mente anche l'aspetto sicurezza, SSH per esempio...

niente... openssh non è installabile. anche questo andrebbe cross-compilato e poi 

ci sono problemi con le dipendenze. Ci ho già provato 

L'unica strada, per dargli un taglio, sarebbe una ri-generazione del S.O. Linux per

l'embedded e con tutti i pacchetti che servono e aggiornati ma, soprattutto questa,

è una cosa che richiede skill solidi.

 

Quote

...nel File Manager... ci trovo sia il binding OpenHAB che la libreria Java/C modificata? Oppure sono tutt'uno in un singolo pacchetto?

l'ultima versione è così composta:

1. libreria c modificata per supportare la generazione degli eventi

2. bundle OSGi (per openHAB) con bridge java/c che include la libreria di cui al punto precedente

3. binding HomePLC (per openHAB) con dipendenze al bundle di cui al punto precedente

 

Il pacchetto è unico ma alla fine si parla di due file da inserire in openHAB... tra l'altro versione 1.x.

Di pacchetti ne esistono 2... uno per il caso HomePLC.Ladder+MasterWeb e uno per l'HomePLC.linux.

 

Quote

penso che sia uno sviluppo più lato IDE che lato libreria nativa,

le interfacce operano tutte sulla stessa libreria già presente...

Qui occorre mettersi comodi... fatto... allora andiamo.

 

Tutto ha inizio con i sorgenti della libreria scritta in c ("nativa" per gli amici di HomePLC) che

è possibile scaricare dal file manager della NET.

Questa libreria contiene le istruzioni di base del tipo...

int libHplcGetMx(unsigned short addr , unsigned char bit, unsigned short *retvalue);
int libHplcSetMx(unsigned short addr , unsigned char bit ,unsigned char value);
int libHplcGetMw(unsigned short addr , unsigned short *data);
int libHplcSetMw(unsigned short addr,unsigned short data);
int libHplcGetIx(unsigned short iw,unsigned char bit,unsigned char * retvalue);
int libHplcGetQx(unsigned short qw,unsigned char bit,unsigned char * retvalue);
int libHplcSetQx(unsigned short qw,unsigned char nbit,unsigned char value);
int libHplcSetQw(unsigned short qw,unsigned short value);
int libHplcGetQw(unsigned short qw,unsigned short * retvalue);
int libHplcGetIw(unsigned short iw,unsigned short * retvalue);
int libHplcNotQx(unsigned short qw,unsigned short nbit);

più qualche altra istruzione di utilità.

In questa libreria c'è l'interfaccia per recuperare e modificare i dati nella tabella delle risorse di HomePLC

ma per funzionare è necessario il driver per la vera interazione con il processore domotico che altro

non è che un componente della motherboard dell'embedded.

Questo driver si preoccupa dell'interazione con l'hardware e i sorgenti non sono disponibili.

 

Ogni linguaggio di programmazione non interagisce direttamente con la libreria originaria ma

interagisce con una propria particolare versione in quanto ogni linguaggio di programmazione

ha i propri meccanismi per lavorare con librerie scritte in linguaggio c.

 

Per Java si parla del componente Java Native Interface, per PHP di framework Zend e moduli,

per Python, mi pare, che effettivamente sia possibile utilizzare la libreria così com'è.

 

Nel caso delle QT... queste vengono utilizzate per realizzare l'interfaccia grafica nella 

versione con display di MasterWeb e Controller... Io avendo la versione da guida DIN

l'ho direttamente rimosse dal Sistema Operativo in modo da avere un pò più di flash

a disposizione.

 

Quindi, per chiarire meglio, i sorgenti della libreria "nativa" sono pressochè tutti uguali

ma, a seconda di quale linguaggio si richiede l'integrazione, va preparata in modo

differente.

 

Quote

Capisco la gelosia per i sorgenti... ma così...

La libreria nativa disponibile di default (Java compatibile - diciamo così) pone alcuni limiti all'utilizzo con il 

linguaggio Java: in particolare obbliga a realizzare software le cui classi appartengono tutte allo stesso package

e per una buona progettazione software questo è fortemente sconsigliato.

A questo punto erano possibili due soluzioni... percorse entrambe:

1. Utilizzare il meccanismo Java della reflection per superare questo scoglio

2. Riscrivere la libreria nativa al fine di confezionarla alle mie necessità

Devo dire che sebbene l'uso della reflection sia sconsigliato il risultato era comunque adeguato.

Riscrivere la libreria nativa ha richiesto il dover riprendere tutti i vecchi studi sul linguaggio c e

studiarsi tutto il meccanismo della Java Native Interface per scambiare informazioni tra Java e C.

Il risultato in questo caso ovviamente è molto più elegante rispetto alla reflection ma ha richiesto

tempo e impegno maggiore.

 

A questo punto perchè non spingersi oltre... e dotare la libreria nativa di un meccanismo di

inoltro eventi al variare di una risorsa. In questo modo, chi avrebbe realizzato software, avrebbe semplicemente

dovuto predisporre un Observer per poi inoltrare l'evento con il protocollo preferito (anche MQTT).

Questo, manco a dirlo, ha richiesto ulteriore studio per gestire il multithreading in c e soprattutto

permetterne nuovamente l'interazione con Java in modo diretto.

 

Sebbene questi costrutti siano di pubblico dominio a complicare la cosa si è aggiunto il fatto

che un ambiente di sviluppo, bello e pronto, non è mai esistito e quindi, prima ancora di poter

scrivere una riga di codice, ho dovuto predisporre una macchina apposta con tutta la

toolchain adeguata alla cross-compilazione e verificare, di volta in volta, che il codice

compilato risultasse veramente compatibile con l'architettura ARM dell'embedded.

 

Per la predisposizione di una toolchain devo ringraziare una base di esperienza pubblicata sul

forum originario della NET a cura di un ragazzo che aveva tentato di metterla in piedi prima di

me e quindi, con queste dritte, sono riuscito a realizzare una macchina Ubuntu con 

toolchain compatibile e poi ho personalizzato e configurato una installazione di Eclipse

come IDE per generare le librerie.

 

Ora... quanto scritto in queste poche righe (e magari anche noiose ai più) ha richiesto

diversi mesi di impegno e anche svariate notti insonni (e Aleandro lo può confermare

in quanto, anche lui, più di una volta ha dovuto rispondere verso mezzanotte o anche

oltre, a qualche mio quesito insistente  sui meccanismi più interni e particolari di HomePLC).

 

La generazione degli eventi, integrata da me nella libreria nativa di HomePLC, è una particolarità

che mi ha consentito poi successivamente di realizzare un binding openHAB bidirezionale

e, soprattutto, molto leggero (per le limitate risorse dell'embedded).

Un primo generatore di eventi lo avevo realizzato direttamente in Java ma, sebbene utilizzabile,

si mangiava troppe risorse.

 

Quindi, per finire, ho rilasciato liberamente l'utilizzo dei binding per l'interazione HomePLC/openHAB

e della libreria nativa con l'aggiunta degli eventi in modo anche di poterla perfezionare sulla base

delle esperienze di chi l'ha potuta provare.

 

Quello che ho fatto io non è l'unico meccanismo utilizzabile: una sistemista recentemente ha pensato a una

soluzione veramente elegante che sfrutta delle REST API in PHP tramite il webserver lighttpd

e la libreria HomePLC per PHP e il binding HTTP per openHAB.

Ovviamente in questo caso manca la gestione ad eventi e il tutto avviene a polling.

 

Quote

come passi la codifica homeplc="QX:9.1" fra il processo HomePLC e il processo OpenHAB (e viceversa)? A che livello comunicano, socket? Sono entrambi in locale giusto? (forse all'inizio avevi OpenHAB su un embedded esterno perché parlavi di comunicazione ethernet fra i due...)

C'è stato un momento in cui avevo una installazione di openHAB su raspberry.

Avevo un componente su HomePLC che inoltrava gli eventi e riceveva i comandi e, dall'altra parte, il binding su raspberry.

Ho fatto diversi tentativi: tramite java socket e tramite protocollo CoAP (grazie ad alcune librerie free).

 

Poi, dall'assistenza NET, mi hanno sollecitato a installare direttamente openHAB su HomePLC.Linux

ma, così com'era, si bloccava in fase di avvio.

Il problema era su alcuni componenti software che non erano compatibili con la javaVM per embedded.

A quel punto ho rimediato modificando parte dell'installazione di openHAB per adattarla al 

dispositivo su cui veniva installata.

 

Personalmente credo sia meglio, allo stato attuale, tornare a separare l'installazione di openHAB su un

dispositivo esterno e realizzare per HomePLC un componente robusto per lo scambio di dati tra

i due dispositivi. In questo modo, sul dispositivo esterno, posso utilizzare il software che più mi

aggrada e scegliere un dispositivo con un sistema operativo perfettamente aggiornato.

L'HomePLC.Linux diventa a tutti gli effetti un Gateway che espone uno o più metodi di

interfacciamento software all'HomePLC.

 

 

 

 

 

 

 

 

 

 

[lnx]

Ciao Smooth e grazie mille per il tomo didattico! 

Ho letto e riletto...

 

18 hours ago, smoothhands said:

niente... openssh non è installabile. anche questo andrebbe cross-compilato e poi ci sono problemi con le dipendenze. Ci ho già provato 

L'unica strada, per dargli un taglio, sarebbe una ri-generazione del S.O. Linux per l'embedded e con tutti i pacchetti che servono e aggiornati ma, soprattutto questa, è una cosa che richiede skill solidi.

 Quindi come ti connetti alla shell del modulo din? Solo fisicamente?

 

18 hours ago, smoothhands said:

Qui occorre mettersi comodi... fatto... allora andiamo.

Comodissimo, andiamo! 

 

18 hours ago, smoothhands said:

Ogni linguaggio di programmazione non interagisce direttamente con la libreria originaria ma

interagisce con una propria particolare versione in quanto ogni linguaggio di programmazione

ha i propri meccanismi per lavorare con librerie scritte in linguaggio c.

Per Java si parla del componente Java Native Interface, per PHP di framework Zend e moduli,

per Python, mi pare, che effettivamente sia possibile utilizzare la libreria così com'è.

Quindi, per chiarire meglio, i sorgenti della libreria "nativa" sono pressochè tutti uguali ma, a seconda di quale linguaggio si richiede l'integrazione, va preparata in modo differente.

Cominciamo a scendere nel tecnico, benissimo! Fin qui mi torna...  

 

18 hours ago, smoothhands said:

A questo punto erano possibili due soluzioni... percorse entrambe:

1. Utilizzare il meccanismo Java della reflection per superare questo scoglio

2. Riscrivere la libreria nativa al fine di confezionarla alle mie necessità

Devo dire che sebbene l'uso della reflection sia sconsigliato il risultato era comunque adeguato.

Riscrivere la libreria nativa ha richiesto il dover riprendere tutti i vecchi studi sul linguaggio c e

studiarsi tutto il meccanismo della Java Native Interface per scambiare informazioni tra Java e C.

Il risultato in questo caso ovviamente è molto più elegante rispetto alla reflection ma ha richiesto

tempo e impegno maggiore.

Effettivamente senza reflection suona molto meglio... ma capisco il lunghissimo lavoro che c'è dietro... 

Hai la mia totale ammirazione! 

 

18 hours ago, smoothhands said:

A questo punto perchè non spingersi oltre... e dotare la libreria nativa di un meccanismo di

inoltro eventi al variare di una risorsa. In questo modo, chi avrebbe realizzato software, avrebbe semplicemente dovuto predisporre un Observer per poi inoltrare l'evento con il protocollo preferito (anche MQTT).

Questo, manco a dirlo, ha richiesto ulteriore studio per gestire il multithreading in c e soprattutto

permetterne nuovamente l'interazione con Java in modo diretto.

Peccato sono già sposato!!! 

 

18 hours ago, smoothhands said:

Quello che ho fatto io non è l'unico meccanismo utilizzabile: una sistemista recentemente ha pensato a una soluzione veramente elegante che sfrutta delle REST API in PHP tramite il webserver lighttpd e la libreria HomePLC per PHP e il binding HTTP per openHAB.

Ovviamente in questo caso manca la gestione ad eventi e il tutto avviene a polling.

Bè, la tua soluzione è a mio giudizio sicuramente la migliore e la più elegante.

Sempre a mio giudizio, ritengo che il sistema ad eventi sia pressoché indispensabile per rendere il tutto più "naturale", OTTIMO LAVORO! 

 

18 hours ago, smoothhands said:

C'è stato un momento in cui avevo una installazione di openHAB su raspberry.

Avevo un componente su HomePLC che inoltrava gli eventi e riceveva i comandi e, dall'altra parte, il binding su raspberry.

Ho fatto diversi tentativi: tramite java socket e tramite protocollo CoAP (grazie ad alcune librerie free).

 

Personalmente credo sia meglio, allo stato attuale, tornare a separare l'installazione di openHAB su un dispositivo esterno e realizzare per HomePLC un componente robusto per lo scambio di dati tra

i due dispositivi. In questo modo, sul dispositivo esterno, posso utilizzare il software che più mi

aggrada e scegliere un dispositivo con un sistema operativo perfettamente aggiornato.

L'HomePLC.Linux diventa a tutti gli effetti un Gateway che espone uno o più metodi di

interfacciamento software all'HomePLC.

Sì, anche qui sono completamente d'accordo.

HomePLC.Linux sarebbe bene fosse il più leggero possibile, ogni componente aggiuntivo (specialmente se di alto livello) lo vedo più opportuno separato e quindi "facilmente" intercambiabile 

 

Ed è quello che piacerebbe fare a me: HomePLC.Linux con (i tuoi) eventi, gestione (OpenHAB o altro) su embedded separato e dialogo MQTT 

Spero di poterci mettere le mani presto e, se mi dici che è possibile, provare questa strada... non vedo l'ora!

 

Grazie sopratutto e te e gente come te che ha già fatto gran parte del lavoro sporco 

E grazie anche ad Aleandro per l'indispensabile supporto che ti ha dato 

Grazie grazie grazie!

[smoothhands]

Quote

Quindi come ti connetti alla shell del modulo din? Solo fisicamente?

L'HomePLC.Linux è dotato di porta ethernet, RS485 (più di una), RS232 condivisa

e una com. Mi connetto con ssh ma l'embedded utilizza...

dropbear       0.51-1-ev1     lightweight SSH2 server and client

ma non ho idea se si possa utilizzare anche per altre cose.

 

Quote

HomePLC.Linux con (i tuoi) eventi, gestione (OpenHAB o altro) su embedded separato e dialogo MQTT 

Spero di poterci mettere le mani presto e, se mi dici che è possibile, provare questa strada...

il sistema linux sull'embedded soffre di alcune limitazioni (che ho cercato di illustrare il meglio possibile) dovute a

ben precise scelte, non ultime quelle della stabilità e leggerezza, ma senza sacrificare troppo le possibilità agli sviluppatori.

L'hardware è fin troppo potente se utilizzato semplicemente come gateway/adapter però la mia scelta, dopo anni di

prove (oramai...), ricadrebbe nell'utilizzare l'HomePLC.Ladder + MasterWeb.

Questo perchè la logica di controllo la demanderei principalmente al sistema meglio supportato e aggiornato da

parte del produttore e sarei sicuro delle massime performance e compatibilità con tutto il sistema HomePLC.

Poi affiancherei a questo il MasterWeb in modo da lavorare come gateway verso l'applicativo che preferisco.

Sul MasterWeb cercherei di predisporre più interfacce standard possibili (REST HTTP, WebSocket, MQTT, CoAP, etc...)

verso il mondo esterno in modo da garantirmi l'integrabilità col resto del mondo in futuro.

 

[lnx]

Eccomi. Scusa ma dopo questo tuo ultimo commento mi sono riletto alcuni vecchi post per evitare di fare domande già risposte in passato.

 

Innanzitutto ho capito una cosa fondamentale! HomePLC.Linux e Master Web sono la stessa cosa (hardware), dipende solo dal firmware che viene flashato!

Poi ho letto che te hai acquistato sia HomePLC.Linux (flashato come controller), sia HomePLC.Ladder (senza mai attivare la licenza)... se posso permettermi, strana scelta 2 controller 

Ma comunque scusa... eventualmente il re-flash è una cosa fattibile in autonomia, giusto? O può farlo solo la NET?

Perché se fosse fattibile in autonomia potresti sempre acquistare licenza Ladder, flashare il firmware master sull'HomePLC.Linux ed ottendere così il setup di cui parli... Sbaglio? 

 

Ad ogni modo, tornando a noi... Vorrei cercare di fare finalmente il punto e capire la migliore direzione per me.

 

Premetto che sono prettamente un utente linux, Windows l'ho abbandonato parecchi anni fa. Capisco la tua osservazione sul maggior supporto Ladder e tutto il resto... ma personalmente l'idea di usare Windows mi intristisce un po' 

 

Poi ricordo anche di aver letto che l'ambiente Master Web (essendo un master e non il controller principale) non ha il completo accesso/controllo ai registri del controller, come invece ha HomePLC.Linux essendo tutt'uno... questo non porta a complicazioni come ad esempio allineamento stati, doppi registri da mantenere e perdita degli eventi??? 

 

On 5/31/2016 at 12:05 AM, smoothhands said:

La primissima versione prevedeva di installare openHAB su un dispositivo separato: come un raspberry pi.

In questo modo il trasferimento dei dati tra raspberry e HomePLC.Linux avveniva via rete.

L'elaborazione dell'evento avveniva sempre in modo nativo nella libreria per linux quindi poi inviato ad openHAB via rete. In questo modo la lentezza del trasferimento via rete non pregiudicava più di tanto le prestazioni.

 

Comunicavo inizialmente tramite socket e scambio di dati mediante connessione TCP di pacchetti binari in Java.

Poi ho fatto della prove tramite protocollo CoAP.

Onestamente questa primissima versione di cui parli è quella che mi sembra più adatta a me (non esiste il migliore, esiste il più adatto, giusto?  ):

1. Ambiente totalmente linux (addio VirtualBox, Wine o PlayOnLinux)

2. Eventi!!! (e possibilmente comunicazione MQTT)

3. Applicativo di alto livello su RPi3 indipendente (OpenHAB o altro)

 

Ripeto, capisco quello che dici sul Ladder, supporto e tutto il resto... quindi se questa direzione ti senti di sconsigliarla ti prego di smontarmi subito!  

Grazie ancora e buona domenica! 

[smoothhands]

Ciao lnx,

Quote

...strana scelta 2 controller

Quando ho acquistato l'HomePLC.Linux non sapevo se sarei riuscito ad ottenere qualcosa di utilizzabile. 

Sono partito da zero e per paura di rimanere senza logica ho pensato di acquistare comunque la versione Ladder.

In realtà, se correttamente configurato e progettato, un impianto HomePLC funziona già egregiamente

anche solo con la logica distribuita presente sui singoli moduli DIN.

Quindi ho collegato completamente il mio impianto ma ho inserito il controller solo quando avevo raggiunto

una versione funzionante del sistema.

Non ho mai attivato la mia licenza Ladder perchè, al tempo, aveva una durata limitata. Poi non mi sono più informato.

Non so dirti come vengono gestite le licenze attualmente.

 

Quote

 il re-flash è una cosa fattibile in autonomia, giusto? O può farlo solo la NET?

Puoi farlo in autonomia... sempre con accortezza ovviamente.

 

Quote

potresti sempre acquistare licenza Ladder, flashare il firmware master sull'HomePLC.Linux ed ottendere così il setup di cui parli

Si, è sempre fattibile.

 

Quote

...questo non porta a complicazioni come ad esempio allineamento stati, doppi registri da mantenere e perdita degli eventi???

La tabella delle risorse del sistema HomePLC è composta da 8000 registri da 16bit.

La parte domotica (chiamiamola così) dell'embedded mantiene aggiornata (visto l'accesso al bus) una

tabella della stessa dimensione indicata prima.

La versione HomePLC.Linux (in quanto controller) è posizionata al primo livello dell'architettura e quindi ha il pieno controllo

di tutte le aree della tabella delle risorse.

La versione MasterWeb è posizionata al livello dei master e comprensibilmente non può avere gli stessi privilegi del

controller: in primis l'accesso in scrittura su alcune risorse gestite direttamente dal controller Ladder.

Nessun problema di allineamento stati: il tutto è gestito dal protocollo XComm.

 

Per gli eventi occorre che siano ben chiare un paio di cose:

- Nativamente, previsti dall'azienda, esistono degli eventi gestiti dal protocollo XComm ma rilevabili solo da ABS.

- Sono riuscito a modificare col tempo la versione originale della shared library libhplclib.so utilizzabile da software Java.

Nel secondo caso il funzionamento degli eventi è vincolato all'utilizzo del linguaggio Java.

 

Quote

non esiste il migliore, esiste il più adatto, giusto?

Si, sono d'accordo con te, però è bene che ti faccia un'idea ben precisa di cosa sia possibile fare e cosa no.

Meglio ancora che ti renda conto di quali limitazioni ci siano per poter sfruttare al meglio il dispositivo e il sistema.

 

Si tratta di un ambiente Linux a tutti gli effetti.

Puoi connettere al pacchetto java/shared library una libreria MQTT che puoi rimediare in rete ma devi comunque

prevedere anche un server che faccia da message broker. E progettare il contenuto dei messaggi.

All'esterno puoi utilizzare quello che preferisci... sempre che comprenda quello che riceve.

openHAB ha binding che fa da client MQTT.

 

Quote

se questa direzione ti senti di sconsigliarla ti prego di smontarmi subito!

Non posso sconsigliarti a priori questa strada per il semplice fatto che io stesso utilizzo esclusivamente un HomePLC.Linux.

Però, se consideri bene la natura di un sistema come openHAB, puoi notare come la sua posizione centrale non

snatura i singoli sistemi a cui è connesso. Questo software è un Home Automation Bus in grado di veicolare

informazioni tra sistemi anche molto differenti.

Io stesso, alla fine, ho fatto "l'errore" di inserire completamente la logica di controllo all'interno di openHAB

ma, sebbene stia funzionando da qualche anno, non potrà mai essere reattiva come se fosse programmata 

direttamente sul dispositivo. Eventualmente anche in Java... ma sempre direttamente sul dispositivo.

openHAB interpreta la logica di controllo in base ai suoi file di configurazione e quindi, nonostante i suoi vantaggi,

è inevitabilmente lenta. Il suo compito sarebbe quello di lavorare ad alto livello e integrare sistemi domotici (o meno) differenti.

 

Tornando al sistema HomePLC basato su Linux

come ti ho scritto qualche post fa... il supporto al parco dispositivi HomePLC è un pò più limitato rispetto alla versione

Ladder e i relativi firmware sono un pò più vecchi. Detto questo... in casa mia funziona tutto comunque egregiamente 

 

Non so che altro aggiungere. Se hai qualche domanda/dubbio più specifico chiedi pure.

 

 

 

 

 

[lnx]

Ciao smoothhands,

 

2 hours ago, smoothhands said:

Quando ho acquistato l'HomePLC.Linux non sapevo se sarei riuscito ad ottenere qualcosa di utilizzabile. 

Sono partito da zero e per paura di rimanere senza logica ho pensato di acquistare comunque la versione Ladder.

Immaginavo, era solo una curiosità 

 

2 hours ago, smoothhands said:

In realtà, se correttamente configurato e progettato, un impianto HomePLC funziona già egregiamente anche solo con la logica distribuita presente sui singoli moduli DIN.

Quindi ho collegato completamente il mio impianto ma ho inserito il controller solo quando avevo raggiunto una versione funzionante del sistema.

Su questo, anche se poi approfondirò più avanti, credo di aver capito che il controller è omettibile solo collegando ingressi con uscite locali (rispetto ai singoli moduli DIN intendo), giusto? Scelta che tra l'altro immagino sia sempre consigliabile, in caso di un'eventuale problema al controller...

Anche se comunque non ho capito come imporre al singolo modulo DIN una particolare logica senza passare per il controller (tipo attiva l'uscita 1 sia con l'ingresso 1 che con l'ingresso 2). Anche i moduli DIN sono programmabili magari collegandosi fisicamente? 

 

2 hours ago, smoothhands said:

Non ho mai attivato la mia licenza Ladder perchè, al tempo, aveva una durata limitata. Poi non mi sono più informato.

Non so dirti come vengono gestite le licenze attualmente.

Effettivamente non ho ancora capito quanto possa costare un anno di licenza Ladder, nemmeno a grandi linee... €50? €100? €1000? @Aleandro2008 ? 

 

2 hours ago, smoothhands said:

La parte domotica (chiamiamola così) dell'embedded mantiene aggiornata (visto l'accesso al bus) una tabella della stessa dimensione indicata prima.

Scusa, non sono sicuro di aver capito... Questo solo con il firmware Master Web o anche nella versione controller? Se specifichi "accesso al bus" immagino che la duplice tabella di cui parli riguardi solo il Master Web...

 

2 hours ago, smoothhands said:

La versione HomePLC.Linux (in quanto controller) è posizionata al primo livello dell'architettura e quindi ha il pieno controllo di tutte le aree della tabella delle risorse.

La versione MasterWeb è posizionata al livello dei master e comprensibilmente non può avere gli stessi privilegi del controller: in primis l'accesso in scrittura su alcune risorse gestite direttamente dal controller Ladder.

[...]

Meglio ancora che ti renda conto di quali limitazioni ci siano per poter sfruttare al meglio il dispositivo e il sistema.

Sì, è chiarissimo. È per questo che HomePCL.Linux mi convince personalmente di più... Perché mi sembra che, per un linuxiano come me, sia più lineare (meno intermediari) e più versatile (tutti i registri con pieni poteri a portata di mano).

Comunque, a parte la maggiore robustezza del Ladder e l'inferiore dedizione da parte della NET per il controller linux, non vedo particolari aspetti negativi, anzi... ma le cose da capire sono tantissime, forse mi sfugge qualche altro aspetto negativo o limitazione... 

 

2 hours ago, smoothhands said:

Sono riuscito a modificare col tempo la versione originale della shared library libhplclib.so utilizzabile da software Java.

Nel secondo caso il funzionamento degli eventi è vincolato all'utilizzo del linguaggio Java.

[...]

Si tratta di un ambiente Linux a tutti gli effetti.

Puoi connettere al pacchetto java/shared library una libreria MQTT che puoi rimediare in rete ma devi comunque prevedere anche un server che faccia da message broker. E progettare il contenuto dei messaggi.

All'esterno puoi utilizzare quello che preferisci... sempre che comprenda quello che riceve.

openHAB ha binding che fa da client MQTT.

Poco tempo fa ho fatto qualche esperimento con Raspberry (tramite i pin GPIO controllavo relay, regolavo dimmer e leggevo sensori) e diversi software sia open (ho provato anche OpenHAB) sia scritto da me (utilizzando NodeJS e Android), il tutto con comunicazione prettamente MQTT. Funzionava tutto, luci, dimmer e sensori... Magari ti mando un messaggio privato per non andare off topic.

Essendo questa una soluzione indubbiamente sperimentale, mi piacerebbe sostituire la parte GPIO con un sistema domotico vero (sistema HomePLC appunto) ed installare quindi il tutto come impianto di casa primario.

Se ho capito bene, correggimi se sbaglio, i passi che dovrei fare (immaginando di avere un HomePLC.Linux) sarebbero:

1. Sostituire, con il tuo permesso e consenso, la libreria libhplclib.so
2. Creare un software Java (con JNI) che in background trasformi tutto (sia le azioni dell'utente, sia gli eventi da te implementati) in messaggi MQTT
3. Installare Mosquitto (su Raspberry nel caso non fosse possibile sullo stesso controller linux per limitazioni inaspettate)
4. Continuare ad utilizzare le mie applicazioni di alto livello esattamante come facevo prima

Mi sugge qualcosa?

Nel caso sia corretto, la strada Master Web mi sembrerebbe un po' più tortuosa per ottenere questo setup che avrei in mente... ma forse è solo perché mi sto focalizzando esclusivamente su HomePLC.Linux 

 

2 hours ago, smoothhands said:

Io stesso, alla fine, ho fatto "l'errore" di inserire completamente la logica di controllo all'interno di openHAB ma, sebbene stia funzionando da qualche anno, non potrà mai essere reattiva come se fosse programmata direttamente sul dispositivo. Eventualmente anche in Java... ma sempre direttamente sul dispositivo.

Ti chiedo scusa, non ho capito 

Perché dici "ho fatto l'errore di inserire completamente la logica di controllo all'interno di openHAB"? OpenHAB non ti permette solo di inviare e ricevere roba (e quindi gestire tramite hplc="%...") usando una comoda interfaccia web?

E anche "non potrà mai essere reattiva come se fosse programmata direttamente sul dispositivo"... ma non hai (anche se solo successivamente) installato OpenHAB sul controller?

Ad ogni modo, OpenHAB non è nei miei piani... 

 

2 hours ago, smoothhands said:

Tornando al sistema HomePLC basato su Linux come ti ho scritto qualche post fa... il supporto al parco dispositivi HomePLC è un pò più limitato rispetto alla versione Ladder e i relativi firmware sono un pò più vecchi. Detto questo... in casa mia funziona tutto comunque egregiamente 

Esatto! 

Ed eviterei Windows... 

 

2 hours ago, smoothhands said:

Non so che altro aggiungere. Se hai qualche domanda/dubbio più specifico chiedi pure.

Già approfitto abbastanza, dimmelo pure... 

[lnx]

6 hours ago, smoothhands said:

Io stesso, alla fine, ho fatto "l'errore" di inserire completamente la logica di controllo all'interno di openHAB

ma, sebbene stia funzionando da qualche anno, non potrà mai essere reattiva come se fosse programmata 

direttamente sul dispositivo.

 

Ho appena rivisto il tuo video ed effettivamente dici:

"Allo stesso modo reagiscono abbastanza rapidamente anche premendo i classici pulsanti, tutto controllato dalle regole di OpenHAB".

 

Mi sembra di capire proprio che l'analogo della programmazione Ladder l'hai realizzata con le regole di OpenHAB, non avevo colto questo aspetto fin'ora... 

 

Ma scusami, i pulsanti fisici non sono direttamente connessi agli ingressi %IX HomePLC e OpenHAB riceve solo il famoso evento "l'uscita %QXn.m si è attivata" per allineare gli stati dei client? 

Io avrei in mente di fare così... è fattibile?

[smoothhands]

Ciao lnx,

Quote

non ho capito come imporre al singolo modulo DIN una particolare logica senza passare per il controller

la logica locale al modulo la “configuri” dal software di supervisione ABS.

 

Quote

i moduli DIN sono programmabili magari collegandosi fisicamente?

li “configuri” sempre tramite controller: nel caso Ladder devi usare un convertitore oppure l'ETM*.

 

Quote

solo con il firmware Master Web o anche nella versione controller?

entrambe le versioni. Cambiano solo le aree di tale tabella che vengono aggiornate.

Nel MasterWeb sono in numero minore e non tutte in RW.

 

Quote

1. Sostituire, con il tuo permesso e consenso, la libreria libhplclib.so

Non serve il mio permesso... é già disponibile.

Forse servirà qualche piccolo aggiustamento nel caso ti serva qualcosa di specifico.

 

Quote

1. Creare un software Java (con JNI) che in background trasformi tutto (sia le azioni dell'utente, sia gli eventi da te implementati) in messaggi MQTT

La parte con JNI é già stata fatta... devi solo implementare l'interfaccia di un metodo che

altro non è che il listener del generatore di eventi.

Poi tocca a te tutta la parte MQTT.

 

Quote

Perché dici "ho fatto l'errore...

openHAB non é solo interfaccia. É soprattutto logica di controllo.

Inoltre l'interfaccia non é solo web ma anche nativa per iOS, Android e Microsoft.

 

[smoothhands]

Quote

...e OpenHAB riceve solo il famoso evento "l'uscita %QXn.m si è attivata" per allineare gli stati dei client?

Eh no...

In openHAB sono state configurate tante risorse (gli Item) quante sono quelle effettivamente utilizate

da HomePLC, ognuna con una stringa specifica.

Quando premo un pulsante fisico viene inviato un segnale lungo il bus e il processore domotico

modifica un registro della tabelle delle risorse.

Il generatore di eventi nella libreria nativa si accorge di tale variazione e inoltra l'evento

al binding HomePLC realizzato apposta per openHAB.

Il binding, ricevuto l'evento, aggiorna lo stato dell'Item corrispondente e viene eseguita

una rule opportuna se programmata in modo da reagire a quel particolare evento.

La rule puó essere dal semplice relé passo-passo alla piú complessa gestione delle

tapparelle e... chi piú ne ha piú ne metta. Hai un intero linguaggio a disposizione (XTend)

per realizzare queste rule.

Ammettendo di voler accendere una luce la rule inoltrerà un comando verso un altro

Item associato a una risorsa di uscita di HomePLC.

Lanciato il comando il binding inoltrerà alla libreria nativa l'esecuzione di una istruzione

opportuna per variare un registro della tabella delle risorse.

Il processore domotico si occuperà di rilevare la variazione e distribuire lungo il bus

l'attuazione.

 

Quando un Item varia opeHAB notifica tutte le interfacce attive.

 

Ho tralasciato dettagli ma il percorso é questo.

[lnx]

Ciao smoothhands,

 

16 hours ago, smoothhands said:

In realtà, se correttamente configurato e progettato, un impianto HomePLC funziona già egregiamente anche solo con la logica distribuita presente sui singoli moduli DIN.

Quindi ho collegato completamente il mio impianto ma ho inserito il controller solo quando avevo raggiunto una versione funzionante del sistema.

 

9 hours ago, smoothhands said:

la logica locale al modulo la “configuri” dal software di supervisione ABS.

li “configuri” sempre tramite controller: nel caso Ladder devi usare un convertitore oppure l'ETM*.

Perdonami, non ho capito bene.

Prima leggo che hai collegato il controller solo dopo aver raggiunto una versione funzionante (poiché un sistema HomePLC può lavorare anche con logica locale sui DIN) e poi leggo che i moduli DIN si configurano tramite controller... 

 

9 hours ago, smoothhands said:

Quando premo un pulsante fisico viene inviato un segnale lungo il bus

Scusa, usi pulsanti "domotici" direttamente collegati al bus, oppure pulsanti elettrici normalissimi collegati agli ingressi dei moduli I/O?

 

9 hours ago, smoothhands said:

e il processore domotico modifica un registro della tabelle delle risorse.

Immagino che l'ingresso %IXn.m cambi da 0 a 1, giusto?

 

9 hours ago, smoothhands said:

Il generatore di eventi nella libreria nativa si accorge di tale variazione e inoltra l'evento

al binding HomePLC realizzato apposta per openHAB.

Quindi nel tuo caso l'evento che viene emesso sul sistema è la variazione dell'ingresso, non dell'uscita!! Corretto?

 

Onestamente a me piacerebbe fare diversamente, ma vorrei capire se è fattibile. 

 

Preferirei implementare la logica di controllo/programmazione in altro modo (non con OpenHAB, anche se mi pare di aver capito che si possa usare solamente java se vogliamo gli eventi) ed, eventualmente, relegare OpenHAB al suo scopo originale (quello di stare "on-top" e coordinare solamente...).

L'evento che vorrei propagare quindi sarebbe la variazione delle uscite per l'allineamento stati (e non le variazioni degli ingressi)... è un ragionamento corretto?? 

[smoothhands]

Ciao lnx,

Quote

Perdonami, non ho capito bene.

La configurazione (o programmazione locale) dei vari moduli la si fa da software di supervisione e il modo per

farlo è quello di connettere un convertitore usb o il modulo ETM* (nel caso ladder).

Il modo che conosco è quello di connetterli alla porta RS485 del controller ladder oppure direttamente tramite connettore di

rete al controller linux. Non sono sicuro che la programmazione locale possa essere fatta connettendo il convertitore direttamente

al dispositivo.

 

Ho acquistato i sistema HomePLC prima che l'appartamento fosse completato. Quindi ho inziato a fare i miei test

su una valigetta di prova autocostruita. Ho acquistato anche due set di alimentazione.

Una volta terminato l'appartamento ho installato nel quadro elettrico e nelle cassette di distribuzione i vari dispositivi

ma non avendo ancora completato i miei test ho lasciato il controller linux nella valigetta.

Prima di installare i componenti nell'appartamento però li ho programmati collegandoli al controller.

 

In realtà avrei potuto anche inserire il controller linux direttamente nel quadro elettrico e programmarlo tranquillamente

tramite rete ethernet. La logica del controller rimane esclusa fino a quando non la attivi da programma.

 

Il funzionamento della logica locale ai moduli è abbastanza elaborata e potresti farla funzionare congiuntamente

alla logica centrale del controller: per capire bene il tutto dovresti partecipare a un corso.

 

 

 

[lnx]

2 minutes ago, smoothhands said:

Il funzionamento della logica locale ai moduli è abbastanza elaborata e potresti farla funzionare congiuntamente

alla logica centrale del controller: per capire bene il tutto dovresti partecipare a un corso.

 

Sì, lo so... c'era un corso la settimana scorsa ma purtroppo per motivi di lavoro non sono potuto andare.

Mercoledì pomeriggio comunque ho un appuntamento alla NET, magari riesco a contrattare una lezioncina privata 

[smoothhands]

Ciao lnx,

Quote

usi pulsanti "domotici" direttamente collegati al bus, oppure pulsanti elettrici normalissimi collegati agli ingressi dei moduli I/O?

uso pulsanti di una serie qualunque collegati agli ingressi dei moduli DIN o alle "zampe" dei ragnetti.

 

Quote

l'ingresso %IXn.m cambi da 0 a 1, giusto?

si esatto... si tratta di un bit all'interno di un ben preciso registro.

 

Quote

l'evento che viene emesso sul sistema è la variazione dell'ingresso, non dell'uscita!!

Rilevo variazioni sia sugli ingressi che sulle uscite (tutti i registri in pratica).

In questo modo, quando un comando da logica modifica un'uscita, inizialmente

il comando si propaga verso l'HomePLC e poi, alla modifica della risorsa, un evento

risale per confermare che la risorsa è stata realmente modificata.

 

Non ti confondere però con l'attuazione vera e propria che si propaga nel bus e spetta al sistema HomePLC

a partire dalla tabella delle risorse.

 

Quote

mi pare di aver capito che si possa usare solamente java se vogliamo gli eventi

attualmente è così.

Visto che la libreria nativa è una shared library potrebbe essere utilizzata con programmi

scritti in c/c++ e forse in python... ma andrebbe comunque modificata.

 

Quote

L'evento che vorrei propagare quindi sarebbe la variazione delle uscite per l'allineamento stati (e non le variazioni degli ingressi)

Se hai intenzione di realizzare la tua logica direttamente sul controller Linux gli eventi sulle uscite potrebbero essere sufficienti.

Però occorrerebbe verificare caso per caso quello che vuoi realizzare.

Ad esemprio se integri HomePLC con un'altro sistema e vuoi comandare, che sò... PIPPO, al variare

della temperatura di una sonda... a quel punto ti serve anche l'evento su quell'ingresso.

 

 

 

[lnx]

Ciao Smooth,

 

23 minutes ago, smoothhands said:

Se hai intenzione di realizzare la tua logica direttamente sul controller Linux gli eventi sulle uscite potrebbero essere sufficienti.

Però occorrerebbe verificare caso per caso quello che vuoi realizzare.

Ad esemprio se integri HomePLC con un'altro sistema e vuoi comandare, che sò... PIPPO, al variare

della temperatura di una sonda... a quel punto ti serve anche l'evento su quell'ingresso.

Sì, scusa... ovviamente la sensoristica prevende eventi scatenati dagli ingressi 

 

27 minutes ago, smoothhands said:

Rilevo variazioni sia sugli ingressi che sulle uscite (tutti i registri in pratica).

In questo modo, quando un comando da logica modifica un'uscita, inizialmente il comando si propaga verso l'HomePLC e poi, alla modifica della risorsa, un evento risale per confermare che la risorsa è stata realmente modificata.

Bello!!! Il doppio controllo mi piace, la famosa prova del nove! 

 

Ad ogni modo, che dici... realizzare un componente Java (JNI) dedicato per la logica/programmazione potrebbe essere comunque più snello di OpenHAB nonostante il linguaggio sia il medesimo...

 

E ancora grazie mille! 

[lnx]

1 hour ago, lnx said:

Sì, scusa... ovviamente la sensoristica prevende eventi scatenati dagli ingressi 

 

Prevede, non prevende 

[smoothhands]

In tutto questo trambusto però non ho ancora capito

in quale linguaggio vorresti realizzare la tua logica di controllo.

 

Se ti va bene Java é già tutto pronto, non devi assolutamente

pensare a JNI, e realizzi il tuo software senza nemmeno troppe beghe

per l'ambiente di sviluppo.

L'unica cosa é acquistare una versione di HomePLC.Linux più carrozzata

per stare più tranquillo con memoria e performance.

Io ho la versione 1GHz 1GByte RAM 256MByte flash.

Sicuramente é molto più snello che usare openHAB.

Te ne accorgi della differenza proprio quando premi un pulsante fisico.

Comunque se con openHAB accende e spegne le luci mia moglie...

...vuol dire che la differenza é accettabile 

 

Se vuoi lavorare in c/c++, soluzione più performante, devo metterci invece le

mani per quanto riguarda gli eventi. Tempo permettendo ovviamente.

 

 

 

 

[lnx]

Ciao Smooth,

 

30 minutes ago, smoothhands said:

In tutto questo trambusto però non ho ancora capito in quale linguaggio vorresti realizzare la tua logica di controllo.

Sì, hai ragione, è colpa mia...  è che senza l'accesso a nessuna guida né manuale ho impiegato un po' per cominciare a districarmi con tutte queste nozioni e quindi sicuramente ho scritto cose un po' a caso 

Mercoledì pomeriggio spero di farmi dare qualcosa di cartaceo su cui studiare, implorerò... 

Detto questo, se fosse il C/C++ a sostituire il Ladder sarebbe ovviamente il top... ma hai già fatto tanto, tantissimo!!! Direi di iniziare con Java, poi vedremo... se questo progetto diventerà reale (come spero), sarei anche disposto a darti una mano nella manovalanza (anche se non è che abbia tanta esperienza in C/C++) 

 

30 minutes ago, smoothhands said:

Se vuoi lavorare in c/c++, soluzione più performante, devo metterci invece le mani per quanto riguarda gli eventi. Tempo permettendo ovviamente.

Ma questo non posso chiederlo 

 

30 minutes ago, smoothhands said:

Se ti va bene Java é già tutto pronto, non devi assolutamente pensare a JNI, e realizzi il tuo software senza nemmeno troppe beghe per l'ambiente di sviluppo.

Sì sì, chiaro... ma come è emerso precedentemente, nel tuo componente Java/JNI dovrei aggiungere la parte MQTT e se la gelosia sui sorgenti permane  (ne hai tutto il diritto ovviamente  ) forse che dovrò riscrivere il tutto... 

Vedremo, vedremo...

 

30 minutes ago, smoothhands said:

Sicuramente é molto più snello che usare openHAB.

Magari poi ti faccio venire voglia e mi segui... 

 

Grazie sul consiglio hardware. Purtroppo nell'ecommerce HBE non vengono elencati tutti i device e ovviamente manca l'HomePLC.Linux quindi non so quali e quanti modelli ci siano (mi sembra di aver capito due comunque, il tuo da 1GHz dovrebbe essere il più potente...)

Ad ogni modo, l'HomePLC.Ladder da guida DIN leggo che costa meno di €500 (non so se posso scrivere il prezzo esatto che vedo online), il linux non so... 

[smoothhands]

Quote

e se la gelosia sui sorgenti permane ... forse che dovrò riscrivere il tutto

Mi tengo magari quelli modificati in C  ma la parte Java mi toccherà dartela

altrimenti come fai ad andare avanti. Non ha senso riscrivere tutto.

 

Poi per la parte c/c++ vedremo... come ho detto è una shared library

e quindi puoi usarla come componente.

Dovrei però riscrivere sicuramente i nomi delle funzioni altrimenti 

risulterebbe inutilizzabile da c/c++.

Dai vediamo. Intanto senti con la NET cosa ti dicono poi fa sapere.

 

 

 

 

[lnx]

Grazie mille Smooth, sei stato indispensabile...  e speriamo che l'incontro sia proficuo. 

Buona serata!

[del_user_56966]

Quote

Non so dirti come vengono gestite le licenze attualmente.

 

La licenza per il Ladder adesso è gratuita,

inoltre è già noto che anche la prossima versione del Ladder che è molto più potente e professionale sarà gratuita... 

|

La versione Linux del Controller nella fase attuale del progetto non ha caratteristiche di Supervisione ma è dedicata solo al controllo della logica ecco..

perché manca lo strato ad eventi...

nella seconda fase (che però per adesso non si sa quando partirà) sembra che oltre a queste funzioni ci saranno molte altre funzionalità innovative...

del resto come sempre nei sistemi HomePLC..

|

in effetti la versione Ladder è andata molto avanti come sviluppo... nel Ladder si scrive sempre meno mentre le funzioni sono sempre più performanti..

anche se non ho molto tempo da dedicarci non mi dispiacerebbe se in seguito le due versioni venissero allineate..  

in particolare per favorire l'accesso alla Bioregolazione... 

 

 

 

 

 

 

 

[lnx]

Ciao Aleandro,

 

3 minutes ago, Aleandro2008 said:

La licenza per il Ladder adesso è gratuita,

inoltre è già noto che anche la prossima versione del Ladder che è molto più potente e professionale sarà gratuita... 

Intendi anche dopo il primo anno? Per sempre??

 

3 minutes ago, Aleandro2008 said:

La versione Linux del Controller nella fase attuale del progetto non ha caratteristiche di Supervisione ma è dedicata solo al controllo della logica ecco..

perché manca lo strato ad eventi...

Se tutto va bene sono prossimo all'acquisto di un HomePLC.Linux, come avrai capito dalla discussione... potresti per cortesia essere più terra terra su questo punto? Vorrei togliermi più dubbi possibile prima, non dopo 

 

3 minutes ago, Aleandro2008 said:

in effetti la versione Ladder è andata molto avanti come sviluppo... nel Ladder si scrive sempre meno mentre le funzioni sono sempre più performanti..

anche se non ho molto tempo da dedicarci non mi dispiacerebbe se in seguito le due versioni venissero allineate..  

in particolare per favorire l'accesso alla Bioregolazione... 

Sì, dei pro del Ladder ne sono consapevole, ma purtroppo io ho una decisa avversione verso Windows, i contro della versione Linux dovrebbero essere proprio molti... 

E spara pure casomai, sono tutto orecchi