[gelöst] AT Device STATE falsch

Begonnen von sven.scherf, 14 Dezember 2023, 13:43:48

Vorheriges Thema - Nächstes Thema

sven.scherf

Hallo zusammen,

ich habe ein Problem mit dem Status setzen von einem AT Device nach dem reboot.

Nachts um 00:05 läuft bei mir der AT Rollladen_alle_Zufall_oben welcher mir die Uhrzeit zum öffnen der Rollläden in den AT Rollladen_alle_oben setzt.
Rollladen_alle_Zufall_oben
Internals:
   CFGFN      ./rollladen.cfg
   COMMAND    {
if (!$we) {
        my $Zufallszahl = int(rand(15) +1);
        my $Uhr = "08:".sprintf("%2.2d",$Zufallszahl).":00";
        fhem("modify Rollladen_alle_oben *".$Uhr);
                { Log 1, "Kein Wochenende $Uhr" };
    }else{
        my $Zufallszahl = int(rand(15) +1 );
        my $Uhr = "08:".(44 + $Zufallszahl).":00";
        fhem("modify Rollladen_alle_oben *".$Uhr);
               { Log 1, "Wochenende $Uhr" };
    }
        WriteStatefile();
        fhem("save");
}
   DEF        *00:05:00 {
if (!$we) {
        my $Zufallszahl = int(rand(15) +1);
        my $Uhr = "08:".sprintf("%2.2d",$Zufallszahl).":00";
        fhem("modify Rollladen_alle_oben *".$Uhr);
                { Log 1, "Kein Wochenende $Uhr" };
    }else{
        my $Zufallszahl = int(rand(15) +1 );
        my $Uhr = "08:".(44 + $Zufallszahl).":00";
        fhem("modify Rollladen_alle_oben *".$Uhr);
               { Log 1, "Wochenende $Uhr" };
    }
        WriteStatefile();
        fhem("save");
}
   FUUID      5cbaebfb-f33f-3d5f-e8e7-5d2713693ac1d496
   NAME       Rollladen_alle_Zufall_oben
   NR         314
   PERIODIC   yes
   RELATIVE   no
   REP        -1
   STATE      Next: 00:05:00
   TIMESPEC   00:05:00
   TRIGGERTIME 1702595100
   TRIGGERTIME_FMT 2023-12-15 00:05:00
   TYPE       at
   READINGS:
     2023-12-14 03:00:33   state           Next: 00:05:00
Attributes:
   room       Rollladen

Rollladen_alle_oben
Internals:
   CFGFN      ./rollladen.cfg
   COMMAND    {
    if (Value("Rollladen_Automatic") eq "on") {
        if (Value("Rollladen_next_Automatic") eq "off") {
            fhem("set Rollladen_next_Automatic on")
        } else {
            fhem("set Rollladen_alle oben")
        }
    }
}
   DEF        *08:20:00 {
    if (Value("Rollladen_Automatic") eq "on") {
        if (Value("Rollladen_next_Automatic") eq "off") {
            fhem("set Rollladen_next_Automatic on")
        } else {
            fhem("set Rollladen_alle oben")
        }
    }
}
   FUUID      5cbaebfb-f33f-3d5f-42c8-c4624fcc3b945a0e
   NAME       Rollladen_alle_oben
   NR         327
   PERIODIC   yes
   RELATIVE   no
   REP        -1
   STATE      Next: 08:20:00
   TIMESPEC   08:20:00
   TRIGGERTIME 1702624080
   TRIGGERTIME_FMT 2023-12-15 08:20:00
   TYPE       at
   READINGS:
     2023-12-14 08:20:00   state           Next: 08:20:00
Attributes:
   room       Rollladen
In dem AT Rollladen_alle_Zufall_oben wird zum Schluss der Befehl fhem("save") und seit dem Auftreten des Fehlers, dass es nicht mehr funktioniert zusätzlich noch der Befehl WriteStateFile() abgesetzt.

Nachts um 03:00 wird bei mir der Raspi mit dem fhem System neu gestartet. Dies hatte ich mal eingebaut wie es mal Probleme mit dem Raspi gab.

Meine Erwartung ist nun, dass die Nachts um 00:05 ermittelte und in den AT Rollladen_alle_oben geschriebene Zeit morgens zu dieser Zeit die Rollläden öffnet.

Dem ist aber nicht mehr so.

Den AT Rollladen_alle_oben habe ich zur Kontrolle mal auf 08:20 eingestellt und dieser wird jede Nacht durch den AT Rollladen_alle_Zufall_oben auf eine andere Zeit zwischen 08:00 und 08:15 eingestellt.
Dies lasse ich mir in dem Logfile eintragen.
Zusätzlich habe ich mir die Datei fhem.save angeschaut und nach dem AT Rollladen_alle_oben gesucht. Hier steht auch die Zeit die Nachts ermittelt wird drin.
Der Zeitstempel der Datei ist nachts 03:00 (reboot time)
Dies bedeuetet ja, dass die Änderungen gespeichert werden, aber nach dem reboot vom Raspi nicht gelesen und gesetzt werden.
Da im AT Rollladen_alle_oben bleibt meine eingestellte 08:20 drin ist.

Die ganze Sache über sehr lange Zeit ohne Probleme funktioniert aber auf einmal will es nicht mehr.

Verstehe ich hier was falsch bzw. wo kann ich hier noch ansetzen ?



Viele Grüße

Sven
Raspi 3 mit CUL Stick 433/868MHZ, Homematic

Beta-User

Guckst du in die Hilfe (commandref) zu den Attributen von "at" (die ist ziemlich überschaubar!), dann wirst du vermutlich erkennen, dass das Setzen des passenden Attributs das bewirkt, was das völlig unnötige doppelte save-Kommando deiner Meinung nach hätte erreichen sollen...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

sven.scherf

Hi,

ich denke Du meinst das Attribut computeAfterInit .

Dies gibt es ja schon seit 2016.
Mein Problem gibt es aber erst ca. 1 Monat oder so.
Deshalb kann ich es nicht so ganz verstehen warum sich das Verhalten geändert hat.

Ich habe das Attribut mal gesetzt.

Ist es egal mit welchem Wert ?
Hierzu ist nichts dokumentiert, ich habe es mal auf enabled gesetzt und bin auf morgen früh gespannt :)

Viele Grüße

Sven
Raspi 3 mit CUL Stick 433/868MHZ, Homematic

rudolfkoenig

#3
Stehen im FHEM-Log um 00:05 relevante Meldungen?
Was steht in fhem.cfg bzw. log/fhem.save nach save drin fuer Rollladen_alle_oben?

Ein WriteStateFile() vor oder nach save ist ueberfluessig: das macht save schon selbst.

computeAfterInit ist relevant, wenn die Uhrzeit in der at Definition selbst per Perl-Expression berechnet wird, in etwa so:
define myAt at {Zeitberechnung} BefehleWenn Zeitberechnung Daten von anderen Definitionen benoetigt, die nach der myAt Definition angelegt werden, dann geht beim Start die Zeitberechnung schief. Mit computeAfterInit wird nach dem Start die Zeit nochmal berechnet.

Nachtrag: ein vom Programm ausgeloestes save verweigert den Dienst, falls autosave nicht gesetzt ist. Das ist der Fall, falls beim Start Fehler gemeldet wurden.
Die Meldung "Skipping save, as autosave is disabled" erfolgt auf verbose 4, da etliche Module save aufrufen, und es Benutzer gestoert hat.[/code]

sven.scherf

Hallo,

dann ist ja das Attribut computeAfterInit nicht relevant.
Da die Startzeit vom AT Rollladen_alle_oben in der Nacht um 00:05 gesetzt wird.

Hier das Log von fhem
256788 2023.12.14 00:04:59.998 5: out@192.168.10.92:61172 PINGRESP: (208)(0)
256789 2023.12.14 00:05:00.059 1: Kein Wochenende 08:13:00
256790 2023.12.14 00:05:15.003 5: in@192.168.10.92:61172 PINGREQ: (192)(0)
256791 2023.12.14 00:05:15.003 4:   MQTT2_FHEM_Server_192.168.10.92_61172 Briefkasten PINGREQ
256792 2023.12.14 00:05:15.004 5: out@192.168.10.92:61172 PINGRESP: (208)(0)

autosave ist in der fhem.cfg auf 0 gesetzt.
Dies habe ich nun auf 1 gesetzt.

fhem.cfg
define Rollladen_alle_oben at *08:20:00 {\
        if (Value("Rollladen_Automatic") eq "on") {\
                if (Value("Rollladen_next_Automatic") eq "off") {\
                        fhem("set Rollladen_next_Automatic on")\
                } else {\
                        fhem("set Rollladen_alle oben")\
                } \
        }\
}
setuuid Rollladen_alle_oben 5cbaebfb-f33f-3d5f-42c8-c4624fcc3b945a0e
attr Rollladen_alle_oben computeAfterInit enable
attr Rollladen_alle_oben room Rollladen

fhem.save
setstate Rollladen_alle_Zufall_oben Next: 00:05:00
setstate Rollladen_alle_Zufall_oben 2023-12-14 03:00:33 state Next: 00:05:00
setstate Rollladen_alle_oben Next: 08:13:00

Der Zeitstempel von fhem.save ist nachts 03:00, also genau da wo ich den Raspi boote.

Hier steht in der fhem.save aber die nachts ermittelte Zeit für den AT richtig drin.

Dies sieht doch so aus, als wenn die Zeit für den AT Rollladen_alle_oben aus der fhem.save nicht mehr gelesen würde oder ?

Viele Grüße
Sven


Raspi 3 mit CUL Stick 433/868MHZ, Homematic

Beta-User

Wenn du immer um 3Uhr neu startest, ist egal, was um 5 Min. nach Mitternacht berechnet wurde...

Das Lesen eines alten Status setzt jedenfalls keinen neuen Timer in Gang.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

sven.scherf

Hi,

das autosave war es.

Autosave auf 1 und es tut wie es soll.

Was ich aber nicht verstehe ist, dass wenn in der fhem.save der korrekte Wert für den AT Rollladen_alle_oben drin steht warum dieser nicht beim start gelesen wird.

Die fhem.save wird unter anderem vom fhem("save") oder bei einem reboot vom System geschrieben.
Deshalb ergab sich ja der Filestamp 03:00(reboot vom Raspi)
Hier stand die richtige Uhrzeit für den AT drin.

Wann wird die fhem.save eingelesen und verarbeitet ?


viele Grüße

Sven

Raspi 3 mit CUL Stick 433/868MHZ, Homematic

rudolfkoenig

fhem.save wird beim save und beim shutdown geschrieben.
Die dafuer verwendete Funktion ist WriteSaveFile.
Wiederholende at Definitionen werden in fhem.cfg gespeichert, einmalige (die ohne *) in fhem.save.

autosave wird automatisch von FHEM auf 0 gesetzt, falls beim Start ein Fehler passiert ist.
Das bleibt solange auf 0, bis es vom Benutzer explizit geaendert (oder entfernt) wird.

In diesem Fall war autosave 0 zusammen mit einem Neustart das Problem.


sven.scherf

Raspi 3 mit CUL Stick 433/868MHZ, Homematic

erwin

hi Sven,
das Konstrukt ist unnötig kompliziert, versuch mal zum test:
define testaAT at *{sprintf('08:%.2d:00',($we)?int(rand(15))+45:int(rand(15)))} {Log3 (undef, 1, "testaAT hit !!!");;}
attr testaAT computeAfterInit 1
attr testaAT room test
#  COMMAND    {Log3 (undef, 1, "testaAT hit !!!");}
#  DEF        *{sprintf('08:%.2d:00',($we)?int(rand(15))+45:int(rand(15)))} {Log3 (undef, 1, "testaAT hit !!!");}
#  FUUID      657afe97-f33f-f1ab-43cd-af072169fab02f65
#  NAME      testaAT
#  NR        122
#  NTM        08:05:00
#  PERIODIC  yes
#  RELATIVE  no
#  REP        -1
#  STATE      Next: 08:05:00
#  TIMESPEC  {sprintf('08:%.2d:00',($we)?int(rand(15))+45:int(rand(15)))}
#  TRIGGERTIME 1702623900
#  TRIGGERTIME_FMT 2023-12-15 08:05:00
#  TYPE      at
#  eventCount 1
#  .attraggr:
#  .attrminint:
#  READINGS:
#    2023-12-14 17:26:38  state          Next: 08:05:00
#
setstate testaAT Next: 08:05:00
setstate testaAT 2023-12-14 17:26:38 state Next: 08:05:00
das computeafterInit ist in diesem Fall nötig!
...die perl-timespec ist zwar kompliziert (weil keine blanks/newlines erlaubt sind), wenn man es übersichtlichtler haben möchjte, könnte man das in eine 99_myUtils.pm auslagern.  ;D
Falls das funktioniert - (im Log die entsprechenden Einträge zu richtigen Zeit sind), - kannst du dein Rollladen_alle_Zufall_oben löschen und diese def für deine Zwecke adaptieren.
l.g. erwin
FHEM aktuell auf RaspberryPI Mdl 1-4
Maintainer: 00_KNXIO.pm 10_KNX.pm
User: CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT, 1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,..,MQTT2, KNX, SONOFF, mySENSORS,....
Hardware:  Busware ROT, Weinzierl IP731, 1-Wire GW,...