Convertion Rule doesn't send KNX Updates

[mobil750 (Helmut Richter)]

I have a fresh installation of OH3 and did all configurations via UI only.

Now I want to forward 1-wire temperature measurements to KNX bus which works well in OH2.5.

OH3 seem to work when looking into the logs but on KNX bus nothing is sent - checked with ETS Group Monitor.

Here my Configurations:

KNX/IP Gateway Config

UID: knx:ip:ccc7b32f9f
label: KNX/IP Gateway
thingTypeUID: knx:ip
configuration:
  useNAT: false
  readRetriesLimit: 3
  ipAddress: 192.168.1.215
  localIp: 192.168.1.230
  autoReconnectPeriod: 60
  type: TUNNEL
  localSourceAddr: 0.0.0
  readingPause: 50
  portNumber: 3671
  responseTimeout: 10
location: KG Flur HKV

KNX Thing

UID: knx:device:ccc7b32f9f:e5ae86ee1e
label: KNX Device Garten Temperatur
thingTypeUID: knx:device
configuration:
  pingInterval: 600
  readInterval: 0
  fetch: false
bridgeUID: knx:ip:ccc7b32f9f
location: Garten
channels:
  - id: CH_GA_Schotter_Temperatur
    channelTypeUID: knx:number
    label: CH GA Schotter Temperatur
    description: ""
    configuration:
      ga: 7/0/220+<7/0/220

Onewire Thing

UID: onewire:basic:ecee5f7fea:28_FFBCFD721604
label: Temperature Sensor Garten (28.FFBCFD721604)
thingTypeUID: onewire:basic
configuration:
  refresh: 300
  id: /28.FFBCFD721604
bridgeUID: onewire:owserver:ecee5f7fea
location: Garten

Rule Code:

rule "Garten Temperatur"
when
    Item OW_Item_Garten_Temperatur received update
then
    logInfo("Garten Temperatur", "OW_Item_Garten_Temperatur = " + OW_Item_Garten_Temperatur.state)
    KNX_Item_Garten_Temperatur.sendCommand((OW_Item_Garten_Temperatur.state as Number).floatValue)
end

Screenshot of Log file

Other rules activating/deactivating KNX devices work as expected.
I have no clue what’s wrong here and hope on help.

Thanks
Helmut

[J-N-K (Jan N. Klug)]

The openHAB version of the KNX binding does not support sending values with units. It‘s a bug or a missing feature, depending on your POV.

[mobil750 (Helmut Richter)]

Does that mean that I cannot sent temperature updates at all?

[Udo_Hartmann]

No. In fact, you did it the right way (i.e. to remove the unit with (state as Number).floatValue)

But:

1. Why setting up the same GA twice? NEVER do this!
2. Why setting up the GA as readable? (i.e. <)
3. What’s the DPT of the corresponding CO?

Please be aware that it’s more common to setup a control channel (that is, openHAB is proxy of the sensor. Usually openHAB receives states from knx and sends commands. When using a control channel, it’s the other way around, openHAB sends the status (e.g. temperature measurement) to knx and receives commands (you can use this to control another actuator like a HUE lamp directly from a knx wall switch)

[mobil750 (Helmut Richter)]

Thanks a lot for the reply but your answers cause some questions regarding the cooperation of OH3 and KNX. Please refer to the inline comments / questions.
My feeling is there is a (big) difference between OH2.5 and OH3.x

| Udo_Hartmann
September 6 |

• | - |

No. In fact, you did it the right way (i.e. to remove the unit with (state as Number).floatValue)

I got it working now by changing the Item type from „Number:Temperature“ to „Number“.
But this is not really straight forward from my point of view especially when it causes to avoid actions like sending commands without any hint in the logs.
I think it is reasonable to define an Item as precise as possible.

But:

1. Why setting up the same GA twice? NEVER do this!

OK, in this case it is wrong and should be „<7/0/220“. I will change it.

1. Why setting up the GA as readable? (i.e. <)

In this case it is a conversion via rule of an 1-wire temperature value to a KNX state which is only updated when the 1-wire item changes.
KNX devices sometime request the status of a device (e.g. startup of a new device) and can be programmed to fetch the current state. Same for ETS or other KNX scripts to retrieve a value on demand and not waiting for an active update.
I have other Things (e.g. a KNX switch defined with 1.001:1/0/100+<1/2/100) which show the correct switch state only after toggling the switch instead of checking the provided status GA (1/2/100).
Same for the configuration via Main UI. For some of the Items the current state is shown, for other - defined in the same way but maybe another room - show NULL. Checking the state via KNX bus requests the correct state is replied. I expect that the current state is retrieved whenever an element is used in the UI, because of the given readable GA <X/Y/Z.

I have still an OH2.5 system which behaves here different - better …

1. What’s the DPT of the corresponding CO?

It is a temperature - DPT 9.001.
For me it was complete unclear whether it makes sense to provide the DPT. The documentation says it is optional. Sometime I had the feeling that removing the DPT helped to get the current state in the UI.

BTW, is still correct that when changing / adding / removing the DPT OH3 has to be completely restarted?!?
Excerpt from KNX Binding documentation:
„Note: After changing the DPT of already existing Channels, openHAB needs to be restarted for the changes to become effective."

[Udo_Hartmann]

@mobil750

I got it working now by changing the Item type from „Number:Temperature“ to „Number“.

knx can’t use UoM (yet) so you can’t link UoM Items to knx Channels.

@mobil750

In this case it is a conversion via rule of an 1-wire temperature value to a KNX state which is only updated when the 1-wire item changes.

So you must not read the state from knx at all.
Please only request GA which are marked readable in ETS - and please keep in mind, that a readable GA must be readable exactly in one CO linked to that GA. And it has to be the main GA (i.e. the first GA on that particular CO)

@mobil750

I have other Things (e.g. a KNX switch defined with 1.001:1/0/100+<1/2/100) which show the correct switch state only after toggling the switch instead of checking the provided status GA (1/2/100).

Well, maybe some read requests are messed up. Check openhab.log

@mobil750

It is a temperature - DPT 9.001.

So that’s default DPT for number channel. That’s the point…
I’m not sure about the need of restart. It’s possible to pause (and so restart) Things.
And when it comes to OH2, it’s possible to restart only the binding in question, no need for a complete restart.

[mobil750 (Helmut Richter)]

Thanks again, but on one point I can’t agree because of the KNX logic with it’s status CO’s.

You wrote:
„So you must not read the state from knx at all.
That means a KNX device can’t update e.g. a temperature display on demand but has to wait for an update by the sourcing (e.g. 1-wire) system - correct? I’m not sure whether this is acceptable for all cases especially for KNX sources with sporadic data updates.

Please only request GA which are marked readable in ETS - and please keep in mind, that a readable GA must be readable exactly in one CO linked to that GA. And it has to be the main GA (i.e. the first GA on that particular CO)"

I can’t agree to the last sentence. KNX switches for example have 2 channels, the actor channel to toggle the switch and the correspondent status channel which give the real state of the switch. That means the second GA has to be the readable status GA - correct?
If it is so as you wrote I see no sense to have several GA’s for a channel at all.

[Udo_Hartmann]

@mobil750

That means a KNX device can’t update e.g. a temperature display on demand but has to wait for an update by the sourcing (e.g. 1-wire) system - correct? I’m not sure whether this is acceptable for all cases especially for KNX sources with sporadic data updates.

No. The whole point is, you have to use number-control as Channel Type. That way openHAB is the sensor (from perspective of a knx device). The knx device can send a read request and openHAB will answer.
Please be aware that < is only to mark a GA as readable for openHAB, not for other knx devices. It’s not the R-Flag, readable (L in german for lesbar) The meaning of < is “This GA has a CO with the R-flag set.”

@mobil750

I can’t agree to the last sentence. KNX switches for example have 2 channels, the actor channel to toggle the switch and the correspondent status channel which give the real state of the switch. That means the second GA has to be the readable status GA - correct?

Yes, but the switch isn’t the device which will answer the read request, but it’s the actuator. And the actuator has a CO for the status.
A knx device does only send on the first GA set to the CO.

[mobil750 (Helmut Richter)]

Thanks for further clarifications.

I got it now. For the last part, I used the wrong word „switch“ but meant the actor.

[mobil750 (Helmut Richter)]

Sorry, I have to come back to this topic.

The issue regarding sending numbers and the linkage between 1-wire and KNX is solved and works perfectly now.

I have still issues with the simple KNX actors switching e.g. a power outlet.

Here an example of a Thing definition:

UID: knx:device:ccc7b32f9f:6f8124feaf
label: KNX Device KG Hobbyraum Steckdosen
thingTypeUID: knx:device
configuration:
  pingInterval: 600
  readInterval: 0
  fetch: false
bridgeUID: knx:ip:ccc7b32f9f
location: Hobbyraum
channels:
  - id: CH_KG_Hobbyraum_steckdosen
    channelTypeUID: knx:switch
    label: CH KG Hobbyraum Steckdosen
    description: ""
    configuration:
      ga: 1.001:1/0/40+<1/2/40

from my understanding it is compliant to the documentation (which only shows a text based example) and I expect that when saving that Thing and linking an Item to it, the binding will read the current status on KNX bus using the GA <1/2/40 and updating the status in the MainUI when the corresponding GroupValueWrite is received. But this doesn’t happen. The status is remains “NULL” until I toggle the actor via HW KNX switch or via the UI (eg. openHab App on my mobile) or the KNX device sends it periodically by itself.
In OH2.x I’m pretty sure, the states have been updated whenever the KNX thing or item file has been rewritten.

Is my understanding totally wrong here?

As I see it via the KNX Group Monitor on the bus, OH3 isn’t retrieving the states from the Items.

Sorry for bothering …

[Udo_Hartmann]

Is GA 1/2/40 linked to a CO which has R-Flag set?

In fact, openHAB does send a read Request only if starting up. I’m not sure if refreshing a Thing (or maybe unpause the thing) is sufficient.

EDIT: Seems to be sufficient to pause/upause.

[mobil750 (Helmut Richter)]

Yes the GA 1/2/40 is definitely linked to a single CO with the R-Flag set.

I made another experience. For me it seems that only the Standard DPT shown in the OH KNX documentation are supported. Using non-supported once cause OH3 to ignore all bus events.

I have a presence detector (with additional Alarm channel) which I programmed with „DPT 1.011 and GA 2/0/5“ and a periodic firing of 20s. In OH3 I defined a channel with „1.011:<2/0/5“.
The sensor fired periodically „Inactive“ but the OH3.1 UI showed constantly „Active“. After changing the OH3 channel to „<2/0/5“ and disabling / re-enabling the Thing the Items state changed to „Inactive".

Re-enabling does not trigger a GroupValueRead on the KNX bus to get the current state, the item is waiting for a corresponding message on the bus.
Wouldn’t it be reasonable to make a GroupValueRead for each Main-UI newly defined or changed Things channel?

Comparing OH2.5 and OH3 there is a (big) difference of the KNX behavior.
Adding a new sensor in OH2.5 with „Type switch : alarm_KGAR “Alarm” [ ga="1.011:<2/3/5“]“ seem to have no problem with non-standard DPT’s.