Readings beim Dummy

[manne44]

Hallo, ich habe mir angewöhnt, dass ich verschiedene Werte für Übersichtlichkeit als Readings in ein Dummy packe.
So z.B.

Code Auswählen Erweitern


defmod swLichtGarage_set dummy
attr swLichtGarage_set DbLogExclude .*
attr swLichtGarage_set alias swLichtGarage_set
attr swLichtGarage_set comment 192.168.178.84
attr swLichtGarage_set readingList cfg_bg_color_act cfg_bg_color_locked cfg_bg_color_std cfg_label_name cfg_locked cfg_menu_select mode mode_x presence sec_on sec_on_time time_off time_on
attr swLichtGarage_set room SW-SET

mit den Readings

Code Auswählen Erweitern


Text einschalten
cfg_bg_color_act 1
cfg_bg_color_locked 2
cfg_bg_color_std 1
cfg_label_name LichtGarage
cfg_locked off
cfg_menu_select simple
connected NONE
mode NONE
mode_x NONE
presence NONE
sec_on 300
sec_on_time 00:05:00
state autodef
time_off 22:00:00
time_on 08:00:00


Gibt es einen Absturz oder andere Unregelmäßigkeiten, die zwar sehr selten vorkommen, dann sind die Readings verschwunden, lediglich die Defines sind weiterhin vorhanden. Was kann ich da machen, dass die Readings vollständig erhalten bleiben? Muß ich mir eigene Typen bauen?
Ich finde meine Vorgehensweise eigentlich gut, aber offenbar nicht FHEM-regelgemäß, denn die Readings sind weg, enthalten aber eine Vielzahl von Informationen ohne die nichts mehr richtig funktioniert. Und das nach einer Unregelmäßigkeit wieder so hinzubiegen, das ist sehr, sehr zeitaufwendig.
Was muss ich ändern, damit die Werte erhalten bleiben?
Vielen Dank.

[betateilchen]

Gibt es einen Absturz oder andere Unregelmäßigkeiten, die zwar sehr selten vorkommen, dann sind die Readings verschwunden, lediglich die Defines sind weiterhin vorhanden.

Vorausgesetzt, Du hast nach dem Beschreiben der readings ein "save config" gemacht, sollten die readings auch nach einem FHEM Neustart wieder vorhanden sein.

[manne44]

Das stimmt normalerweise, aber heute habe ich Quatsch gemacht, FHEM war mit dem Browser nicht mehr zu erreichen, ich habe mir die LOG-Datei angesehen und bemerkt, dass immer wieder nach Fehlern die Fhem.cfg geladen wurde ohne klare Begründung für mich. Habe dann den RPI4 resettet, FHEM kam nicht wieder, dann schrittweise in Betrieb genommen und suksessive immer weiter bis alles lief. Da waren aber die Readings weg.

[manne44]

Ich habe mal ganz frech FHEM gestoppt

Code Auswählen Erweitern


systemctl stop fhem

und dann aus einem heutigen Backup die fhem.save nach /opt/fhem/log kopiert und die fehlerhafte Datei damit überschrieben. Und nach dem Start von FHEM ist nun alles wieder so wie es sein soll.
Aber so richtig gefällt mir das nicht. Am Liebsten würde ich mit eigene Typen bzw. eigene Dummy-Geräte programmieren, die diese Readings von Hause aus enthalten, aber mangels Perl-Kenntnissen kann ich das leider nicht.

[Damian]

Am Liebsten würde ich mit eigene Typen bzw. eigene Dummy-Geräte programmieren, die diese Readings von Hause aus enthalten, aber mangels Perl-Kenntnissen kann ich das leider nicht.

Nützt dir nur nichts, wenn die Inhalte verloren gehen, da sie auch in diesem Fall im save-File gespeichert werden.

[betateilchen]

Oder anders ausgedrückt: das Speichern von readings erfolgt nicht type-abhängig unterschiedlich

[manne44]

Das stimmt schon, aber in meinem Fall mit den Dummy-Readings sind dann die Variablen und die Werte weg, nur die nackten Defines sind noch da. Mit Perlfunktionen erzeuge ich dann diese Readings mit Standardwerten und kann dann die Struktur wieder herstellen, die Werte sind zwar weg, aber die Form stimmt wieder, so dass bei Bedarf darauf zugegriffen werden kann.
Zum Beispiel:

Code Auswählen Erweitern


sub
init_new_switch_set($$) {
my ($dev,$name) = @_;
fhem('setreading '.$dev.'_set Text einschalten');
fhem('setreading '.$dev.'_set cfg_bg_color_act 1');
fhem('setreading '.$dev.'_set cfg_bg_color_locked 2');
fhem('setreading '.$dev.'_set cfg_bg_color_std 1');
fhem('setreading '.$dev.'_set cfg_label_name '.$name);
fhem('setreading '.$dev.'_set cfg_locked off');
fhem('setreading '.$dev.'_set cfg_menu_select simple');
fhem('setreading '.$dev.'_set connected NONE');
fhem('setreading '.$dev.'_set mode NONE');
fhem('setreading '.$dev.'_set mode_x NONE');
fhem('setreading '.$dev.'_set presence NONE');
fhem('setreading '.$dev.'_set sec_on 300');
fhem('setreading '.$dev.'_set sec_on_time 00:05:00');
fhem('setreading '.$dev.'_set state autodef');
fhem('setreading '.$dev.'_set time_off 22:00:00');
fhem('setreading '.$dev.'_set time_on 08:00:00');
}

sub
setSETlists() {
my $i = 0;
foreach my $entry(@setDeviceList) {
init_new_switch_set($entry,$setNameList[$i]);
$i++;
}
}

Und das für 25 Devices und andere gibt es auch. Somit muss ich dann für alle diese Dummy-Readings schon bei der Definition solche Notfall-Funktionen anlegen.
Das ist bei Standard-Geräten nicht der Fall, denn dort sind zwar die Werte futsch, aber die Struktur stimmt noch, was bei meiner Vorgehensweise nicht so ist.

[betateilchen]

dass immer wieder nach Fehlern die Fhem.cfg geladen wurde ohne klare Begründung für mich.

Du solltest Deine Energie besser darauf verwenden, herauszufinden, warum die readings überhaupt "verschwinden".
FHEM selbst löscht die jedenfalls nicht aus dem statefile, wenn sie da mal drinstehen.

[manne44]

Das wäre sicher am besten, aber es fällt mir schwer, solche schwerwiegenden Abstürze zu reproduzieren. Kommt er mal alle zwei, drei Jahre, dann sind Untersuchungen schwierig.