frage zum update von fhem

Begonnen von the ratman, 04 Juni 2019, 09:38:27

Vorheriges Thema - Nächstes Thema

Loredo

Ich gebe zu bedenken, dass der FHEM Installer auf der Agenda stehen hat, eine Alternative zum Update Befehl zu werden. Unter anderem ist dabei vorgesehen, dass es eine flexiblere/einfachere Handhabung von lokalen Änderungen und der Einbeziehung von Entwicklerversionen aus einem anderen Unterverzeichnis oder Repository gibt.


Und ja, ist und soll Version ist auch vorgesehen anzuzeigen. Die Ist Version kann man ja jetzt schon sehen (und zwar sowohl Revision als auch die Modulversion, die ein Autor möglicherweise zur besseren Kennzeichnung vergeben hat).
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

the ratman

ZitatDu willst schließlich was haben, was andere nicht unbedingt für notwendig halten...
falsch! ich hab mir nur gedacht, dass es hilfreich sein könnte. wirklich eigenes erbitte ich eher selten und akzeptiere dann auch jegliches "nein". dieser wunsch fallt aber unter die rubrik "win-win" für user und programmierer, drum war ich so frech. aber wenn ich jetzt loredos beitrag les, war ich eh nur zu flott.

Zitatmanchmal friert die Hölle zu, ich habe schon Sachen erlebt...
ich auch ... und von der hölle wissen zumindest die 2 armen programmierer, dies mir beibringen wollten als ich selber noch glaubt hab, es lernen zu können und dafür auch zeit gehabt hätte ... glaub mir, funzt bei mir nicht. ich denk fürs programmieren "verkehrt".
→do↑p!dnʇs↓shit←

Beta-User

Zitat von: Beta-User am 04 Juni 2019, 12:44:32
Und bgzl. der Idee, die revision in list mit aufzunehmen: Es gibt irgendwo eine Wunschliste, du bist doch sonst nicht so erschrocken ;) .
Kurze Rückmeldung dazu, nachdem ich mir den code dazu mal angesehen habe:
Die Version-Abfrage erfolgt nicht innerhalb von fhem.pl, sondern via 98_version.pm. Ergo würde sowas Abhängigkeiten schaffen, von denen ich annehme, dass diese nicht gewünscht sind.
Um dieses Problem wiederum zu umgehen, wären weitere Eingriffe/Codeerweiterungen erforderlich (z.B. in der Ladefunktion für Module und in commandDefine). Ist zwar auch kein Hexenwerk, aber Aufwand, glaube daher nicht, dass das so wichtig ist, dass jemand das in Angriff nehmen würde.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Loredo

#18
Zitat von: Beta-User am 04 Juni 2019, 11:19:45
(Aber generell: Evtl. wäre es sinnvoll, die Modulversion zukünftig grundsätzlich in list aufzuführen? Erspart ggf. blöde Rückfragen und noch blödere Reaktionen auf die Rückfrage...)


Bei Benutzern, die ein FHEM Installer Device definiert haben, gibt es in jedem Device das Internal FVERSION, welches mit der aktuellen Revision- und Versionsinfo des entsprechenden Moduls gefüllt ist - auch unabhängig davon, ob der Modulautor eine direkte Unterstützung für die Metadaten eingebaut hat.


FVERSION ist somit Teil von jedem "list <DEVICE>" und somit auch die essentiellen Metainformationen.
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER