wie du möchtest 
aber da es sich um ein falscher Freund handelt und einen anderen Sinn in der französischen Sprache hat, kann es in der UI anders interpretiert werden. Ich hätte eher für „Lokalisierung“ plädiert, ansonsten gibt es auch „Situation“ oder „Position“, aber okay für ihren Jargon, da ich kein Z-Wave habe, werde ich mich nicht wie eine Mimose verhalten 
Kannst du mir eine technische Bewertung geben?
Mich interessieren besonders die Datenformat-Entscheidungen bei der external_id und dem name 
Ich habe ein paar Kommentare gemacht, darunter einen speziellen zur Konsistenz zwischen den external_id des Geräts und der Features… Gute Arbeit
Danke für dein Feedback @AlexTrovato, alles ist korrigiert (ich habe Kommentare zu einigen Rückmeldungen hinzugefügt)
Ich habe einen Docker-Build erstellt, der bereits fertig ist:
gladysassistant/gladys:zwavejs-ui-integration
Ich freue mich auf jedes Feedback in der Praxis!
Viel besser für die Konfiguration, aber andererseits habe ich es geschafft, ein Gerät ohne Feature zu erstellen 
Ist das an sich ein Problem?
lol nein 
Für den Code ist es für mich in Ordnung.
Für die Tests kann ich nicht weitergehen, da ich nicht die passenden Geräte habe.
Versuchst du subtil, an Equipment zu kommen? 
Ich habe den verbundenen Broker installiert, aber ich kann auch nicht weiter testen.
Falls ich in meinen Ferien Zeit habe, werde ich schauen, ob ich meine Geräte hinzufügen kann.
Ich habe meine Tests fortgesetzt und einige Probleme gefunden. Vielleicht hast du die Punkte während des Livestreams angesprochen, aber ich hatte keine Zeit, 7,5 Stunden Video in meinen Tag zu quetschen. Ich werde es während meines Urlaubs ansehen.
Ich war überrascht, keine Nachrichten zu erhalten, dass die Geräte noch nicht entwickelt sind.
Also habe ich den Scan überprüft und wenn man den Befehl fixiert, muss man irgendwo angeben, dass das Präfix und der MQTT-Name, den man in der Z-wave JS UI konfiguriert hat, dieselben sein müssen wie die, die im Befehl verwendet werden.
Im Scan hast du geschrieben:
this.publish('zwave/_CLIENTS/ZWAVE_GATEWAY-zwave-js-ui/api/getNodes/set', 'true');
Aber ich habe in Zwave zwave2mqtt statt zwave-js-ui eingegeben und zum Glück habe ich das Präfix zwave
Nachdem ich die Parameter geändert habe, funktioniert es gut, ich habe die Liste aller meiner Geräte (nicht unterstützt)
Nachdem die Geräte erkannt wurden, sehe ich zwei Probleme. Das erste ist, dass ich sie speichern kann, obwohl sie nicht unterstützt werden. Das ist ein Detail, aber ich denke, dass es stören könnte.
Das zweite Problem betrifft den Namen. Ich habe ein Gerät pro Raum mit dem Namen Heizkörper (insgesamt fünf). Jetzt weiß ich nicht, welches welches ist. Ich könnte den Namen in der zwave-js-ui ändern, aber das erscheint mir nicht logisch, da es einen Heizkörper verwaltet.
In ZwaveJSUI werden sie durch « location » unterschieden.
Vielleicht « location » anzeigen?
Ich mache weiter und denke, dass für die Hinzufügung von Geräten auch einige Dinge geändert werden müssen. Ich werde eine andere Nachricht dazu schreiben, wenn ich es besser angesehen habe.
Hallo,
Was mich besonders interessiert, sind die Datenformat-Entscheidungen für die external_id und den name
Was ist die Absicht hinter dieser externen ID?
Ich habe mich an die Integration eines zusätzlichen Geräts gemacht (eine Steckdose mit einem einfachen Ein-/Ausschalter). Ich bin skeptisch, dass der nodeId nicht als eindeutige und von der Position/name unabhängige Kennung verwendet wird. Wenn ich mich nicht im Funktionsumfang geirrt habe, erfordert das Senden von Werten (zum Beispiel zum Ausschalten/Einschalten der Steckdose) diesen nodeId.
Ich habe auch nicht am gesamten Live-Stream teilgenommen. Vielleicht hast du die Gründe für dieses « Format » erwähnt.
Ich bin offen für einen Austausch zu diesem Punkt. Ich habe auch noch ein paar andere Geräte, die ich anschließend integrieren könnte.
Danke
Der externe ID ist die eindeutige Kennung, die es ermöglicht, ein Gerät/eine Funktion unter Verwendung der „externen“ Kennungen auf der Integrationsseite zu identifizieren. Dadurch kann die Zuordnung zwischen unseren internen Kennungen und der externen Kennung hergestellt werden.
Tatsächlich scheint im Fall eines Geräts mit « Steuerung » der nodeID erforderlich zu sein. Bei Sensoren ist es umgekehrt, location/name ist obligatorisch und der nodeId wird nicht bereitgestellt… nicht besonders konsistent, aber gut, wir werden damit arbeiten
Daher müssen wir beide Fälle verwalten können: Identifikation eines Geräts nur über location/name und Identifikation eines Geräts nur über NodeId.
Ich denke, wir könnten eventuell zu meinem ursprünglichen Vorschlag zurückkehren:
- externe ID des Geräts mit dem nodeId
- externe ID der Funktion mit der location+name
Ah tatsächlich, du hast recht! Das muss in der Oberfläche angegeben werden. Danke für den Hinweis
Ja, das könnte man eventuell machen!
Wenn man sich dein exampleData anschaut, gibt es doch diese Idee von value updated:
Ich habe diese Art von Sensoren nicht, um diese Änderung zu validieren (sie kommt nächste Woche an). Aber wenn du mir vorher das MQTT ZWaveJSUI-Log schicken könntest, könnte uns das mehr verraten.
Das hängt vielleicht auch von deiner Konfiguration in ZWaveJS UI ab: Einstellungen MQTT > Gateway > « Z-Wave-Ereignisse senden »
Danke,
Ich habe das Gerät erhalten, konnte einen Test durchführen und bestätige, dass das Ereignis node_value_updated tatsächlich gesendet wird:
Topic: zwave/_EVENTS/ZWAVE_GATEWAY-zwave-js-ui/node/node_value_updatedQoS: 0
{
"data": [
{
"id": 4,
"inited": true,
"name": "Detecteur Ouverture",
"location": "Entree",
"status": 1,
"isControllerNode": false,
"interviewStage": 5,
"deviceClass": {
"basic": "Routing Slave",
"generic": "Notification Sensor",
"specific": "Notification Sensor",
"mandatorySupportedCCs": [],
"mandatoryControlCCs": []
},
"zwavePlusVersion": 1,
"ready": true,
"zwavePlusRoleType": 6,
"isListening": false,
"isFrequentListening": false,
"canSleep": true,
"isRouting": true,
"supportedDataRates": [
40000,
100000
],
"maxDataRate": 100000,
"supportsSecurity": false,
"isSecure": false,
"supportsBeaming": true,
"protocolVersion": 3,
"firmwareVersion": "3.2",
"manufacturerId": 271,
"manufacturer": "Fibargroup",
"productId": 4096,
"productDescription": "Fibaro Door Window Sensor 2",
"productType": 1794,
"productLabel": "FGDW002",
"deviceDatabaseUrl": "https://devices.zwave-js.io/?jumpTo=0x010f:0x0702:0x1000:3.2",
"keepAwake": false
},
{
"commandClassName": "Notification",
"commandClass": 113,
"property": "Access Control",
"propertyKey": "Door state",
"endpoint": 0,
"newValue": 23,
"prevValue": 22,
"propertyName": "Access Control",
"propertyKeyName": "Door state"
}
]
}
Meiner Meinung nach ist die Logik, auf node_value_updated umzusteigen, die richtige. Damit vermeidet man Probleme mit der Benennung/Standort und alles wird über die nodeId verwaltet (man verwendet die ZWave-ID für den Knoten und für die Features).
Ich habe gerade den PR aktualisiert: [ZWaveJS-UI] Manage Binary Switch by sescandell · Pull Request #1996 · GladysAssistant/Gladys · GitHub
Der Status wird jetzt von Gladys im Fall eines Binary Switch verwaltet (das öffnet die Tür für andere Geräte).
Wir haben einen neuen Gerätetyp, der kein Sensor ist (eine Steckdose), und der bei Updates (über das Dashboard) oder aus einer Szene heraus funktioniert, indem er beispielsweise auf den Zustandswechsel des Türöffnungssensors reagiert.
[Update] (das Forum lässt mich nicht mehr als 3 aufeinanderfolgende Nachrichten hinzufügen)
Kleine Überlegung: Seht ihr einen Nachteil darin, den Begriff « ui » aus dem Begriff « zwavejs-ui » im Code der Integration zu entfernen und einfach nur von « zwavejs » zu sprechen? (@pierre-gilles)
Ich denke, die aktuelle Integration ist auf einem guten Weg und sauber genug, um eine Migration auf zwavejs ohne den MQTT-Teil in einer mehr oder weniger nahen Zukunft in Betracht zu ziehen (jedenfalls habe ich große Lust, es zu versuchen). Das würde die Integration erheblich vereinfachen. Eine erste, funktionsgleiche Integration wie die aktuelle (also ohne Verwaltung der Assoziation usw.) scheint mir zunächst umsetzbar. Das würde nicht ausschließen, nebenbei sein zwavejs-ui für das Hinzufügen/Entfernen von Geräten außerhalb von Gladys zu haben.
Ich kann mich um die Umbenennung kümmern und sie in den Änderungen vorschlagen, die mit dem laufenden PR verbunden sind. Sobald dieser PR geschlossen ist, kann ich weiterhin Entwicklungen vorschlagen (Migration zu zwavejs, Integration neuer Geräte).
Wir sind hier völlig im Detail, ich gebe es zu, aber in einer Perspektive, in der wir auf zwavejs-ui verzichten und eine direkte Integration von zwavejs vornehmen, wäre es « schade », sich mit diesem Suffix zu belasten.
Tatsächlich hatte ich das nicht gesehen, aber alles ist in Z-Wave JS UI konfigurierbar.
Wenn wir diese Konfiguration verwenden:
Erhalte ich:
zwave/capteur-ouverture/notification/endpoint_0/Access_Control/Door_state_simple
{
"id": "2-113-0-Access Control-Door state (simple)",
"nodeId": 2,
"toUpdate": false,
"commandClass": 113,
"commandClassName": "Notification",
"endpoint": 0,
"property": "Access Control",
"propertyName": "Access Control",
"propertyKey": "Door state (simple)",
"propertyKeyName": "Door state (simple)",
"type": "number",
"readable": true,
"writeable": false,
"label": "Door state (simple)",
"ccSpecific": { "notificationType": 6 },
"stateless": false,
"commandClassVersion": 5,
"min": 0,
"max": 255,
"list": true,
"states": [
{ "text": "Window/door is open", "value": 22 },
{ "text": "Window/door is closed", "value": 23 }
],
"value": 22,
"lastUpdate": 1704966002274,
"nodeName": "capteur-ouverture",
"nodeLocation": "salon"
}
Mit der NodeId!
Damit können wir die Verwendung von Standort und Name vermeiden.
Ich bin ein großer Fan der Option der Z-Wave-„Roh“-Events. Der ganze Mehrwert von Z-Wave JS UI besteht darin, ihre transformierten Events zu verwenden, die sofort einsatzbereit sind.
Ich bevorzuge die Option, die ich oben mit der NodeId angegeben habe.
Wir bleiben so, wie es derzeit ist. Es ist eine Integration mit zwavejs-ui
Für die Integration mit „reinem“ zwavejs bin ich immer weniger dafür. Zwave-js-ui wird täglich erweitert und ermöglicht Dinge, die wir wahrscheinlich nie in Gladys machen werden. Kein Grund, das Rad neu zu erfinden
Es gibt schon seit Monaten/Jahren viele Nutzer wie dich, die hier im Forum große Versprechungen für diese Integration gemacht haben, und ich denke, wir müssen pragmatisch sein.
Mein Ziel ist, dass diese Integration so schnell wie möglich live geht.
Ich werde die Änderung auf die NodeId vornehmen, aber das wird die einzige Änderung sein, die ich vornehme, dann geht die aktuelle Integration so, wie sie ist, in den Produktionsbetrieb
Pragmatismus, Pragmatismus, Pragmatismus!!
Allerdings wäre ich bei diesem Punkt sehr dankbar für Hilfe Vielen Dank für das Angebot!!
Ich habe bereits einen PR auf deinen PR erstellt, in dem ich all das und noch viel mehr berücksichtige. Die Verwendung von node_value_updated scheint mir konsistenter. Es ist getestet und validiert auf echten Geräten.
In diesem Modus hat zwavejs alles richtig formatiert und ähnlich wie bei den Events „pro Gerät“. Das erscheint mir konsistenter und ebenso pragmatisch.
Der Link zum PR für den Fall, dass du ihn nicht gesehen hast, mit weiteren Entwicklungen: [ZWave] Manage Binary Switch by sescandell · Pull Request #1996 · GladysAssistant/Gladys (github.com)
Wenn ich sage, dass ich in diesem Bereich vorankommen kann, dann ist das nicht nur heiße Luft (Beweis ist dieser PR, auf dem ich Entwicklungen für diese Integration vorantreibe). Und ich denke, dass die Verwendung von zwavejs statt zwavejs-ui nichts gefährdet.
Zum Thema Benennung, ich bin gerne bereit zu diskutieren, inwiefern sich das aus Sicht des Benutzers ändert? Wir sind uns einig, dass es sich um eine Hypothese handelt. Ich sage nicht, dass Gladys alles machen muss, was zwavejs-ui macht. Außerdem: Heute oder morgen mit zwavejs in Gladys, für die erweiterte Knotenverwaltung: Du nutzt zwavejs-ui. Die Verwendung von zwavejs in Gladys hindert dich nicht daran. Die hypothetische Aussage ist: „Die Integration in Gladys vereinfachen“ (und nicht zwangsläufig einen zusätzlichen MQTT und ein zusätzliches Node-Projekt haben, das läuft). Aber aktuell ist das nicht das Hauptthema.
Hallo zusammen!
Ich habe einige Korrekturen am PR basierend auf dem Feedback vorgenommen:
- Klare Erklärungen zum verwendeten MQTT-Präfix und den verschiedenen Einstellungen, die in der Z-Wave JS UI erforderlich sind, damit die Integration funktioniert.
- Verwendung der nodeId zur eindeutigen Identifizierung eines Geräts statt location/name.
- Hinzufügen einer Nachricht, um klarzustellen, dass wir uns in der Alpha-Phase dieser Integration befinden und nur ein Gerät verwaltet wird.
Die aktuelle Integration sieht so aus:
Der aktualisierte PR: Z-Wave JS UI integration by Pierre-Gilles · Pull Request #1982 · GladysAssistant/Gladys · GitHub
Ich habe auch an der Dokumentation gearbeitet, die hier in der Demo getestet werden kann:
- Dokumentation FR: Intégrez vos appareils Z-Wave grâce à Z-Wave JS UI | Gladys Assistant
- Dokumentation EN: Integrate your Z-Wave devices with Z-Wave JS UI | Gladys Assistant
Der Zeitplan
Ich hatte es versprochen, die Wette war eine minimale Z-Wave JS UI-Integration, die einen einzigen Sensor verwaltet, an einem Tag, und die Wette ist gehalten!
Die Integration wird heute im Laufe des Tages zusammengeführt und am Montag in Gladys Assistant v4.35.0 bereitgestellt.
Ich freue mich auf euer Feedback, falls ihr welches habt, bis dahin
@Sescandell Ich habe deine PR gesehen und es ist großartige Arbeit! Ich denke, wir haben uns missverstanden, was den Pragmatismus angeht. Ich sprach von deinem Wunsch, zu reinem Z-Wave JS zu wechseln. Für den Rest (deine aktuelle PR usw.) bin ich zu 100% mit dir einverstanden und ich freue mich auf deine Hilfe, um später weitere Kompatibilitäten hinzuzufügen!
Nur eine kleine Rückmeldung zur Dokumentation, die Links funktionieren nicht:
Sollte der Link nicht eher Z-Wave JS UI sein?