[ASC] wie mache ich ein exklusives update für asc?

[frank]

moin,

wie mache ich eigentlich ein exklusives update von asc inklusive aller abhängigkeiten oder ein entsprechenden update check?
wie bekomme ich alle abhängigkeiten angezeigt?

entsprechend kommt die frage: wie verhält es sich eigentlich mit "exclude from update"?

[Beta-User]

Falls es keine Fangfrage speziell an CoolTux ist:

Die pm in ./FHEM ist ein Wrapper für ./lib/FHEM/Automation/ShuttersControl.pm, und im Verzeichnis ./lib/FHEM/Automation/ShuttersControl liegen dann die originär für das Modul benötigten weiteren Dateien. Ergo muss das alles "einigermaßen" zusammenpassen (der Wrapper enthält eigentlich nur einen Verweis und die commandref und kann daher viel älter oder neuer sein...).
Um ein Komplettupdate zu machen, muss man also diese Dateien alle "mitnehmen", wobei fhem.pl (und GP_Utils.pm) auch eine gewisse Aktualität haben muss (würde schätzen, dass <18 Monate unproblematisch ist) und uU. auch noch weitere Dateien aus dem "./lib-Fundus" benötigt werden.

"exclude" wäre dementsprechend die "Umgekehrung"

[frank]

Ergo muss das alles "einigermaßen" zusammenpassen

   

auf den punkt gebracht: es gibt also in fhem keinen komfortablen update-mechanismus für package-module.
schade eigentlich.

Code Auswählen Erweitern

update check AutoShuttersControl
das checked dann auch nur den wrapper, oder?

"exclude from update" ist doch dann eigentlich unmöglich für package-module, da unter umständen weitere module von bestimmten dateien abhängig sind.

[Beta-User]

auf den punkt gebracht: es gibt also in fhem keinen komfortablen update-mechanismus für package-module.
schade eigentlich.

Jein. So oder so stellt sich die Frage, welchen Sinn Teil-updates haben. Komfortabel ist und bleibt es so oder so nur dann, wenn alles auf einem einheitlichen Stand ist. Auch meine "gepackagten" Module, die keine Dateien aus "./lib" verwenden, sind teils darauf angewiesen, dass fhem.pl einigermaßen aktuell ist... (und das wären sie auch, wenn sie nicht gepackaged wären!)

Code Auswählen Erweitern

update check AutoShuttersControl
das checked dann auch nur den wrapper, oder?

Nein:

No source file named controls_AutoShuttersControl found

(Es kann aber sein, dass du eine eingebunden hast, weil teilweise Testversionen per separater control-file bereitgestellt worden sind. Dann klappt das auch (eingeschränkt!) mit dem "Teilupdate").

"exclude from update" ist doch dann eigentlich unmöglich für package-module, da unter umständen weitere module von bestimmten dateien abhängig sind.

Das kann man so nicht sagen, aber klar, es ist schwerer zu durchschauen, was wirklich benötigt wird. Im Zweifel kommt halt eine Fehlermeldung und das Modul kann nicht geladen werden, wenn ein vorausgesetzter Teil fehlt.

Das hatte ich ein paar Mal mit WeekdayTimer und RHASSPY, weil die die Timer-Register benutzen, und teils diese Datei nicht mit upgedated worden war (weil der User entweder nur die aktualisierte Datei manuell reinkopiert und verwendet hat oder das Gesamtupdate nicht sauber durchgelaufen war).

exclude ist jedenfalls regex, von daher sollte es in dem konkreten Fall nicht sooooo schwer sein.

Prinzipiell teile ich aber deine Skepsis, speziell was das Aufteilen in viele Teile angeht. (und in dem wrapper+eine Hauptdatei unter ./lib sehe ich auch keinen signifikanten Vorteil).
Was gemeinsam genutzte Code-Teile angeht, ist das was anderes. Da finde ich es sehr gut, dass z.B. grade die Timer-Register-Sache zentral abgelegt ist, das ist sehr viel transparenter wie die "alte" Technik, irgendein anderes Modul (Twilight) vorauszusetzen und dann komplett abzuschmieren, wenn da jemand was umbenennt...

[frank]

So oder so stellt sich die Frage, welchen Sinn Teil-updates haben.

ganz einfach: mit limitiertem internetzugang über handy muss man traffic sparen.

mit meiner fhem version (vielleicht 2-3 monate alt) gab es probleme mit einem neu erstellten asc device.
es stellte sich dann die frage, ob ein anfänger-konfigurations-problem vorlag oder ein update das problem lösen könnte.
also hätte ich gerne gecheckt für welche asc files ein update existiert, um diese ggf zu aktualisieren.

nach einem kompletten fhem update läuft es nun erst einmal problemlos.


seltsam ist allerdings noch das reading rolloDevice_lastPosValue.
entweder ist der name und die beschreibung in der commandref "schlecht/falsch", oder es gibt ein problem:
mein reading enthält nicht grundsätzlich den letzten wert, denn bei manuellen fahrten wird es nicht aktualisiert.
ein "besserer" name wäre demnach zb: rolloDevice_PosValueBeforeLastAscDrive

[Beta-User]

ganz einfach: mit limitiertem internetzugang über handy muss man traffic sparen.

a) Mit einem USB-Stick sollten sich viele Daten per Turnschuh-Netzwerk aktualisieren lassen, wenn nötig...
b) In der Konstellation ist der gesplittete Code sogar von Vorteil: Es wird immer nur die (Teil-) Datei angefaßt, die auch geändert ist, nicht "immer alles". (dafür kann man andererseits uU. nicht erkennen, ob die Versionen wirklich zusammenpassen, siehe z.B. die svn-Revisionen aktuell in https://svn.fhem.de/trac/browser/trunk/fhem/lib/FHEM/Automation/ShuttersControl...)

Was die Doku angeht, freut sich CoolTux bestimmt über konstruktive Zuarbeit (an eine Änderung der Namen glaube ich aber nicht). Nach meinem Verständnis geht es da immer um die "Soll"-Zustände, wie sie sich aus ASC ergeben haben bzw. hätten. Alles, was (ggf. auch nur scheinbar - fehlende "event-on-.*"-Attribute sind eine der Hauptursachen für User-Fragen) manuell passiert, interessiert ASC nur dahingehend, dass ggf. eben (eine Zeitlang) nicht mehr automatisch gefahren wird.