Need help with Zennio KCI450

Hi guys,
i need some help with integrating the Zennio KCI450. As far as i understand i´ts a device for counting power consumption.

Here you can see the config in ETS (i didn´t do this on my own, it was installed when we bought the house).
I have other KNX devices running but this one won´t work. After crating the thing with appropriate adresses and channels, the items just show NULL.

Anybody here has experience with this one?
Search-function shows nothing useful ;(

Thank you!

First: I’m pretty sure it’s a Zennio KCI 4 S0 (see KCI 4 S0 KNX interface for Consumption Meters)

In question of the NULL problem, please be aware that CO 149 and 172 are both 4 Byte Type.

149 → DPT_ActiveEnergy (this is DPT 13.010)
172 → DPT_Value_Power (this is DPT 14.056) (But I’m pretty sure it’s also

As openHAB default DPT for Number is 9.001, you have to set the DPT explicitly. There may be only the Main DPT but not the Subnumber, the Subnumber is not important (at least at the moment :wink: ), so simply use 13.001 or 14.001

1 Like


Oh jea, you are right. Its a Zennio KCL 4 S0.

I think i did, what you supposed. When it comes to setting the DPT i am not sure.
Could you check my config?

UID: knx:device:c2762653aa
label: KNX Stromzähler
thingTypeUID: knx:device
  pingInterval: 10
  address: 1.1.4
  readInterval: 0
  fetch: true
bridgeUID: knx:ip:d49019977f
  - id: StromzaehlerHeizung
    channelTypeUID: knx:number
    label: Stromzähler Heizung
    description: ""
      ga: 13.001:3/1/0
  - id: Test2
    channelTypeUID: knx:number
    label: Test2
    description: ""
      ga: 13.010:3/1/0
  - id: Test3
    channelTypeUID: knx:number
    label: Test3
    description: ""
      ga: 14.056:3/1/1

Yes, should be correct. But keep in mind, that maybe the openHAB knx Binding is not aware of 14.056 or 13.010.

Please be aware that incomming GA should be exclusive. The binding is getting the incomming GA, does a quick search for a channel with this GA and does the status update. It never does a lookup for all channels with the GA! In other words: First channel found will receive the update, every other channel won’t.

Here, maybe the update goes to channel StromzaehlerHeizung OR to channel Test2, but it will never to to both channels.


Ah jea, at least i got one value now :wink: It tells me “21”… Which is half of 42, the ultimate answer to all questions. LOL :wink:

Anyway, on GA 14.001:3/1/1 i still get NULL.

So what may this 21 mean? As this should be a counter for the main heater, i was expecting a little bit more :wink: I think this device works in “clicks” per xxxx Watt. Maybe 21 means “21 clicks per xxx time”?
EDIT: I found a chart which started today. At one time the Value peaks up to almost 3000.

Does that mean, this may not work at all or do i have to change this value in ETS?

Thank you so much, Udo. Very much appreciated!

No, but it’s possible that you have to use 13.001 instead of 13.010 and 14.001 instead of 14.056.
The main DPT (part left from dot) is about the number format, is it a Bit, is it a Nibble, is it Word, is it Long, is it Float or Integer, signed or unsigned…
The sub part (right from the dot) is about the way, the data should be interpreted, i.e. is it UP/DOWN, ON/OFF, YES/NO, TRUE/FALSE… °C, °F, K, Air Temperature, Water Temperature, flow rate, … it’s an (nearly) endless list (to take a closer look: - V02.02.01 from 2021)

So, openHAB does not need to know the exact Subnumber, but you can’t set the Main DPT without setting the Subnumber.
To get a current list of all supported DPT (Main and Sub), take a look at the source code: openhab-addons/ at main · openhab/openhab-addons · GitHub but please be aware that this file was updated recently.
As I already did a lookup, both type 13.010 and 14.056 are known DPT. So, as you still get null for 3/1/1, please also try DPT 13.010. Both 13 and 14 are 4-Byte and the manual states DPT_Value_Power, which is DPT14.056, but as number format it states
unsigned Counter value, where DPT14 is Signed Float. (see knx document…)
I’m pretty sure that Zennio has an issue :slight_smile: here.