Lorawan-stack: Überblick über einzelne Gateways

Erstellt am 6. März 2019 · 7Kommentare · Quelle: TheThingsNetwork/lorawan-stack

Zusammenfassung:
Die Konsole benötigt eine Übersichtsseite für Gateways, ergänzend zu unseren Übersichtsseiten für Anwendungen und Geräte. Siehe auch Nr. 26.

Die Übersichtsseite sollte enthalten:

grundlegende Informationen wie ID, Name, Beschreibung, Erstellungsdatum
Statusinfo (zuletzt gesehen)
Standort des Gateways (Antenne).
Anzahl gesendeter/empfangener Nachrichten
Frequenzplan
Hardwareinformationen (Marke, Modell, Signalstärke, Firmware)
Privatsphäre (öffentliches/privates Gateway)

Implizit beinhaltet die Arbeit an der Übersicht auch:

Gateway-Elternansicht (mit Seitenleiste, Breadcrumb-Container)

Warum brauchen wir das?
Die Übersichtsseiten unserer Unternehmen dienen dem schnellen Zugriff auf die wichtigsten Informationen in geringer Klicktiefe.

Was ist schon da?
Die entsprechenden API-Endpunkte. Als Referenz ein Beispiel für eine GET /gateways/{gateway_ids.gateway_id} -Antwort von der Gateway-Registrierung:

{
  "ids": {
    "gateway_id": "string",
    "eui": "string"
  },
  "created_at": "2019-03-06T08:55:43.727Z",
  "updated_at": "2019-03-06T08:55:43.727Z",
  "name": "string",
  "description": "string",
  "attributes": {
    "additionalProp1": "string",
    "additionalProp2": "string",
    "additionalProp3": "string"
  },
  "contact_info": [
    {
      "contact_type": "CONTACT_TYPE_OTHER",
      "contact_method": "CONTACT_METHOD_OTHER",
      "value": "string",
      "public": true,
      "validated_at": "2019-03-06T08:55:43.727Z"
    }
  ],
  "version_ids": {
    "brand_id": "string",
    "model_id": "string",
    "hardware_version": "string",
    "firmware_version": "string"
  },
  "gateway_server_address": "string",
  "auto_update": true,
  "update_channel": "string",
  "frequency_plan_id": "string",
  "antennas": [
    {
      "gain": 0,
      "location": {
        "latitude": 0,
        "longitude": 0,
        "altitude": 0,
        "accuracy": 0,
        "source": "SOURCE_UNKNOWN"
      },
      "attributes": {
        "additionalProp1": "string",
        "additionalProp2": "string",
        "additionalProp3": "string"
      }
    }
  ],
  "status_public": true,
  "location_public": true,
  "schedule_downlink_late": true,
  "enforce_duty_cycle": true,
  "downlink_path_constraint": "DOWNLINK_PATH_CONSTRAINT_NONE"
}

Was fehlt?

Kurze Diskussion darüber, was da drin sein muss (fehlt uns etwas)
Wireframes und/oder Screendesigns
Implementierung

Wie schlagen Sie vor, dies umzusetzen?
Ergänzend zu unserer Anwendungsimplementierung.

Was können Sie selbst tun und wo brauchen Sie Hilfe?
Ich würde gerne mit einem kurzen Wireframe weitermachen, sobald ich etwas Input zu den Anforderungen habe.

console discuss in progress

Quelle

kschiffer

Hilfreichster Kommentar

Ich würde es einfach halten; ID, EUI, Name, Beschreibung und Frequenzplan.

Schön wäre es, einen Online-Indikator anzuzeigen, indem Sie auf GS drücken und die Verbindungsstatistiken überprüfen. Bei 200 <= Status < 300 ist es verbunden, bei 404 ist es nicht verbunden und alles andere ist ein Fehler. Dies ist ein Anruf pro angezeigtem Eintrag, aber es lohnt sich und ist billig, von GS zu dienen, da es aus dem Speicher stammt.

johanstokking am 3. Mai 2019

👍2

Alle 7 Kommentare

Ich denke, wir brauchen hier bald etwas Input darüber, was auf der Gateway-Übersichtsseite angezeigt werden soll.
cc @htdvisser @johanstokking

kschiffer am 3. Mai 2019

Ich würde es einfach halten; ID, EUI, Name, Beschreibung und Frequenzplan.

johanstokking am 3. Mai 2019

👍2

von https://github.com/TheThingsNetwork/lorawan-stack/issues/26#issue -404416151

Verbindungsstatistik pro Gateway anzeigen (wenn die Gateway_Server_Adresse mit der Gateway Server API-Konfiguration der aktuellen Konsole übereinstimmt)

und

Schön wäre es, einen Online-Indikator anzuzeigen, indem Sie auf GS drücken und die Verbindungsstatistiken überprüfen. Bei 200 <= Status < 300 ist es verbunden, bei 404 ist es nicht verbunden und alles andere ist ein Fehler.

Wir sollten uns darauf einigen, was wir dem Benutzer zeigen.

Lassen
gtw_gs_address sei die Adresse des für das Gateway konfigurierten Gateway-Servers
console_gs_address ist die Adresse des Gateway-Servers des aktuellen Clusters, der an die Konsole übergeben wird

Wenn es größer oder gleich 200 und kleiner als 300 ist, dann ist es connected
wenn 404
2.1 wenn gtw_gs_address oder console_gs_address == empty -> Status unknown . Dies kann passieren, wenn die Adresse des Gateway-Servers nicht im aktuellen Cluster vorhanden ist oder die Adresse beim Erstellen des Gateways nicht hinzugefügt wurde oder wenn beides der Fall ist.
2.2 wenn gtw_gs_address == console_gs_address -> Status disconnected
2.3 wenn gtw_gs_address != console_gs_address -> das Gateway is not managed by this console
alles andere -> der Status des Gateways ist unknown , die Gateway-Übersichtsseite zeigt einen Fehler an

Benutzeroberfläche:
connected (1)
Screenshot 2019-05-06 at 11 46 17

unknown (2.1)
Screenshot 2019-05-06 at 11 46 52

disconnected (2.2)
Screenshot 2019-05-06 at 11 44 50

not this console (2.3)
Screenshot 2019-05-06 at 11 53 11

@johanstokking @htdvisser @kschiffer

bafonins am 6. Mai 2019

Ich würde eine andere Logik für die Verbindungsanzeige verwenden. Es sollte mit der Adresse des Gateway-Servers beginnen und nicht mit der Anfrage an den GS (weil es keinen Sinn macht, einen GS anzurufen, von dem wir bereits wissen, dass er das Gateway nicht bedient):

Wenn console.gateway_server_address leer ist, ist die Funktion vollständig deaktiviert
Wenn gateway.gateway_server_address leer ist, dann entweder:
1. nehmen Sie console.gateway_server_address an, aber zeigen Sie auch die Nachricht
2. die Funktion ist für dieses Gateway deaktiviert und zeigt die Meldung an
Wenn gateway.gateway_server_address nicht gleich console.gateway_server_address ist, wird die Funktion für dieses Gateway deaktiviert und die Meldung angezeigt

Ich würde auch die Botschaft etwas abändern. Wir versuchen dem Benutzer mitzuteilen, dass das ausgewählte Gateway nicht dem Gateway-Server im Cluster der aktuellen Konsole zugewiesen ist. Es ist immer noch möglich, Inhalte des Gateways zu lesen/schreiben, die sich auf dem Identitätsserver und nicht auf dem Gateway-Server befinden (im Grunde alles andere als Verbindungsstatus und Datenverkehr).

htdvisser am 6. Mai 2019

Ich würde auch die Botschaft etwas abändern.

Was wäre die Botschaft?

bafonins am 6. Mai 2019

Bei der Bestellung stimme ich @htdvisser zu.

Wir haben also fünf Zustände:

Wenn console.gateway_server_address gleich gateway.gateway_server_address ist, dann drücken Sie die GS:
- 1. Verbunden , wenn 200 <= Status < 300
- 1. Nicht verbunden, wenn 404
- 1. Fehler falls nicht
Ansonsten
- 1. Unbekannt Wenn gateway.gateway_server_address leer ist; das Gateway ist nicht bereitgestellt
- 1. Anderer Cluster sonst (d. h. Adressen abweichen)

johanstokking am 6. Mai 2019

👍1

Ich würde auch die Botschaft etwas abändern.
Was wäre die Botschaft?

Auf jeden Fall weiß ich nicht, ob der obere Teil ein guter Ort ist, um die Benachrichtigung anzuzeigen. Um eine aussagekräftige Nachricht zu haben, brauchen wir wahrscheinlich einen längeren Text, der dort nicht gut aussieht. Ich würde sagen, dass Unknown oder Other Cluster als Status ausreichen und wir uns an anderer Stelle umsehen sollten, um den Benutzer später über Einzelheiten zu informieren.

kschiffer am 6. Mai 2019

👍1

War diese Seite hilfreich?

0 / 5 - 0 Bewertungen

Lorawan-stack: Überblick über einzelne Gateways

Hilfreichster Kommentar

Alle 7 Kommentare

Verwandte Themen