is it somehow possible to get the source (SpecificKnxSource in my example) of a KNX Telegram within a rule? All Members of SomeGroup are KNX-Items.
rule "SomeRule"
when
Member of SomeGroup changed or
Member of SomeGroup received command
then
if (<SpecificKnxSource>) {
// DoSomething
}
end
The background is the following: I want to differ on a shutters blade change --> was it caused by manual interaction, or were the blades changed via OpenHab (my AutoShading algorithm)…
I doubt if this is possible as, from my understanding, this does not reflect the knx philosophy:
The receiving device does not differentiate between the sources that triggered a telegram to some group address. It simply performs the assigned task.
But thats just my impression of knx, if someone knows more feel free to correct me.
What you could do:
Assign two different group addresses to your actor channel, one for manual sensor, one for openHAB-related triggering.
Then create a knx thing that is linked to you manual trigger (sensor) and base your rule on updates to that things (actually a linked items) state.
Not perfect if you have more than one sensors triggering it (but the number will be limited), i know, but this way you see who triggers it.
Anyone got a better idea ? Is the sending device address accessible ?
My idea was to first configure the knx actor to respond to two different group addresses (for each of the channels you want to use).
The first set is the set of group addresses you currently use for the manual switch.
Then there may be different options (which you have to try):
E.g.:
Create a knx thing “Thing1” in openHAB and assign the first set of addresses
Create another knx thing “Thing2” in openHAB and assign the second set of addresses
So whenever you want to switch with openHAB use items linked to the second thing.
The existing physical switch/dimmer uses the original addresses.
My idea is that Thing1 and Thing2 react independent from each other.
Dunno if this really works, but it would be worth a try.
Other option is to model the sensor itself (as stated in my original post) and react to its state changes.
As I said, this is a workaround to emulated the desired behaviour somehow as the receiving device does not know about the device that triggered it. (It just reacts to the telegrams send on the bus)
triggeringItem gives you the item of group that triggered a group-based rule.
It does not provide you with the information about which device on the knx bus caused the change in the triggeringItem.
The wording here is misleading in this context, but only makes sense in the group context.
I’ve tested creating duplicate GAs within ETS and creating duplicat things/items:
From the idea it is working so far, but as I would also need to do this for “central”-GAs this is too much overkill for me.
For each shutter a possible manual action could come from these GAs:
Shutter up/down
Shutter Blades up/down
and these two GAs also for the whole room/floor/house (central approach)
So i decided to do the following:
When OpenHab is sending a new (AutoShading-)Shutter-Blade-Position to the KNX-Bus, I start a short Timer (2 seconds) before.
When then OpenHab recognizes a command/change it identifies the command/change as coming from OpenHab if the Timer is still active. Otherwise a “manual” action was the reason for the command/change.
I know this is not ideal, because if I press a KNX-button within this 2 secons - OpenHab woun’t recognize this correctly. But for the moment this is OK for me - as long as anybody has some better ideas…???
