Frage zu Breaking Changes im Zigbee Adapter 2.x
-
@haselchen sagte in Frage zu Breaking Changes im Zigbee Adapter 2.x:
Wie deutlich noch?
Zwar V3 aber auch dort steht es:
Sind aber auch unterschiedliche breaking changes.
Das ist der Grund für den Versionssprung. Die Major Version geht immer dann hoch wenn es signifikante Änderungen gibt. (1.x auf 2.x: geänderte states, 2.x zu 3.x : geändertes Startverhalten)
A.
-
Der Hinweis ist da.
Mir als User reicht das. -
@thomas-braun said in Frage zu Breaking Changes im Zigbee Adapter 2.x:
Offengesagt würde ich im ChangeLog einer zu 'stable' erklärten Version aber auch einen noch deutlicheren Hinweis auf die Breaking Changes erwarten.
Insbesondere beim Umfang selbiger im konkreten Fall.Genau das meinte ich weiter oben.
@asgothian said in Frage zu Breaking Changes im Zigbee Adapter 2.x:
Wenn man aber nach Deiner Fehlerbeschreibung, oder der Zigbee Adapter Version sucht kommt man ganz schnell auf Links zu genau diesem Thread.
Dazu kann ich nur sagen: Ich hab gesucht und nix gefunden. Wahrscheinlich war ich zu blind, deshalb bin ich ja für euren Hinweis auf den Thread dankbar.
-
@haselchen sagte in Frage zu Breaking Changes im Zigbee Adapter 2.x:
Wie deutlich noch?
Deutlicher...
Für mich geht da auch bei mehrmaligem Lesen nicht so ganz eindeutig hervor, worin denn nun die ggfls. zu umschiffenden Klippen liegen.Zumal ich auch nicht weiß, ob die 2.0.1 überhaupt im stable erschienen ist oder ob da nicht die 2.0.5 als erste Version aus dem 2er-Zweig reingelaufen ist.
Ich musste mir zuletzt auch Schelte beim ChangeLog zum diag-Skript anhören... Da hatte ich alle Interimsversionen schön mit Datum (Versionsnummer) versehen; das sollte dann aber zum finalen Release aber alles zu einem Eintrag zusammengefasst werden.
Das solche Dinge trotzdem nicht gelesen werden steht dann nochmal auf einem anderen Blatt...
-
@gaspode sagte in Frage zu Breaking Changes im Zigbee Adapter 2.x:
deshalb bin ich ja für euren Hinweis auf den Thread
Das ist das Ziel des Forums. Und des Hinweises.
Wir wollen jeden mitnehmen. Und wer fragt bekommt auch (hoffentlich hilfreiche) Antworten.
Das ganze so gut zu dokumentieren das es ohne Fragen einfach durch läuft kostet so wahnsinnig viel Zeit...
Nur nebenbei - An der Doku hab ich etwa 4 mal so lange wie an den Code-Verifikationen, Anpassungen und Tests gesessen - und das bei dem (wie du korrekt bemerkt hast) geringen Doku Umfang.
A.
-
Ja, Dokuschreiben ist auch bekanntermaßen des Developers unbeliebteste Tätigkeit. Kann ich nur zu gut nachempfinden.
-
@thomas-braun sagte in Frage zu Breaking Changes im Zigbee Adapter 2.x:
@haselchen sagte in Frage zu Breaking Changes im Zigbee Adapter 2.x:
Zumal ich auch nicht weiß, ob die 2.0.1 überhaupt im stable erschienen ist oder ob da nicht die 2.0.5 als erste Version aus dem 2er-Zweig reingelaufen ist.
Die Versionen siehst doch in der Adapterübersicht?!
Latest , Stable....
Die 2.05 scheint die erste und aktuelle Stable im 2er Bereich gewesen zu sein.
-
@asgothian said in Frage zu Breaking Changes im Zigbee Adapter 2.x:
Das ganze so gut zu dokumentieren das es ohne Fragen einfach durch läuft kostet so wahnsinnig viel Zeit...
Das ist mir klar. die vorliegende Änderung ist aber halt für den Anwender schon ein Brett, wenn er davor sitzt und vieles nicht mehr passt. Wie gesagt, von meiner Seite alles gut. Mir hat der Hinweis auf den Thread völlig gereicht (wenn ich auch auf die Spitze von @haselchen gut hätte verzichten können
)Und nur um das nochmal klar zu sagen: Die Doku des Adapters ist super. Nur aus dem Changelog und der Doku konnte ich halt überhaupt nicht raus lesen, was jetzt genau das Problem bzw. die Änderung ist. Das geht nur mit Hilfe des Tester Threads, auf den du mich ja gleich aufmerksam gemacht hast. Nochmals Danke.
-
@gaspode sagte in Frage zu Breaking Changes im Zigbee Adapter 2.x:
Das geht nur mit Hilfe des Tester Threads,
Dafür sind sie ja da, weil dort zu jeder neuen Betaversion diese Hinweise, P7tfalls und Workarounds bis hin zum bugfix besprochen werden.
Wenn du aber schreibst
@gaspode sagte in Frage zu Breaking Changes im Zigbee Adapter 2.x:
Aber Normaluser werden wohl kaum in den Testerbereich schauen
und das zutrifft, wäre es schade um die dort geleistete Arbeit.
Was könnte man den machen, damit dieser Testerbereich, der schlussendlich genau das Ziel bei neuen Versionen sein sollte, besser zu "promoten"
@MCM1957 achtet mittlerweile sehr genau darauf, dass dort entsprechende Threads angelegt werden.
-
@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 sagte in Frage zu Breaking Changes im Zigbee Adapter 2.x:
im ChangeLog ist das ja alles nur kurz angerissen
das ist ja auch ok so!
da kann nicht alles haarklein für jede Eventualität stehen@thomas-braun sagte in Frage zu Breaking Changes im Zigbee Adapter 2.x:
Zumindest würde ich den im ChangeLog verlinken.
Das wäre sicher hilfreich und ein Grund mehr immer einen solchen Thread hier zu eröffnen.
-
@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.
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. -
@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. -
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.
-
@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 offtopic -
@mcm1957 Danke.. muss ich mich erst einlesen - ich meld mich via discord. Hab kein telegram.
A.
