KNX Cookbook (legacy)

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.

On my end I have managed to narrow down the issue to only situations of power loss. The KNX IP interface is not getting an IP address after power is resumed, manufacturer has admitted some other users having similar issue. I have installed a power delay timer switch so the KNX IP interface now starts 3 minutes after power is resumed. Letā€™s see if this will resolve the problem.

Isnt it the case that the IP interface is up much faster than the DHCP server?. Thus getting no/the default ip address. Not sure if this qualifies as a bug.

Probably it is earlier up but that is not how network device should behave. It is the only device in my network that has this problem and I have over 40 of them.

I have a strange issue with KNX integration. Finally I have found some time to configure controls for Fan speed but it does not work yet. The telegram is sent to the bus, Iā€™ve double checked the group addresses etc but the specific function does not work. Also tested it with manual knx.send service but the device does not react. Other commands work e.g. turn on and off, also climate device nicely changes the hvac_mode. Iā€™m sending a value from 1 to 4 for this Fan Speed control, what Iā€™ve noticed is that on the bus it shows no DPT value - donā€™t know why and how I could control it.


When I write value to the group address in ETS the device works ok, the difference in the bus monitor is the DPT for that telegram - in this case it matches the definition:

How can I fix it so that HA integration sends the right DPT for that telegram?

DPT information is never encapsulated in knx telegrams. This is solely read from your project by ETS. If you have not set this information In ETS for 1/4/9 it will not be shown.
That said, this has nothing to do with the device not reacting properly.

Iā€™d find out what DPT the communication object expects and use an exposure for this together with a template sensor.

Or wait until the next update and use knx.send with a type. (Currently it can only send raw payloads - if you pass it an integer this is treated like a DPT 1/2/3 wich is probably not what you want)

1 Like

Yeah, that is exactly the conclusion I came to as well. I have just configured the expose: with correct data type and it works well now :slight_smile:

Hope itā€™s ok if I post my question in hereā€¦
I have a group address that I use to turn off all lights on my first floor.
I exposed that using xknx.yml (not sure if done correctly)

groups:
    light:
        light.knx.group_unterer_stock: { group_address_switch: '0/0/1', group_address_switch_state: '0/0/1' }

Now Iā€™d like to trigger an automation (to also turn off all hue lights that I have) but itā€™s not working and I donā€™t know where to start lookingā€¦

My automation looks like this:

binary_sensor:
  - platform: knx
    name: light_knx_unterer_stock_off
    state_address: '0/0/1'
    automation:
      - counter: 1
        hook: 'off'
        action:
          - entity_id: light.hue_kueche_oben
            service: light.turn_off
          - entity_id: light.couchtisch
            service: light.turn_off

Have you tried to set ignore_internal_state=True?
If the state on this GA doesnā€™t change to ON if one light is turned ON the hook wonā€™t fire because there was no state change.

Thanks for your help @farmio! Didnā€™t try that setting. Where would that go?

So basically on the 0/0/1 Adress I have a button in my wall sending a 0 and then a couple of lights turn off on a short pressā€¦ on a long press it would send a 1 to turn on all the lights.
This address has no state though.
That works fine (not sure if thatā€™s how itā€™s done, but it works for me)

So now in HA I just want to do something when that address gets a new valueā€¦

Am I on the right path? Or am I doing something entirely wrong?

Itā€™s ok. The ignore_internal_state goes on the binary_sensor config - See documentation.

If you once donā€™t turn on all of your lights with 0/0/1, the state will be still 0. When you press your button now and send a 0 the internal state has not changed, but you want tonprocess it anyway. This is what the config does.

You could also use a scene for these things.

@farmio I just donā€™t see where the ignore_internal_state needs to goā€¦ I looked at the config for the knx-binary sensor and itā€™s not there?


Or am I blind???

Also googling for ā€œignore_internal_stateā€ brings surprisingly little search resultsā€¦ But I learned that you are one of the main xknx-github contributors though! Thanks a lot for that!!! Really cool!

Oh, Iā€™m sorry. This isnā€™t even integrated to HA yet :rofl:
It was merged to xknx 4 month ago but hasnā€™t found its way to HA. With the next version (HA 0.115 or current dev) you will be able to try this.

1 Like

Update:
I changed all config examples in the original posting to reflect the changes that were introduced to the KNX integration with the release of Home Assistant v0.115. (platform: knx was removed from the entity definitions.)
AFAICT the old definitions are still accepted and working in v0.115 (at least they did for me). But itā€™s surely commendable to keep the cookbook in sync with the latest documentation.

2 Likes

Thanks for update. For me the old config did not work after upgrade to 115, had to change the config to make it work.

Same here, Iā€™m going to need to rework all of the KNX stuff in my config. Perhaps itā€™s a good time to separate it out into dedicated YAML files instead of just piling it all into the main config YAML.

My wife told me this morning, ā€œdid you change something in the app?ā€ (she usually only interfaces with HA via the HA app) I told her I updated it before realizing the KNX updates were going to take me a lot longer to sort out than I thought. She then tells me, ā€œyou mean I have to get out of my chair and press a button?!ā€ :rofl:

If you have plenty of KNX devices it could indeed take some time but in general was not difficult - search/replace in notepad++ was enough for 99% of changes :slight_smile:

1 Like