Python 3.2 Migration in develop bzw. 1.0 Release

[callidomus]

Hi Ronny,

nein, das habe ich noch nie gesehen. Diese Fetzen langen aber auch nicht um irgendwie den Kontext zu erahnen.

Immer wieder gerne referiert:
https://knx-user-forum.de/smarthome-...rbehebung.html

Ich brauche mehr Informationen.

Bis bald

Marcus

[callidomus]

Hallo,

ich habe folgende Änderungen, auf Basis der Anregung aus https://knx-user-forum.de/347544-post14.html, vorgenommen.

• age() = Alter des aktuellen Wertes, also seit der letzten Änderung in Sekunden
• prev_age() = Alter des vorherigen Wertes, also seit der vorletzten Änderung in Sekunden
• last_change() = Zeitpunkt der letzten Änderung des Wertes als datetime
• prev_change() = Zeitpunkt der vorletzten Änderung des Wertes als datetime
• last_update() = Zeitpunkt der letzten Aktualisierung des Wertes (includiert Änderungen) als datetime

Weiterhin gibt es zwei neue Zeit-Methoden in tools:

• sh.tools.dt2ts(dt) konvertiert ein datetime in ein Unix Timestamp
• sh.tools.dt2js(dt) konvertiert ein datetime in ein JavaScript Timestamp (Sekunden & Millisekunden)

Bis bald

Marcus

[callidomus]

Ach ja, und changed_by liefert
'Init:None' für intiale, 'Cache:None' für gecachte Werte zurück.

Bis bald

Marcus

[stromie]

Hallo Marcus

schon das du mich an die https://knx-user-forum.de/smarthome-p...rbehebung.html erinnerst.
Leider trat der Fehler zum ersten mal auf. Im logfile steht nicht viel anders drin da nicht im Debug lief.
Habe jetzt erst mal den Debug angemacht und werde sehen ob der Fehler wieder auftritt.
Es hat was mit dem threading zu tun.
Ich dachte vielleicht ist so was schon mal bei dir aufgetreten.


Ich werde das weiter untersuchen. Vielleicht liegt es an meinen Dimplex plugin das per pymodbus auf die WP zugreift.


Grüße

[callidomus]

Hi Mike,

Hallo,

beim "Refactoring lib.item" wurde die Methode "fade" entfernt. Gibt es dafür einen Ersatz? Ich habe diese Methode in einigen Logiken verwendet.

ist wieder drin.

Bis bald

Marcus

[callidomus]

Hallo,

so wir näher uns einem Feature-Freeze. Ich bin dabei die Tests vorzubereiten.

Einen habe ich noch:

sh.match_items kann noch nach einem Attribute filtern.

z.B. sh.match_items('winter*:heizung') liefert alle Items zurück die mit winter anfangen und ein Attribute 'heizung' definiert haben.

Dadurch können die Items, bei eval_trigger, auch den Attributfilter verwenden.

Bis bald

Marcus

[2ndsky]

Python 3.2 Migration in develop bzw. 1.0 Release

Als kleine Anregung, wie wäre es noch mit last_value() für den letzten Wert? Das würde manche Logiken vereinfachen und manchmal sogar den Einsatz des sqlite Plugins überflüssig machen.

[Robert]

Hi Marcus,

beim Wiederherstellen von __last_change wird bei gecacheten Items ein "offset-naive" datetime verwendet, der dann in Kombination mit _sh_now() crasht:

2013-10-18 11:28:22,380 INFO     1w-sen       Item Garage.Kombisensor.Versorgungsspannung = 4.72 via 1-Wire /bus.3/26.6F0973010000/VDD None -- item.py:__update:357
2013-10-18 11:28:22,498 ERROR    1w-sen       Method 1w-sen exception: can't subtract offset-naive and offset-aware datetimes -- scheduler.py:_task:348
Traceback (most recent call last):
  File "/usr/local/smarthome/lib/scheduler.py", line 344, in _task
    obj()
  File "/usr/local/smarthome/plugins/onewire/__init__.py", line 395, in _sensor_cycle
    item(value, '1-Wire', path)
  File "/usr/local/smarthome/lib/item.py", line 279, in __call__
    self.__update(value, caller, source, dest)
  File "/usr/local/smarthome/lib/item.py", line 350, in __update
    self.__prev_age = (self._sh.now() - self.__last_change).total_seconds()
TypeError: can't subtract offset-naive and offset-aware datetimes
2013-10-18 11:28:24,192 INFO     Main         knx: 1.1.230 set 6/3/150 to 0.16 -- __init__.py:parse_telegram:190

Die Daten des Kombisensor stehen bei mir alle auf "cache = true", da sonst wenn die einzelnen Messwerte eintrudeln fehlerhafte Ergebnisse berechnet werden (daher auch mein Wunsch sowas detektieren zu können um ein Eval erst starten zu lassen, wenn alle Werte "geupdated" wurden - nur als Randbemerkung!).

Fix:

diff --git a/lib/item.py b/lib/item.py
index 805b527..65193b9 100755
--- a/lib/item.py
+++ b/lib/item.py
@@ -99,7 +99,7 @@ def _cast_num(value):
 #####################################################################
 def _cache_read(filename):
     ts = os.path.getmtime(filename)
-    dt = datetime.datetime.fromtimestamp(ts)
+    dt = datetime.datetime.fromtimestamp(ts, self._sh._tzinfo)
     value = None
     with open(filename, 'rb') as f:
         value = pickle.load(f) 

[callidomus]

Hi Robert,

danke für den Fix. Ist integriert.

Bis bald

Marcus

[callidomus]

Hi Robert,

Die Daten des Kombisensor stehen bei mir alle auf "cache = true", da sonst wenn die einzelnen Messwerte eintrudeln fehlerhafte Ergebnisse berechnet werden (daher auch mein Wunsch sowas detektieren zu können um ein Eval erst starten zu lassen, wenn alle Werte "geupdated" wurden - nur als Randbemerkung!).

ein Item erst triggern zu lassen, wenn es wirklich das erste mal geändert wird, ist denkbar.
Aber bei das eval erst durchführen zu lassen, wenn alle verwendetetn Items geändert worden sind, dafür fehlt mir ein Konzept. Ich denke das ist auch nicht immer gewünscht. Das hängt halt start vom eval ab.
Hast Du einen Vorschlag oder Patch?

Bis bald

Marcus

[mike]

Hi Marcus,

danke für das Fade. Ich nutze das übrigens am häufigsten für Countdown-Timer.

Ich habe noch ein paar Probleme in lib/item.py entdeckt. Alles im Zusammenhang mit eval/eval_trigger. Ich habe einen Patch angehangen ...

Grüße
Mike

[callidomus]

Hi Mike,

danke für Deinen Patch. Es sollte jetzt funktionieren.

Bis bald

Marcus

[henfri]

Hallo,

ich denke, das hier ist noch ein Bug:

2013-10-19 10:47:15 ERROR    1w-disc      no payload for /bus.0/26.7ED96B010000/pages/page.3
Traceback (most recent call last):
  File "/usr/local/smarthome/plugins/onewire/__init__.py", line 181, in identify_sensor
    page3 = self.read(path + 'pages/page.3')  # .encode('hex').upper()
  File "/usr/local/smarthome/plugins/onewire/__init__.py", line 75, in read
    return self._request(path, cmd=2)
  File "/usr/local/smarthome/plugins/onewire/__init__.py", line 145, in _request
    raise owex('no payload for {0}'.format(path))
plugins.onewire.owex: no payload for /bus.0/26.7ED96B010000/pages/page.3

und:

2013-10-19 12:02:48 ERROR    Main         Connections: local variable 'reply' referenced before assignment
Traceback (most recent call last):
  File "/usr/local/smarthome/lib/connection.py", line 108, in poll
    con._in()
  File "/usr/local/smarthome/lib/connection.py", line 240, in _in
    self.found_terminator(data)
  File "/usr/local/smarthome/plugins/visu/__init__.py", line 410, in rfc6455_parse
    self.json_parse(payload.decode())
  File "/usr/local/smarthome/plugins/visu/__init__.py", line 313, in json_parse
    if 'update' in reply:
UnboundLocalError: local variable 'reply' referenced before assignment

Gruß,
Hendrik

[callidomus]

Hallo Hendrik,

vielen Dank. Das hat mir echt geholfen.

Der Onewire-Bug ist noch offen. Was ist denn 26.7ED96B010000 für ein Sensor? Also Hersteller und Typ.

Bis bald

Marcus

[henfri]

Hi Marcus,

vielen Dank. Das hat mir echt geholfen.

Schön. Da hatte ich beim Posten meine Zweifel (mir hätte es nicht geholfen ;-)

Der Onewire-Bug ist noch offen. Was ist denn 26.7ED96B010000 für ein Sensor? Also Hersteller und Typ.

Hersteller ist einfach: ElabNet.
Typ muss ich nachsehen...:
Ah, das ist ein BMS, bei dem -dank der Litze die am Busmaster hängt- wohl die 5V abgegangen sind. Das CommunityGate Web-IF sagt: 0V und Error bei den Werten.

Anbei mal die Seite aus dem Web-IF und der Inthalt des Verzeichnisses im ow-fuse (wobei es da Lesefehler gab, als ich die tar.gz (.zip bitte ignorieren, das ist nur um die Foren-SW auszutricksen) erstellt habe)

Gruß,
Hendrik