search

snowdd1 / homebridge-knx

KNX platform shim for homebridge
https://github.com/nfarina/homebridge
GNU General Public License v2.0
97 stars 56 forks source link

Pool KNXD connections for writing #78

Open snowdd1 opened 7 years ago

snowdd1 commented 7 years ago

As new knxd allows to assign sender specifc hardware addresses, it seems to be a bad idea to open a new eibd.connection for each value write.
I didn't bother before, because homebridge is not supposed to write that much values to the bus. However, if one would really switch ALL the lights in his house, well then...

New branch https://github.com/snowdd1/homebridge-knx/tree/pool-knx-conn

snowdd1 commented 7 years ago

To test use

npm install https://github.com/snowdd1/homebridge-knx/tarball/pool-knx-conn
snowdd1 commented 7 years ago

first tests quite promising, need another tweak of node-eibd again.

Luehrsen commented 7 years ago

Can I help with this? I am running into this issue with complex scenes.

oliversluke commented 6 years ago

@snowdd1 @Luehrsen - I am also very interested in this as I run into issues the moment I ask Siri to switch more than 8 lights at the same time. Have you found any solution for this?

snowdd1 commented 6 years ago

Has anyone except me been testing that? I ran into some issues (disconnects from knxd) but my original issue was somehow solved in knxd by assigning used addresses faster, so I gave up investigating.

oliversluke commented 6 years ago

@snowdd1 - I still have the problem when I either create scenes with more than 8 devices or when I want to switch on / off all lights. How have you configured KNXD to release the used addresses faster?

I use the following configuration: KNXD_OPTS="-e 0.0.1 -E 0.0.2:8 -c -b ipt:192.168.178.xxx"

Any chance to finalize the pooling concept you started to implement to support large installations with more than 8 devices?

Thank you, Oliver

snowdd1 commented 6 years ago

In the ˋ-E ˋ Parameter you can define the number of addresses to be used for KNX clients. You have reserved 8 addresses obviously. I simply changed that number to 64 or more, my hardware devices all use 1.1.x addresses, so there is no conflict whatsoever.

bolfox commented 6 years ago

Me too, i have a knx ip gateway (Weinzierl 730) that can handle max 5 connection, some are already used for other project.

I have checked with ets log and every time i send a command it change the eib address, on scenes with more light (more than connection free) it lost some command.

There is the possibility to fix to ONE connection and make a sort of queue on scenes?

oliversluke commented 6 years ago

@snowdd1 - I tested your proposal and changed the :8 to:64 with the following result:

Now, I don't get any errors anymore in HomeKit when I switch more than 8 lights - so HomeKit does not say any longer that some of my devices are not responding. However, it looks like my IP Router (GIRA) is not able to process all the commands fast enough and randomly some lights do not switch and others do. @bolfox seams to have a comparable challenge in his setup.

Any other idea how we can fix this?

snowdd1 commented 6 years ago

The knxd has some new parameters to set the pace of telegrams per seconds sent. Please see the knxd repository and the issue list here on Github.

oliversluke commented 6 years ago

@snowdd1 - Perfect! Adding "--send-delay=60" improved my situation significantly! Thank you!

bolfox commented 6 years ago

Adding the send delay in my case cause a huge delay on single command some time and the scenes keep not working. Why homebridge open a new connection on commands?

oliversluke commented 6 years ago

@bolfox @snowdd1 - After one day of testing, I can confirm that the delay-setting improves the situation in the sense of it is working; all lights are switched, and no errors in HomeKit.

However, I have the same problem @bolfox is describing. Randomly, some commands are now delayed up to 30seconds or more. This is not always the case, in most cases the respective lights switch very fast, but every 5 action or so results in this major delay.

@snowdd1 - Any additional idea for us?

oliversluke commented 6 years ago

@bolfox - I found a solution for the problem; maybe it also works for you. I switched from knxd version 14 to knxd version 12. There version 12 in combination with the --send-delay argument works now very well for me. Maybe you can also test this. If you have the same result we know it is more an issue with knxd version 14 and not with @snowdd1 code.

bolfox commented 6 years ago

@OliverS79 Tried v0.16, same error on scene, downgraded to v0.12,same problem... Have used only --send-delay ? My cfg is : KNXD_OPTS="-e 15.15.255 -E 15.15.251:8 --send-delay=200 -b ipt:192.168.0.99"

oliversluke commented 6 years ago

@bolfox - My is KNXD_OPTS="-e 0.0.1 -E 0.0.2:64 -c --send-delay -b ipt:192.168.178.20"

Together with version 12 this is now working perfect.

In your options - please try changing the :8 to :64

bolfox commented 6 years ago

@OliverS79 - Added the -c, nothing changed, BUT, changing to :64 is work like a charm... I don't now why... :-) Probaly it create a commands queue, the cons is that it hang all my tunnel connection...

bolfox commented 6 years ago

Damn, it works only the first time. Probably it hang all the tunnel connection...

bolfox commented 6 years ago

I have tried numerous version and setting, scenes not working, the best solution will be to set and use always the same knx address for the comunications on bus...

bolfox commented 6 years ago

Any news about?