Lorawan-stack: Verwenden Sie einen Assistenten zum Anlegen von Endgeräten

Das Hauptproblem bei der aktuellen Implementierung der Geräteform besteht darin, dass alles miteinander gekoppelt ist. Dies bewirkt

1. Komplexes und langes Validierungsschema
2. Keine einfache Möglichkeit, bestimmte Felder basierend auf der Stack-Konfiguration zu deaktivieren
3. Keine einfache Möglichkeit, die Formularfelder/Feldtitel gemäß den ausgewählten Werten zu ändern
4. Unnötige Komplexität im js-SDK für Batch-Erstellung/Aktualisierung/Löschung sowie Erstellungs-Rollback-Logik

Ich schlage vor, das Geräteformular als mehrstufiges Formular zu implementieren. Das kann etwa so aussehen:

Ein solcher Ansatz adressiert alle oben genannten Probleme:

1. Statt eines komplexen Schemas definieren wir für jeden Schritt ein kleines.
2. Deaktivieren Sie einfach den gesamten Schritt, wenn eine bestimmte verantwortliche Komponente nicht im Stack verfügbar ist. Darüber hinaus können wir den Nutzer per Beschreibung/Benachrichtigung darüber informieren.
3. Passen Sie jeden Schritt in Abhängigkeit von den zuvor übermittelten Werten an. Ändern Sie beispielsweise die Bezeichnung Join EUI in App EUI für die Lorawan-Version 1.0.x .
4. Batch-Anfragen sind nicht erforderlich. Der Benutzer wird für die Erstellung von Geräten in verschiedenen Komponenten verantwortlich. Wir möchten jedoch möglicherweise die Stapellöschung der Einfachheit halber beibehalten.

Bearbeitungsgeräte können als Stapel von Ziehharmonikas implementiert werden:

Wo jedes Akkordeon mit einer eigenständigen Form erweitert wird.

Neben dem Geräteformular können wir auch den Assistenten für das Antragsformular verwenden, um:

1. Erstellen Sie die Anwendung im is
2. Verknüpfen Sie die Anwendung mit als

cc @kschiffer @johanstokking @htdvisser

Klingt für mich gut, besonders wenn wir Felder für Komponenten in einem Schritt zusammenfassen können. Auf diese Weise können wir Schritte einfach überspringen/deaktivieren, wenn eine Komponente nicht verfügbar ist.

Verweist auch auf https://github.com/TheThingsNetwork/lorawan-stack/issues/1234 ; selbst wenn JS verfügbar ist, kann der Benutzer die JS-Felder überspringen.

Ich habe mir ein solches Diagramm ausgedacht:

Jeder Knoten ist ein Schritt

• Schritte mit gepunkteter Umrandung übermitteln das Formular nicht, sondern behalten es für die nächsten Schritte im lokalen Status.
• Andere senden bei der Übermittlung Anfragen an den Server.

Es sieht kompliziert aus, aber die aktuelle Implementierung hat einen noch größeren Zustandsraum in Bezug auf Validierung / Einreichung / Feldmaskengenerierung / etc.

Betrachten Sie das Diagramm als ersten Vorschlag, um die Diskussion zu beginnen.

Ich denke, das ist ein guter Anfang.

• Vielleicht wäre der Fluss besser, wenn der Join-Server zuerst käme.
• Eine wichtige Sache, bei der wir noch nicht wirklich vorangekommen sind, ist das Vorbefüllen von Feldern aus Gerätevorlagen im Geräte-Repository #263. Ich denke, das könnte den Prozess für Produktionsbereitstellungen wirklich vereinfachen.

Und ein paar Kleinigkeiten:

• A DevEUI ist für ABP-Geräte nicht verboten (kann optional gesetzt werden)
• LoRaWAN 1.0.x-Geräte haben kein NwkKey , sondern nur ein AppKey
• FNwkSIntKey heißt NwkSKey (zum Benutzer hin)
• Der Anwendungsserver erhält nicht die NwkKey oder AppKey

Ja, toller Anfang.

• Vielleicht wäre der Fluss besser, wenn der Join-Server zuerst käme.

Ich stimme dem zu. Wenn der Aktivierungsmodus OTAA ist und das Cluster-JS aktiviert ist, haben Benutzer auf der JS-Seite die Möglichkeit, Stammschlüssel einzugeben und sie auf dem Cluster-JS zu speichern. (Wenn sie das deaktivieren, verwendet NS die JS-Suche, genau wie wenn kein JS im Cluster aktiviert ist)

• "Aktivierungsmodus" befindet sich in der Nutzlast - in Ihrem Diagramm entspricht er tatsächlich 2 Feldern - multicast bool und supports_join bool . Es gibt 3 mögliche Optionen, da multicast && supports_join nicht gültig ist.
• frequency_plan -> frequency_plan_id

• resets_f_cnt ist optional, standardmäßig false .

• FNwkSIntKey sollte nur für <1.1 als NwkKey dargestellt werden

• FNwkSIntKey fehlt in den ABP NS-Einstellungen für >= 1.1
• multicast -Geräte benötigen nur AppSKey - NS benötigt keine Schlüssel, damit multicast -Geräte funktionieren, nur AS

@htdvisser

Vielleicht wäre der Fluss besser, wenn der Join-Server zuerst käme.

Warum?

Eine wichtige Sache, bei der wir noch nicht wirklich vorangekommen sind, ist das Vorbefüllen von Feldern aus Gerätevorlagen im Geräte-Repository #263. Ich denke, das könnte den Prozess für Produktionsbereitstellungen wirklich vereinfachen.

Für mich scheint es außerhalb des Rahmens dieses Problems zu liegen

Ein DevEUI ist für ABP-Geräte nicht verboten (kann optional gesetzt werden)

Wollen wir es auch für ABP-Geräte einstellen? Ich würde sagen, je weniger Felder wir haben, desto besser. Es ist jedoch erforderlich, dass wir es hinzufügen können.

FNwkSIntKey heißt NwkSKey (zum Benutzer hin)

Das Label sollte also sowohl für 1.0.x als auch für 1.1.x NwkSKey lauten? Folgendes haben wir in der Konsole:

• LoRaWAN 1.0.x-Geräte haben keinen NwkKey, nur einen AppKey
• Der Anwendungsserver erhält den NwkKey oder AppKey nicht

Behoben 👌

@johanstokking

Wenn der Aktivierungsmodus OTAA ist und das Cluster-JS aktiviert ist, haben Benutzer auf der JS-Seite die Möglichkeit, Stammschlüssel einzugeben und sie auf dem Cluster-JS zu speichern. (Wenn sie das deaktivieren, verwendet NS die JS-Suche, genau wie wenn kein JS im Cluster aktiviert ist).

Es geht also nur darum, Benutzern zu erlauben, den Anmeldeschritt für den Serverbeitritt zu überspringen? Überhaupt keine Anfragen an js?

Könnten Sie in Bezug auf https://github.com/TheThingsNetwork/lorawan-stack/issues/1134 auch angeben, wo diese Felder im Diagramm hingehören?

@rvolosatovs

Activation mode" ist in Payload - in Ihrem Diagramm entspricht es tatsächlich 2 Feldern - multicast bool und supports_join bool. Es gibt 3 mögliche Optionen, da Multicast && supports_join nicht gültig ist.

Nur um klarzustellen:

1. supports_join=true - OTAA
2. supports_join=false - ABP
3. multicast=true && **no** supports_join - Multicast
   Ist das richtig?

resets_f_cnt ist optional, standardmäßig falsch.

Ich denke, es ist immer noch in Ordnung, es den Benutzern zu zeigen. Sollte es den Benutzern gestatten, es für Multicast-Geräte einzustellen?

FNwkSIntKey sollte nur für <1.1 als NwkKey dargestellt werden

Du meinst NwkSKey ?

frequency_plan -> frequency_plan_id
FNwkSIntKey fehlt in den ABP NS-Einstellungen für >= 1.1

Behoben 👌

Aktualisiertes Diagramm:

@htdvisser

Vielleicht wäre der Fluss besser, wenn der Join-Server zuerst käme.

Warum?

Ja, ich komme darauf zurück; Ich denke, es ist sinnvoller, MAC-Versionen einzugeben, bevor Sie Schlüssel eingeben. Also unterstütze ich den Stromfluss. Wenn die MAC-Version eingegeben wird (wenn NS aktiviert ist), müssen wir nicht nach NwkKey fragen, da dies 1.1.x ist.

Eine wichtige Sache, bei der wir noch nicht wirklich vorangekommen sind, ist das Vorbefüllen von Feldern aus Gerätevorlagen im Geräte-Repository #263. Ich denke, das könnte den Prozess für Produktionsbereitstellungen wirklich vereinfachen.

Für mich scheint es außerhalb des Rahmens dieses Problems zu liegen

Es ist in der Tat außerhalb des Geltungsbereichs.

Ein DevEUI ist für ABP-Geräte nicht verboten (kann optional gesetzt werden)

Wollen wir es auch für ABP-Geräte einstellen? Ich würde sagen, je weniger Felder wir haben, desto besser. Es ist jedoch erforderlich, dass wir es hinzufügen können.

Ja, wir möchten optional danach fragen. Je mehr Identifizierungsinformationen wir über Endgeräte haben, desto besser. Es ist auch beim zustandsbehafteten passiven Roaming erforderlich. Der Grund, warum wir Benutzer nicht zwingen, die DevEUI einzugeben, liegt darin, dass wir nicht möchten, dass Benutzer falsche Werte eingeben, wenn keine DevEUI vorhanden ist.

FNwkSIntKey heißt NwkSKey (zum Benutzer hin)

Das Label sollte also sowohl für 1.0.x als auch für 1.1.x NwkSKey lauten? Folgendes haben wir in der Konsole:

Es ist NwkSKey für 1.0.x und FNwkSIntKey für 1.1.x.

Wenn der Aktivierungsmodus OTAA ist und das Cluster-JS aktiviert ist, haben Benutzer auf der JS-Seite die Möglichkeit, Stammschlüssel einzugeben und sie auf dem Cluster-JS zu speichern. (Wenn sie das deaktivieren, verwendet NS die JS-Suche, genau wie wenn kein JS im Cluster aktiviert ist).

Es geht also nur darum, Benutzern zu erlauben, den Anmeldeschritt für den Serverbeitritt zu überspringen? Überhaupt keine Anfragen an js?

In der Tat.

Ein Beispiel ist ein Gerät mit Semtech-Modem, das den Semtech Join Server verwendet. Wir müssen in diesem Fall nur EUIs kennen.

Könnten Sie in Bezug auf #1134 auch angeben, wo diese Felder im Diagramm hingehören?

Sie gehören in den JS-Schritt; Diese Felder gehen in JS, wenn JS im Cluster aktiviert ist und der Benutzer die Geräte auf JS bereitstellen möchte.

Diese Felder sind optional.

Nur um klarzustellen:

1. supports_join=true - OTAA
2. supports_join=false - ABP
3. multicast=true && **no** supports_join - Multicast
   Ist das richtig?

Streng:

1. OTAA: supports_join
2. ABP: !supports_join && !multicast
3. Multicast: multicast

Ungültig ist supports_join && multicast , aber dies wird (oder sollte) bei NS validiert werden.

resets_f_cnt ist optional, standardmäßig falsch.

Ich denke, es ist immer noch in Ordnung, es den Benutzern zu zeigen. Sollte es den Benutzern gestatten, es für Multicast-Geräte einzustellen?

Nein, das ist nicht für Multicast. resets_f_cnt bezieht sich auf Uplink, aber es gibt keinen Uplink in Multicast.

FNwkSIntKey sollte nur für <1.1 als NwkKey dargestellt werden

Du meinst NwkSKey ?

Sollte in der Tat NwkSKey sein.

@bafonins siehe bitte die Antwort von @johanstokking .
In Bezug auf multicast ist auch die Geräteadresse erforderlich

• Felder von https://github.com/TheThingsNetwork/lorawan-stack/issues/1134 hinzugefügt
• DevEUI zu abp/multicast-Geräten hinzugefügt
• Device Address zu Multicast-Geräten hinzugefügt
  

Die Geräteadresse fehlt noch in den Netzwerkservereinstellungen des multicast -Geräts

Die Geräteadresse fehlt immer noch in den Netzwerkservereinstellungen des Multicast-Geräts

Aktualisiert 👌

Multicast kann 1.0.x und 1.1.x sein. Die Eingabe der Sitzungsinformationen ( DevAddr und Schlüssel) ist für Multicast dieselbe wie für ABP.

Auch resets_join_nonces kann in JS mit 1.1.x gesetzt werden

Die Aufteilung der Geräteerstellung ist definitiv erforderlich und eine gute Möglichkeit, den Ablauf und die Implementierung näher an die Anforderungen des Backends zu bringen und gleichzeitig die Komplexität für den Benutzer zu reduzieren.

Einige Gedanken und Herausforderungen, die ich sehe:

• Wir sollten Funktionen hinzufügen, um den gesamten Ablauf abzubrechen, was zu einer Löschung aller bereits erstellten Registrierungseinträge führt.
  
  
  
  • Ebenso muss das Formular beim Wechseln zum vorherigen Schritt in den „Aktualisierungsmodus“ versetzt werden (sollte relativ einfach sein, da die Endpunkte dieselben sind, mit Ausnahme von IS).
  
  
• Ein Problem, das ich sehe, ist, dass der Application Server-Schritt sehr flach ist (wird sich das wahrscheinlich später ändern?) und das Hinzufügen der Payload-Formatoptionen dort auch nicht wirklich den Anforderungen des Benutzers beim Erstellen eines Geräts entspricht.
  
  
  
  • Eine Lösung könnte darin bestehen, den AS- und den JS-Schritt zusammenzuführen, da beide ziemlich einfach und nicht voneinander abhängig sind. Mir ist klar, dass dies gegen die Trennung nach Komponenten verstößt, aber ich denke, dies würde den gesamten Fluss mit einer vernünftigen Abstraktion vereinfachen. Zumal wir innerhalb der Schritte keine Verbindung zu den jeweiligen Stack-Komponenten kommunizieren.
  
  
• Abhängig von der Stack-Konfiguration erhalten wir möglicherweise einen Assistenten, der nur einen oder zwei Schritte hat, was ein Anti-Pattern für Assistenten ist.
  
  
  
  • Für den Fall von nur einem Schritt können wir den Assistentenaspekt einfach ausblenden/entfernen
  
  
  • Bei zwei Schritten müssen wir glaube ich mit dem Thema leben 🤷‍♂
  
  
• Es sollte berücksichtigt werden, dass die Assistentenlösung die _Zeit bis zur Fertigstellung_ für die User Story ziemlich verlängert
  
  
  
  • Dies könnte in Situationen zu einem Problem werden, in denen viele Geräte von Hand erstellt werden müssen, obwohl wir für diesen Anwendungsfall Stapelerstellungsfunktionen einführen werden und die CLI/Skripterstellung auch in solchen Situationen hilfreich sein kann
  
  
  • Berücksichtigen Sie dennoch den Unterschied zur V2-Konsolengeräteerstellung und wie Benutzer diese Änderung wahrnehmen könnten
  
  
• Ich mag die entsprechende "segmented edit"-Lösung für allgemeine Einstellungen
• Das Flussdiagramm ist sehr hilfreich und wir sollten es aktuell halten 👍

Unnötige Komplexität im js-SDK für Batch-Erstellung/Aktualisierung/Löschung sowie Erstellungs-Rollback-Logik

Ich denke, die Funktionalität im SDK zum Aufteilen und Zusammenführen von Geräteanforderungen ist immer noch ziemlich wertvoll, auch wenn wir sie in diesem Fall nicht verwenden

@johanstokking für Multicast-Geräte benötigt NS nur die SNwkSIntKey in 1.1 für die MIC-Berechnung. FNwkSIntKey und NwkSEncKey sollten eigentlich nicht erlaubt sein, IMO zu setzen.

• Wir sollten Funktionen hinzufügen, um den gesamten Ablauf abzubrechen, was zu einer Löschung aller bereits erstellten Registrierungseinträge führt.
  
  
  
  • Ebenso muss das Formular beim Wechseln zum vorherigen Schritt in den „Aktualisierungsmodus“ versetzt werden (sollte relativ einfach sein, da die Endpunkte dieselben sind, mit Ausnahme von IS).
  
  

Ich denke nicht, dass wir irgendetwas erschaffen sollten, bevor wir Finish oder so etwas erreichen. Das Hin- und Hergehen im Assistenten und das Schließen des Browserfensters sollte nicht zu halb erstellten Geräten führen.

• Ein Problem, das ich sehe, ist, dass der Application Server-Schritt sehr flach ist (wird sich das wahrscheinlich später ändern?) und das Hinzufügen der Payload-Formatoptionen dort auch nicht wirklich den Anforderungen des Benutzers beim Erstellen eines Geräts entspricht.

Wir werden hier Konfigurationen für Anwendungspakete hinzufügen (dh Remote-Multicast-Setup, fragmentierte Datenblockübertragung, Semtech-Modemoptionen usw.). Also ja, es ist jetzt flach, aber es wird erweitert.

• Eine Lösung könnte darin bestehen, den AS- und den JS-Schritt zusammenzuführen, da beide ziemlich einfach und nicht voneinander abhängig sind. Mir ist klar, dass dies gegen die Trennung nach Komponenten verstößt, aber ich denke, dies würde den gesamten Fluss mit einer vernünftigen Abstraktion vereinfachen. Zumal wir innerhalb der Schritte keine Verbindung zu den jeweiligen Stack-Komponenten kommunizieren.

Für unser zukünftiges Selbst würde ich empfehlen, sie getrennt zu halten. Auch ihre Kombination macht das Rendern von Inhalten auf diesen Seiten von der Verfügbarkeit der Komponenten abhängig, was einen ohnehin schon komplexen Ablauf noch komplexer macht.

• Abhängig von der Stack-Konfiguration erhalten wir möglicherweise einen Assistenten, der nur einen oder zwei Schritte hat, was ein Anti-Pattern für Assistenten ist.

  • Für den Fall von nur einem Schritt können wir den Assistentenaspekt einfach ausblenden/entfernen
  • Bei zwei Schritten müssen wir glaube ich mit dem Thema leben 🤷‍♂

• Es sollte berücksichtigt werden, dass die Assistentenlösung die _Zeit bis zur Fertigstellung_ für die User Story ziemlich verlängert

  • Dies könnte in Situationen zu einem Problem werden, in denen viele Geräte von Hand erstellt werden müssen, obwohl wir für diesen Anwendungsfall Stapelerstellungsfunktionen einführen werden und die CLI/Skripterstellung auch in solchen Situationen hilfreich sein kann
  • Berücksichtigen Sie dennoch den Unterschied zur V2-Konsolengeräteerstellung und wie Benutzer diese Änderung wahrnehmen könnten

Die Trennung der Komponenten und die flexiblen Bereitstellungsszenarien ist eine der wichtigsten Änderungen im Vergleich zu V2, daher ist es absolut sinnvoll, dass dies in der V3-Konsole wirksam ist.

In der Tat sollten Benutzer zum Erstellen großer Mengen von Geräten sowieso APIs und CLI verwenden.

Es gibt kein Szenario mit einem Schritt, es sind immer mindestens zwei Schritte.

Wie wäre es mit dem Rendern von Registerkarten anstelle von Seiten? Auf diese Weise ist es immer noch eine Seite, aber die Dinge sind leicht zugänglich, ohne in Schritten hin und her zu gehen.

@johanstokking

Ich denke nicht, dass wir irgendetwas erschaffen sollten, bevor wir Finish oder so etwas erreichen.

Wenn wir die eigentliche Anfrage erst im letzten Schritt stellen, bedeutet dies, dass wir 3-4 Anfragen stellen würden. Wie gehen wir mit Fehlern um, die von verschiedenen Komponenten zurückgegeben werden? Behandeln Sie dies, navigieren Sie den Benutzer zum fehlerhaften Schritt / setzen Sie den Speicher zurück / etc. ist komplex. Aus diesem Grund schlage ich vor, bei jedem Schritt Werte einzureichen, da sich jeder nachfolgende Schritt darauf verlassen kann, dass die eingereichten Werte gültig sind.

Das Hin- und Hergehen im Assistenten und das Schließen des Browserfensters sollte nicht zu halb erstellten Geräten führen.

Ich bin dagegen, dass Benutzer Daten im Assistenten bearbeiten dürfen (für die Schritte, die zur Übermittlung führen). Mb, nur optionale Felder, die in einer einzigen Komponente gespeichert sind (und keine anderen Komponenten benötigen diese), sagen wir name , description . Andernfalls wird die Handhabung ziemlich kompliziert.

@kschiffer

Abhängig von der Stack-Konfiguration erhalten wir möglicherweise einen Assistenten, der nur einen oder zwei Schritte hat, was ein Anti-Pattern für Assistenten ist.

Nun, wir sind offen für alternative Lösungen. Irgendwelche Vorschläge?

Wenn wir die eigentliche Anfrage erst im letzten Schritt stellen, bedeutet dies, dass wir 3-4 Anfragen stellen würden. Wie gehen wir mit Fehlern um, die von verschiedenen Komponenten zurückgegeben werden? Behandeln Sie dies, navigieren Sie den Benutzer zum fehlerhaften Schritt / setzen Sie den Speicher zurück / etc. ist komplex. Aus diesem Grund schlage ich vor, bei jedem Schritt Werte einzureichen, da sich jeder nachfolgende Schritt darauf verlassen kann, dass die eingereichten Werte gültig sind.

OK. Das ist in Ordnung, solange die Konsole Geräte verarbeiten kann, die sich in ER befinden, aber nicht in JS/NS/AS gefunden werden können, weil dieser Schritt fehlgeschlagen ist oder der Benutzer die Registerkarte geschlossen hat oder so.

Ich bin dagegen, dass Benutzer Daten im Assistenten bearbeiten dürfen (für die Schritte, die zur Übermittlung führen). Mb, nur optionale Felder, die in einer einzigen Komponente gespeichert sind (und keine anderen Komponenten benötigen diese), sagen wir name , description . Andernfalls wird die Handhabung ziemlich kompliziert.

Was meinen Sie?

Beachten Sie, dass AS zum Beispiel keine Felder benötigt, es muss nur das Gerät existieren. Wenn also der AS vorhanden ist, sollte der Benutzer, selbst wenn der Benutzer keine Werte für AS eingibt, dennoch ein (leeres) Gerät in AS erstellen.

Was meinen Sie?

Es tut uns leid. Dies war ein Vorschlag von @kschiffer :

Ebenso muss das Formular beim Wechseln zum vorherigen Schritt in den „Aktualisierungsmodus“ versetzt werden (sollte relativ einfach sein, da die Endpunkte dieselben sind, mit Ausnahme von IS).

Das Hin- und Hergehen im Assistenten und das Schließen des Browserfensters sollte nicht zu halb erstellten Geräten führen.

Ich würde dies als zukünftige Verbesserung betrachten. Im Moment können wir dem Benutzer nur eine Benachrichtigung über einen nicht abgeschlossenen Flow anzeigen. Später kann der Benutzer das Gerät auf der Seite mit den allgemeinen Einstellungen bearbeiten/löschen.

Nun, wir sind offen für alternative Lösungen. Irgendwelche Vorschläge?

Nun, ich denke, dass es in Anbetracht der _Edge-Casiness_ dieser besonderen Situation in Ordnung ist, mit diesem Problem zu leben. Ihre Formulierung legt nahe, dass ich Bedenken nicht ohne Lösungsvorschläge äußern sollte, aber ich gebe anderen gerne die Möglichkeit, einige zu finden, wenn ich nicht sofort welche finde.

Ich bin dagegen, dass Benutzer Daten im Assistenten bearbeiten dürfen (für die Schritte, die zur Übermittlung führen). Mb, nur optionale Felder, die in einer einzigen Komponente gespeichert sind (und keine anderen Komponenten benötigen diese), sagen wir name , description . Andernfalls wird die Handhabung ziemlich kompliziert.

Dies würde wiederum mit den Best Practices für das Assistentenmuster brechen. Benutzer werden wahrscheinlich frühere Felder überarbeiten oder einfach überprüfen wollen, insbesondere angesichts der Tatsache, dass diese voneinander abhängig sind. Ich bin damit einverstanden, diese Funktionalität zunächst nicht einzubeziehen, aber sie sollte irgendwann hinzugefügt werden (wie in: in einem Problem im Auge behalten).

Andernfalls wird die Handhabung ziemlich kompliziert.

Im Allgemeinen sollte die Notwendigkeit, komplexe Frontend-Logik zu implementieren, unser Engagement für UX nicht beeinträchtigen.

Ich würde dies als zukünftige Verbesserung betrachten. Im Moment können wir dem Benutzer nur eine Benachrichtigung über einen nicht abgeschlossenen Flow anzeigen. Später kann der Benutzer das Gerät auf der Seite mit den allgemeinen Einstellungen bearbeiten/löschen.

Nicht optimal, aber für mich akzeptabel, solange wir dies irgendwann verbessern.

Wie offline besprochen, hier ist der ursprüngliche Vorschlag;

Gerät erstellen

1. Allgemeine Einstellungen
   
   
   
   • Felder
     
     
     
     
     
     • ids
     
     
     
     • Optional name
     
     
     
     • Optional description
     
     
     
     • Optional attributes
     
     
     
     • Erforderlicher Aktivierungsmodus: OTAA, ABP oder Multicast
     
     
     
     • Wenn NS im Cluster
       
       
       
       
       
       
       
       • lorawan_version
       
       
       
       
       • lorawan_phy_version
       
       
       
       
     
     
     
   
   
   • Dieser Schritt erstellt das Gerät nur in IS. Auf diese Weise wissen wir, dass die Identifikatoren kostenlos sind
   
   
   • Der Aktivierungsmodus wird im Sitzungsstatus verwendet
   
   
   • Wenn nicht NS im Cluster, können Sie der Einfachheit halber im Assistenten die höchsten bekannten Versionen (dh jetzt 1.1.0 bzw. 1.1.0-A) im Sitzungsstatus verwenden
   
   

2. LoRaWAN-Einstellungen

   • Wenn NS im Cluster: Felder
     
     
     
     • lorawan_version (erforderlich)
     
     
     • lorawan_phy_version (erforderlich)
     
     
     • supports_join gesetzt, wenn der Aktivierungsmodus OTAA ist (erforderlich)
     
     
     • multicast gesetzt, wenn der Aktivierungsmodus Multicast ist
     
     
     • supports_class_b
     
     
     • supports_class_c
     
     
     • frequency_plan_id (erforderlich)
     
     
     • 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
     
     
   • Wenn NS im Cluster: Felder, wenn der Aktivierungsmodus OTAA ist
     
     
     
     • Checkbox, ob externes JS verwendet werden soll (standardmäßig aktiviert)
     
     
   • Felder, wenn der Aktivierungsmodus ABP oder Multicast ist
     
     
     
     • Wenn NS oder AS im Cluster: session.dev_addr
     
     
     • Wenn NS oder AS im Cluster: Generieren Sie ein session.keys.session_key_id
     
     
     • Wenn NS im Cluster: session.keys.f_nwk_s_int_key.key - erforderlich
     
     
     • Wenn NS im Cluster: session.keys.s_nwk_s_int_key.key (wenn LW >= 1.1.0) - erforderlich
     
     
     • Wenn NS im Cluster: session.keys.nwk_s_enc_key.key (wenn LW >= 1.1.0) - erforderlich
     
     
     • Wenn AS im Cluster: session.keys.app_s_key.key - erforderlich
     
     
     • Wenn NS im Cluster: session.last_conf_f_cnt_down
     
     
     • Wenn NS im Cluster: session.last_n_f_cnt_down
     
     
   • Wenn NS im Cluster: Felder, wenn der Aktivierungsmodus ABP ist
     
     
     
     • mac_settings.resets_f_cnt
     
     
   • Wenn NS oder AS im Cluster: Felder, wenn der Aktivierungsmodus ABP ist
     
     
     
     • session.last_f_cnt_up - Dies ist aus Sicherheitsgründen erforderlich
     
     

   • Wenn NS im Cluster: Felder, wenn der Aktivierungsmodus ABP oder OTAA ist

     • 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

   • Dadurch wird das Gerät in NS und AS (falls im Cluster) eingestellt. Wenn wir ein OTAA-Gerät haben, müssen wir an dieser Stelle nichts in AS einstellen, aber ich würde trotzdem die Forderung nach Konsistenz stellen

3. Wenn AS im Cluster: Anwendungseinstellungen
   
   
   
   • Felder
     
     
     
     
     
     • payload_formatters
     
     
     
   
   
   • Dadurch wird das Gerät in AS versetzt
   
   
4. Wenn JS im Cluster und wenn OTAA und wenn kein externes JS verwendet wird: Sicherheitseinstellungen
   
   
   
   • Felder
     
     
     
     
     
     • Generieren Sie root_keys.root_key_id
     
     
     
     • root_keys.app_key.key
     
     
     
     • root_keys.nwk_key.key (wenn LW >= 1.1.0)
     
     
     
     • resets_join_nonces
     
     
     
     • home_net_id
     
     
     
     • network_server_kek_label
     
     
     
     • application_server_kek_label
     
     
     
     • application_server_id
     
     
     
   
   
   • Dadurch wird das Gerät in JS eingestellt
   
   

Gerät aktualisieren

Hier würde ich einen Ansatz mit Registerkarten wählen, im Grunde mit Assistentenschritten als Registerkarten.

Der Schlüssel hier ist das;

• ids , supports_join , multicast sind schreibgeschützt
• Der Aktivierungsmodus wird in dieser Reihenfolge ausgewertet:
  
  
  
  • OTAA: wenn kein NS im Cluster oder wenn NS im Cluster und NS supports_join sagt
  
  
  • ABP: benötigt NS im Cluster (und ist nur in diesem Fall relevant): !supports_join && !multicast
  
  
  • Multicast: benötigt NS im Cluster (und ist nur in diesem Fall relevant): !supports_join && multicast (obwohl multicast ausreichen sollte)
  
  

Einige Anwendungsfälle zur Unterstützung bei der Aktualisierung von Geräten:

• Die Konsole kann NS, AS und JS im Cluster haben, aber das Gerät befindet sich möglicherweise nicht im NS, AS oder JS (die Konsole erhält 404). Dies ist ein gültiger Fall und die Konsole sollte damit umgehen. Ein Beispielfall ist ein beanspruchtes Gerät, bei dem das Gerät in ER und JS eingestellt ist, aber (noch) nicht in NS und AS
• Aufbauend auf dem Vorhergehenden: Stellen Sie die LoRaWAN- und Anwendungseinstellungen eines Geräts ein, das sich nur in ER und JS befindet (d. h. stellen Sie es in NS und AS ein).
• Ändern lorawan_version und lorawan_phy_version (dies ändert Einschränkungen)
• Ändern der Option "externes JS"; Angenommen, Sie haben ein vorhandenes Gerät, möchten aber Root-Schlüssel im Cluster-JS konfigurieren. Dann deaktivieren Sie dieses Kontrollkästchen und der Benutzer sollte in der Lage sein, die Stammschlüssel auf der Registerkarte Sicherheitseinstellungen festzulegen
• Über den Massenimport kann das Gerät auf JS erstellt werden und Stammschlüssel haben, aber sie werden nicht offengelegt. Wie heute sollte der Benutzer sehen können, dass Stammschlüssel vorhanden sind ( root_keys != nil ), aber sie sind nicht verfügbar ( root_keys.app_key == null usw.). Der Benutzer sollte in der Lage sein, die Stammschlüssel intakt zu lassen

Allgemeines

• Für Schlüssel ein Eingabefeld oder eine Zufallsgenerator-Schaltfläche
• Der Unterschied zwischen externem JS und nicht exponierten Stammschlüsseln;
  
  
  
  • Bei externem JS befindet sich das JS nicht im selben Cluster wie das NS. Dadurch kann ein OTAA-Gerät erstellt werden, ohne dass die Sicherheitseinstellungen eingegeben werden müssen, da die Schlüssel an anderer Stelle konfiguriert werden
  
  
  • Nicht verfügbar gemachte Stammschlüssel sind dort, wo sich das Gerät im clusterlokalen JS befindet, aber das JS macht die Stammschlüssel nicht verfügbar. Dies dient der Sicherheit, dh im Fall von sicheren Elementen, bei denen JS Zugriff auf Stammschlüssel hat, diese aber nicht offenlegt
  
  

Ich denke, https://github.com/TheThingsNetwork/lorawan-stack/issues/579#issuecomment -525719408 enthält bereits alles Notwendige für NS.
Ich denke, alle mac_settings sollten verfügbar sein, um für alle Nicht-Multicast-Geräte eingestellt zu werden.
Für Multicast-Geräte macht nur folgendes Sinn:

• "mac_settings.factory_preset_frequenzen"
• "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"

Vielleicht einige Dinge zu klären

Schaffen:

1. Allgemeine Einstellungen
   A. Wenn wir das Gerät in der Notaufnahme erstellen, legen wir keine NS/AS/JS-Adressen fest. Aktualisieren wir die ER-Registrierung, wenn das Gerät in diesen eingestellt ist? Was ist, wenn wir ein externes JS verwenden?
   B. Speichern wir den Aktivierungsmodus im ER?
   C. Speichern wir die Phy/Mac-Versionen in der Notaufnahme?
2. LoRaWAN-Einstellungen
   A. Wie wäre es mit supports_class_b ?
3. Anwendungseinstellungen
   A. Ja, das könnte bedeuten, dass wir das Gerät zweimal am AS einstellen

Aktualisieren:

• Aktivierungsmodus: wäre viel einfacher, wenn wir dies in ER speichern würden
• Betrachten wir nur 404er oder auch die NS/AS/JS-Adressen im ER?
• Ich denke, es wäre schön, eine einzelne NS/AS/JS-Registrierung löschen zu können, beispielsweise wenn "externes JS" in true geändert wird, oder um den Gerätestatus im NS zurückzusetzen

Allgemeines:

• _"Externes JS ist, wo sich das JS nicht im selben Cluster wie das NS befindet"_: Ich denke, das sollte so etwas wie "join_server_address ist nicht dasselbe wie die JS-Adresse in der Konsolenkonfiguration" sein.

Wenn wir über Felder der obersten Ebene sprechen:
https://github.com/TheThingsNetwork/lorawan-stack/blob/375c82cc068bbadb72b887e25631f8f2dc03a366/api/end_device.proto#L395 -L418 dieser ganze Chunk gehört in NS (aber nicht alle davon sind erforderlich)

m{in,ax}_frequency gilt nicht für Multicast

@rvolosatovs

Ich denke, #579 (Kommentar) enthält bereits alles Notwendige für NS.

Ich denke, alle mac_settings sollten verfügbar sein, um für alle Nicht-Multicast-Geräte eingestellt zu werden.
Für Multicast-Geräte macht nur folgendes Sinn:

Eines der Probleme bei diesem Problem ist die Menge an Informationen, die in Kommentaren verborgen sind.

Können Sie bitte _exakt_ die Felder an den richtigen Stellen hinzufügen? Mir geht es gut, wenn Sie meine gesamte Liste der Aufzählungspunkte kopieren, damit wir schrittweise daran arbeiten, bis wir eine endgültige Version haben.

@htdvisser

1. Allgemeine Einstellungen
   A. Wenn wir das Gerät in der Notaufnahme erstellen, legen wir keine NS/AS/JS-Adressen fest. Aktualisieren wir die ER-Registrierung, wenn das Gerät in diesen eingestellt ist? Was ist, wenn wir ein externes JS verwenden?

Ich denke, wir sollten die Adressen aktualisieren, wenn wir die Geräte in AS/NS/JS einstellen.

B. Speichern wir den Aktivierungsmodus im ER?

Nein, dafür haben wir im Moment kein Feld, brauchen wir nicht wirklich und es schafft Raum für Ungereimtheiten.

C. Speichern wir die Phy/Mac-Versionen in der Notaufnahme?

Nein, siehe API-Dokumentation. Auch hier sehe ich keine Notwendigkeit und es schafft Raum für Inkonsistenzen.

A. Wie wäre es mit supports_class_b ?

Ja, ich denke, wir sollten das hinzufügen, in Erwartung von #19. @rvolosatovs bitte fügen Sie dies gegebenenfalls in eine aktualisierte Version ein.

1. Anwendungseinstellungen
   A. Ja, das könnte bedeuten, dass wir das Gerät zweimal am AS einstellen

Ja, das tut nicht weh

Aktualisieren:

• Aktivierungsmodus: wäre viel einfacher, wenn wir dies in ER speichern würden

Ja, aber ich bin mir nicht sicher, ob wir auf Leichtigkeit setzen sollten und ob das vollständig zutrifft. Wir müssen es im Hot Path verfügbar haben.

Außerdem wäre es nur einfach, wenn wir von Null anfangen könnten. Wir müssen jedoch abwärtskompatibel sein, Heuristiken hinzufügen, wenn lorawan_version nicht in ER ist, bedingte Gets von NS einführen usw.

• Betrachten wir nur 404er oder auch die NS/AS/JS-Adressen im ER?

Wir können einen 404 nur bekommen, wenn eine Adresse gesetzt ist, sonst gibt es nichts zu bekommen. Wir sollten beide als "nicht in dieser Registrierung" interpretieren. Wir können hier (wie zuvor) keinen Fehler machen, genau aus dem Grund, dass die Erstellung in IS und AS/NS/JS nicht gleichzeitig erfolgt und Benutzer in der Lage sein sollten, von der Konsole erstellte Inkonsistenzen zu beheben.

• Ich denke, es wäre schön, eine einzelne NS/AS/JS-Registrierung löschen zu können, beispielsweise wenn "externes JS" in true geändert wird, oder um den Gerätestatus im NS zurückzusetzen

Ja, das machen wir später

• _"Externes JS ist, wo sich das JS nicht im selben Cluster wie das NS befindet"_: Ich denke, das sollte so etwas wie "join_server_address ist nicht dasselbe wie die JS-Adresse in der Konsolenkonfiguration" sein.

Ja, das ist in der Tat der Weg, um es zu überprüfen. join_server_address kann auch leer sein, wenn Interop verwendet wird.

@bafonins hast du noch die Quelle für die Grafik?
Da bereits viel Arbeit in die Konstruktion geflossen ist, sollten wir das einfach aktualisieren, um es vollständig zu machen und eine klare Darstellung zu erhalten?
Wir können auch daran arbeiten, den NS-Teil offline zu aktualisieren, um die Diskussion hier nicht zu überladen.

Ich habe das Diagramm mit allen möglichen NS-Feldern aktualisiert
Die roten Felder sind Pflichtfelder

@rvolosatovs Wir wollen den Ablauf und die Felder definieren, die wir beim Erstellen und Aktualisieren von Geräten in der Konsole präsentieren.

So wie,

• Wir sollten nicht zulassen, dass sich mac_state.lorawan_version ändert
• Wir können vorerst mac_state.ping_slot_periodicity über die CLI ausführen
• Bitte denken Sie darüber nach, wie der Benutzer supports_class_b , supports_class_c und mac_state.device_class setzen wird; was gehört zu create, was gehört zu update, wie verhält man sich zueinander?
• Wir sollten einzelne Zähler nicht ändern; Eine Schaltfläche "Frame-Zähler zurücksetzen" würde ausreichen (was afaik eine separate Aktion sein kann, wie wir es in der V2-Konsole haben, die die Zähler auf 0 setzt)
• Wir sollten sorgfältig auswählen, welche Einstellungen wir in der Konsole von mac_settings und mac_state.desired_parameters wollen; @htdvisser kannst du hier mitdenken?

Ich habe die Reihenfolge in https://github.com/TheThingsNetwork/lorawan-stack/issues/579#issuecomment -553347858 geändert. Bitte arbeiten Sie schrittweise an dieser Liste.

Können Sie bitte genau die Felder an den richtigen Stellen hinzufügen?

Ich habe diese Frage beantwortet - dh ich habe alle Felder dargestellt, die auf NS gesetzt werden können und gesetzt werden sollten . So jedenfalls habe ich deine Frage verstanden.

In Bezug auf das, was in der Konsole sein sollte, sollte alles mac_state wahrscheinlich nur über CLI einstellbar sein, aber wir können dies für ABP/Multicast-Geräte und/oder OTAA-Geräte verlangen, die mit einer bestehenden Sitzung registriert werden, und, daher MAC-Zustand.
Ich werde deinen Kommentar aktualisieren.

Wir sollten einzelne Zähler nicht ändern; Eine Schaltfläche "Frame-Zähler zurücksetzen" würde ausreichen (was afaik eine separate Aktion sein kann, wie wir sie in der V2-Konsole haben, die die Zähler auf 0 setzt).

Wir müssen in der Lage sein, Downlink-Frame-Zähler für ABP und Multicast festzulegen – andernfalls kann NS keine Downlinks senden
Für Uplink-Rahmenzähler sind auch vom Sicherheitsstandpunkt für ABP sehr nützlich

Gerät aktualisieren

Hier würde ich einen Ansatz mit Registerkarten wählen, im Grunde mit Assistentenschritten als Registerkarten.

Lassen Sie uns hier den Akkordeon-Ansatz verwenden, wie er im ersten Kommentar von @bafonins vorgestellt wird :

Es wird uns weniger Probleme mit dem horizontalen Abstand geben und ermöglicht die Unterscheidung von Modi mit den Schaltflächen Edit / Create .

@rvolosatovs

Wir müssen in der Lage sein, Downlink-Frame-Zähler für ABP und Multicast festzulegen – andernfalls kann NS keine Downlinks senden
Für Uplink-Rahmenzähler sind auch vom Sicherheitsstandpunkt für ABP sehr nützlich

Wenn das einfach ist, können wir es tun. Tatsächlich können zwei/drei Eingabefelder einfacher sein als ein Reset-Button, der eine bestimmte Aktion auslöst.

In Bezug auf das, was in der Konsole sein sollte, sollte alles mac_state wahrscheinlich nur über CLI einstellbar sein, aber wir können dies für ABP/Multicast-Geräte und/oder OTAA-Geräte verlangen, die mit einer bestehenden Sitzung registriert werden, und, daher MAC-Zustand.

Ich verstehe. Ich denke, wir sollten "neue und zurückgesetzte ABP-Geräte" von "vorhandenen ABP-Geräten, die bereits in einem Netzwerk waren" trennen.

Ersteres sollte vollständig sein, also sollte es einige mac_state enthalten (dh Frequenzen zum Zurücksetzen auf die Werkseinstellungen, RX1-Verzögerung, RX2-Einstellungen usw.), aber nicht mac_state.desired_parameters .

Letzteres sollte über die Migration erfolgen und wir können die Feinabstimmungseinstellungen später in der Konsole hinzufügen; vorerst sollte CLI verwendet werden.

Danke für die Aktualisierung

LoRaWAN-Einstellungen

• Wenn NS im Cluster: Felder
  
  
  
  • 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
  
  

Sind diese für OTAA notwendig? Gilt das nicht nur für ABP und Multicast?

@johanstokking

LoRaWAN-Einstellungen

• Wenn NS im Cluster: Felder
  
  
  
  • 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
  
  

Sind diese für OTAA notwendig? Gilt das nicht nur für ABP und Multicast?

Alle MAC-Einstellungen sind optional.
Der einzige Fall, in dem dies "erforderlich" ist, sind Multicast-Geräte der Klasse B, was auf die Besonderheiten des Betriebs der Klasse B zurückzuführen ist.
Abgesehen davon sind wahrscheinlich factory_preset_frequencies für ABP erforderlich, um die besten Ergebnisse zu erzielen, aber nichts hindert das OTAA-Gerät daran, diesen Satz zu haben.

Alle MAC-Einstellungen sind optional.
Der einzige Fall, in dem dies "erforderlich" ist, sind Multicast-Geräte der Klasse B, was auf die Besonderheiten des Betriebs der Klasse B zurückzuführen ist.

OK

Abgesehen davon ist wahrscheinlich factory_preset_frequencies für ABP erforderlich, um die besten Ergebnisse zu erzielen, aber nichts hindert das OTAA-Gerät daran, diesen Satz zu haben.

Es ist für OTAA unwirksam; Die standardmäßigen Join-Frequenzen sind gemäß Spezifikation erforderlich, und die Kanäle kommen über Join-Accept- und MAC-Befehle herein. Es sollte keine Außerbandkonfiguration von voreingestellten Frequenzen für OTAA-Geräte geben.

@bafonins können Sie ein Status-Update und einen Zeitplan zu diesem Problem geben?

Für app_s_key und skip_payload_crypto ist hier das Ding;

• AS berücksichtigt das Feld skip_payload_crypto des Endgerätes. Wenn true , führt AS keine Payload-Verschlüsselung und -Entschlüsselung durch
  
  
  
  • AS erhält auch auf Anwendungsebene (über Link, wie Payload-Formatierer) ein skip_payload_crypto , das Vorrang vor der Einstellung des Endgeräts hat
  
  
• Es gibt wahrscheinlich immer ein app_s_key in AS, aber es kann umschlossen sein, dh session.keys.app_s_key.key ist nicht gesetzt (aber encrypted_key und kek_label sind gesetzt)
  
  
  
  • Wenn AS den KEK nicht hat, dh es kann den verschlüsselten Schlüssel nicht entpacken. Nun, diese Fehler. Wir werden wahrscheinlich nur die verschlüsselten app_s_key unverändert an die Kunden zurückgeben
  
  
• Wenn in der Konsole skip_payload_crypto auf true gesetzt ist (auf Endgerät oder Anwendungslink), kümmern Sie sich nicht um app_s_key : Deaktivieren Sie es, egal