KNX Cookbook (legacy)

The KNX Cookbook has moved to the Community Guide section.
Please continue any discussions there:



very good work and thanks for your efford!
In a thread Exposing a boolean… you already mentioned a workaround for exposing bools to the bus.

But thats not very useful for what I need.
I have some fake knx group addresses, for home automation status transmissions. For example, a group address for device tracking/presence detection. If my home-assistant sees my mobile at home, it sends a “true” to that special group address. But if any component is asking for the status to that group address, no one is listening or answering, because of missing knx hardware attached to that group.
For that, I thougt the “knx-expose” config will solve this issue. Unfortunately not… because of missing bool support in the hass knx component.

Now I can workaround every switch with a bunch of automations. But thats not straight forward and will be very confusing with a lot of switches.

Any idea about that?

Hi @selfisch,
at the end of the Cookbook you find an appetizer for next topics to come. Of these the chapter “How to send flags, values and strings to the KNX bus” is exactly what you are looking for. It is about the KNX Send service, which allows you to send data to arbitrary KNX group addresses, that don’t need to be bound to any HA entities. Unfortunately the documentation is very thin on that service. The most important thing to know is that in most cases the payload has to be an array of integers. A percent value for example can be sent as [0] or [255]. A 14 byte string (e.g. for a notice text on a display) has to be sent as [65, 66, 67, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0] for the string “ABC”. In general, the number of ints in the array must match the byte count of the DPT type of the KNX group address that you want to write to. The only value type that I found that can be sent as a simple int (not an array) is a boolean, e.g. a 0 or 1 for the state of a switch. Hope that helps you get going until I find the time to write the next chapters.

Hi @Jpsy ,

great to hear! I see, you are much deeper in this topic and I have to learn a lot :-).
Thanks for your explenation of the values that can be send by the service. Documentation is very thin, you are right :-).

If you need any help in investigation or testing, let me know.
I will see, how anything with the KNX send service can be realized.


Thanks for your ideas!
I use some dummy adresses in ETS with the ETS Dummy DB:

You can then add non-existent group adresses in ETS which you can trigger in Home Assistant.

Anyway, I find the idea of not dimming lights, but setting to 0, 10, 50, 100% very interesting. How is that done in ETS? Does this only work with the MDT switches or might it work with Busch Jäger switches as well?

1 Like

Great work!
Is there some kind of feature to publish a heartbeat or something like that?
So when HA would go down or being updated, KNX can fallback to a default working (With some logic functions?).

1 Like

Hi Jens,
sorry for the late reply.

I have no heartbeat / watchdog in place, but to implement this I would use a “staircase lighting” function (“switch-off delay”) of a KNX actuator or a KNX logic component. This function block must be set to be re-triggerable, so the delay starts again if it receives another ON signal while it is still ON. If you trigger the group address of such a block with a cyclic HA automation time pattern trigger, then it will never fall back to OFF as long as HA lives and sends it signals. If HA stalls the KNX logic will fall back to OFF after the delay time, which will signal that HA is dead.

I recommend not to use such a watchdog to activate KNX functions only when HA fails. IMHO the better approach (the one I follow) is to make KNX as autonomous as possible, and then build HA functions on top of that, not replacing that. KNX is decentralized and rock solid. HA is a very potent companion to KNX but it will always be less reliable as it represents a complex single point of failure.
In all my home automations my goal is, that my house stays usable without HA. If I can build a function in KNX then I do so, even if it would be simpler in HA.
HA is my “higher brain function” for really complex stuff that I could live without, if it dies. It is also my interface between KNX and all other technologies. It is not a replacement for things that can be done in KNX itself.


Hi Tippfeler,
also sorry for the very late reply:
Yes, I use MDT Glas Switches to send the 0 / 10 / 50 / 100% values and I am very happy with that solution. The MDT switch offers configs that will cycle through a given set of percent values (up to 4) with each touch of the switch. I do not know which other vendors provide that functionality.

Thanks for your reply!
I will look into your solution.

I do think that it is indeed the better way to make KNX as autonome as possible. However, i would like to use the push buttons in my house to be integrated with HA as well. My renovation is almost finished, and i will start programming my KNX/HA combination soon. I will try to give an update!

Thanks for your input!


Thanks for your documentation!

Is this still an issue? If so, have you filed an issue at ?

It seems like parts of your next chapters have already written itself :wink:

  # expose binary values
  - type: 'binary'
    entity_id: switch.my_switch
    address: '1/2/3'
  # expose strings
  - type: 'string'
    entity_id: my_string
    address: '1/2/4'
1 Like

Hi @farmio,

oh no, I have to thank YOU:
For all the work you have put into XKNX and the HA KNX integration recently!

My chapter about sending flags, values and strings to the KNX bus will focus more on explaining the KNX send service. I have written a bit about that already in my reply to @selfisch.

Oh and…

the issue with the inverted KNX covers is partly resolved, at least so far that I could removed it from the cookbook (and from my personal HA installation).

In fact I still see an inverted value in the current_position attribute of the cover entities (“100%” when state is “open” and “0%” when “closed”), but that does not affect the HA integration otherwise. Could it be, that this is a remnant of an older attempt to resolve the main inversion issue in XKNX?
I will file an issue report on that artifact soon.

I’ve recently added a description to the send service basically quoting your post :wink: I think of this service more like a debug tool. Sending values to the bus ExposeSensor is the way to go for me.

The last update to cover that could have changed things was in Mar 2018. I have no cover device myself so I can just take guesses here.

From the HA cover template the behaviour you are describing is correct (but seems counterintuitive for me too):

class CoverDevice(Entity):
    """Representation of a cover."""

    def current_cover_position(self):
        """Return current position of cover.
        None is unknown, 0 is closed, 100 is fully open.

I clearly see your point. Especially the fact that Expose is able to answer read requests on the KNX bus is far superior to the knx.send command (which sends only once).
My problem here is that I do most of my automations in Node Red. The Node Red add-on for HA so far has no way to write back values into HA sensors. But that would be needed to write to a sensor which is then exposed to KNX.
I think it would be possible to use an HA MQTT sensor and expose it to KNX. Node Red can send to MQTT. But that makes things complicated and bloated. The simple task of sending a value to a KNX group address would stretch from Node Red over MQTT into the HA config. This is clearly a limitation of the current Node Red add-on, not of the KNX integration. But for most of my purposes the knx.send service is just good enough. I mainly use it to update status GAs in KNX. For this there is rarely a need to support recurring read requests.

Oh yes, you are right. This clearly shows that the open–>100% association is by design. As you said it is quite counterintuitive. But I guess we can all live with that.

I don’t know Node Red, but isn’t there an implementation of knx especially for node red? So you wouldn’t have to convert to raw values by hand. Would be nice for floats…

Eh. This one:

Any idea why KNX lights etc don’t show up in “Entities” of HA?

@gagga: No. What exactly have you done so far? Did you check the log for errors in the KNX integration?

@farmio: Sorry for the late reply. Great hint. I am using KNX ultimate for some time now and it works like a charm. To be honest: The KNX integration of HA still has its problems with inversions of cover positions. E.g. Alexa (coupled through Nabu Casa) lifts the cover when you say “cover X on”, lowers the covers with “off” and inverts percentage positions.

I have just had a look at the cover topic. Its a little bit awkward because HA defines 0% as closed whereas in KNX 0% is open. So a fully enabled most right slider on the default lovelace card means cover open. I have no idea who came up with that :upside_down_face:

@Jpsy Why do you say “cover on” and “cover off” instead of “up/down”? Is this some Alexa specific thing or do you have some sort of special covers? Anyhow if HA interprets your “off” as 0% it does what it is supposed to do - its just unintuitive (at least for us, it seems).

I have no actual covers yet to test things so I can just look at logs. :female_detective: If you like you can test the PR / fork:

1 Like

I have a quick question : what exactly do I need to integrate with HA if I have 4 devices (air conditioning in my case) with knx adaptors. Is the knx - IP gateway all I need? Is there any good guide how to start from scratch with devices or if the box?

You will need a KNX IP gateway (or interface), a KNX bus power supply, KNX cable and connectors (black/red), the ETS software (the free demo version will work with up to 5 devices) and a Windows PC. Try YouTube for the basics.

1 Like