Sending Number items to KNX bus fails "None of the configured GAs on channel could handle the command"

Hello! I know there are older solved postings about this problem, but none of them have helped.

We are on openhab 3.4.3. The task is to create a rule to send a Number (percentage) to the KNX bus to be displayed on a KNX MDT glass button.

Sending strings works fine, sending datetimes works fine, reading numbers from the KNX bus works fine, but sending numbers (from a rule or from the openhab cli with openhab:send) leads to an error message in openhab.log like:

[DEBUG] [.internal.handler.DeviceThingHandler] - None of the configured GAs on channel ‘knx:device:bridge:Tasterwerte:WR_battery_soc’ could handle the command ‘26 %’ of type ‘QuantityType’


 Thing device Tasterwerte [] {
        Type number  : WR_battery_soc [ ga="5.001:5/3/0" ] 


Number:Dimensionless WR_battery_soc_fuer_Taster "Battery State of Charge (WR) [%d %%]"  <batterylevel> {channel="knx:device:bridge:Tasterwerte:WR_battery_soc"}


    var temp = WR_battery_soc.state as Number

What we have tried so far (all lead to the same error message; maybe with “the command ‘81 %’ of type ‘QuantityType’” or “the command ‘81’ of type ‘DecimalType’”, but the same underlying problem):

  • Changes to the rule: manually casting the value to DecimalType or QuantityType, adding .intValue or .floatValue, postUpdate instead of sendCommand
  • Changes to the item: Number:Dimensionless instead of Number, no label to avoid the %unit%
  • Changes to the thing: removing the 5.001, number-control instead of number

Finally, looking at the code that produces the error message. That is “handleCommand()” in

  withKNXType(channelUID, (selector, channelConfiguration) -> {
                        OutboundSpec commandSpec = selector.getCommandSpec(channelConfiguration, typeHelper, command);
                        // only send GroupValueWrite to KNX if GA is not blocked once
                        if (commandSpec != null
                                && !groupAddressesWriteBlockedOnce.remove(commandSpec.getGroupAddress())) {
                            if (isControl(channelUID)) {
                                rememberRespondingSpec(commandSpec, true);
                        } else {
                                    "None of the configured GAs on channel '{}' could handle the command '{}' of type '{}'",
                                    channelUID, command, command.getClass().getSimpleName());

→ and that doesn’t tell me anything. Why is

(commandSpec != null && !groupAddressesWriteBlockedOnce.remove(commandSpec.getGroupAddress()))

false and how can I change that?

Help please!

Try to use knx number-control istead number type.
And what sence to use the rule? As I understood WR_battery_soc.state is number. So you can directly send this value to knx.

Examples in bottom of this page KNX - Bindings | openHAB

Thank you for your reply

I already mentioned above that there is no difference between number and number-control.

The sense of the rule is usually to create the number from something? In this example with the battery charge it is true that I could also just link the thing to the two channels (that would be mqtt and knx in this case), because the value is not changed, but does not work. Also, there are other cases where I would like to send a number to the KNX bus. I can send Strings and Datetimes and ON/OFF, UP/DOWN commands from rules, but not numbers?

So I should have added above: The number does not arrive on the KNX bus, whether the thing is linked directly to the GA, or sent from a rule, or from the openhab-cli.

I had another idea and changed it the thing from number(-control) to dimmer(-control), because that is 5.001. Interestingly, that makes the error message disappear when the Item is defined as Number, but not when it is defined as Number:Dimensionless. But unfortunately even in the case without the error message, the value does not arrive at the GA on the bus.

There must be one small detail missing?

May be you try to send 81.0 instead 81 as 5.001 - integer number? Just in case, put DPT 9.001.

Also give screen of ETS setups. May be problem is here.

May be try to use GUI to seach the problem.
100% must work if you will connect mqtt buttery channel with number-control knx.
Like this (example for time control)

And don`t forget to put profile for knx channel to “Follow” to send event to knx bus

Cool idea. I hadn’t tried other DPTs. 9.001 or 9.007 unfortunately do not change anything.

That’s what I meant with .intValue or .floatValue above. We tried 80, 80.0 and 0.8 to mean 80%, but unfortunately, no.

ETS setup of 5/3/0:


The “68%” that can be seen in the screenshot was set by ETS.

This GA is connected to knx object (MDT screen)?

yes, exactly, the one connection is to the MDT device in this case.

Mmm, last idea try this from GUI interface setups.

That was another interesting idea, thank you.

Created a new Number Item and linked it to MQTT and KNX channels:

The value from MQTT arrives in the Item (98).

this is the MQTT channel

and this is the KNX channel

And then the error message in openhab.log:

[DEBUG] [.internal.handler.DeviceThingHandler] - None of the configured GAs on channel ‘knx:device:bridge:MDTTasterKueche:WR_battery_soc’ could handle the command ‘98’ of type ‘DecimalType’

Here need number-control.

We found a solution :partying_face:

Our solution is to use Dimmer for the percentage values, instead of Number or Number:Dimensionless. This is because the KNX binding uses Dimmer (and its cousin Rollershutter) for “a value between 1 and 100”, where 100 means full, top, all and 0 means empty, bottom, none.

The different types of KNX channels have different parameters (see KNX - Bindings | openHAB). Number and switch only have one called “ga”, whereas dimmer and rollershutter have many. One of them is position (a value between 0 and 100). All the parameters take group addresses as values, but they map to different DPTs. Position maps to DPT 5.001, whereas ga (of number) maps to 9.001.

This is the working configuration:

KNX channel is dimmer-control, and the key is position, not ga!:

Type dimmer-control  : WR_battery_soc    [ position="5.001:5/3/0" ]

Item is Dimmer:

Dimmer WR_battery_soc "Battery State of Charge (WR) [%d %%]" <batterylevel> (PV) {

This example connects one Item to two channels to transfer the value directly. It works just as well if the value is something calculated in a rule and sent with .sendCommand() to an Item connected to just one KNX channel.

There probably is an alternative solution where the Item is Number and the DPT is, but we didn’t investigate that because our KNX device (MDT glass display button) only accepts a reduced list of DPTs and no 9.xxxs. :clown_face:

During debugging, we got the error message “None of the configured GAs on channel ‘’ could handle the command ‘98’ of type ‘…’” for the types QuantityType, DecimalType and PercentageType, and we were confused. But we probably just never had all the correct values configured at the same time. It is very hard to keep track of which changes are actually applied. Also, “after changing the DPT of already existing Channels, openHAB needs to be restarted for the changes to become effective.” (see KNX - Bindings | openHAB), which is very inconvenient. And our openhab is 99% file based configuration (started with OH 1), and trying things with the GUI can be very useful, but also conflicting and confusing. One strategy is to duplicate (and triplicate) all the settings with different variable names.

Thank you @Pavel for your suggestions and time!

1 Like

Yes, it needs to be number-control :+1:, but it would not be visible there on this screenshot.

It can be seen here on the channel:


(I do not like the GUI. I find it very confusing. I have been using openhab for many years since OH1, always linking KNX and other devices, I understand very well what Items, Things and Channels are, but this interface is not for me!)

I am glad to see that you solved the problem. But I want to check with number-control.

Type **number**-control  : WR_battery_soc    [ ga="5.001:5/3/0" ]

After some days I will have access to KNX instalation and will check.

I like text definition too. But in OH3 we have rather good GUI with code page. And now I use it for some autoscan options, good begins without start mistakes and comfortable copy-past in code page