Existe-t-il un moyen d'envoyer des messages HTTP (GET, POST, etc.) du central BLE (client) au périphérique BLE (serveur)? Actuellement, j'envoie du texte brut en utilisant le protocole du GATT. Étant donné qu'un serveur HTTP fonctionnant déjà à l'intérieur de mon périphérique, je préférerais utiliser le protocole HTTP. Quelqu'un m'a suggéré d'utiliser HPS (HTTP Proxy Service) sur BLE pour faire ce travail. Mais je n'ai vraiment aucune idée de HPS.

Existe-t-il un autre moyen d'envoyer des messages HTTP du client au serveur via BLE? Quelqu'un peut-il me dire comment cela peut être fait? ou Existe-t-il un autre moyen d'envoyer HTTP via BLE.

Toute aide serait appréciée

3
Shibin Francis 27 nov. 2017 à 15:43

3 réponses

Meilleure réponse

<edit> Vous avez demandé s'il y avait un moyen autre que le HPS standardisé d'envoyer des messages HTTP via Bluetooth. D'après ce que je sais, vous avez une autre option standardisée. </edit> La seule chose normalisée est IPv6 sur BLE, mais elle est loin d'être bien prise en charge. Le problème avec http est qu'il sera assez inefficace en raison des longues chaînes qui doivent être envoyées comme en-têtes.

<edit>

Vous pouvez trouver le service HPS ici: https: //www.bluetooth. org / docman / handlers / downloaddoc.ashx? doc_id = 308344.

Si vous voulez vraiment utiliser HTTP sur BLE mais que vous ne voulez utiliser aucune des méthodes standardisées, vous pouvez par exemple ouvrir un L2CAP CoC et simplement envoyer la requête HTTP dans un sens et renvoyer la réponse HTTP dans un sens. De cette façon, vous remplacez simplement TCP par L2CAP CoC.

</edit>

4
Emil 22 avril 2020 à 11:24

Je ne suis pas d'accord avec l'affirmation d'Emil selon laquelle IPv6 sur Bluetooth est la seule option standardisée. Je travaille pour le Bluetooth SIG btw. Le service proxy HTTP est un service standard du GATT. Vous pouvez télécharger la spécification ici: https://www.bluetooth.com/specifications/gatt/

Il y a des commentaires ici à l'effet que "HTTP sur Bluetooth" est une mauvaise idée mais aucune élaboration quant à ce qui est "mauvais". Je pense qu'il peut y avoir une certaine confusion sur ce qui est impliqué et quelle est l'utilisation prévue du service proxy HTTP.

Ce service proxy HTTP GATT doit s'exécuter sur un périphérique qui possède à la fois une pile Bluetooth Low Energy (LE) et une pile TCP / IP. Il a des caractéristiques GATT qui permettent de configurer les requêtes HTTP, en écrivant des valeurs à ces caractéristiques. Cela inclut les valeurs d'en-tête HTTP. On s'attend à ce que la plupart de ces paramètres ne changent pas ou du moins ne changent pas fréquemment après avoir été définis initialement. Les appareils agissant en tant que client auprès du service proxy HTTP du GATT envoient ensuite des données via HTTP et TCP / IP indirectement , via le serveur GATT. Pour ce faire, ils écrivent dans la caractéristique HTTP Entity Body .... généralement une petite valeur telle qu'une lecture de capteur. Une opération HTTP est ensuite déclenchée par le dispositif client GATT en écrivant un seul octet dans la caractéristique de point de contrôle HTTP (par exemple 1 pour déclencher un HTTP GET).

Il est peut-être inapproprié de parler de HTTP via Bluetooth. Ce n'est pas ce qui se passe ici. Il s'agit d'une architecture à trois niveaux, avec une communication Bluetooth LE très légère entre (1) un périphérique Bluetooth et un (2) périphérique Bluetooth et TCP / IP à double technologie, agissant comme un proxy, qui communique ensuite la demande encodée Bluetooth qu'il a configurée à l'intérieur, à un (3) serveur HTTP distant via TCP / IP.

Quant aux commentaires sur l'utilisation du profil de port série et à la suggestion que cela offrirait des avantages en termes de performances, cela est également discutable. Il n'y a pas de détail sur ce qui est envisagé ici mais je suppose que l'idée est que toutes les opérations HTTP soient formulées et envoyées via une connexion Bluetooth BR / EDR en utilisant le profil du port série. Bluetooth BR / EDR fonctionne à 2 méga symboles par seconde au niveau de la couche physique et par défaut, Bluetooth LE fonctionne à 1 méga symbole par seconde. Mais depuis Bluetooth 5, sorti il y a plusieurs années, Bluetooth LE prend également en charge 2 méga symboles par seconde. De plus, en raison de la conception du service de proxy HTTP, avec des composants fixes ou rarement variables d'une requête HTTP qui ne doivent être configurés qu'une seule fois, vous constaterez probablement que vous transférez moins de données lorsque vous utilisez HPS vs SPP. Tout dépend, bien sûr, mais je pense que c'est probable ...

J'espère que cela t'aides.

0
martin_bluetooth_sig 22 avril 2020 à 09:57

Vous pouvez utiliser la passerelle Bluetooth. Certaines passerelles Bluetooth prennent en charge l'API Restful sur les appareils opérateur.

0
Qingang Wang 9 janv. 2020 à 16:28
47511294