KNX Cookbook (legacy)

Just recently with 0.110.0

I just noticed that you could not get a routing connection to work. What OS / installation method are you using? Is there an error in the logs?
I have made some changes to routing stuff too. It’s not yet released, but I’d be happy If you (or anyone) would like to test this. https://github.com/XKNX/xknx/pull/295

I use a very basic hass.io on a Raspi 3b.
Will retry a multicast connection and check the logs soon. I will also try to run you PR but this will probably take some days.

I think custom components don’t run on Hassio, but I could be totally wrong here.

I would be interested in the logs though.

Custom components can be used on hass.io. It is a full HA coming with its own underlying OS. I will report soon.

Is there a config to enable extended debug logging for your component?

In HA (Top Level configuration.yaml):

logger:
  default: info
  logs:
    xknx: debug

To enable full debug log.
For finer granularity xknx provides xknx.log, xknx.knx and xknx.telegram (and coming in the next version: xknx.raw_socket) loggers.

1 Like

are you on 0.110 beta? There have been bugfixes for climate recently but I’m not sure what they really do as I don’t use climate modes at all.

I’m on latest 111.4 now and still no luck. The issue is exactly as it was. I can of course control the AC with some customized switches / automations and read status with KNX sensors but this is not as nice as the thermostat/climate devices. Anyway actually for a dashboard operation it might be still ok as I need to create those various sensors/switches and relevant automations anyway.

Hi guys,

running on 0.111.4. HA loses connection to KNX about every other day. Restart HA solves it but it’s annoying. Any hint how to troubleshoot? For what to look in tge logs?

Regards
Ralf

I’d look for Errors from the Knx integration. If there is nothing you can enable debug logging - see some posts above.
Are these disconnects happening when you program devices or do anything special on the bus or LAN? Tunneling or routing (maybe show post configuration)?

Nothing out of the ordinary for now. Some messages to and from the bus. Just every approx 8 sec these 3 lines …

2020-06-27 16:30:59 DEBUG (MainThread) [xknx.knx] Sending: <KNXIPFrame <KNXIPHeader HeaderLength="6" ProtocolVersion="16" KNXIPServiceType="KNXIPServiceType.CONNECTIONSTATE_REQUEST" Reserve="0" TotalLength="16" />
2020-06-27 16:30:59 DEBUG (MainThread) [xknx.knx] Received: <KNXIPFrame <KNXIPHeader HeaderLength="6" ProtocolVersion="16" KNXIPServiceType="KNXIPServiceType.CONNECTIONSTATE_RESPONSE" Reserve="0" TotalLength="8" />
2020-06-27 16:30:59 DEBUG (MainThread) [xknx.log] Success: received correct answer from KNX bus: ErrorCode.E_NO_ERROR

I can provide longer logs. For now it still works. I will look into the logs again after it stopped working again.

This is the tunnels heartbeat message - it is sent every 15 seconds to keep the connection alive.
You’ll have to wait until it crashes again and then look for errors.

Hi Matthias,

happened again yesterday evening. I have full log. Stripped it down to the relevant minutes. 2 MB. The heartbeat is coming like multiple times per second. Any preferred way to get access to the log file for analysis?

Regards
Ralf

I have no idea what is going on there. Seems like you have multiple instances of xknx (or xknx.io.tunnel) running at the same time - battling for a ConnectionStateResponse.
But I don’t know how this would even be possible. Very strange.

Matthias, thanks for taking the time to look into the logs. This is my yaml. Anything suspect there?

---
knx:
  tunneling:
    host: '10.0.10.7'
    port: 3671
    local_ip: '10.0.10.8'
  expose:
    - type: 'time'
      address: '0/6/6'
      entity_id: 'sensor.time'
    - type: 'binary'
      address: '1/1/8'
      entity_id: 'light.esstisch'
    - type: 'binary'
      address: '2/1/1'
      entity_id: 'light.flur_og'
    - type: 'binary'
      address: '10/0/7'
      entity_id: 'light.bad_spiegel'
    - type: 'binary'
      address: '2/1/14'
      entity_id: 'switch.dachboden_relay'
    - type: 'percentU8'
      entity_id: cover.arbeiten
      attribute: position
      address: '1/3/8'
  fire_event: true
  fire_event_filter:
    - "1/3/1-6"     # Rolladen Ergeschoss Lang/Kurz Objekte
    - "2/3/1-4"     # Rolladen Obergeschoss Lang/Kurz Objekte
    - "1/3/7-12"    # Rolladen Ergeschoss Status Objekte
    - "2/3/9-12"    # Rolladen Obergeschoss Status Objekte
    - "0/1/11"      # Zentral aus Eltern Tuere
    - "0/6/9"       # Zentral aus Eltern Bett
    - "0/1/9"       # Zentral aus Bad Tuere

Looks right. Maybe try to disable your Knx AppDaemon stuff and see if the problems persist.

Is it safe to assume this message should come approx every 15s? I turned off the appdaemon totally.

Have a log grep on above message and will see whats in the log when the frequency of this log line is happening more often than one per 15s.

Depends on your bus traffic. This message is for every received telegram.

I turned off the appdaemon stuff completely. Still, every 2-3 days I encounter the problem that the bus is not reachable.

So no cure here so far. I removed the fire_events for the status objects 1/3/7-12 and 2/3/9-12 as well now to see if there is any “ring/loop” firing to the KNX bus.

Actually that’s a good idea, I will have a look at the bus traffic next time that happens. Missed it this time.

Will keep you posted.

@rak
Have you managed to resolve the problem? I have a problem with Weinzierl KNX IP Interface 731 which loses network connection every few days, actually it can’t be access even from ETS software and is not visible on my router neither. I have to restart it manually after which it works for a few days.
Anyone faced similar issue with this device?

Sorry, was off due to vacation. Not solved. Still an issue. I am looking atm into options to auto reboot the server every day. Bad solution but WAF is unacceptable with being unreliable.