Prise en charge du protocole MQTT

Bonjour Arnaud,

La plateforme Metrics est exactement ce qu'il te faut.

Nous n'avons pas pour le moment de point d'entrée MQTT, mais nous pouvons l'étudier. A à la remontée de vos données, vous n'avez pas la possibilité de récupérer les mesures et convertir ça en HTTP pour faire un POST vers notre plateforme ?

La platforme Metrics permet de collecter, stocker et requêter. La partie requette peut se faire dans plusieurs protocole (actuellement OpenTSDB, mais d'autres arrivent : Warp10, Prometheus, Graphite,...) et vous pouvez surtout composer rapidement des dashboard via Grafana en utilisant l'un des protocoles cités.

Pour MQTT, selon la possibilité que vous avez, nous poursuivrons la discussion pour voir ensemble comment on peut répondre au besoin via MQTT (MQTT défini le transport mais pas le format des données).

Bonjour Steven,

Merci bcp pour votre réponse!

Concernant MQTT, les requêtes sont au format JSON et ce serait cool de pouvoir avoir un point d'entrée MQTT. Serait-ce possible?
Je n'ai pas la possibilité de le transformer en http car c'est le matériel (micrologiciel intégré) qui push les données toutes les 5 secondes.
Par contre, il y a aussi un mécanisme de sécurité:
> Bidirectional digital signature; 32~128-bit data encryption, Serialization;

Je n'ai pas encore le prototype de la box intégrant les capteurs de mesure mais elle devrait arriver fin de semaine prochaine ou la semaine suivante.

Concernant le requêtage, nous avons une api nodeJs qui devra être capable de requêter les données stockées sur Metrics. Je ne souhaite pas utiliser grafana ou un autre outil de dashboarding pour cela.
Je présume que cela sera possible avec OpenTSDB ?

Pour le requêtage, nous avons plusieurs solutions :

* Warp10 que nous préconisons (solution la plus optimale sur beaucoup de critère)
* OpenTSDB
* Prometheus (soon)
* Graphite (Soon)

Pour requêter en Warp10, il y a deux possibilités :

* API HTTP
* Langage WarpScript (assez simple pour un besoin simple, mais très puissant pour des besoins complexes)

Exemple de requêtage en WarpScript :
[ token_read 'sensor.temperature' { 'sensor_id' '01' 'location' 'room_1' } NOW -1 ] FETCH

Et on va récupérer la dernière valeur disponible pour le capteur de temperature donc l'identifiant est sensor_id=01 qui se trouve dans la room_1.

Pour MQTT il faut qu'on en discute ensemble plus en détails (quel type de matériel, etc...) car ça semble très propriétaire, donc on doit voir comment faire une interface générique qui couvre l'ensemble des besoins. Pouvez-vous me donner (en DM) un email de contact afin d'aller plus en détail sur MQTT ?

Pour être honnête, je ne connais pas le language Warp10 mais je présume qu'il est capable de faire ce dont nous avons besoin.

A propos de MQTT, je vous envois un message en DM.

Bien reçu le DM. Je vous envoie un email tout de suite :slight_smile:

Bonjour,

Le support du protocole MQTT pour ingérer des données sur Metrics est-il toujours en alpha ?
Comment peut-on tester ?

Bonjour Thomas,

nous sommes justement sur un redesign de notre stack d'ingestion pour prendre en compte les protocoles customs (TCP/UDP) comme graphite , Metricbeat, et également MQTT.

Le problème avec MQTT c'est qu'il ne défini que le transport, pas le format des messages.
Pourriez-vous préciser quel device vous utilisez, son format de donnée, et éventuellement la doc correspondante ? merci :)

bonjour,

Si vous avez besoin d'un processus scalable et asynchrone avant de stocker dans une timeserie, il y a kafka dispo chez ovh aussi https://labs.ovh.com/queue-as-a-service

Je l'utilise en sortie du backend SIgfox pour ne louper aucun event,
ensuite des processus indépendants poussent chaque mesure dans une timeserie , dans un SGBDR et dans un eventStore.

Belle journée.

Bonjour, je suis dans la même situation que ArnaudH1. J'aurais besoin de capter et stocker des données issues de thethingsnetwork, et voulais savoir ou en était le point d'entrée mqtt.
Merci

Bonjour !

Nous n'avons pour le moment pas avancé sur MQTT pour une raison simple : il n'y a pas de standard concernant le format des messages. En ce sens, MQTT est comparable à HTTP, fournir un point d'entrée HTTP n'est pas suffisant, il faut définir le format qu'on peut comprendre derrière (Sur HTTPS nous comprenons OpenTSDB, Warp10, Prometheus, Graphite, Influxdb).

En parcourant le SDK de The Things Network, le publish semble positionner les données dans types.DownlinkMessage.PayloadRaw

// Publish downlink message
err = myNewDevicePubSub.Publish(&types.DownlinkMessage{
AppID: appID, // can be left out, the SDK will fill this
DevID: "my-new-device", // can be left out, the SDK will fill this
PayloadRaw: []byte{0xaa, 0xbc},
FPort: 10,
Schedule: types.ScheduleLast, // allowed values: "replace" (default), "first", "last"
Confirmed: false, // can be left out, default is false
})

alors que le souscription d'un event utile event.Data :


// Subscribe to events
events, err := allDevicesPubSub.SubscribeEvents()
if err != nil {
log.WithError(err).Fatal("my-amazing-app: could not subscribe to events")
}
log.Debug("After this point, the program won't show anything until we receive an application event.")
for event := range events {
log.WithFields(ttnlog.Fields{
"devID": event.DevID,
"eventType": event.Event,
}).Info("my-amazing-app: received event")
if event.Data != nil {
eventJSON, _ := json.Marshal(event.Data)
fmt.Println("Event data:" + string(eventJSON))
}
break // normally you wouldn't do this
}

Comment voudriez vous pousser les données sur Metrics ?

Merci de votre réponse.
Je m'absente 10 jours mais reviendrai vers vous en rentrant.
Cordialement
Servan RIAUD