lighting controller and knx

[J V]

Hello,

How do I control a knx light using the lighting controller?

I have a eib sensor connected to an eib pushbutton block, connected to an eib actuator.

To activate this light using the lighting controller, what do I connect?
Is the Aq output a "switch" or a "smart actuator?"
My first idea was to connect the Aq of the lighting block to the O input of the knx block, but I feel this may prevent changing the light using a knx lightswitch.
Would it be possible to covert the output of Aq somehow to something that connects to TR?
Or would I need an "extended actuator" and have signals for on/off?

(I will have the same question regarding an eib dimmer....)

Thanks!

[Christian Fenzl]

This has been (and is) heavily discussed in the German forums.
The lightning controller has no status inputs for EIB actuators, therefore you have to program your switches and actuators "dumb" to fit to the Loxone system.
Therefore, all switches send their button presses to the Miniserver (lightning controller), and the Miniserver to the actuators.

Every KNX button sensor is not configured as switch, but with the mode "send ON on press" and "send OFF on release" (or something equal). In this setting every button works like a Loxone DI.

If you want status lights on the button sensors, you create actuator outputs that send the light state from MS to the group address of the LED of the sensor.

Dimming is the same with other EIS type of the actuators.

Could you imagine what I've tried to explain? ;-)

[J V]

Hello,

Thanks!
I get it... So either in ETS it is necessary to change things, similar to how Loxone shows it on their website for an extended knx sensor, or I have to come up with something else... As I do not know KNX (nor have the license), I will either have to contact my installer or try something in Loxone. My installer configured all knx lights with an address from which I can get the status (e.g. 1/1/1 switches a light whereas 1/2/1 gives me the status of the light), the leds on the switches are connected to sync with that. At the moment, I store the states of a light in a memory flag (one for every light), which is then used as input to the S of a eib pushbutton (to show the correct status of the button in the loxone app).

I suspect that it should be possible to create some logic that can trigger the TR input of my eib pushswitch block. Just of the top of my head, I imagine something like:
-
if (light is on) and (Aq of the lighting block changes from 0 to 1) then do not trigger (the light is already on)
if (light is on) and (Aq of the lighting block changes from 1 to 0) then trigger (the light is on and should be switched off)
if (light is off) and (Aq of the lighting block changes from 0 to 1) then trigger (the light if off and should be switched on)
if (light is off) and (Aq of the lighting block changes from 1 to 0) then do not trigger (the light is already off)
-
The first condition I should have in the memory flag, the second one I think can be achieved with a push switch ( https://www.loxone.com/enen/kb/push-switch/ ), to change the permanent on/off into a change.

It would of course still allow a person to change a light (using e.g. a physical knx light switch), and the loxone lighting controller would not know of this change and still assume it is in the same scene-mode. But if that is the only issue, I could live with it...

Seems like something to test when I have the chance...
I would have to check which addresses I have for the dimmers...

More stuff to try... Thanks!!


Jörg

[J V]

edit: removed some wrong question...

The above part may solve the actuators but not yet send the status of the lights to the lighting block. I'm thinking now if I cannot use the inputs (I1, I2, ...) to tell the lighting block the status of the lights as they are. I suspect they behave as the outputs (1 when the light is on, 0 when it is off)? I think something should be possible using the current knowledge of the lights. One more thing to look at.

I have found some threads on the German forum and the seem to contain some examples, so I will check there. The most difficult thing is that the configuration of the knx can be different...

Jörg

[J V]

Just to come back to this: my solution that seems to work.

First off: in KNX, I have a message that allows me to trigger an actor, and there is a sensor that tells me the current status of an actor. As such, in Loxone, I have a memory flag that allows me to trigger an actor, and a memory flag that allows me to see if a light is on/off.

The idea of integrating the lighting controller is the following:
1. the lighting controller triggers the EIB switches using the R and O outputs of an EIB Switch function block. Both on/off are connected to the AQ output, but the off has a not. I do not use a trigger as it became too complicated. The circuit I1-AQ1 is used as an indicator, AQ1 is connected to the disable of the retractive switch on the second page: if AQ1=1 and we need to have it on, it means I1 should not be triggered.
2. any combination of switches is translated into a status number; this number matches with the numbers of the moods. I use 0 for all off, 99 for all on, 1 to indicate that no mood matches, and then the numbers from 2 and up for to mood numbers. If the combination matches, we trigger an analog memory to send this mood number to the lighting controller (input AIs);this will make the lighting controller show the current mood. The fact that we use O and R to switch the EIB Switches means we will not get into an on/off loop. I have to retrigger the analog memory everytime a mood changes, which is why I have all the equal-blocks and the monoflops; I could not find a better way. If the status number is 1, it means the combination does not match a mood. This can have 2 causes: we are mixing moods in the lighting controller, or we are making changes with the EIB switches. In the latter case, we want to update the lighting controller to tell it we are in manual mode; this is done by making sure AQ1 is on, which is done by triggering I1 when needed. In the first case, the current mood number (AQs on the lighting controller) will be negative; in this case it means we don't want the lighting controller to change to manual, so we do not trigger I1 (nor do we send AIs).

The output of the status block is compared against a memory block that holds the same value 50 cycles ago: the reason for this is that not all the lights switch at the same time, and we don't want any states during the transition of one mood to another mood to trigger the lighting controller. (as a status block has just 4 inputs, I needed 2 of them)

We also disable the lighting controller for 0.2 seconds as soon as any lights change due to the lighting controller (it is enough to test the on signal of each output, as the pushbutton translates both rising and falling edge to a pulse.

I think this should clarify the figures below (2 EIB switches are missing as I could not fit them on the screenshot; but they are similar).





The effect is that the lighting controller shows the current situation (if it matches a mood), or manual if it does not. Use of the lighting controller correctly updates the status of the light switches and even the mixing of modes using the controller is possible.

edit: the system goes wrong if buttons are pressed too quickly; I tried to minimize the delays (0.2s during which the lighting controller is disabled, 50 cycles for the status output) but if someone triggers faster than those times, there may be an issue. I took the delays from experiments, they may still be shorter (or may need to be longer if you have more circuits). The lighting controller and eib switch status are de-synchronized when it goes wrong, but this fixes itself on the next usage of either of them (another benefit of using O and R rather than trigger on the EIB switch blocks).

edit2: there is no reason not to start number the moods from 2. I changed it so that the moods are numbered 0 (off), 99 (bright) and then from 1 to as many as needed. The status is -1 if the combination does not match a mood. No difference in functionality but perhaps a bit more readable.

Hope this helps someone!

edit3: Now to get working on integrating a knx dimmer...

Jörg

[J V]

Just thinking that I made it too complicated: the pushbuttons to the left of the lighting controller serve to disable the lighting controller while the lights are changing (to avoid intermediate combinations of states due to the switches not switching at the same time). But the analog memory (right of the status on page 2, the one with the 50 cycles delay) serves the same purpose... So maybe those pushbuttons can be removed. I'll test it as soon as I can.

edit1:
The part that connects to the disable input of the lighting controller block can be removed; delaying the status value with 50 cycles and checking if it matches the status value is enough to prevent the system of triggering on intermediate values. So it becomes quite a bit simpler.

First tests for the dimmer seems to indicate it also works, but I need a bit more of testing before as my knx dimmers are software limited to 70% (otherwise they have issues driving the low loads as I have leds connected). So I need to capture that in the system as well.

edit2:
The same approach works for the dimmers: just send the AQx from the lighting controller to the EIB value input. And in the status block, check for a value rather than just 1/0.

[Gast]

I think that you could actually just send the dimming value (0-100%) to a virtual output of your miniserver corresponding to a (hidden) virtual input of your miniserver. In my case i can send data to: http://miniserver-iport/dev/sps/io/10738f35-0053-820b-ffff8bb53a8e1951/ai1/dimmingvalue and change the status of a dimmer channel in the lightning controller. AI1 corresponding to the input number of the lightning controller and the lighning controller is: 10738f35-0053-820b-ffff8bb53a8e1951. This value i found under control when looking in node-red under information and read more.

[J V]

Interesting... Not sure I fully get it from reading the post, but will have to study it a bit more.

I started my config from scratch, as it was quite messy since I had it since Loxone Config v6. Some things could be done much better now, and the format shown on the app also was not as nice as it used to be. So I'm getting back to this soon; I just redid the EIB switches and improved some things on the past config. Now to add the lighting controllers, the intelligent room controller (these are the most tricky ) and the media controllers...

[Gast]

It's like you do a webcall to the api. It's described here: https://www.loxone.com/enen/kb/web-services/ but i found out how the Lighning controller is represented through the name in node red. Then it all maked sense!

[J V]

I get it. I'm not sure it is needed though, as I could translate the analogy values correctly, but I will check it: your approach may provide for a more robust solution. I'm also thinking it may help me in integrating the knx thermostats with the IRC.
I never used node-red and have no node-red server running, but it looks interesting.
Thanks!