Consommation de données pour la surveillance par GSM

Consommation de données pour la surveillance par GSM

Une grande part du coût d'une installation de mesure distante basée sur le réseau cellulaire est liée aux frais de communication facturés par l'opérateur. Il est donc important d'estimer correctement la quantité de données qui sera transmise afin de budgéter le système, choisir l'abonnement le plus approprié et faire les bons choix techniques. Voici quelques éléments qui vous aideront pour cette étape.



Pour que cette discussion reste concrète, nous allons prendre en exemple une petit système composé d'un YoctoHub-GSM-3G-EU, assurant la connectivité à trois modules Yoctopuce:

  • Un Yocto-PT100 pour mesurer la température
  • Un Yocto-4-20mA-Rx pour mesurer deux grandeurs physiques spécifiques
  • Un Yocto-GPS pour localiser le système (latitude, longitude, altitude, vitesse)

Au total, il s'agit donc de sept mesures à transmettre.

Notre système de test de transmission par GSM
Notre système de test de transmission par GSM


Si l'on désire surveiller ces 7 mesures chaque minute 24h/24, on pourrait imaginer qu'avec un système idéal cela coûte par exemple 4 octets par mesure, soit grosso-modo 30 octets par minute.

Hélas, Internet n'est pas si efficace que cela pour les petites quantités de données, et il faut y ajouter un bon nombre de données auxiliaires nécessaires au fonctionnement du système.

  1. Les données doivent être au minimum encapsulées dans des paquets réseau TCP/IP afin d'être acheminées au bon serveur, ce qui rajoute au minimum 50 octets à chaque transmission.
  2. Le protocole d'échange utilisé par le serveur peut ajouter quelques centaines d'octets par transmission. C'est le cas par exemple avec le protocole HTTP, qui utilise des headers en texte très verbeux.
  3. Les données elles-même sont souvent encodées de manière plus explicite qu'une transmission binaire, par exemple en JSON. Cela multiplie facilement la quantité de données à transmettre par 3 ou 4.
  4. La vérification de la continuité de la connexion GSM afin de pouvoir poster les données sans retard peut aussi coûter quelques dizaines d'octets par minute, selon le degré de qualité désiré.


Tout cela est un peu vague, mais heureusement, pour préciser les choses, les YoctoHub-GSM disposent d'un compteur d'octets transmis et reçus. Il n'est pas garanti que le chiffre facturé par l'opérateur soit exactement le même puisque des arrondis peuvent s'appliquer, mais au moins cela permet d'avoir une idée plus précise de la consommation de données. Pour relever ce compteur, il vous suffit d'appeler les méthodes:


cellular.get_dataSent()
cellular.get_dataReceived()
 


Si votre YoctoHub-GSM est connecté par un câble USB à un PC, vous pouvez donc faire un petit script qui relève ces deux valeurs chaque minute et fait des statistiques. C'est ce que nous avons fait ici, pour documenter la consommation de quelques scénarios classiques.

Consommation de base

Lorsqu'un YoctoHub-GSM est connecté au réseau TCP/IP, le comportement par défaut est de vérifier sa connectivité chaque minute, afin d'initier une nouvelle connexion en cas de problème. Ce comportement coûte 60 octets par minute, en upload et en download. Si nécessaire, il est possible d'espacer les paquets de vérification à l'aide de la méthode


cellular.set_pingInterval(n_sec)
 



Par ailleurs, le hub effectue un échange avec un serveur NTP toutes les 10 minutes pour faire un éventuel ajustement de l'horloge en temps réel, utilisée pour l'horodatage des mesures. Cela représente 150 octets par échange, dans les deux sens.

Multiplié par 60 minutes, 24 heures et 31 jours, on se retrouve avec une consommation de 6.7 MB/mois pour un maintient de la connectivité et de l'horodatage 24 heures sur 24, indépendamment du nombre de capteurs connectés. Il est bien entendu possible de réduire proportionnellement ce volume en endormant le hub à l'aide de l'horloge interne pendant certaines heures de la nuit, ou en ne le réveillant que périodiquement.

Envoi de mesures par callback HTTP simple

Si l'on rajoute une transmission minimaliste de la valeur courante de chaque capteur chaque minute par une simple requête HTTP GET avec un encodage CSV, on monte à 0.6KB en upload et 0.5KB en download par minute, soit 50 MB/mois. En choisissant l'alternative plus luxueuse d'une transmission par HTTP POST en formulaire WWW-urlencodé, on arrive même à 70 MB/mois.

Ces chiffres correspondent à notre petit système de test avec sept valeurs mesurées. Si vous avez plus de capteurs, ils grandiront un peu, mais pas proportionnellement puisqu'une partie significative des données transmises est due à la pénalité des protocoles, indépendante du nombre de capteurs.

Connexion par callback HTTP Yocto-API

L'utilisation du protocole de callback Yocto-API coûte plus cher. En effet, ce n'est pas qu'une valeur par capteur qui est transmise chaque minute, mais l'état courant de chaque capteur, y compris les valeurs minimales et maximales rencontrées, l'unité de mesure, la précision, les réglages, l'uptime, etc. Et bien sûr, l'intérêt de ce protocole est qu'il permet aussi d'agir sur les modules pour changer leur configuration à distance, ou actionner un actuateur.

Dans sa version de base, le protocole Yocto-API en http coûte pour notre système 12.1KB/minute en upload, et 0.7KB/minute en download, soit un total de 580 MB/mois. Hereusement, si on active l'optimisation introduite il y a quelques temps pour la librairie PHP, on peut ramener le trafic à 300 MB/mois.

Connexion par callback WebSocket

L'utilisation d'un canal WebSocket persistant permet d'éviter la répétition des entêtes HTTP à chaque requête. Par contre, le maintien de ce canal ouvert en permanence, avec la publication en continu de toutes les mesures a aussi un coût non négligeable.

Sans autre précaution, la connexion permanente en WebSocket de notre système coûte entre 3 et 5 KB/minute en upload, et entre 2 et 3 KB en download, soit un total de 350 MB/mois environ. Comme chaque nouvelle mesure est transmise instantanément, le volume transmis variera selon la variabilité des mesures. Par contre cela permet, par exemple à l'aide du GatewayHub, de générer autant de callbacks HTTP simples vers des services tiers que désiré, sans trafic GSM supplémentaire.

De même, si l'on désire forwarder un callback WebSocket vers un callback HTTP Yocto-API avec le GatewayHub, il faut compter avec le chargement à travers le canal websocket de l'état complet de chaque capteur, ce qui représente une charge supplémentaire. Pour un callback HTTP Yocto-API par minute, on arrive à 500 MB/mois. C'est presque le double de ce que coûte un callback HTTP Yocto-API optimisé fait directement par le hub, mais cela offre l'avantage de permettre de prendre entièrement le contrôle à distance du hub à tout moment.

Heureusement, on peut faire mieux que cela. En effet, les 350 MB/mois utilisés pour transmettre instantanément en permanence la valeur courante de chaque capteur ne sont pas forcément utiles, surtout si on ne veut que traiter les données qu'une fois par minute. Il suffit donc de désactiver sur tous les senseurs l'envoi des valeurs instantanées, et d'utiliser à la place les mesures par intervalle de temps.


sensor.muteValueCallbacks()
sensor.set_reportFrequency("1/m")
 


Grâce à l'utilisation des mesures par intervalle de temps, on ramène le traffic à 1.3KB/min en download et 0.9KB/min en upload, soit 100 MB/mois seulement avec une connexion WebSocket permanente. De plus, on reçoit pour chaque intervalle de temps non seulement la valeur moyenne, mais aussi les valeurs min/max sur l'intervalle. Et en cas d'interruption temporaire de connectivité GSM, si vous avez activé l'enregistreur de données sur les modules, vous pourrez retrouver précisément les mesures manquantes, puisqu'elles seront enregistrées simultanément et avec la même granularité.

Cette solution exige toutefois que vous codiez votre solution en exploitant la librairie Yoctopuce et son API callback WebSocket. Si vous cherchez quelquechose de plus facile à mettre en place, en utilisant le GatewayHub et un callback HTTP simple vers un service tiers comme EmonCMS, vous pouvez aussi simplement reconfigurer les capteurs pour propager la valeur moyenne par minute plutôt que la valeur instantanée, comme expliqué dans cet article.


sensor.set_advMode(YSensor.ADVMODE_PERIOD_AVG);
 


Cela vous permettra probablement de bénéficier de la possibilité d'une connection à distance sur votre hub, tout en consommant moins de 100 MB/mois.

Conclusion

Les différences de consommation de donnée GSM entre les différentes options sont vraiment significatives. Cela vaut donc la peine de les prendre en compte dès la conception de la solution logicielle que vous mettrez en place pour lire vos capteurs.

N'oubliez pas non plus que vous pouvez aussi largement réduire la consommation en espaçant les mesures et/ou en déconnectant le hub du réseau par une mise en sommeil.

Et avant de signer le contrat avec un opérateur mobile, n'oubliez pas de vérifier pour de vrai avec une SIM de test qu'il comptabilise les données comme vous vous y attendez...

Commenter aucun commentaire Retour au blog












Yoctopuce, get your stuff connected.