Interface shell

Introduction

L’échange d’information entre les micro-contrôleurs BLE et hôte se réalisent à l’aide de l’interface shell.

Trames Shell

  • Émission

uart:~$ mesh models msg publish <elem idx> <Model ID> <opcode> [payload] [msg_id]
  • elem idx: index de l’élément dans la configuration du produit obligatoire

  • Model Id: identifiant du modéle défini par la SIG obligatoire

  • opcode: correspond au type de message envoyé (par exemple, get, set ou status) obligatoire

  • payload: les données utiles optionnel

  • msg_id: identifiant du message (spécifique pour certain comportement) optionnel

  • Réception

Mesh status from <address src> dst <address dst> rssi <rssi> element <elem idx>, model <model id> op <opcode> len <len>: [payload]
  • address src: adresse émettrice

  • address dst: adresse destinataire

  • rssi: valeur du rssi

  • elem idx: index de l’élément dans la configuration du produit

  • Model Id: identifiant du modèle défini par la SIG

  • opcode: correspond au type de message envoyé (par exemple, get, set ou status)

  • len: longueur des données utiles

  • payload: les données utiles optionnel

Connexion

Quels sont les paramétres de configuration du shell ?

  • baudrate :

    • Speed : 115200

    • Stopbits : 8N1

  • Flow Control : No

Est-il possible d’émettre plusieurs commandes en même temps ?

NON, actuellement l’interface est half duplex, il faut attendre la réception du message de succès ou d’échec

  • Succès :

    cmd_end (err 0)
    
  • Échec :

    cmd_end (err -1)
    

Warning

En cas d’échec, le code err varie, il sera obligatoirement négatif.

Démarrage du module BLE

Comment savoir que le module BLE a démarré ?

  • Le message Application is ready est transmis sur le shell.

Application is ready
uart:~$
  • Afin de pouvoir utiliser l’interface shell BLE, il est nécessaire de l’initialiser via la commande Mesh init

uart:~$ mesh init
Mesh shell initialized
cmd_end (err 0)

Comment redémarrer le module BLE ?

  • il est possible de redémarrer le module BLE à l’aire d’une commande kernel reboot cold

uart:~$ kernel reboot cold

Application is ready
uart:~$

Comment récupérer les informations du module BLE ?

La commande vnd info all permet de récupérer les informations listées ci-dessous :

build time: Feb 29 2024 10:27:03
MODULE_MANUFACTURER_NAME=*****
MODULE_MANUFACTURER_ID=XX
MODULE_MODEL_NAME=****
MODULE_MODEL_ID=X
MODULE_PLATFORM=NRF52840
BOARD=******_nrf52840
PROJECT_NAME=******
MODULE_SW_VERSION_MAJOR=X
MODULE_SW_VERSION_MINOR=Y
MODULE_SW_VERSION_REVISION=R
MODULE_SW_VERSION_BUILD=Z
MODULE_VERSION_STR=X.Y.R.Z
OUTPUT_FILENAME=************_vX.Y.R.Z
ADDRESS_MAC=XX:XX:XX:XX:XX:XX
name=****_XXXX

Comment connaitre le status BLE du produit ?

Le produit est soit provisionné soit non provisionné.

  • Lorsque le produit a été provisionné par un tiers alors un message shell est transmis : Local node provisioned, net_idx 0xXXXX address 0xXXXX.

cmd_end (err 0)

...

Provisioning link opened on PB-GATT
Local node provisioned, net_idx 0x0000 address 0x02d7
  • Si le produit est exclu par un tiers du réseau BLE Mesh alors le message : The local node has been reset and needs reprovisioning

cmd_end (err 0)

...

The local node has been reset and needs reprovisioning
  • Afin de vérifier à n’importe quel moment que le produit est provisionné ou non, la commande vnd isprov renvoie si le produit est provisionné ou non.

uart:~$ mesh init
Mesh shell initialized
cmd_end (err 0)
uart:~$ vnd isprov
prov=false
cmd_end (err 0)
Provisioning link opened on PB-GATT
Local node provisioned, net_idx 0x0000 address 0x02df
Provisioning link closed on PB-GATT
cmd_end (err 0)
uart:~$ vnd isprov
prov=true
cmd_end (err 0)

...

The local node has been reset and needs reprovisioning
cmd_end (err 0)
uart:~$ vnd isprov
prov=false
cmd_end (err 0)
uart:~$

Rappels de https://dev.linkio.net/doc/lio_mesh_solution/pages/controller/shell.html

Mesh commands

For commands :

  • elem id : the element index of the model instance (source)

  • model id : the model id sender (source)

  • company id: the Company ID of the vendor model

  • addr : the destination address

  • opcode : the opcode message to send

  • opcode_rsp: the opcode waited for response

  • payload : Hexadecimal BCD value

  • msg_id : ID of message, if not given, it’s 0

For answers :
  • src addr : the element address of the model instance (source)

  • dest addr : the element address of the model instance (destination)

  • rssi : Received Signal Strength Indicator

  • elem id : the element index of the model instance (source)

  • mid cid : the client model id + compagny id(for vendor) which received message

  • opcode cid: the opcode + compagny id(for vendor) which received message

  • status : Linkio status

  • length : payload length

models msg send

Send a command from a generic model client to destination

==> mesh models msg send <elem id> <model id> <addr> <opcode> [payload] [msg_id]

models msg send-vnd

Send a command from a vendor model client to destination

==> mesh models msg send-vnd <elem id> <model id> <company id> <addr> <opcode> [payload] [msg_id]

models msg send-rsp

Send a command from a generic model client with an expected response from destination

==> mesh models msg send-rsp <elem id> <model id> <addr> <opcode> <opcode_rsp> [payload] [msg_id]

models msg send-vnd-rsp

Send a command from a vendor model client with expected response from destination

==> mesh models msg send-vnd-rsp <elem id> <model id> <company id> <addr> <opcode> <opcode_rsp> [payload] [msg_id]

models msg publish

Publish a status message on a generic model client.

==> mesh models msg publish <elem id> <model id> <opcode> [payload] [msg_id]

models msg publish-vnd

Publish a status message on a vendor model client.

==> mesh models msg publish-vnd <elem id> <model id> <company id> <opcode> [payload] [msg_id]