absurd problem with openhab and knxd (control via ETS and knxtools works!)

[ards...@gmail.com]

Hi,

I have an absurd problem with knxd. I cannot get it work with openhab.

I am running rasp3 with openhab 3.3 and on the same box I have the tpuart with:

KNXD_OPTS="-f9 -t1023 -e 1.1.250 -E 1.1.240:8 -u /tmp/eib -D -T -R -S -b tpuarts:/dev/knx"

[20:50:54] pi@raspberrypi:~$ /usr/local/bin/knxd --version
knxd 0.14.28:ceccae1-emipatch

I have a KNX/Dali converter on 1.1.1 so technically this is my only KNX device (next to the tpuart on 1.1.250 as per config)

When I monitor the bus ... I see perfect results (as in: the Switch works and lights go on/off) WHEN either a) I write the value via ETS on group address 0/0/10 _OR_ b) when I issue it via knx tools ('knxtool groupswrite ip:localhost 0/0/10 1')

This works as well when I use Easy KNX Lite as an app on my phone (and using the gateway mulitcast IP)

In openhab I defined a Switch which is linked to a channel (and the channel is mapped to 0/0/10) owned by the KNX/Dali Thing.

And guess what: When I switch via ETS or via knxtools, the Switch in the UI works perfectly as in: it follows the state that was issued.

However, turning the switch manually in openhab does not give me the desired result.

No switching happens and 'knxtool vbusmonitor1 ip:localhost' remains empty

I have attached the logilfes of all three "clients"

1-ETS

2-knxtools

3-openhab (issueing the switch in the UI/manually)

here is the snippet for 3-openhab and the suspicous line is 'Packet not from us'

Oct 23 20:18:26 raspberrypi knxd[19022]: Layer 0 [13:server/Server         4239733.703] Recv(022): 06 10 02 0B 00 16 08 01 C0 A8 02 AC D4 C1 08 04 01 02 08 06 07 00
Oct 23 20:18:26 raspberrypi knxd[19022]: Layer 8 [13:server/Server         4239733.703] Unexpected service type: 020b
Oct 23 20:18:26 raspberrypi knxd[19022]: Layer 0 [13:server/Server         4239733.706] Recv(014): 06 10 02 01 00 0E 08 01 C0 A8 02 AC D4 C1
Oct 23 20:18:26 raspberrypi knxd[19022]: Layer 8 [13:server/Server         4239733.706] SEARCH_REQ
Oct 23 20:18:26 raspberrypi knxd[19022]: Layer 1 [13:server/Server         4239733.706] Send(070): 08 01 C0 A8 02 68 0E 57 36 01 02 00 11 FA 00 00 01 02 03 04 05 06 E0 00 17 0C B8 27 EB C6 8D 7F 6B 6E 78 64 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Oct 23 20:18:26 raspberrypi knxd[19022]: Layer 0 [13:server/Server         4239733.706] Send(076): 06 10 02 02 00 4C 08 01 C0 A8 02 68 0E 57 36 01 02 00 11 FA 00 00 01 02 03 04 05 06 E0 00 17 0C B8 27 EB C6 8D 7F 6B 6E 78 64 00 00 00 00 00 00 00 00 00 00
Oct 23 20:18:26 raspberrypi knxd[19022]: Layer 0 [13:server/Server         4239734.401] Recv(021): 06 10 04 20 00 15 04 01 06 00 11 00 BC E0 11 FA 00 0A 01 00 81
Oct 23 20:18:26 raspberrypi knxd[19022]: Layer 8 [433:tunnel/1.1.242        4239734.401] TUNNEL_REQ
Oct 23 20:18:26 raspberrypi knxd[19022]: Layer 3 [432:tunnel/ConnC          4239734.402] Packet not from us
Oct 23 20:18:26 raspberrypi knxd[19022]: Layer 1 [13:server/Server         4239734.402] Send(004): 04 01 06 00
Oct 23 20:18:26 raspberrypi knxd[19022]: Layer 1 [13:server/Server         4239734.402] Send(015): 04 01 39 00 2E 00 BC E0 11 FA 00 0A 01 00 81
Oct 23 20:18:26 raspberrypi knxd[19022]: Layer 0 [13:server/Server         4239734.402] Send(010): 06 10 04 21 00 0A 04 01 06 00
Oct 23 20:18:26 raspberrypi knxd[19022]: Layer 0 [13:server/Server         4239734.402] Send(021): 06 10 04 20 00 15 04 01 39 00 2E 00 BC E0 11 FA 00 0A 01 00 81
Oct 23 20:18:26 raspberrypi knxd[19022]: Layer 0 [13:server/Server         4239734.403] Recv(010): 06 10 04 21 00 0A 04 01 39 00
Oct 23 20:18:26 raspberrypi knxd[19022]: Layer 8 [433:tunnel/1.1.242        4239734.403] TUNNEL_ACK

In a github issue I found the follwoing comment by smurfix:

"Packet not from" says that the address is still registered to a different link.

and: "knxd filters by physical address and will not forward packets from A if their phys source address previously appeared on B, in order to prevent a packet storm when you have a cycle or worse in your bus."

But I don´t know if that relates to my problem and what I can do about it?

@smurfix: I would very much appreciate your help on that! Thanks a lot.

Best

/Jochen

[Matthias Urlichs]

Hello,

> Oct 23 20:18:26 raspberrypi knxd[19022]: Layer 0 [13:server/Server    
> 4239734.401] Recv(021): 06 10 04 20 00 15 04 01 06 00 11 00 BC E0 11
> FA 00 0A 01 00 81
> Oct 23 20:18:26 raspberrypi knxd[19022]: Layer 8 [433:tunnel/1.1.242  
>      4239734.401] TUNNEL_REQ

Well. The tunnel has the address 1.1.242, but the packet is clearly from
1.1.250 ("11 FA") … which happens to be knxd's own address.

This is nonsense. You need to tell OpenHAB to either use the dynamic
address that it received from knxd, or to use a fixed address that is
not assigned to knxd (i.e. *not* in the 1.1.240…1.1.247 range, and
definitely *not* 1.1.250).

Using the address of knxd itself as the source address of a packet that
OpenHAB transmits is clearly broken. Kindly tell, well, whoever authored
the document that suggests that this can possibly be correct, that this
needs to be fixed.

--
-- mit freundlichen Grüßen
--
-- Matthias Urlichs

[ards...@gmail.com]

argh - ok this is embarrassing now (for me).

Yes, indeed, I had 1.1.250 in the "Local Device Address" field in the Openhab UI where you configure the KNX/IP interface

Below the field it gives a hint: "The Physical Address (Individual Address) in x.y.z notation for identification of this KNX/IP gateway within the KNX bus"

So I was too quick in filling in the physical address of knxd, whereas I should have inserted any non-conflicting client address as you pointed out.

Thanks for your quick help and I did do a small donation. Keep up doing such great work!

Best

/Jochen

[Matthias Urlichs]

On 25.10.22 08:39, ards...@gmail.com wrote:
> Yes, indeed, I had 1.1.250 in the "Local Device Address" field in the
> Openhab UI where you configure the KNX/IP interface
> Below the field it gives a hint: "The Physical Address (Individual
> Address) in x.y.z notation for identification of this KNX/IP gateway
> within the KNX bus"

Sehr lustig. Man ersetze "this KNX/IP gateway" durch "this OpenHAB
instance" und das Ganze ist um Einiges eindeutiger.

https://github.com/openhab/openhab-addons/issues/13602

[ards...@gmail.com]

Absolut. Danke für das openhab Ticket. Da werden sonst sicherlich andere auch noch drüber stolpern.

/Jochen