I’m having a contact from my KNX installation. This contact is ‘hard-coded’ (over ETS) is in a group, and that group trigger some lights. But I would like to reuse this contact in a rule so the lights are also triggerd.
Contact contact_WO_Badkamer1x "Badkamer 1x" <contact> (contactWO,ContactBadkamer) { knx="4/1/1" }
I thought to use this in a rule, but apparently it’s not working? Any idea what I’m doing wrong?
<knip>
sendCommand(contact_WO_Badkamer1x, ON)
</knip>
You can’t send commands to a contact: it’s a passive device. Trigger upon a state change of the contact and send commands to your lights instead.
That was what I feared. Thanks to confirm!
A small workaround below perhaps? At first sight it seem to work, not sure it’s healty, so feel free to comment!
My items:
Contact contact_WO_Badkamer1x "Badkamer 1x" <contact> (contactWO,ContactBadkamer) { knx="4/1/1" }
Switch Switch_WO_Badkamer1x "Badkamer 1x" <contact> (contactWO,ContactBadkamer) { knx="4/1/1" }
My Rule:
<knip>
sendCommand( Switch_WO_Badkamer1x, ON )
</knip>
ps the whole issue is that my girlfriend is afraid of “servers”. So she want that our electricity keeps on working, even when the server is gone. So in my KNX installation, I’ve configured some groups and so through ETS. This way, when the server is out, we still have a minium of service (fe 1 light in the bathroom instead of 3 in normal situation. The 2 other lights are added through rules). But of course, this brings some thinking out of the box to get things running…
You can change ‘contact’ into ‘switch’, then you can send commands to that item.
But your question does not make sense to me.
You don’t want to send commands to a switch, do you ? A light switch is no actuator, it’s a (passive) input device, it will not know what to do with that command.
You will need another item for the actor that the light is attached to (with its own KNX address).
I know that this a bit a strange setup. But if you want to keep on sharing the bed with your girlfriend… 
I’ll try to explain, don’t break your head on it, mine broke already a few times on it.
In openHAB, my knx items have the real addresses of the nodes. The group addresses aren’t know by openhab. In openhab, I’ve used the proper description for everything (button = contact, relay = switch…).
When an openhab item (switch) is now being triggered, the knx-group isn’t aware of it. This because only the knx contacts have an sending flag in the knx group. And sometimes, this ends in strange situations. Because the group isn’t aware of the status of a device. And therefor when you use a knx-button afterwards, it sends the wrong command (fe ON instead of OFF) to the node.
But at first sight, with using 2 almost identical items (one contact and one switch) and the same knx address, it’s working. Maybe I could also just rename the contact with switch, but to keep it a bit clear…
ehmm…
I believe that this statement is incorrect.
OpenHab knows the Group Address (GA) for your KNX deployment based on the (bound) items that you define.
When you set the item (like in your example above):
Switch Switch_WO_Badkamer1x "Badkamer 1x" <contact> (contactWO,ContactBadkamer) { knx="4/1/1" }
You use the GA of KNX (not the PAs of the KNX devices). In this example, the GA 4/1/1 is used.
In the KNX Bus, you will have (at least) 1 actuator (active) and 1 push-button (passive) linked to this GA.
An OpenHab defined item will act as another “virtual” push-button on the same GA and will send a KNX Telegram to the BUS on that specific GA (i.e. On or Off, etc).
If you want to trigger multiple lights with OpenHab, you can define multiple items (with their individual/associated GAs), put them in an OpenHab (OH) Group and then control the OH Group.
Here is an example:
Group:Switch:OR(ON, OFF) g_Lights "Grouped Lights [(%d)]"
Switch Light_1 "Light 1" (g_Lights) {knx="4/1/1"}
Switch Light_2 "Light 2" (g_Lights) {knx="4/1/2"}
Then, in your sitemap, display the Group Switch:
Switch item=g_Lights mappings=[OFF="All OFF"]
Switch item=g_Lights mappings=[ON="All ON"]
BR,
Dim
Ps: If you want OH to be able to read the status of the light, add the status GA to each item (e.g. {knx="4/1/1+<4/2/1"} where 4/2/1 is the status GA.
Well, I chose to avoid KNX, and I’m still with my girlfriend. Married even. 
Indeed, could be nicer.
Will have a look to redefine all PAs towards GAs.
Specially the multiple group sounds intresting to me.
Today, I’ve created a rule for this to check the status of the light, and if, then…
Back to the drawing board…
Well, I could be wrong, but… as I begun knx without a server, I can control every light and every roller shutter through wall mounted switches, even the temperature is controlled via knx, and the rom temperature controllers are integrated to the switches.
If openHAB fails, the only things that stop working are:
As I used only two motion detectors in the corridor, the lights are not that smart, but I can control everything from within openHAB and without any drawbacks even through the wall mounted switches. openHAB only knows about the GA to switch or dim, up/down/stop and so on, but these are put together with the state GA, there is no rule needed to get full control. The only thing that does not work is a stop state from roller shutters, because the actuator does not send any. But I could change the actuators to new ones, which would report the absolute position…
I do not see any advantage to isolate switches from actuators, as knx is not intended to work this way. In most cases, you will have to send a command even to the switches, in order to tell them if a light is on or off (if using toggle mode). I even set up a bunch of scenes for living room (eight independent light sources, four dimmed) with knx.
WAF is near 100% :), visitors aren’t upset with strange operations concepts.
Same here
You are correct. In the KNX architecture, the system works mainly standalone (with its switches and actuators).
OpenHab comes on top as a parallel control layer that enables more automation options (and many other cool features and integrations to other systems).
One important aspect is to have the Status Group Addresses configured correctly in the KNX deployment in order for OpenHab to be able to read reliably the status of the (light/shutter/dimmer/etc) actuator channels.
I think that if Ben starts to use Status GAs (linked to the actuator channels) along with the Command GAs in his items definitions, he won’t experience the situation that he is describing here:
BR,
Dim
I’ve double checked, and for the moment, I’ve got all GA instead of the HA. But I’m a bit confused where I should put it. On the level of the light, or on the level of the switch?
If I want to control that light (=group), then I should put the HA on the light and not on the contact since I can’t control ‘contact’? So I need to use the light in my rules, and not the contact?
In the ETS group 4/1/2, I’m having 2 objects:
Now I see 2 possibilities to configure this. What’s the best?
Possibility 1
Switch light1 "Bathroom" <light> (LightsALL) { knx="4/1/1+3/3/3" }
Contact Switch1 "Bathroom 1x" <contact> (contactALL) { knx="3/1/1" }
Possibility 2
Switch light1 "Bathroom " <light> (LightsALL) { knx="3/1/62+3/3/3" }
Contact Switch1 "Bathroom 1x" <contact> (contactALL) { knx="4/1/1" }
The most common configuration would be (in ETS):
knx push button switch(es) linked to GA 3/1/1 (this will be sent if button is pressed) + GA 3/1/2 (only receive and change the internal state marker, for toggle and/or feedback, this is, if the actuator is listening to other GA or is member of a scene and thus will change it’s state independently of GA 3/1/1)
knx actuator input (ON/OFF) linked to GA 3/1/1 (receive only)
knx actuator output (state ON/OFF) linked to GA 3/1/2 (send the state, this knx node is the only one to transmit, all other knx nodes do only receive updates)
Now, in openHAB you would define this actuator channel as:
Switch myLight "My first light is [%s]" <light> {knx="3/1/1 + <3/1/2",autoupdate="false"}
If you would switch the light from knx side, the actuator would send the state, which would be received by openHAB (GA 3/1/2) and the state of myLight would change according to the state of the actuator.
If, on the other hand, switching the light from within openHAB (regardless if UI or rules), the knx binding will send GA 3/1/1 to knx, the actuator will receive and answer with GA 3/1/2.
Because the item is linked to autoupdate="false", the item state will only change if a command is received through knx (GA 3/1/2), or if changed through method or action postUpdate().
Because of the leading <, openHAB will (only at startup) ask knx for the state of GA 3/1/2, so, only the actuator will answer the state and openHAB will have the correct state from the very beginning.
This mechanism is very simple, but as I’m no English native speaker, my description is far more complex as needed
Thanks!
It sounds ‘logic’ when you explain it with the leading < and the update. It’s always nicer if you understand the things you do.
Next week, I’ll have a look to change all my ETS-groups in the item file and test it.