Ankündigung

Einklappen
Keine Ankündigung bisher.

Bug: Umwandlung von/nach DPT 5.001 nicht konsistent!

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

    Bug: Umwandlung von/nach DPT 5.001 nicht konsistent!

    Ausgangssituation:
    - smartVISU 2.5
    - smarthome.py 0.9 als Backend
    - mehrere Android-Clients mit Firefox (bereits alle Browser beendet zur Sicherheit)
    - ABB JA/S 8.230.1M als Raffstore-Aktor
    - Raffstore werden sowohl über Taster und Visu als auch Wetterstation (getrennte GAs) gesteuert

    Problem:
    Ich habe einen Teil meiner Raffstore bereits in die Visu integriert (mit 'device.shutter'). Wenn ich die Raffstore manuell über die Visu hoch- oder runterfahre und dann stoppe, oder sie per "Fensterklick" absolut positionieren will, fahren sie die Position an, um dann stückweise (in Bereich von wenigen %) immer weiter zu fahren.

    Ausschnitt aus dem ETS Gruppenmonitor:
    - per Klick in Visu auf 60% - Resultat 60% - ok
    - per Klick in Visu auf 40% - Resultat 40% - ok
    - per Klick in Visu ab, dann Stopp - Resultat 45,5% - ok
    - nun fängt die Visu? an, den Raffstore schrittweise! wieder auf 40% zu fahren (ob das jetzt immer die letzte per Absolutwert angefahrene Position ist weiß ich nicht) - gut zu erkennen sind die 5 Sekunden Abstände zwischen Status-Visuvorgabe-Status-Visuvorgabe...

    Code:
    #,Zeit,Dienst,Flags ,Prio,Quelladresse,Quelle,Zieladresse,Ziel,Rout,Typ,DPT,Info
    3,2013-06-19 08:55:45.433,vom Bus,,Low,1.1.0,omnigate / eibd,4/2/203,-,6,Write,1 Byte,$99 | 60 %
    9,2013-06-19 08:56:01.162,vom Bus,,Low,1.1.113,"Jalousieaktor, JA/S8.230.1M",4/2/223,Raffstore Elternbad Status Position,5,Write,  5.001 Prozent (0..100%),$99 | 60 %
    10,2013-06-19 08:56:11.326,vom Bus,,Low,1.1.0,omnigate / eibd,4/2/203,-,6,Write,1 Byte,$66 | 40 %
    15,2013-06-19 08:56:29.272,vom Bus,,Low,1.1.113,"Jalousieaktor, JA/S8.230.1M",4/2/223,Raffstore Elternbad Status Position,5,Write,  5.001 Prozent (0..100%),$66 | 40 %
    16,2013-06-19 08:56:52.108,vom Bus,,Low,1.1.0,omnigate / eibd,4/2/201,Raffstore Elternbad Auf-Ab,6,Write,  1.008 Auf/Ab,$01 | Ab
    17,2013-06-19 08:56:55.673,vom Bus,,Low,1.1.0,omnigate / eibd,4/2/202,Raffstore Elternbad Lamellenverst. / Stopp,6,Write,  1.007 Schritt,$01 | Erhöhen
    19,2013-06-19 08:56:57.703,vom Bus,,Low,1.1.113,"Jalousieaktor, JA/S8.230.1M",4/2/223,Raffstore Elternbad Status Position,5,Write,  5.001 Prozent (0..100%),"$74 | 45,5 %"
    20,2013-06-19 08:56:57.753,vom Bus,,Low,1.1.0,omnigate / eibd,4/2/203,-,6,Write,1 Byte,"$72 | 44,7 %"
    25,2013-06-19 08:57:02.335,vom Bus,,Low,1.1.113,"Jalousieaktor, JA/S8.230.1M",4/2/223,Raffstore Elternbad Status Position,5,Write,  5.001 Prozent (0..100%),"$72 | 44,7 %"
    26,2013-06-19 08:57:02.384,vom Bus,,Low,1.1.0,omnigate / eibd,4/2/203,-,6,Write,1 Byte,"$70 | 43,9 %"
    27,2013-06-19 08:57:07.313,vom Bus,,Low,1.1.113,"Jalousieaktor, JA/S8.230.1M",4/2/223,Raffstore Elternbad Status Position,5,Write,  5.001 Prozent (0..100%),"$70 | 43,9 %"
    28,2013-06-19 08:57:07.350,vom Bus,,Low,1.1.0,omnigate / eibd,4/2/203,-,6,Write,1 Byte,"$6D | 42,7 %"
    29,2013-06-19 08:57:12.345,vom Bus,,Low,1.1.113,"Jalousieaktor, JA/S8.230.1M",4/2/223,Raffstore Elternbad Status Position,5,Write,  5.001 Prozent (0..100%),"$6D | 42,7 %"
    30,2013-06-19 08:57:12.394,vom Bus,,Low,1.1.0,omnigate / eibd,4/2/203,-,6,Write,1 Byte,$6B | 42 %
    31,2013-06-19 08:57:17.238,vom Bus,,Low,1.1.113,"Jalousieaktor, JA/S8.230.1M",4/2/223,Raffstore Elternbad Status Position,5,Write,  5.001 Prozent (0..100%),$6B | 42 %
    32,2013-06-19 08:57:17.281,vom Bus,,Low,1.1.0,omnigate / eibd,4/2/203,-,6,Write,1 Byte,"$68 | 40,8 %"
    33,2013-06-19 08:57:22.402,vom Bus,,Low,1.1.113,"Jalousieaktor, JA/S8.230.1M",4/2/223,Raffstore Elternbad Status Position,5,Write,  5.001 Prozent (0..100%),"$68 | 40,8 %"
    34,2013-06-19 08:57:22.515,vom Bus,,Low,1.1.0,omnigate / eibd,4/2/203,-,6,Write,1 Byte,$66 | 40 %
    gleicher! Zeitpunkt im smarthome.py Log
    Code:
    2013-06-19 08:57:14,544 SmartHome.py DEBUG    192.168.178.202:52685 sent '{"cmd":"item","id":"Elternbad.Raffstore.Position","val":60}' -- __init__.py:json_parse:257
    2013-06-19 08:57:14,545 SmartHome.py INFO     Elternbad.Raffstore.Position = 60 via Visu 192.168.178.202:52685 -- item.py:_update:219
    2013-06-19 08:57:14,589 SmartHome.py DEBUG    knx: 1.1.0 set 4/2/203 to 99 -- __init__.py:parse_telegram:180
    2013-06-19 08:57:17,211 Scheduler    DEBUG    series next time: 2013-06-19 08:57:27+02:00 -- scheduler.py:_next_time:238
    2013-06-19 08:57:27,238 Scheduler    DEBUG    series next time: 2013-06-19 08:57:37+02:00 -- scheduler.py:_next_time:238
    2013-06-19 08:57:30,318 SmartHome.py DEBUG    knx: 1.1.113 set 4/2/223 to 60 -- __init__.py:parse_telegram:185
    
    
    2013-06-19 08:57:37,267 Scheduler    DEBUG    series next time: 2013-06-19 08:57:47+02:00 -- scheduler.py:_next_time:238
    2013-06-19 08:57:40,440 SmartHome.py DEBUG    192.168.178.202:52685 sent '{"cmd":"item","id":"Elternbad.Raffstore.Position","val":40}' -- __init__.py:json_parse:257
    2013-06-19 08:57:40,440 SmartHome.py INFO     Elternbad.Raffstore.Position = 40 via Visu 192.168.178.202:52685 -- item.py:_update:219
    2013-06-19 08:57:40,489 SmartHome.py DEBUG    knx: 1.1.0 set 4/2/203 to 66 -- __init__.py:parse_telegram:180
    2013-06-19 08:57:47,294 Scheduler    DEBUG    series next time: 2013-06-19 08:57:57+02:00 -- scheduler.py:_next_time:238
    2013-06-19 08:57:57,321 Scheduler    DEBUG    series next time: 2013-06-19 08:58:07+02:00 -- scheduler.py:_next_time:238
    2013-06-19 08:57:58,436 SmartHome.py DEBUG    knx: 1.1.113 set 4/2/223 to 40 -- __init__.py:parse_telegram:185
    
    
    2013-06-19 08:58:07,347 Scheduler    DEBUG    series next time: 2013-06-19 08:58:17+02:00 -- scheduler.py:_next_time:238
    2013-06-19 08:58:17,374 Scheduler    DEBUG    series next time: 2013-06-19 08:58:27+02:00 -- scheduler.py:_next_time:238
    2013-06-19 08:58:21,208 SmartHome.py DEBUG    192.168.178.202:52685 sent '{"cmd":"item","id":"Elternbad.Raffstore.AufAb","val":"1"}' -- __init__.py:json_parse:257
    2013-06-19 08:58:21,209 SmartHome.py INFO     Elternbad.Raffstore.AufAb = True via Visu 192.168.178.202:52685 -- item.py:_update:219
    2013-06-19 08:58:21,267 SmartHome.py DEBUG    knx: 1.1.0 set 4/2/201 to 1 -- __init__.py:parse_telegram:180
    2013-06-19 08:58:24,792 SmartHome.py DEBUG    192.168.178.202:52685 sent '{"cmd":"item","id":"Elternbad.Raffstore.Stopp","val":"1"}' -- __init__.py:json_parse:257
    2013-06-19 08:58:24,793 SmartHome.py INFO     Elternbad.Raffstore.Stopp = True via Visu 192.168.178.202:52685 -- item.py:_update:219
    2013-06-19 08:58:24,839 SmartHome.py DEBUG    knx: 1.1.0 set 4/2/202 to 1 -- __init__.py:parse_telegram:180
    
    2013-06-19 08:58:26,869 SmartHome.py DEBUG    knx: 1.1.113 set 4/2/223 to 45 -- __init__.py:parse_telegram:185
    2013-06-19 08:58:26,869 SmartHome.py INFO     Elternbad.Raffstore.Position = 45 via KNX 1.1.113 -- item.py:_update:219
    2013-06-19 08:58:26,919 SmartHome.py DEBUG    knx: 1.1.0 set 4/2/203 to 72 -- __init__.py:parse_telegram:180
    2013-06-19 08:58:27,401 Scheduler    DEBUG    series next time: 2013-06-19 08:58:37+02:00 -- scheduler.py:_next_time:238
    2013-06-19 08:58:31,500 SmartHome.py DEBUG    knx: 1.1.113 set 4/2/223 to 44 -- __init__.py:parse_telegram:185
    2013-06-19 08:58:31,501 SmartHome.py INFO     Elternbad.Raffstore.Position = 44 via KNX 1.1.113 -- item.py:_update:219
    2013-06-19 08:58:31,549 SmartHome.py DEBUG    knx: 1.1.0 set 4/2/203 to 70 -- __init__.py:parse_telegram:180
    2013-06-19 08:58:36,367 SmartHome.py DEBUG    knx: 1.1.113 set 4/2/223 to 43 -- __init__.py:parse_telegram:185
    2013-06-19 08:58:36,367 SmartHome.py INFO     Elternbad.Raffstore.Position = 43 via KNX 1.1.113 -- item.py:_update:219
    2013-06-19 08:58:36,414 SmartHome.py DEBUG    knx: 1.1.0 set 4/2/203 to 6d -- __init__.py:parse_telegram:180
    2013-06-19 08:58:37,230 Scheduler    DEBUG    series next time: 2013-06-19 08:58:47+02:00 -- scheduler.py:_next_time:238
    2013-06-19 08:58:41,511 SmartHome.py DEBUG    knx: 1.1.113 set 4/2/223 to 42 -- __init__.py:parse_telegram:185
    2013-06-19 08:58:41,511 SmartHome.py INFO     Elternbad.Raffstore.Position = 42 via KNX 1.1.113 -- item.py:_update:219
    2013-06-19 08:58:41,558 SmartHome.py DEBUG    knx: 1.1.0 set 4/2/203 to 6b -- __init__.py:parse_telegram:180
    2013-06-19 08:58:46,394 SmartHome.py DEBUG    knx: 1.1.113 set 4/2/223 to 41 -- __init__.py:parse_telegram:185
    2013-06-19 08:58:46,395 SmartHome.py INFO     Elternbad.Raffstore.Position = 41 via KNX 1.1.113 -- item.py:_update:219
    2013-06-19 08:58:46,439 SmartHome.py DEBUG    knx: 1.1.0 set 4/2/203 to 68 -- __init__.py:parse_telegram:180
    2013-06-19 08:58:47,258 Scheduler    DEBUG    series next time: 2013-06-19 08:58:57+02:00 -- scheduler.py:_next_time:238
    2013-06-19 08:58:51,569 SmartHome.py DEBUG    knx: 1.1.113 set 4/2/223 to 40 -- __init__.py:parse_telegram:185
    2013-06-19 08:58:51,570 SmartHome.py INFO     Elternbad.Raffstore.Position = 40 via KNX 1.1.113 -- item.py:_update:219
    2013-06-19 08:58:51,625 SmartHome.py DEBUG    knx: 1.1.0 set 4/2/203 to 66 -- __init__.py:parse_telegram:180
    2013-06-19 08:58:55,211 SmartHome.py DEBUG    knx: 1.1.230 set 6/3/150 to 0 5d -- __init__.py:parse_telegram:180
    2013-06-19 08:58:56,451 SmartHome.py DEBUG    knx: 1.1.113 set 4/2/223 to 40 -- __init__.py:parse_telegram:185
    Item.conf
    Code:
    [Elternbad]
      [[Raffstore]]
        [[[AufAb]]]
          type = bool
          visu = yes
          enforce_updates = true
          knx_dpt = 1
          knx_send = 4/2/201
        [[[Stopp]]]
          type = bool
          visu = yes
          enforce_updates = true
          knx_dpt = 1
          knx_send = 4/2/202
        [[[Position]]]
          type = num
          visu = yes
          knx_dpt = 5001
          knx_send = 4/2/203
          knx_cache = 4/2/223
        [[[Lamelle]]]
          type = num
          visu = yes
          knx_dpt = 5001
          knx_send = 4/2/204
          knx_cache = 4/2/224
        [[[Referenzfahrt]]]
          type = bool
          visu = yes
          enforce_updates = true
          knx_dpt = 1
          knx_send = 4/2/210
        [[[Automatik]]]
          type = bool
          visu = yes
          knx_dpt = 1
          knx_send = 4/2/212
          knx_cache = 4/2/228
    Visu-Code
    Code:
          {{ device.shutter('Elternbad_Seite.Elternbad.Raffstore', '', 'Elternbad.Raffstore.AufAb', 'Elternbad.Raffstore.Stopp', 'Elternbad.Raffstore.Position', '', 'Elternbad.Raffstore.Lamelle', '', 0, 100, 10, 'full') }}
          <br />
     			<label for="Elternbad_Seite.Elternbad.Raffstore.Automatik">Automatik&nbsp;</label>        
    			{{ basic.dual('Elternbad_Seite.Elternbad.Raffstore.Automatik', 'Elternbad.Raffstore.Automatik', icon1~'fts_shutter_auto.png', icon0~'fts_shutter_auto.png', '', '') }}
    Zuerst dachte ich, evtl. würde die Umrechnung um +-1 Bit zwischen Visu und Aktor oder so differieren und so diese Schritte entstehen. Allerdings scheint evtl. auch die alte Absolutwert-Vorgabe eine Rolle zu spielen.

    Weitere Logiken hinsichtlich der Raffstore gibt es nicht. Ein Raffstore der in der Visu noch nicht benutzt - wohl aber in sh.py definiert - wird, verhält sich normal.

    Ich kann leider nicht einschätzen, wie die Visu-Scripte auf die Rückmeldung des Aktors wohl reagieren.

    Grüße
    Robert

    #2
    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.
    Mit freundlichen Grüßen
    Niko Will

    Logiken und Schnittstelle zu anderen Systemen: smarthome.py - Visualisierung: smartVISU
    - Gira TS3 - iPhone & iPad - Mobotix T24 - ekey - Denon 2313 - Russound C5 (RIO over TCP Plugin) -

    Kommentar


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

      Kommentar


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

        Kommentar


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

          Kommentar


            #6
            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!)

            Kommentar


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

              Kommentar


                #8
                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
                Mit freundlichen Grüßen
                Niko Will

                Logiken und Schnittstelle zu anderen Systemen: smarthome.py - Visualisierung: smartVISU
                - Gira TS3 - iPhone & iPad - Mobotix T24 - ekey - Denon 2313 - Russound C5 (RIO over TCP Plugin) -

                Kommentar


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

                  Kommentar


                    #10
                    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.0 / 100) & 0xff]
                    sollte auch noch geändert werden.

                    Möchtest Du es einchecken?

                    Bis bald

                    Marcus

                    Kommentar


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

                      Kommentar


                        #12
                        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'
                        Mit freundlichen Grüßen
                        Niko Will

                        Logiken und Schnittstelle zu anderen Systemen: smarthome.py - Visualisierung: smartVISU
                        - Gira TS3 - iPhone & iPad - Mobotix T24 - ekey - Denon 2313 - Russound C5 (RIO over TCP Plugin) -

                        Kommentar


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

                          Kommentar


                            #14
                            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.
                            Mit freundlichen Grüßen
                            Niko Will

                            Logiken und Schnittstelle zu anderen Systemen: smarthome.py - Visualisierung: smartVISU
                            - Gira TS3 - iPhone & iPad - Mobotix T24 - ekey - Denon 2313 - Russound C5 (RIO over TCP Plugin) -

                            Kommentar


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

                              Kommentar

                              Lädt...
                              X