Auf der Seite « Geräte » kann man nach Namen suchen, wenn es viele Geräte gibt.
Aber es wäre auch praktisch, nach Räumen anzeigen zu können, wie auf dem Dashboard.
Was denkst du dazu @cicoub13?
In Sachen Machbarkeit sollte es eher einfach sein, da es bereits eine Sortierung nach Namen gibt.
Fehler beim Hinzufügen von Geräten
Fehlerdetails: Beim Hinzufügen eines neuen Geräts tritt regelmäßig der Fehler « Ein Fehler ist beim Speichern aufgetreten » auf.
Die Aktion « Lichter der Szenen ein-/ausschalten » umfasst alle Geräte der Kategorie « light ».
Dieses Gerät sollte einfach nicht der Kategorie « light » angehören
Nur eine kleine allgemeine Bemerkung zu dieser Entwicklung ^^
Die Entwicklung des Dienstes Zigbee2mqtt begann im Oktober 2019, also ist er seit 1 Jahr und 4 Monaten in Entwicklung.
Ich habe das Gefühl, dass dieser Dienst ein bisschen in seinem eigenen Zweig blockiert ist… Das Projekt ist seit einiger Zeit im Tunnelmodus, und deshalb kann niemand es nutzen, das ist schade!
Sollten wir nicht lieber die Entwicklungen auf den Teil « Qualität » statt auf den Teil « Quantität » der Funktionen konzentrieren, um es in master zu mergen und damit allen zu nutzen?
Ehrlich gesagt, bevorzuge ich kleine PRs, die schnell auf einem Thema iterieren, auch wenn man 5 PRs hintereinander macht, um neue Funktionen hinzuzufügen, anstatt eine monolithische PR, die 2 Monate für die Überprüfung braucht, weil sie so dicht ist!
Die PRs von @AlexTrovato sind gute Beispiele für effektive PRs
@cicoub13@lmilcent Für euch, ist der Dienst bereit für die Produktion, und wenn nicht, was würde noch fehlen?
Für mich sind hier die Punkte, die noch erledigt werden müssen, bevor eine funktionierende v1 veröffentlicht werden kann:
Problem Nr. 1: Der « Suche »-Teil muss jederzeit funktionieren. Es kommt regelmäßig vor, dass ein Scan bei Gladys nicht funktioniert, aber bei Zigbee2Mqtt schon. @cicoub13 schien ein Socket-Problem zu erwähnen. Sobald dieses Problem behoben ist, ist es für eine v1 in der Produktion funktionsfähig.
Problem Nr. 2 vor der Produktion: Das Management von Löschungen/Hinzufügungen von Geräten mit denselben Namen. Wie ich erklärt habe, muss es möglich sein, ein Gerät zu löschen und dann wieder mit demselben Namen hinzuzufügen, ohne dass es Probleme gibt.
In meinen Tests ist das noch nicht der Fall.
Der Rest sind Verbesserungen, die hinzugefügt werden könnten, die aber nicht den Server-Teil betreffen, es ist rein Frontend. Typischerweise, Fehler besser verwalten, um den Benutzer nicht zu verlieren (was ich oben erwähnt habe und sich auf Punkt 2 bezieht) und die Anzeige der in Gladys integrierten Geräte filtern können, da es schnell viele geben kann.
Dieser Teil wird nach und nach in der Produktion erledigt: Überprüfen, dass jeder Sensor vollständig von Gladys unterstützt wird. Ich habe festgestellt, dass meine Öffnungsmelder und Temperatursensoren verwaltet werden, aber zum Beispiel fehlen die Werte battery und temperature.
Ich werde einen PR auf dem cicoub13-Repo für die Sensoren erstellen, die ich zu Hause habe.
Ich bin absolut deiner Meinung, es ist Zeit, dass diese von vielen von uns sehnlichst erwartete Funktion veröffentlicht wird! Und wir sind wirklich sehr nah dran, sobald die Punkte 1 und 2 gelöst sind, ist es bereit.
Was denkst du, @cicoub13?
Ich finde, Punkt 3. ist auch sehr wichtig. Frontend-Fehler sind alles andere als optional, die Fehlermeldungen müssen klar sein, sonst ist es unmöglich, sie zu debuggen, wenn sie in der Wildnis landen und es auf einer Instanz Probleme gibt!
Ich denke, das Herzstück ist da, aber es fehlt noch an Feinschliff. Ich habe nicht allzu viele Probleme mit meinen 4 Sensoren, aber @lmilcent hat einige Blockaden, die dazu führen, dass wir die Integration so nicht veröffentlichen können.
Ich konzentriere mich auf die Fehler und das Nutzererlebnis.
Die Hinzufügung von Geräten ist wirklich gut von Renaud durchdacht, also füge ich im Vorbeigehen noch ein paar hinzu.
Dieses Wochenende habe ich die Testabdeckung überprüft und es gibt keine Also ist das der große Teil, an dem ich diese Woche arbeite
Ich bin mit @pierre-gilles einer Meinung, dass wir im Moment keine Funktionen hinzufügen sollten, sondern uns auf die Qualität konzentrieren.
Wenn andere Leute testen könnten, wäre das auch super
Okay, danke für das Feedback! Natürlich ist die Stabilität des Dienstes extrem wichtig. Ich will diesen Teil nicht überstürzen, solange die Integration nicht stabil ist, werden wir sie nicht veröffentlichen
Autsch Natürlich ist es ohne Tests schwer, eine gute Stabilität zu erreichen…
Es ist schade, dass die Tests nicht gleichzeitig mit der Integration entwickelt wurden, jetzt, um sie nachträglich hinzuzufügen, versuche wirklich, das erwartete Verhalten zu testen, und nicht vom Code aus Tests zu erstellen, die keinen echten Nutzen haben.
Auf jeden Fall zögere nicht, wenn du auf dem Weg Blockaden/Fragen hast
Viel Glück beim Schreiben der Tests, das ist eine große Aufgabe (aber notwendig…).
Was die Fehler betrifft, habe ich versucht, mehr Informationen über meinen Fehler beim Hinzufügen von Geräten zu erhalten, aber ich habe trotz der Protokolle im Verbose-Modus nichts Neues
Wenn ich den Fehler reproduziere, wird auf der Gladys-Seite nichts angezeigt. Ich habe nur die API im Browser, die antwortet:
« External ID muss eindeutig sein » « zigbee2mqtt:CapteurMouvementSalleAManger:battery »
Aber ich hatte dieses Gerät vor dem Hinzufügen in « CapteurMouvementSalleAMangerunique » umbenannt. Daher scheint die Umbenennung in der Frontend-Ansicht nicht auf allen Ebenen korrekt zu sein.
Heute Abend habe ich versucht herauszufinden, was den Fehler beim Hinzufügen meiner Lonsonho (oder TuYa)-Steckdose verursachen könnte.
Auf der Backend-Seite ist es hier:
Die Variable feature ist leer, wenn ich versuche, meine Steckdose hinzuzufügen, was den Fehler verursacht.
Ich habe noch nicht nachgeschaut, wie diese Variable abgerufen wird, aber es ist schon ein Ansatzpunkt.
[edit]
Modellseite:
Meine TuYa-Steckdose wollte nicht zu Gladys hinzugefügt werden. Nachdem ich die Modelldatei geändert hatte, entfernte ich mehrere Funktionen und die Steckdose konnte integriert werden. Ich habe keine richtige Erklärung, da alle Funktionen von Gladys unterstützt werden sollten.
Falls du noch andere Ansatzpunkte hast, um die Ursache des Fehlers zu finden, zeig mir gerne die interessanten Dateien, und ich werde sie mir ansehen, sobald ich ein paar Minuten Zeit habe!
[edit 2]
Ich habe verstanden, was bei meiner Steckdose (und wahrscheinlich auch bei anderen Modellen) das Problem ist.
In der zugehörigen Modelldatei war die angewendete Konfiguration features.switch, features.power, features.current, features.voltage.
Diese spezifischen features des zigbee2mqtt-Dienstes werden dann in features übersetzt, die Gladys versteht.
Zum Beispiel wird features.switch mit der zugehörigen Kategorie in Gladys übersetzt.
Zigbee2mqtt-Dienst:
Übersetzung, um den Gladys-features zu entsprechen, die hier sind:
Und was ich festgestellt habe, ist, dass es nicht notwendig ist, im Zigbee2mqtt-Modell alle features anzugeben, da einige implizit sind (zumindest im Objekt SWITCH enthalten).
Für Switch sind die featurescurrent, voltage, power und energy implizit (siehe den obigen Code-Ausschnitt).
Daher sollte im Zigbee2mqtt-Modell einfach angegeben werden: features.switch. Aber was ich noch nicht verstehe, ist, dass die Weboberfläche nur noch die Funktion Ein/Aus anzeigt, wenn man das macht. Die Verbrauchsdaten, Spannung oder Strom werden nicht angezeigt.
@cicoub13, du hast ein bisschen mehr daran gearbeitet, könntest du Aufklärung über die Funktionsweise geben? Ist meine Argumentation zumindest teilweise richtig? Ich habe noch nicht verstanden, wie Gladys die features basierend auf dem hinzufügt, was der zigbee2mqtt-Dienst zurückgibt.
@lmilcent Ich beschäftige mich gerade mit den Geräten und dem Mapping der Zigbee-Features zu den Gladys-Features. Sobald ich das besser verstehe, denke ich, dass wir deine Geräte leicht einrichten können.
Es wäre gut, wenn wir eine Session zusammen auf Google Meet machen könnten, um alle seltsamen Verhaltensweisen und die Backend-Logs in diesem Fall zu betrachten. Sobald ich ein neues Image habe, schicke ich dir eine Nachricht, um einen Abend (je nach unseren Verfügbarkeiten) zu planen.
Während der Discover-Phase werden alle Kategorien von Features mit einer Umwandlung in convertCategory erkannt (für diejenigen, die zwischen Gladys und Zigbee nicht denselben Namen haben). Falls es Probleme mit nicht kompatiblen Geräten oder fehlenden Features gibt, passiert es hier
Danke, das ist super klar!
Ich mag die Diagramme dafür
Aber von welchen „erwähnten Dateien“ sprichst du?
Ich kann einige davon über die API-Aufrufe finden, aber bei den anderen (den loop-Dateien zum Beispiel)?
Danke für das Schema @cicoub13, das ist wirklich super, so etwas für Neueinsteiger zu haben
Vielleicht könnten wir diese Schemas behalten und sie irgendwo in der Dokumentation unter „Entwickler“ speichern, sobald der Dienst veröffentlicht ist? Behalte sie im Hinterkopf, das könnte nützlich sein!
Zur Information: Am 02. März haben @cicoub13 und ich alle Bugs und Details durchgegangen, die ich finden konnte.
Wir haben die blockierenden Bugs identifiziert, die eine „Produktionsfreigabe“ verhindern, sowie die Nachbesserungen oder neuen Funktionen, die in anderen Versionen implementiert werden können.
Alles liegt jetzt in den Händen von @cicoub13, er beendet das Schreiben der Tests (sacré boulot, bravo à toi ) und generiert hoffentlich eines der letzten Testbilder
Es ist nur noch eine Frage von einem Tag bis zu einem Pull Request und von Wochen, bis er überprüft, modifiziert, genehmigt und in Gladys integriert wird!
Der Druck Aber ja, dieser Anruf half uns, die letzten Fehler gut zu verstehen, und ich kann dieses Wochenende daran arbeiten
Das nächste Bild wird recht stabil sein und es wäre gut, wenn andere Leute mit vielen verschiedenen Geräten testen könnten
Also ist das der große Teil, an dem ich diese Woche arbeite 
Natürlich ist es ohne Tests schwer, eine gute Stabilität zu erreichen…
Wir haben die blockierenden Bugs identifiziert, die eine „Produktionsfreigabe“ verhindern, sowie die Nachbesserungen oder neuen Funktionen, die in anderen Versionen implementiert werden können.
) und generiert hoffentlich eines der letzten Testbilder 
Es ist nur noch eine Frage von einem Tag bis zu einem Pull Request und von Wochen, bis er überprüft, modifiziert, genehmigt und in Gladys integriert wird!