Falsches Verhalten bei Szene (speichern)

[henfri]

Hallo,

ich habe eine Szene definiert:

        Szene:
          type: scene
          knx_cache: 10/1/0
          knx_send: 10/1/0
          knx_dpt: 17.001
          enforce_updates: true

und:

2:
    name: Ambiente
    actions:
     - {item: eg.Wohnzimmer.Hauptlicht.Dimmwert, value: 30, learn: true}
     - {item: eg.Esszimmer.Hauptlicht.Dimmwert, value: 0, learn: true}
     - {item: eg.Kueche.Hauptlicht.Dimmwert, value: 0, learn: true}
     - {item: eg.Kueche.Schrank.Dimmwert, value: 30, learn: true}
     - {item: eg.Esszimmer.Niesche.Dimmwert, value: 50, learn: true}
     - {item: eg.Wohnzimmer.Voute.sequencer, value: 1, learn: true}
     - {item: eg.Wohnzimmer.Voute.sequencer.s, value: 30, learn: true}
     - {item: eg.Wohnzimmer.Voute.sequencer.v, value: 30, learn: true}

Das ganze funktioniert, wenn ich die Szene abrufen möchte.
Wenn ich die Szene aber speichern möchte, sendet der Taster zwar korrekt, aber Sh-NG schaltet die Szene, statt sie zu speichern.
So sieht das in der richtigen zeitlichen Abfolge aus:
szene3.PNG
(unten noch die originale aus dem Busmonitor)

Was mache ich falsch?

Gruß,
Hendrik



szene1.png
szene2.PNG

[Tontechniker]

Hallo Hendrik,
kann es sein, dass die "2:", als Label verwendet, nicht richtig ist. Ich hab mal was gelesen, dass man dort keine Zahlen verwenden soll, nur Buchstaben (Text).
Gruß
Hans

[Msinn]

Tontechniker Du beziehst Dich auf Item Namen. Die dürfen nicht rein numerisch sein. Szenen-Nummern sind schon qua Definition numerisch.

henfri Ich bin mir nicht sicher ob shNG dpt 17 hier unterstützt. Ich verwende für Szenen immer noch dpt 5.

[henfri]

Danke.
Geht mit Dpt 5 dann auch das speichern?

Gruß,
Hendrik

[Msinn]

Davon gehe ich aus.

[smai]

Die Ursache liegt im Decoding von DPT 17.001 (und 17).
Auf Zeile 275 von dpts.py steht:

return (struct.unpack('>B', payload)[0] & 0x3f) + 1

Das   & 0x3f  bewirkt, dass nur die letzten 6 Bits berücksichtigt werden, also ein Modulo 64 erfolgt. Damit wird aus Speichern einer Szene das Abrufen.

Dies ist insofern korrekt, als dass 17.001 "Scene Number" tatsächlich nur zum Abrufen von Szenen da ist und in KNX mit 6 Nutz-Bits spezifiziert ist.
Ich weiss jedoch nicht, ob das einfach Abschneiden korrekt ist oder ob der Wert besser ignoriert und als Warning geloggt werden sollte.

Szene Speichern wäre der DPT 18.001 "Scene Control", welcher von SHNG aktuell nicht unterstützt wird.

17.001 gibt's übrigens erst in develop, vorher gab es nur 17 (ohne +1). In der KNX Spec hingegen gibt es keine 17, sondern nur 17.001.

[henfri]

Hallo,

danke für die Erklärung.
Ja, an 17.001 war ich beteiligt..: https://knx-user-forum.de/forum/%C3%...t-17-vs-17-001

Wäre dies eine Möglichkeit für DPT18.001?
https://github.com/smarthomeNG/plugi...enfri:patch-15
Oder habe ich etwas falsch verstanden?

Gruß,
Hendrik

[smai]

Statt 0x4f müsste es 0xbf sein (binär 10111111).

Ich bin aber weiterhin der Meinung, dass das einfache Löschen der unzulässigen Bits nicht sehr sinnvoll ist. Lieber es geschieht gar nicht (mit Logeintrag) als wie in deinem Fall etwas unerwartetes.

[henfri]

Hallo,

wie kann es denn zu den unzulässigen Bits kommen?

Wenn ich dich richtig verstehe, würdest du prüfen, ob der Wert > 128 bzw >64 ist und wenn ja eine Warnung heraus geben.
Aber welcher Wert würde zurück gegeben?
Ein "nichts machen" ist an dieser Stelle ja nicht vorgesehen...

Gruß
Hendrik

[Msinn]

Warum nimmst Du nicht einfach dpt 5 (So wie das normal war bevor es in der KNX Spezifikation dpt 17 und 18 gab)?

[smai]

wie kann es denn zu den unzulässigen Bits kommen?

Etwa indem (wie in deinem Fall) der Sender einen anderen DPT verwendet.
Wenn man das nicht erwarten würde, wäre ja das bitwise and gar nicht notwendig.

Ein "nichts machen" ist an dieser Stelle ja nicht vorgesehen...

Ich habe nicht den ganzen Stack angeschaut, prinzipiell müsste entweder eine Exception geworfen werden oder - aber nur falls nicht möglich - zur Not None zurückgegeben werden.

[mumpf]

Hallo smai,

in diesem Fall stimme ich Dir nicht zu. Wenn man bei einem Item einen DPT angibt, dann sagt man damit, wie das Item den Wert auf dem Bus zu interpretieren hat. Ein gutes Beispiel ist immer DPT 5 und DPT 5.001. Die Daten, die gesendet werden, sind identisch (8-Bit vorzeichenlos), aber in einem Fall bekomme ich den Wertebereich 0-255 (DPT 5) und im anderen 0-100 (DPT 5.001). Ich bekomme das, wofür ich mich entscheide, und das ist meiner Meinung nach gut so.

Um das auf den vorliegenden Fall zu übertragen: Wenn ich bei einem Item DPT 17.001 wähle, dann sage ich damit, dass ich über dieses Item nur Szenen abrufen will. Es ist also vollkommen OK, dass Bit 7 maskiert wird. Wenn ich auch speichern können will, muss es eben DPT 18.001 sein. Dafür sind doch DPT da, um dem Empfänger einer Nachricht zu sagen, wie er sie interpretieren soll. Eine Warnung/Fehler wäre nur angebracht, wenn z.B. ein 2-Byte Wert ankäme, denn der kann nicht als 1-Byte interpretiert werden.

Ist meine Meinung zu dem Thema,
Gruß, Waldemar

[smai]

Ich bleibe bei der Meinung, dass eine Schnittstelle bei nicht spezifizierten Werten nicht irgend etwas unerwartetes tun soll, sondern einen Fehler ausgeben und die Verarbeitung abbrechen.

Der Vergleich mit 1/2 Byte gefällt mir. Da könntest du ja auch einfach nur das zweite Byte übernehmen, wäre aber dann genauso falsch.

[henfri]

Hallo,

Ich habe einen PR erstellt. Danke für die Korrektur @smai.
Das implementieren des von dir gewünschten Verhalten ist einfach (return None ist vorgesehen), sollte aber diskutiert werden.
Willst du einen eigenen Thread dafür öffnen, oder soll ich (ersteres wäre mir lieber)?

Gruß,
Hendrik