KNX Cookbook

Community Guides
, ,
41

Hi Ingo,
sorry for the late reply. Yes I use Node-RED. I actually migrated most of my automations to it. It is so much easier to do complex things in NR than through HA automations!

And Julian is basically correct:

You really don’t need any special Node-RED KNX contribs. If you install Node-RED in HA through Frenck’s Node-RED add-on you will find special nodes to create NR messages on HA state changes and on HA events and also to call HA services like turn_on or turn_off. If you install the additional Node-RED websocket companion component in HA you can even create new HA entities out of Node-RED without any preparation in HA itself.

This being said I actually do use an additional KNX add-on in Node-RED. I tried several solutions and finally chose KNX-ULTIMATE. I use it for tasks where it seems much easier to send KNX telegrams directly from Node-RED without any extra step over HA. An example would be text messages that I want to display on my MDT Glass Switches. In fact I now mix and match KNX nodes from HA and KNX ULTIMATE nodes. Whatever seems more appropriate. The basic rule (which I sometimes break) is: If I can cleanly and fully represent some KNX device through a HA KNX entity then I do so. If there is no matching KNX entity in HA, I use direct communication in NR.

There is one more detail that I want you to be aware of:
Through all my NR automations there is a dangerous situation that I faced again and again. It is actually not NR specific, but as it is so much easier to do fancy automations in NR, it is also easier to get to this point. It always happens when I integrate and synchronize multiple external systems through HA, e.g. KNX and Zigbee. The problem is: looping messages.

As long as you only want your Zigbee bulbs to follow your KNX switches there is no trouble. But I also want my KNX switches to update their state when the Zigbee bulbs are controlled through other means, like HA’s Lovelace frontend. Or through third parties like the Hue App. So I sync the state of Zigbee with KNX and I also sync the state of KNX with Zigbee. Et voila: Message loops can happen!

If you are lucky, you see your lights flickering and know that something is wrong. If you are not so lucky you will find HA lagging for no obvious reason and your history database explodes.

To avoid that situation I have created a sub-flow called “Loop breaker” which I use whenever I need bi-directional (or multi-directional) syncing. I will publish that subflow here soon - wanted to do that for quite some time already. It can be used like another NR node, very simple. (I was actually suprised that I could not find any existing NR contrib that fills that gap.)

About MQTT:
Yes, I have it installed and I do some very simple messaging through it. But far less than I expected. There will be more MQTT when I start using my own ESP32 air quality sensors. But so far it is not very important for me.

1 Like
42

Hi Jürg,

I’m sorry if you caught it as stealing other work or ideas.

I’m sorry if you caught it as stealing other work or ideas.

I was just looking for inspiration on how I could do this, as I can also benefit of the function by myself.

Just like KNX integration with lighting, climate, etc., it could be that an integration for multimedia.

My customer has just asked if I can make this control / integration. So I just have to report back to the customer that it is an option or not.

therefore, I took my client’s installation as a starting point to use it as an example.

43

After updating from latest 0.117.x to 0.118.2 (now 0.118.3) my KNX lights in HA did not respond to state changes send from KNX via the state_address. I had to set fire_event true like this to make it work again:
</s> <s>fire_event: true</s> <s>fire_event_filter: ["*/*/*"]</s> <s>
Now the status is not set correctly after boot, but at least when I manually do a read for each entity / send it to the bus via ETS.
The solution only worked for some hours.

44

Hello Markus, I have the same issue. Somebody already opened an issue on GitHub.
#43550

1 Like
45

Aaah, good to know, thanks. Since 0.118 I am having issues with some of my KNX automations realized in Node RED flows. It seems like the HA State Change nodes of my KNX switches do not fire anymore. Certainly the same problem.

46

FYI:
To temporarily revert back to 0.117 you can use the HA command line.
To do so you need SSH access to your HA instance, i.e. through Frenck’s SSH add-on.
Then the command to revert ist:

ha core update --version 0.117.6
47

Hello everybody,

I have the following entry in my configuration.yaml

knx:
    tunneling:
       host: '192.168.2.23'
       port: 3671
       local_ip: '192.168.101.100'
    
    light:
    - name: 'kitchen'
      address: '1/0/9'

Unfortunately no “kitchen” switch appears under entities.
I have to say that I currently don’t have an IP router ready to receive …
After restarting he still has to insert the entity despite no connection to the IP router, right?

Thanks in advance

Vielen Dank im voraus

48

Hi Andreas,
have you checked the HA log? Usually any entities that could not be initialized are listed there.

49

Mixing 2, 3 and 4 Space indentation in yaml is probably not serving you well. Have a look at the docs on how these entries are indented correctly.

2 Likes
50

Oh yes, @farmio’s sharp eye nailed it! :clap:

51 
knx:
 tunneling:
 host: '192.168.2.23'
 port: 3671
 local_ip: '192.168.101.100'
        
 light:
 - name: 'kitchen'
 address: '1/0/9'

Invalid config for [knx]: expected a dictionary for dictionary value @ data[‘knx’][‘tunneling’]. Got None extra keys not allowed @ data[‘knx’][‘address’]. Got ‘1/0/9’ extra keys not allowed @ data[‘knx’][‘host’]. Got ‘192.168.2.23’ extra keys not allowed @ data[‘knx’][‘local_ip’]. Got ‘192.168.101.100’ extra keys not allowed @ data[‘knx’][‘port’]. Got 3671 required key not provided @ data[‘knx’][‘light’][0][‘address’]. Got None. (See /config/configuration.yaml, line 11). Component error: packages - Integration ‘packages’ not found.

52

Make sure the indentation is correct. 2 spaces (not one) for single indentation and in the right place:

knx:
  tunneling:
    host: '192.168.2.23'
    port: 3671
    local_ip: '192.168.101.100'
        
  light:
    - name: 'kitchen'
      address: '1/0/9'

Highly recommended to use editor like notepad++ with configuring yaml language to 2 spaces indentation.

53

it works, thank you :wink:

1 Like
54

Hi!

I have tried every (for me) concievable way to make HA or Node Red pick up on KNX telegrams sent to GA 0/1/34. The telegrams are routed to Home Assistant, but not decoded because of an error:

2020-12-08 23:02:25 ERROR (MainThread) [xknx.log] Error while processing telegram <CouldNotParseTelegram description="payload invalid" device_name="Good morning" feature_name="State" group_address="0/1/34" payload="<DPTArray value="[0x0]" />"/>

This error, I believe, is due to the binary_sensor not able to make sense out of the telegram payload. The KNX telegram is sent to the bus from a button (not a switch), in order to tell my old fashioned touchscreen to turn on some lights (the scene is stored in the touch screen, and not in the individual actuators or switches).

After some trying and failing, I have been able to send the correct telegram to the bus by using the KNX send service (through Node Red): {“address”: “0/1/34”, “payload”: “00”, “type”: “1byte_unsigned”}, but I am not able to pick up the telegram when it originates from the bus, and hence not make HA act on it.

I do not have access to ETS (yet), but I got some PDF files (group address report from ETS) from the electrician saying the telegram in question is datatype “1 byte”.

Any suggestions on how to set up Home Assistant or Node Red to act on this telegram?

55

Hi Lars,
you are right. The DPT that is implicitly assumed for a HA binary switch does not match the DPT of your telegrams. Try a sensor instead and set its DPT to 5.010:

knx:
  sensor:
    - name: Good Morning
      state_address: '0/1/34'
      type: '1byte_unsigned'

You may also want to try DPT 17.001 (type: 'scene_number') which is probably what your KNX touchscreen is actually trying to communicate.

2 Likes
56

Thanks a lot for your support. Both sensors (1byte_unsigned and scene_number) are able to correctly decode the telegram payload. (The sensor type ‘scene_number’ seems to be adding +1 to the KNX payload. KNX scene number 0 is identified as scene 1 etc., but that is not a problem). I also noticed I actually have two scenes using the same GA. Nice. But, unofrtunately, my problem still persists:

The sensor state doesnt change when the same scene is activated twice in a row, and HA is then not able to pick up the second scene initiation (since the sensor state didnt change). I worked around this issue for KNX scene 0 on GA 0/1/35 (the only scene number on this GA), made possible by the binary sensor being able to decode the telegram:

  binary_sensor:
   - name: "all_lights_off"
      state_address: '0/1/35'
      sync_state: false
      reset_after: 5
      invert: true

Perhaps it is possible to reset the sensor the same way as a binary_sensor, or maybe other ways of solving this?

57

Have you tried to use always_callback = True with your sensor? (I think you’ll need 1.0.0 beta for this).
You can also try to add an automation to set the scene sensor to eg. 0 (when using type: scene_number you will never receive 0) after reception of another value.
Otherwise you can use a knx_event when you set fire_event = True in knx: and define a frie_event_filter: []

PS binary_sensor is not able to decode the scene telegram. Scene 1 (in knx scene enumeration begins with 1 but their logical payload begins with 0 -> scene_number-1) is treated like an “False” binary telegram because the evaluated payload is all 0. the “real” scene payload comes in the next byte and not looked at here. When the knx library one day checks the payload size (how many bits were received) this will not work anymore.

2 Likes
58

To be honest these are the reasons why I use KNX Ultimate in parallel with the HA KNX integration. Nearly all of my automations are based on Node RED anyway. So in such cases I simply create an Ultimate node that listens to the GA and fires a NR message with each telegram. I then process the payload (if needed) and write the result into some HA entity through a call service node. For scenes I would probably use an input_select - or even an input_binary if there is only one scene number.
Don’t get me wrong though: I would always insist on using the native HA KNX integration whenever it results in a HA entity that can also write back state changes to KNX. This way you get a bidirectional coupling between the KNX GA and the HA entity.
But this is not possible in your cases as HA sensors can never be changed through call_service calls, Lovelace buttons or the like. They are kind of read only entities. So you cannot change the sensor in HA to change your scene number in KNX.
An input_select or input_boolean can be changed. But please be aware that you will have to establish any backward communication of these changes to KNX by yourself. So you will have to create a second
NR flow that is triggered on state changes of your input_X entity and that sends back to the KNX GA.
Read my posting about message loops further up this thread before you try to do that. ;o)
Welcome to the scary world of manual syncing between HA and KNX. Shields up. Node red alert.

1 Like
59

You could “knx: expose” the input_select state, couldn’t you?

1 Like
60

Hi Matthias,

yes, sure, that’s definitely an option. And I use it for the way from HA to KNX. I am really using a wild mix of HA KNX and KNX Ultimate in Node RED. And it really never created any problems beside the fact that message loops can happen. But I mostly fight with these when yet another external system has to be coupled - like KNX to HA to Zigbee - and I want to sync them all in all directions.

While we are at it: Could you please tell me how HA itself does avoid message loops? I mean, if you receive a KNX telegram in your integration and change the state of - let’s say - a HA KNX switch, how does HA make sure that this change is not sent back again to KNX and creates an infinite loop? Is it the responsibility of each integration to block that? Or is there a generic mechanism in HA that prevents such loops? Could this mechanism be exploited somehow from NR?