Supervisione - Integrazione Tra Diverse Sedi E Diverse Tecnologie

[Bacaezio]

Ciao a tutti,

da circa 2 anni, ho ereditato la gestione e configurazione/evoluzione di un impianto KNX con circa 400 dispositivi, a cui ho aggiunto un sistema di super visione OpenHAB, il cliente usa quest'ulitmo per la gestione di luci, tapparelle e gestione riscaldamento, quest'ultimo è l'aspetto più importante e utilizzato in quanto viene utilizzato per l'accensione e spegnimento del riscaldamento in determinati locali o nei giorni di chiusura dell'edeficio. Detto questo, ora mi viene chiesto di gestire dallo stesso sistema di supervisione altri edifici sparsi sul territorio e qui la domanda, quale sistema potrei usare al posto di KNX per limitare un pò i costi?

con KNX avrei bisogno minimo di, alimentatore, router ETH e attuatore per attivare la caldaia con un costo per sede 600/700 €

considerate che con OpenHAB ci sono diversi "binding" per diversi protocolli, ad es. z-wave, modbus, knx ecc

Un idea che mi frulla per la testa è quella di utilizzare un SNMP Ethernet Controller c'è qualcuno che ha esperienza in questo campo?

Grazie 1000

Andrea

[del_user_56966]

Detto questo, ora mi viene chiesto di gestire dallo stesso sistema di supervisione altri edifici sparsi sul territorio e qui la domanda, quale sistema potrei usare al posto di KNX per limitare un pò i costi?

Dipende principalmente dal sistema di supervisione e dalla sicurezza che questo debba garantire!

Modificato: 25 novembre 2013 da Aleandro2008

[Bacaezio]

Ciao Aleandro 2008,

il sistema di supervisione è OpenHAB (http://www.openhab.org), per sicurezza cosa inendi? Le sedi remote verranno connesse via VPN al sede centrale e il sistema di supervisione prevede l'utilizzo di canale criptato (https) e accesso tramite user e password.

Grazie

ciao

Andrea

[smoothhands]

Ciao Bacaezio,

avevo notato anch'io il sistema OpenHAB e, per quanto mi riguarda, stavo cercando di realizzare tempo fa

un binding per HomePLC.

Potresti utilizzare HomePLC.Linux per interfacciarti con il sistema domotico e dato che è programmabile

direttamente in Java non avresti grossi problemi dovuti alla gestione di librerie in codice nativo.

Il traffico avverrebbe tramite rete ethernet.

Certo è che un device HomePLC.Linux, visto il costo, dedicato solo come interfaccia tra il sisema hardware

e openHAB è un pò sprecato ed è per questo che a un certo punto ho pensato di installare direttamente

openHAB all'interno dell'HomePLC.Linux.

A questo punto le cose sembravano andare abbastanza bene tranne che openHAB richiede molto spazio

dovuto all'implementazione Equinox (OSGi) che si porta dietro un bel numero di bundles.

Allora ho provato a ricreare un miniOpenHAB basato su Felix (Apache) che ha un footprint

più ridotto e che non avrebbe riempito lo spazio su HomePLC.Linux.

Purtroppo tutto il pacchetto Equinox serve anche per gestire il meccanismo della definizione

degli Items, Sitemap e della relativa generazione automatica del codice che con Felix

non è possibile utilizzare.

Poi avevo altro da fare e allora ho abbandonato per un pò la cosa.

In definitiva interfacciare openHAB a HomePLC, secondo me è fattibilissimo e avresti

un sistema domotico di tutto rispetto.

Il problema è che usando openHAB come cuore dei vari sistemi non avresti bisogno

di tutta la potenza (e del costo) del modulo HomePLC.Linux ma ti basterebbe

un'interfaccia che riceve le attuazioni e trasmette gli eventi a openHAB.

Non so quanto possa funzionare bene ma un'idea porebbe essere un

RaspBerry Pi (al posto di HomePLC.Linux) con interfaccia RS485 verso

sistema HomePLC e utilizzare modbus con suoi devices + un bel sistemino

Java adHoc da interfacciare su rete ethernet con openHAB.

[Andrea Ghensi]

Ciao smoothhands, immagino tu sia il Danilo che ha scritto sul gruppo di openHAB in merito a homeplc...

l'idea di installare openHAB direttamente su homeplc linux è fantastica... ma quali sono le specifiche di hplc.linux che non riesci a farci stare l'applicativo così com'è? giusto per farmi un'idea di quanto ci si possa "giocare". parli anche di "costo" non giustificato, volevo capire se il sovrapprezzo rispetto al homeplc standard sia maggiore di un raspberry o altro sistema embedded (per ora ho un olinuxino, usa un ARM A7 e ha microSD, SD e connettore SATA ) interfacciato via modbus/RS485... Ovvio che rasPI e le altre devboard non sono così affidabili come può essere un sistema studiato per essere operativo 24/7 (tant'è che sul sito dell'olinuxino è espressamente scritto che se usi il sistema per applicazioni finali sono tutti cavoli tuoi...)

[del_user_56966]

Ovvio che rasPI e le altre devboard non sono così affidabili come può essere un sistema studiato per essere operativo 24/7

analizzato cosi non rende bene il concetto, un normale embedded non è paragonabile 1:1 con un HomePLC.Linux....

sul primo devi crearti uno strato di comunicazione col Bus tramite una seriale

nel caso delle seriali i dati acquisibili sono molto limitati e lenti...

ci sono degli esempi lampanti di Controller professionali sul mercato che dopo la potenza del processore a monte...

lasciano decisamente desiderare sul Bus a valle...

un HomePLC non utilizza la normale comunicazione ne richiede uno strato di drive e di comunicazione...

ma ha un processore di comunicazione dedicato... sono quindi due apparati in uno CPU Linux + CPU Domotica

il programmatore non deve inventarsi nulla, legge e scrive la Domotica come se fosse una periferica del Kernal di Linux...

inoltre l'orologio di un embedded normalmente ha un errore di qualche minuto mese.. quello di HomePLC è di qualche minuto/anno...

quindi nell'uso standalone i due dispositivi hanno precisioni completamente differenti...

[smoothhands]

Ciao Andrea,

ma quali sono le specifiche di hplc.linux che non riesci a farci stare l'applicativo così com'è?

il modello di HomPLC.Linux che ho ordinato contiene un Freescale i.Core M53 con una CPU Cortex A8 a 1GHz.

E' un modello con 1GB di memoria ma che contiene 256MB di NAND flash sulla quale è installato il sistema.

Anche eliminando completamente uno dei sistemi demo preinstallati, dopo aver aggiornato il jdk, mi rimangono

circa 90MB di spazio libero.

A questo punto installare il runtime di openHAB più la totalità degli addon richiede 92MB di spazio.

E' vero che non serviranno tutti gli addon ma comunque si arriva un pezzo in la.

un HomePLC non utilizza la normale comunicazione ne richiede uno strato di drive e di comunicazione...

ma ha un processore di comunicazione dedicato... sono quindi due apparati in uno CPU Linux + CPU Domotica

il programmatore non deve inventarsi nulla, legge e scrive la Domotica come se fosse una periferica del Kernal di Linux...

Come ha scritto Aleandro vieni sollevato dal compito di realizzare tutto lo stack di comunicazione sul bus

e con le librerie di sistema fornite a corredo è sufficiente accedere direttamente all'area di memoria

sulla quale il sistema domotico tiene aggiornata una immagine dello stato del sistema: ne più ne meno

come un sistema PLC classico.

Questo ovviamente semplifica molto le cose anche se la libreria di interfaccia con java mi ha inizialmente

creato qualche difficoltà dovuta alla gestione java dei package.

volevo capire se il sovrapprezzo rispetto al homeplc standard sia maggiore di un raspberry...

Ci vado corto... di listino un HomePLC.Linux come il mio costa 10 volte un raspberry.

Questo però è il valore di listino quindi devi considerare la scontistica che ti viene

applicata e, pre questo, devi far riferimento direttamente alla netbuilding.

Modificato: 2 marzo 2014 da smoothhands

[del_user_56966]

E' un modello con 1GB di memoria ma che contiene 256MB di NAND flash

oltre a quella standard da 256....dovrebbero esserci anche versioni con 512 Megabyte e 1Gbyte di memoria?

[smoothhands]

Dimenticavo,

l'HomePLC.Linux ha anche la possibilità di espandere la memoria

con una microsd. Verrebbe utilizzata per lo storage di logs e dati

di una eventuale applicazione di domotica installata.

Voglio provare a vedere se si riesce a far montare parte della sd

per espandere la memoria di sistema a boot.

Non sono proprio ferratissimo ma non dovrei far danni.

Non è proprio una Debian standard ma è pur sempre un

embedded Linux con Busybox.

Ciao Aleandro,

io in effetti avevo ordinato quella con 1GB di memoria ma con il comando top me ne mostra

sempre 256MB.

Penso sia dovuto all'immagine di sistema preinstallato che non è proprio il suo.

Poi non vorrei che la ram sia una cosa e la memoria flash su cui sia installato

il sistema linux sia un'altra.

Modificato: 2 marzo 2014 da smoothhands

[del_user_56966]

Poi non vorrei che la ram sia una cosa e la memoria flash su cui sia installato

il sistema linux sia un'altra.

infatti pensavo proprio a qualcosa del genere, caricare il programma tramite sd card o USB sulla memoria,

senza doverlo tenere necessariamente in quella di sistema...

[del_user_56966]

Ci vado corto... di listino un HomePLC.Linux come il mio costa 10 volte un raspberry.

sarei curioso di capire... cosa ne pensi se al posto di un processore con la Debian Standard...

che mi pare sia una parte consistente del costo...

si potesse collegare al processore lato Domotica HomePLC un Raspberry oppure un Arduino...

[Andrea Ghensi]

il modello di HomPLC.Linux che ho ordinato contiene un Freescale i.Core M53 con una CPU Cortex A8 a 1GHz.

E' un modello con 1GB di memoria ma che contiene 256MB di NAND flash sulla quale è installato il sistema.

azz 256MB sono pochini effettivamente...

io in effetti avevo ordinato quella con 1GB di memoria ma con il comando top me ne mostra

sempre 256MB.

...

Poi non vorrei che la ram sia una cosa e la memoria flash su cui sia installato

il sistema linux sia un'altra.

Decisamente sì, RAM e NAND flash sono due cose separate.

Con il comando top vedi la memoria RAM, non la NAND.

piuttosto cosa ti dice il comando df? fdisk -l? e cosa c'è in /etc/fstab? forse la NAND è effettivamente da 1GB ma è stata partizionata per separare il sistema di base da eventuali aggiunte... nessun manuale a corredo?

l'HomePLC.Linux ha anche la possibilità di espandere la memoria
con una microsd. Verrebbe utilizzata per lo storage di logs e dati
di una eventuale applicazione di domotica installata.

Voglio provare a vedere se si riesce a far montare parte della sd
per espandere la memoria di sistema a boot.
Non sono proprio ferratissimo ma non dovrei far danni.
Non è proprio una Debian standard ma è pur sempre un
embedded Linux con Busybox.

ah, beh, se c'è uno slot microsd siamo a posto, nulla ci vieta di aggiungere una riga al /etc/fstab per montare al boot una partizione (magari in sola lettura) dalla scheda sd e piazzarci lì i programmi.

Certo non sarà reattivo come metterlo direttamente sulla NAND, ma è sicuramente meglio di un sistema embedded separato.

In alternativa stavo cercando qualche altro programma opensource per la home automation, ne ho trovati un bel po' tra cui l'italiano freedomotic (che se non ho capito male hanno sviluppato proprio all'università di Trento, praticamente nell'aula di fianco alla mia ), ora vediamo di scremare la lista alla ricerca del "migliore" in quanto a risorse richieste e funzionalità disponibili.

[smoothhands]

cosa ne pensi se al posto di un processore con la Debian Standard...

si potesse collegare al processore lato Domotica HomePLC un Raspberry oppure un Arduino...

Il fatto è che nell'HomePLC.Linux non ho a disposizione una Debian standard.

E' una versione ridotta e adattata alla scheda utilizzata a fianco del processore domotico.

In particolare realizzata dalla Evidence se non sbaglio.

Se esistesse un dispositivo con solo il processore domotico a bordo io non sarei che contento.

Ovvio che poi rimane il problema di trovare un modo performante per interfacciare

il processore domotico con il resto del mondo. E come dicevi in un post precedente una

porta seriale non è affatto performante.

[smoothhands]

piuttosto cosa ti dice il comando df? fdisk -l? e cosa c'è in /etc/fstab?

Allora...

il comando df secco restituisce

df: cannot read table of mounted file systems: No such file or directory

il comando df / restituisce

df: Warning: cannot read table of mounted file systems: No such file or directory
Filesystem           1K-blocks      Used Available Use% Mounted on
-                       253952    162104     91848  64% /

il comando fdisk -l restituisce... nulla!!!

il comando cat /etc/fstab restituisce

none            /dev/pts        devpts  gid=5,mode=620
tmpfs           /dev/shm        tmpfs      defaults        0 0
tmpfs           /tmp        tmpfs   defaults        0 0

nessun manuale a corredo?

Il manuale c'è ma a parte qualche informazione di base il resto è tutto orientato al sistema HomePLC e quindi

aree di memoria e descrizione dei dispositivi che possono essere inseriti su bus RS485.

Poi mi è stata inviata una chiavetta con una macchina virtuale vmware contenente un sistema ubuntu

con eclipse preinstallato... dovrebbe servire da cross compilazione per realizzare sistemi per l'HomePLC.Linux.

Probabilmente anche per preparare un nuovo O.S. da sbatterci sopra. Ma non ho approfondito... dovrei chiedere

in assistenza ma non ho mai tentato.

Per quanto riguarda la ram mi è stato assicurato che il dispositivo contiene 1GB ma per qualche ragione

non se ne vedono più di 256MB.

La cosa che mi ha insospettito è che nella famosa penna usb (con scritto da restituire... tra l'altro ... e che ho

restituito ) ci sono dei documenti relativi ad un altro tipo di prodotto... ovvero quello più piccolo

Mah... funzionava tutto abbastanza bene e allora non ho approfondito lasciando a tempi più maturi eventuali

aggiornamenti.

[smoothhands]

Nella chiavetta che mi è stata inviata, assieme all'immagine di una macchina ubuntu, ci sono

anche due manuali:

- Evelin BSP che è il manuale del sistema linux installato

che mostra come flashare un nuovo sistema sul device

e parla di u-boot e un pò di configurazioni.

- Evelin SDK che è dedicato all'ambiente di sviluppo con eclipse

Modificato: 2 marzo 2014 da smoothhands

[Andrea Ghensi]

effettivamente cercando in internet l'i.Core M53 salta fuori il SOM della Engicam s.r.l., che ha 256MB di NAND flash e 1GB di RAM, quindi non ci si scappa (ancora non capisco perché ti trova solo 256MB di RAM ).

mi sembra strano anche che df e fdisk non diano nulla in output, a meno che il sistema dalla flash venga copiato tutto in ram durante il boot. In realtà non ho mai lavorato con nane flash quindi non ho la certezza di quello che sto dicendo.

forse il comando "mount" potrebbe illustrarci meglio la situazione (soprattutto dove legge il rootfs!)

Evelin BSP che è il manuale del sistema linux installato

che mostra come flashare un nuovo sistema sul device

e parla di u-boot e un pò di configurazioni.

con u-boot si dovrebbe riuscire a far partire il sistema direttamente da scheda sd (come ultima spiaggia!)

[smoothhands]

forse il comando "mount" potrebbe illustrarci meglio la situazione (soprattutto dove legge il rootfs!)

/ # mount
rootfs on / type rootfs (rw)
/dev/root on / type jffs2 (rw,relatime)
none on /proc type proc (rw,relatime)
none on /sys type sysfs (rw,relatime)
none on /dev type ramfs (rw,relatime)
none on /dev/pts type devpts (rw,relatime,gid=5,mode=620)
tmpfs on /dev/shm type tmpfs (rw,relatime)
tmpfs on /tmp type tmpfs (rw,relatime)

[smoothhands]

Piccolo aggiornamento... sul manuale Evidence-BSP si può trovare

On the NAND of the board, binaries are located at the following addresses:
Address   Size      Content
0x0000000 0x00FFFFF u-boot.bin
0x0100000 0x02FFFFF uImage
0x0400000 0xFC00000 filesystem.jffs2

che quarda un pò se si trasformano in decimale otteniamo 256... che è la dimensione della nand flash.

[del_user_56966]

In particolare realizzata dalla Evidence se non sbaglio.

so che alcuni hanno frequentato i corsi per potersi ricompilare il sistema operativo... e che esistano

degli aggiornamenti rispetto alla versione preinstallata... volendo c'è la possibilità di montarsi e smontarsi il kernal come meglio si crede..

certo con le giuste conoscenze... e penso che serva anche un motivo che non la sola passione

personalmente al momento non ho approfondito....

Se esistesse un dispositivo con solo il processore domotico a bordo io non sarei che contento.

Ovvio che poi rimane il problema di trovare un modo performante per interfacciare

il processore domotico con il resto del mondo.

infatti chiedevo come vedresti un un Raspberry oppure un Arduino... al posto del processore Linux attuale...

ha un senso dare a questi dispositivi un sistema di I/O potente come quello HomePLC??...

[smoothhands]

so che alcuni hanno frequentato i corsi per potersi ricompilare il sistema operativo...

Sono corsi della NET?

e che esistano degli aggiornamenti rispetto alla versione preinstallata...

Sul filemanager ci sono immagini per il processore a 1GHz ma non ho

mai avuto il coraggio di flashare

tra l'altro la porta seriale ce l'ho solo in un vecchio pc fisso a casa di mio

padre

infatti chiedevo come vedresti un un Raspberry oppure un Arduino... al posto del processore Linux attuale...

ha un senso dare a questi dispositivi un sistema di I/O potente come quello HomePLC??

Beh... come sempre a livello hobbistico un tentativo non lo butterei via affatto.

Non so se l'Arduino avrebbe senso perchè esistono già schede di espansione dedicate

che forniscono relè, ingressi e sensori vari.

Quindi, se usato in questo modo, a parte il vantaggio di una programmazione diversa

rispetto al ladder, lo vedo come un sistema ridondato rispetto al bus RS485 e

i vari moduli collegati ad esso.

Diverso se venisse utilizzato come ponte tra il processore domotico è un'interfaccia web.

In questo modo potrei leggere e scrivere nei registri HomePLC tramite

comandi del protocollo http.

Si tratterebbe di un rude Gateway http-homeplc.

Il RaspberryPI ha il vantaggio di avere installato un sistema linux più standard

e completo che ti da la libertà di installare pacchetti software direttamente con

apt-get dai repository senza necessità di generare da zero un nuovo file system.

Poi però, per avere prestazione decenti, dovresti collegare il processore domotico

con una scheda di espansione al RPI e quindi risulterebbe tutto un pò delicato.

Qui sul forum si è sempre elogiato l'utilizzo di logiche ladder per la loro immediatezza

e velocità di realizzazione... anche di logiche complesse.

Però in questo modo si perde una parte di mercato di persone con una formazione

più informatica e quindi più abituate a linguaggi di alto livello.

L'HomePLC.Linux è una meraviglia da questo punto di vista però, per chi non

appartiene al circuito giusto, è un po off-limits perchè è difficile accedere alla

documentazione dettagliata come anche questo thread, un pò, dimostra.

Modificato: 2 marzo 2014 da smoothhands

[del_user_56966]

Sono corsi della NET?

no non sono corsi Net...

Non so se l'Arduino avrebbe senso perchè esistono già schede di espansione dedicate

che forniscono relè, ingressi e sensori vari.

si ma quelli non hanno caratteristiche utili per la distribuzione l'impiantistica reale...

ti ricordo che la norma europea riguardo la domotica esclude i sistemi con cablaggio centralizzato...

Qui sul forum si è sempre elogiato l'utilizzo di logiche ladder per la loro immediatezza

e velocità di realizzazione... anche di logiche complesse.

Però in questo modo si perde una parte di mercato di persone con una formazione

più informatica e quindi più abituate a linguaggi di alto livello.

per le esperienze che mi sono capitate, la programmazione strutturata non è molto utilizzata in campo.. neppure io riesco a programmare

cose complesse col cliente che mi bisbiglia nell'orecchio...

al contrario il Ladder e i Functional Block hanno sicuramente il vantaggio di un degug grafico che ti permette di lavorare...

anche in ambiente altamente disturbato come uno stabilimento o un cantiere dove...

insieme a te ci sono muratori, idraulici, e spesso anche il cliente...

questo sommato al fatto che il saper programmare da solo non basta per fare domotica... ma si deve avere anche una forte esperienza impiantistica...

da come risultato che tra il pubblico che adopera il LadderHome conosco anche molti degli sviluppatori a cui accenni tu... che ritengono che in campo sia più semplice svolgere

i compiti di base con le librerie del LadderHome più che programmando ad alto livello...

mentre per applicazioni e programmi specifici con gestione del web server, sicurezza, gestionali accessi ecc.. è sicuramente preferibile quello con Linux...

L'HomePLC.Linux è una meraviglia da questo punto di vista però, per chi non

appartiene al circuito giusto, è un po off-limits perchè è difficile accedere alla

documentazione dettagliata come anche questo thread, un pò, dimostra.

in effetti quel prodotto secondo me non è stato concepito per i clienti finali ma solo per aziende che sviluppano applicazioni mirate...

l'assistenza lato Domotica è la stessa della versione Ladder... quella lato Kernal specialmente se si vogliono fare modifiche..

necessita di un livello più elevato di quella fornita di base...

come ti accennavo prima se volessi farmi la mia centrale Domotica personale come minimo dovrei farmi un corso sul Kernal...

e poi mettere in piedi una mia compilazione dedicata... ma al momento non ho di queste esigenze

tanto meno adesso che è stato annunciata l'uscita del nuovo HomePLC che è fino a 40 volte più potente dell'attuale....

Modificato: 3 marzo 2014 da Aleandro2008

[smoothhands]

come ti accennavo prima se volessi farmi la mia centrale Domotica personale come minimo dovrei farmi un corso sul Kernal...

Se mi interessasse proprio questo con chi potrei sentire?

è stato annunciata l'uscita del nuovo HomePLC che è fino a 40 volte più potente dell'attuale....

...e che fa? vola?

Modificato: 3 marzo 2014 da smoothhands

[del_user_56966]

Se mi interessasse proprio questo con chi potrei sentire?

per le istruzioni su come procedere sempre la net, poi ti danno i riferimenti di chi contattare...

.e che fa? vola?

ti meraviglieresti?

il primo droide volante/spia, per capirci quelli che adesso trovi al negozio... aveva a bordo parte della tecnologia che c'è in HomePLC...

quindi dire che vola non è affatto sbagliato....

[Andrea Ghensi]

Scusate l'ignoranza, ma che ve ne fareste di ricompilare il kernel? quello fornito da Evelin BSP (leggendo i manuali disponibili online) è già fatto su misura per il i.Core, quindi il lavoro principale per personalizzare il sistema va fatto lato rootfs (tra l'altro farebbe tutto il configuratore presente nella virtual machine, e c'è una cartella apposita per aggiungere i programmi voluti).

Chiaro che se ci si vuole fare una cultura di linux o si ha intenzione di aggiungere driver particolari per chissà quale funzione allora un corso sul kernel potrebbe essere decisamente utile

riguardo al discorso di utilizzare un altro embedded al posto dell'i.Core, non penso che cambi molto, o meglio: mentre l'i.Core si innesta direttamente in un connettore del PLC, e quindi è stato dotato di connessione diretta ai registri di memoria (se deduco bene da quello che mi avete spiegato in questa discussione), il raspberry o altri sistemi embedded che non siano "system on module" hanno già le porte per le connessioni alle periferiche integrate, quindi bisognerebbe sfruttare quelle per tentare di collegarsi agli stessi registri di memoria... un lavoraccio per nulla piuttosto vedrei bene la possibilità di utilizzare un system-on-module con qualche giga di memoria NAND in modo da farci stare su un sistema con i controfiocchi.

Ah, sul sito di evidence c'è scritto che Evelin utilizza il sistema apt-get per la gestione dei suoi pacchetti (usando un repository specifico per questa macchina), e che viene fornita con le utility di base di Debian (in alternativa a busybox per sistemi che non hanno problemi di spazio/memoria), quindi avrà i suoi limiti ma è pur sempre debian based

[del_user_56966]

Chiaro che se ci si vuole fare una cultura di linux o si ha intenzione di aggiungere driver particolari per chissà quale funzione allora un corso sul kernel potrebbe essere decisamente utile

conosci qualche utente linux che si accontenta della compilazione originale...

piuttosto vedrei bene la possibilità di utilizzare un system-on-module con qualche giga di memoria NAND in modo da farci stare su un sistema con i controfiocchi.

in effetti dice che possa essere potenziato con un quad core... ma secondo me il processore attuale (quello da 1 GHz)

va più che bene per questo tipo di applicazioni... quello che serve semmai è un programma che ne sfrutti le caratteristiche...

magari basato sul C++ e le QT di nokia...

e una buona interfaccia Web.... basata su PHP... tutte funzioni già disponibili su questa compilazione...

un maggiore potenza potrebbe essere utile se si usa la VM di java...