No worries, I understand if it doesn’t works. Looks quite complicated, thanks for your efforts.
Hi Burningstone,
in order to listen to knx_events the following has to be enabled in the config file:
fire_event: true
fire_event_filter: ["1/0/*", "6/2,3,4-6/*"]
Having done that, this came out:
On
{
"event_type": "knx_event",
"data": {
"address": "5/3/1",
"data": 1
},
"origin": "LOCAL",
"time_fired": "2020-01-13T19:33:21.879668+00:00",
"context": {
"id": "d2d1aa77688f47f790d46d67d6342bf4",
"parent_id": null,
"user_id": null
}
}
Off
{
"event_type": "knx_event",
"data": {
"address": "5/3/1",
"data": 0
},
"origin": "LOCAL",
"time_fired": "2020-01-13T19:33:23.134494+00:00",
"context": {
"id": "4ca8ad4064404b87856fae185cc60019",
"parent_id": null,
"user_id": null
}
}
Press Dimmer Up
{
"event_type": "knx_event",
"data": {
"address": "5/3/3",
"data": [
9
]
},
"origin": "LOCAL",
"time_fired": "2020-01-13T19:33:24.476131+00:00",
"context": {
"id": "0ed36abb34bc4df3beae75947f25ea6c",
"parent_id": null,
"user_id": null
}
}
Release Dimmer Up
{
"event_type": "knx_event",
"data": {
"address": "5/3/3",
"data": [
0
]
},
"origin": "LOCAL",
"time_fired": "2020-01-13T19:33:25.380084+00:00",
"context": {
"id": "99248b758794403e8d13cf259bc85777",
"parent_id": null,
"user_id": null
}
}
Press Dimmer Down
{
"event_type": "knx_event",
"data": {
"address": "5/3/3",
"data": [
1
]
},
"origin": "LOCAL",
"time_fired": "2020-01-13T19:33:26.646244+00:00",
"context": {
"id": "556d020605684714a058dafdfa7bfe86",
"parent_id": null,
"user_id": null
}
}
Release Dimmer Down
{
"event_type": "knx_event",
"data": {
"address": "5/3/3",
"data": [
0
]
},
"origin": "LOCAL",
"time_fired": "2020-01-13T19:33:27.653840+00:00",
"context": {
"id": "fa48757c673e4bd2a3cb8727571d1f78",
"parent_id": null,
"user_id": null
}
}
What do you think now? Would it be possible to connect this events with your app?
1 Like
Ok, this looks very good! I was hoping that I don’t need to integrate a knx event monitor into AppDaemon 
From what I see this should be relatively easy. I’ll come back soon with something to test for you.
So from your data I get this:
address data button press
5/3/1 1 -> short press Button A
5/3/1 0 -> short press Button B
5/3/3 9 -> long press Button A
5/3/3 0 -> release Button A after long press
5/3/3 1 -> long press Button B
5/3/3 0 -> release Button B after long press
Now, how can I identify, which switch has been pressed? is “5/” the identifier for the switch? Will the addresses be the same for another switch but starting with “7/” instead of “/5”? Do you have another switch to test?
Yes, you got it right.
And yes that’s the way to identify the switches. I am not organizing the addresses by switch, but by light groups, for example:
Light Group 01:
On/Off Address 5/1/1
Dimming Address 5/2/1
Light Group 06:
On/Off Address 5/1/6
Dimming Address 5/2/6
Light Group 12:
On/Off Address 5/1/12
Dimming Address 5/2/12
and so on… but in reality its the same…
Hmm I don’t get it, the example you show uses always “5/3/” no matter if it is on/off or dimming. In the example events it’s the last part of the address that is changing based on on/off or dimming and in the description you give now it’s the middle part of the address that is changing based on on/off or dimming.
Sorry if I am making it complicated for you. 
Those addresses are configurable and 5/3/1 and 5/3/3 were just for test purposes. For the final working configuration I would like to use the new notation because for me it is easier to organize. Works like this:
5 refers to all the zigbee lights, lets call this a group.
Then comes the middle group that defines an action. 1 for switching and 2 for dimming
And in the end comes the number of the light to be switched or dimmed. This creates an address group.
We end with:
5/1/1: Switch light 1 on or off and 5/2/1: dimm light 1 up or down.
5/1/2: Switch light 2 on or off and 5/2/2: dimm light 2 up or down.
Hope this helps!
And yes, I have more switches that we can test. But since everything in neatly packed in different addresses, I got the feeling that if one works the others will too.
Ah I see, you’re not making it complicated, I just don’t own any of the devices and ask a lot of questions because I need very specific and accurate information. 
I’ll come up with something to test for you very soon, promise 
Good news, I got something to test for you 
In my limited testing it worked fine (I simulated the KNX events with the addresses you provided). You are able to configure the address for dimming and for on/off in the app. Which version of AppDaemon are you using? Do you have some experience with AppDaemon, like reading the log etc.?
Hi,
well I had AppDaemon 3, but updated to 4 but is there seems to be a problem:
ERROR 'log' directive deprecated, please convert to new 'logs' syntax
I can configure the addreses thats right. Have no experience with AppDaemon, but I’m willing to learn…
I know, but I mean you can configure the address in the app I wrote, so if you ever going to change your address scheme it shouldn’t be a problem 
I’ll send you a PM later with the code and some instructions.
For the log error, you need to change the log section in appdaemon.yaml as described in the docs
Thanks for the info. Ok will give it a try and let you know how it goes.