HS/FS falschen Auslöselogik in HS

[Grinei]

Guten Tag!
Ich habe ein Problem der falschen Auslöselogik in HS.
Es gibt einen Bewegungssensor, einen Ausschaltknopf, einen Dimmer und einen Visu HS-Knopf mit einer dazugehörigen Logik in einer Gruppenadresse. Das Problem ist, dass die Logik zu arbeiten beginnt, wenn der Bewegungssensor eingeschaltet ist. Dies geschieht, weil Visu HS den Status von der Adresse liest, dann den Wert auf "Ein" ändert und die Logik ausführt. Bitte helfen Sie mir, dieses Problem zu lösen.
Ich muss den Status in Visu HS und die Logik sehen, wenn ich den Knopf an meinem Finger drücke und nicht den Status.

Vielen Dank.
Ich entschuldige mich für die deutsche Sprache, die ich durch einen Übersetzer schreibe.


Mein Problem ist fast identisch

Hallo Zusammen, ich stehe derzeit vor einem Problem bei dem ihr mir ggf. weiterhelfen könnt. Folgende Konstellation. Gruppenadressen: 0/0/1 Schalten 1 (Schaltobjekt Aktor Kanal 1) 0/0/2 Schalten 2 (Schaltobjekt Aktor Kanal 1) 0/0/3 Rückmeldung (Rückmeldeobjekt Aktor Kanal 1) Im HS: Rückmelde Gruppenadresse als Zentraladresse auf Schalten 1 Tasten: Visu -> Quad Template "Schalten ohne Status" auf Schalten 1 Was möchte ich: Prinzipiell möchte ich im Homeserver nur unterscheiden ob auf Gruppenadresse 0/0/1 oder 0/0/2 geschrieben wurde. Mein Problem ist jedoch, dass die Zentraladresse der Gruppenadresse 0/0/1 bewirkt, dass beim schreiben auf 0/0/2, im Homeserver so reagiert wird als ob die Taste gedrückt worden wäre. Sprich die "hörende" Zentraladresse ist ansich nicht nur hörend, sondern löst auch im Homeserver eine Aktion aus als ob die Taste (0/0/1) gedrückt worden wäre. (Sieht man im letzten bild. Beim Schalten auf 0/0/2 wird durch die Zentraladresse auch 0/0/6 geschrieben). Sprich eine Unterscheidung ist nicht mehr möglich Wie könnte ich mein Problem anders lösen. Habt ihr Ideen? Gruß Markus

https://knx-user-forum.de/forum/%C3%...ng-tastendruck

[KNXLeipzig]

poste doch mal die Logik als Screenshots

[Grinei]

poste doch mal die Logik als Screenshots

Danke für die Antwort, ich füge Screenshots bei

[Grinei]

Helfen Sie bitte, das Problem zu lösen.

Vielen Dank !

[bramlangen]

More information is needed.
GA 3/0/0 triggers a command action in the HS. Presumably it turns ON GA 3/4/1, the block of the movement detector.
But you have it set up in the HS that 9/0/12 triggers (internal to the HS only) 3/0/0, and therefore also triggers the command action.
If 9/0/12 is the status feedback you refer to, then remove that link. Figure out why that link is there - presumably the HS does not always know the correct status of 3/0/0. If so, why not? Fix that, and you are on your way to have this issue resolved.

Bram

[Grinei]

More information is needed.
GA 3/0/0 triggers a command action in the HS. Presumably it turns ON GA 3/4/1, the block of the movement detector.
But you have it set up in the HS that 9/0/12 triggers (internal to the HS only) 3/0/0, and therefore also triggers the command action.
If 9/0/12 is the status feedback you refer to, then remove that link. Figure out why that link is there - presumably the HS does not always know the correct status of 3/0/0. If so, why not? Fix that, and you are on your way to have this issue resolved.

Bram

Vielen Dank für die Antwort.

Die Gruppenadresse 9 \ 0 \ 12 ist die zentrale Adresse für den gira wall-Schalter (ein langer Tastendruck zum Dimmen). Wenn Sie es entfernen, funktioniert der Schalter nicht mehr ordnungsgemäß.

Wenn ich entfernen Schaltfläche in der Visualisierung , speichere ich 3 \ 0 \ 0, um die Logik zu starten, dann wird alles wie gewünscht funktionieren, aber ich brauche eine Schaltfläche in der Visualisierung, und damit bekomme ich ein falsches Ergebnis der Logik.

[bramlangen]

I still don't understand what you are exactly trying to do. If 3/0/0 triggers an action that is normally OK, but NOT OK when it comes from the Visu, then you should try and give the Visu button a separate GA, and tie that GA as a 'listening address' to the devices that need to act on it - making sure there is no loop back to the 3/0/0 or the 9/0/12 GA.

[Grinei]

I still don't understand what you are exactly trying to do. If 3/0/0 triggers an action that is normally OK, but NOT OK when it comes from the Visu, then you should try and give the Visu button a separate GA, and tie that GA as a 'listening address' to the devices that need to act on it - making sure there is no loop back to the 3/0/0 or the 9/0/12 GA.

Meinen Sie, legen Sie eine GA auf dem HS an ( Internal HS) ?

[bramlangen]

No.
Maybe first explain in detail what you try to do. When you push the Visu button, 3/0/0 toggles. When it switches ON, then the movement detector is blocked. Presumably that is what you want.
But you write that the movement detector, when it is in normal operation, also blocks itself. How?
The HS toggles 3/0/0, which turns the light on or off. Which GA does the movement detector send?

[Grinei]

No.
Maybe first explain in detail what you try to do. When you push the Visu button, 3/0/0 toggles. When it switches ON, then the movement detector is blocked. Presumably that is what you want.
But you write that the movement detector, when it is in normal operation, also blocks itself. How?
The HS toggles 3/0/0, which turns the light on or off. Which GA does the movement detector send?

ja das ist genau das was ich will. Wenn Sie die Taste in der Visualisierung drücken, wird der Bewegungssensor gesperrt

3 \ 0 \ 0 hat im Inneren: einen Stellantrieb (Dimmer), einen Wandschalter und einen Visualisierungstaster. (siehe Foto)
filedata/fetch?id=1309238&d=1545936510&type=thumb
Bewegungssensor ist eine GA 3/4/0

Blockierung tritt auf, weil für 3/0/0 eine zentrale Adresse für Status 9/0/12 vorhanden ist
filedata/fetch?id=1309239&d=1545936135&type=thumb
filedata/fetch?id=1309240&d=1546728123&type=thumb


Wird die zentrale Adresse gelöscht, ist der Status in der Visualisierung nicht sichtbar (siehe Foto)

filedata/fetch?id=1309241&d=1546728377&type=thumb

[bramlangen]

I think the problem is that you do not use that HS button as a real ON/OFF switch for the light, but as an override switch. If the wall switch and the HS switch not only switch on the light, but also block the sensor, that really is two actions in one. If I would try to implement something like this, I would use two separate buttons: one for turning the light ON manually, using the switch - in essence it serves as a 'slave' for the movement detector. A second button on the Visu would then lock or release the movement detector.

Give it some thought.

[Grinei]

I think the problem is that you do not use that HS button as a real ON/OFF switch for the light, but as an override switch. If the wall switch and the HS switch not only switch on the light, but also block the sensor, that really is two actions in one. If I would try to implement something like this, I would use two separate buttons: one for turning the light ON manually, using the switch - in essence it serves as a 'slave' for the movement detector. A second button on the Visu would then lock or release the movement detector.

Give it some thought.

Vielen Dank für die Hilfe

Leider passt das nicht zu mir.

Die Idee ist, dass der Bewegungssensor gesperrt ist, wenn ein Benutzer einen Schalter oder eine Schaltfläche in einer Visualisierung berührt.

Das ganze Problem in der Schaltfläche in der HS Visu. und zentrale Adresse für sie

Die Schaltfläche ist an die Adresse der Logik angehängt, die durch Drücken eines Fingers ausgelöst werden soll, und nicht aus dem Status der zentralen Adresse. Wenn die zentrale Adresse jedoch gelöscht wird, ist der Status der Schaltfläche nicht sichtbar

[bramlangen]

Well, you created a loop. No matter which action turns on the light, you always let the feedback signal trigger 3/0/0 - which then triggers the line of logic.
If you absolutely want to stick with what you have now, then modify your logic to fool the system you have created. See the attachment for what it would look like. Here are the steps:

1. REMOVE the central address 9/0/12 from GA 3/0/0 in the HS EIB objects listing
2. Replace the update functionality of 3/0/0 with a new line of logic (second line of logic in the attachment).
   (I included these two steps as otherwise I think that 3/0/0 will already be updated before the line of logic with the 'Sperre' had a chance to execute.)
3. Expand your original logic with a 'Sperre' (first line of logic in the attachment).
   The net effect is that when you push one of the buttons, 3/0/0 will immediately execute blocking of the sensor. But when the sensor turns on the light, then the feedback signal will close the block for 1 second. During that block 3/0/0 will be updated by 9/0/12 - but the 3/0/0 signal will not pass the block.

I find it a very odd way to do what you want to do - but test and see if it works for you.

By the way, no need to every time include an entire post as a quote.

Good luck!
Bram

[Grinei]

I find it a very odd way to do what you want to do - but test and see if it works for you.

For example, you are in the bedroom in which there is a presence sensor, you want to turn off the light with a button on the wall or in the app, but it will turn on again as the sensor is unlocked. It seems to me uncomfortable to make a separate button to block the sensor. It should be as simple as possible. For example if a person touch a button or change brightness it means he doesn’t need the presence sensor any more, and the sensor will be blocked from manual human actions.

Thank You so much for help !

I will be truing your method.

Be the way with Gira X1 l've never had such the same problem.

[bramlangen]

OK, makes sense. I too use something to lock out the sensor when automatic action is not needed. But I noticed that you lock the sensor regardless whether the light is switched ON or OFF using one of your buttons. So you must have some provision to unlock that sensor again, so there must be more than just that one button.