Lassen Sie uns über Gladys V4 sprechen

Hallo,

meine Meinung: Aus Nutzersicht sehe ich keinen Sinn darin, Skripte von Szenen zu trennen. Das Skript ist eine der Optionen/Aktionen der Szenen. Tatsächlich würde das Zusammenführen es ermöglichen, ein Skript möglicherweise leichter auszulösen und es mit anderen Elementen der Szenen zu verketten.
Aus technischer Sicht, wenn die Schnittstelle dafür super mega langsam wird, sollte man besser trennen. Aber ich nehme an, es geht nur um eine kleine Latenz, die durch die Anzeige des Editors verursacht wird, also erträglich.

Das ist meine Meinung.

Hallo zusammen!

Heute habe ich an den WebSockets in Gladys 4 gearbeitet.

Um weiterhin so leicht wie möglich zu bleiben, werden native WebSockets verwendet und nicht mehr socket.io wie in Gladys 3. Dies wird die Integration mit mobilen Apps einfacher machen.

Ein kleines Demo-Video, das ich auf Twitter gepostet habe =>

Beim NLP (Natural Language Processing) habe ich auch Fortschritte gemacht.

Alle Sätze im Brain sind in JSON-Konfigurationsdateien definiert, die ich so einfach wie möglich zu verstehen versucht habe.

Wichtiger Hinweis: Wenn ich „einfach zu verstehen“ sage, meine ich einen Entwickler, der die Gladys-Codebasis unterstützen möchte. Ein Benutzer wird nie etwas damit zu tun haben, es ist Code.

Hier ein Beispiel für eine Konfigurationsdatei:

Für benutzerdefinierte Sätze wird es ein ganz anderer Prozess sein, der derzeit nicht verwaltet wird :slight_smile:

+1 Ich bin einverstanden! Ich werde in diese Richtung versuchen.

Hallo,

Zuerst einmal denke ich, dass es besser ist, das Skript so wie du sagst in eine Szene für alle Personen zu setzen, die Gladys nutzen werden.

Aber ich denke, man kann einen „Entwicklermodus“ hinzufügen, der es ermöglicht, einen Tab hinzuzufügen, wenn man das Kästchen aktiviert, um einen Skript-Tab anzuzeigen, der es ermöglicht, Skripte direkt auf Gladys auszuführen, ohne über Szenen zu gehen.

Zweitens fand ich in Gladys 3 das JSON, das es ermöglicht, Sätze und Aktionen im NLP hinzuzufügen, etwas besonders. Ist es geplant, selbst Aktionen hinzuzufügen? In einem zweiten Schritt, ist es möglich, diese neuen Sätze zu speichern, um sie teilen zu können?
Vielleicht ist das ein Punkt, über den man nachdenken sollte.

Mmm, ich bin nicht unbedingt ein Fan dieser Herangehensweise. Normalerweise, wenn die Benutzeroberfläche gut gemacht ist, warum sollte man dann einen Tab hinzufügen müssen? Lass uns erstmal sehen, wie es aussieht, wenn wir die Skripte in die Szenen einbauen :slight_smile: Vielleicht ist es eine schlechte Idee, aber ohne zu testen, kann man es nicht wissen!

Ja, wie ich oben erwähnt habe, ist das JSON nur für die „nativen“ Sätze, also die Sätze, die jeder standardmäßig hat. Nur die GitHub-Contributor (die erfahrenen Gladys-Entwickler) werden mit dieser Datei arbeiten, nicht der Benutzer.

Um benutzerdefinierte Sätze hinzuzufügen, die speziell für deine Installation sind, z. B.: Wenn ich sage „Es ist Weihnachten!“ => Dann die Szene „Weihnachten“ starten, wird das ein anderer Prozess sein, wahrscheinlich in den Szenenprozess mit Trigger integriert. Der Trigger wird ein Trigger basierend auf einem Satz sein, ganz einfach.

Ich denke, das wird in einem zweiten Schritt kommen. Man könnte tatsächlich eine Share-Funktion oder eine Art interaktive Community-Benutzeroberfläche erstellen, bei der jeder Sätze für die nächste Gladys-Version vorschlagen/upvoten kann (so wie ich es mit der Community-Spreadsheet für Gladys-kompatible Geräte gemacht habe), aber lass uns den Umfang dieser ersten Version minimal halten, um nicht den Überblick zu verlieren!

Hallo zusammen!

Heute habe ich ein nettes kleines Video für euch! :stuck_out_tongue:

Kleines Video der Szeneneditor-Oberfläche und was passiert, wenn man eine Szene testet =>

Ich bin super zufrieden mit dem Szenenausführungsmotor, er funktioniert super und die Möglichkeiten sind endlos :slight_smile:

Allerdings bin ich mit der Szeneneditor-Oberfläche noch nicht zufrieden.. Sie ist etwas schwerfällig, und ich denke, dass es bei einer Szene mit 100 Aktionen schnell unübersichtlich wird. Wenn jemand eine Idee hat, wie man diese Oberfläche klarer gestalten kann, interessiert mich das sehr!

Hallo, ich mag den Stil sehr, er lässt mich vibrieren :wink:
Ansonsten eine kleine Idee für den Fall der 100 Aktionen: Ein System für „Pagination“ / „Slideshow“ einführen. Ich erkläre es:

  • Standardmäßig werden 2 oder 3 Schritte (First + Then) angezeigt
  • Auf der rechten Seite der Seite wird ein Indikator « > » (nächster), und « < » (vorheriger) hinzugefügt, falls vorhanden
  • Und darunter wird eine Art Abkürzung im Stil der Pagination hinzugefügt, um direkt auf die Aktion N zuzugreifen, ohne „Seite für Seite“ zurückkehren zu müssen.

Mmm ich bin nicht begeistert, das wäre sehr schwerfällig als Schnittstelle und wenig flüssig…

Bisher war das Hauptfeedback, das ich überall erhalten habe, dass man auf vertikal statt horizontal umstellen sollte..

Ursprünglich war mein erster Prototyp vertikal, es ist möglich, dass ich einen weiterentwickelten Prototypen vertikal erstelle, um zu vergleichen.

Hier ist mein Vorschlag für eine vertikale Version :slight_smile:

Die Idee ist, eine globale Übersicht der Szene mit Hilfe von ausziehbaren Blöcken zu ermöglichen:
In der großen Ansicht können sie bearbeitet werden, in der kleinen Ansicht sieht man eine Zusammenfassung (möglicherweise gekürzt) der Aktion.
Ich habe auch bedingte Blöcke hinzugefügt, ich weiß nicht, ob das eine geplante Funktion ist :wink:

Idealerweise könnte man jeden Blocktyp mit einem Icon identifizieren.
Was meint ihr dazu? :slight_smile:

Eigentlich ist das Problem doch dasselbe, oder? :smiley: Klar, die Aktionen in Serie sind vertikal, aber die Aktionen, die parallel ausgeführt werden, sind horizontal. Was passiert, wenn du 30 parallele Aktionen hast? Dann hast du horizontal viel Platzbedarf und du brauchst eine horizontale Scroll-Leiste ^^

Ein zusätzlicher Vorschlag: Wenn man vertikal denkt, aber keinen horizontalen Scroll-Bereich haben will, warum nicht Blöcke „Aktionsgruppen“ machen? Jeder Block kann zusammengeklappt oder aufgeklappt werden und enthält eine Reihe von Karten mit allen Aktionen.

So bleibt es sauber und übersichtlich, egal ob man 5 oder 100 Aktionen hat.

Ich überlasse es euch zu raten, womit ich meinen Montag verbracht habe… :smiley:

Es ist noch nicht fertig, aber es kommt gut voran!

Mein Ziel: Absolut alle Funktionen einer Z-Wave-Smart-Home-Box zu haben, sogar die technischsten (z. B. das Mesh-Netzwerkdiagramm von Z-Wave anzeigen).

Der Nutzer muss nicht auf eine andere Smart-Home-Box zurückgreifen, um Konfigurations-/Wartungsarbeiten durchzuführen, alles wird in Gladys sein.

Cool, du hast am Zigbee gearbeitet :blush:

Hallo, super cool!

Wenn du Tester für die Integration brauchst, zögere nicht, ich habe jede Menge Z-Wave-Geräte von verschiedenen Marken/Funktionen.

Also geht es um Module? Können wir jetzt damit beginnen, die V3-Module nach V4 zu migrieren???

Auf jeden Fall!

Ja, es geht um Module!

Noch nicht bereit für die Migration. Im Moment beschäftige ich mich gerade mit großen Modulen, um alle klassischen Probleme der Module zu bereinigen und anschließend eine Dokumentation zu erstellen: „Wie migriert man ein Modul von der V3 zur V4“ :slight_smile: Ich halte euch auf dem Laufenden über den Fortschritt.

Zögere nicht, uns schnell ein „Go“ zu geben, auch wenn noch nicht alles fertig ist. Vielleicht können wir so frühzeitig Probleme erkennen und zur Dokumentation beitragen. Wir können als Testentwickler fungieren.
Und wir könnten auch etwas Zeit bei der offiziellen Veröffentlichung von V4 sparen.
Kurz gesagt, ich bin motiviert :wink:

@AlexTrovato Mach dir mal keine Sorgen, sobald es aus meiner Sicht in Ordnung ist, halte ich euch auf dem Laufenden! :slight_smile:

Derzeit denke ich nicht, dass das der Fall ist.

Das Ziel ist es, eine Reihe von Designproblemen der v3 zu beheben, daher halte ich es für notwendig, dass ich vor der Freigabe an die Entwickler Folgendes schreibe:

  • Entwicklungsrichtlinien
  • Einen Satz automatisierter Tests

Ohne das werden wir die gleichen Probleme haben wie in der v3. Ich möchte mit einer soliden Grundlage für die v4 starten.

Und da ich bisher kaum ganze Dienste geschrieben habe, weiß ich selbst nicht, wie ein „perfekter“ Gladys-4-Dienst aussieht :smiley:

Aber wie du siehst, arbeite ich im Moment wie verrückt (in diesem April arbeite ich 5 von 7 Tagen an Gladys, ich hatte diesen Monat keinen Freelance-Auftrag), also geht es sehr, sehr schnell voran :slight_smile:

Kleine Frage an die Z-Wave-Experten:

In Gladys 4 hat jede Funktion eines Geräts zwingend eine Kategorie.

Wie kann ich im Z-Wave-Protokoll jede Funktion kategorisieren?

Beispiel: Für meinen Fibaro-Bewegungssensor hier ein Beispiel einer comclass, die ich erhalte:

"49": {
        "1": {
          "value_id": "10-49-1-1",
          "node_id": 10,
          "class_id": 49,
          "type": "decimal",
          "genre": "user",
          "instance": 1,
          "index": 1,
          "label": "Temperature",
          "units": "C",
          "help": "",
          "read_only": true,
          "write_only": false,
          "min": 0,
          "max": 0,
          "is_polled": false,
          "value": "27.1"
        },
        "3": {
          "value_id": "10-49-1-3",
          "node_id": 10,
          "class_id": 49,
          "type": "decimal",
          "genre": "user",
          "instance": 1,
          "index": 3,
          "label": "Luminance",
          "units": "lux",
          "help": "",
          "read_only": true,
          "write_only": false,
          "min": 0,
          "max": 0,
          "is_polled": false,
          "value": "105"
        },
        "25": {
          "value_id": "10-49-1-25",
          "node_id": 10,
          "class_id": 49,
          "type": "decimal",
          "genre": "user",
          "instance": 1,
          "index": 25,
          "label": "Seismic Intensity",
          "units": "",
          "help": "",
          "read_only": true,
          "write_only": false,
          "min": 0,
          "max": 0,
          "is_polled": false,
          "value": "0.0"
        }
      },

Wie kann ich diese drei Funktionen (Temperatur, Lichtsensor und Erdbebensensor) identifizieren?

Der Label? Ich habe den Eindruck, dass der Label eher eine Information für den Benutzer ist, oder?

Funktioniert die Kombination aus comclass (hier 49) + Index (1, 3 und 25)? Oder sind diese Zahlen spezifisch für meine Installation?

Heißt das, dass man eine Datenbank aller Z-Wave-Geräte erstellen muss, um die Zuordnung zu machen?

Ich werde meine Recherchen fortsetzen, aber wenn ihr mehr Informationen habt, bin ich dankbar…

Ich war bei Home Assistant und glaube, meine Antwort gefunden zu haben…

https://github.com/home-assistant/home-assistant/blob/dev/homeassistant/components/zwave/const.py

Soweit ich verstanden habe, ist es tatsächlich die Kombination aus comclass und index, die die notwendigen Informationen liefert.

Hier ist comclass 49 = COMMAND_CLASS_SENSOR_MULTILEVEL

INDEX_SENSOR_MULTILEVEL_TEMPERATURE = 1

Falls ihr noch weitere Informationen habt, bin ich immer noch interessiert!

Ein bisschen Datenvisualisierung heute, ich habe an der UI der Z-Wave-Modulseite gearbeitet!

Das sind Testdaten hier, aber in der Realität kann der Benutzer das Mesh-Netzwerkdiagramm seines Z-Wave-Netzwerks visualisieren und so sehen, ob einige Geräte schlecht mit dem Netzwerk verbunden sind :slight_smile:

Hallo Leute, ich mag das Design des Diagramms nicht so sehr.
Aber das scheint sehr interessant zu sein, um Z-Wave von A bis Z zu steuern.

Viel Erfolg und ich gebe zu, dass ich auf die v4 gespannt bin, die mir mit der v3 von Gladys gefehlt hat :wink: !