Hi, a largely smooth transition for me so thanks to the team for continuing the great work, and best wishes for the festive season to everyone who celebrates it.
The only problem I’ve spotted is that the light level data from Aeon Multisensor 6 items (Z wave binding) appear to have remained unchanged ever since the update. Other channels (temperature, humidity, presence) are updating fine, but the light level has remained fixed for a couple of days. Anyone else got this, or any suggestions? Happy to post up any additional data if there’s specific information that will help. Update was from a 3.3.x copy, and I’m running on Windows 10.
Now that you mention it I have noticed that at least one of my NeoCoolcam PD03Z PIR sensors has stopped reporting luminance values. I’ve just deleted the thing and it’s linked items and recreated so will see if this has any affect.
Just to report a counter example: I updated to 3.4 yesterday and my fibaro_fgms001_00_000 continues to report changing motion, temperature, luminance and battery levels as expected.
I think this is related to the change in 3.4 for quantity types. I can see this in the log for the ZWave node I deleted and recreated a few minutes ago:
2022-12-23 14:39:50.873 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 87: Updating channel state zwave:device:c247fe7742:node87:sensor_luminance to 179 lx [QuantityType]
2022-12-23 14:42:51.129 [DEBUG] [col.commandclass.ZWaveMultiLevelSensorCommandClass] - NODE 87: Sensor Type = Luminance(3), Scale = 1
2022-12-23 14:42:51.129 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 87: Updating channel state zwave:device:c247fe7742:node87:sensor_luminance to 167 lx [QuantityType]
2022-12-23 14:45:51.922 [DEBUG] [col.commandclass.ZWaveMultiLevelSensorCommandClass] - NODE 87: Sensor Type = Luminance(3), Scale = 1
2022-12-23 14:45:51.923 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 87: Updating channel state zwave:device:c247fe7742:node87:sensor_luminance to 141 lx [QuantityType]
2022-12-23 14:48:52.525 [DEBUG] [col.commandclass.ZWaveMultiLevelSensorCommandClass] - NODE 87: Sensor Type = Luminance(3), Scale = 1
2022-12-23 14:48:52.525 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 87: Updating channel state zwave:device:c247fe7742:node87:sensor_luminance to 176 lx [QuantityType]
2022-12-23 14:51:53.541 [DEBUG] [col.commandclass.ZWaveMultiLevelSensorCommandClass] - NODE 87: Sensor Type = Luminance(3), Scale = 1
2022-12-23 14:51:53.542 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 87: Updating channel state zwave:device:c247fe7742:node87:sensor_luminance to 144 lx [QuantityType]
2022-12-23 14:54:54.067 [DEBUG] [col.commandclass.ZWaveMultiLevelSensorCommandClass] - NODE 87: Sensor Type = Luminance(3), Scale = 1
2022-12-23 14:54:54.067 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 87: Updating channel state zwave:device:c247fe7742:node87:sensor_luminance to 109 lx [QuantityType]
2022-12-23 14:57:55.103 [DEBUG] [col.commandclass.ZWaveMultiLevelSensorCommandClass] - NODE 87: Sensor Type = Luminance(3), Scale = 1
2022-12-23 14:57:55.103 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 87: Updating channel state zwave:device:c247fe7742:node87:sensor_luminance to 70 lx [QuantityType]
2022-12-23 15:00:56.103 [DEBUG] [col.commandclass.ZWaveMultiLevelSensorCommandClass] - NODE 87: Sensor Type = Luminance(3), Scale = 1
2022-12-23 15:00:56.103 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 87: Updating channel state zwave:device:c247fe7742:node87:sensor_luminance to 48 lx [QuantityType]
2022-12-23 15:06:58.081 [DEBUG] [col.commandclass.ZWaveMultiLevelSensorCommandClass] - NODE 87: Sensor Type = Luminance(3), Scale = 1
2022-12-23 15:06:58.081 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 87: Updating channel state zwave:device:c247fe7742:node87:sensor_luminance to 39 lx [QuantityType]
2022-12-23 15:09:59.062 [DEBUG] [col.commandclass.ZWaveMultiLevelSensorCommandClass] - NODE 87: Sensor Type = Luminance(3), Scale = 1
2022-12-23 15:09:59.062 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 87: Updating channel state zwave:device:c247fe7742:node87:sensor_luminance to 30 lx [QuantityType]
2022-12-23 15:22:02.392 [DEBUG] [col.commandclass.ZWaveMultiLevelSensorCommandClass] - NODE 87: Sensor Type = Luminance(3), Scale = 1
2022-12-23 15:22:02.392 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 87: Updating channel state zwave:device:c247fe7742:node87:sensor_luminance to 42 lx [QuantityType]
2022-12-23 15:31:05.767 [DEBUG] [col.commandclass.ZWaveMultiLevelSensorCommandClass] - NODE 87: Sensor Type = Luminance(3), Scale = 1
2022-12-23 15:31:05.767 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 87: Updating channel state zwave:device:c247fe7742:node87:sensor_luminance to 27 lx [QuantityType]
2022-12-23 15:37:07.664 [DEBUG] [col.commandclass.ZWaveMultiLevelSensorCommandClass] - NODE 87: Sensor Type = Luminance(3), Scale = 1
2022-12-23 15:37:07.664 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 87: Updating channel state zwave:device:c247fe7742:node87:sensor_luminance to 16 lx [QuantityType]
2022-12-23 15:52:28.108 [DEBUG] [col.commandclass.ZWaveMultiLevelSensorCommandClass] - NODE 87: Sensor Type = Luminance(3), Scale = 1
2022-12-23 15:52:28.108 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 87: Updating channel state zwave:device:c247fe7742:node87:sensor_luminance to 5 lx [QuantityType]
The luminance values were being reported by the device, they just didn’t seem to make it through to the linked item.
The linked item that has just been recreated when I created the thing is a number item with no UoM:
However, another PIR (same make and model) that I haven’t deleted and recreated (so this is the item that was created in OH3.3) is a number with the UoM luminous intensity:
I need to do some more investigation into this and shine a torch at a couple of these PIRs but I thought I’d post this in case anyone has any suggestions on what diagnostics I can perform.
If QuantityType is posted to a plain Number item the unit is stripped and the value posted as plain number, as requested by the user that created a plain Number item.
Thanks for reminding me to use DEBUG mode. I could fix the issue on my own. So it looks like the new version is more precise.
The error was
2022-12-23 11:40:40.096 [ERROR] [jdbc.internal.JdbcPersistenceService] - bundle org.openhab.persistence.jdbc:3.4.0 (304)[org.openhab.persistence.jdbc.internal.JdbcPersistenceService(382)] : The activate method has thrown an exception
java.lang.IllegalArgumentException: 12 is not a valid item name
So I deleted the entry in the database table and it worked. However now my regular historic temperature update throws errors. I’ll double check the forum and maybe enable debug again to dig deeper. However, the strange thing is, the values are updated.
The errors are:
[WARN ] [jdbc.internal.JdbcPersistenceService] - JDBC::query: Unable to query item
org.openhab.persistence.jdbc.internal.exceptions.JdbcSQLException: Error in SQL query!!!; HOUR_OF_DAY: 2 -> 3 Query: SELECT time, value FROM Item328 WHERE TIME>='2021-12-23 19:45:12' ORDER BY time ASC Parameters: []; Pool Name= yank-default; SQL= SELECT time, value FROM Item328 WHERE TIME>='2021-12-23 19:45:12' ORDER BY time ASC
It’s important to configure the same time-zone in the JDBC connection string as in openHAB. But I don’t think anything changed in 3.4 in this regard. See also:
I was still on RC1 (because I wasn’t brave enough so far to go the the final as I was working on the blockly jsscripting migration and didn’t want to change too many things at the same time) and now I updated to final 3.4.0 Release build.
I can now say that it at least happens much much less. Currently it is only affecting one out of four and it only “happens” around every two minutes (still annoying though(. The difference that I see is that the three stable ones are a google minis whereas the one that is flickering a bit, is a nest hub.
Even there is no obvious change (I checked the code and libs) it seems there is a transient dependency somewhere.
(note that this is not due to a restart because I had done that several times before)
I just upgraded to 3.4.0 but found several warning messages in the openhab.log file, such as:
2022-12-24 16:52:33.971 [WARN ] [d4j.internal.RRD4jPersistenceService] - Failed to open rrd4j database ‘Sunology_Voltage’ (java.lang.IllegalStateException)
…
2022-12-24 16:48:19.152 [WARN ] [core.thing.internal.ThingManagerImpl] - No config description for ‘channel-type:http:channel-config-number’ found when normalizing configuration for ‘http:url:69657263c9:46’. This is probably a bug.
2022-12-24 16:48:19.154 [WARN ] [core.thing.internal.ThingManagerImpl] - No config description for ‘channel-type:http:channel-config-number’ found when normalizing configuration for ‘http:url:69657263c9:T1_HCHP’. This is probably a bug.
2022-12-24 16:48:19.155 [WARN ] [core.thing.internal.ThingManagerImpl] - No config description for ‘channel-type:http:channel-config-number’ found when normalizing configuration for ‘http:url:69657263c9:T1_PAPP’. This is probably a bug.
…
2022-12-24 16:48:42.329 [WARN ] [core.audio.internal.AudioManagerImpl] - Failed playing audio stream ‘org.openhab.core.audio.FileAudioStream@7e05af3f’ as no audio sink was found.