Alpha Tester für Zigbee Adapter v2.0

[Asgothian]

Hallo,

nachdem die Tests mit der 1.11.x Version wenig erfolgversprechend waren haben wir (die Zigbee-Entwickler) uns dazu entschlossen eine neue Version mit einer grösseren Zahl an 'breaking changes' fertig zu machen. Diese läuft aktuell Immer noch unter 1.11, wird aber wahrscheinlich als Version 2.0 veröffentlicht werden.

Für diese Version werden Tester gesucht. Folgendes wird sich ändern:

• Alle Geräte werden auf Basis der von Zigbee2mqtt.io vorgegebenen Exposes im ioBroker implementiert. (Bereits aktiv - bitte testen, kommentieren)
• Es soll möglich sein für einzelne Gerätetypen auf die 'alten' Definitionen aus dem Zigbee Adapter v1.10.x zurück zu greifen - dazu gibt es den Tab 'Legacy Devices'. Geräte die hier eingetragen sind werden die alten Definitionen nutzen. Das kann dazu führen das bestimmte Funktionen nicht mehr gegeben sind, wenn die alten Definitionen nicht mit den aktuellen Zigbee-herdsman-convertern zusammen spielen. Dieses wird von uns zunächst nicht aktualisiert. Anpassungen können auf Basis von (noch zu erzeugenden) Log-Meldungen als PR's am Adapter eingereicht werden (ohne die Meldungen auch gerne jetzt schon) (Bereits aktiv, bitte testen, kommentieren). Nach dem Anpassen der Legacy Overrides muss der Adapter neu gestartet und ein State-Cleanup durchgeführt werden um die Anpassungen zu sehen.
• Es soll möglich sein für einzelne Geräte (später auch Gerätetypen) eigene Bilder zu definieren. (Bereits aktiv - bitte testen, kommentieren) Das passiert in 3 Schritten:
  -- Schritt 1: das Gewünschte Bild als PNG (Grösse < 100 kb) in das Datenverzeichnis des Zigbee Adapters (oder ein Unterverzeichnis davon) kopieren (/opt/iobroker/iobroker-data/zigbee_x , wobei x die Instanz-Nummer ist.
  -- Schritt 2: auf der umgedrehten Kachel das neue Bild auswählen
  -- Schritt 3: ein Upload des Zigbee Adapters durchführen.
  Erst nachdem alle 3 Schritte erfolgreich durchgeführt wurden wird das neue Bild im Adapter genutzt.
• es soll möglich sein (analog zu den externen Konvertern) externe Device-Definitionen machen zu können. (aktuell nicht implementiert)
• die Optionen zum verwalten der Gruppen sollen verbessert werden, so das Geräte von der Gruppen-Kachel aus der Gruppe entfernt werden können. (aktuell nicht implementiert)

Wichtig Diese Adapter-Version ist im Alpha-Stadium. Nicht weil sie besonders oft abstürzt, sondern weil sich bei der Erstellung der States aus den Exposes noch Anpassungen ergeben werden. Eine Nutzung als Produktiv-Adapter ist daher nicht empfohlen

Zum testen muss der aktuelle Test-branch von meinem GitHub installiert werden. (Link: https://github.com/asgothian/ioBroker.zigbee/tarball/1.11).

An Vorschlägen wie einzelne Funktionalitäten angepasst / verbessert werden können bin ich interessiert.

A.
Nachtrag: Nochmal ganz deutlich - wer diesen Adapter auf seinem aktiven ioBroker nutzt riskiert das er bei jeder neuen Version weitere Anpassungen am Umfeld (Skripte, Visualisierungen) durchführen muss. Auch ist der Adapter aktuell nur mit wenigen Koordinatoren getestet - auch da können Auffälligkeiten auftreten. Installation auf eigene Gefahr !!!

[Asgothian]

Platzhalter für bugs / Ideen / anstehende Anpassungen

[arteck]

isch guck

[arteck]

@Asgothian
sieht gut aus .. ab und an geht der nicht

[Asgothian]

@arteck schau ich mir an. Gibt’s Fehlermeldungen auf der Browser Konsole ?

[arteck]

@asgothian sagte in Alpha Tester für Zigbee Adapter v2.0:

@arteck schau ich mir an. Gibt’s Fehlermeldungen auf der Browser Konsole ?

würde sagen ist erstmal zweitrangig... aber ich schau

[mcm1957]

@asgothian

Nur als Anregung für ev spätere alpha tests:

Im Prinzip könnt ihr gerne auch neue 2.x.x-alpha.x Releases auf npm hochladen. Sofern das mit dem standrmäßigen Workflow passiert werden -alpha.x Releases auf npm NICHT mit latest getagged und erscheinen daher nicht im LATEST Repository sind aber via ui und commandline unter Verwendung der "url" iobroker.zigbee@next (oder iobroker.zigbee@2.0.0-alpha-x) dann installierbar. ACHTUNG: Bei manuellem Deploy setzt npm automatisch das Tag LATEST was zu einem Veröffentlichen im Repo fürhen würde. Manuelle Deploys sind daher nur dann sinnvoll wenn ihr auch die Tags richtig mitgebt.

Ist aber in jedem Fall eure Entscheidung. Spricht auch nichts gegen direkte GH Installation. <

[arteck]

@mcm1957 das Verfahren ist mir bekannt. aber lieber nein... man sollte schon wissen was man mit dem neuen Repo veranstalten kann..
und wen die Bude dunkel bleibt weil.. ohh hab nicht aufgepasst.. ne lieber nicht

estra repo ist hier besser

[mcm1957]

@arteck
OK- Ich hab nicht gesehen dass das Ganze ja in einem anderen Repo stattfindet. Da macht das definitiv keinen Sinn (wenns überhaupt ginge). Hab im Geiste nur neue Major (und branch) gesehen.

[Asgothian]

@arteck Kannst du nochmal schauen - ich hatte gepatzt - es waren nicht alle geplanten Änderungen aktiv.

A.