KNX and Intesis air conditioner

A company called Intesis offers plug-ins modules for well-known air conditioning systems for KNX coupling.

I´d like to have a scene selector menu for scenes “0”=Off, “1”=“Auto”. Both are configured in ETS5 and GA is available for set/get scene (7/0/4).

My setup is an openhab 2.5.2 on Synology, I use the Panasonic type called PA-AC-KNX-1i and KNX 2.5.2 binding.

So far I have:

things file
Type number: A_EG_AZ_Aircon_setScene "Klima EG AZ Szene" [ga="7/0/4+<7/0/4"]

items file
Number A_EG_AZ_Aircon_setScene "Klima EG AZ Szene" (Klima_EGAZ) { channel="knx:device:tunnel1:AirCon:A_EG_AZ_Aircon_setScene"}

sitemap file
Selection item=A_EG_AZ_Aircon_setScene mappings=[0="off", 1="Auto"]

I can switch on scene 0 or 1 by using ETS5/diagnosis and send the GA the scene. Also, I get back the current scene by sending GA 7/0/4.

The scene selector

  • chosing a scene has no effect, ETS5 diagnosis received nothing. The events.log has entries like
    2020-08-04 12:55:29.358 [nt.ItemStatePredictedEvent] - A_EG_AZ_Aircon_setScene predicted to become 0
    2020-08-04 12:55:29.384 [vent.ItemStateChangedEvent] - A_EG_AZ_Aircon_setScene changed from 1 to 0

  • doesn’t receive the currently selected scene

  • The events.log file seems to receive no events.

Any idea?

Please don‘t set the ga twice. Set the number channel to the appropriate DPT. So use

Type number: A_EG_AZ_Aircon_setScene "Klima EG AZ Szene" [ga="17.001:<7/0/4"]


Thanks for the advice, Udo.
So there is at least another issue, I switched on debugging and there is an odd entry after editing like you proposed:

18:26:11.429 [DEBUG] [x.internal.handler.DeviceThingHandler] - None of the configured GAs on channel 'knx:device:tunnel1:AirCon:A_EG_AZ_Aircon_setScene' could handle the command '1' of type 'DecimalType'

Seems to be related to

Intesis wants to make use of DPT 18.001

I cleared the cache, tried to use a different DPT mentioned in another post, worked.
Type number: A_EG_AZ_Aircon_setScene "Klima EG AZ Szene" [ga="5.005:<7/0/4"]

Now I hope, it will work.

Two things i have on my mind:

  • Would it be an idea to send log messages like this with a more user-friendly content like “this DPT is not supported or so”?

  • I stumble upon the clearing cache thing from time to time and spent hours on wasting time, just to realize the cache needs to be emptied. The issue is that it´s not predictable, when it´s the right point of time forme. How about clearing the cache automatically on every startup? In my eyes all current devices are fast enough to cope with a few seconds of delay.

No, it‘s definitely 17.001 or 18.001, not 5.005! 17.001 -> 0 to 63 (i.e. 1 to 64 in ETS!!!)
18.001 -> 0 to 63, but the MSB is read (0) or write (1)

As you won‘t store scenes from openHAB (or at least it‘s inconvenient and not well supported) it‘s very likely that 17.001 will suffice.

17.001 is fine for sending a scene. Getting back the status of the current scene does not work.

Here are all config files I consider to be useful. Maybe it´s just a typo somewhere?

Openhab 2.5.2

items file
Number A_EG_AZ_Aircon_setScene "Klima EG AZ Szene" Klima_EGAZ) {channel="knx:device:tunnel1:AirCon:A_EG_AZ_Aircon_setScene"}

sitemap file
Selection item=A_EG_AZ_Aircon_setScene mappings=[0="Off",1="Auto"]

things file
Thing device AirCon "Klimaanlage" [readInterval=5] {Type number: A_EG_AZ_Aircon_setScene "Klima EG AZ Szene" [ ga="17.001:<7/0/4"]}

openhab.log, debug mode (happens every 3 seconds)
2020-08-07 14:36:29.958 [DEBUG] [.internal.handler.DeviceThingHandler] - onGroupWrite Thing 'knx:device:tunnel1:AirCon' received a GroupValueWrite telegram from '1.1.19' for destination '7/0/4'!

The parameters

The group address

The openhab output

No, you simply can’t read a szene, there is no actuator which will answer the read request. But if I press the scene wall switch, openHAB gets the new scene number.

In ETS5 asking the device for the current scene works, so I took the assumption that it also worked in OH. But that´s ok :slight_smile:

Then that‘s a wrong behaviour of ETS5. No device should be configured to answer read requests to a scene GA. The point is, you can configure more than one device to react to a scene GA (that‘s the whole point of scenes). But how should a device know, if every device is unchanged after the last scene call? So there is absolutely no way to determine if a scene is still active. Scene is „fire and forget“. Of course you can create rules to check all members of a scene if they got a command, but that will make it much more complex, and to be honest, it would be much easier to use openHAB to send a Scene „manually“ and check for changes.