OpenHAB3 KNX dimmer item

Hi Guys,

This week i decided to upgrade my running installation based on 2.5 -> 3. Everything went smooth and I must say, what a great improvements so far!

I’m currently struggling with one thing being a KNX dimmer.

Below is my channel configuration:

  - id: Kantoor_licht_spots
    channelTypeUID: knx:dimmer
    label: Kantoor licht spots
    description: Kantoor licht spots
      increaseDecrease: 2/3/15
      position: 5.001:2/3/0+2/3/28
      switch: 1.001:2/3/29+2/3/30
  • I double checked the GA’s and can confirm these are correct
  • Yes 2/3/0 is indeed somewhat strange but that is correct in regard to my ETS configuration
  • Also i tested using ETS sending values to these addresses and indeed it is working
  • I have 55 dimmers in my configuration which are all not working
  • Worth mentioning is that my rollershutters (almost dimmers) are working perfectly
  • If I configure a switch item on the same channel, it does work

Furthermore I started some KNX logging which is completely clean, except for these messages once in a while, but timingwise not related to toggling the dimmer in OpenHAB:

2021-01-06 20:14:53.341 [DEBUG] [g.knx.internal.dpt.KNXCoreTypeMapper] - toType: KNX DPT_Control_Dimming: break received.

I’m starting to think that I might hit a bug…
Or can someone point me in the right direction?

Hi Calculator,

In my channel configuration I placed a “<” in the GA’s.

  • id: SalontafelDimmer
    channelTypeUID: knx:dimmer
    label: Salontafel Dimmer
    description: null
    increaseDecrease: 0/0/12
    position: 5.001:0/0/13+<0/0/13
    switch: 1.001:0/0/11+<0/0/11

HI Richard,

Thank four your suggestion! I changed it without success.
That notation i’ve used in the past indeed to get a status of a GA.

I removed the channel and the item, then removed all measurements from InfluxDB while i found that there was an INT value stored for the dimming value instead of float. (don’t ask me how it came there, but it must be me misusing the OpenHAB3 GUI)
Then after removing these values i recreated the channel and setup the item, and it started working.

I’m trying to reproduce the issue to see if it was me doing weird stuff, or there maybe is an issue in some dark corner… The main question is, how is that INT value stored?

Furthermore i captured this when OpenHAB restarted:

2021-01-08 08:21:13.360 [ERROR] [org.influxdb.impl.BatchProcessor    ] - Batch could not be sent. Data will be lost
org.influxdb.InfluxDBException$FieldTypeConflictException: field type conflict: input field "value" on measurement "KNXgenericdevice_Kantoorlichtspots" is type float, already exists as type integer
       at org.influxdb.InfluxDBException.buildExceptionFromErrorMessage( ~[bundleFile:?]
       at org.influxdb.InfluxDBException.buildExceptionForErrorState( ~[bundleFile:?]
       at org.influxdb.impl.InfluxDBImpl.execute( ~[bundleFile:?]
       at org.influxdb.impl.InfluxDBImpl.write( ~[bundleFile:?]
       at org.influxdb.impl.OneShotBatchWriter.write( ~[bundleFile:?]
       at org.influxdb.impl.BatchProcessor.write( [bundleFile:?]
       at org.influxdb.impl.BatchProcessor$ [bundleFile:?]
       at java.util.concurrent.Executors$ [?:?]
       at [?:?]
       at java.util.concurrent.ScheduledThreadPoolExecutor$ [?:?]
       at java.util.concurrent.ThreadPoolExecutor.runWorker( [?:?]
       at java.util.concurrent.ThreadPoolExecutor$ [?:?]
       at [?:?]

The most logical explanation to me is that i first created the channel, then created an item (switch), toggled the value of the switch, which triggered an update of 1 (INT) to de influxDB. That being said it could have blocked updates to the KNX bus in a later stage when i reconfigured the item as a dimmer.
While doing a value update it might first try to update the internal persistanceDB before sending out to the bus to prevent differences in states on bus and openHAB DB.

Any ideas someone?

I just found this issue which sounds related although in my case it’s KNX instead of homematic: