Funktionsbeschreibung
Zigbee-Geräte geben standardmäßig einen Wert zurück, der der Verbindungsqualität mit dem Server oder dem zentralen Knoten entspricht. Ich nehme an, dass es bei Z-Wave und anderen Protokollen ähnlich ist.
Ich schlage vor, in Gladys eine Funktion « Link Quality » hinzuzufügen, wie sie bereits von Zigbee2mqtt vorgeschlagen wird:
Zusätzlich zu dem, was ich zur Erkennung schwacher Batterien oder Ausfällen von Sensoren vorgeschlagen habe, könnten wir dann eine Warnung ausgeben, wenn ein Sensor ein sehr schwaches Signal empfängt.
Allerdings finde ich « link quality » nicht sehr klar. « Signalstärke » ist besser und man versteht es direkt.
Es sollte jedoch eine klare und einfache Skala geben. In unseren Handys haben wir Balken von 1 bis 5, das finde ich recht klar. In deinem Beispiel (ich weiß nicht, ob es echte Daten sind), sagt « 120 lqi » niemandem etwas ^^
Ich würde mich für eine « Signalstärke » von 1 bis 5 im Stil von Netzwerkbalken/WLAN-Balken entscheiden
Frontend-seitig habe ich noch nichts gemacht, die Idee einer Netzwerkleiste zur Darstellung des Signals ist gut, aber wir haben nichts in dem Icon-Paket (es ist qualitativ, aber es gibt nicht viel, außerdem wird das Repo nicht mehr gewartet).
@pierre-gilles, was hat damals die Wahl der Feather-Icons statt z. B. Material Design Icons motiviert, die eine große Community haben und wirklich komplett sind?
Für die Funktion
Die Wahl der Feather-Icons wurde dadurch motiviert, dass Tabler Feather Icons verwendet, also passt das Design gut zusammen. Ein weiterer Punkt war der Minimalismus (das geringe Gewicht der Abhängigkeit).
Material Design Icons ist ein Thema, da gibt es mehrere Punkte zu beachten:
Gladys ist kein Material Design-Projekt, also muss man sehen, ob dieser Iconsatz auch außerhalb einer nicht-Material-UI Sinn macht
Wie groß ist das Gewicht der Abhängigkeit? Nicht zu schwer? Gladys ist eine PWA, also wird das Bundle bei jedem Update vollständig heruntergeladen, das muss man berücksichtigen.
Welche Icons interessieren uns genau in Material, die wir nicht in Feather haben? Eine vollständige Migration (denn man muss das Bestehende konvertieren, wir verwenden Feather derzeit in den Szenen und der Name des Icons wird in der DB gespeichert), wenn es nur für 1-2 Icons ist, ist das vielleicht Overkill
Ich bin nicht grundsätzlich gegen einen Wechsel, wenn es Sinn macht
Für diesen speziellen Fall, warum sucht man nicht einfach ein gutes SVG im Internet? Wenn dir das von Material gefällt, warum nimmst du es nicht einfach?
Ein SVG nehmen und die Ressource hinzufügen, warum nicht. Das Risiko ist, dass der Stil etwas von Feather abweicht. Ich werde lieber versuchen, im Feather-Stil zu arbeiten.
MDI als Ersatz für Feather ist eine andere Diskussion.
Wie kann ich die Größe des MDI-Bundles herausfinden? (das zwangsläufig größer sein wird (23.000 Icons))
@pierre-gilles Ich schlage vor, zunächst nur die Unit-Feature hinzuzufügen, die Box kommt später in einem anderen PR. Dadurch kann Alex mit der automatischen Erkennung der Features vorankommen.
Welchen Nutzen hat der Benutzer, eine Präzision von 1/255 zu haben?
Ich weiß nicht, offene Frage.
Bisher haben wir immer versucht, in Gladys ein Format zu definieren, das für alle Integrationen gleich ist (Beispiel: die Farben der Lampen), und Konvertierungsfunktionen in jedem Dienst.
Dadurch haben wir generische Komponenten und müssen nicht fünf verschiedene UIs entwickeln.
Wenn wir das Farbformat jedes Herstellers ohne Konvertierung gespeichert hätten, wäre das die Hölle gewesen ^^
Hallo, ich springe kurz in die Unterhaltung, um zu präzisieren, dass wir das auch bei Netatmo haben (am Tag, an dem es veröffentlicht wird). Ich werde in der PR von @damalgos nachschauen, welche Werte ich gesetzt hatte.
