Lorawan-stack: Présentation de la passerelle unique
Résumé:
La console a besoin d'une page de présentation pour les passerelles, complémentaire à nos pages de présentation pour les applications et les appareils. Voir aussi #26.
La page de présentation doit contenir :
- informations de base telles que l'identifiant, le nom, la description, la date de création
- informations d'état (dernière vue)
- l'emplacement des passerelles (antennes)
- nombre de messages envoyés/reçus
- plan de fréquence
- informations sur le matériel (marque, modèle, force du signal, micrologiciel)
- confidentialité (passerelle publique/privée)
Implicitement, travailler sur la vue d'ensemble contiendra également :
- vue parent de la passerelle (avec barre latérale, conteneur de fil d'Ariane)
Pourquoi avons nous besoin de ça?
Les pages d'aperçu de nos entités servent d'accès rapide aux informations les plus importantes en une faible profondeur de clic.
Qu'y a-t-il déjà ?
Les points de terminaison d'API correspondants. Pour référence, un exemple de réponse GET /gateways/{gateway_ids.gateway_id} du registre de la passerelle :
{
"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"
}
Que manque-t-il?
- Discussion rapide sur ce qui doit y être (est-ce qu'il nous manque quelque chose)
- Wireframes et/ou screendesigns
- Mise en œuvre
Comment proposez-vous de mettre cela en œuvre ?
Complémentaire à notre implémentation d'application.
Que pouvez-vous faire vous-même et pour quoi avez-vous besoin d'aide ?
Je voudrais faire un suivi avec un wireframe rapide, une fois que j'ai quelques commentaires sur les exigences.
kschiffer
Tous les 7 commentaires
Je pense que nous avons besoin d'informations ici bientôt sur ce qu'il faut afficher sur la page de présentation de la passerelle.
cc @htdvisser @johanstokking
kschiffer
le 3 mai 2019
Je garderais les choses simples; ID, EUI, nom, description et plan de fréquence.
Ce serait bien d'afficher un indicateur en ligne en appuyant sur le GS et en vérifiant les statistiques de connexion. Si 200 <= état < 300, il est connecté, si 404 il n'est pas connecté, et tout le reste est une erreur. Il s'agit d'un appel par entrée affiché, mais cela en vaut la peine et est bon marché à servir à partir de GS car il provient de la mémoire.
johanstokking
le 3 mai 2019
de https://github.com/TheThingsNetwork/lorawan-stack/issues/26#issue -404416151
afficher les statistiques de connexion par passerelle (si l'adresse du serveur de passerelle correspond à la configuration de l'API du serveur de passerelle de la console actuelle)
et
Ce serait bien d'afficher un indicateur en ligne en appuyant sur le GS et en vérifiant les statistiques de connexion. Si 200 <= état < 300, il est connecté, si 404 il n'est pas connecté, et tout le reste est une erreur.
Nous devons nous mettre d'accord sur ce que nous montrons à l'utilisateur.
laisser
gtw_gs_address soit l'adresse du serveur passerelle configuré pour la passerelle
console_gs_address soit l'adresse du serveur passerelle du cluster actuel passé à la console
- Si supérieur ou égal à 200 et inférieur à 300, alors son
connected - si 404
2.1 sigtw_gs_addressouconsole_gs_address == empty-> statutunknown. cela peut se produire si l'adresse du serveur de passerelle n'est pas présente dans le cluster actuel ou si l'adresse n'a pas été ajoutée lors de la création de la passerelle, ou si les deux.
2.2 sigtw_gs_address == console_gs_address-> étatdisconnected
2.3 sigtw_gs_address != console_gs_address-> la passerelleis not managed by this console - autre chose -> le statut de la passerelle est
unknown, la page Présentation de la passerelle affiche une erreur
Interface utilisateur :
connected (1)
unknown (2.1)
disconnected (2.2)
not this console (2.3)
@johanstokking @htdvisser @kschiffer
bafonins
le 6 mai 2019
J'utiliserais une logique différente pour l'indicateur de connectivité. Il doit commencer par l'adresse du serveur de la passerelle, et non par la requête au GS (car cela n'a pas de sens d'appeler un GS dont nous savons déjà qu'il ne dessert pas la passerelle) :
- Si
console.gateway_server_addressest vide, alors la fonctionnalité est complètement désactivée - Si
gateway.gateway_server_addressest vide, alors soit :- assumez
console.gateway_server_addressmais affichez également le message - la fonctionnalité est désactivée pour cette passerelle et afficher le message
- assumez
- Si
gateway.gateway_server_addressn'est pas égal àconsole.gateway_server_address, alors la fonctionnalité est désactivée pour cette passerelle et affiche le message
Je changerais aussi un peu le message. Nous essayons de dire à l'utilisateur que la passerelle sélectionnée n'est pas affectée au serveur de passerelle dans le cluster de la console actuelle. Il est toujours possible de lire/écrire des éléments de la passerelle qui se trouvent dans le serveur d'identité et non dans le serveur de passerelle (essentiellement tout autre que l'état de la connectivité et le trafic)
htdvisser
le 6 mai 2019
Je changerais aussi un peu le message.
Quel serait le message ?
bafonins
le 6 mai 2019
Je suis d'accord avec @htdvisser sur la commande.
Nous avons donc cinq états :
- Si
console.gateway_server_addressest égalgateway.gateway_server_address, alors appuyez sur GS :- Connecté si 200 <= état < 300
- Non connecté si 404
- Erreur sinon
- Autrement
- Inconnu Si
gateway.gateway_server_addressest vide ; la passerelle n'est pas provisionnée
- Inconnu Si
- Sinon, autre cluster (c'est-à-dire que les adresses diffèrent)
johanstokking
le 6 mai 2019
Je changerais aussi un peu le message.
Quel serait le message ?
En tout cas, je ne sais pas si la partie supérieure est un bon emplacement pour afficher la notification. Pour avoir un message significatif, nous avons probablement besoin d'un texte plus long qui n'aura pas l'air bien là-bas. Je dirais que Unknown ou Other Cluster comme statut est suffisant et nous devrions chercher un autre endroit pour informer l'utilisateur des détails plus tard.
kschiffer
le 6 mai 2019
Questions connexes
johanstokking
·
5Commentaires
johanstokking
·
8Commentaires
MatteMoveSRL
·
7Commentaires
johanstokking
·
6Commentaires
johanstokking
·
3Commentaires
Commentaire le plus utile
Je garderais les choses simples; ID, EUI, nom, description et plan de fréquence.
Ce serait bien d'afficher un indicateur en ligne en appuyant sur le GS et en vérifiant les statistiques de connexion. Si 200 <= état < 300, il est connecté, si 404 il n'est pas connecté, et tout le reste est une erreur. Il s'agit d'un appel par entrée affiché, mais cela en vaut la peine et est bon marché à servir à partir de GS car il provient de la mémoire.