UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[Thomas Braun]

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.

[Asgothian]

@gaspode sagte in Frage zu Breaking Changes im Zigbee Adapter 2.x:

@haselchen said in Frage zu Breaking Changes im Zigbee Adapter 2.x:

@gaspode

Der Thread hat glaube ich 25 Seiten....ich tippe tatsächlich auf die Tomaten ;)

Ja, schon. Dennoch halte ich es nicht für optimal, wenn erwartet wird, dass die Anwender nach diesem Test Thread suchen. Ich selbst hab da jetzt kein Problem damit, aber es wird bestimmt den ein oder anderen Anwender abschrecken, im schlimmsten Fall wirft er die Flinte ins Korn und geht woanders hin.

• Das es Breaking changes zum 2.0 gibt ist im Readme hinterlegt (zum 2.0.0 - da ist der breaking change eingetreten). Dafür diese durch die Versionen weiter zu schleppen gibt es (leider) keinen sauberen Weg. Und einfach bei jeder Version >2.0 immer wieder darauf hinweisen verwirrt die Leute noch mehr.
• Das bei vielen Geräten die 'Exposes' geändert wurden steht auch drin - auch der Hinweis auf Fernbedienungen
• das Exposes ab 2.0 als Standard für die Generierung der Datenpunkte genommen werden steht auch drin.
• Einen Wiki-Artikel zu den Hintergründen gibt es auch. Da steht auch drin wie man versuchen kann die alten Datenpunkte zurück zu kriegen. Hat auch keiner gelesen.

Das in den Readme keine Romane geschrieben werden sind die Nutzer selber schuld - ich habe Anfangs zu fast allem neuen entsprechende Doku und wiki Artikel geschrieben die keiner gelesen hat. Statt dessen wurde einfach blind ein Issue aufgemacht (auch ohne die bestehenden Issues zu lesen).

Es gibt auch zu dem Thema 'nicht mehr funktionierende Geräte' und 'geänderte' oder 'verschwundene' Datenpunkte mehrere Issues. Auch die liest keiner. Ich denke sobald die geschlossen sind interessiert das niemanden. Aber offen lassen macht auch keinen Sinn - sie sind ja soweit möglich 'gelöst'.

Du bist gerne eingeladen einen entsprechenden Artikel / Hinweis auf Github hinzu zu fügen. Mir fehlt dafür inzwischen die Geduld.

Die meisten haben im übrigen durchaus den Thread zum Testen gefunden - alleine das sie den Anfang des Threads lesen scheint dann doch zuviel verlangt.

A.

p.s. Damit soll Deine Aussage nicht als falsch dargestellt werden - Aber etwas mehr 'Mitarbeit' erwarte ich dann doch.

Nachtrag: @gaspode: Du hast vollkommen recht - niemand soll in das 'Tester' Subforum gehen und da von Hand nach dem Thread suchen, Wenn man aber nach Deiner Fehlerbeschreibung, oder der Zigbee Adapter Version sucht kommt man ganz schnell auf Links zu genau diesem Thread.

[haselchen]

@thomas-braun

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.

[Asgothian]

@haselchen sagte in Frage zu Breaking Changes im Zigbee Adapter 2.x:

@thomas-braun

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.

[haselchen]

@asgothian

Der Hinweis ist da.
Mir als User reicht das.

[Gaspode]

@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.

[Thomas Braun]

@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... ;-)

[Asgothian]

@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.

[Thomas Braun]

@asgothian

Ja, Dokuschreiben ist auch bekanntermaßen des Developers unbeliebteste Tätigkeit. Kann ich nur zu gut nachempfinden.

[haselchen]

@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.

[Gaspode]

@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.

[Homoran]

@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.

[Thomas Braun]

@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.

[Homoran]

@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.

[Gaspode]

@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.

[Homoran]

@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.

[Gaspode]

@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.

[Asgothian]

@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.

[mcm1957]

@asgothian

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#L171

Und 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.

[Gaspode]

@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.