Ankündigung

**2ndsky** · 19.06.2013, 14:38

Ich habe ein ähnliches Problem, das ich noch nicht genauer analysieren konnte warum, aber zumindest weiß ich seit welcher Änderung das Problem besteht. Ich muss mal meine Logs noch an Marcus schicken deswegen. IMHO ist das ein Problem des KNX Plugins. Marcus hat für ein Feature das KNX Plugin modifiziert ("knx plugin: send status update for knx_send group addresses").

In commit 909a3fa8dfde241aa653f7f9f0f79b5cd04923ed wurde folgendes geändert:

Code:

@@ -300,6 +300,5 @@ def parse_logic(self, logic):
                     self.gar[ga] = {'dpt': dpt, 'item': None, 'logic': logic}
 
     def update_item(self, item, caller=None, source=None):
-        if caller != 'KNX':
-            for ga in item.conf['knx_send']:
-                self.groupwrite(ga, item(), item.conf['knx_dpt'])
+        for ga in item.conf['knx_send']:  # send status update
+            self.groupwrite(ga, item(), item.conf['knx_dpt'])

Seit dem habe ich das Problem, das Wert GAs von sh.py empfangen, geändert und damit erneut gesendet werden. Der Aktor ändert daraufhin den Wert und sendet den Status erneut. Dieser wird wieder von sh.py empfangen und das Spiel beginnt von vorne. Irgendwann stabilisiert sich das auf einen bestimmten Wert.

Wie gesagt, ich konnte noch nicht analysieren, warum das so ist und hatte auch noch keine Zeit das Log an Marcus zu schicken. Denke aber du könntest das gleiche Problem haben. Versuch einfach mal die Änderung im KNX Plugin rückgängig zu machen und die "if caller != 'KNX'" Bedingung wieder einzubauen und schau mal, ob es dann noch auftritt.

**Robert** · 19.06.2013, 14:57

Ja, passt. Das würde zu meiner Einschätzung, dass da was "numerisch" nicht ok ist, passen. Allerdings erklärt das nicht warum das bei mir (scheinbar) nur an visualisierten Raffstoren auftritt. Vielleicht habe ich da ja auch zu viel gespielt.

Deinen Sachverhalt habe ich übrigens gestern erst gehabt:

Code:

[Vorratsraum]
  [[Deckenlicht]]
    type = bool
    visu = yes
    knx_dpt = 1
    knx_send = 1/0/7
    knx_cache = 1/0/8
    [[[Automatikschalter]]]
      type = bool
      enforce_updates = true
      knx_dpt = 1
      knx_listen = 5/0/203

1/0/7 ist "Dauerbeleuchtung des Aktors"
1/0/8 ist Status (also ob Lampe leuchtet oder nicht - egal warum)
5/0/203 ist Automatiktrigger für Treppenhausfunktion

seit dem von dir beschriebenen Update hatte die Beleuchtung eine "Selbsthaltefunktion": Autotrigger löste aus, Beleuchtung ging an und sh.py hat schön von 1/0/8 auf 1/0/7 "zurückgekoppelt". Das ist korrekt, sonst wäre das Item inkonsistent! Da bleibt nix anderes, als das Item richtig zu definieren:

Code:

[Vorratsraum]
  [[Deckenlicht]]
    type = bool
    visu = yes
    knx_dpt = 1
    knx_cache = 1/0/8
    [[[Dauerbeleuchtung]]]
      type = bool
      visu = yes
      knx_dpt = 1
      knx_send = 1/0/7
      knx_cache = 1/0/7
    [[[Automatikschalter]]]
      type = bool
      visu = yes
      enforce_updates = true
      knx_dpt = 1
      knx_listen = 5/0/203

Also These: Die Umwandlung von DPT 5001 ist nicht numerisch stabil, d.h. bei Vorwärts- und Rückwärtswandlung (% (0...100) <-> 8bit (0...255) kommen inkonsistente Werte raus.

Kann man das Thema ggfl. in das sh.py Forum schieben? Andernfalls muss hier evtl. ein Haken dran und ein neuer Thread her...

Grüße
Robert

**callidomus** · 19.06.2013, 15:37

Hallo Robert,

Zitat von Robert Beitrag anzeigen

Also These: Die Umwandlung von DPT 5001 ist nicht numerisch stabil, d.h. bei Vorwärts- und Rückwärtswandlung (% (0...100) <-> 8bit (0...255) kommen inkonsistente Werte raus.

Ich kann die These bestätigen und könnte Sie auch mathematisch beweisen/nachvollziehen. DPT 5.001 löst in ≈ 0,4 % Schritten auf.

Hilft jetzt aber nicht. Was hilft, ist es auf dpt5 umzustellen. Dazu muss das Widget aber von 0-255 gehen, dann entfällt die Konvertierung.

Bis bald

Marcus

**Robert** · 19.06.2013, 15:39

Bug: Umwandlung von/nach DPT 5.001 nicht konsistent!

Hi!

Ausgehend von diesem Thread https://knx-user-forum.de/smartvisu/...tml#post322183 habe ich die Umwandlungen für DPT 5.001 getestet: Es kommt hierbei zu Ungenauigkeiten die blöde Auswirkungen haben (siehe obiger Thread), wenn es zu einer Rückkopplung kommt.

Ich versuche heute Abend einen Fix mit Pull-Request (ob ich das hinbekomme...) anzubieten.

Testcase (im Verzeichnis des KNX-Plugins auszuführen)

Code:

#!/usr/bin/env python

import dpts

for percent in range(0,101):
    bit8 = dpts.encode['5001'](percent)

    percent2 = dpts.decode['5001'](chr(bit8[1]))
    print "Test: {0} -> {1} -> {2}".format(percent,bit8,percent2)

Ergebnis:

Code:

Test: 0 -> [0, 0] -> 0
Test: 1 -> [0, 2] -> 0
Test: 2 -> [0, 5] -> 1
Test: 3 -> [0, 7] -> 2
Test: 4 -> [0, 10] -> 3
Test: 5 -> [0, 12] -> 4
Test: 6 -> [0, 15] -> 5
Test: 7 -> [0, 17] -> 6
Test: 8 -> [0, 20] -> 7
Test: 9 -> [0, 22] -> 8
Test: 10 -> [0, 25] -> 9
Test: 11 -> [0, 28] -> 10
Test: 12 -> [0, 30] -> 11
Test: 13 -> [0, 33] -> 12
Test: 14 -> [0, 35] -> 13
Test: 15 -> [0, 38] -> 14
Test: 16 -> [0, 40] -> 15
Test: 17 -> [0, 43] -> 16
Test: 18 -> [0, 45] -> 17
Test: 19 -> [0, 48] -> 18
Test: 20 -> [0, 51] -> 20
Test: 21 -> [0, 53] -> 20
Test: 22 -> [0, 56] -> 21
Test: 23 -> [0, 58] -> 22
Test: 24 -> [0, 61] -> 23
Test: 25 -> [0, 63] -> 24
Test: 26 -> [0, 66] -> 25
Test: 27 -> [0, 68] -> 26
Test: 28 -> [0, 71] -> 27
Test: 29 -> [0, 73] -> 28
Test: 30 -> [0, 76] -> 29
Test: 31 -> [0, 79] -> 30
Test: 32 -> [0, 81] -> 31
Test: 33 -> [0, 84] -> 32
Test: 34 -> [0, 86] -> 33
Test: 35 -> [0, 89] -> 34
Test: 36 -> [0, 91] -> 35
Test: 37 -> [0, 94] -> 36
Test: 38 -> [0, 96] -> 37
Test: 39 -> [0, 99] -> 38
Test: 40 -> [0, 102] -> 40
Test: 41 -> [0, 104] -> 40
Test: 42 -> [0, 107] -> 41
Test: 43 -> [0, 109] -> 42
Test: 44 -> [0, 112] -> 43
Test: 45 -> [0, 114] -> 44
Test: 46 -> [0, 117] -> 45
Test: 47 -> [0, 119] -> 46
Test: 48 -> [0, 122] -> 47
Test: 49 -> [0, 124] -> 48
Test: 50 -> [0, 127] -> 49
Test: 51 -> [0, 130] -> 50
Test: 52 -> [0, 132] -> 51
Test: 53 -> [0, 135] -> 52
Test: 54 -> [0, 137] -> 53
Test: 55 -> [0, 140] -> 54
Test: 56 -> [0, 142] -> 55
Test: 57 -> [0, 145] -> 56
Test: 58 -> [0, 147] -> 57
Test: 59 -> [0, 150] -> 58
Test: 60 -> [0, 153] -> 60
Test: 61 -> [0, 155] -> 60
Test: 62 -> [0, 158] -> 61
Test: 63 -> [0, 160] -> 62
Test: 64 -> [0, 163] -> 63
Test: 65 -> [0, 165] -> 64
Test: 66 -> [0, 168] -> 65
Test: 67 -> [0, 170] -> 66
Test: 68 -> [0, 173] -> 67
Test: 69 -> [0, 175] -> 68
Test: 70 -> [0, 178] -> 69
Test: 71 -> [0, 181] -> 70
Test: 72 -> [0, 183] -> 71
Test: 73 -> [0, 186] -> 72
Test: 74 -> [0, 188] -> 73
Test: 75 -> [0, 191] -> 74
Test: 76 -> [0, 193] -> 75
Test: 77 -> [0, 196] -> 76
Test: 78 -> [0, 198] -> 77
Test: 79 -> [0, 201] -> 78
Test: 80 -> [0, 204] -> 80
Test: 81 -> [0, 206] -> 80
Test: 82 -> [0, 209] -> 81
Test: 83 -> [0, 211] -> 82
Test: 84 -> [0, 214] -> 83
Test: 85 -> [0, 216] -> 84
Test: 86 -> [0, 219] -> 85
Test: 87 -> [0, 221] -> 86
Test: 88 -> [0, 224] -> 87
Test: 89 -> [0, 226] -> 88
Test: 90 -> [0, 229] -> 89
Test: 91 -> [0, 232] -> 90
Test: 92 -> [0, 234] -> 91
Test: 93 -> [0, 237] -> 92
Test: 94 -> [0, 239] -> 93
Test: 95 -> [0, 242] -> 94
Test: 96 -> [0, 244] -> 95
Test: 97 -> [0, 247] -> 96
Test: 98 -> [0, 249] -> 97
Test: 99 -> [0, 252] -> 98
Test: 100 -> [0, 255] -> 100

**Robert** · 19.06.2013, 15:40

neuer Thread:

https://knx-user-forum.de/smarthome-...nd-weiter.html

Nachtrag: Doch klar, wenn die Umrechnung numerisch stabil ist ist alles ok!

siehe: http://www.tapko.de/de/service/tools.html - einfach mal paar Prozentwerte rein (und kaufmännisch runden!)

**Robert** · 19.06.2013, 16:10

Das Hin- und Hergeschiebe der Beiträge und ganzer Threads ist ein wenig... naja... Ein Haken an meinen ersten Thread hätte den wohl erledigt und man hätte sich auf die Hauptsache konzentrieren können.

Ich habe jetzt einen Patch (mit Float rechnen und kaufmännisch runden):

dpts.py

Code:

def de5001(payload):
    if len(payload) != 1:
        return None
    return int(round(struct.unpack('>B', payload)[0] * 100.0 / 255))

evtl. sollten die anderen DPTs auch untersucht werden.

Grüße
Robert

**2ndsky** · 19.06.2013, 16:58

Ich habe auch mit DPT5 ein Problem. Wenn ich besagte Zeile oben nicht im KNX Plugin drin habe, wird mir sporadisch Items auf Werte gesetzt, die mit der Zeile nicht passieren.

Hier mal der Auszug der relevanten Stelle (komplettes Log im Anhang, einfach .zip entfernen, ist KEIN gezipptes File, aber .log kann man nicht hochladen und .txt ist nur bis knapp 20K erlaubt):

Code:

1393 2013-06-17 17:37:42,539 SmartHome.py DEBUG    knx: 1.1.3 set 1/5/23 to 12 -- __init__.py:parse_telegram:185
1394 2013-06-17 17:37:42,539 SmartHome.py DEBUG    eg.kueche.leds.blau.wert = 12 via KNX 1.1.3 -- item.py:_update:219
1395 2013-06-17 17:37:42,559 SmartHome.py DEBUG    knx: 1.0.254 set 1/1/23 to 1 -- __init__.py:parse_telegram:180
1396 2013-06-17 17:37:42,594 SmartHome.py DEBUG    knx: 1.0.254 set 1/4/23 to c -- __init__.py:parse_telegram:180
1397 2013-06-17 17:37:42,612 SmartHome.py DEBUG    knx: 1.1.3 set 1/5/24 to 51 -- __init__.py:parse_telegram:185
1398 2013-06-17 17:37:42,612 SmartHome.py DEBUG    eg.kueche.leds.weiss.wert = 51 via KNX 1.1.3 -- item.py:_update:219
1399 2013-06-17 17:37:42,655 SmartHome.py DEBUG    knx: 1.0.254 set 1/4/24 to 33 -- __init__.py:parse_telegram:180
...
1402 2013-06-17 17:37:42,854 SmartHome.py DEBUG    knx: 1.1.3 set 1/5/23 to 255 -- __init__.py:parse_telegram:185
1403 2013-06-17 17:37:42,854 SmartHome.py DEBUG    eg.kueche.leds.blau.wert = 255 via KNX 1.1.3 -- item.py:_update:219
1404 2013-06-17 17:37:42,893 SmartHome.py DEBUG    knx: 1.0.254 set 1/4/23 to ff -- __init__.py:parse_telegram:180

1/5/23 = Status LED blau
1/4/23 = Wert setzen LED blau
1/5/24 = Status LED weiß
1/4/24 = Wert setzen LED weiß

Der Wert für eg.kueche.leds.blau.wert von 255 kommt übern Bus vom DALI GW... es gibt aber keinen KNX TLN der den Wert auf 255 setzt. Verwende ich die Bedingung if caller != 'KNX' tritt dieses Phänomen nicht auf. Außerdem, wenn ich über den Bus den Wert empfange, muss dieser ja nicht wieder auf den Bus geschrieben werden.

Die Items sind wie folgt konfiguriert:

Code:

[eg]
    [[kueche]]
        [[[leds]]]
            [[[['blau']]]]
                type=bool
                visu=true
                knx_dpt=1
                knx_send=1/1/23
                knx_cache=1/2/23

                [[[[['wert']]]]]
                    type=num
                    visu=true
                    knx_dpt=5
                    knx_send=1/4/23
                    knx_cache=1/5/23

EDIT: zu der Zeit als das angehänget Log erstellt wurde waren die knx_cache noch knx_init.

Angehängte Dateien

smarthome.log.zip (195,7 KB, 5x aufgerufen)

**callidomus** · 19.06.2013, 17:05

Zitat von Robert Beitrag anzeigen

Kann man das Thema ggfl. in das sh.py Forum schieben? Andernfalls muss hier evtl. ein Haken dran und ein neuer Thread her...

Zitat von Robert Beitrag anzeigen

Das Hin- und Hergeschiebe der Beiträge und ganzer Threads ist ein wenig... naja... Ein Haken an meinen ersten Thread hätte den wohl erledigt und man hätte sich auf die Hauptsache konzentrieren können.

Scherzkecks

**callidomus** · 19.06.2013, 17:14

Hallo Robert,

Zitat von Robert Beitrag anzeigen

Ich habe jetzt einen Patch (mit Float rechnen und kaufmännisch runden):

danke, sieht gut aus.

Code:

def en5001(value):
   return [0, int(int(value) * 255[COLOR="Red"].0[/COLOR] / 100) & 0xff]

sollte auch noch geändert werden.

Möchtest Du es einchecken?

Bis bald

Marcus

**callidomus** · 19.06.2013, 17:17

Hi Niko,

Zitat von 2ndsky Beitrag anzeigen

Ich habe auch mit DPT5 ein Problem. Wenn ich besagte Zeile oben nicht im KNX Plugin drin habe,

DPT5 != DPT5001

Und welche Zeile meinst Du? caller != 'KNX'? Oder die von Robert?

Bis bald

Marcus

**2ndsky** · 19.06.2013, 17:19

Hallo Marcus,

Zitat von mknx Beitrag anzeigen

DPT5 != DPT5001

ist mir klar, ich wollte damit aussagen, dass es nicht nur bei DPT5001 zu Problemen kommen kann.

Zitat von mknx Beitrag anzeigen

Und welche Zeile meinst Du? caller != 'KNX'? Oder die von Robert?

caller != 'KNX'

**callidomus** · 19.06.2013, 17:27

Hi Niko,

Ich verstehe das Problem nicht, welcher Wert ist nicht gewollt?

Zitat von 2ndsky Beitrag anzeigen

Der Wert für eg.kueche.leds.blau.wert von 255 kommt übern Bus vom DALI GW... es gibt aber keinen KNX TLN der den Wert auf 255 setzt.

Von welchem Bus sprichst Du? Doch von KNX. Dann ist das DALI GW (1.1.3) der TLN der den Wert setzt!

Zitat von 2ndsky Beitrag anzeigen

Außerdem, wenn ich über den Bus den Wert empfange, muss dieser ja nicht wieder auf den Bus geschrieben werden.

Wenn Du eine Status-GA verwendest (in dem Fall knx_send), dann schon.
In diesem Fall ist das so vollkommen korrekt.

Bis bald

Marcus

**2ndsky** · 19.06.2013, 17:43

Zitat von mknx Beitrag anzeigen

Von welchem Bus sprichst Du? Doch von KNX. Dann ist das DALI GW (1.1.3) der TLN der den Wert setzt!

Aus irgendeinem Grund wird der Wert für blau auf 255 gesetzt... ich habe keine Ahnung wo her. Das DALI GW meldet diesen Status zurück, wer den Wert gesetzt hat ist nicht ersichtlich. Man sieht nur, dass sh.py ihn zuvor auf "c" gesetzt hat (vermutlich wird hier hex und dezimal Darstellung gemischt). Ich weiß nur, dass dies nicht auftritt wenn ich "if caller != 'KNX'" drin hab.

Zitat von mknx Beitrag anzeigen

Wenn Du eine Status-GA verwendest (in dem Fall knx_send), dann schon.
In diesem Fall ist das so vollkommen korrekt.

Ich fasse zusammen:
- Taster setzt Wert für Kanal A auf X
- Aktor meldet, Status für Kanal A ist gleich X
- sh.py empfängt, Status für Kanal A ist gleich X
- sh.py setzt entsprechendes Item auf X
- sh.py setzt Wert für Kanal A auf X (sendet diesen also nochmals auf den KNX Bus)

sh.py sendet also den Wert, obwohl dieser im Aktor bereits korrekt gesetzt und rückgemeldet wurde.

Was müsste ich tun um das zu verhindern? Für Setzen und Status jeweils ein extra Item? Das wäre sinnfrei, denn dann könnte sh.py den Status für das Item "Setzen" beim Start nur abfragen, wenn es sich im eibd Cache befindet, da Write KOs nicht immer auslesbar sind.

**umatz** · 19.06.2013, 17:52

Bug: Umwandlung von/nach DPT 5.001 nicht konsistent!

Ich habe seit einiger Zeit ein ähnliches Verhalten beim Dimmen meiner über ein KNX-DALI-GW angebundenen Downlights:
Licht ist aus
Ich dimme per Taster auf z.B. 40%
Kurz danach (wenige Sekunden) wird das Licht 'von Geisterhand' auf 100% gesetzt

Bin gerade unterwegs, kann heute Abend Logs und Config nachliefern.

Greetinx,
Udo

Ankündigung

Bug: Umwandlung von/nach DPT 5.001 nicht konsistent!

Bug: Umwandlung von/nach DPT 5.001 nicht konsistent!

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar