openHAB 3.4 Release discussion

[higgers (Steve Higton)]

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.

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

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.

[Matthias_Kaufmann (Matthias)]

I realized an issue with shelly 2.5 as rollershutter with unchanged code, see here

[MrNight (Stefan)]

Hi Jacob,

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

[laursen (Jacob Laursen)]

@MrNight

So I deleted the entry in the database table and it worked.

I’ll have a look at this, having a single invalid item name shouldn’t prevent the service from working.

However now my regular historic temperature update throws errors. I’ll double check the forum and maybe enable debug again to dig deeper.

With debug logs there might be some more information. What are the column types for table Item328, and the corresponding item type?

You could also have a look at:

JDBC - Persistence Services

There are now some tools which can help pinpoint issues, namely jdbc tables list and jdbc schema check.

[MrNight (Stefan)]

time is “timestamp PK”
value is “double”

But I just spoted there might be timzone error. As in other JDBC post, outside of openHAB, the same error message comes up.

[laursen (Jacob Laursen)]

@MrNight

But I just spoted there might be timzone error. As in other JDBC post, outside of openHAB, the same error message comes up.

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:

[jdbc] Charts don't show the correct dates/times because persistence doesn't check with the right timezeone

[JimT (jimtng)]

@stefan.hoehn

the chromecast binding has become pretty flickering in that the device go offline / online every other 10sec (which is the refresh rate).

I’ve noticed this too. It happens only on one of my Chromecast devices.

[stefan.hoehn (Stefan Höhn)]

Thanks, Jim, that means it is not specific to my setup only.

Unfortunately that seemed to be the case in the beginning here as well, in the meantime all devices have that problem

[laursen (Jacob Laursen)]

@MrNight

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

Fix for that:

[jdbc] Fix IllegalArgumentException on service activation

[Lolodomo]

@higgers

Now that you mention it I have noticed that at least one of my NeoCoolcam PD03Z PIR sensors has stopped reporting luminance values.

I checked and discovered the same issue with my 2 Fibaro devices! I assume it is again due to the recent changes about UoM!

Edit: after checking, my displayed values are in sync with the last changed values.

[MrNight (Stefan)]

Just for documentation purposes, the time zone wasn‘t set correctly for my MySQL container. Environment variable TZ.

[laursen (Jacob Laursen)]

@MrNight

Just for documentation purposes, the time zone wasn‘t set correctly for my MySQL container. Environment variable TZ.

After fixing this, is the JDBC persistence service working correctly for you?

[Lolodomo]

@stefan.hoehn

Since I upgraded to 3.4.0 (RC1) the chromecast binding has become pretty flickering in that the device go offline / online every other 10sec (which is the refresh rate).

Looks like there is an old issue opened about the chromecast things going OFFLINE:

[chromecast] Things go offline after a while

[stefan.hoehn (Stefan Höhn)]

I think I have some good news:

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)

[MrNight (Stefan)]

Yes, everything is working fine.

[gd35]

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.

Any ideas why I have such warning messages ?

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

Is this during the first startup or always? Do you have a very slow system?

[gd35]

These warning messages appeared when I started openhab (it was not the first start after the upgrade). I must said that I got several error messages when I started openhab 3.4.0 the first time. Openhab started twice without any intervention on my side. I used a docker container for openhab.

2022-12-24 16:48:19.131 [WARN ] [ty.util.ssl.SslContextFactory.config] - No Client EndPointIdentificationAlgorithm configured for Client@3b5a64ea[provider=null,keyStore=null,trustStore=null]
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.

And this one appeared several minutes after starting openhab. I also got this message for other items:

2022-12-24 16:52:33.971 [WARN ] [d4j.internal.RRD4jPersistenceService] - Failed to open rrd4j database ‘Sunology_Voltage’ (java.lang.IllegalStateException)

Openhab seems to run fine but I did not check everything…

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

I can’t comment on rrd4j, but the other issue is known and will be fixed by Fix ThingManager is missing config description during normalization by J-N-K · Pull Request #3191 · openhab/openhab-core · GitHub