Hi,
I am trying to differentiate commands from openhab and from an light switch. Currently for a rollershutter. The light switch must control the KNX actor directly and should be received in oh. But i have to detect If the command is from the KNX Bus or is send from oh via sendCommand.
Have somebody an Idea?
Kind regards
You can have a look in the ETS5 software, with the diagnose tool you can see if the KNX recieves the command from OH.
Sending via openhab is not a problem. I want to detect when i press a light switch, which controls s. th. e.g. a rollershutter. And i don’t want this as a status update.
When i configure KNX channel like this
Type rollershutter : rollershutterKitchenDoor [ upDown="3/1/0", stopMove="3/2/0", position="5.001:3/3/0+<3/4/0" ]
Openhab just receives changes as update.
Well a rule with trigger received command is not being triggered.
When i configure the rollershutter as rollershutter-command it is triggered as command but the rollershutter actor in the bus is not being triggered.
Can somebody help? Do not somebody want to trigger rules like this with KNX?
If you want to receive commands, you have to use the *-control type for the channel.
This way openHAB acts as the actuator, so it will send the real actuator state to knx (remember to use the status GA as first GA), receive commands from knx and send them to the real actuator (or maybe use the command to start some rules)
If you want to do both receive ans send command, you’ll have to use two channels and two independent items.
But when i use the state GA as first GA i will ever receive a command even when i send via openHAB. Because the BUS actuator sends a status update which will openhab then receive as a command.
I want to control the KNX actuators directly via the light switch because if openhab crashs i can still control things manually. Using openhab as a Proxy is not an Option.
Well, I guess I did not get the point.
Let’s say I have a light switch, this is
GA 1/1/1 to Switch Light ON/OFF
GA 1/1/2 to get status of Light
This would result in two channels:
Type switch : ch1 [ ga="1/1/1+1/1/2" ]
Type switch-control : wallswitch [ ga="1/1/1" ]
where wallswitch will receive ON and OFF commands and ch1 will receive ON and OFF updates
You can use ch1 to send commands. As the real state is from knx, you shouldn’t send status updates to knx at all.
If you want to use a dimmer which is not part of knx, you have to send the status to knx to visualize it at the wallswitch.
Ok thanks,
This is the same what i tried. I tested again, with more reboots on every change and now it seems to look good.
Well, not enough openhab restarts on knx thing changes.
Thanks for your help and patience.
Well, I think that is a bug in the core, if changing a Thing or a part of the thing (thing is created via text file, so the changes are done through this text file as well), these changes will not take place immediately but only after a restart (at least the bundle has to be restarted).
It seems this problems occurs especially when the bundle works with a bridge and a hierarchic definition scheme.
Sorry for reviving a year-old thread, but this describes one problem I have since switching from OH1 to OH2: I no longer receive commands on KNX wallswitch presses when the item status doesn’t change. On OH1 I simply had something along the lines of
Switch wallswitch1_long { knx = "15/6/15" }
translated to OH2 as a things entry
Type switch : wallswitch1_long [ ga="15/6/15" ]
and item
Switch wallswitch1_long { channel="knx:device:bridge:generic:wallswitch1_long" }
With the above, OH2 doesn’t receive commands on the item wallswitch1_long. When I switch the things configuration to
Type switch-control : wallswitch1_long [ ga="15/6/15" ]
as described by @Udo_Hartmann above, OH2 receives the command and the corresponding rule is triggered. However, this now has a side effect: OH2 answers the command with a bus reply. When I have 2 instances of OH running with such a config, they immediately enter an endless loop on this GA.
Is there any way to reliably receive KNX commands in OH2 to trigger internal rules or other state changes but without causing further KNX bus traffic?
Short answer: Don’t use two instances of openHAB with the same (knx) configuration 
There are 2 reasons for having 2 instances
I think I may have found a solution for this particular case: as mentioned in Loop when using a knx2 switch-control channel, setting
Switch wallswitch1_long { channel="knx:device:bridge:generic:wallswitch1_long", autoupdate="false" }
actually causes the previous OH1 behaviour: OH2 receives the command but doesn’t answer.
Now I think I am even more confused about when to use switch vs. switch-control. If I want to e.g. have a dimmer that has a real KNX actuator and a real KNX wallswitch controlling it, and I want to distinguish between the actuator being set from OH2 (through the UI or a rule with postUpdate) and a change triggered from the KNX bus (e.g. the physical switch), do I need to duplicate all my GAs?
You should’nt control a knx dimmer through a .postUpdate
If there is a real dimmer in knx, use a dimmer channel. IF there is no real dimmer but you want to use a knx switch to control another non-knx-dimmer, use a dimmer-control channel. The former will be controlled via sendCommand and you will get all updates via state changes, the latter will be controlled from knx (will receive commands) and will post its state to knx via postUpdate.
Thanks for clarifying - that was my previous understanding. There is a real KNX dimmer and a real wallswitch directly writing to the respective on/off and up/down GAs. However, in my (rather too complex already) blinds automation rule, I’d like to mark blinds a manually overridden when the wallswitch is used. To do that, I need to distinguish updates to the items coming from the OH2 UI or rule (with sendCommand) and a command coming in through the KNX bus and therefore causing the update to the real KNX dimmer.
Do I need to duplicate my GAs to do that?
If there was a change initiated from openHAB, you will get a sendCommand, if the change was initiated from the wall switch, you will only get a state change, so in openHAB it’s pretty easy to distinguish between both changes.
I.e. OH2 only needs a “dimmer” thing in this case, and in the rule trigger, there’s a “received command” for internal changes and a “received update” for both internal and KNX-originated events? Then the use case of only reacting to KNX events (to mark an item state as “manual”) but not OH-internal events is not obvious to me at the moment (I always had the same issue with OH1 as well). 
To clarify, openHAB UIs only issue commands to Items.
That may or may not cause an Item state update later, depending on how you have chosen to configure autoupdate on that Item, and depending if it is linked to a binding channel that might respond.
Obviously it is your choice if any rule issues a command or a state update, with different effects.
In the normal course of things, a binding will pick up OH commands and pass to real devices, while incoming device status gets passed as OH Item updates.
The KNX xxx-control type channels are the exceptions to that general rule, so that incoming from device presents as command in openHAB. That allows something like a wall control panel to act in a similar way to openHAB own UI.
This function inversion is two-way, so that an OH Item state update is passed to a configured real device (you might light an indicator on a control panel, for example).
None of that takes any account of anything that might happen independently, like your wall control directly controlling the dimmer.
Assuming thewallswitch is independently controlling blinds, you don’t need openHAB to “do” anything, only “observe” wallswitch use, right? Just configure it as ordinary non-control channel, and have your rules listen for updates. You’ve no reason to send the wallswitch any OH command.
An alternative approach you might want to use for consistency, make the wallswitch a xxx-control type channel. Your rules would now listen for commands representing manual poking.
If you set your Item’s autoupdate to false, the Item state will not update.
Think of a rule that triggers on received command for knxItem and another rule that triggers on changed for knxItem. It’s easy to setup a timer which is always started when the former rule is triggered. Now you can check in the latter rule, if the timer still exists (the only job the timer has is to deinitialize its var with null)
This is only possible since knx2 doesn’t receive a command from knx.
But it’s also possible to setup a second channel (and a second item as well) with the same GA but a control type. Now you will get the command, but only on the second item. Obviously, this item has to be configured as autoupdate="false" to prevent command echoing. But it’s also possible to define another GA to receive those status updates.
Please be aware that (as always in knx) the first GA is used to receive commands and to issue status updates, while all other GAs are only used to receive commands.
Thanks a lot - that makes sense. I am still pondering how best to do that with my current blinds rule setup (without having to change my GAs on the KNX side, which would be a lot more effort) and will reply with an update when it’s working.
It took me long enough, but I have finally gotten around to making my rules explicitly react to manual overrides, both through KNX events and manual UI control actions. I took your advice of using a timer to “lock” changes while the automatic blinds rule is running and marking any other change events as manual when this timer is not running. When I have tested my new rules in more depth, I will try to post my current solution.