Italian Come inviare comandi da pc a smartphone, via rete dati telefonica?

amorosik

Well-Known Member
Licensed User
Avrei necessita' di inviare dei comandi ad un'app che gira su smartphone, collegato a rete internet solo via connessione dati fornita dalla sim
I comandi vengono inviati da pc ufficio che dispone di connessione internet
Il principale obiettivo da raggiungere sono le prestazioni, intese come velocita' tra invio comando da postazione pc e visualizzazione dello stesso sullo smartphone
Sto provando con l'invio dei classici sms, ma le prestazioni non sono accettabili, nel senso che alcuni arrivano su telefono dopo qualche secondo dall'invio, altri dopo una decina di secondi, altri anche dopo qualche minuto, e questi sono tempi inaccettabili, da contenere all'interno di 1-2 secondi
Poi ho tentato col realizzare un mini tcp-server in ascolto sul telefono, in grado di elaborare icomandi ricevuti, ma ovviamente usando la rete dati telefonica e' impossibile arrivare da pc a smartphone in quanto 'nascosto' dalla struttura del gestore telefonico e quindi pur avendo l'indirizzo locale del telefono non si riesce a raggiungerlo da internet
Ho poi provato usando il servizio Pushover.net , installando un client apposito a bordo del telefono, ma anche con questo sistema i tempi di arrivo del messaggio non sono conformi alle prestazioni che mi prefiggo di ottenere, nel senso che alcuni arrivano dopo qualche secondo altri anche dopo qualche minuto
Quindi sms no, via socket tcp no, via notifica push no
Cosa resta?
Come fare per comunicare 'rapidamente' tra pc e smartphone (collegato a rete dati della sim)?
 

uniplan

Active Member
Licensed User
MQTT oppure il servizio di push di Google.
Il problema però a mio parere è a monte. Tu vuoi garanzia di affidabilità e di recapito istantaneo da servizi che per loro stessa natura non garantiscono il recapito istantaneo.
 

udg

Expert
Licensed User
Se Firebase messaging o MQTT risultano "inaffidabili" in merito ai tempi di consegna, direi che ti rimane solo il polling costante da parte dei device verso il server (sperando che non siano troppo numerosi e i piani Intenet siano flat).
In pratica, ogni x secondi (o minuti o altro), ciascun device interroga il server per scoprire se ci sono comani nuovi ed in caso affermativo li scarica e li esegue.
 

amorosik

Well-Known Member
Licensed User
Ringrazio per la risposta
Ma non e' che voglio garanzia di prestazioni da un servizio che non puo' garantirle
E' il contrario, vorrei individuare un servizio che possa garantire le prestazioni richieste
MQTT come funziona?
Se non sbaglio i due dispositivi quindi pc e smartphone, comunicano con un server intremedio, e' corretto?
E questo server intermedio me lo posso mettere in casa?
Dove posso trovare documentazione per addentrarmi, dal punto di vista B4X, nel mondo mqtt ?
 

amorosik

Well-Known Member
Licensed User
Se Firebase messaging o MQTT risultano "inaffidabili" in merito ai tempi di consegna, direi che ti rimane solo il polling costante da parte dei device verso il server (sperando che non siano troppo numerosi e i piani Intenet siano flat).
In pratica, ogni x secondi (o minuti o altro), ciascun device interroga il server per scoprire se ci sono comani nuovi ed in caso affermativo li scarica e li esegue.

Ho dato un'occhiata ai servizi Firebird Cloud Messaging
Nel video disponibile a questa pagina,


al 50', scrivono di un tempo max di 250ms per il 95% dei messaggi
Com'e' sta storia?
 

udg

Expert
Licensed User
MQTT: scarica un broker (es. mosquitto) ed installalo su un tuo server. Attenzione che richiede un certificato SSL (ok anche Let's Encrypt)
Il meccanismo è semplice. Fornitore e fruitore di messaggi si iscrivono allo stesso topic.

Firebase ha un vantaggio: i messaggi arrivano anche a device spento e certamente mentre è attiva una diversa app. In questo caso devi creare un sw B4J per inviare il messaggio al server di Google e poi quest'ultimo lo invia ai destinatari da te indicati
 

sirjo66

Well-Known Member
Licensed User
Puoi lavorare con il socket tcp, ma quando apri il canale di comunicazione deve essere lo smartphone che chiama il PC in ufficio e non viceversa, proprio per il problema che su rete 4G lo smartphone come dici tu è "nascosto".
Ovviamente il router del PC in ufficio deve essere correttamente configurato in modo da aprire la porta richiesta e reindirizzarla correttamente al PC voluto (ma è molto semplice da fare non preoccuparti).
In questo modo, quando dovesse cadere la comunicazione, sia lo smartphone sia il PC in ufficio se ne accorgono e riaprono subito il canale di comunicazione in modo da essere sempre online e quindi garantire una comunicazione veloce tra i due
 

LucaMs

Expert
Licensed User
MQTT: scarica un broker (es. mosquitto) ed installalo su un tuo server. Attenzione che richiede un certificato SSL (ok anche Let's Encrypt)
Il meccanismo è semplice. Fornitore e fruitore di messaggi si iscrivono allo stesso topic.

Firebase ha un vantaggio: i messaggi arrivano anche a device spento e certamente mentre è attiva una diversa app. In questo caso devi creare un sw B4J per inviare il messaggio al server di Google e poi quest'ultimo lo invia ai destinatari da te indicati
Con Firebase Cloud Messaging non è necessario creare un server b4j, anche l'app stessa può inviare messaggi FCM.
Quindi, un server non... serve, o meglio non è necessario mai, con FCM.

Che tu poi voglia inviarli tramite connessione dati... non cambia la cosa.
 

amorosik

Well-Known Member
Licensed User
Puoi lavorare con il socket tcp, ma quando apri il canale di comunicazione deve essere lo smartphone che chiama il PC in ufficio e non viceversa, proprio per il problema che su rete 4G lo smartphone come dici tu è "nascosto".
Ovviamente il router del PC in ufficio deve essere correttamente configurato in modo da aprire la porta richiesta e reindirizzarla correttamente al PC voluto (ma è molto semplice da fare non preoccuparti).
In questo modo, quando dovesse cadere la comunicazione, sia lo smartphone sia il PC in ufficio se ne accorgono e riaprono subito il canale di comunicazione in modo da essere sempre online e quindi garantire una comunicazione veloce tra i due


Intendi dire "...aprire un socket tcp e non chiuderlo fino a fine programma..." ???
Perche' normalmente si apre il canale di comunicazione, si spara/riceve, e si chiude
Se cosi' fosse, quando lo smartphone si accende e parte il programma, aprirebbe un socket e lo manterrebbe aperto solo allo scopo di poter ricevere comandi dal pc ufficio?
Eh si, probabilmente lato prestazioni sarebbe la cosa migliore perche' da pc a smartphone ci metterebbe un tempo brevissimo
Ma cosa accadrebbe se la comunicazione venisse interrotta, tipo inserimento in galleria che impedisce telefonate, oppure interferenze radio temporanee ?
Dopo un tot di tempo viene segnalata la cosa?
E poi bisogna riconnettere o si ricollega automaticamente?
Si, comunque sembra papabile l'ipotesi, non ho ancora ben idea da dove partire, ma sembra una buona idea
Se qualche anima buona volesse indicarmi qualche spunto di codice/documentazione per ottenere l'effetto sopra descritto, sarei veramente grato
 

LucaMs

Expert
Licensed User
Se qualche anima buona volesse indicarmi qualche spunto di codice/documentazione per ottenere l'effetto sopra descritto, sarei veramente grato
😇

Io farei come già scritto:

1) tentare di mantenere in vita servizio e app, come da esempio in "Background location tracking"
2) usare Firebase Cloud Messaging, sia sugli smartphone (che possono fare sia da client che da "server") che, eventualmente - se necessario, in un sw per PC (B4J).

Niente di complicato.

😇
 

amorosik

Well-Known Member
Licensed User
😇

Io farei come già scritto:

1) tentare di mantenere in vita servizio e app, come da esempio in "Background location tracking"
2) usare Firebase Cloud Messaging, sia sugli smartphone (che possono fare sia da client che da "server") che, eventualmente - se necessario, in un sw per PC (B4J).

Niente di complicato.

😇
Ahhh beh, se non e' niente di complicato allora mi fiondo a provare
Potendo non usare servizi esterni, in questo caso i Firebase Cloud Mesaging, preferirei
Ma visto che dell'ambiente non sono ancora esperto, allora seguo tuo consiglio e provo prima cogli fcm
Grazie
 

ff16

New Member
Avrei necessita' di inviare dei comandi ad un'app che gira su smartphone, collegato a rete internet solo via connessione dati fornita dalla sim
I comandi vengono inviati da pc ufficio che dispone di connessione internet
Il principale obiettivo da raggiungere sono le prestazioni, intese come velocita' tra invio comando da postazione pc e visualizzazione dello stesso sullo smartphone
Sto provando con l'invio dei classici sms, ma le prestazioni non sono accettabili, nel senso che alcuni arrivano su telefono dopo qualche secondo dall'invio, altri dopo una decina di secondi, altri anche dopo qualche minuto, e questi sono tempi inaccettabili, da contenere all'interno di 1-2 secondi
Poi ho tentato col realizzare un mini tcp-server in ascolto sul telefono, in grado di elaborare icomandi ricevuti, ma ovviamente usando la rete dati telefonica e' impossibile arrivare da pc a smartphone in quanto 'nascosto' dalla struttura del gestore telefonico e quindi pur avendo l'indirizzo locale del telefono non si riesce a raggiungerlo da internet
Ho poi provato usando il servizio Pushover.net , installando un client apposito a bordo del telefono, ma anche con questo sistema i tempi di arrivo del messaggio non sono conformi alle prestazioni che mi prefiggo di ottenere, nel senso che alcuni arrivano dopo qualche secondo altri anche dopo qualche minuto
Quindi sms no, via socket tcp no, via notifica push no
Cosa resta?
Come fare per comunicare 'rapidamente' tra pc e smartphone (collegato a rete dati della sim)?
ciao a tutti, ciao amorosik hai trovato un metodo veloce? ;-)
Gli squilli? 1,2 input.
oppure gli telefoni direttamente e glie lo dici a voce ...all app 🙃 o con una codifica di toni. (e voi altri non ridete, non lo so proprio se programmando un telefonino certe cose si possono fare ...che magari risponda pure da solo :p )
 
Last edited:

amorosik

Well-Known Member
Licensed User
Non l'ho ancora fatto, ma sul sito goooogle c'e' scritto che il 95% dei messaggi vengono consegnati entro 250 millisecondi
Fosse vero, la cosa farebbe ben sperare
Ma 'ste cose e' sempre bene toccarle con mano perche' dal dire al fare c'e' sempre il mare di mezzo
 
Top