Änderung bei prev_change()?

[henfri]

Hallo,

hat sich etwas bei prev_change() getan?
Im Log meckert er:

2013-10-14 21:36:39 WARNING  Allgemein.Stromzaehler.Momentanleistung_freq Problem evaluating 4500/sh.Allgemein.Stromzaehler.Counter.prev_change(): unsupported opera
nd type(s) for /: 'int' and 'datetime.datetime'

Er mag also einen int nicht durch datetime teilen. Aber früher war prev_change() doch ein float, mit der Zeit die das Item zuletzt in s gültig war, oder?

Gruß,
Hendrik

[Robert]

Hi Hendrik,

Guck doch bei so was einfach kurz selber in den Code von lib/item.py - dann weißt du es sofort und eindeutig. Du willst wahrscheinlich .age()?

Und was war früher? Vor 1945? Vor dem Wechsel auf 3.2? Oder das Develop gestern?

Wohlwollende Grüße
Robert

[henfri]

Hi Robert,
danke für deine Antwort

Guck doch bei so was einfach kurz selber in den Code von lib/item.py - dann

Ja, sicher ein guter Tipp. Irgendwie scheitere ich aber momentan noch an den ganz kleinen Dingen...
Hier mal der Auszug:

  
     def last_change(self):
        return self._last_change
  def prev_change(self):
        return self._prev_change

    def changed_by(self):
        return self._changed_by

    def age(self):
        delta = self._sh.now() - self._last_change
        return delta.total_seconds()

Also da ist's ja eindeutig, dass es Unterschied ist. (int vs timedate)
In der Doku ist es auch etwas unterschiedlich beschrieben, es wird aber nicht deutlich, dass eins int und eins timedate ist:

age()

Returns the age of the current item value.

last_change()

Returns an datetime object with the latest update time.

prev_change()

Returns the age in seconds of the change before the latest update.

Im Gegenteil: nur last_change() sollte ein datetime objekt geben.

Du willst wahrscheinlich .age()?

Bei .age() hatte ich den Eindruck, dass das manchmal (?!) eine sehr kleine Zahl ist, zu dem Zeitpunkt zu dem eval abgearbeitet wird. Und mir ist es egal, ob ich die Zeit seit der letzten Änderung oder zwischen der vorletzten und letzten habe. Letztere hat keine Timing-Probleme.

Und was war früher? Vor 1945? Vor dem Wechsel auf 3.2? Oder das Develop gestern?

Vor zwei Wochen. Da war mir das nicht aufgefallen.


Gruß,
Hendrik

[callidomus]

Hi,

sorry da ist/war ein Bug drin. prev_change wurde nicht richtig initialisiert.

Bis bald

Marcus

[henfri]

Wunderbar, dann bin ich ja beruhigt!
Danke!

[Robert]

Hm, hatte mir das sogar noch die Tage im Konstruktor angeschaut, um zu sehen wie ich feststellen kann ob das Item schon geupdated wurde.

Finde es etwas inkonsequent, dass foo_change mal int, mal datetime sind. Zudem: 0? Nicht eher max_range-1? Das sind eher kleine Änderungen, die aber das Erkennen ob ein Item schon mal geändert wurde sehr erleichtern, bzw. auch Divisionen durch 0 verhindern.

Weiter: Könnte man anhand des Dateidatums der Cache-Files (bei cache = true) nicht "last_change" und damit auch age() korrekt wiederherstellen?

Viele Grüße
Robert

[callidomus]

Hallo Ihr beiden,

ich habe gerade die Item-Klasse umstrukturiert.

Was haltet Ihr von dem neuen Verhalten?

Es gibt in Zukunft nur noch zwei Methoden: last_change und next2last_change. last_change liefert die Sekunden, seit das Item das letzte mal geändert wurde. next2last_change liefert die Sekunden der Gültigkeit des vorletzten Wertes.

age() entfällt - entspricht dem neuen last_change(). Das alte last_change() mit datetime entfällt ebenso.

Weiterhin habe ich den Vorschlag von Robert aufgenommen und restauriere bei gecacheten Items die last_change Zeit.
Wenn ich mal nichts besseres zu tun habe, mache ich das auch noch für sqlite mit last_change und next2last_change.

Bis bald

Marcus

[henfri]

Hallo,

ich kann das nicht einschätzen. Wo ich mich bisher etwas schwer tue, ist das Timing und die Reihenfolge der Abarbeitung (update von eval und update des Age/prev_change).
Das wäre zumindest für die Doku noch wichtig.

gruß,
Hendrik

[JuMi2006]

Doofe Frage, greift last_change auch nachdem ein item durch enforce_update aktualisiert wurde aber den Wert nicht verändert hat?

Für mich wäre z.B. age() das Alter von value und last_change() das Alter seit dem letzten Update.

[callidomus]

Hallo Hendrik,

Wo ich mich bisher etwas schwer tue, ist das Timing und die Reihenfolge der Abarbeitung (update von eval und update des Age/prev_change).
Das wäre zumindest für die Doku noch wichtig.

Das eval eines Items wird immer als erstes durchgeführt, da man sonst nicht vergleichen kann, ob sich der Wert geändert hat.
Wenn sich der Wert geändert hat, dann wird der Wert aktualisiert (inkl. last_change & next2last_change) und triggert dannach die evals der anderen Items (über watch_items verknüpft).

Kannst Du das sinnvoll für die Doku aufbereiten?

Bis bald

Marcus

[henfri]

Mach ich.

von unterwegs gesendet

[callidomus]

Hi Mirko,

Für mich wäre z.B. age() das Alter von value und last_change() das Alter seit dem letzten Update.

last_change wird bei enforce_updates neu gesetzt. Hast Du ein konkretes Beispiel bei dem ein Item enforce_updates gesetzt hat und das Alter wichtig ist?

Bis bald

Marcus

[Robert]

Was haltet Ihr von dem neuen Verhalten?

Es gibt in Zukunft nur noch zwei Methoden: last_change und next2last_change. last_change liefert die Sekunden, seit das Item das letzte mal geändert wurde. next2last_change liefert die Sekunden der Gültigkeit des vorletzten Wertes.

age() entfällt - entspricht dem neuen last_change(). Das alte last_change() mit datetime entfällt ebenso.

Frei raus: Nicht soo intuitiv.

Für mich ist "last_change()" vom Sprachgefühl ein absoluter Zeitstempel, sprich entweder Unixzeit oder Datetime. Es gibt bei mir auch durchaus Logiken, wo ich diesen Zeitstempel nicht mit "now()" verrechne, sondern mit einem anderen Zeitstempel. Jetzt müsste ich "now()" wieder draufrechnen und zurückwandeln, um dann vergleichen zu können.
Ich denke jeder könnte anhand des Codeschnipsels (now()-item.last_change()).total_seconds() verstehen und benutzen. Oder eine Funktion (macht den Kohl auch nicht fett!) "sec_since_last_change" - da ist dann Einheit und zeitliche Relation klar.

Noch eine kleine Bitte: auch im develop sollte es bitte für sowas ne Übergangszeit geben, wo ".age" auf ".last_change()" für 1-2 Wochen gemappt wird mit dicker "logger.warning". Zumindest bei Jan und mir stehen jetzt Logiken. War ja eine "offizielle" Funktion ohne "_". Ich weiß, ich weiß - ist "develop" - aber man muss die Leute ja nicht unnötig triezen.

Weiterhin habe ich den Vorschlag von Robert aufgenommen und restauriere bei gecacheten Items die last_change Zeit.

Vielen Dank!

Viele Grüße
Robert

[JuMi2006]

Wenn wir bei "Wünsch Dir was!" wären würde ich es folgendermaßen lösen

age() = Alter des aktuellen Wertes, egal ob ein enforce_update kam oder nicht in Sekunden

prev_age() = Alter des vorherigen Wertes, egal ob ein enforce_update kam oder nicht in Sekunden

last_change() = Zeitpunkt der letzten Änderung des Wertes (kein update!) in unix-time

last_change.dt() = Zeitpunkt der letzten Änderung des Wertes (kein update!) als datetime

prev_change() = Zeitpunkt der vorletzten Änderung des Wertes (kein update!) in unix-time

prev_change.dt() = Zeitpunkt der vorletzten Änderung des Wertes (kein update!) als datetime

last_update() = Zeitpunkt der letzten Aktualisierung des Wertes (includiert updates) in unix-time

last_update.dt() = Zeitpunkt der letzten Aktualisierung des Wertes (includiert updates) als datetime

So wäre das für MICH als Normalsterblicher irgendwie sinnig und man könnte je nach belieben damit arbeiten.

Das war mein Wunschkonzert Ich würde am liebsten alles in unix-Zeit haben (Auch Sonnenauf- und Untergang usw.) und im Zweifel mit .dt() daraus ein datetime machen.

Grüße

[Robert]

age() = Alter des aktuellen Wertes, egal ob ein enforce_update kam oder nicht in Sekunden +1

prev_age() = Alter des vorherigen Wertes, egal ob ein enforce_update kam oder nicht in Sekunden

last_change() = Zeitpunkt der letzten Änderung des Wertes (kein update!) in unix-time

last_change.dt() = Zeitpunkt der letzten Änderung des Wertes (kein update!) als datetime +1

prev_change() = Zeitpunkt der vorletzten Änderung des Wertes (kein update!) in unix-time

prev_change.dt() = Zeitpunkt der vorletzten Änderung des Wertes (kein update!) als datetime +1

last_update() = Zeitpunkt der letzten Aktualisierung des Wertes (includiert updates) in unix-time

last_update.dt() = Zeitpunkt der letzten Aktualisierung des Wertes (includiert updates) als datetime

Finde ich mich drin wieder. Hab mal die Attribute, die ich auch genau so wichtig fände markiert. Auch das "age()" ohne force_updates() nachgeführt würde fände ich gut. "prev_age()" bräuchte ich hingegen nicht wirklich und die Umwandlung datetime->Unixtime ist durch anhängen von ".utctimetuple()" selber möglich. Aber eben auch die Begrifflichkeiten und Möglichkeiten die sich ergeben finde ich gut.

Grüße
Robert