Philips Hue Gerätetyp bearbeiten

Ich verstehe nicht, warum du das machen willst? Hatten wir nicht gesagt, dass wir einfach nur die Feature-Kategorie in einen Schalter ändern müssen (siehe Editer le type de feature des devices Philips Hue - #10 par pierre-gilles )

Hallo @pierre-gilles,
Und zwar geht es um deine eigene Anfrage mit @AlexTrovato zu diesem Thema: https://community.gladysassistant.com/t/pouvoir-modifier-les-pieces-des-divers-features-composant-un-device-avec-multiples-relais/5935/7?u=terdious,
also merken:

Ursprünglich wolltet ihr das mit dem Modell machen. Aber wenn wir das tun, beschränken wir uns auf Philips Hue. Aber es gibt enorm viele Steckdosen wie diese. Die Sonoff-Relais sind in derselben Situation.
Kurz gesagt, um die Spur des ursprünglichen Geräts zu behalten, wie denkst du, dass man das anders als in der Datenbank machen könnte. Oder ich habe den besonderen Punkt deines Vorschlags nicht verstanden, dafür entschuldige ich mich.

Ich sehe nicht, warum das auf Philips Hue beschränkt sein sollte!

Aktuell, in jeder Integration, wenn wir ein Gerät erhalten, verwenden wir die Daten, die von der Integration bereitgestellt werden, um zu entscheiden, welche Gerätekategorie diesem Gerät zugewiesen wird.

Das Einzige, was ich vorschlage, ist, dass wir statt zu sagen « dieser Schalter ist ein Schalter, Punkt », sagen « dieser Schalter ist ein Schalter, aber er könnte in ein Licht umgewandelt werden, weil an diesem Schalter eine Lampe angeschlossen sein könnte ».

Um zu entscheiden, ob wir diesen Schalter anzeigen, schlage ich vor, die gleichen Kriterien zu verwenden, die wir verwenden, um zu entscheiden, ob es ein Schalter ist (wir verlieren diese Information nicht).

Ich weiß, das ist schwer zu erklären ^^

Stimmt, mein Fehler, ich habe überhaupt nicht geschrieben, was ich dachte ^^. Ich stellte mir vor, eine gemeinsame Variable zu erstellen, die alle betroffenen Modelle auflistet. Was natürlich Unsinn ist. Kein Problem ^^

Eigentlich gar nicht. Mit deinen Erklärungen ist das klar ^^ nun, denke ich ^^
Allerdings sind wir uns heute einig, dass wir auf der Frontseite kein Werkzeug haben, um das zu tun, denn soweit ich verstehe, möchtest du, dass wir:

  • eine neue Aktion auf der Frontseite erstellen, um die Variable « lights » von Philips Hue abzurufen und die Kategorie bei jedem Poll bei der Ankunft abzurufen.
  • wenn es sich um einen « switch-binary » handelt, zeigen wir den Toggle.
  • wenn Toggle :check_mark:, ändern wir die Kategorie in light, wenn nicht markiert, ändern wir die Kategorie in ihren ursprünglichen Zustand.
  • und wir zeigen in der Funktion die Grundkategorie an.

Wenn das stimmt, denke ich, dass ich es schaffen kann. Könntest du aber meinen Vorschlag in der PR ansehen. Er ist funktionsfähig und testbar. Denn in diesem Vorschlag muss nur noch in jeder Integration geändert werden, wie das Gerät erstellt wird (durch Hinzufügen eines Parameters), und der Rest ist für alle identisch.

Ich habe gerade deinen PR @Terdious durchgesehen, ich denke nicht, dass wir die Typänderung so implementieren wollen. Das macht in Bezug auf die Datenbankmodellierung keinen Sinn (es verletzt viele Paradigmen der Datenbankmodellierung). Ich finde, das ist ein bisschen Basteln da ^^

Okay, danke, dass du dir das angesehen hast und für dein Feedback.

Allerdings ist da nichts zusammengebastelt. Ich bin nämlich Automatisierungstechniker / GMAO-Administrator und GMAO-Datenbankadministrator. Und in unserem Bereich funktioniert das so, alles, was Einstellungen betrifft, wird immer in der Datenbank gespeichert, daher mein Vorschlag ^^. Allerdings funktioniert es vielleicht in der reinen Informatik anders. Ich bin hier, um dazuzulernen ^^ Falls du Zeit hast, mir zu erklären, wie du das siehst, denn ich sehe nicht, wie ich diese Daten abrufen kann, ohne erneut auf das Gerät zurückgreifen zu müssen. In jedem Fall haben wir mit ein paar Leuten darüber gesprochen, vielleicht fehlt in der Tabelle device_feature eine Spalte, oder?

Ich bin nach wie vor sehr daran interessiert, das umzusetzen!!

Ich habe die Antwort nicht parat :slight_smile: Ich muss mich erstmal in das Thema einarbeiten, aber ich denke, wir können uns das ansehen, nachdem ich mit der Multi-User-Funktion fertig bin? (Ich glaube, das ist wichtiger, vor allem für dich aha :stuck_out_tongue: )

Aber klar doch!!^^ Und ich muss noch Netatmo fertig machen^^ Wir sehen uns danach!!

Ich habe einen PR-Vorschlag für die Typänderung (Steckdose → Licht) gemäß dem Gerätemodell gemacht.

https://github.com/GladysAssistant/Gladys/pull/1108

Die Unterstützung dieser Änderung erfolgt nur auf der Frontend-Seite und basiert auf einer Methode zur Bestimmung, ob die Kategorie des Features geändert werden kann.

Hier, für Tasmota, kenne ich die Licht-Typmodelle, ich prüfe also, ob mein Feature ein Schalter / Binär ist und ob das Gerätemodell nicht in der Liste der als Licht identifizierten Typen steht.
In diesem Fall erlaube ich nur die Bearbeitung der Kategorie (nicht des Typs).

Genial! Das ist genau das Richtige, finde ich, das ist doch reines Frontend.

Hallo,
ich habe ein Docker-Image mit der Funktion erstellt, die Kategorie eines Features für Tasmota-Geräte zu ändern, jedoch nur, wenn es sich um Steckdosen handelt.

Dadurch kann ein Gerät, das mit einem Feature „Steckdose/Schalter“ erkannt wurde, in eine Lampe geändert werden.

Die Einschränkungen/Beschränkungen für die Änderung sind absichtlich streng, um sicherzustellen, dass die ausgelöste Aktion korrekt ist.

Die Änderungen wurden an der gemeinsamen grafischen Komponente vorgenommen, indem eine Option hinzugefügt wurde, die es ermöglicht, die Kategorie während der Bearbeitung zu ändern.

Zur Erinnerung: Nur für Tasmota, vorerst.

Falls Interessierte das Verhalten testen/überprüfen möchten, hier das Docker-Image.
atrovato/gladys:change-feature-category
https://hub.docker.com/layers/171261089/atrovato/gladys/change-feature-category/images/sha256-70adc5aeecf3fd192ac2047ba1e63b0fece4f83bb1d96c121a3c5bf1ead386da?context=repo

Sobald diese Funktion validiert ist, können wir sie auf jeden Dienst erweitern.

Danke.

Hallo @AlexTrovato,

Tests deiner PR durchgeführt mit einem Sonoff 4CH:

  • Änderung von 2 der Schalter-Features zu Beleuchtung: :white_check_mark:
Sonoff 4CH bei der Entdeckung:

Sonoff 4CH nach Modifikation:

  • Integration der 4 Features im Dashboard in 2 separate Boxen, eine mit den 2 Schaltern und eine mit den 2 Beleuchtungen.
  • Test des Einschaltens der 2 Schalter nacheinander: :white_check_mark:.
    :eight_spoked_asterisk: Der Hauptschalter der Box bewegt sich nicht (Hinweis auch für @pierre-gilles, immer dieselbe Bemerkung, man würde erwarten, dass er alle Binärwerte der Box steuert. Also welchen Sinn hat es, ihn anzuzeigen, wenn es keine Beleuchtung in der Box gibt?)
  • Test des Einschaltens der 2 Beleuchtungen nacheinander: :white_check_mark:. Der Schalter der Box leuchtet beim Einschalten der ersten Beleuchtung korrekt auf.
  • Test des Einschaltens des Boxenschalters: :white_check_mark:. Beide Beleuchtungen gehen an

Fortsetzung der Tests: Steuerung durch Kategorie in Szenen

  • :eight_spoked_asterisk: Gut, ich weiß, das ist nicht das Problem dieser PR, aber es ist besser, es überall zu erwähnen: @pierre-gilles, es ist immer noch unmöglich, festzustellen, um welches Feature es sich handelt, wenn es mehrere Features derselben Kategorie gibt, sowohl im Trigger als auch in der Aktion « Gerät steuern ». Die Anzeige des Namens des Features für die entsprechenden Integrationen wäre notwendig.


  • :eight_spoked_asterisk: Auch ist es unmöglich, eine Beleuchtung unabhängig zu steuern, wenn mehrere Beleuchtungen in verschiedenen Räumen zum selben Gerät gehören. Aber die Aktion « Gerät steuern » hilft gut. Es kann dennoch frustrierend sein, die dafür vorgesehene Aktion nicht verwenden zu können ^^ Das Gleiche gilt für Steckdosen.

  • Erstellung verschiedener Szenen:

  1. Trigger: 1. Schalter auf EIN / Aktion 1: Gerät steuern: 2. Schalter auf EIN / Aktion 2: Gerät steuern: 1. Beleuchtung auf EIN - Ok :white_check_mark:
  2. Trigger: 1. Beleuchtung auf AUS / Aktion 1: Gerät steuern: 1. Schalter auf AUS / Aktion 2: Gerät steuern: 2. Beleuchtung auf AUS - Ok :white_check_mark:
  3. Trigger: 1. Schalter auf EIN / Aktion: Licht einschalten: Sonoff 4CH - Ergebnis: 1. Beleuchtung eingeschaltet, also ok :white_check_mark:, aber 2. Beleuchtung nicht eingeschaltet :sos: (Vermutung: Wenn ein Gerät 2 Kategorien Light/Binary enthält, gibt es kein for each. Nur das erste Feature wird berücksichtigt.)
  4. Trigger: 1. Beleuchtung auf EIN / Aktion: Steckdose einschalten: Sonoff 4CH - Ergebnis: 1. Schalter eingeschaltet, also ok :white_check_mark:, aber 2. Schalter nicht eingeschaltet :sos: (Vermutung: Wenn ein Gerät 2 Kategorien Switch/Binary enthält, gibt es kein for each. Nur das erste Feature wird berücksichtigt.)
  • Letzter Test: Neustart des Containers und Überprüfung. Alles ist gut persistent :white_check_mark:

Ich hoffe, das hilft dir. Für die PR selbst sehe ich nichts zu beanstanden. Danke @AlexTrovato

Kannst du einen Screenshot davon machen, wie es in dem Teil aussieht, wo du den Typ der Features änderst? :slight_smile:

Arf, das muss irgendwo nicht vermerkt sein, weil ich es komplett vergessen hatte :sweat_smile: Entschuldigung!

Ich habe ein Issue erstellt, damit es nicht verloren geht:

Entschuldigung, ich hatte den Bug überhaupt nicht im Kopf.

Ich habe ein Github-Issue erstellt:

Das erinnert mich daran, dass wir bald einen Weg finden müssen, um das Git besser zu organisieren, denn es gibt so viele Issues / PRs, dass ich mich komplett darin verliere, ich schaue es kaum noch an, weil es ein Chaos ist…

Ah, die Box „Licht an“ wurde unter der Annahme entworfen, dass Geräte vom Typ „Lampe“ zwangsläufig nur ein Feature haben. Wenn die Box alle Lichter des ausgewählten Geräts einschaltet, würde das für dich funktionieren? :slight_smile:

Genau, die Box wurde unter der Annahme erstellt, dass eine Lampe nur ein einziges Binär-Feature hat. Wenn ich alle Binärwerte des Geräts einschalte, wäre das in Ordnung? Wenn es in Ordnung ist, muss ein Github-Issue erstellt werden, sonst geht es in einer Minute verloren :stuck_out_tongue:

Aber klar ^^ Hier für 4CH

Entschuldige dich bitte nicht, ich bin hauptsächlich verantwortlich, ich gebe die Dinge immer im Forum an, aber seit Beginn habe ich nur 1 oder 2 Issues auf Github erstellt. Als regelmäßiger Beitragender sollte ich das durchsetzen. Ich gebe zu, dass mir die Zeit fehlt (wie uns allen natürlich) und dass es mich meistens 1 Stunde kostet, einen Beitrag zu erstellen, der eigentlich nur 5 bis 10 Minuten dauern sollte. Das hindert mich sehr oft daran, auf Github zu gehen und ihn zusätzlich auf Englisch zu übersetzen… und da ich Schwierigkeiten habe, mich gut auszudrücken oder zu lange Beiträge zu verfassen… kurz gesagt, ich schweife ab. Ich werde mich ein bisschen mehr anstrengen!! :sweat_smile:

Vielen Dank!

In der Tat!! Da Gladys V4 immer mehr an Umfang gewinnt und jetzt doch viele Dinge integriert, wird es komplexer ^^ Das ist in gewisser Weise eine gute Sache :wink:

Also, in diesem Fall gebe ich wirklich meine Meinung dazu ab, aber es wird wahrscheinlich von anderen bestätigt werden müssen. Jedes Mal, wenn ich auf diese Box gehe, erwarte ich (ebenso für die Aktion „Steckdose(n) ein/aus“ natürlich):

  • Dass sie mir alle Geräte anzeigt, die mindestens eine Beleuchtung enthalten.
  • Dass ich ein Gerät auswählen kann, das nur eine Beleuchtung hat
  • Wenn das Gerät mehrere Beleuchtungsfunktionen enthält:
    • Dass ich das gesamte Gerät auswählen kann (z. B. mit dem Namen des Geräts am Ende „(Alle Beleuchtungen)“: „Sonoff 4CH (Alle Beleuchtungen)“ und dass es alle Beleuchtungsfunktionen dieses Geräts steuert
    • Dass ich eine Beleuchtungsfunktion des Geräts auswählen kann: „Sonoff 4CH - Badezimmerbeleuchtung“ oder „Sonoff 4CH - WC-Beleuchtung“ und dass es nur diese Funktion steuert.

Alle möglichen Szenarien sind dann „möglich“ :slight_smile:

Das ist sauber!

Ok, also wenn ich das richtig verstehe, müssen wir aufhören, in „Geräten“ zu denken, sondern immer in „Funktionen“.

Stattdessen sollte der Geräteauswahl ein Funktionsauswahl ersetzt werden.

Das wird nicht einfach zu ändern sein (es muss migriert werden), aber es muss gemacht werden, ich erstelle ein GitHub-Issue dafür:

Es wird aber nicht sofort sofort sein, es ist viel Arbeit ^^

Danke für das Feedback!

Ich hatte bereits ein Issue zum Wechsel der Box erstellt

Ah gut gesehen! Ich schließe meine :slight_smile:

Zur Funktionalität: Funktionell ist das für mich in Ordnung.

Ich habe eine technische Rückmeldung zum Code des Pull Requests gegeben.

@pierre-gilles, @AlexTrovato,
Ich erlaube mir, ein wenig nachzuschlagen, nachdem ich das gesamte Gespräch noch einmal gelesen habe. Wir sind uns einig, dass diese Funktion bereits bereitgestellt wurde, aber nur für alle Geräte mit einem „Bearbeiten“-Button?

@AlexTrovato, da diese Funktion mit der Frontend verbunden ist, sind wir uns einig, dass nur noch der „Bearbeiten“-Button zur Philips Hue-Integration hinzugefügt werden muss? Wenn das der Fall ist, werde ich mich darum kümmern.

Es gab eine Entwicklung einer ähnlichen Funktion in einer anderen Integration, ja, aber nicht in der Philips Hue-Integration.