Status listeners not working above main GroupAddress 9

[tss68nl]

I am in the process of integrating a quite large KNX system in our home with Homekit using homebridge, and I am having issues with the status feedback.

It happens when you change the status of anything (light, temperature, lux) from the physical KNX system, and the Homekit has to follow the status.

After some testing, I narrowed it down that all GA's work inclusive of all GA's in 9/x/x work, but all groups presumeably 10/0/0 or higher will not provide any feedback. (Lowest I tested was 10/1/101).
I see the KNX data coming in in the busmonitor of homebridge, so I am sure the network relays the status message to homebridge. But it is not sent to HomeKit so it seems.

[snowdd1]

That is not nice, at least.
I have to admit I never tested with two digits in first group, as my installation ends at 8/ currently.
Can you post some output from homebridge log?
Thanks
Raoul

[tss68nl]

Interesting things. I tested with 4/1/101 and 10/1/101. In the homebridge log I only see the 4/1/101:

[10/6/2016, 10:49:36 AM] [KNX] [Toilet Lamp plafond]: Received value from bus:1 for 4/1/101 from 15.15.8 of type DPT1 for On
[10/6/2016, 10:49:49 AM] [KNX] [Toilet Lamp plafond]: Received value from bus:0 for 4/1/101 from 15.15.8 of type DPT1 for On

So it looks as if the listener is not set correctly. If I look at the loading DEBUG=* output we can read along with homebridge loading all listeners, and I see this:

The first group with 2 digits does register correctly so it seems. But, the resulting groups do not work. They don't show up in the homebridge.log either:

[10/6/2016, 11:09:40 AM] [KNX] Initializing platform accessory 'Tuin voor'...
[10/6/2016, 11:09:40 AM] [KNX] Preparing Services: 2
[10/6/2016, 11:09:40 AM] [KNX] Preparing Service: 0 of type Lightbulb
[10/6/2016, 11:09:40 AM] [KNX] [Tuin voor]:Lightbulb on/off characteristic enabled
[10/6/2016, 11:09:40 AM] [KNX] knx registering BOOLEAN 17/1/100
[10/6/2016, 11:09:40 AM] [KNX] [Tuin voor]:[On]: Issuing read requests on the KNX bus...
[10/6/2016, 11:09:40 AM] [KNX] [knxdevice:knxread] preparing knx request for 17/1/100
[10/6/2016, 11:09:40 AM] [KNX] Preparing Service: 1 of type Lightbulb
[10/6/2016, 11:09:40 AM] [KNX] [Tuin voor]:Lightbulb Brightness characteristic enabled
[10/6/2016, 11:09:40 AM] [KNX] knx registering PERCENT 17/1/111
[10/6/2016, 11:09:40 AM] [KNX] [Tuin voor]:[Brightness]: Issuing read requests on the KNX bus...
[10/6/2016, 11:09:40 AM] [KNX] [knxdevice:knxread] preparing knx request for 17/1/111

After that, all items that start with a double digit, are truncated (0 should be 10) :

[10/6/2016, 11:09:40 AM] [KNX] Initializing platform accessory 'Wasruimte Lamp plafond'...
[10/6/2016, 11:09:40 AM] [KNX] Preparing Services: 1
[10/6/2016, 11:09:40 AM] [KNX] Preparing Service: 0 of type Lightbulb
[10/6/2016, 11:09:40 AM] [KNX] [Wasruimte Lamp plafond]:Lightbulb on/off characteristic enabled
[10/6/2016, 11:09:40 AM] [KNX] knx registering BOOLEAN 0/1/101
[10/6/2016, 11:09:40 AM] [KNX] [Wasruimte Lamp plafond]:[On]: Issuing read requests on the KNX bus...
[10/6/2016, 11:09:40 AM] [KNX] [knxdevice:knxread] preparing knx request for 0/1/101

And 3 should be 13 in this case:

[10/6/2016, 11:09:40 AM] [KNX] Initializing platform accessory 'Hal Lamp plafond Hal'...
[10/6/2016, 11:09:40 AM] [KNX] Preparing Services: 1
[10/6/2016, 11:09:40 AM] [KNX] Preparing Service: 0 of type Lightbulb
[10/6/2016, 11:09:40 AM] [KNX] [Hal Lamp plafond Hal]:Lightbulb on/off characteristic enabled
[10/6/2016, 11:09:40 AM] [KNX] knx registering BOOLEAN 3/1/101
[10/6/2016, 11:09:40 AM] [KNX] [Hal Lamp plafond Hal]:[On]: Issuing read requests on the KNX bus...
[10/6/2016, 11:09:40 AM] [KNX] [knxdevice:knxread] preparing knx request for 3/1/101

It definately seems that the registration of the listeners is not working well. But it is remarkable that the truncation in the feedback only occurs after the first double digit registration. It happens that the first has a brightness also, but, even before that, I have switched lights with a brightness in main group 5/, and they work perfectly. So I am guessing it has to do with the double digit that breaks something?

[snowdd1]

Really strange, can you post the corresponding excerpts from your config.json?

[snowdd1]

I did not yet find any mistakes in the code, but I keep looking for it...

[tss68nl]

Sure :

    ,{  "name": "Tuin voor",  
        "services": [
            {
                "name": "Voordeur"
                ,"type": "Lightbulb" 
                ,"On":          {"Set": "17/1/0","Listen": "17/1/100"}
            }
            ,{
                "name": "Voordeur %"
                ,"type": "Lightbulb" 
                ,"Brightness":  {"Set": "17/1/12","Listen": "17/1/111"}
            }
        ]
    }
    ,{  "name": "Wasruimte Lamp plafond",  
        "services": [
            {
                "name": "Lamp plafond"
                ,"type": "Lightbulb" 
                ,"On": {"Set": "10/1/1","Listen": "10/1/101"}
            }
        ]
    }
    ,{  "name": "Hal Lamp plafond Hal",  
        "services": [
            {
                "name": "Lamp plafond Hal"
                ,"type": "Lightbulb" 
                ,"On": {"Set": "13/1/1","Listen": "13/1/101"}
            }
        ]
    }

I now see, that all status replies come into the homebridge.log. But the applications (Homekit, Elgato etc) do not recieve an update. So where only 17/ came into the homebridge.log, now all items come into the homebridge.log. Still, all groups below 10/ work flawlessly.

Can you confirm by creating a group locally in/above 10?

There is one exception, which is that I see packet loss now and then when there are multiple commands in a short time, between homebridge and the apps. But thats another issue, possibly to do with either UDP connections, or the amount of message handlers. I'll gather info on that and put in a separate thread.

[tss68nl]

Ok, hold on....I had an emtpy temperature in the json almost at the end:

    ,{  "name": " Temperatuur",
        "services": [
            {
                "name": "Temp "
                ,"type": "TemperatureSensor"
                ,"CurrentTemperature": { "Listen":  "//" }
            }
        ]
    }

This breaks the config, but only for groups 10 and higher. Filling out a non-existing 31/1/1 listener fixes them, and filling in // breaks it again.

However, Group 10 and 13 now work, but group 17 still does not work. I will investigate if it's from group 15 (the old limit for main groups), of from group 13 (The normal filtering of KNX-IP routers)

[tss68nl]

Yes, I can confirm it's group 16/ and 17/ that do not work. 15/ and below works.
They do not appear in the homebridge.log, so this is no bug of homebridge-knx.

To trace it down, I looked into the knxtool busmonitor, and there the 16/ commands and replies do show up. So knxd does get them. It seems that homebridge doesn't get the groups above 15. It could be that the connection is capped to 15/ by default.

So this is probably due to either the homebridge connection to knxd, or due to it's internal handling of the data. Should I take this up with the homebridge project? Or is there a setting that can be added to the connection properties that you know of?

Sorry to open an issue on homebridge-knx... it sure looked like the issue to be in there, but it's not!

[snowdd1]

Hi I didn't find anything in my code either. I think it is located at node-eibd in https://github.com/andreek/node-eibd/blob/master/lib/parser.js#L40 where the received telegram is decoded, I think it is only using the old addressing ranges. You might open an issue at André's project.

[snowdd1]

That has been fixed in node-eibd v.0.3.6