Home Connect Forum

[Adimarantis]

Hallo,

Ich habe die letzten Monate die Home Connect Integration überarbeitet und inzwischen auch das Wiki aktualisiert und auf meine Version angepasst. Dazu habe ich mich auch bereits mit Stefan (swhome) abgestimmt.
Nachdem beide Moderatoren des Home Connect Forums anscheinend nicht mehr aktiv sind, würde es da nicht Sinn machen mich hinzuzufügen?
Ich hatte auch schon überlegt das Modul von GitHub ins SVN zu nehmen, aber dann dürften zu viele Leute beim Update ungewollt die neue Version bekommen, und die ist nicht 100% rückwärtskompatibel.

Jörg

[rudolfkoenig]

Ich habe Dich als Moderator des Home Connect Bereichs hinzugefuegt.

[Beta-User]

hatte auch schon überlegt das Modul von GitHub ins SVN zu nehmen, aber dann dürften zu viele Leute beim Update ungewollt die neue Version bekommen, und die ist nicht 100% rückwärtskompatibel.

Meine 2 (unbeteiligten) ct:

Wir sollten ein Nebeneinanderher zwischen der "eigentlich zu verwendenden Version" (deine) und "historischen" Versionen (die unbedarfte Einsteiger dann aber verwenden!) möglichst vermeiden.
Sowas hatten wir zuhauf (aus dem Kopf mindestens) mit EIB/KNX und MQTT_BRIDGE/MQTT_GENERIC_BRIDGE.

Es ist klar, dass solche Übergänge nicht "schmerzfrei" vonstatten gehen, ich selbst hatte "Spaß" mit Heating_Control/WeekdayTimer - und überhaupt dem Ausbau der öfters "ausgeborgten Funktionen" aus Twilight...

Mein Vorschlag wäre:
- entweder Übernahme asap ins svn unter dem alten Namen, deutlicher Hinweis nach "CHANGED" (und, falls es bis zu einer Revisionsänderung warten soll auch nach "UPDATE"), ggf. ein angepinnter Post hier im passenden Forenbereich (und im Wiki), ggf. Kopie der letzten Version nach contrib.
- oder Änderung der alten Version mit dem deutlichen Hinweis im log, in der Detailansicht, whereever: Bitte umsteigen, das Modul ist deprecated und Einchecken einer Parallelversion (z.B. HomeConnect2).

Letzteres liest aber erfahrungsgemäß aber sowieso niemand rechtzeitig, von daher kann man sich den Aufwand auch sparen und Verwirrung bei Einsteigern vermeiden...

[betateilchen]

Man könnte ja die "breaking changes" jetzt ankündigen und dann mit dem nächsten FHEM Release 6.4 aktiv setzen.

Das letzte release war im Januar 2024, ich denke, allzu lange wird es bis 6.4 nicht mehr dauern.

[tobi01001]

Mal aus (meiner) Anwendersicht:
Ich habe die Entwicklung des "neuen" Ansatzes etwas verfolgt, bin aber nicht darauf ein- bzw umgestiegen, da meine zwei Geräte mit dem "alten" so funktionieren wie ich mir das wünsche und ich keinen Bedarf sehe, alles auf das Neue zu adaptieren.

Ich sehe allerdings auch, dass Ändeurngen, Modernisierungen etc nicht schmezfrei und nicht immer rückwirkungsfrei funktionieren.
Für neue Nutzer und neue Hardware hat man dann doch lieber ein aktuell gepfegtes Modul.

Ich kann es ja den "Umstieg" mit "excludefromUpdate" hinauszögern.
Dazu hätte ich folgende Wünsche:

• Vor dem Release "deutlich" im alten Modul darauf hinweisen (vll auch über ein Internal / Reading? - falls das eine Möglichkeit wäre?), dass bald (mit 6.4?) ein Release mit breaking changes kommt.
• Sofern möglich: Ein Auflistung jener "breaking changes" für Benutzer des alten Moduls.

Parallel zwei Module zu haben - eines halbwegs verwaist und eines aktuell, finde ich auch nicht zielführend.

LG

[rudolfkoenig]

Vor dem Release "deutlich" im alten Modul darauf hinweisen (vll auch über ein Internal / Reading? - falls das eine Möglichkeit wäre?), dass bald (mit 6.4?) ein Release mit breaking changes kommt.

Wenn man in der Initialize Funktion des Moduls an $defs{global}{init_errors} was anhaengt(!), dann wird das an prominenter Stelle in FHEMWEB angezeigt.

[Beta-User]

Ich kann es ja den "Umstieg" mit "excludefromUpdate" hinauszögern.

Dann mach das. Jetzt...

Dasselbe gilt für jeden Mitleser, der Sorge hat, dass ihm künftig ein update was zerschießt . Es "entgeht" euch nichts - das alte Modul wird ja so oder so keine "echten" updates erhalten, oder.....?


Zu - noch so prominenten - Hinweisen hatte ich ja schon was geschrieben. Das macht nur für eine relativ kurze Übergangsphase Sinn, denn Probleme machen v.a. die User, die irgendwann - aus welchem Grund auch immer - gezwungen sind, FHEM neu zu installieren und dann versuchen, ihre alte cfg auf ein neues FHEM loszulassen. Regelmäßige updater werden (hoffentlich) "CHANGED" zur Kenntnis nehmen und entsprechend handeln. Bloße "Gelegenheits-updater" gibt es auch, und nur die "erwischt" man mit dem Ankündigungsverfahren.

Ob sich bei der (relativ geringen) Zahl der (per Statistik) "gemeldeten" Installationen lohnt, den Aufwand zu treiben, sei mal dahingestellt -  die "Reparatur" ist ja ggf. relativ einfach. Falls überhaupt ein Problem besteht...

Sofern möglich: Ein Auflistung jener "breaking changes" für Benutzer des alten Moduls.

Falls (!) es sowas schon gibt, macht es ggf. Sinn, das zu verlinken oä., aber das scheint sehr individuell zu sein, von daher soll das notfalls halt ausprobieren, wer will und ggf. seine Erfahrungen mit dem Umstieg schildern.
Dazu kann man ja einen neuen (gepinnten) Thread aufmachen (in dem die alte Version auch angehängt werden kann).

[tobi01001]

Probleme machen v.a. die User

Ja, das update Leben wäre ohne user deutlich einfacher.

Am Ende ist es aber wie du schriebst. Entweder man achtet auf CHANGED und aktualisiert in einer gewissen Regelmäßigkeit oder eben nicht.
Wenn allerdings ständig nicht rückwirkungsfreie Aktualisierungen stattfänden, wäre das der Updatefreundlichkeit und Nutzerfreundlichkeit nicht zuträglich.

Glücklicherweise ist das extrem selten der Fall.

Und zur Änderungsübersicht:
Breaking changes meine ich Erklärungen für dinge die nicht abwärtskompatibel sind. Eine Änderung im Readingnamen oder der Einheit z.b. Wh nach kWh ist je nach Anwendung bereits ein breaking change - aber nomral relativ schnell und selbsterklärend gefixt. Was ich meine ist z.B.:

• Änderungen in der Anmeldemethode
• Zwingend erforderliche / nicht mehr erforderliche Attribute
• gar nicht mehr vorhandene Readings
• ...

Dazu kann man ja einen neuen (gepinnten) Thread aufmachen (in dem die alte Version auch angehängt werden kann).

Es gibt den zugehörigen "Entwicklungsthread". Aber dazu müsste man im Zweifel von vorne bis hinten lesen um die Evolution zu überblicken. Das wäre in einer Zusammenfassung einfacher. Anderseits bin ich mir relativ sicher, dass das hier ein eher theoretisches Konstrukt ist und die Auswirkungen überschaubar sind (und letztendlich die Vorteile überwiegen).

[Beta-User]

Ja, das update Leben wäre ohne user deutlich einfacher.

Danke für das Highlighten!

Gemeint war eigentlich, dass v.a. diese User-Gruppe (jedenfalls nach meinen eher begrenzten Erfahrungen hier im Forum) Probleme mit breaking changes hat, weil das dann (in der skizzierten Situation) "zusätzlich zu allem anderen auch noch kommt", (und dann entsprechend wenig verständnisvoll reagiert).

Das wäre in einer Zusammenfassung einfacher.

Völlig klar. Whodunnit?

Vielleicht magst du ja anfangen, das (grob!) zusammenzufassen, was bisher im Thread stand (falls es nicht schon eine Zusammenfassung gibt), und ggf. dann direkt den betreffenden Thread mit deinen eigenen Erfahrungen starten .

[tobi01001]

Danke für das Highlighten!

Gerne, mir war schon klar wie du das gemeint hast. Aber das las sich so, dass ich den nicht liegen lassen konnte.

Vielleicht magst du ja anfangen, das (grob!) zusammenzufassen, was bisher im Thread stand (falls es nicht schon eine Zusammenfassung gibt), und ggf. dann direkt den betreffenden Thread mit deinen eigenen Erfahrungen starten .

Wenn ich das bereits wüsste, bräuchte ich nicht fragen.
Aber wer lesen kann und das auch tut...

auch das Wiki aktualisiert und auf meine Version angepasst.

https://wiki.fhem.de/wiki/HomeConnect#Unterschiede_zur_Urversion
kann diese Diskussion auch mit Verweis auf die bereits erfolgte Arbeit von Adimarantis beenden.

Das hätte ich mal gleich mit lesen sollen - zumal es sogar die "alten" Readingnamen ermöglicht.

[Beta-User]

Das hätte ich mal gleich mit lesen sollen - zumal es sogar die "alten" Readingnamen ermöglicht.

Vielleicht könnte man in dem Zug auch gleich alte Zöpfe abschneiden....?

[Adimarantis]

Zurück vom Skiurlaub    - Wow einiges an Diskussion.

Eine Sache die ich dazu bemerken möchte:
HomeConnect war noch nie im SVN, sondern alle Anwender mussten ja entsprechend die zusätzliche Update Quelle aus Github eintragen.
Was mir jetzt z.B. nicht klar ist: Was passiert wenn ein gleichnamiges Modul sowohl im FHEM SVN als auch in einer zusätzlichen Quelle vorkommt? Ist das Verhalten deterministisch? Üblicherweise dürfte ja das FHEM SVN an erster Stelle im controls.txt stehen.

Ich hatte swhome übrigens schon vorgeschlagen in sein Modul eine FW_detailFN einzubauen und einfach oben im Device einen deprecation Hinweis zu geben. Leider liest er wohl auch PMs nur sporadisch. Muss ich vielleicht einfach mal einen PR auf Github machen.