NEWS
Alpha Tester für Zigbee Adapter v2.0
-
@Asgothian
sieht gut aus .. ab und an geht der nicht
-
@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
zigbee hab ich, zwave auch, nuc's genauso und HA auch
-
Version 2.0:
- Ansteuerung der Farbe via 'color' Datenpunkt. Nimmt an:
-- #rrggbb
-- JSON, wie bei zigbee2mqtt.io beschrieben, jeweils passend zu dem was das Gerät akzeptiert.
-- "named" Farben von hier - Ansteuerung mit Hue/Saturation bzw. X/Y, bzw. getrennt Rot,Grün,Blau über die entsprechenden 'channel' Datenpunkte. Dabei wird aktuell 500 ms (5s bei Änderungen aus dem Admin) nach der letzten Anpassung der dp 'color' auf den entsprechenden Wert aktualisiert. Erst dieser Wert wird an die Hardware gesandt.
- Auswahl der 'named color' von der Kachel aus dem Adapter aus möglich.
- states
colortemp_move, hue_move, hue_calibration aktuell entfallen. (20.2. : colortemp_move und hue_move bleiben, hue_calibration wird nicht wieder kommen - muss über sendPayload eingetragen werden) - Exposes sind Standard für alle Geräte.
- Per 'Local Overrides' lassen sich die im Zigbee Adapter fest definierten Gerätedefinitionen (samt Icons) nutzen.
- Bilder / Namen können Geräte und Modellspezifisch angepasst werden. (Gilt für Gruppen und Devices)
- Gruppen-Icons im Objektbaum
- Verbesserung bei Gruppen: Entfernen von Mitgliedern von der Gruppen-Kachel aus möglich (unter "edit name")
- channel exclude samt Inhalt ist obsolete
- state info.groups ist obsolete.
- Map generation schneller, mit Meldungsfenster wenn Fehler beim sammeln der Daten aufgetreten sind (deaktivierbar)
- Datei dev_names.json ist obsolete. Daten werden in komplexerer Datei LocalOverrides.json gespeichert. Eine Übernahme der Daten aus dev_names.json findet Statt sofern es keine LocalOverrides.json gibt.
- Nutzt Zigbee-Herdsman 3.2.2, Zigbee-Herdsman-Converters 21.20.0
- orphaned States (states im Adapter Namespace die nicht vom Adapter gelesen / beschrieben werden) werden im Objektbaum orange markiert
Known bugs:
No adding new Groupsfixed 20.2.
No editing Groupsfixed 20.2.
Card-Background wechselt erst nach Reload wenn im Admin zwischen heller und dunkler Ansicht umgeschaltet wirdA.
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. <
Entwicklung u Betreuung: envertech-pv, hoymiles-ms, ns-client, pid, snmp Adapter;
Support Repositoryverwaltung.Wer Danke sagen will, kann nen Kaffee spendieren: https://paypal.me/mcm1957atiobroker
- Ansteuerung der Farbe via 'color' Datenpunkt. Nimmt an:
-
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. <
@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 nichtestra repo ist hier besser
zigbee hab ich, zwave auch, nuc's genauso und HA auch
-
@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 nichtestra repo ist hier besser
-
@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
-
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.
Edit: Auch wenn der Adapter offiziell noch unter Node 18+ läuft habe ich festgestellt das die verwendeten Bibliotheken auf Node 20 angewiesen sind!
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 !!!Neue Version 1.11.3 auf Github.
- Bugfixes
- Stabilität
- custom Device images device/modell spezifisch
- custom Device Namen device/Modell spezifisch
- Custom images for groups
- composite color
- übernahme von dev_names.json in die neue Device-spezifische Konfiguration
Über Tests / Testberichte würde ich mich freuen.
Wichtig:
- installieren
- starten
- device cleanup durchühren
Insbesondere bräuchte ich Tests mit Farb-Lampen/Leuchten, da ich an der Farbe einiges getan hab:
- Ansteuerung des 'color' Datenpunktes ist möglich mit allen Optionen die bei zigbee2mqtt.io für das Topic 'color' vorgesehen sind - plus die Namen von Web-Colors.
- Ansteuerung der einzeldatenpunkte r g b sowie x y und hue saturation wird über den color Datenpunkt gezogen. Wichtig: Wenn angesteuert durch ein Skript aktuell 500 ms delay zwischen Aktualisierung der Werte und erzeugen des neuen Wartes für color. Wenn angesteuert über den Admin: 5 s Zeit.
Bekannte Bugs:
Map does not workEdit: Map is fixed
ioBroker auf RPi4 - Hardware soweit wie möglich via Zigbee.
"Shit don't work" ist keine Fehlermeldung, sondern ein Fluch. -
Neue Version 1.11.3 auf Github.
- Bugfixes
- Stabilität
- custom Device images device/modell spezifisch
- custom Device Namen device/Modell spezifisch
- Custom images for groups
- composite color
- übernahme von dev_names.json in die neue Device-spezifische Konfiguration
Über Tests / Testberichte würde ich mich freuen.
Wichtig:
- installieren
- starten
- device cleanup durchühren
Insbesondere bräuchte ich Tests mit Farb-Lampen/Leuchten, da ich an der Farbe einiges getan hab:
- Ansteuerung des 'color' Datenpunktes ist möglich mit allen Optionen die bei zigbee2mqtt.io für das Topic 'color' vorgesehen sind - plus die Namen von Web-Colors.
- Ansteuerung der einzeldatenpunkte r g b sowie x y und hue saturation wird über den color Datenpunkt gezogen. Wichtig: Wenn angesteuert durch ein Skript aktuell 500 ms delay zwischen Aktualisierung der Werte und erzeugen des neuen Wartes für color. Wenn angesteuert über den Admin: 5 s Zeit.
Bekannte Bugs:
Map does not workEdit: Map is fixed
zigbee hab ich, zwave auch, nuc's genauso und HA auch
-
@arteck Du meinst die Farbe des Koordinators ? Der sollte erst sauber eingefärbt sein wenn du die Karte hast aufbauen lassen. Bei den Cards ist es ein bekannter bug, das die Hintergrundfarbe der Karten beim Umstellen der Farben nicht aktualisiert wird - das passiert dann erst bei einem neu laden.
A.
ioBroker auf RPi4 - Hardware soweit wie möglich via Zigbee.
"Shit don't work" ist keine Fehlermeldung, sondern ein Fluch. -
@arteck Du meinst die Farbe des Koordinators ? Der sollte erst sauber eingefärbt sein wenn du die Karte hast aufbauen lassen. Bei den Cards ist es ein bekannter bug, das die Hintergrundfarbe der Karten beim Umstellen der Farben nicht aktualisiert wird - das passiert dann erst bei einem neu laden.
A.
@asgothian sagte in Alpha Tester für Zigbee Adapter v2.0:
n. Bei den Cards ist es ein bekannter bug,
den hab ich damals ausgebaut.. na ja egal...
Du meinst die Farbe des Koordinators ? Der sollte erst sauber eingefärbt sein wenn du die Karte hast aufbauen lassen
die hab ich ...
der ist aber immer noch schwarz
zigbee hab ich, zwave auch, nuc's genauso und HA auch
-
@asgothian sagte in Alpha Tester für Zigbee Adapter v2.0:
n. Bei den Cards ist es ein bekannter bug,
den hab ich damals ausgebaut.. na ja egal...
Du meinst die Farbe des Koordinators ? Der sollte erst sauber eingefärbt sein wenn du die Karte hast aufbauen lassen
die hab ich ...
der ist aber immer noch schwarz
@arteck spannend - die Farben kommen bei mir richtig an. Ich schau mir das nochmal an
Weisst du wann du den Fehler mit den Kacheln ausgbaut hast (ungefähr ?) Bei mir war der gefühlt nie wegioBroker auf RPi4 - Hardware soweit wie möglich via Zigbee.
"Shit don't work" ist keine Fehlermeldung, sondern ein Fluch. -
@arteck spannend - die Farben kommen bei mir richtig an. Ich schau mir das nochmal an
Weisst du wann du den Fehler mit den Kacheln ausgbaut hast (ungefähr ?) Bei mir war der gefühlt nie wegWeisst du wann du den Fehler ausgbaut hast (ungefähr ?)
du weisst ja mit dem Alter das ist so ne Sache....
mach du erstamal.. isch guck dann mal -
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.
Edit: Auch wenn der Adapter offiziell noch unter Node 18+ läuft habe ich festgestellt das die verwendeten Bibliotheken auf Node 20 angewiesen sind!
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 !!!heute morgen ist bei mir die Version 2.0 im latest aufgetaucht, ich habe noch nicht das Update durchgeführt, wollte erstmal fragen, da keine Breaking Changes dabei standen:
device cleanup notwendig?
lt. dem Thread hier sollte ja einige States anders sein, ok, das seh ich.. bei 240 Devices wird das aber nur sichtbar, wenn ich kein cleanup mache ( sonst seh ich ja nicht, was neu ist) wuerde die neuen States rausschreiben und dann ein Cleanup machen.Beim State cleanup werden alle Funktionen und Räume gelöscht? Falls ja, müsste ich alles neu zuordnen..?
Ich hoffe, die Namen bleiben erhalten?
Die Entwicklung dahin ist sehr gut und war wahrscheinlich ein Haufen Arbeit, vielen Dank !
-
heute morgen ist bei mir die Version 2.0 im latest aufgetaucht, ich habe noch nicht das Update durchgeführt, wollte erstmal fragen, da keine Breaking Changes dabei standen:
device cleanup notwendig?
lt. dem Thread hier sollte ja einige States anders sein, ok, das seh ich.. bei 240 Devices wird das aber nur sichtbar, wenn ich kein cleanup mache ( sonst seh ich ja nicht, was neu ist) wuerde die neuen States rausschreiben und dann ein Cleanup machen.Beim State cleanup werden alle Funktionen und Räume gelöscht? Falls ja, müsste ich alles neu zuordnen..?
Ich hoffe, die Namen bleiben erhalten?
Die Entwicklung dahin ist sehr gut und war wahrscheinlich ein Haufen Arbeit, vielen Dank !
@neuschwansteini Bitte diese Version aktuell nicht installieren. Es kommt die Tage eine aktualisierte (bessere) Version im Latest.
Zu den Breaking changes - es gibt sie !. Ein entsprechender Hinweis wird bei der oben angekündigten Version kommen.
- ja, die States die vom Adapter nicht mehr unterstützt werden sind im Objektbaum sichtbar.Auch der 'state cleanup' button ist nur vorhanden wenn es solche 'orphaned states' gibt.
- der State-Cleanup löscht ausschliesslich die 'orphaned states'. Alle anderen werden nicht angefasst. Allerdings gibt es keine automatische Zuordnung zu Räumen/Funktionen. Im Log wird jeder gelöschte State protokolliert, so das du ggf. eine Liste aller 'orphaned' states nach dem State-Cleanup aus dem Log ziehen kannst.
- Der Grossteil der Changes sind uns von aussen (zigbee-herdsman-converters Bibliothek) vorgegeben worden. Es gab eine theoretische Möglichkeit das abzufedern - auf die entsprechende Anforderung das getestet wird kam so wenig Reaktion das ich das einstellen musste.
- Die Namen der Geräte bleiben erhalten.
A.
- ja, die States die vom Adapter nicht mehr unterstützt werden sind im Objektbaum sichtbar.Auch der 'state cleanup' button ist nur vorhanden wenn es solche 'orphaned states' gibt.
-
@neuschwansteini Bitte diese Version aktuell nicht installieren. Es kommt die Tage eine aktualisierte (bessere) Version im Latest.
Zu den Breaking changes - es gibt sie !. Ein entsprechender Hinweis wird bei der oben angekündigten Version kommen.
- ja, die States die vom Adapter nicht mehr unterstützt werden sind im Objektbaum sichtbar.Auch der 'state cleanup' button ist nur vorhanden wenn es solche 'orphaned states' gibt.
- der State-Cleanup löscht ausschliesslich die 'orphaned states'. Alle anderen werden nicht angefasst. Allerdings gibt es keine automatische Zuordnung zu Räumen/Funktionen. Im Log wird jeder gelöschte State protokolliert, so das du ggf. eine Liste aller 'orphaned' states nach dem State-Cleanup aus dem Log ziehen kannst.
- Der Grossteil der Changes sind uns von aussen (zigbee-herdsman-converters Bibliothek) vorgegeben worden. Es gab eine theoretische Möglichkeit das abzufedern - auf die entsprechende Anforderung das getestet wird kam so wenig Reaktion das ich das einstellen musste.
- Die Namen der Geräte bleiben erhalten.
A.
super, gut, dass ich nachgefragt habe.. :)
Sehr gut programmiert, dann kann ja (fast) nix schiefgehen. - ja, die States die vom Adapter nicht mehr unterstützt werden sind im Objektbaum sichtbar.Auch der 'state cleanup' button ist nur vorhanden wenn es solche 'orphaned states' gibt.
-
super, gut, dass ich nachgefragt habe.. :)
Sehr gut programmiert, dann kann ja (fast) nix schiefgehen. -
Seit 2 Tagen ist die V2 auf npm. Wie kommts, dass bei mir weiterhin nur die 1.14 gefunden und geladen wird? Ich bin auf Stable.
@maxpd sagte in Alpha Tester für Zigbee Adapter v2.0:
Wie kommts, dass bei mir weiterhin nur die 1.14 gefunden und geladen wird?
wo und wie versuchst du es?
@maxpd sagte in Alpha Tester für Zigbee Adapter v2.0:
Ich bin auf Stable.
könnte je nach Vorgehen ein Grund sein
-
@maxpd sagte in Alpha Tester für Zigbee Adapter v2.0:
Wie kommts, dass bei mir weiterhin nur die 1.14 gefunden und geladen wird?
wo und wie versuchst du es?
@maxpd sagte in Alpha Tester für Zigbee Adapter v2.0:
Ich bin auf Stable.
könnte je nach Vorgehen ein Grund sein
@homoran sorry, wollte ich gerade ergänzen ;)
Über die normale suche an adaptern wird 1.10.14 ausgegeben.
Bei installation aus eigener URL, wobei ich da nur npm wähle und zigbee eingebe, wird latest, also 2.0 installiert - wobei verfügbar weiterhin mit 1.10.14 ausgegeben wird.Gruß
maxpdRaspi 4 8gb | iobroker + pivccu3 | 46 Adapter | 68 Scripte, 120 Devices
-
@homoran sorry, wollte ich gerade ergänzen ;)
Über die normale suche an adaptern wird 1.10.14 ausgegeben.
Bei installation aus eigener URL, wobei ich da nur npm wähle und zigbee eingebe, wird latest, also 2.0 installiert - wobei verfügbar weiterhin mit 1.10.14 ausgegeben wird.@maxpd sagte in Alpha Tester für Zigbee Adapter v2.0:
Über die normale suche an adaptern wird 1.10.14 ausgegeben.
klar, wenn du im stable bist
@maxpd sagte in Alpha Tester für Zigbee Adapter v2.0:
Bei installation aus eigener URL, wobei ich da nur npm wähle und zigbee eingebe, wird latest, also 2.0 installiert
nicht das (3. Reiter) sondern npm, wie beschrieben.
@maxpd sagte in Alpha Tester für Zigbee Adapter v2.0:
wobei verfügbar weiterhin mit 1.10.14 ausgegeben wird.
klar, wenn du weiterhin im stable bist
-
@homoran sorry, wollte ich gerade ergänzen ;)
Über die normale suche an adaptern wird 1.10.14 ausgegeben.
Bei installation aus eigener URL, wobei ich da nur npm wähle und zigbee eingebe, wird latest, also 2.0 installiert - wobei verfügbar weiterhin mit 1.10.14 ausgegeben wird.
Support us
774
Online32.4k
Benutzer81.5k
Themen1.3m
Beiträge