Is this the last working outgoing telegram or the first failing?
We need to locate the first failing action.
Which installation method are you running?
I am running Home Assistant OS.
It is hard to find the first failing telegram because in that time I was in the bed 
I know this telegram was not delivered because it sends text to room display and this text was not displayed.
2021-09-21 00:02:01 DEBUG (MainThread) [xknx.telegram] <Telegram direction="Outgoing" source_address="0.0.0" destination_address="9/1/62" payload="<GroupValueWrite value="<DPTArray value="[0x4d,0x61,0x74,0x6f,0x75,0x161,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0]" />" />" />
2021-09-21 00:02:01 DEBUG (MainThread) [xknx.knx] Sending: <KNXIPFrame <KNXIPHeader HeaderLength="6" ProtocolVersion="16" KNXIPServiceType="TUNNELLING_REQUEST" Reserve="0" TotalLength="35" />
body="<TunnellingRequest communication_channel_id="73" sequence_counter="187" cemi="<CEMIFrame SourceAddress="IndividualAddress("1.1.21")" DestinationAddress="GroupAddress("9/1/62")" Flags="1011110011100000" payload="<GroupValueWrite value="<DPTArray value="[0x4d,0x61,0x74,0x6f,0x75,0x161,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0]" />" />" />" />" />
I discovered the HA is sending TUNNELLING_ACK to the bus (I hope I understand it correctly ) even after not sending TUNNELLING_REQUEST already.
2021-09-21 00:12:08 DEBUG (MainThread) [xknx.knx] Received: <KNXIPFrame <KNXIPHeader HeaderLength="6" ProtocolVersion="16" KNXIPServiceType="TUNNELLING_REQUEST" Reserve="0" TotalLength="21" />
body="<TunnellingRequest communication_channel_id="73" sequence_counter="21" cemi="<CEMIFrame SourceAddress="IndividualAddress("1.1.11")" DestinationAddress="GroupAddress("8/6/3")" Flags="1011110011100000" payload="<GroupValueWrite value="<DPTBinary value="1" />" />" />" />" />
2021-09-21 00:12:08 DEBUG (MainThread) [xknx.knx] Sending: <KNXIPFrame <KNXIPHeader HeaderLength="6" ProtocolVersion="16" KNXIPServiceType="TUNNELLING_ACK" Reserve="0" TotalLength="10" />
body="<TunnellingAck communication_channel_id="73" sequence_counter="21" status_code="ErrorCode.E_NO_ERROR" />" />
Every incoming telegram yields an ACK, that’s perfectly fine.
How is that text payload generated? I think that might be the source of your issue.
Like Matthias said its much better to use the routing of the Jung KNX router.
Best to just use knx: and dont bother with the rate limiter unless you have a very busy KNX bus (tho you shouldnt 
) and other settings. Just your group addresses.
I have tested HA with KNX with the Jung, Gira 216700 router and Meanwell KSR-01IP. All of them just worked.
Even have 2 sites with HA + Homeserver as i needed the interface of the Homeserver and the weird integrations that HA provide 
such as TV’s, Sonos, Unifi, ect ect
Tunneling is fine - it’s by far the most used connection method - thus better tested (but also far more complex). And it doesn’t need to account for filters in line couplers/routers for every GA.
It’s also the default connection method. So when you use only knx: you are tunneling 
However
this isn’t fine as 0x161 > 0xFF hence I’d like to know how this was created so we can reproduce and implement a proper error for that.
In the doc:
knx:
tunneling:
host: "192.168.2.23"
Let me to believe that you needed to setup tunneling and routing would be default.
But now i’m not sure it will default to routing 
Wont matter for me atm as it just works. But something to keep in mind for the future.
Yes, knx: only is tunneling.
To be more precise: setting neither tunneling: nor routing: starts xknx in automatic mode which prefers tunneling. If you want to coerce to routing just add routing: without any sub-keys.
You are right. This could be a problem.
0x161 = š (in latin unicode)
I am sending DPT16 string as KNX.notify to JUNG RCD 3096. In this case it is “Matouš” (who has name anniversary today). It is not always with diacritics.
I was surprised it could handle non ASCII characters
I changed my knx config to
knx:
routing:
and it does not communicate with the router.
Valid knx String characters are very limited indeed. Nothing we can do about that but fail gracefully…
Do you get any errors in your HA logs when you are using routing? You will probably also want to set an individual_address.
2021-09-21 18:22:43 DEBUG (MainThread) [xknx.log] Starting Routing from 10.0.0.66 as 1.1.23
2021-09-21 18:22:51 DEBUG (MainThread) [xknx.telegram] <Telegram direction="Outgoing" source_address="0.0.0" destination_address="11/1/14" payload="<GroupValueRead />" />
2021-09-21 18:22:51 DEBUG (MainThread) [xknx.knx] Sending: <KNXIPFrame <KNXIPHeader HeaderLength="6" ProtocolVersion="16" KNXIPServiceType="ROUTING_INDICATION" Reserve="0" TotalLength="17" /> body="<RoutingIndication cemi="<CEMIFrame SourceAddress="IndividualAddress("1.1.23")" DestinationAddress="GroupAddress("11/1/14")" Flags="1011110011100000" payload="<GroupValueRead />" />" />" />
2021-09-21 18:22:53 WARNING (MainThread) [xknx.log] Error: KNX bus did not respond in time (2.0 secs) to GroupValueRead request for: 11/1/14
2021-09-21 18:22:53 WARNING (MainThread) [xknx.log] Could not sync group address '11/1/14' (Branka - State)
Only outgoing telegrams which are not processed by KNX.
Bingo! 0x161 is the problem
I reproduced it now.
Thank you Matthias 
1 Like
That’s most probably due to filter tables (see Outgoing KNX telegrams are not send after HA core update - #9 by farmio)
Routing isn’t as straightforward as tunneling. You shouldn’t just use any address - 1.1.x is a TP line.
xknx in routing mode is an IP device so e.g. 0.0.1
The Router has to be on 1.1.0
Then you’d need a dummy device in ETS and connect everything you want to have forwarded to HA.
But these addresses all depend on how your bus topology is really set up.
TLDR: keep using tunneling, it’s fine. Use routing from ETS to avoid kicking HAs connection every time you use ETS.
Absolutely. I will keep using tunneling. I hope it will be stable from now.
And in case of routing. So in xknx/HA should individual_address be 0.0.1?
I have one TP line 1.1.x, IP router at 1.1.21
I looked to my ETS project and I had dummy device 1.0.21 for Gira HS without any GAs. But no forwarding all traffic to this device.
It depends on the setup of your topology, but
This is wrong anyway so I don’t know. Routers and line couplers have to be x.y.0. It may work in your installation, but it may also introduce issues when you use multiple routers etc.
Are GAs connected to this dummy device? If so then ETS is updating filter tables automatically. In not, I’d probably change the company who set this mess up 
OK. Thank you for your explanation. Dummy device has no GAs.
It was OK in the past (Gira), because Gira communicated flawlessly. ETS connection was through Gira with iETS. Now, routing must be set up for ETS. I reconfigured it yesterday. It is now possible to communicate with devices but no bus/ga monitor. I guess it is due to wrong addressing.
I made a PR replacing invalid characters with “?” to mitigate this issue in the future. Happy Hacktoberfest!
1 Like