Lorawan-stack: Utiliser un assistant pour créer des terminaux

Le principal problème avec l'implémentation actuelle de la forme de l'appareil est que tout est couplé. Ce qui provoque

1. Schéma de validation complexe et long
2. Pas de moyen simple de désactiver certains champs en fonction de la configuration de la pile
3. Pas de moyen simple de modifier les champs de formulaire/titres de champ en fonction des valeurs sélectionnées
4. Complexité inutile dans le sdk js pour la création/mise à jour/suppression par lots ainsi que la logique de restauration de la création

Je propose d'implémenter le formulaire de dispositif comme le formulaire multi-étapes. Cela peut ressembler à ceci :

Une telle approche résout tous les problèmes mentionnés ci-dessus :

1. Au lieu d'un schéma complexe, nous en définissons un petit pour chaque étape.
2. Désactivez simplement toute l'étape si un certain composant responsable n'est pas disponible dans la pile. De plus, nous pouvons en informer l'utilisateur via une description/notification.
3. Adaptez chaque étape en fonction des valeurs soumises précédemment. Par exemple, remplacez l'étiquette Join EUI par App EUI pour la version lorawan 1.0.x .
4. Pas besoin de requêtes groupées. L'utilisateur devient responsable de la création de l'appareil dans différents composants. Cependant, nous voudrons peut-être conserver la suppression par lots pour plus de commodité.

Les dispositifs d'édition peuvent être implémentés sous la forme d'une pile d'accordéons :

Où chaque accordéon se développe avec une forme autonome.

Outre le formulaire de l'appareil, nous pouvons également utiliser l'assistant pour le formulaire de demande pour :

1. Créez l'application dans le is
2. Liez l'application à comme

cc @kschiffer @johanstokking @htdvisser

Cela me semble bien, surtout si nous pouvons regrouper les champs des composants en une seule étape. De cette façon, nous pouvons simplement ignorer/désactiver les étapes lorsqu'un composant n'est pas disponible.

Référencement https://github.com/TheThingsNetwork/lorawan-stack/issues/1234 également ; même si JS est disponible, l'utilisateur peut ignorer les champs JS.

Je suis venu avec un tel diagramme:

Chaque nœud est une étape

• Les étapes avec un contour en pointillé ne soumettent pas le formulaire mais le conservent dans l'état local pour les étapes suivantes.
• D'autres envoient des demandes au serveur lors de la soumission.

Cela semble compliqué, mais l'implémentation actuelle a un espace d'état encore plus grand concernant la validation/la soumission/la génération de masque de champ/etc.

Considérez le schéma comme une proposition initiale pour démarrer la discussion.

Je pense que c'est un bon début.

• Peut-être que le flux serait meilleur si le serveur de jonction venait en premier.
• Une chose importante sur laquelle nous n'avons pas encore vraiment progressé est le pré-remplissage des champs à partir des modèles d'appareils dans le référentiel d'appareils #263. Je pense que cela pourrait vraiment simplifier le processus de déploiement en production.

Et quelques petites choses :

• Un DevEUI n'est pas interdit pour les appareils ABP (il peut éventuellement être défini)
• Les appareils LoRaWAN 1.0.x n'ont pas de NwkKey , seulement un AppKey
• FNwkSIntKey s'appelle NwkSKey (vers l'utilisateur)
• Le serveur d'applications n'obtient pas les NwkKey ou AppKey

Oui, bon début.

• Peut-être que le flux serait meilleur si le serveur de jonction venait en premier.

Je suis d'accord avec ça. Si le mode d'activation est OTAA et que le cluster JS est activé, sur la page JS, les utilisateurs ont le choix d'entrer des clés racine et de les stocker sur le cluster JS. (s'ils désactivent cela, NS utilise la recherche JS, tout comme lorsqu'il n'y a pas de JS dans le cluster activé)

• Le "mode d'activation" est en charge utile - dans votre diagramme, il correspond en fait à 2 champs - multicast bool et supports_join bool . Il y a 3 options possibles, puisque multicast && supports_join n'est pas valide.
• frequency_plan -> frequency_plan_id

• resets_f_cnt est facultatif, false par défaut.

• FNwkSIntKey doit être présenté comme NwkKey uniquement pour <1.1

• FNwkSIntKey manque dans les paramètres ABP NS pour >= 1.1
• multicast appareils n'ont besoin que AppSKey - NS n'a pas besoin de clés pour que les appareils multicast fonctionnent, seulement AS

@htdvisser

Peut-être que le flux serait meilleur si le serveur de jonction venait en premier.

Pourquoi?

Une chose importante sur laquelle nous n'avons pas encore vraiment progressé est le pré-remplissage des champs à partir des modèles d'appareils dans le référentiel d'appareils #263. Je pense que cela pourrait vraiment simplifier le processus de déploiement en production.

Pour moi, cela semble en dehors de la portée de cette question

Un DevEUI n'est pas interdit pour les appareils ABP (il peut éventuellement être défini)

Voulons-nous également le définir pour les appareils ABP ? Je dirais que moins nous avons de champs, mieux c'est. Cependant, il est nécessaire que nous puissions l'ajouter.

FNwkSIntKey s'appelle NwkSKey (vers l'utilisateur)

L'étiquette doit donc être NwkSKey pour les versions 1.0.x et 1.1.x ? Voici ce que nous avons atm dans la console :

• Les appareils LoRaWAN 1.0.x n'ont pas de NwkKey, seulement une AppKey
• Le serveur d'applications n'obtient pas la NwkKey ou l'AppKey

Corrigé 👌

@johanstokking

Si le mode d'activation est OTAA et que le cluster JS est activé, sur la page JS, les utilisateurs ont le choix d'entrer des clés racine et de les stocker sur le cluster JS. (s'ils désactivent cela, NS utilise la recherche JS, tout comme lorsqu'il n'y a pas de JS dans le cluster activé).

Il s'agit donc simplement de permettre aux utilisateurs d'ignorer l'étape de soumission du serveur de connexion ? Aucune demande à js du tout?

Concernant https://github.com/TheThingsNetwork/lorawan-stack/issues/1134 , pourriez-vous également spécifier où ces champs appartiennent-ils dans le diagramme ?

@rvolosatovs

Le mode d'activation" est dans la charge utile - dans votre diagramme, il correspond en fait à 2 champs - multicast bool et supports_join bool. Il y a 3 options possibles, puisque multicast && supports_join n'est pas valide.

Juste pour clarifier:

1. supports_join=true - OTAA
2. supports_join=false - ABP
3. multicast=true && **no** supports_join - multidiffusion
   Est-ce correct?

resets_f_cnt est facultatif, false par défaut.

Je pense que c'est toujours bien de le montrer aux utilisateurs. Doit-il permettre aux utilisateurs de le configurer pour les appareils de multidiffusion ?

FNwkSIntKey doit être présenté comme NwkKey uniquement pour <1.1

Vous voulez dire NwkSKey ?

fréquence_plan -> fréquence_plan_id
FNwkSIntKey est manquant dans les paramètres ABP NS pour >= 1.1

Corrigé 👌

Diagramme mis à jour :

@htdvisser

Peut-être que le flux serait meilleur si le serveur de jonction venait en premier.

Pourquoi?

Ouais je reviens sur ça; Je pense qu'il est plus logique d'entrer les versions MAC avant d'entrer les clés. Je supporte donc le flux actuel. Si la version MAC est entrée (lorsque NS est activé), nous n'avons pas à demander NwkKey puisque c'est 1.1.x.

Une chose importante sur laquelle nous n'avons pas encore vraiment progressé est le pré-remplissage des champs à partir des modèles d'appareils dans le référentiel d'appareils #263. Je pense que cela pourrait vraiment simplifier le processus de déploiement en production.

Pour moi, cela semble en dehors de la portée de cette question

C'est effectivement hors sujet.

Un DevEUI n'est pas interdit pour les appareils ABP (il peut éventuellement être défini)

Voulons-nous également le définir pour les appareils ABP ? Je dirais que moins nous avons de champs, mieux c'est. Cependant, il est nécessaire que nous puissions l'ajouter.

Oui, nous voulons éventuellement le demander. Plus nous avons d'informations d'identification sur les terminaux, mieux c'est. Il est également requis dans l'itinérance passive avec état. La raison pour laquelle nous ne forçons pas les utilisateurs à saisir le DevEUI est que s'il n'y a pas de DevEUI, nous ne voulons pas que les utilisateurs saisissent de fausses valeurs.

FNwkSIntKey s'appelle NwkSKey (vers l'utilisateur)

L'étiquette doit donc être NwkSKey pour les versions 1.0.x et 1.1.x ? Voici ce que nous avons atm dans la console :

C'est NwkSKey pour 1.0.x et FNwkSIntKey pour 1.1.x.

Si le mode d'activation est OTAA et que le cluster JS est activé, sur la page JS, les utilisateurs ont le choix d'entrer des clés racine et de les stocker sur le cluster JS. (s'ils désactivent cela, NS utilise la recherche JS, tout comme lorsqu'il n'y a pas de JS dans le cluster activé).

Il s'agit donc simplement de permettre aux utilisateurs d'ignorer l'étape de soumission du serveur de connexion ? Aucune demande à js du tout?

En effet.

Un exemple est un appareil doté du modem de Semtech qui utilise le serveur de jonction Semtech. Nous avons seulement besoin de connaître les EUI dans ce cas.

Concernant #1134, pourriez-vous également préciser où ces champs appartiennent-ils dans le diagramme ?

Ils appartiennent à l'étape JS ; ces champs pour passer au JS, si le JS est activé dans le cluster et si l'utilisateur souhaite provisionner les appareils sur le JS.

Ces champs sont facultatifs.

Juste pour clarifier:

1. supports_join=true - OTAA
2. supports_join=false - ABP
3. multicast=true && **no** supports_join - multidiffusion
   Est-ce correct?

Strictement:

1. OTAA : supports_join
2. PBA : !supports_join && !multicast
3. Multidiffusion : multicast

Non valide est supports_join && multicast , mais ceci est (ou devrait être) validé chez NS.

resets_f_cnt est facultatif, false par défaut.

Je pense que c'est toujours bien de le montrer aux utilisateurs. Doit-il permettre aux utilisateurs de le configurer pour les appareils de multidiffusion ?

Non, ce n'est pas pour la multidiffusion. resets_f_cnt fait référence à la liaison montante, mais il n'y a pas de liaison montante dans la multidiffusion.

FNwkSIntKey doit être présenté comme NwkKey uniquement pour <1.1

Vous voulez dire NwkSKey ?

Devrait être NwkSKey en effet.

@bafonins veuillez voir la réponse de @johanstokking .
En ce qui concerne multicast - l'adresse de l'appareil est également requise

• Champs ajoutés à partir de https://github.com/TheThingsNetwork/lorawan-stack/issues/1134
• Ajout DevEUI aux appareils abp/multicast
• Ajout Device Address aux appareils de multidiffusion
  

L'adresse de l'appareil est toujours manquante dans les paramètres du serveur réseau de l'appareil multicast

L'adresse du périphérique est toujours manquante dans les paramètres du serveur réseau du périphérique de multidiffusion

Mis à jour 👌

La multidiffusion peut être 1.0.x et 1.1.x. La saisie des informations de session ( DevAddr et clés) est la même pour la multidiffusion que pour l'ABP.

resets_join_nonces peut également être défini dans JS avec 1.1.x

Diviser la création de l'appareil est absolument nécessaire et constitue un bon moyen de rapprocher le flux et la mise en œuvre des exigences du backend, tout en réduisant la complexité pour l'utilisateur.

Quelques réflexions et défis que je vois :

• Nous devrions ajouter une fonctionnalité pour interrompre l'ensemble du flux, ce qui entraînerait la suppression de toutes les entrées de registre déjà créées.
  
  
  
  • De même, passer à l'étape précédente nécessite de mettre le formulaire en "mode mise à jour" (cela devrait être relativement facile car les points de terminaison sont les mêmes, sauf pour IS)
  
  
• Un problème que je vois est que l'étape du serveur d'applications est très superficielle (cela changera-t-il probablement plus tard ?) Et l'ajout des options de format de charge utile n'est pas non plus vraiment conforme aux besoins de l'utilisateur lors de la création d'un appareil.
  
  
  
  • Une solution pourrait être de fusionner les étapes AS et JS étant donné que les deux sont assez simples et non interdépendantes. Je me rends compte que cela va à l'encontre de la séparation par composant mais je pense que cela simplifierait l'ensemble du flux avec une abstraction raisonnable. Surtout étant donné que nous ne communiquons aucune connexion aux composants de pile respectifs dans les étapes.
  
  
• Selon la configuration de la pile, nous pourrions nous retrouver avec un assistant qui ne comporte qu'une ou deux étapes, ce qui est un anti-modèle pour les assistants.
  
  
  
  • Pour le cas d'une seule étape, nous pouvons simplement masquer/supprimer l'aspect assistant
  
  
  • Pour deux étapes, je pense qu'il faut vivre avec le problème 🤷‍♂
  
  
• Il faut considérer que la solution de l'assistant augmentera un peu le _time-to-complete_ pour la user story
  
  
  
  • Cela pourrait devenir un problème dans les situations où de nombreux appareils doivent être créés à la main, bien que nous introduirions des fonctionnalités de création par lots pour ce cas d'utilisation et que la CLI/les scripts puissent également aider dans de telles situations.
  
  
  • Néanmoins, considérez la différence avec la création d'appareils de console V2 et comment les utilisateurs pourraient percevoir ce changement
  
  
• J'aime la solution "édition segmentée" correspondante pour les paramètres généraux
• Le diagramme de flux est très utile et nous devrions le tenir à jour 👍

Complexité inutile dans le sdk js pour la création/mise à jour/suppression par lots ainsi que la logique de restauration de la création

Je pense que la fonctionnalité du SDK pour diviser et fusionner les demandes d'appareils est toujours très utile, même si nous ne l'utilisons pas dans ce cas.

@johanstokking pour les appareils multicast NS n'a besoin que du SNwkSIntKey en 1.1 pour le calcul MIC. FNwkSIntKey et NwkSEncKey , en fait, ne devraient pas être autorisés à définir IMO.

• Nous devrions ajouter une fonctionnalité pour interrompre l'ensemble du flux, ce qui entraînerait la suppression de toutes les entrées de registre déjà créées.
  
  
  
  • De même, passer à l'étape précédente nécessite de mettre le formulaire en "mode mise à jour" (cela devrait être relativement facile car les points de terminaison sont les mêmes, sauf pour IS)
  
  

Je ne pense pas que nous devrions créer quoi que ce soit avant d'appuyer sur Terminer ou quelque chose du genre. Les allers-retours dans l'assistant et la fermeture de la fenêtre du navigateur ne doivent pas entraîner la création d'appareils à moitié.

• Un problème que je vois est que l'étape du serveur d'applications est très superficielle (cela changera-t-il probablement plus tard ?) Et l'ajout des options de format de charge utile n'est pas non plus vraiment conforme aux besoins de l'utilisateur lors de la création d'un appareil.

Nous ajouterons ici la configuration des packages d'application (c'est-à-dire la configuration de la multidiffusion à distance, le transfert de blocs de données fragmentées, les options de modem Semtech, etc.). Donc oui c'est peu profond maintenant mais ça va être prolongé.

• Une solution pourrait être de fusionner les étapes AS et JS étant donné que les deux sont assez simples et non interdépendantes. Je me rends compte que cela va à l'encontre de la séparation par composant mais je pense que cela simplifierait l'ensemble du flux avec une abstraction raisonnable. Surtout étant donné que nous ne communiquons aucune connexion aux composants de pile respectifs dans les étapes.

Pour notre futur moi, je recommanderais de les garder séparés. De plus, leur combinaison rend le rendu des éléments sur ces pages conditionnel à la disponibilité des composants, ce qui ajoute de la complexité à un flux déjà complexe.

• Selon la configuration de la pile, nous pourrions nous retrouver avec un assistant qui ne comporte qu'une ou deux étapes, ce qui est un anti-modèle pour les assistants.

  • Pour le cas d'une seule étape, nous pouvons simplement masquer/supprimer l'aspect assistant
  • Pour deux étapes, je pense qu'il faut vivre avec le problème 🤷‍♂

• Il faut considérer que la solution de l'assistant augmentera un peu le _time-to-complete_ pour la user story

  • Cela pourrait devenir un problème dans les situations où de nombreux appareils doivent être créés à la main, bien que nous introduirions des fonctionnalités de création par lots pour ce cas d'utilisation et que la CLI/les scripts puissent également aider dans de telles situations.
  • Néanmoins, considérez la différence avec la création d'appareils de console V2 et comment les utilisateurs pourraient percevoir ce changement

La séparation des composants et les scénarios de déploiement flexibles sont l'un des principaux changements par rapport à la V2, il est donc tout à fait logique que cela soit efficace dans la console V3.

En effet, pour créer de grandes quantités d'appareils, les utilisateurs doivent de toute façon utiliser les API et la CLI.

Il n'y a pas de scénario en une étape, c'est toujours au moins deux étapes.

Que diriez-vous d'afficher des onglets au lieu de pages ? De cette façon, c'est toujours une page mais les choses sont facilement accessibles sans aller et venir par étapes.

@johanstokking

Je ne pense pas que nous devrions créer quoi que ce soit avant d'appuyer sur Terminer ou quelque chose du genre.

Si nous faisons la demande réelle uniquement à la dernière étape, cela signifie que nous ferions 3-4 demandes. Comment gérons-nous les erreurs renvoyées par différents composants ? Gérer cela, diriger l'utilisateur vers l'étape erronée/réinitialiser le magasin/etc. est complexe. C'est pourquoi je suggère de soumettre des valeurs à chaque étape, car chaque étape successive peut s'appuyer sur les valeurs soumises comme valides.

Les allers-retours dans l'assistant et la fermeture de la fenêtre du navigateur ne doivent pas entraîner la création d'appareils à moitié.

Je suis contre le fait d'autoriser les utilisateurs à modifier les données dans l'assistant (pour les étapes qui aboutissent à la soumission). Mb, seuls les champs optionnels qui sont stockés dans un seul composant (et aucun autre composant n'en a besoin), disons name , description . Sinon la manipulation devient assez compliquée.

@kschiffer

Selon la configuration de la pile, nous pourrions nous retrouver avec un assistant qui ne comporte qu'une ou deux étapes, ce qui est un anti-modèle pour les assistants.

Eh bien, nous sommes ouverts à des solutions alternatives. Des propositions ?

Si nous faisons la demande réelle uniquement à la dernière étape, cela signifie que nous ferions 3-4 demandes. Comment gérons-nous les erreurs renvoyées par différents composants ? Gérer cela, diriger l'utilisateur vers l'étape erronée/réinitialiser le magasin/etc. est complexe. C'est pourquoi je suggère de soumettre des valeurs à chaque étape, car chaque étape successive peut s'appuyer sur les valeurs soumises comme valides.

D'ACCORD. C'est bien, tant que la console peut gérer les appareils qui sont dans ER mais qui ne peuvent pas être trouvés dans JS/NS/AS parce que cette étape a échoué ou que l'utilisateur a fermé l'onglet ou quelque chose du genre.

Je suis contre le fait d'autoriser les utilisateurs à modifier les données dans l'assistant (pour les étapes qui aboutissent à la soumission). Mb, seuls les champs optionnels qui sont stockés dans un seul composant (et aucun autre composant n'en a besoin), disons name , description . Sinon la manipulation devient assez compliquée.

Que veux-tu dire?

Notez que cet AS, par exemple, n'a pas besoin de champs, il a juste besoin que le périphérique existe. Donc, si l'AS est là, même si l'utilisateur n'entre aucune valeur pour l'AS, il doit toujours créer un appareil (vide) dans l'AS.

Que veux-tu dire?

Pardon. C'était vers la suggestion de @kschiffer :

De même, passer à l'étape précédente nécessite de mettre le formulaire en "mode mise à jour" (cela devrait être relativement facile car les points de terminaison sont les mêmes, sauf pour IS)

Les allers-retours dans l'assistant et la fermeture de la fenêtre du navigateur ne doivent pas entraîner la création d'appareils à moitié.

Je considérerais cela comme une amélioration future. Pour l'instant, nous pouvons simplement afficher une notification à l'utilisateur sur le flux inachevé. Plus tard, l'utilisateur peut modifier/supprimer l'appareil dans la page des paramètres généraux.

Eh bien, nous sommes ouverts à des solutions alternatives. Des propositions ?

Eh bien, je pense que compte tenu de la _edge-casiness_ de cette situation particulière, il est normal de vivre avec ce problème. Votre formulation suggère que je ne devrais pas formuler de préoccupations sans proposer de solutions, mais j'aime donner aux autres la possibilité d'en proposer si je ne peux pas en trouver immédiatement.

Je suis contre le fait d'autoriser les utilisateurs à modifier les données dans l'assistant (pour les étapes qui aboutissent à la soumission). Mb, seuls les champs optionnels qui sont stockés dans un seul composant (et aucun autre composant n'en a besoin), disons name , description . Sinon la manipulation devient assez compliquée.

Cela romprait à nouveau avec les meilleures pratiques pour le modèle d'assistant. Les utilisateurs voudront probablement réviser ou simplement inspecter les champs antérieurs, d'autant plus qu'ils sont interdépendants. Je suis d'accord pour ne pas inclure cette fonctionnalité au départ, mais elle devrait être ajoutée éventuellement (comme dans : suivi dans un problème).

Sinon la manipulation devient assez compliquée.

D'une manière générale, la nécessité de mettre en œuvre une logique frontale complexe ne devrait pas affecter notre engagement envers l'UX.

Je considérerais cela comme une amélioration future. Pour l'instant, nous pouvons simplement afficher une notification à l'utilisateur sur le flux inachevé. Plus tard, l'utilisateur peut modifier/supprimer l'appareil dans la page des paramètres généraux.

Pas optimal mais acceptable pour moi, tant que nous finirons par améliorer cela.

Comme discuté hors ligne, voici la proposition initiale ;

Créer un appareil

1. Réglages généraux
   
   
   
   • Des champs
     
     
     
     
     
     • ids
     
     
     
     • Facultatif name
     
     
     
     • Facultatif description
     
     
     
     • Facultatif attributes
     
     
     
     • Mode d'activation requis : OTAA, ABP ou Multicast
     
     
     
     • Si NS dans le cluster
       
       
       
       
       
       
       
       • lorawan_version
       
       
       
       
       • lorawan_phy_version
       
       
       
       
     
     
     
   
   
   • Cette étape crée le périphérique uniquement dans IS. De cette façon, nous savons que les identifiants sont gratuits
   
   
   • Le mode d'activation est utilisé dans l'état de session
   
   
   • Si ce n'est pas NS dans le cluster, pour plus de simplicité dans l'assistant, vous pouvez utiliser les versions connues les plus élevées (c'est-à-dire maintenant 1.1.0 et 1.1.0-A respectivement) dans l'état de session
   
   

2. Paramètres LoRaWAN

   • Si NS dans le cluster : Champs
     
     
     
     • lorawan_version (obligatoire)
     
     
     • lorawan_phy_version (obligatoire)
     
     
     • supports_join défini si le mode d'activation est OTAA (obligatoire)
     
     
     • multicast défini si le mode d'activation est multidiffusion
     
     
     • supports_class_b
     
     
     • supports_class_c
     
     
     • frequency_plan_id (obligatoire)
     
     
     • mac_settings.supports_32_bit_f_cnt
     
     
     • mac_settings.factory_preset_frequencies
     
     
     • mac_settings.ping_slot_data_rate_index.value
     
     
     • mac_settings.ping_slot_frequency
     
     
     • mac_settings.ping_slot_periodicity.value
     
     
     • mac_settings.rx2_data_rate_index.value
     
     
     • min_frequency
     
     
     • max_frequency
     
     
   • Si NS dans le cluster : Champs si le mode d'activation est OTAA
     
     
     
     • Case à cocher s'il faut utiliser un JS externe (coché par défaut)
     
     
   • Champs si le mode d'activation est ABP ou Multicast
     
     
     
     • Si NS ou AS dans le cluster : session.dev_addr
     
     
     • Si NS ou AS dans le cluster : générer un session.keys.session_key_id
     
     
     • Si NS dans le cluster : session.keys.f_nwk_s_int_key.key - obligatoire
     
     
     • Si NS dans le cluster : session.keys.s_nwk_s_int_key.key (si LW >= 1.1.0) - requis
     
     
     • Si NS dans le cluster : session.keys.nwk_s_enc_key.key (si LW >= 1.1.0) - requis
     
     
     • Si AS dans le cluster : session.keys.app_s_key.key - obligatoire
     
     
     • Si NS dans le cluster : session.last_conf_f_cnt_down
     
     
     • Si NS dans le cluster : session.last_n_f_cnt_down
     
     
   • Si NS dans le cluster : Champs si le mode d'activation est ABP
     
     
     
     • mac_settings.resets_f_cnt
     
     
   • Si NS ou AS en cluster : Champs si le mode d'activation est ABP
     
     
     
     • session.last_f_cnt_up - ceci est requis pour la sécurité
     
     

   • Si NS dans le cluster : Champs si le mode d'activation est ABP ou OTAA

     • mac_settings.adr_margin
     • mac_settings.class_b_timeout
     • mac_settings.class_c_timeout
     • mac_settings.desired_adr_ack_delay_exponent.value
     • mac_settings.desired_adr_ack_limit_exponent.value
     • mac_settings.desired_max_duty_cycle.value
     • mac_settings.desired_rx1_data_rate_offset
     • mac_settings.desired_rx1_delay.value
     • mac_settings.desired_rx2_data_rate_index.value
     • mac_settings.desired_rx2_frequency
     • mac_settings.max_duty_cycle.value
     • mac_settings.rx1_data_rate_offset
     • mac_settings.rx1_delay.value
     • mac_settings.status_count_periodicity
     • mac_settings.status_time_periodicity
     • mac_settings.supports_32_bit_f_cnt
     • mac_settings.use_adr

   • Cela définit le périphérique dans NS et AS (si en cluster). Si nous avons un appareil OTAA, nous n'avons rien à définir dans AS à ce stade, mais je ferais toujours appel à la cohérence

3. Si AS dans le cluster : Paramètres de l'application
   
   
   
   • Des champs
     
     
     
     
     
     • payload_formatters
     
     
     
   
   
   • Cela définit l'appareil en AS
   
   
4. Si JS en cluster et si OTAA et si pas d'utilisation de JS externe : paramètres de sécurité
   
   
   
   • Des champs
     
     
     
     
     
     • Générer root_keys.root_key_id
     
     
     
     • root_keys.app_key.key
     
     
     
     • root_keys.nwk_key.key (si LW >= 1.1.0)
     
     
     
     • resets_join_nonces
     
     
     
     • home_net_id
     
     
     
     • network_server_kek_label
     
     
     
     • application_server_kek_label
     
     
     
     • application_server_id
     
     
     
   
   
   • Cela définit l'appareil en JS
   
   

Mettre à jour l'appareil

Ici, j'opterais pour une approche par onglets, essentiellement avec des étapes d'assistant sous forme d'onglets.

La clé ici est que;

• ids , supports_join , multicast sont en lecture seule
• Le mode d'activation est évalué dans cet ordre :
  
  
  
  • OTAA : si aucun NS dans le cluster, ou si NS dans le cluster et NS indique supports_join
  
  
  • ABP : nécessite NS dans le cluster (et n'est pertinent que dans ce cas) : !supports_join && !multicast
  
  
  • Multidiffusion : nécessite NS dans le cluster (et n'est pertinent que dans ce cas) : !supports_join && multicast (bien que multicast devrait suffire)
  
  

Quelques cas d'utilisation à prendre en charge lors de la mise à jour des appareils :

• La console peut avoir NS, AS et JS dans le cluster, mais le périphérique peut ne pas être dans le NS, AS ou JS (la console obtient 404). Il s'agit d'un cas valide et la console doit gérer cela. Un exemple de cas est un appareil revendiqué, qui a l'appareil défini dans ER et JS, mais pas (encore) dans NS et AS
• S'appuyant sur le précédent : définissez les paramètres LoRaWAN et Application d'un appareil uniquement dans ER et JS (c'est-à-dire définissez-le dans NS et AS)
• Changer lorawan_version et lorawan_phy_version (cela change les contraintes)
• Modification de l'option "JS externe" ; c'est-à-dire que vous avez un appareil existant mais que vous souhaitez configurer les clés racine dans le cluster-JS. Ensuite, vous décochez cette case et l'utilisateur devrait pouvoir définir les clés racine dans l'onglet Paramètres de sécurité
• Via l'importation en bloc, l'appareil peut être créé sur JS et avoir des clés racine, mais elles ne sont pas exposées. Comme aujourd'hui, l'utilisateur devrait pouvoir voir que les clés racine sont là ( root_keys != nil ) mais elles ne sont pas exposées ( root_keys.app_key == null etc). L'utilisateur doit pouvoir laisser les clés racine intactes

Trucs généraux

• Pour les clés, un champ de saisie ou un bouton de génération aléatoire
• La différence entre JS externe et les clés racine non exposées ;
  
  
  
  • JS externe est l'endroit où le JS n'est pas dans le même cluster que le NS. Cela permet de créer un appareil OTAA sans avoir à saisir les paramètres de sécurité, car les clés sont configurées ailleurs
  
  
  • Les clés racine non exposées correspondent à l'emplacement de l'appareil dans le JS local du cluster, mais le JS n'expose pas les clés racine. C'est pour la sécurité, c'est-à-dire en cas d'éléments sécurisés, où JS a accès aux clés racine mais ne les expose pas
  
  

Je pense que https://github.com/TheThingsNetwork/lorawan-stack/issues/579#issuecomment -525719408 contient déjà tout le nécessaire pour NS.
Je pense que tous les mac_settings devraient être disponibles pour être définis pour tous les appareils non multicast.
Pour les appareils multicast, seuls les éléments suivants ont un sens :

• "mac_settings.factory_preset_frequencies"
• "mac_settings.ping_slot_data_rate_index.value"
• "mac_settings.ping_slot_frequency"
• "mac_settings.ping_slot_periodicity.value"
• "mac_settings.rx2_data_rate_index.value"
• "mac_settings.rx2_frequency"

Peut-être des choses à clarifier

Créer:

1. réglages généraux
   une. Lorsque nous créons l'appareil dans l'urgence, nous ne définissons pas les adresses NS/AS/JS. Mettons-nous à jour l'enregistrement ER lorsque l'appareil est défini dans ceux-ci ? Et si nous utilisions un JS externe ?
   b. Stockons-nous le mode d'activation dans les urgences ?
   c. Conservons-nous les versions phy/mac dans l'urgence ?
2. Paramètres LoRaWAN
   une. Que diriez-vous supports_class_b ?
3. Paramètres de l'application
   une. Oui, cela pourrait signifier que nous avons mis l'appareil sur l'AS deux fois

Mettre à jour:

• Mode d'activation : ce serait beaucoup plus facile si nous le stockions dans ER
• Regardons-nous uniquement les adresses 404 ou également les adresses NS/AS/JS dans les urgences ?
• Je pense que ce serait bien de pouvoir supprimer un enregistrement NS/AS/JS individuel, par exemple lors du changement de "JS externe" en true , ou de réinitialiser l'état de l'appareil dans le NS

Trucs généraux :

• _"External JS est l'endroit où le JS n'est pas dans le même cluster que le NS"_ : je pense que cela devrait être quelque chose comme "join_server_address n'est pas la même que l'adresse JS dans la configuration de la console"

Si nous parlons de champs de niveau supérieur :
https://github.com/TheThingsNetwork/lorawan-stack/blob/375c82cc068bbadb72b887e25631f8f2dc03a366/api/end_device.proto#L395 -L418 tout ce morceau appartient à NS (mais tous ne sont pas obligatoires)

m{in,ax}_frequency ne s'applique pas à la multidiffusion

@rvolosatovs

Je pense que #579 (commentaire) contient déjà tout le nécessaire pour NS.

Je pense que tous les mac_settings devraient être disponibles pour être définis pour tous les appareils non multicast.
Pour les appareils multicast, seuls les éléments suivants ont un sens :

L'un des problèmes avec ce problème est la quantité d'informations enfouies dans les commentaires.

Pouvez-vous ajouter _exactement_ les champs aux bons endroits ? Je suis d'accord si vous copiez toute ma liste de points afin que nous travaillions progressivement dessus jusqu'à ce que nous ayons une version finale.

@htdvisser

1. réglages généraux
   une. Lorsque nous créons l'appareil dans l'urgence, nous ne définissons pas les adresses NS/AS/JS. Mettons-nous à jour l'enregistrement ER lorsque l'appareil est défini dans ceux-ci ? Et si nous utilisions un JS externe ?

Je pense que nous devrions mettre à jour les adresses lorsque nous définissons les appareils dans AS/NS/JS.

b. Stockons-nous le mode d'activation dans les urgences ?

Non, nous n'avons pas de champ pour cela pour le moment, nous n'en avons pas vraiment besoin et cela crée de la place pour des incohérences.

c. Conservons-nous les versions phy/mac dans l'urgence ?

Non, consultez la documentation de l'API. Encore une fois, je n'en vois pas la nécessité et cela crée de la place pour des incohérences.

une. Que diriez-vous supports_class_b ?

Ouais, je suppose que nous devrions ajouter cela, en attendant #19. @rvolosatovs , veuillez l'inclure dans une version mise à jour, le cas échéant.

1. Paramètres de l'application
   une. Oui, cela pourrait signifier que nous avons mis l'appareil sur l'AS deux fois

Oui, ça ne fait pas de mal

Mettre à jour:

• Mode d'activation : ce serait beaucoup plus facile si nous le stockions dans ER

Oui, mais je ne sais pas si nous devrions opter pour la facilité et si cela s'applique pleinement. Nous devons l'avoir disponible dans le chemin chaud.

De plus, ce ne serait facile que si nous pouvions repartir de zéro. Cependant, nous devons être compatibles en amont, en ajoutant des heuristiques lorsque lorawan_version n'est pas dans ER, en introduisant des obtentions conditionnelles à partir de NS, etc.

• Regardons-nous uniquement les adresses 404 ou également les adresses NS/AS/JS dans les urgences ?

Nous ne pouvons obtenir un 404 que s'il y a une adresse définie, sinon il n'y a rien à obtenir. Nous devrions interpréter les deux comme "pas dans ce registre". Nous ne pouvons pas nous tromper ici (comme nous l'avons fait auparavant), précisément pour la raison que la création dans IS et AS/NS/JS ne se produit pas en même temps, et les utilisateurs devraient pouvoir récupérer les incohérences créées par la console.

• Je pense que ce serait bien de pouvoir supprimer un enregistrement NS/AS/JS individuel, par exemple lors du changement de "JS externe" en true , ou de réinitialiser l'état de l'appareil dans le NS

Oui, faisons ça plus tard

• _"External JS est l'endroit où le JS n'est pas dans le même cluster que le NS"_ : je pense que cela devrait être quelque chose comme "join_server_address n'est pas la même que l'adresse JS dans la configuration de la console"

Oui, c'est bien le moyen de le vérifier. join_server_address peut aussi être vide, en utilisant l'interopérabilité.

@bafonins avez-vous toujours la source du graphique ?
Étant donné qu'il a déjà fallu beaucoup de travail pour le construire, je pense que nous devrions simplement le mettre à jour pour le rendre complet afin d'avoir une représentation claire ?
Nous pouvons également travailler sur la mise à jour de la partie NS hors ligne pour ne pas encombrer la discussion ici.

J'ai mis à jour le graphique avec tous les champs NS possibles
Les champs en rouge sont obligatoires

@rvolosatovs, nous visons à définir le flux et les champs que nous présentons dans la console lors de la création et de la mise à jour des appareils.

En tant que tel,

• Nous ne devrions pas autoriser le changement mac_state.lorawan_version
• Nous pouvons faire mac_state.ping_slot_periodicity via CLI pour l'instant
• Veuillez penser à la façon dont l'utilisateur va définir supports_class_b , supports_class_c et mac_state.device_class ; qui fait partie de la création, qui fait partie de la mise à jour, comment les uns sont-ils liés les uns aux autres ?
• Nous ne devrions pas changer les compteurs individuels ; un bouton "réinitialiser les compteurs de trames" ferait l'affaire (ce qui, autant que je sache, peut être une action distincte, comme nous l'avons dans la console V2, qui définit les compteurs sur 0 )
• Nous devons sélectionner avec soin les paramètres que nous voulons dans la console de mac_settings et mac_state.desired_parameters ; @htdvisser pouvez-vous réfléchir ici ?

J'ai changé l'ordre dans https://github.com/TheThingsNetwork/lorawan-stack/issues/579#issuecomment -553347858. Veuillez travailler progressivement sur cette liste.

Pouvez-vous s'il vous plaît ajouter exactement les champs aux bons endroits ?

J'ai répondu à cette question - c'est-à-dire que j'ai présenté tous les champs, qui peuvent être définis et doivent être définis sur NS. Ou du moins c'est ainsi que j'ai compris votre question.

En ce qui concerne ce qui devrait être dans la console, tout mac_state ne devrait probablement être paramétrable que via CLI, cependant nous pouvons exiger cela pour les appareils ABP/multicast et/ou les appareils OTAA, qui sont enregistrés avec une session existante, et, d'où l'état MAC.
Je mettrai à jour votre commentaire.

Nous ne devrions pas changer les compteurs individuels ; un bouton "réinitialiser les compteurs de trames" ferait l'affaire (ce qui, autant que je sache, peut être une action distincte, comme nous l'avons dans la console V2, qui met les compteurs à 0)

Nous devons être en mesure de définir des compteurs de trames de liaison descendante pour ABP et multidiffusion - sinon NS ne peut pas envoyer de liaisons descendantes
Pour la liaison montante, les compteurs de trames sont également très utiles du point de vue de la sécurité pour ABP

Mettre à jour l'appareil

Ici, j'opterais pour une approche par onglets, essentiellement avec des étapes d'assistant sous forme d'onglets.

Utilisons ici l'approche accordéon, telle que présentée dans le premier commentaire de @bafonins :

Cela nous donnera moins de problèmes avec l'espace horizontal et permet de distinguer les modes avec les boutons Edit / Create .

@rvolosatovs

Nous devons être en mesure de définir des compteurs de trames de liaison descendante pour ABP et multidiffusion - sinon NS ne peut pas envoyer de liaisons descendantes
Pour la liaison montante, les compteurs de trames sont également très utiles du point de vue de la sécurité pour ABP

Si c'est simple, nous pouvons le faire. En fait, deux/trois champs de saisie peuvent être plus simples qu'un bouton de réinitialisation qui déclenche une action spécifique.

En ce qui concerne ce qui devrait être dans la console, tout mac_state ne devrait probablement être paramétrable que via CLI, cependant nous pouvons exiger cela pour les appareils ABP/multicast et/ou les appareils OTAA, qui sont enregistrés avec une session existante, et, d'où l'état MAC.

Je comprends. Je pense que nous devrions séparer "les appareils ABP nouveaux et réinitialisés" des "appareils ABP existants qui ont déjà été sur un réseau".

Le premier devrait être complet, il devrait donc inclure quelques mac_state (c'est-à-dire les fréquences de réinitialisation d'usine, le délai RX1, les paramètres RX2, etc.) mais pas mac_state.desired_parameters .

Ce dernier doit être effectué via la migration et nous pouvons ajouter les paramètres de réglage fin plus tard dans la console ; pour l'instant CLI doit être utilisé.

Merci pour la mise à jour

Paramètres LoRaWAN

• Si NS dans le cluster : Champs
  
  
  
  • mac_settings.factory_preset_frequencies
  
  
  • mac_settings.ping_slot_data_rate_index.value
  
  
  • mac_settings.ping_slot_frequency
  
  
  • mac_settings.ping_slot_periodicity.value
  
  
  • mac_settings.rx2_data_rate_index.value
  
  

Sont-ils nécessaires pour OTAA ? N'est-ce pas uniquement pour ABP et Multicast ?

@johanstokking

Paramètres LoRaWAN

• Si NS dans le cluster : Champs
  
  
  
  • mac_settings.factory_preset_frequencies
  
  
  • mac_settings.ping_slot_data_rate_index.value
  
  
  • mac_settings.ping_slot_frequency
  
  
  • mac_settings.ping_slot_periodicity.value
  
  
  • mac_settings.rx2_data_rate_index.value
  
  

Sont-ils nécessaires pour OTAA ? N'est-ce pas uniquement pour ABP et Multicast ?

Tous les paramètres MAC sont facultatifs par conception.
Le seul cas où ceux-ci sont "obligatoires" sont les appareils de multidiffusion de classe B, c'est-à-dire en raison des spécificités de fonctionnement de la classe B.
En dehors de cela, factory_preset_frequencies est susceptible d'être requis pour l'ABP pour de meilleurs résultats, mais rien n'empêche l'appareil OTAA d'avoir cet ensemble.

Tous les paramètres MAC sont facultatifs par conception.
Le seul cas où ceux-ci sont "obligatoires" sont les appareils de multidiffusion de classe B, c'est-à-dire en raison des spécificités de fonctionnement de la classe B.

d'accord

En dehors de cela, factory_preset_frequencies est susceptible d'être requis pour ABP pour de meilleurs résultats, mais rien n'empêche l'appareil OTAA d'avoir cet ensemble.

C'est inefficace pour OTAA; les fréquences de jointure par défaut sont requises par la spécification, et les canaux arrivent via les commandes join-accept et MAC. Il ne devrait pas y avoir de configuration hors bande des fréquences préréglées pour les appareils OTAA.

@bafonins pouvez-vous donner une mise à jour de l'état et un calendrier sur ce problème ?

Pour app_s_key et skip_payload_crypto , voici le truc ;

• AS respecte le champ skip_payload_crypto du terminal. Si true , AS n'effectue pas le chiffrement et le déchiffrement de la charge utile
  
  
  
  • AS obtiendra également un skip_payload_crypto au niveau de l'application (via Link, comme les formateurs de charge utile), qui a priorité sur le paramètre de l'appareil final
  
  
• Il y a probablement toujours un app_s_key dans AS, mais il peut être encapsulé, c'est-à-dire session.keys.app_s_key.key n'est pas défini (mais encrypted_key et kek_label sont définis)
  
  
  
  • Lorsque AS n'a pas la KEK, c'est-à-dire qu'il ne peut pas déballer la clé chiffrée. Maintenant, ces erreurs. Nous renverrons probablement simplement le app_s_key crypté tel quel aux clients
  
  
• Dans la console, si skip_payload_crypto est défini sur true (sur l'appareil final ou le lien d'application), ne vous embêtez pas avec app_s_key : désactivez-le, ne vous en souciez pas