Bug: Umwandlung von/nach DPT 5.001 nicht konsistent!

[umatz]

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

So, hier die Details:
SmartHome.py Version: 0.9-Beta-17-g5a480bb
Item Definition:

[eg]
    [[wohnzimmer]]
        name = Wohnzimmer
        sv_page = room
        sv_img = scene_livingroom.png
        [[[deckenspots]]]
            name=Deckenspots
            type=bool
            visu=yes
            sv_widget = "{{ device.dimmer('item', 'item.name', 'item', 'item.dimmwert', '0', '100') }}"
            knx_dpt=1
            knx_send=1/0/2
            knx_init=1/0/22
            [[[[dimmwert]]]]
                type=num
                visu=yes
                knx_dpt=5001
                knx_send=1/0/39
                knx_init=1/0/29

Und kommentierter Logauszug des problematischen Verhaltens:

2013-06-19 21:48:52,533 SmartHome.py INFO     knx: 1.1.9 set 1/0/9 to 9 -- __init__.py:parse_telegram:180
# Beginn Dimmen am Taster
2013-06-19 21:48:53,688 SmartHome.py INFO     knx: 1.1.9 set 1/0/9 to 0 -- __init__.py:parse_telegram:180
# Loslassen Tasterwippe
2013-06-19 21:48:56,105 SmartHome.py INFO     knx: 1.1.5 set 1/0/29 to 25 -- __init__.py:parse_telegram:185
# DALI-GW (1.1.5) meldet auf Dimmwert-Status-GA 25 zurück
2013-06-19 21:48:56,105 SmartHome.py DEBUG    eg.wohnzimmer.deckenspots.dimmwert = 25 via KNX 1.1.5 -- item.py:_update:219
# SH aktualisiert item mit Statuswert
2013-06-19 21:48:56,106 SmartHome.py INFO     knx: 15.15.2 set 1/0/39 to 3f -- __init__.py:parse_telegram:180
# eibd (15.15.2) sendet 3f (und nicht 25!) auf die Dimmwert-Setz-GA (1/0/39)  (vermutlich getriggert durch SH?)
2013-06-19 21:48:56,147 SmartHome.py INFO     knx: 1.1.5 set 1/0/22 to True -- __init__.py:parse_telegram:185
# DALI-GW setzt den Schalt-Status (1/0/22) auf True und ursprünglich nur sanft gedimmtes Licht geht volle Kanne an
2013-06-19 21:48:56,147 SmartHome.py DEBUG    eg.wohnzimmer.deckenspots = True via KNX 1.1.5 -- item.py:_update:219
# SH aktualisiert item mit Statuswert True 
2013-06-19 21:48:56,148 SmartHome.py INFO     knx: 15.15.2 set 1/0/2 to 1 -- __init__.py:parse_telegram:180
# eibd sendet True auf Schalt-GA (vermutlich getriggert durch SH?)

2013-06-19 21:48:59,619 SmartHome.py INFO     knx: 1.1.9 set 1/0/9 to 1 -- __init__.py:parse_telegram:180
# Ab hier beginnt mein Korrekturdimmen am Taster um Helligkeit wieder zu reduzieren
2013-06-19 21:49:03,898 SmartHome.py INFO     knx: 1.1.9 set 1/0/9 to 0 -- __init__.py:parse_telegram:180
2013-06-19 21:49:11,232 SmartHome.py INFO     knx: 1.1.5 set 1/0/29 to 29 -- __init__.py:parse_telegram:185
2013-06-19 21:49:11,233 SmartHome.py DEBUG    eg.wohnzimmer.deckenspots.dimmwert = 29 via KNX 1.1.5 -- item.py:_update:219
2013-06-19 21:49:11,234 SmartHome.py INFO     knx: 15.15.2 set 1/0/39 to 49 -- __init__.py:parse_telegram:180
# Auch hier wird wieder ein anderer Wert als ursprünglich reinkam auf den Bus gesendet (49 statt 29)!

Dieses Verhalten habe ich seit einigen Wochen, vorher lief das Dimmen problemlos.

Ich denke man muss leider das senden über zwei unterschiedliche Attribute regeln.

knx_??? = A # sendet an A wenn sich der Wert nicht über KNX ändert (SchaltGA)
knx_??? = B # sendet an B wenn sich der Wert ändert (StatusGA)

Das habe ich noch nicht verstanden. Mir erscheint meine Item-Definition wie oben angegeben logisch und sauber.
Wäre mein Problem behoben, wenn ich nur die in diesem Thread enthaltenen Patches (also die Korrektur der Umwandlung von DPT5.001) anwende ohne meine Konfig zu ändern?

Greetinx,
Udo

[callidomus]

Ja, wollte ich auch noch vorschlagen. Zudem: Kann de5001 nicht ein float zurückgeben und bei en5001 der cast auf int entfallen? Intern gibt es doch eh float-Verarbeitung! Dadurch werden die Fehler noch geringer.

Ich würde es dann gerne einchecken - muss nur noch schauen wie ich das mit dem GIT hinbekomme.

Ein KNX DPT 5.001 liefert kein Float, daher denke ich sollte das de5001 auch kein Float liefern.
Das cast auf int bei dem en5001 könnte prinzipiell weg, ich habe es für den Fall eingebaut das ein Benutzer ein Bool oder String als type angiebt, selbst damit würde es funktionieren. Es stört meiner Meinung nach nicht und darf daher bleiben.

Auf
https://github.com/mknx/smarthome/bl.../dev/README.md
habe ich noch einen Punkt "Push changes" eingefügt.

Bis bald

Marcus

[callidomus]

Hi Niko,

ich habe Dein Setup noch mal durchdacht.
Ich denke man muss leider das senden über zwei unterschiedliche Attribute regeln.

knx_??? = A # sendet an A wenn sich der Wert nicht über KNX ändert (SchaltGA)
knx_??? = B # sendet an B wenn sich der Wert ändert (StatusGA)

Verständlich was ich meine?

Bis bald

Marcus

[2ndsky]

Klar, wenn ich den Status 100% empfange und sende dann wieder 100% ist das zunächst kein Problem. Dennoch finde ich es unschön, wenn der Status über KNX empfangen und dann wieder auf den KNX gesendet wird. Außerdem erzeugt das zusätzliche Buslast, die nicht sein muss. Das mag im normalen EFH noch egal sein, bei größeren Objekten könnte das aber schnell zum Problem werden.

Wenn du von einem logischen Fehler bei der Item Konfiguration sprichst, wie sollte diese dann aussehen bei Wert-GA X und Status-GA Y?

EDIT: in deinem Fall war es ja das Problem, dass die Dauerbeleuchtung mit dem Status der Lampe verknüpft war. Ich will aber den Status der Lampe mit dem Schalten der Lampe (nicht der Dauerbeleuchtung) haben.

[Robert]

Scherzkecks

Selber ;-P Ne, schon verstanden - ich meinte halt "nur verschieben" oder "nur Haken dran", aber halt nicht aus zwei Threads einen (evtl. missverständlichen) machen. Insbesondere da der zweite bewusst "kurz" und problemorientiert war. Aber so passt es jetzt auch, zumal wir hier ja vielleicht bald nen Haken dran machen können.

Hallo Robert,

danke, sieht gut aus.

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?

Ja, wollte ich auch noch vorschlagen. Zudem: Kann de5001 nicht ein float zurückgeben und bei en5001 der cast auf int entfallen? Intern gibt es doch eh float-Verarbeitung! Dadurch werden die Fehler noch geringer.

Ich würde es dann gerne einchecken - muss nur noch schauen wie ich das mit dem GIT hinbekomme.

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

Ohne Prophet zu sein: schätze das ist das gleiche Problem wie bei mir. Du hast wahrscheinlich ein Item mit send_item für den Helligkeitswert, was auch auf die Rückmeldung hört (watch_item). sh.py will jetzt wenn die Rückmeldung (watch_item) kommt das für sh.py scheinbar nicht aktualisierte send_item aktualisieren und schreibt dort den Wert hin. Aufgrund der Rechenungenaugikeit ist das aber ein anderer Wert als der zurückgemeldete. Hier beginnt dann ein Spiel aus Update/Rückmeldung.

Kurz, auch wahrscheinlich für Niko:

[Item]
send_item = x
watch_item = y

Wenn y empfangen wird wird zwangsweise x geupdated und - falls bisher noch nicht auf den Bus gesendet oder sowieso wenn force_updates = true - auch wieder gesendet. Das ist richtig so, sonst hätte das Item keinen konsistenten Wert.

Die Abfrage auf "knx" ist also korrekterweise entfernt worden und überdeckte nur einen "logischen Fehler" in der Item-Definition (siehe die kurze Beschreibung meines Leuchten-Problems hier im Thread)

Das Hochschaukeln ist zwar ähnlich gelagert aber keine direkte Folge dessen. Hier ist es völlig ok, Rückmeldung und Setz-GA gemeinsam zu haben, sofern bei geänderter Status-GA (z.B. durch hoch-runter bei der Jalousie) auch gefahrlos die Absolutposition neu geschrieben werden darf (ist dann ohne Rundungsfehler harmlos).

Grüße
Robert

[umatz]

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

[2ndsky]

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.

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.

[callidomus]

Hi Niko,

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

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!

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]

Hallo Marcus,

DPT5 != DPT5001

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

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

caller != 'KNX'

[callidomus]

Hi Niko,

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

[callidomus]

Hallo Robert,

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

danke, sieht gut aus.

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]

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

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

[2ndsky]

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):

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:

[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.

[Robert]

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

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

[Robert]

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