NEWS
[Erledigt] Frage zu Breaking Changes im Zigbee Adapter 2.x
-
@homoran sagte in Frage zu Breaking Changes im Zigbee Adapter 2.x:
Was könnte man den machen, damit dieser Testerbereich, der schlussendlich genau das Ziel bei neuen Versionen sein sollte, besser zu "promoten"
Zumindest würde ich den im ChangeLog verlinken.
In diesem Fall ist da ja offenbar auch noch deutlich mehr 'Kommunikationsbedarf' vonnöten, im ChangeLog ist das ja alles nur kurz angerissen, meiner Meinung nach.@thomas-braun said in Frage zu Breaking Changes im Zigbee Adapter 2.x:
Zumindest würde ich den im ChangeLog verlinken.
Genau, hab ich oben ja auch bereits angeregt.
@homoran said in Frage zu Breaking Changes im Zigbee Adapter 2.x:
und das zutrifft, wäre es schade um die dort geleistete Arbeit.
Also ich mache ja Support für den Windows Installer und auch für meinen eigenen kleinen Adapter. Viele Anwender sind da schon überfordert, mal ins Changelog zu gucken oder bei Rückfragen zu liefern, wonach man gefragt hat. Von daher verstehe ich den Frust schon sehr gut.
Speziell zum Test-Bereich: Ich habe den bisher noch nie als einen Bereich gesehen, in dem normale User, die nur Stable Versionen einsetzen, lesen. Ich selbst gucke normalerweise schon ab und an rein und versuche auch mit zu testen, im Moment komme ich nur kaum dazu. Hab seit 4 Wochen einen Hund. :dog2:
Aber wir schweifen ab. Das Problem ist ja schon mit der ersten Antwort gelöst worden.
Nur nochmal die Rückfrage (und sorry, wenn das auch schon im Test Thread oder der Doku steht): Wie kann ich helfen, um die "alten" Datenpunkte für die Geräte, die ich kenne, wieder einzuführen? Ich selbst hab jetzt erst mal meine Scripte angepasst, aber für andere Anwender wäre es bestimmt schöner, wenn einfach alle alten States wieder da wären.
-
@thomas-braun said in Frage zu Breaking Changes im Zigbee Adapter 2.x:
Zumindest würde ich den im ChangeLog verlinken.
Genau, hab ich oben ja auch bereits angeregt.
@homoran said in Frage zu Breaking Changes im Zigbee Adapter 2.x:
und das zutrifft, wäre es schade um die dort geleistete Arbeit.
Also ich mache ja Support für den Windows Installer und auch für meinen eigenen kleinen Adapter. Viele Anwender sind da schon überfordert, mal ins Changelog zu gucken oder bei Rückfragen zu liefern, wonach man gefragt hat. Von daher verstehe ich den Frust schon sehr gut.
Speziell zum Test-Bereich: Ich habe den bisher noch nie als einen Bereich gesehen, in dem normale User, die nur Stable Versionen einsetzen, lesen. Ich selbst gucke normalerweise schon ab und an rein und versuche auch mit zu testen, im Moment komme ich nur kaum dazu. Hab seit 4 Wochen einen Hund. :dog2:
Aber wir schweifen ab. Das Problem ist ja schon mit der ersten Antwort gelöst worden.
Nur nochmal die Rückfrage (und sorry, wenn das auch schon im Test Thread oder der Doku steht): Wie kann ich helfen, um die "alten" Datenpunkte für die Geräte, die ich kenne, wieder einzuführen? Ich selbst hab jetzt erst mal meine Scripte angepasst, aber für andere Anwender wäre es bestimmt schöner, wenn einfach alle alten States wieder da wären.
@gaspode sagte in Frage zu Breaking Changes im Zigbee Adapter 2.x:
kann ich helfen, um die "alten" Datenpunkte für die Geräte, die ich kenne, wieder einzuführen?
wenn ich das richtig in Erinnerung habe, kannst du das auf deiner Installation durchführen.
@asgothian sagte in Tester für Zigbee Adapter 2.0.x gesucht:
Wichtg Die 'breaking changes' werden von Entwicklerseite nicht zurück gedreht. Es besteht die Möglichkeit das Personen die die entsprechenden Geräte haben die 'alten' Datenpunkte wieder aktivieren und deren Funktionalität auch mit dem aktuellen Herdsman gewährleisten. Wir werden dabei durchaus unterstützen - die Haupt-Arbeit muss aber von den Nutzern dieser Geräte geleistet werden: Wir geben Hinweise und Anhaltspunkte wo Anpassungen notwendig sind und wie man an die notwendigen Informationen heran kommt, die Anwender müssen sich um die Programmierung und den Test, bis hin zu einem PR auf den Adapter kümmern. Das können wir aktuell nicht leisten.
A.kein Support per PN! - Fragen im Forum stellen - es gibt fast nichts, was nicht auch für andere interessant ist.
Benutzt das Voting rechts unten im Beitrag wenn er euch geholfen hat.
der Installationsfixer: curl -fsL https://iobroker.net/fix.sh | bash -
-
@gaspode sagte in Frage zu Breaking Changes im Zigbee Adapter 2.x:
kann ich helfen, um die "alten" Datenpunkte für die Geräte, die ich kenne, wieder einzuführen?
wenn ich das richtig in Erinnerung habe, kannst du das auf deiner Installation durchführen.
@asgothian sagte in Tester für Zigbee Adapter 2.0.x gesucht:
Wichtg Die 'breaking changes' werden von Entwicklerseite nicht zurück gedreht. Es besteht die Möglichkeit das Personen die die entsprechenden Geräte haben die 'alten' Datenpunkte wieder aktivieren und deren Funktionalität auch mit dem aktuellen Herdsman gewährleisten. Wir werden dabei durchaus unterstützen - die Haupt-Arbeit muss aber von den Nutzern dieser Geräte geleistet werden: Wir geben Hinweise und Anhaltspunkte wo Anpassungen notwendig sind und wie man an die notwendigen Informationen heran kommt, die Anwender müssen sich um die Programmierung und den Test, bis hin zu einem PR auf den Adapter kümmern. Das können wir aktuell nicht leisten.
A.@homoran said in Frage zu Breaking Changes im Zigbee Adapter 2.x:
wenn ich das richtig in Erinnerung habe, kannst du das auf deiner Installation durchführen.
OK, ich hatte das so aufgefasst, dass das wieder zurück fließen kann/soll. Hab ich aber evtl. auch falsch verstanden. Für mich brauch ich's nicht.
-
@homoran said in Frage zu Breaking Changes im Zigbee Adapter 2.x:
wenn ich das richtig in Erinnerung habe, kannst du das auf deiner Installation durchführen.
OK, ich hatte das so aufgefasst, dass das wieder zurück fließen kann/soll. Hab ich aber evtl. auch falsch verstanden. Für mich brauch ich's nicht.
@gaspode Solltest du eine der alten Device-Definitionen an die neuen Nachrichten anpassen, dann soll das auch zurück fliessen, aber:
Das ist 'abandoned code'. Wenn du das machst und wir es im Adapter einspielen bist Du im Zweifelsfall denen die es Nutzen gegenüber der Anspechpartner wenn zukünftige Änderungen dazu führen das es nicht geht. Wir können und wollen das nicht weiter aktiv Supporten, da wir dafür die Geräte brauchen und einen erheblichen Overhead behalten würden - den kann das aktuelle Entwicklerteam effektiv nicht mehr leisten.
A.
Nachtrag:
Du hattest ja auch wegen der externen Konverter gefragt. Das die plötzlich nicht so weiter gehen liegt auch ein einer Anpassung der ZHC die ohne Ankündigung bei einem minor Versionsupdate plötzlich dazu gekommen ist. So etwas kommt leider immer wieder mal vor.ioBroker auf RPi4 - Hardware soweit wie möglich via Zigbee.
"Shit don't work" ist keine Fehlermeldung, sondern ein Fluch. -
@gaspode Solltest du eine der alten Device-Definitionen an die neuen Nachrichten anpassen, dann soll das auch zurück fliessen, aber:
Das ist 'abandoned code'. Wenn du das machst und wir es im Adapter einspielen bist Du im Zweifelsfall denen die es Nutzen gegenüber der Anspechpartner wenn zukünftige Änderungen dazu führen das es nicht geht. Wir können und wollen das nicht weiter aktiv Supporten, da wir dafür die Geräte brauchen und einen erheblichen Overhead behalten würden - den kann das aktuelle Entwicklerteam effektiv nicht mehr leisten.
A.
Nachtrag:
Du hattest ja auch wegen der externen Konverter gefragt. Das die plötzlich nicht so weiter gehen liegt auch ein einer Anpassung der ZHC die ohne Ankündigung bei einem minor Versionsupdate plötzlich dazu gekommen ist. So etwas kommt leider immer wieder mal vor.Um hier nochmal auf die BREAKING Dinge einzugehen.
- Natürlich ist es so, dass die BREAKING Infos im README stehen müssen (und es auch tun).
- Natürlich stehen die bei der 2.0.0 bzw. dor wo sie aktiv wurden.
- Es ist normal, dass erst eine spätere Version (ev. erst 2.1.x) ins STABLE kommt.
- Meines Erachtens kann man und sollte man NICHT diese Breaking Informationen aktiv in spätere Versionen kompieren. Zum Zeitpunkt der Ersztellung einer version ist ja noch nicht mal bekannt ob diese ins Stable Repo kommt - oder sich noch Probleme zeigen.
An sich ist es Aufgabe des Users ALLE changelogs, insbesondere aber alle Changelogs ab einem MAJOR versionssprung zu lesen. Diese findet er NUR im Changelog auf Github. Nur weil technisch bedingt nur die letzten x (ich glaube 7) Releases u d ihre Changelogs beim Installationsuodate anbgezeigt werden (können).
Nur leider schaut kaum mal wer in die Releasenotes...
ABER
Für wirklich wichtige BREAKING CHANGES die dem User wirklich engetrichtert werden müssen gibts es eine Alternative / zusätzliche Möglichkeit. Bitte verwendet dafür doch die NEWs Funktionalität / io-package.json MESSAGE Entry. Damit kann man am definieren, dass bei Update von irgendeiner Version (z.B. <2.0.0) auf irgendeine Version (z.B. >=2.0.0) eine Meldung bei der Installation angezeigt wird. Diese muss der User dann auch bestätigen. Damit ist zumindest bei Usern die die GUI benutzen sichergestellt, dass er VOR der Installation eines Updates die wichtigsten Infos erhält. (Ob die CLI Updates die news Angezeigt werden weiß ich nicht - CLI User sind aber zieloch sicher erfahrene User und sollten wissen was ein Major Update ist und dass man doch einen Blick in den Changelog werfen sollte.)Ein Beispiel dazu - gibt aber auch noch andere :-) :
https://github.com/iobroker-community-adapters/ioBroker.snmp/blob/c424acc7abc23e8db06ce6c0225a66118f7176d3/io-package.json#L171Und ja, man könnet überlege die Testertopics zwingend zu machen - das wär aber ein Thema fürs unsere Meetings ob sowas gewunschen ist und vor allem wie vorgegangen werden soll, wenn es ein Dev nicht mag / macht - bspw durch Anlagen eines Topics via Admin etc? - aller Dinge die zu besprechen wären wenn der Bedarf / Sinn erstmal geklärt ist.
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
-
Um hier nochmal auf die BREAKING Dinge einzugehen.
- Natürlich ist es so, dass die BREAKING Infos im README stehen müssen (und es auch tun).
- Natürlich stehen die bei der 2.0.0 bzw. dor wo sie aktiv wurden.
- Es ist normal, dass erst eine spätere Version (ev. erst 2.1.x) ins STABLE kommt.
- Meines Erachtens kann man und sollte man NICHT diese Breaking Informationen aktiv in spätere Versionen kompieren. Zum Zeitpunkt der Ersztellung einer version ist ja noch nicht mal bekannt ob diese ins Stable Repo kommt - oder sich noch Probleme zeigen.
An sich ist es Aufgabe des Users ALLE changelogs, insbesondere aber alle Changelogs ab einem MAJOR versionssprung zu lesen. Diese findet er NUR im Changelog auf Github. Nur weil technisch bedingt nur die letzten x (ich glaube 7) Releases u d ihre Changelogs beim Installationsuodate anbgezeigt werden (können).
Nur leider schaut kaum mal wer in die Releasenotes...
ABER
Für wirklich wichtige BREAKING CHANGES die dem User wirklich engetrichtert werden müssen gibts es eine Alternative / zusätzliche Möglichkeit. Bitte verwendet dafür doch die NEWs Funktionalität / io-package.json MESSAGE Entry. Damit kann man am definieren, dass bei Update von irgendeiner Version (z.B. <2.0.0) auf irgendeine Version (z.B. >=2.0.0) eine Meldung bei der Installation angezeigt wird. Diese muss der User dann auch bestätigen. Damit ist zumindest bei Usern die die GUI benutzen sichergestellt, dass er VOR der Installation eines Updates die wichtigsten Infos erhält. (Ob die CLI Updates die news Angezeigt werden weiß ich nicht - CLI User sind aber zieloch sicher erfahrene User und sollten wissen was ein Major Update ist und dass man doch einen Blick in den Changelog werfen sollte.)Ein Beispiel dazu - gibt aber auch noch andere :-) :
https://github.com/iobroker-community-adapters/ioBroker.snmp/blob/c424acc7abc23e8db06ce6c0225a66118f7176d3/io-package.json#L171Und ja, man könnet überlege die Testertopics zwingend zu machen - das wär aber ein Thema fürs unsere Meetings ob sowas gewunschen ist und vor allem wie vorgegangen werden soll, wenn es ein Dev nicht mag / macht - bspw durch Anlagen eines Topics via Admin etc? - aller Dinge die zu besprechen wären wenn der Bedarf / Sinn erstmal geklärt ist.
@mcm1957 said in Frage zu Breaking Changes im Zigbee Adapter 2.x:
Für wirklich wichtige BREAKING CHANGES die dem User wirklich engetrichtert werden müssen gibts es eine Alternative / zusätzliche Möglichkeit. Bitte verwendet dafür doch die NEWs Funktionalität / io-package.json MESSAGE Entry. Damit kann man am definieren, dass bei Update von irgendeiner Version (z.B. <2.0.0) auf irgendeine Version (z.B. >=2.0.0) eine Meldung bei der Installation angezeigt wird. Diese muss der User dann auch bestätigen.
Das war bei dem Update auf Zigbee 2.x auch der Fall, also vom Ablauf war das alles vorbildlich gemacht. Ich hatte halt das Problem, dass ich den Test Thread nicht gefunden hatte. Letztendlich war es ja auch nur eine Frage, die beantwortet wurde, nämlich, dass nach dem Updates einige Properties der Zigbee Devices weg fallen. Das habe ich aus den Breaking Changes aus dem Log nicht heraus lesen können (rückblickend lag das wahrscheinlich daran, dass "Exposes" nicht in Zusammenhang mit den resultierenden States gesehen habe):
- switch to converters 21 changes the exposes for a large numbern of devices (mostly remotes)
- new method for controlling color based on subchannels for rgb, hs and xy
- Exposes as default for ALL devices. Use of old definition as option only
Im Test Thread ist es dann ja erklärt, und für mich persönlich war es dann ja auch gut (hatte eh schon auf Verdacht angefangen, meine Scripte umzustellen). Für andere User, die sich evtl. mühsam Blocklies zusammen kopiert haben, stellt das aber u.U. halt ein größeres Problem dar, insbesondere wenn sie dann mit Sprüchen wie "zeig mal ein bisschen mehr Initiative" noch mehr frustriert werden (und damit meine ich ausdrücklich NICHT @Asgothian , der mir sehr nett und kompetent geholfen hat und noch hilft).
Und nochmal ganz deutlich: Ich bin allen Entwicklern hier sehr dankbar für ihren Einsatz und bin immer wieder begeistert, was ioBroker alles bietet. Ich bin auch immer bereit, konstruktiv mit Problemen umzugehen und beim Testen zu helfen, wenn es die Zeit zulässt. Also, nochmal Danke! Und jetzt versuche ich weiter Version 3 des Adapters unter meiner Windows Installation zum Laufen zu bekommen. Dazu dann aber wahrscheinlich morgen mehr im anderen Thread.
-
Um hier nochmal auf die BREAKING Dinge einzugehen.
- Natürlich ist es so, dass die BREAKING Infos im README stehen müssen (und es auch tun).
- Natürlich stehen die bei der 2.0.0 bzw. dor wo sie aktiv wurden.
- Es ist normal, dass erst eine spätere Version (ev. erst 2.1.x) ins STABLE kommt.
- Meines Erachtens kann man und sollte man NICHT diese Breaking Informationen aktiv in spätere Versionen kompieren. Zum Zeitpunkt der Ersztellung einer version ist ja noch nicht mal bekannt ob diese ins Stable Repo kommt - oder sich noch Probleme zeigen.
An sich ist es Aufgabe des Users ALLE changelogs, insbesondere aber alle Changelogs ab einem MAJOR versionssprung zu lesen. Diese findet er NUR im Changelog auf Github. Nur weil technisch bedingt nur die letzten x (ich glaube 7) Releases u d ihre Changelogs beim Installationsuodate anbgezeigt werden (können).
Nur leider schaut kaum mal wer in die Releasenotes...
ABER
Für wirklich wichtige BREAKING CHANGES die dem User wirklich engetrichtert werden müssen gibts es eine Alternative / zusätzliche Möglichkeit. Bitte verwendet dafür doch die NEWs Funktionalität / io-package.json MESSAGE Entry. Damit kann man am definieren, dass bei Update von irgendeiner Version (z.B. <2.0.0) auf irgendeine Version (z.B. >=2.0.0) eine Meldung bei der Installation angezeigt wird. Diese muss der User dann auch bestätigen. Damit ist zumindest bei Usern die die GUI benutzen sichergestellt, dass er VOR der Installation eines Updates die wichtigsten Infos erhält. (Ob die CLI Updates die news Angezeigt werden weiß ich nicht - CLI User sind aber zieloch sicher erfahrene User und sollten wissen was ein Major Update ist und dass man doch einen Blick in den Changelog werfen sollte.)Ein Beispiel dazu - gibt aber auch noch andere :-) :
https://github.com/iobroker-community-adapters/ioBroker.snmp/blob/c424acc7abc23e8db06ce6c0225a66118f7176d3/io-package.json#L171Und ja, man könnet überlege die Testertopics zwingend zu machen - das wär aber ein Thema fürs unsere Meetings ob sowas gewunschen ist und vor allem wie vorgegangen werden soll, wenn es ein Dev nicht mag / macht - bspw durch Anlagen eines Topics via Admin etc? - aller Dinge die zu besprechen wären wenn der Bedarf / Sinn erstmal geklärt ist.
@mcm1957 sagte in Frage zu Breaking Changes im Zigbee Adapter 2.x:
Für wirklich wichtige BREAKING CHANGES die dem User wirklich engetrichtert werden müssen gibts es eine Alternative / zusätzliche Möglichkeit. Bitte verwendet dafür doch die NEWs Funktionalität / io-package.json MESSAGE Entry. Damit kann man am definieren, dass bei Update von irgendeiner Version (z.B. <2.0.0) auf irgendeine Version (z.B. >=2.0.0) eine Meldung bei der Installation angezeigt wird. Diese muss der User dann auch bestätigen. Damit ist zumindest bei Usern die die GUI benutzen sichergestellt, dass er VOR der Installation eines Updates die wichtigsten Infos erhält. (Ob die CLI Updates die news Angezeigt werden weiß ich nicht - CLI User sind aber zieloch sicher erfahrene User und sollten wissen was ein Major Update ist und dass man doch einen Blick in den Changelog werfen sollte.)
Ein Beispiel dazu - gibt aber auch noch andere :
https://github.com/iobroker-community-adapters/ioBroker.snmp/blob/c424acc7abc23e8db06ce6c0225a66118f7176d3/io-package.json#L171Vielen Dank für den Hinweis - das schaue ich mir an.
A.
ioBroker auf RPi4 - Hardware soweit wie möglich via Zigbee.
"Shit don't work" ist keine Fehlermeldung, sondern ein Fluch. -
@mcm1957 sagte in Frage zu Breaking Changes im Zigbee Adapter 2.x:
Für wirklich wichtige BREAKING CHANGES die dem User wirklich engetrichtert werden müssen gibts es eine Alternative / zusätzliche Möglichkeit. Bitte verwendet dafür doch die NEWs Funktionalität / io-package.json MESSAGE Entry. Damit kann man am definieren, dass bei Update von irgendeiner Version (z.B. <2.0.0) auf irgendeine Version (z.B. >=2.0.0) eine Meldung bei der Installation angezeigt wird. Diese muss der User dann auch bestätigen. Damit ist zumindest bei Usern die die GUI benutzen sichergestellt, dass er VOR der Installation eines Updates die wichtigsten Infos erhält. (Ob die CLI Updates die news Angezeigt werden weiß ich nicht - CLI User sind aber zieloch sicher erfahrene User und sollten wissen was ein Major Update ist und dass man doch einen Blick in den Changelog werfen sollte.)
Ein Beispiel dazu - gibt aber auch noch andere :
https://github.com/iobroker-community-adapters/ioBroker.snmp/blob/c424acc7abc23e8db06ce6c0225a66118f7176d3/io-package.json#L171Vielen Dank für den Hinweis - das schaue ich mir an.
A.
@asgothian
Ein Hinweis:
Wenn du das TESTEN willst musst du es in die Systemobjekte in die Repository Daten kopieren. Das geht nicht anders da ja admin VOR der Installation die INfo haben muss. Wird bei normalen Update vom repobuilder erledigt. Aber wenn du's teste willst musst die Repodaten "faken". Mehr Infos ggF auf Telegram - wird hier zu offtopicEntwicklung 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
-
@asgothian
Ein Hinweis:
Wenn du das TESTEN willst musst du es in die Systemobjekte in die Repository Daten kopieren. Das geht nicht anders da ja admin VOR der Installation die INfo haben muss. Wird bei normalen Update vom repobuilder erledigt. Aber wenn du's teste willst musst die Repodaten "faken". Mehr Infos ggF auf Telegram - wird hier zu offtopic -
@mcm1957 Danke.. muss ich mich erst einlesen - ich meld mich via discord. Hab kein telegram.
A.
@asgothian
Discord ist genauso OK da ja bekanntermasßen gespiegelt... -
@mcm1957 sagte in Frage zu Breaking Changes im Zigbee Adapter 2.x:
Für wirklich wichtige BREAKING CHANGES die dem User wirklich engetrichtert werden müssen gibts es eine Alternative / zusätzliche Möglichkeit. Bitte verwendet dafür doch die NEWs Funktionalität / io-package.json MESSAGE Entry. Damit kann man am definieren, dass bei Update von irgendeiner Version (z.B. <2.0.0) auf irgendeine Version (z.B. >=2.0.0) eine Meldung bei der Installation angezeigt wird. Diese muss der User dann auch bestätigen. Damit ist zumindest bei Usern die die GUI benutzen sichergestellt, dass er VOR der Installation eines Updates die wichtigsten Infos erhält. (Ob die CLI Updates die news Angezeigt werden weiß ich nicht - CLI User sind aber zieloch sicher erfahrene User und sollten wissen was ein Major Update ist und dass man doch einen Blick in den Changelog werfen sollte.)
Ein Beispiel dazu - gibt aber auch noch andere :
https://github.com/iobroker-community-adapters/ioBroker.snmp/blob/c424acc7abc23e8db06ce6c0225a66118f7176d3/io-package.json#L171Vielen Dank für den Hinweis - das schaue ich mir an.
A.
@asgothian said in Frage zu Breaking Changes im Zigbee Adapter 2.x:
Vielen Dank für den Hinweis - das schaue ich mir an.
Wie gesagt, das ist für Version 2 auch perfekt umgesetzt. Der Hinweis kommt und muss auch bestätigt werden. Ich hatte lediglich Verständnisprobleme. s.o.
Es ist halt oft schwierig, Dinge für "Unwissende" zu erklären, wenn man tief im Thema steckt. Ein "Achtung: Nach dem Update werden für einige Geräte diverse States nicht mehr verfügbar sein. Scripts müssen ggfs angepasst werden. Mehr Info unter <Link zum Test Thread>" hätte mir persönlich sehr geholfen. -
@asgothian said in Frage zu Breaking Changes im Zigbee Adapter 2.x:
Vielen Dank für den Hinweis - das schaue ich mir an.
Wie gesagt, das ist für Version 2 auch perfekt umgesetzt. Der Hinweis kommt und muss auch bestätigt werden. Ich hatte lediglich Verständnisprobleme. s.o.
Es ist halt oft schwierig, Dinge für "Unwissende" zu erklären, wenn man tief im Thema steckt. Ein "Achtung: Nach dem Update werden für einige Geräte diverse States nicht mehr verfügbar sein. Scripts müssen ggfs angepasst werden. Mehr Info unter <Link zum Test Thread>" hätte mir persönlich sehr geholfen.Jep
Für Umstieg uf 2.0.0 ist ne Message drinnen:
https://github.com/ioBroker/ioBroker.zigbee/blob/31026b41a23c87c7efb99183c32fb0f9a11ea923/io-package.json#L199Für Umstieg von 2.x.x. auf 3.x.x keine keine drinnen. Kann abe rnicht beurteilen, ob da eine sinnvoll wäre.
-
Wie deutlich noch?
Zwar V3 aber auch dort steht es:
Ich kann @Asgothian ´s Frust nachvollziehen.
Und er ist schon jemand , der die Changelogs wirklich mit "Leben" füllt.@haselchen said in Frage zu Breaking Changes im Zigbee Adapter 2.x:
Zwar V3 aber auch dort steht es:
Nur, um das Thema abzuschließen. Es ging NICHT um das Häkchen, das nach Update auf V3 gesetzt werden muss. Da steht ja für jeden verständlich im Changelog der V3 drin.
Es ging darum, dass einige States mit V2 weggefallen sind und ich - als Zigbee Unwissender - den Teil des Changelogs von V2 nicht richtig verstanden habe und ich auch nichts gefunden habe, was das erklärt. Daher hab ich diesen Thread hier eröffnet und die Sache wurde ja auch innerhalb von Minuten aufgeklärt. Nochmals Danke dafür. -
@haselchen said in Frage zu Breaking Changes im Zigbee Adapter 2.x:
Zwar V3 aber auch dort steht es:
Nur, um das Thema abzuschließen. Es ging NICHT um das Häkchen, das nach Update auf V3 gesetzt werden muss. Da steht ja für jeden verständlich im Changelog der V3 drin.
Es ging darum, dass einige States mit V2 weggefallen sind und ich - als Zigbee Unwissender - den Teil des Changelogs von V2 nicht richtig verstanden habe und ich auch nichts gefunden habe, was das erklärt. Daher hab ich diesen Thread hier eröffnet und die Sache wurde ja auch innerhalb von Minuten aufgeklärt. Nochmals Danke dafür.Keine Ahnung, warum Du dieses Zitat anführst .
Da ging es um die „Breaking Change“ Aussage.
In diesen Kontext warst Du gar nicht involviert.Aber Schwamm drüber …. nun sind wir alle auf dem aktuellen (Wissens-)Stand 😎
825
Online32.4k
Benutzer81.5k
Themen1.3m
Beiträge