Ja, das Ziel ist dasselbe, der LQI berücksichtigt den RSSI und die gesendeten/empfangenen Pakete sowie die Route, die Einheiten sind unterschiedlich, aber in beiden Fällen möchte der Benutzer Netzwerkbalken in der UI.
Das Problem mit 1 bis 5 ist, dass wir an Präzision verlieren, wenn wir Szenen erstellen möchten (Nachricht bei schwachem Signal). Für mich ist das in Ordnung. Mal sehen, was die anderen dazu denken.
Man könnte einen Kompromiss finden und auf 0 bis 10 umsteigen. Nicht sicher, ob mehr Präzision wirklich so nützlich ist
Danach denke ich wirklich, dass es sich lohnt, zwischen den verschiedenen Diensten zu faktorisieren, dann entwickelt man die UI einmal und alles ist kompatibel.
Ja, aber was ist dann der Sinn von zwei verschiedenen Funktionen?
Der einzige Vorteil, den ich sehe, wäre möglicherweise, in der neuen « Grafik »-Ansicht eine detaillierte Anzeige der Entwicklung des genauen LQI zu zeigen.
Aber ist das wirklich nützlich?
Eigentlich möchte ich vermeiden, dass wir eine spezifische Zigbee-Entwicklung machen, die anderen Integrationen nicht zugutekommt, denn jedes Protokoll macht sein eigenes Ding (ist immer so), und dass wir dann gezwungen sind, eine andere UI pro Protokoll zu entwickeln, was nicht das Ziel von Gladys ist!
Aber wenn es einen echten Unterschied gibt und einen echten Bedarf, die beiden zu unterscheiden, kein Problem, wir können die beiden getrennt halten, ich möchte nur sicher sein, dass der genaue Nutzen für den Endnutzer klar ist
Die Einheiten sind nicht dieselben, diese beiden Funktionen sind in gewisser Weise sehr eng miteinander verbunden, aber sie tragen nicht dieselbe Information.
Was ich nicht wollte, war, die Zigbee-Daten zu konvertieren und keinen „gladys“-Wert für die Link-Quality zu haben, da sie bereits mit ihren Spezifikationen auf der Zigbee-Seite (für den Server-Teil) definiert ist. Wenn ich mich in die Lage eines Benutzers versetze, der eine Szene erstellt, und die Zigbee-Dokumentation ihm 0-255 anzeigt, und auf der Gladys-Seite 0-5 ist, wird das Frustration verursachen
Bei der Anzeige/Icons des „Signals“ in der UI werden es in beiden Fällen klassische Balken sein.
Trotzdem möchtest du genau dieselbe Information in der UI anzeigen! Deshalb verstehe ich das nicht!
Welchen Sinn hat es, das an zwei verschiedenen Stellen zu speichern, wenn das Ziel ist, dasselbe anzuzeigen?
Wie wird das verwendet werden?
Genau das ist für mich ein Argument für die Faktorisierung!
In der UI sollte der Benutzer keine Werte eingeben müssen, Dokumente durchstöbern (wir sind nicht bei Home Assistant), wenn es auf Gladys-Seite verallgemeinert ist, sind wir in der Lage, eine spezifische UI mit vorgefüllten Werten zu erstellen.
Beispiel: Ein/Aus, ich habe eine generische Komponente erstellt (der Benutzer muss nicht wissen, dass 0 aus und 1 an bedeutet: Die UI erledigt das für ihn)
Der Benutzer muss nicht erraten, dass die Farbe in RGB, HEX oder was auch immer gespeichert ist: Er möchte einfach die Farbe steuern, egal welches Protokoll verwendet wird, und er hat einen Farbauswahl-Tool, der den Job erledigt, egal welche Marke, und die Farbe wird in jedes Format konvertiert: Das ist der Job des Entwicklers, nicht des Benutzers.
Daher mein Kommentar zur Signalqualität, wenn wir das Verhalten verallgemeinern, werden wir in der Lage sein, eine Komponente in der UI zu erstellen, die es dir ermöglicht, 0 bis 5 « Balken » auszuwählen (wir müssen das Format der Komponente vorstellen), und der Benutzer muss nicht einmal die Zigbee-Dokumentation lesen
Ein weiteres Argument für die Faktorisierung!
Hier kann ich sehen, dass das Signal sogar negativ ist
Wir müssen ein wenig Ordnung schaffen, sonst wird es ein Chaos, und wir müssen fünf verschiedene UIs für jeden Gerätetyp codieren.
Man kann sich auch anrufen, um darüber zu sprechen, vielleicht ist das einfacher Wie du willst!
Die Idee ist einfach, das aus Nutzersicht zu integrieren, anstatt zuerst an den Backend zu denken und dann mit unterschiedlichen Implementierungen pro Integration dazustehen
Also, du weißt, was ich dir jetzt antworten werde, ich weiß nicht, ob ich es noch einmal sagen muss
Um also weiterzumachen, sind wir uns einig, dass wir in beiden Fällen eine Zahl als Eingabe haben (den LQI oder den RSSI), und als Ausgabe wollen wir eine ganze Zahl von 0 bis 5, um diese fünf verschiedenen Miniaturansichten anzuzeigen.
Und aus dem, was ich aus dieser Diskussion verstehe, bist du, @VonOx, dafür, die Umwandlung in der Frontend-Anwendung durchzuführen (und die Rohdaten in der Datenbank zu speichern), und ich bin eher dafür, dies in der Backend-Anwendung zu tun (und die transformierten Daten in der Datenbank zu speichern).
Beide Ansätze haben Vor- und Nachteile:
Wenn wir die Umwandlung in der Backend-Anwendung durchführen und nur 0 bis 5 in der Datenbank speichern, verlieren wir im Grunde genommen Informationen, die nützlich sein könnten (oder auch nicht).
Wenn wir die Umwandlung in der Frontend-Anwendung durchführen, bedeutet das, dass wir jede Marke und jedes Format bei der Anzeige verwalten müssen, wobei wir bisher in Gladys dies immer im Backend-Service gemacht haben.
Genau, denn für mich haben wir zwei unterschiedliche Einheiten, die nicht dieselbe Bedeutung haben. Auch wenn die Darstellung in der Benutzeroberfläche identisch ist.
Also brauchen wir andere Meinungen (ich bin kein Berufs-Entwickler, also zählt meine Meinung weniger).
Danach spricht nichts dagegen, den Namen der Funktion zu ändern, da diese 0-5 weder ein LQI noch ein RSSI ist, sondern ein „abgeleiteter“ Wert. Man könnte eine eigene Funktion für Gladys erstellen, „Signalqualität“, die von 0 bis 5 geht.
Anschließend erstellt man Konvertierungsfunktionen, um von einer zur anderen zu wechseln.
Würde dir das sinnvoll erscheinen?
Oder wärst du wirklich dafür, die gesamte Konvertierung auf der Frontend-Seite durchzuführen?
Denn das Problem bei der Konvertierung auf der Frontend-Seite ist, dass man sie überall durchführen muss: im Dashboard, bei den Triggern der Szenen, bei den Aktionen der Szenen, bei den Nachrichten usw.
Während man, wenn man das auf der Backend-Seite macht, die Verarbeitung nur einmal durchführt.
Gefällt dir dieses Icon!
(ich bin kein Berufs-Entwickler, also zählt meine Meinung weniger).