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(InfluxDBException.java:144) ~[bundleFile:?]
at org.influxdb.InfluxDBException.buildExceptionForErrorState(InfluxDBException.java:173) ~[bundleFile:?]
at org.influxdb.impl.InfluxDBImpl.execute(InfluxDBImpl.java:827) ~[bundleFile:?]
at org.influxdb.impl.InfluxDBImpl.write(InfluxDBImpl.java:460) ~[bundleFile:?]
at org.influxdb.impl.OneShotBatchWriter.write(OneShotBatchWriter.java:22) ~[bundleFile:?]
at org.influxdb.impl.BatchProcessor.write(BatchProcessor.java:340) [bundleFile:?]
at org.influxdb.impl.BatchProcessor$1.run(BatchProcessor.java:287) [bundleFile:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
at java.lang.Thread.run(Thread.java:834) [?:?]
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: