falschen Auslöselogik in HS

[Shine120]

In my opinion the best way to do this with only one button is to use short and long push action.... short push turns light on while the movement detector is enabled and long push (separate Groupadress) blocks the MD... left side on right side off.... And in Bed Rooms the fall back time is set to your regular sleeptime

[Grinei]

OK, makes sense.

erhielt eine Antwort von Gira Hotline

Ich glaube ich habe das Problem verstanden: Das Sperren des Bewegungssensors wird durch die Rückmeldung von 9/0/12 als hörende Gruppenadresse von 3/0/0 realisiert. Dies führt dazu, dass sich der Sensor selbst sperrt.

Ihre Idee mit einer separaten Taste wird das Problem lösen.

Der Grund für die Rückmeldung von 9/0/12 als hörende Gruppenadresse von 3/0/0 liegt ja im Aufbau der Funktionsvorlage „Dimmen plus“. Wäre das Status separat als Objekt angelegt, könnten Sie auf die hörende Gruppenadresse verzichten. Im Entwicklerforum www.entwicklerforum.gira.de können eigene Funktionsvorlagen erstellt werden. Das Forum ist leider nur in deutscher Sprache. Das zeitliche Aufwand zum Entwickeln einer eigenen Funktionsvorlage ist hoch.

Weitere Lösungsansätze sehe ich aktuell nicht.

teure Geräte, die nicht für einfache Operationen geeignet sind

[bramlangen]

Just implement the logic I proposed, should give you the result you are looking for.

[Grinei]

Just implement the logic I proposed, should give you the result you are looking for.

versuchte es mit Ihrer Logik, erhielt aber zyklische Sperrtelegramme

[bramlangen]

Well, if 9/0/12 sends a '1', then the trigger initiated by 3/0/0 will be blocked for 1 second by 'my' logic. Did you remove the listening address 9/0/12 everywhere where it ties to 3/0/0? Check the group monitor to see the sequence of events.

[Grinei]

Check the group monitor to see the sequence of events.

Hello !

this is my EIB monitor now


the problem is in the second logic block, if i delete it , cyclic telegrams will stop



Thank you so much !

[bramlangen]

the problem is in the second logic block, if i delete it , cyclic telegrams will stop

So, problem solved? No idea what the second line of logic actually does. In one of your first posts you write 'Blockieren des Sensors beim Ein- und Ausschalten mit der visu HS und der Taste'. Which is odd, as you apparently always block the sensor, and never release it. So, if removing those commands resolves the issue, then great.

If that is not what you meant to say, so the problem is not yet solved: the telegrams in the group monitor show that the HS (assuming that the HS is 15.15.250) still updates 3.0.0 immediately when the feedback telegram arrives. It does so within ~0.1 second, so I presume you have not removed the listening address, which in your earlier post is shown in the picture attached here. The first line of new logic will block that update for 1 second, so you must have elsewhere in the HS an update trigger.
temp.jpg

[Grinei]

So, problem solved?

Unfortunately, the problem is not solved, because if I delete the second line of logic that was attached by you, the problem is solved with cyclic telegrams, but the status is not updated.

I deleted all central addresses for 3/0/0 and everywhere 9/0/12

[bramlangen]

Try this: in the second line, after the input box, add a two-input =AND= module. Keep one input on =1=, or set it to (yellow) =1= to make it more clear that this is a forced input. Tie the input box GA (9/0/12) to the second input. Then use output A3 (sbc) and tie that one to the input of the binary trigger. That should take care of the rapid cyclic sending.

[bramlangen]

....and as an afterthought, you can tie the sbc output of that =AND= box directly to a normal output box with just 3/0/0 in it .???? . Then you can eliminate the binary trigger and the two commands.

[Grinei]

Try this

Thank you so so much for help!!!!

yes, the rapid cyclic sending stopped.

But i have a new problem now.

If I set the value in percent for example 50%, then the dimmer is turned on at 100% percent, apparently because the group address 3/0/0 receives the value 1 from the logic.

It seems to me that my problem will be solved only by rewriting the template.

Do I still have hope?

[bramlangen]

(To make the logic simpler, you can make the change as suggested in post #25.)

Yes, there is hope...

The sequence you show:

1. You set the brightness (3/3/2) to 55%
   Presumably it was OFF, as you now get the 9/0/12 feedback telegram. --> OK
2. The HS logic now sets 3/0/0 to =1=, so that the status will be correct on the visu. --> OK
3. The actor sends another feedback telegram, which is to be expected. It does not retrigger 3/0/0, so that is good! --> OK
4. The actor then sets itself to 100% - which is probably how you configured the actor. Consider the following (from the manual):
   1. GA 3/0/0 is tied to KO #2 of the actor. This is the ON/OFF input.
   2. You probably have the ETS parameter for 'Lighting Level at On' set to 100%. That KO has more options. One is called 'Memory Function'.
      I don't know if changing that 'Memory Function' setting to 'Previous' will do the trick in all possible scenarios. That option sets it to the last know light level when it was on.

You may first want to see what that 'Previous' setting does for you. I don't have such a Zennio dimmer - the Gira dimmers I use have a similar setting, I use that 'last known dimming state' for the ON/OFF action which works fine for where I use this.
If that is not what you want to see happen, then you could consider NOT tying the ON/OFF GA directly to the actor, but instead use either a value transmitter, or let the HS 'translate' the ON signal to a 100% input, and the OFF signal to a 0% input.

[Grinei]

Yes, there is hope...

Hello !
Thank you so much for help !

Now when turned off, the lock still happens, as the dimmer sends the value
is there a solution in this case?

attached a screenshot

[bramlangen]

This makes sense - GA 9/0/12 is only blocking GA 3/0/0 when that feedback telegram is a =1=. Module 15016 then also sends a =1= (which blocks the blocking module), and one second later it sends a =0=. If a =0= arrives at the input, it sends a =0=, and one second later it again sends a =0=. In other words, the block never blocks in that case. To make the same action happen when 9/0/12 sends a =0=, then add module 19018, right after the input box and before module 15016. The attachment is only a copy/paste, be sure to set A1 and A2 to =1= (both trigger inputs need to show a yellow '1'). The output of 19018 will be the input (E2) of 15016.
No matter which value 9/0/12 sends, the block will now always block (for one second).
You will now need to verify that the blocking action is fast enough for the first line of logic to set the block, before the second line of logic has executed.
Give it a try.
(By the way, a standard binary trigger would have the same effect if you tie both outputs to the input of module 15016.)