Lorawan-stack: Configuration de la couche MAC de l'appareil dans la console

Créé le 25 févr. 2020  ·  9Commentaires  ·  Source: TheThingsNetwork/lorawan-stack

Résumé

La couche MAC du périphérique doit être configurable à partir de la console.
Remplace https://github.com/TheThingsNetwork/lorawan-stack/issues/1378

Pourquoi avons nous besoin de ça?

  • Création/mise à jour d'appareils de classe B depuis la console
  • Création/mise à jour des terminaux en utilisant des paramètres de couche MAC autres que ceux par défaut (par exemple, The Things Uno)

Qu'est-ce qu'il y a déjà ? Que voyez-vous maintenant?

CLI comme seul moyen de configurer la couche MAC du périphérique

Que manque-t-il? Qu'est-ce que tu veux voir?

Prise en charge de la configuration de tous les champs MACSettings .

Liste de priorité des champs
Haut

  • Tous les dispositifs

    • [x] rx2_data_rate_index
    • [x] rx2_frequency
    • [x] factory_preset_frequencies

  • Spécifique à la classe A (aka, tous les appareils non multicast)

    • [x] rx1_delay
    • [x] rx1_data_rate_offset
    • [x] resets_f_cnt

  • Spécifique à la classe B

    • [x] ping_slot_periodicity
Moyen

  • Spécifique à la classe A (aka, tous les appareils non multicast)

    • [ ] max_duty_cycle
    • [x] supports_32_bit_f_cnt
    • [ ] use_adr
    • [ ] status_time_periodicity
    • [ ] status_count_periodicity

  • Spécifique à la classe B

    • [ ] ping_slot_data_rate_index
    • [x] ping_slot_frequency
    • [ ] beacon_frequency
Meugler

  • Spécifique à la classe A (aka, tous les appareils non multicast)

    • [ ] adr_margin
    • [ ] desired_rx1_delay
    • [ ] desired_rx1_data_rate_offset
    • [ ] desired_rx2_data_rate_index
    • [ ] desired_rx2_frequency
    • [ ] desired_max_duty_cycle
    • [ ] desired_adr_ack_limit_exponent
    • [ ] desired_adr_ack_delay_exponent

  • Spécifique à la classe B

    • Non multidiffusion

      • [ ] class_b_timeout

      • [ ] desired_ping_slot_data_rate_index

      • [ ] desired_ping_slot_frequency

      • [ ] desired_beacon_frequency

  • Spécifique à la classe C

    • Non multidiffusion

      • [ ] class_c_timeout

REMARQUE : Certains d'entre eux peuvent déjà être configurables (par exemple, des éléments FCnt), veuillez mettre à jour les cases à cocher en conséquence et vérifier que ces paramètres sont placés aux bons endroits (c'est-à-dire qu'ils ne sont pas disponibles pour les appareils de multidiffusion)

Je pense que les paramètres spécifiques aux classes B et C devraient être disponibles pour tous les appareils, même pour les appareils pour lesquels le SupportsClass{B,C} est false . De cette façon, les utilisateurs peuvent désactiver/activer (temporairement) le fonctionnement en classe B/C chaque fois que nécessaire et conserver les paramètres spécifiques.

Les paramètres spécifiques à la classe A ne devraient être disponibles que pour les appareils non multicast.

Comment proposez-vous de mettre cela en œuvre ?

Ajoutez tous les champs de MACSettings https://github.com/TheThingsNetwork/lorawan-stack/blob/74c9da9a9e07a31d7103eabcd3440f9c80c24ea1/api/end_device.proto#L190 -L284 en tant que champs à la configuration de la couche réseau. Ces champs doivent être configurables à tout moment, c'est-à-dire à la fois lors de la création et de la mise à jour.

Utilisez les commentaires du proto pour la description.

Pouvez-vous le faire vous-même et soumettre une Pull Request ?

@bafonins s'en chargera

console compaapi documentation uweb
Source
picture rvolosatovs

Tous les 9 commentaires

Je suis surtout fait avec les champs de haute priorité pour la configuration des paramètres MAC:


Captures d'écran
ABP :

Screenshot 2020-03-29 at 17 41 50

classe B :

Screenshot 2020-03-29 at 17 44 00

OTAA :
Screenshot 2020-03-29 at 18 11 58

Cependant, afin de tous les ajouter et de permettre aux utilisateurs de s'inscrire, par exemple, The Things Uno via la console, le champ mac_state.factory_preset_frequencies est manquant. Je ne sais pas exactement comment cela devrait être représenté dans l'interface utilisateur, j'ai actuellement ces idées :

  1. En tant que multi-sélection :
    Screenshot 2020-03-30 at 09 47 01

OMI, un tel champ rend la sélection des fréquences très facile. De plus, nous pouvons présenter à l'utilisateur des fréquences basées sur le frequency_plan_id pour l'appareil final. Cependant, comme @rvolosatovs l'a mentionné, les entrées peuvent avoir des valeurs arbitraires et ne dépendent pas nécessairement du plan de fréquence de l'appareil final.

De plus, pour cette approche, il serait formidable d'avoir un RPC pour récupérer des préréglages de fréquences par bande.

  1. En tant que tableau d'entrées numériques (similaire à la façon dont nous autorisons l'ajout d'en-têtes aux intégrations de webhook) :
    Screenshot 2020-03-30 at 11 06 13

Cette approche est plus souple, cependant, elle prend plus de temps à l'utilisateur pour paramétrer le champ, nécessite de taper des fréquences.

  1. En tant que multi-sélection avec des options pour créer de nouvelles étiquettes :

freqqs

Fondamentalement, une combinaison de 1 et 2.

@rvolosatovs @johanstokking

bafonins picture bafonins le 30 mars 2020

Je pense qu'avoir la liste (2) est le plus clair, car cela montre l'ordre. Et l'ordre est important.

Les fréquences peuvent en effet être n'importe quoi, mais il serait très utile de les récupérer via un plan de fréquences existant.

johanstokking picture johanstokking le 30 mars 2020
👍1

Ajout de compat/api car nous pourrions avoir besoin d'un NS rpc pour obtenir le plan de fréquences.

johanstokking picture johanstokking le 30 mars 2020

Je pense qu'avoir la liste (2) est le plus clair, car cela montre l'ordre. Et l'ordre est important.

Les deux composants sélectionnés (1) et (2) préservent également l'ordre.

Les fréquences peuvent en effet être n'importe quoi,

Avec (3) des valeurs de fréquence arbitraires peuvent également être ajoutées

bafonins picture bafonins le 30 mars 2020

Je pense que la solution (2) est également la plus propre, tandis que (3) est plus agréable pour une petite quantité de fréquences, en avoir plusieurs (par exemple 4 ou plus) semblera encombrée et difficile à suivre.
Ce serait formidable si nous pouvions avoir des suggestions de fréquence pour (2) dans chaque zone de texte (à partir du plan de fréquences proposé RPC), donc un peu ce que vous voyez dans (3), mais par zone de texte

rvolosatovs picture rvolosatovs le 30 mars 2020
👍1

Plus ou moins terminé avec l'implémentation, mais je veux attendre que https://github.com/TheThingsNetwork/lorawan-stack/issues/2605 soit fusionné avant de faire un PR pour ajouter des tests pour l'assistant de périphérique (y compris la gestion des paramètres mac)

bafonins picture bafonins le 12 juil. 2020

Quel est le statut ici ?

johanstokking picture johanstokking le 3 nov. 2020

@johanstokking https://github.com/TheThingsNetwork/lorawan-stack/pull/3065 est prêt à être examiné. J'ai ajouté tous les champs de priorité élevée et certains champs de priorité moyenne.

bafonins picture bafonins le 3 nov. 2020
👍1

Changement de jalon de ce problème pas de prochaine étape. Tous les champs de priorité élevée ainsi que certains champs de priorité moyenne ont été ajoutés dans https://github.com/TheThingsNetwork/lorawan-stack/pull/3065. J'y reviendrai plus tard si d'autres champs doivent être ajoutés à la console.

bafonins picture bafonins le 21 déc. 2020
Cette page vous a été utile?
0 / 5 - 0 notes

Questions connexes

ecities picture ecities  ·  5Commentaires
johanstokking picture johanstokking  ·  8Commentaires
johanstokking picture johanstokking  ·  5Commentaires
kschiffer picture kschiffer  ·  7Commentaires
adriansmares picture adriansmares  ·  8Commentaires