Italian MQTT - ci sono esperienze italiane ?

[valentino s]

Sto valutando di usare MQTT per far parlare uno o piu' device mobile con un pc in ufficio, senza salvare dati su un server online.

Il pc in ufficio farebbe da server dei dati da comunicare on demand ai device mobili.

L'idea e' di usare b4j per il pc e gli altri per i device mobili.

1. Qualcuno ci ha gia' lavorato ?
   
2. Ha preferito installare mosquitto su un proprio server o si e' appoggiato a servizi esterni ?
   
3. Quali sono i contro di una soluzione del genere ?

Scusate, anche a me sembra abbastanza secca come domanda, ma non vorrei imbarcarmi in una soluzione della quale si parla solo bene -) e poi sicuramente ha qlc che non va.

Grazie a tutti

 

[LucaMs]

1) pochissimo, quasi niente
2) beh, conosci la risposta: se installi mosquito il pc dovrà sempre essere accesso, altrimenti gli altri dispositivi...! Appoggiarsi a servizi esterni è quasi sempre meglio evitarlo, cercare sempre di essere "indipendenti" (magari un bel giorno il fornitore del servizio si sveglia e ti chiede x al mese oppure chiude)
3) nessuna, mi pare

Ma ci sono membri italiani che c'hanno smanettato di più (anche utilizzato seriamente, vero HHUUHHH?)

 

[udg]

UHHHUUUUHHHHHH Confermo.
Ho provato tre alternative, seppur in ambiti e con scopi diversi.
cloudmqtt.com - provider esterno, gratuito fino ad una decina di user (se non ricordo male); ho modificato il codice demo della chat presente sul forum per crearmi una piccola chat di famiglia con stanze multiple e non ricordo che altro
b4j con jmqttbroker - su un vps a basso costo utilizzato anche per altro; esperimento che usa il serializator per scambio dati tra app mobile e b4j (per poi far uso di MySql) e introduzione di mqtt per inviare messaggi privati 1-1 o 1-tutti.
mosquitto su Windows Server 2008 - l'installazione sembra terminare regolarmente ma non è vero. Non so se dipenda da come il sistemista abbia configurato WS o dalla webfarm in Inghilterra o altro (includendo me stesso), ma non ho avuto il piacere di poterlo testare
mosquitto su server Linux - funziona bene ma l'instalalzione e configurazione è avvenuta ad opera di un sistemista mooolto geloso delle sue macchine..

jmqtt ha al momento due importanti limiti: non usa SSL e non funziona in QOS livello 2.

A livello di test, una soluzione vale l'altra. In produzione mi orienterei su mosquitto (o equivalente) per completezza e robustezza. Attenzione a studiare bene il meccanismo dei livelli di QOS e tararlo sulle reali necessità.

udg

 

[roncoa]

Io per far colloquiare i miei moduli domotici fatti con degli ESP8266 con android, ho utilizzato CloudMQTT senza avere nessun problema.
Ho testato anche Mosquitto installato su un Raspberri PI 3

 

[udg]

@roncoa molto interessante il tuo utilizzo; avresti il tempo e la voglia di imbastire un tutorial passo-passo che parta dall'acquisto di un esp8266 e mostri come una app android controlli le luci o altro?
Lo soi che ci sono vari thread sul forum, ma un tutorial che parta da "andiamo su amazon e con 16€ acquistiamo abc.." è un'altra cosa..

 

[pixet]

Ciao,
ho fatto un po di prove per delle app IoT, ho usato eMQTT con e senza il database per l'autenticazione ma senza salvare i dati inviati dai client.
Ho realizzato un server in casa, i test li ho fatti su RasPi e poi ho fatto un server basato su debian e poi installando emqtt.
La scelta di usare eMQTT è nata dalla facilità di realizzare cluster e molto altro.
Ho fatto molti test di carico ed è sorprendente, attualmente gira su un Alix dula-core con 4GB di ram.
Con questa configurazione ho simulato connessioni utente fino a oltre 50000 e non ha mai collassato.
Ho provato anche quelli online, ma in seguito penso di attivare MongoDb o CougarDB dove salverò i dati che arrivano dai client.
Le app che lo usano al momento sono per gestire controllo accessi il db gira su un client dedicato che risponde ai messaggi degli altri client.
Il client dedicato è i B4J mentre le app girano su Android e iOS
Rob

 

[roncoa]

@roncoa molto interessante il tuo utilizzo; avresti il tempo e la voglia di imbastire un tutorial passo-passo che parta dall'acquisto di un esp8266 e mostri come una app android controlli le luci o altro?
Lo soi che ci sono vari thread sul forum, ma un tutorial che parta da "andiamo su amazon e con 16€ acquistiamo abc.." è un'altra cosa..

Inizia a dare un occhiata qui ci sono gli sketch degli ESP8266.

Per cominciare, il mio consiglio e' una NODEMCU: facile da gestire e programmare.

 

[Gnappo jr]

UHHHUUUUHHHHHH Confermo.
Ho provato tre alternative, seppur in ambiti e con scopi diversi.
cloudmqtt.com - provider esterno, gratuito fino ad una decina di user (se non ricordo male); ho modificato il codice demo della chat presente sul forum per crearmi una piccola chat di famiglia con stanze multiple e non ricordo che altro
b4j con jmqttbroker - su un vps a basso costo utilizzato anche per altro; esperimento che usa il serializator per scambio dati tra app mobile e b4j (per poi far uso di MySql) e introduzione di mqtt per inviare messaggi privati 1-1 o 1-tutti.
mosquitto su Windows Server 2008 - l'installazione sembra terminare regolarmente ma non è vero. Non so se dipenda da come il sistemista abbia configurato WS o dalla webfarm in Inghilterra o altro (includendo me stesso), ma non ho avuto il piacere di poterlo testare
mosquitto su server Linux - funziona bene ma l'instalalzione e configurazione è avvenuta ad opera di un sistemista mooolto geloso delle sue macchine..

jmqtt ha al momento due importanti limiti: non usa SSL e non funziona in QOS livello 2.

A livello di test, una soluzione vale l'altra. In produzione mi orienterei su mosquitto (o equivalente) per completezza e robustezza. Attenzione a studiare bene il meccanismo dei livelli di QOS e tararlo sulle reali necessità.

udg

Un saluto a tutti.
Qualcuno sa il motivo per il quale jmqtt non funziona in QOS livello 2 e dovoe è dove cavolo è specificata questa limitazione?
C'è un modo per sapere se il messaggio è arrivato al brooker?
Grazie

 

[LucaMs]

https://www.b4x.com/android/forum/threads/jmqtt-official-android-mqtt-client.59497/#post-381673

 

[LordZenzo]

Ho testato anche Mosquitto installato su un Raspberri PI 3

anche io ho un rspberry e non so come si installa mosquitto, ma sarei interessato a saper come!

 

[udg]

@Gnappos : le limitazioni del modulo jBroker sono specificate da Erel in risposta ad un mio specifico quesito.

Tieni a mente che jBroker e jMQTT sono ovviamente due distinti componenti e che le limitazioni di cui si parla si riferiscono solo al primo dei due!

Ho letto un po' la documentazione di eMQTT (suggerito da @pixet nel post #6) e mi pare un'alternativa davvero notevole al più citato mosquitto. Al momento la mia idea è che jBroker è adatto per fare esperienza e giocare un po' a livello di prototipo, ma per andare in produzione è necessario passare ai "fratelli maggiori".

udg

 

[Gnappo jr]

Grazie ad udg e grazie a LucaMS, il mio apprendimento su MQTT può continuare:

Immaginiamo di aver la necessità d'inviare ad un server-booker dei dati raccolti di tanto in tanto da un device Android che ha una connessione instabile. Necessita avere la certezza che i dati siano comunque inviati appena la connessione torni disponibile e ovviamente che siano arrivati a destinazione.

Erel nel post
https://www.b4x.com/android/forum/threads/jmqtt-official-android-mqtt-client.59497/#post-381673
in risposta a TommyBee che chiedeva l'evento deliveryComplete dice:
" Why do you need it? If you need to make sure that the message is delivered then set the QOS to 1 or 2. If it will not be delivered then the connection will break."

Quindi se ho capito bene, un dato è arrivato se la connessione non cade, altrimenti se il dato non arriva al brooker essa cade e bisognerà tentare a ripristinarla con vari tentativi finchè non vi sia successo per poi ritentare l'invio. Questo però sembra bloccare l'esecuzione dell'app finchè non vi è di nuovo connettività o finchè non scade il timeout.
Qualcuno può darmi un parere in merito?

 

[udg]

Ciao,

da quello che ho letto, la faccenda QOS va divisa in due: da una parte la relazione OriginatingClient->broker e dall'altra quella broker->ReceivingClients.
Nella prima relazione il livello QOS lo stabilisce il client che invia il messaggio, che quindi decide se inviare "al buio" (Qos 0), "sicuro ma con possibili ripetizioni" (Qos 1) oppure "sicuro senza ripetizioni ma più lento" (Qos 2). Nella seconda è il ricevente che sottoscrive un canale con un dato QOS.
Nel caso Qos1 quello che accade è che il client invia il messaggio e attende un certo intervallo di tempo una risposta di conferma dal broker; se non arriva ripete l'invio.
Ogni messaggio è caratterizzato da un suo identificatore e quindi nella risposta del broker si fa riferimento a questo valore per dare conferma all'inviante, che fino a quel momento ha conservato localmente copia del messaggio inviato.

Che accade se durante l'attesa della conferma viene fermato il programma che ha inviato il messaggio? Al momento non saprei.. può darsi che la libreria mQTT salvi tali messaggi in qualche file oppure semplicemente che vadano persi.
E se il programma resta in funzione ma cade la connessione? Allora dovrebbe accadere ciò che ha descritto Erel, ovvero una segnalazione di connessione interrotta. E qui ritornerebbe la domanda precedente: a chi tocca salvare i messaggi in attesa di conferma?

Personalmente, fidandomi poco, ho preferito duplicare gli sforzi. Prima salvo il messaggio su un DB remoto e poi invio lo stesso tramite MQTT. Se la giostra MQTT funziona il destinatario riceve il messaggio in tempo reale altrimenti quando si va a sincronizzare preleva dal DB tutti i msg accumulati fino a quel momento. Ovviamente tocca gestire i possibili duplicati.

Credo che la tattica da adottare dipenda sempre molto dal contesto e dalla natura dei messaggi. Se si tratta di IoT e letture continue di strumentazione (es. temperatura) forse perdere qualche dato per strada potrebbe non essere critico e quindi anche QOS 0 potrebbe funzionare (al peggio inserendo un check tipo "se ultimo dato è più vecchio di 5 minuti allora preoccupati..").


udg