[Wunsch] Firmwareversion von HM-Geräten als Reading statt als Attribut

[betateilchen]

Zum einen, weil es als Attribut nicht wirklich viel Sinn macht.

Zum anderen - und das ist viel entscheidender - weil im Moment die Firmwareversion offenbar nur ein einziges Mal während des autocreate bzw. pairing angelegt und danach nie wieder angetastet, geschweige denn aktualisiert wird. Auch ein Löschen des Attributes und ein anschließendes rereadcfg oder restart bringt kein korrektes Ergebnis (das Attribut bleibt einfach gelöscht)

[martinp876]

Zum einen, weil es als Attribut nicht wirklich viel Sinn macht.

ja/nein - kompliziert - siehe unten

weil im Moment die Firmwareversion offenbar nur ein einziges Mal während des autocreate bzw. pairing angelegt

Die FW version wird IMMER upgedated, wenn sie erkennbar ist. Erkennbar ist sie IMMER in einer Anlern/config message, also immer wenn der Anlernknopf gedrückt wird.
Des weiteren gibt es bei einigen devices das Kommando getSerial - mit gleichem Erfolg.

Auch ein Löschen des Attributes und ein anschließendes rereadcfg oder restart bringt kein korrektes Ergebnis (das Attribut bleibt einfach gelöscht)

Verstehe es nicht - habe es gerade noch einmal probiert - mit einer remote. Wenn ich das Attribut ändere oder lösche wird es mit dem nächsten Anlernen wieder gelesen. Das ganze folgt dem Handling von Attributen:
- Bei der Erkennung der FW wird das Attribut gesetzt
- attribute werden im fhem.cfg gespeichert.Das passiert NICHT automatisch (einige wenige Ausnahmen). Wird kein save gemacht wird beim nächsten restart/reread,... der alte wert wieder gelesen

Das alles funktioniert m.E exakt so - soweit sind wir einig - oder passiert bei euch etwas anderes?

Nun zum Speicherort. m.E. ist die Lösung 'attribut' die 2. Beste. Ich habe s übrigens nicht erfunden, es war schon immer so.
Was ist Möglich -es gibt 4 Speicherorte
- helper: sind nicht User sichtbar =>no
- internals: sind volatil - nach einem neustart gelöscht. Damit ist die FW version quasi nie vorhanden.
- Readings: inhaltlich eine gute Wahl. Leider werden die Readings bei mir immer wieder gelöscht. Kann mit der Art des restarts zusammen hängen.. der Speicherplatz ist also nicht "sicher".
- attribut: Inhaltlich falsch. Diese Gruppe ist eigentlich zum steuern des Verhaltens in FHEM. Aber es ist die einzige Gruppe, die sauber gespeichert werden kann.

=> da die FW version - je nach device - nur selten/schwer gelesen werden kann (anlernen drücken bei remotes, SC,...) ist ein "sicherer" speicherort notwendig.

Nach aktellem Stand ist Attribut die einzige Möglichkeit, die durchgängig den Anforderungen genügt. Leider muss der User immer ein 'save' machen.

Alternativen:
Mit meinem Vorstoss vor mehr als einem Jahr, weitere Gruppen oder Typen in FHEM einzuführen bin ich bei den Entwicklern gescheitert.

Neubau - autoSaveDeviceData
Was ich bisher eingeführt habe ist ein loadConfig in HMInfo. Grund hier war für mich, dass die Register bei "config devices" nicht zu Verfügung stehen und eigentlich nicht abgefragt werden können. Wenn man das ausbaut und modifiziert könnte man eine automatisch Speicherung von Devicedaten einbauen (register, peers, FWversion,...) und diese bei neustart lesen. Man müsste automatisch schreiben und lesen....
darstellen könnte man es in Readings.

Ist so etwas gewünscht? Können wir einmal durchdiskutieren.

Gruss Martin

[betateilchen]

Ja, beim erneuten Anlernen wird die Version neu gelesen, das ist schon klar. Auch das "warum das in attr steht" ist mir schon klar. Das war übrigens auch einer der Gründe, warum ich meine Devices vor deren Firmwareupdate in fhem gelöscht und danach wieder neu angelernt hatte.

Aber es führt halt bei einigen Leuten zur Verwirrung, wie man im aktuellen "Homematic Firmware Update" Thread sehen kann.

[martinp876]

dass man es erst löschen musste verstehe ich nicht - sollte nicht sein.

Das es suboptimal ist - sind wir uns einig. Aber aktuell sehe ich keine andere Möglichkeit. Das Problem mit der Firmware sehe ich als nur eines - schlimmer ist es bei peerIDs.
Auf der anderen Seite das Problem der Registerlisten in Readings...

Alles hat ein Problem, dass der User die Daten selbständig aktuell halten muss. Ich sehe nicht, wie ich das "einfach" ändern könnte.

daher meine Anfrage, eine automatische speicherung und lesen solcher daten. Das ist keine kleinigkeit und daher ist die Frage, ob es jemanden interessiert. Ggf. könnten wir es spezifizieren....

[betateilchen]

dass man es erst löschen musste verstehe ich nicht - sollte nicht sein.

Das hast Du falsch verstanden. Das Löschen war einfach der erste Schritt, um herauszufinden, ob es irgendwie anders als durch Anlernen wieder erzeugt werden kann.

[martinp876]

ok.

Bezüglich einer "speziellen Behandlung" solcher Daten siehst du keinen Handlungsbedarf - so verstehe ich deine Antwort.

[betateilchen]

Es wäre schon schön, wenn man das in fhem automatisieren könnte. Aber ich denke, im Moment gibts wichtigere Baustellen.

[frank]

hallo allerseits!

daher meine Anfrage, eine automatische speicherung und lesen solcher daten. Das ist keine kleinigkeit und daher ist die Frage, ob es jemanden interessiert. Ggf. könnten wir es spezifizieren....

da ich diese frage nicht speziell auf das firmware-reading bezogen verstehe, melde ich mal ein leises ja an. 

mein interesse bezieht sich auf die speicherung der "wiederbelebungs"-zeitpunkte meiner hm-cc-vd.

gruss frank

[martinp876]

Hi Frank,

wie im anderen Threat angesprochen arbeite ich an einer Lösung/erweiterung wie folgt:
- fhem.cfg enthält Attribute und Defines  - sollte über save gespeichert werden. User sollten es nur in Ausnahmefällen editieren. Ist wohl auch ein Gedankengang von Rudi...
- man sollte sich ein fhemUser.cfg einrichten, das durch ein notify post-fhem.cfg ausgeführt wird. Hier kann der User aktionen durchführen, die von einem save unberührt bleiben (kommandos, skripte).

Readings:
- hier sollte man HMInfo nutzen, da es über alle entites arbeitet
- saveConfig schreibt alle Readings so, dass sie a) nach FHEM geladen werden können (loadConfig) oder b) als script in ein device geschrieben werden könnten
- loadConfig liest fehlende Readings aus dem Config-file nach FHEM zurück. Insbesondere interessant für Devices, die nur auf "config" reagieren.

=> meine aktuelle Einstellung:

Code Auswählen Erweitern

define userCfg notify global:INITIALIZED include setup/fhemUser.cfg
liest führt das user-config file aus. Ich empfehle ein separates Directory for solche Setting - hier setup

das file fhemUser.cfg enthält unter anderem:

Code Auswählen Erweitern

# load unknown register
set hm loadConfig setup/regSaveConfigs.cfg


man könnte es auch spezifischer machen mit
set hm loadConfig -f vd1 setup/regSaveConfigs.cfg
oder
set hm loadConfig -f ^vd1$ setup/regSaveConfigs.cfg
so dass nur vd1 aus dem file gelesen wird.

Neu wird ein
purgeConfig
sein, dass das wachsende File aus saveConfig einschrumpfen kann. Man kann es manuell auslösen. wenn das config file größer 1MByt ist wird automatisch gepurged.

Und dann noch 2 Attribute in HMInfo
configDir definiert die default direktory für entsprechende Files (bei mir "setup")
configFilename default filename für saveConfig/loadConfig/purgeConfig

Offen ist der automatische speicher mechanismuss - der "sparsame" trigger ist nicht ganz einfach

Version 4800 ist gerade übertragen.
Gruss Martin

[betateilchen]

(http://up.picr.de/17357583tx.png)

Gefällt mir! Danke.