Am 7. ist mein Geburtstag. Aber ich feiere ihn am 8. ![]()
Vielleicht ist es dann schon zu spät, aber warum nicht.
Am 7. verfügbar? Mein Geburtstag ist am 6. und ich feiere am 7. abends, daher abends nicht verfügbar ![]()
Der 8. und 9. werden produktiv ![]()
Er hat viel Krebs
!!
Alles Gute zum Geburtstag @AlexTrovato !! ![]()
Also, heute anrufen oder nicht? Ich bin bis etwa 16 Uhr verfügbar, wenn ihr wollt
Mist, alles Gute zum Geburtstag @pierre-gilles und alles Gute zum Geburtstag @AlexTrovato
Ich bin dabei, wenn ihr Bock habt
Alles Gute zum Geburtstag euch beiden ![]()
Ich antworte etwas spät, aber ich kann heute noch bis ca. 14 Uhr teilnehmen, sonst komme ich zum nächsten Anruf.
Alles Gute zum Geburtstag @pierre-gilles ich trinke gerade den Aperitif, können wir uns anrufen
ich bin den ganzen Tag verfügbar
Rufen wir uns um 14 Uhr hier an? => Réunion Google Meet
Also, wenn du in der Lage bist ![]()
Entschuldigung, ich war nicht schnell genug, ich habe gegessen ![]()
@Romuald_Pochet wärst du in 7 Minuten für ein kurzes Entwicklergespräch verfügbar?
Ich sehe, dass du heute aktiv im Thema Z-Wave warst, dann können wir mit dir darüber sprechen!
Für Info, wir sind mit @AlexTrovato im Call => Réunion Google Meet
Ich bin genervt, ich habe euch verpasst…
Notdienst den ganzen Nachmittag bei der Arbeit…
Könntet ihr uns einen Überblick geben, wenn es nicht zu aufwendig ist?
Und vor allem alles Gute zum Geburtstag @pierre-gilles und @AlexTrovato!!
![]()
![]()
![]()
Ein Kuchen und eine Flasche für jeden, keine Bevorzugung.
Alles Gute zum Geburtstag an euch beide.
Schade! ![]()
Ich mach dir eine Zusammenfassung!
Lixee TIC und komplexe Geräteanzeige in der UI
-
Wir haben über die Anzeige von komplexen Geräten wie Lixee TIC gesprochen, die derzeit in Gladys schwer lesbar sind, weil sie viele Funktionen desselben Typs haben. Für diese Geräte werden wir wahrscheinlich den Feature-Namen im Dashboard und den Szenen anzeigen. Die ganze Arbeit besteht darin, herauszufinden, wie man komplexe/nicht komplexe Geräte erkennt. @AlexTrovato wird sich ein POC ansehen, und wir müssen das vor/nach dem Testen an vollständigen Installationen testen. Die Idee ist, wirklich eine hybride Funktionsweise zu haben und dieses Verhalten nicht zu verallgemeinern, das wirklich nur für Geräte geeignet ist, die aus dem Rahmen fallen.
-
Wir haben über die Leistungsprobleme gesprochen, wenn viele Ereignisse auftreten, wobei dieses Problem auf die synchrone Natur der Node.js EventEmitter zurückzuführen ist. @AlexTrovato wird sich darum kümmern, dass die Ereignisausgabe im „später erledigen“-Modus (sozusagen) erfolgt, damit Node.js nicht blockiert.
Sobald diese beiden Punkte validiert sind, kann die Lixee TIC PR meiner Meinung nach gemerged werden.
Migration Z-WaveJS
@Romuald_Pochet hat uns eine wirklich sehr vielversprechende Demo dessen gezeigt, was er mit ZwaveJS2Mqtt erreicht hat, das bei ihm in der Produktion läuft und wirklich gut aussieht!
Funktional scheint es wirklich gut zu sein, aber bevor wir es in die Produktion mergen können, gibt es drei Dinge zu tun:
- Arbeit an der UI, damit die End-to-End-Funktionalität perfekt ist: Erstellung von Containern usw.
- Abschluss aller Unit-Tests, Cypress-Tests usw., damit der Code sauber und getestet ist
- Herausfinden, wie viele Personen die aktuelle Open-ZWave-Integration in der Produktion verwenden, da diese neue Integration „breaking“ sein wird. Wenn jemand eine bestehende Z-Wave-Installation hat und wir das so pushen, ist seine Installation kaputt. Ich werde mich auf meiner Seite um mehr Telemetrie zu diesem Punkt kümmern, damit wir die tatsächliche Nutzung jeder Integration verfolgen können. Anschließend ist die Idee, je nachdem, wer was verwendet, einen Migrationsplan zu erstellen.
Offensichtlich hat @Romuald_Pochet Anfang August Zeit, um daran zu arbeiten, da wir alle quasi im August im Urlaub sind, können wir meiner Meinung nach nach den Ferien einen Punkt setzen ![]()
Ansonsten, da die aktuelle Open-Zwave-Integration uns bei vielen Themen blockiert: Update von Node 14 auf Node 16, sehr langsames Build im CI aufgrund dessen, Update bestimmter Abhängigkeiten unmöglich aufgrund von Node 14 usw. Wir haben alle gesagt, dass das Ziel jetzt ist, eine erste Version „einfach aber stabil“ zu machen, immer in der Philosophie der v4: Wir machen die Dinge gut, aber wir gehen nicht in alle Richtungen, was die Funktionen betrifft.
Habe ich etwas vergessen?
Für Info @Romuald_Pochet @AlexTrovato @VonOx, ich habe beim Thema der Messung der Nutzung der Integrationen Fortschritte gemacht.
Jeder Dienst muss nun eine Funktion isUsed (derzeit optional) bereitstellen, zum Beispiel im Fall von Z-Wave:
https://github.com/GladysAssistant/Gladys/blob/master/server/services/zwave/index.js#L42
Ich habe auch den Zigbee2mqtt-Dienst gemacht, aber noch nicht die anderen Dienste.
Die Idee ist, das so schnell wie möglich zu pushen, um mehr Informationen über die Nutzung des Z-Wave-Dienstes zu erhalten, und dann sehen wir weiter, was wir tun ![]()
Wird das wirklich die Realität bei der Nutzung der Dienste darstellen? Zum Beispiel nutze ich z-wave, aber der Dienst ist in Gladys deaktiviert. Ich verwende NodeRed zur Verwaltung aller meiner z-wave-Geräte.
Ja, deine Geräte werden nicht als Z-Wave-Dienst, sondern als MQTT-Dienst gezählt.
Genau das ist es, was wir hier herausfinden wollen: Wie stark der aktuelle Open-ZWave-Dienst genutzt wird oder nicht, damit wir die Migrationsmethode entscheiden können, die wir anwenden werden.
Okay, aber es wird nicht einfach sein zu wissen, dass das MQTT-Gerät tatsächlich ein Z-Wave-Gerät ist.
Das ist nicht der Zweck der Funktionality ![]()