pannello operatore in php

[matteo_pirazzi]

Buona sea a tutti e complimenti al sito e al forum perchè mi avete tenuto compagnia in questi 3 anni di sviluppo del progetto che sto implementando nell'azienda per cui lavoro (ovviamente a babbo morto)

non sto a tediarvi su tutto il progetto perchè è decisamente complesso descrivere tutte le funzionalità, e per poterle sviluppare voi mi avete dato una gran mano leggendo il forum e cercando le risposte ai dubbi che mano mano crescevano.
Ora il problema è che sebbene abbia cercato per ore non trovo nulla che fa al caso mio.
Il problema è che ho una raspberry (in realta sono piu di 50) che uso per pilotare un display 4" per visualizzare delle informazioni sulle postazioni operatore. Dato che il raspi monta linux con mysql, pensavo di visualizzare le info che mi arrivavano tramite TCP e memorizzate in una db locale con una pagina php che si resfresha ogni 3 secondi (dato che non so quando e quante info mi potrebbero arrivare).

Tutto ok, solo che ho paura di bruciare la SD (che ha circa 1.000.000 di scritture come lifetime) entro breve. Per cui cercavo un concetto da seguire per visualizzare le info senza troppe scritture/letture sulla SD. pensavo di sviluppare una GUI con php ma le info che trovo in giro non sono soddisfacenti e volevo sentire il vostro parere.

Scusatemi infine se sono stato prolisso, se ho infranto qualche regola del forum e se ho annoiato qualcuno.

grazie ancora del supporto, buona continuazione a tutti
matteo

[Santino83_02]

non ho capito che c'entrano le sd dei raspi con il problema della scrittura: da come hai esposto, i raspi sono fonti dati che vanno a scrivere su un server centralizzato, mica internamente.

pure se fose una sd che riceve le info, la connessione tcp non scrive su hard disk ma ha tutto in ram finchè i dati che leggi dal socket tcp non li vada a persistere in qualche modo (db? files? dove ti pare) allora si che scrivi su sd

e cmq tutto si rompe e tutto si ricompra, le sd hanno tanti pregi e qualche difetto, farai un prodotto che tendenzialmente dura "x" giorni/mesi/anni prima di dover sostituire l'hard disk (sempre che non si rompa l'sd prima di esaurire il suo ciclo di vita o crashi l'os o si bruci il trasformatore o qualcuno faccia cadere a terra il raspi etc... )

[matteo_pirazzi]

ciao Santino
Mannaggia come siete veloci!!
... mi sono spiegato male..
In realtà è il contrario, i raspi sono i server in ascolto dal pc centrale che invia i messaggi da visualizzare.
I messaggi vengono inviati tramite TCP (funzioni socket_accept, socket_bind etc etc etc). Ma dato che presuppongo che ci sia un notevole traffico e non è via lan ma via wireless devo limitare al limite i dati che viaggiano , quindi trasferisco solo pochi dati ai raspi.
La parte mancante se la prendono i raspi e la storano in un DB.
Quindi nei raspi c'è il programma server che sta in ascolto e popola un DB e una pagina web (scritta in php e html ) che refresha ogni 3 secondi che prende le info dal DB e le visualizza.
Daccordo che tutto si cambia se si rompe, non è questo il punto, è che mi sembra non molto elegante far girare una pagina web che ogni 3 secondi fa una query a un DB locale per tutto il giorno.
Daccordo anche che il raspi deve fare solo quello... però un pochino mi dispiace per loro che ogni giorno devono fare 20 query al minuto, 1200 all'ora , 12000 al giorno etc etc etc.

Inoltre il pc centrale che raccoglie le info dagli operatori, deve essere molto "skilled" perchè ogni giorno raccoglie circa 4000 letture al giorno dagli operatori (tramite barcode bluethoot) e anche lui deve essere abbastanza scarico per storare le letture nel suo DB locale e inviare le info da visualizzare ai raspi.

Infine abbiamo un altro Pc che funge da gestore che visualizza tutte le info raccolte e le rende disponibile al responsabile di produzione.

Detto cosi sembra piuttosto complicato, ma ti assicuro che è molto peggio...

grazie per la super super super veloce risposta, mi hai lasciato basito...

[Santino83_02]

ciao...

si è che ora non ho nulla da fare e "leggevo" su internet qualcosa, e il forum è il mio luogo di lettura preferito....

Ora, non sono un esperto di hard disk, ma il ciclo di vita è "in scrittura" non "in lettura", e leggere valori da un db è lettura e non dovrebbe causare scritture su disco (non so se tecniche di lock possano incidere sulla cosa però).

comunque è un pò complicato risponderti, non ho ben chiaro il quadro e non lo capisco molto da come lo spieghi. Ad esempio non capisco perchè ti preoccupi della banda di tramissione in wirless ( oh, ma quanti MB di roba vuoi spostare "in continuazione" tra il pc centrale e i raspi??), non capisco come sia possibile che una parte di questi dati i raspi li riceva da remoto e una parte "se li crei da solo" (che fanno, hanno la palla magica?Se li creano i raspi vuol dire che il raspi agisce da fonte di eventi e questi devono essere mandati a qualcun altro per farli conoscere al mondo intero). Poi insomma, 4000 letture al giorno "dagli operatori" sono una bazzecola, anche se fossero "per operatore" ( a meno di non avere decine e decine di operatori). Detto questo, dovresti cambiare abbastanza strategia:

Intanto il software installato su Raspi dovrebbe connettersi via socket al server centrale e instaurare un canale su cui ascolta e invia messaggi. Il client web montato su raspi dovrebbe connettersi via websocket a tale sottostrato software e mostrare a video, in maniera "live", i messaggi di interesse ricevuti. o strato software del raspi deve essere anche capace di gestire una modalità online ed una offline se ho ben capito. Verrà salvato in locale lo stretto necessario, tutto il resto deve essere letto dal server centrale (da socket/ws/quello che te pare) e mantenuto "live" o persistito solo su necessità.

insomma, qualcosa di molto più "live" e meno "refresh ogni tot secondi"

infine, non userei php per fare questo neanche se mi obbligassero. Probabilmente Java ME visto che usi un raspi. Delegando se ce ne sia bisogno il php giusto a fare da "frontend" per il backend scritto in java

[matteo_pirazzi]

ECCO!!!:
"Intanto il software installato su Raspi dovrebbe connettersi via socket al server centrale e instaurare un canale su cui ascolta e invia messaggi. Il client web montato su raspi dovrebbe connettersi via websocket a tale sottostrato software e mostrare a video, in maniera "live", i messaggi di interesse ricevuti. o strato software del raspi deve essere anche capace di gestire una modalità online ed una offline se ho ben capito. Verrà salvato in locale lo stretto necessario, tutto il resto deve essere letto dal server centrale (da socket/ws/quello che te pare) e mantenuto "live" o persistito solo su necessità."
Vabbe diciamo che alle 0.00 sono abbastanza fuso e le mie spiegazioni hanno un qualcosa di magico
diciamo anche che tutta la struttura andrebbe rivista perchè sicuramente è molto ottimizzabile essendo un progretto in continua evoluzione e questo non mi preoccupa un granche. Cmq proprio quello che hai scritto potrebbe essere la soluzione al mio dilemma.
Ovvero il raspi dovrebbe avere un sottostrato che comunica con Pc centrale per scambio dati (adesso è in php e funzia discretamente) . Ma non ho idea come far connettere il client web sul raspi tramite websocket a tale sottostrato software e mostrare a video, in maniera "live", i messaggi di interesse ricevuti.

Ora ti lascio, sono stanco morto,..riprendiamo domani sera se ci sei.,, se non ci sei cmq grazie ancora... sei stato illuminante.
buona notte
matteo

[Santino83_02]

Andiamo OT probabilmente, ma sarà il moderatore al limite a dirci se andare in pvt o continuare. cmq accenniamo una ipotesi:

su raspi gira un processo, che definiremo un pò impropriamente "server" o meglio "server locale", che una volta lanciato prende e instaura una connessione col server remoto e si preoccupa a) di mantenerla attiva b) di ascoltare i messaggi in arrivo c) di inviare messaggi in uscita . Tale server locale apre un socket in ascolto su 127.0.0.1:PORTA e attende che qualche client ci si connetta. Da locale(ovvero dal raspi), apri un browser e ti connetti via websocket a 127.0.0.1:PORTA e inizi a dialogare con il server locale, il quale userà tale socket per girarti messaggi o per permetterti a te di inviarne di tuoi da client web. Possiamo dividere i messaggi in varie tipologie: comandi sincroni, comandi asincroni, eventi. il server locale è altresi il processo che avrà il compito di a) decidere cosa persistere in locale, b) decidere cosa mandare al client connesso alla 127.0.0.1:PORTA, c) decidere se accettare 1 o piu client su tale porta e quindi magari invece di essere in ascolto solo su 127.0.0.1 aprirsi a tutta la rete, d) gestione sicurezza/acl/riconoscimento utente/interazioni varie con altri sistema software... insomma, il cuore di tutto sarà lui mentre tutto il resto servirà solo da "interfaccia" verso di questo server locale.

insomma, detto così alla carlona è tutto facile, andarlo ad implementare è tutta un'altra storia.

Per questo scartavo PHP come linguaggio: anche se è vero che "php fà tutto", è anche vero che la strada che ha preso il linguaggio lo porta ad essere selettivo nei compiti che può svolgere, a meno di non fare affidamento su "tanto codice scritto a mano" e non affidarsi invece a frameworks o linguaggi che rispondono in maniera più solida alle esigenze riscontrate.

Che te lo sto a dire a fare: java, su multithreading e comunicazioni via socket, offre tools e frameworks inesistenti in php, che consentono terribilmente tanto al programmatore di concentrarsi non su "come faccio a mandare un messaggio da A a B" ma su "che ce fa B co sto messaggio mo?".

Credo che anche roba tipo node.js offra molte soluzioni in merito (soprattutto lato websockets, con frameworks tipo socket.io/expressjs ), anche perchè lato client web il websockets lo apri con javascript mica con php (e allora usando il mondo nodejs hai una pletora di framework per fare applicazioni "live" lato client).

Con altri linguaggi non so, non ho esperienza in merito.

Per non parlare poi del protocollo di comunicazione che tutti sti oggetti adotteranno: custom? xmpp? soap ? soap+xmpp ? altri?

E avoja ancora, ho qui accanto 3 libri che parlano dell'argomento e sono solo un assaggio

Buonanotte


EDIT: ovviamente parlo pensando ad una riprogettazione partendo da 0. Nulla ti vieta di cominciare a modificare aspetti della tua applicazione senza dover ricominciare da 0. Es: facendo il refactory intanto del client web sul raspi per parlare con il php via websockets, ad esempio usando lato php librerie come http://socketo.me/ (a giudicare dalla documentazione, sembra una cosa molto interessante)

[.Kurt]

Daccordo che tutto si cambia se si rompe, non è questo il punto, è che mi sembra non molto elegante far girare una pagina web che ogni 3 secondi fa una query a un DB locale per tutto il giorno.

Non ti devi neanche preoccupare più di tanto. InnoDB di mysql, se configurato correttamente, mette in cache dati e indici, quindi dopo la prima query non vai neanche più a leggere direttamente dal disco, ma solo dalla ram. Ulteriori operazioni di aggiornamento/inserimento di quei dati vanno ad aggiornare direttamente la cache stessa, quindi vai veramente a leggere dal disco esattamente una volta, non di più. Questo forse non è neanche un problema che volevi considerare, ma, ehi, tutti noi vogliamo performance migliori, e questa è gratis.

Per quanto riguarda la questione dei limitati cicli di scrittura della scheda sd, c'è poco da fare: i limiti son quelli. Quello che può aiutarti, per quanto stupido il consiglio possa sembrare, è: scrivi meno dati possibili, e il meno spesso possibile. È difficile darti un suggerimento da applicare direttamente al tuo progetto senza prima conoscerlo, ma diciamo che i dati che ti arrivano (e che vuoi memorizzare) sono di un contatore, e che devi incrementare un campo nel db a seconda dei valori ricevuti. In tal caso scrivere direttamente sul disco, ogni volta, è uno spreco. Potresti invece trarre vantaggio da un database NoSql come MongoDB (in cambio di alcuni svantaggi :P), in modo che tutte le operazioni di scrittura sul disco vengano fatte tutte insieme dopo un tot. di tempo. Configurandolo adeguatamente puoi essere in grado di allungare la vita della scheda sd di parecchio. Lo svantaggio è che se si verifica un problema (e ci sono sempre) prima che tutti i dati possano venire scritti, quei dati sono persi. A meno che il server che li invia non li tenga in memoria finché non riceve un "OK" da parte del tuo raspberry, che indichi che i dati inviati sono stati correttamente scritti. Insomma, quello che voglio dire è che hai tante possibilità, e tante strategie che puoi adottare per ridurre le letture/scritture dalla scheda sd.

Ciò su cui Santino si sta concentrando è invece il vero problema che vale la pena affrontare: fare tante richieste per visualizzare/inserire/aggiornare qualcosa molto spesso (3s) è un discreto overhead, che se possibile dovresti eliminare/ridurre. Anche qui le tecniche per farlo si sprecano. Se vuoi suggerimenti o consigli più mirati dovresti descrivere il tuo progetto.

[matteo_pirazzi]

Buon giorno a tutti e un saluti a Kurt che si è unito alla discussione.

su raspi gira un processo, che definiremo un pò impropriamente "server" o meglio "server locale", che una volta lanciato prende e instaura una connessione col server remoto e si preoccupa a) di mantenerla attiva b) di ascoltare i messaggi in arrivo c) di inviare messaggi in uscita .

Questo è gia ok. Il raspi è in ascolto sulla porta 50005 dove riceve i messaggi da visualizzare dal PC centrale al quale risponde ok se è tutto ok .Il mio problema è solo visualizzare in formato grafico tali messaggi sul display dello stesso raspi.

Da locale(ovvero dal raspi), apri un browser e ti connetti via websocket a 127.0.0.1:PORTA e inizi a dialogare con il server locale, il quale userà tale socket per girarti messaggi o per permetterti a te di inviarne di tuoi da client web.

Ok daccordo è proprio questa parte che devo sviluppare e che girando sui vari forum no riesco a abbozzare.

Per Kurt: ti spiego a grandi linee di come funziona l'intero progetto partendo dalla periferia fino al cuore centrale del sistema:
1) Gli operatori di produzione hanno un lettore barcode bluethoot ognuno e ogni volta che iniziano una fase di lavorazione del processo leggono un codice a barre creato ogni volta ad-hoc per l'articolo che devono produrre e la fase di lavoro che devono eseguire . La lettura viene cosi inviata a un PC (TEMPI) che memorizza i dati in un DB locale.
2) il Pc TEMPI appena riceve una lettura invia questi dati al pannello operatore (raspi) in modo da far vedere all'operatore i dati del prodotto e i tempi di produzione massimi.
3) il PC TEMPI inoltre invia questi dati a un altro PC (WEB) per la gestione della produzione. Questo si rende necessario perchè l'hardware a disposizione per il PC TEMPI è molto scarno e ho visto che se devo elaborare qualcosa durante la giornata c'è il rischio di perdere qualche lettura.
Tutto funziona da circa 2 anni e abbiamo oggi un PC tempi con un db di letture di 70000righe ed è ancora bello sveglio e credo perchè fa solo quello, cioè memorizzare i dati che riceve dai barcode e basta. Per cui meno lo sfrutto meglio è per la reattività del sistema. Non credo sia un grosso problema se gli faccio mandare dei dati via TCP ai raspi ad ogni lettura ricevuta dai barcode , ma non deve essere una cosa troppo onerosa per l'hardware.Non ho idea di come potrebbero decadere le prestazioni da qui a 10 anni per cui cerco di tenerlo piu leggero possibile.

Spero sia chiaro, tenete presente che all'inizio i soldi per mettere in piedi il sistema erano = 0, per cui sono dovuto andare al risparmio. Il Pc TEMPI è un asus eeeepc , il PC WEB è sul mio pc virtualizzato (precision T5400) e una volta applicato anche la parte di visualizzazione verso gli operatori mi occuperò del refactoring e magari aggiorno hardware.

ciao e buona giornata a tutti
matteo

[Santino83_02]

Ok daccordo è proprio questa parte che devo sviluppare e che girando sui vari forum no riesco a abbozzare.

su questo rispondo, sul resto mi astengo un pò perchè continuo a non entrare nel vivo del quadro generale, un pò perchè non mi metto a fare l'analisi dell'intero sistema senza conoscere il sistema attuale e le problematiche, un pò perchè si va ot e ad un forumista php interesserebbe ben poco (ihmo).

io direi che se vuoi restare in ambito php per fare tutto, dovresti partire da qui http://socketo.me/ e seguire la guida per fare una chat. Insomma, il concetto è quello: si fà un server in ascolto su localhostorta e da browser ci si connette con un websocket a tale indirizzo. Cosa fanno poi i comandi etc è roba di tutti i giorni. Magari inizia a studiarti questa libreria, a fare qualche prova, segui la demo, schiarisciti le idee, abbozza qualcosa, e poi continuiamo su temi specifichi. Altrimenti fissiamo tutti una bella riunione di 8 ore in ufficio da te, e facciamo un bel 3 mesi di analisi e sviluppi vari sulla realtà della vostra azienda

[matteo_pirazzi]

dopo il tuo ultimo commento, dove hai citato i websocket , mi si è accesa una lampadina! e mi sono messo a studiarli da due giorni a casa alla sera ... in effetti potrebbero fare la caso mio. Adesso mi sto esercitando con un'applicazione server-client per la webchat come mi hai scritto tu e sembra promettente.
.. vi tengo aggiornati nello sviluppo, intanto grazie della collaborazione, è la prima volta che scrivo sul forum e devo dire che è stata un'esperienza piacevole e ultile.

saluti
matteo