Hallo @pierre-gilles
Ich habe gesehen, dass du die Integration von zwaveJS als veraltet markiert hast. Kommt eine externe Integration?
Stelle ich mir dieselben Fragen?
Letztlich werden alle Integrationen extern sein, oder?
Bis auf MQTT, ZigBee und was weiß ich noch…
Das war @Sescandell, der sie als veraltet markiert hat. Ich lasse ihn dir antworten, er kümmert sich um den gesamten Z-Wave-Bereich 
Eine ausgelagerte Version wird gerade hier finalisiert: GitHub - sescandell/gladys-zwavejs · GitHub
Ich habe die vergangene Woche wegen Urlaub ausgesetzt Ich nehme das Thema diese Woche wieder auf, um die neue Integration wie es sich gehört zu veröffentlichen (sobald sie besser in der Praxis getestet wurde). Ich empfehle noch nicht, eine Migration darauf anzustreben, außer zu Testzwecken: Ich habe noch nicht ausreichend getestet.
Willkommen zurück @Sescandell 
Ein paar Fragen zu dieser externen Integration.
- Übernimmst du genau die aktuelle Integration?
- Werden wir ein Docker-ZWaveJS für ALLES haben, um alles über Gladys zu verwalten (Schlüssel, Geräte, Verknüpfungen, etc.)?
- Können wir zwischen einer externen und einer internen ZWaveJS-Installation wählen?
- Können wir einen „Verknüpfen/Entkoppeln“-Button haben?
- Fügst du die Verfolgung des Energieverbrauchs hinzu?
Kurz gesagt, ich möchte nicht mehr über Jeedom verwalten, sondern über Gladys, der die Verwaltungsfunktionen fehlen, zusätzlich zur bestehenden Zuordnung.
Hallo,
Oula, so viele Dinge…
Was ist dein Fall, ich verstehe die Ausgangssituation nicht?
Ja… eigentlich ist das das ganze Thema hinter dieser Externalisierung: Zunächst nichts ändern, nur sicherstellen, dass dieselbe Funktionalität erreicht wird, aber über eine externe Integration und nicht mehr von Pierre Gilles bei den Entwicklungen abhängig sein (er hat mich tatsächlich dazu gedrängt, dies aufgrund eines PR für die Entwicklung von Z-Wave zu tun).
Nein, das ist nicht das primäre Ziel. Das primäre Ziel ist es, die interne Gladys-Integration durch eine externe zu ersetzen. Aber Z-WaveJS und ein MQTT-Server müssen bereits irgendwo auf der Maschine verfügbar sein.
Das können wir nach Version 1 prüfen. Aber es wird auch Entwicklungen auf Seiten des Gladys SDK erfordern. Die Hinzufügung eines Z-Wave-Knotens erfordert mehrere Schritte und Validierungen. Ich glaube nicht, dass wir alles im SDK haben… wir können prüfen und sehen, was noch fehlt.
Was fehlt dir zu diesem Thema? Ich kann fehlende Daten leicht hinzufügen.
Warum über Jeedom und nicht direkt die Z-WaveJS-Schnittstelle? Von dort aus verwaltet man die Assoziationen und spezifische Debug-Anforderungen. Ich gehe dorthin nur sehr selten (Hinzufügen eines Knotens… Debugging während der Entwicklung, aber sonst…). Was machst du in Jeedom Besonderes?
Danke für dein Feedback @Sescandell, ich verstehe sehr gut eine erste Integration identisch.
Nun, die 30-Minuten-Verbrauchsdaten und 30-Minuten-Kosten, die in der internen Integration für alle elektrischen Geräte, die neben der Leistung auch elektrische Energie verwalten, nicht implementiert wurden 
Also im Moment ist es Jeedom, das den Docker zwavejs verwaltet.
Ja, ich weiß, das ist nicht gut, aber ich war von openzwave zu zwavejs gewechselt, bevor ich mit Gladys an meinen Modulen gearbeitet habe.
Und ich benutze es auch, um zu verknüpfen/zu trennen und eine Netzwerkgesundheitsprüfung durchzuführen.
Dann habe ich etwas in zwavejs verpasst 
, und wenn du Screenshots des Verknüpfungsknopfes hast, wäre ich interessiert.
Also die Idee einer V2, die den Docker zwavejs verwaltet, würde mir sehr gefallen 
Das steht auf der To-do-Liste von @pierre-gilles, das für alle Integrationen umzusetzen
Ein bisschen Hintergrund 
.
Anfangs hatte Gladys eine eher alte Zwave-Integration.
@pierre-gilles hatte dann beschlossen, die Integration zu entfernen und die Geräte wurden in MQTT umgewandelt.
Dann kam zwavejs. Ich hatte nie die Möglichkeit, über einen Knopfdruck zurückzumigrieren. Und meine Geräte waren in vielen Szenen vorhanden.
Deshalb hatte ich nie den Sprung zur neuen Integration gewagt.
Wird das nicht schon verwaltet?
Es gibt eine Welt, in der es funktionieren würde, wenn man einfach den „Migrieren“-Knopf im Gladys MQTT-Interface hinzufügt. Der „Migrieren“-Knopf macht im Grunde nur Datenbankmanipulation: Er richtet die IDs neu aus und entfernt das ursprüngliche Gerät.
Aus der Ferne würde ich sagen: Ja, es würde ausreichen, den „Migrieren“-Knopf auf MQTT hinzuzufügen. Aber da dies nicht die Hauptabsicht dieses Knopfes ist, könnte das systematische Hinzufügen auf diese Integration stören. Das geht meiner Meinung nach über zWave hinaus. Das muss @pierre-gilles entscheiden, was er tun möchte.
Nur zur Info, das ist bereits implementiert und wird in der nächsten Version von Gladys verfügbar sein. 
In diesem Fall denke ich, dass der Fall von @spenceur wirklich ein sehr besonderer Fall ist. Da er Entwickler ist, ist es wahrscheinlich am einfachsten, seinen Fall direkt zu lösen, anstatt einen Button in Gladys hinzuzufügen, der fast niemandem nützen würde. 
@spenceur: Die API, die es ermöglicht, ein Gerät von einer Integration zu einer anderen zu migrieren, ist offen und funktioniert mit allen Integrationen. Du kannst Claude bitten, dir ein kleines Skript zu generieren, um deine beiden Geräte zu migrieren. Was denkst du?
Ich gebe zu, dass ich nur gewartet und nichts versucht habe. Ich würde mich mal umschauen, danke.