Ankündigung

Einklappen
Keine Ankündigung bisher.

Änderung bei prev_change()?

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

    Änderung bei prev_change()?

    Hallo,

    hat sich etwas bei prev_change() getan?
    Im Log meckert er:
    Code:
    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

    #2
    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
    HM-KNX - KNX-Interface für Hörmann Garagentorantriebe: http://www.ing-budde.de

    Kommentar


      #3
      Hi Robert,
      danke für deine Antwort
      Zitat von Robert Beitrag anzeigen
      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:
      Code:
        
           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

      Kommentar


        #4
        Hi,

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

        Bis bald

        Marcus

        Kommentar


          #5
          Wunderbar, dann bin ich ja beruhigt!
          Danke!

          Kommentar


            #6
            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
            HM-KNX - KNX-Interface für Hörmann Garagentorantriebe: http://www.ing-budde.de

            Kommentar


              #7
              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

              Kommentar


                #8
                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

                Kommentar


                  #9
                  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.
                  Umgezogen? Ja! ... Fertig? Nein!
                  Baustelle 2.0 !

                  Kommentar


                    #10
                    Hallo Hendrik,

                    Zitat von henfri Beitrag anzeigen
                    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

                    Kommentar


                      #11
                      Mach ich.

                      von unterwegs gesendet

                      Kommentar


                        #12
                        Hi Mirko,

                        Zitat von JuMi2006 Beitrag anzeigen
                        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

                        Kommentar


                          #13
                          Zitat von mknx Beitrag anzeigen
                          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.

                          Zitat von mknx Beitrag anzeigen
                          Weiterhin habe ich den Vorschlag von Robert aufgenommen und restauriere bei gecacheten Items die last_change Zeit.
                          Vielen Dank!

                          Viele Grüße
                          Robert
                          HM-KNX - KNX-Interface für Hörmann Garagentorantriebe: http://www.ing-budde.de

                          Kommentar


                            #14
                            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
                            Umgezogen? Ja! ... Fertig? Nein!
                            Baustelle 2.0 !

                            Kommentar


                              #15
                              Zitat von JuMi2006 Beitrag anzeigen
                              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
                              HM-KNX - KNX-Interface für Hörmann Garagentorantriebe: http://www.ing-budde.de

                              Kommentar

                              Lädt...
                              X