openHAB 4.3 Release Discussion

lsiepel · December 21, 2024, 3:33pm

Did you stop openHAB, as it seems to stop quick without a clear reason. While the log shows some issues. It is not clear to me why it quits.
Please create a seperate topic to further troubleshoot.

lsiepel · December 21, 2024, 3:38pm

If you want stable releases it will be OH5 (summer 25). If you can’t wait you have to re-create the items or switch to oh5 milestone releases and wait for the next one.

HenMus · December 21, 2024, 3:59pm

Sorry Sorry. I made a mistake in the yml file for creating the docker image. I was pointing to a non existing directory. It is working perfect!
I will check the new features soon.
Thanks.

mstormi · December 21, 2024, 9:46pm

The next release by definition will be OH5, so no.
New code will become part of the snapshots when devs find the time to work on it.

Lolodomo · December 21, 2024, 9:55pm

As usual, there will be regular 4.3 patches until 5.0 is released but patches only fixes (serious) bugs and do not add new features.

jimtng · December 22, 2024, 2:05am

A fix for the profile selection when adding a link is here:

PR - currently looking for testers, so if you could, please test the temporary jar below, and report back, and tag me @jimtng
A temporary JAR file/bundle for OH 4.3.0. The above PR / fix, if accepted, will be backported to the 4.3.1 release.

gravedigger · December 22, 2024, 2:42pm

Update went well without any issues. I fixed the getZonedDateTime topic and Logs are showing up as expected.
The only thing I am facing is that I have been using Regex “^(?!.*StringToHide).+” (without quotes) in frontail to hide logs of specific items. Is there any way in the new Log feature to get that done?
Thanks

rlkoshak · December 22, 2024, 6:04pm

There is a discussion and an issue open exploring how to add filters to the root osgi appender. I think the answer is tbd but being looked into.

Nicholas_Waterton · December 23, 2024, 8:17pm

I just upgraded to OpenHab 4.3, and I have found that MQTT cannot send commands reliably.

For example, this is a channel on my thing:

Type dimmer : kitchenPots                   "kitchen pots"                  [ commandTopic="/isy_command/kitchenPots", stateTopic="/isy_status/kitchenPots" ]

This is connected to a simple dimmer item.

I get these errors:

2024-12-23 14:32:45.937 [DEBUG] [nternal.profiles.ProfileCallbackImpl] - Delegating command '59' for item 'kitchenPots' to handler for channel 'mqtt:topic:insteon:kitchenPots'
2024-12-23 14:32:45.937 [DEBUG] [.internal.common.CombinedClassLoader] - Loaded class "org.openhab.core.thing.binding.ThingHandler" by classloader "org.eclipse.osgi.internal.loader.EquinoxClassLoader@6e96f620[org.openhab.core.thing:4.3.0(id=221)]" for "[interface org.openhab.core.thing.binding.ThingHandler]"
2024-12-23 14:32:45.937 [DEBUG] [.internal.common.CombinedClassLoader] - Loaded class "org.openhab.core.thing.ChannelUID" by classloader "org.eclipse.osgi.internal.loader.EquinoxClassLoader@6e96f620[org.openhab.core.thing:4.3.0(id=221)]" for "[interface org.openhab.core.thing.binding.ThingHandler]"
2024-12-23 14:32:45.938 [DEBUG] [.internal.common.CombinedClassLoader] - Loaded class "org.openhab.core.thing.Thing" by classloader "org.eclipse.osgi.internal.loader.EquinoxClassLoader@6e96f620[org.openhab.core.thing:4.3.0(id=221)]" for "[interface org.openhab.core.thing.binding.ThingHandler]"
2024-12-23 14:32:45.938 [DEBUG] [.internal.common.CombinedClassLoader] - Loaded class "org.openhab.core.thing.binding.ThingHandlerCallback" by classloader "org.eclipse.osgi.internal.loader.EquinoxClassLoader@6e96f620[org.openhab.core.thing:4.3.0(id=221)]" for "[interface org.openhab.core.thing.binding.ThingHandler]"
2024-12-23 14:32:45.938 [DEBUG] [.internal.common.CombinedClassLoader] - Loaded class "org.openhab.core.thing.ThingStatusInfo" by classloader "org.eclipse.osgi.internal.loader.EquinoxClassLoader@6e96f620[org.openhab.core.thing:4.3.0(id=221)]" for "[interface org.openhab.core.thing.binding.ThingHandler]"
2024-12-23 14:32:45.940 [DEBUG] [nternal.common.InvocationHandlerSync] - Already in a safe-call context, executing 'ThingHandler.handleCommand()' directly on 'org.openhab.binding.mqtt.generic.internal.handler.GenericMQTTThingHandler@4b898af5'.
2024-12-23 14:32:45.940 [ERROR] [nal.common.AbstractInvocationHandler] - An error occurred while calling method 'ThingHandler.handleCommand()' on 'org.openhab.binding.mqtt.generic.internal.handler.GenericMQTTThingHandler@4b898af5': class org.openhab.core.library.types.OnOffType cannot be cast to class org.openhab.core.library.types.PercentType (org.openhab.core.library.types.OnOffType and org.openhab.core.library.types.PercentType are in unnamed module of loader org.eclipse.osgi.internal.loader.EquinoxClassLoader @4b76e427)
java.lang.ClassCastException: class org.openhab.core.library.types.OnOffType cannot be cast to class org.openhab.core.library.types.PercentType (org.openhab.core.library.types.OnOffType and org.openhab.core.library.types.PercentType are in unnamed module of loader org.eclipse.osgi.internal.loader.EquinoxClassLoader @4b76e427)
        at org.openhab.binding.mqtt.generic.values.PercentageValue.parseCommand(PercentageValue.java:78) ~[?:?]
        at org.openhab.binding.mqtt.generic.ChannelState.publishValue(ChannelState.java:363) ~[?:?]
        at org.openhab.binding.mqtt.generic.AbstractMQTTThingHandler.handleCommand(AbstractMQTTThingHandler.java:154) ~[?:?]
        at jdk.internal.reflect.GeneratedMethodAccessor97.invoke(Unknown Source) ~[?:?]
        at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
        at java.lang.reflect.Method.invoke(Method.java:569) ~[?:?]
        at org.openhab.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:147) [bundleFile:?]
        at org.openhab.core.internal.common.InvocationHandlerSync.invoke(InvocationHandlerSync.java:59) [bundleFile:?]
        at jdk.proxy1706.$Proxy1843.handleCommand(Unknown Source) [?:?]
        at org.openhab.core.thing.internal.profiles.ProfileCallbackImpl.handleCommand(ProfileCallbackImpl.java:95) [bundleFile:?]
        at org.openhab.core.thing.internal.profiles.SystemDefaultProfile.onCommandFromItem(SystemDefaultProfile.java:49) [bundleFile:?]
        at jdk.internal.reflect.GeneratedMethodAccessor96.invoke(Unknown Source) ~[?:?]
        at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
--
2024-12-23 14:32:46.137 [DEBUG] [nternal.profiles.ProfileCallbackImpl] - Delegating command '55' for item 'kitchenPots' to handler for channel 'mqtt:topic:insteon:kitchenPots'
2024-12-23 14:32:46.137 [DEBUG] [.internal.common.CombinedClassLoader] - Loaded class "org.openhab.core.thing.binding.ThingHandler" by classloader "org.eclipse.osgi.internal.loader.EquinoxClassLoader@6e96f620[org.openhab.core.thing:4.3.0(id=221)]" for "[interface org.openhab.core.thing.binding.ThingHandler]"
2024-12-23 14:32:46.138 [DEBUG] [.internal.common.CombinedClassLoader] - Loaded class "org.openhab.core.thing.ChannelUID" by classloader "org.eclipse.osgi.internal.loader.EquinoxClassLoader@6e96f620[org.openhab.core.thing:4.3.0(id=221)]" for "[interface org.openhab.core.thing.binding.ThingHandler]"
2024-12-23 14:32:46.138 [DEBUG] [.internal.common.CombinedClassLoader] - Loaded class "org.openhab.core.thing.Thing" by classloader "org.eclipse.osgi.internal.loader.EquinoxClassLoader@6e96f620[org.openhab.core.thing:4.3.0(id=221)]" for "[interface org.openhab.core.thing.binding.ThingHandler]"
2024-12-23 14:32:46.138 [DEBUG] [.internal.common.CombinedClassLoader] - Loaded class "org.openhab.core.thing.binding.ThingHandlerCallback" by classloader "org.eclipse.osgi.internal.loader.EquinoxClassLoader@6e96f620[org.openhab.core.thing:4.3.0(id=221)]" for "[interface org.openhab.core.thing.binding.ThingHandler]"
2024-12-23 14:32:46.138 [DEBUG] [.internal.common.CombinedClassLoader] - Loaded class "org.openhab.core.thing.ThingStatusInfo" by classloader "org.eclipse.osgi.internal.loader.EquinoxClassLoader@6e96f620[org.openhab.core.thing:4.3.0(id=221)]" for "[interface org.openhab.core.thing.binding.ThingHandler]"
2024-12-23 14:32:46.140 [DEBUG] [nternal.common.InvocationHandlerSync] - Already in a safe-call context, executing 'ThingHandler.handleCommand()' directly on 'org.openhab.binding.mqtt.generic.internal.handler.GenericMQTTThingHandler@4b898af5'.

So, I tried removing the on and off values.

Type dimmer : kitchenPots                   "kitchen pots"                  [ commandTopic="/isy_command/kitchenPots", stateTopic="/isy_status/kitchenPots" ]

I can adjust it once or twice:

2024-12-23 14:54:32.408 [DEBUG] [nternal.profiles.ProfileCallbackImpl] - Delegating command '0' for item 'kitchenPots' to handler for channel 'mqtt:topic:insteon:kitchenPots'
2024-12-23 14:54:32.408 [DEBUG] [.internal.common.CombinedClassLoader] - Loaded class "org.openhab.core.thing.binding.ThingHandler" by classloader "org.eclipse.osgi.internal.loader.EquinoxClassLoader@6e96f620[org.openhab.core.thing:4.3.0(id=221)]" for "[interface org.openhab.core.thing.binding.ThingHandler]"
2024-12-23 14:54:32.409 [DEBUG] [.internal.common.CombinedClassLoader] - Loaded class "org.openhab.core.thing.ChannelUID" by classloader "org.eclipse.osgi.internal.loader.EquinoxClassLoader@6e96f620[org.openhab.core.thing:4.3.0(id=221)]" for "[interface org.openhab.core.thing.binding.ThingHandler]"
2024-12-23 14:54:32.409 [DEBUG] [.internal.common.CombinedClassLoader] - Loaded class "org.openhab.core.thing.Thing" by classloader "org.eclipse.osgi.internal.loader.EquinoxClassLoader@6e96f620[org.openhab.core.thing:4.3.0(id=221)]" for "[interface org.openhab.core.thing.binding.ThingHandler]"
2024-12-23 14:54:32.409 [DEBUG] [.internal.common.CombinedClassLoader] - Loaded class "org.openhab.core.thing.binding.ThingHandlerCallback" by classloader "org.eclipse.osgi.internal.loader.EquinoxClassLoader@6e96f620[org.openhab.core.thing:4.3.0(id=221)]" for "[interface org.openhab.core.thing.binding.ThingHandler]"
2024-12-23 14:54:32.409 [DEBUG] [.internal.common.CombinedClassLoader] - Loaded class "org.openhab.core.thing.ThingStatusInfo" by classloader "org.eclipse.osgi.internal.loader.EquinoxClassLoader@6e96f620[org.openhab.core.thing:4.3.0(id=221)]" for "[interface org.openhab.core.thing.binding.ThingHandler]"
2024-12-23 14:54:32.411 [DEBUG] [nternal.common.InvocationHandlerSync] - Already in a safe-call context, executing 'ThingHandler.handleCommand()' directly on 'org.openhab.binding.mqtt.generic.internal.handler.GenericMQTTThingHandler@879ea9e'.
2024-12-23 14:54:32.411 [DEBUG] [qtt.generic.AbstractMQTTThingHandler] - Successfully published value 0 to topic /isy_command/kitchenPots

but then then I get:

2024-12-23 14:54:35.067 [DEBUG] [nternal.profiles.ProfileCallbackImpl] - Delegating command '100' for item 'kitchenPots' to handler for channel 'mqtt:topic:insteon:kitchenPots'
2024-12-23 14:54:35.068 [DEBUG] [.internal.common.CombinedClassLoader] - Loaded class "org.openhab.core.thing.binding.ThingHandler" by classloader "org.eclipse.osgi.internal.loader.EquinoxClassLoader@6e96f620[org.openhab.core.thing:4.3.0(id=221)]" for "[interface org.openhab.core.thing.binding.ThingHandler]"
2024-12-23 14:54:35.068 [DEBUG] [.internal.common.CombinedClassLoader] - Loaded class "org.openhab.core.thing.ChannelUID" by classloader "org.eclipse.osgi.internal.loader.EquinoxClassLoader@6e96f620[org.openhab.core.thing:4.3.0(id=221)]" for "[interface org.openhab.core.thing.binding.ThingHandler]"
2024-12-23 14:54:35.068 [DEBUG] [.internal.common.CombinedClassLoader] - Loaded class "org.openhab.core.thing.Thing" by classloader "org.eclipse.osgi.internal.loader.EquinoxClassLoader@6e96f620[org.openhab.core.thing:4.3.0(id=221)]" for "[interface org.openhab.core.thing.binding.ThingHandler]"
2024-12-23 14:54:35.068 [DEBUG] [.internal.common.CombinedClassLoader] - Loaded class "org.openhab.core.thing.binding.ThingHandlerCallback" by classloader "org.eclipse.osgi.internal.loader.EquinoxClassLoader@6e96f620[org.openhab.core.thing:4.3.0(id=221)]" for "[interface org.openhab.core.thing.binding.ThingHandler]"
2024-12-23 14:54:35.068 [DEBUG] [.internal.common.CombinedClassLoader] - Loaded class "org.openhab.core.thing.ThingStatusInfo" by classloader "org.eclipse.osgi.internal.loader.EquinoxClassLoader@6e96f620[org.openhab.core.thing:4.3.0(id=221)]" for "[interface org.openhab.core.thing.binding.ThingHandler]"
2024-12-23 14:54:35.070 [DEBUG] [nternal.common.InvocationHandlerSync] - Already in a safe-call context, executing 'ThingHandler.handleCommand()' directly on 'org.openhab.binding.mqtt.generic.internal.handler.GenericMQTTThingHandler@879ea9e'.
2024-12-23 14:54:35.070 [ERROR] [nal.common.AbstractInvocationHandler] - An error occurred while calling method 'ThingHandler.handleCommand()' on 'org.openhab.binding.mqtt.generic.internal.handler.GenericMQTTThingHandler@879ea9e': null
java.lang.ClassCastException: null

And this then happens every time I adjust the item after.

I receive values Ok, but any attempt to send a command gives one of the above two errors, sometimes after a successful publish or two.

Just to be clear, all channels that send a command do this, not just this one.

This worked perfectly in 4.2, but now seems broken.
I have several hundred MQTT things and channels/items, so I had to revert to 4.2, as I simply could not get it to work.

Has anyone else seen this?

jimtng · December 23, 2024, 10:10pm

Can you please post your item definition related to this issue?

Nicholas_Waterton · December 23, 2024, 10:56pm

There is nothing special about it:

Dimmer  kitchenPots              "Kitchen Pots [%d%%]"                                      (GF_Kitchen, Lights, movie, bedtime)    { channel="mqtt:topic:insteon:kitchenPots" }

It’s not just this item, all items that send a command do the same thing.

The ON and OFF values seem to cause the casting error - which must be a bug, as dimmer items can accept ON and OFF, and should be able to send ON and OFF, and according to the documentation:

Channel Type "dimmer"
on: An optional string (like "ON"/"Open") that is recognized as minimum.
off: An optional string (like "OFF"/"Close") that is recognized as maximum.
min: A required minimum value.
max: A required maximum value.
step: For decrease, increase commands the step needs to be known
The value is internally stored as a percentage for a value between min and max.

The channel will publish a value between min and max.

You can connect this channel to a Rollershutter or Dimmer item.

This is, and always has been perfectly valid (apart from the mistakes, I doubt that on is a minnimum, or off is a maximum).

What is not clear is whether min and max are actually required as the documentation states, because this would be redundant for a percentage channel - and I don’t fancy adding pointless min=0, max=100 for every dimmer channel I have. I tried adding min, max to see if it made any difference to the errors - no, same errors.

To reproduce, just try moving a dimmer item connected to a mqtt dimmer channel three times in a short period - and you get the error.

jimtng · December 23, 2024, 11:47pm

I am unable to reproduce the problem. I created a dimmer channel, linked it to a dimmer item. Then sent an ON and OFF command to that dimmer item. It worked.

I created a sitemap with a slider for that dimmer, and moved the slider around (clicking).

I didn’t see any errors. All commands were sent out to MQTT as expected.

Could you help me create a reproduceable set up so I can see the problem? Feel free to create a separate topic or a github issue if you feel necessary.

Nicholas_Waterton · December 24, 2024, 12:27am

Are you using text files or the UI?
Mine are text files.

I even tried deleting all MQTT channels except this one, to see if it was something else causing the issue - no, same thing.

Setup to reproduce:
Thing:

Bridge mqtt:broker:proliant "Proliant" [ 
  host="192.168.100.16",
  port="1883",
  secure=false,
  clientID="Openhab_mqtt2"
]

Thing mqtt:topic:insteon "Insteon"  (mqtt:broker:proliant) {
    Channels:
   Type dimmer : kitchenPots                   "kitchen pots"                  [ commandTopic="/isy_command/kitchenPots", stateTopic="/isy_status/kitchenPots", on="ON", off="OFF" ]
}

Item:

Dimmer  kitchenPots              "Kitchen Pots [%d%%]"                                      (GF_Kitchen, Lights, movie, bedtime)    { channel="mqtt:topic:insteon:kitchenPots" }

You don’t even need a sitemap, just move the slider in the UI a few times quickly, including on and off.

jimtng · December 24, 2024, 12:40am

Nicholas_Waterton:

Setup to reproduce:
Thing:

Bridge mqtt:broker:proliant "Proliant" [ 
  host="192.168.100.16",
  port="1883",
  secure=false,
  clientID="Openhab_mqtt2"
]

Thing mqtt:topic:insteon "Insteon"  (mqtt:broker:proliant) {
    Channels:
   Type dimmer : kitchenPots                   "kitchen pots"                  [ commandTopic="/isy_command/kitchenPots", stateTopic="/isy_status/kitchenPots", on="ON", off="OFF" ]
}

Item:

Dimmer  kitchenPots              "Kitchen Pots [%d%%]"                                      (GF_Kitchen, Lights, movie, bedtime)    { channel="mqtt:topic:insteon:kitchenPots" }

You don’t even need a sitemap, just move the slider in the UI a few times quickly, including on and off.

I did this. The only difference is the broker details. No errors, and the commands were sent out to MQTT

# mqttspy '/isy_command/#'
/isy_command/kitchenPots ON
/isy_command/kitchenPots OFF
/isy_command/kitchenPots 100
/isy_command/kitchenPots 30
/isy_command/kitchenPots 40
/isy_command/kitchenPots 50
/isy_command/kitchenPots 55
/isy_command/kitchenPots 63
/isy_command/kitchenPots 40
/isy_command/kitchenPots 29
/isy_command/kitchenPots 18
/isy_command/kitchenPots 30
/isy_command/kitchenPots ON
/isy_command/kitchenPots OFF
/isy_command/kitchenPots 0
/isy_command/kitchenPots 100

Note: When you have on="ON", off="OFF" in your channel definition, then it would send literal ON and OFF out to MQTT. When I removed this, it would translate ON command to 100 on MQTT, and OFF to 0.

In any case, I can’t reproduce the problem on my system.

Andrew_Rowe · December 24, 2024, 12:58am

OK the other day I checked and I was on 4.0.3
so…

sudo apt-get upgrade openhab

everything looks good great job guys
logs are quiet

this was an upgrade from a 3x upgrade

Nicholas_Waterton · December 24, 2024, 2:17am

It’s because your MQTT isn’t connected to anything. Try this (it is different)

Thing mqtt:topic:insteon "Insteon"  (mqtt:broker:proliant) {
    Channels:
   Type dimmer : kitchenPots                   "kitchen pots"                  [ commandTopic="/isy_command/kitchenPots", stateTopic="/isy_command/kitchenPots", on="ON", off="OFF" ]
}

I don’t think it’s the publishing that’s the issue, its the feedback. When i send a value like 45, all is Ok, and I receive back (from the light it’s connected to) the value 45.

But if I move the slider to 100%, ON get’s published, and ON is received a few milliseconds later, when the light responds.

It’s the ON or OFF being received by a dimmer channel/item that causes all the errors (the casting error). If I take out the on="ON", off="OFF" then I get the second error, as the lights are still responding with ON or OFF.

In both cases the channel stops working at that point.

Whoever modified the MQTT code forgot that Dimmer channels/items can receive ON and OFF, as well as percentage numbers - as well as sending ON and OFF.

Definitely a bug.

Udo_Hartmann · December 24, 2024, 4:08am

Please be aware that the Thing UID is not set as recommended, it should be

Thing mqtt:topic:proliant:insteon "Insteon"  (mqtt:broker:proliant)

(but will not affect the problem…)

DrRSatzteil · December 25, 2024, 12:45pm

Since the upgrade to 4.3 I observe an issue from time to time that I’ve never seen before. When I try to add a thing via the UI the UI tells me that there are no thing types that can be added via the binding. See the attached screenshot.

In this case it was a community marketplace binding but it also happened to me on the Shelly binding. My solution so far was to reboot OH and it always worked as expected afterwards. Has anybody else seen this?

Edit: Oh and when this happens it does not happen for all bindings. Some other binding still work fine. Also already existing things still work normally, it’s just a problem when I try to add a new thing.

jimtng · December 25, 2024, 2:33pm

I have submitted a PR to fix this:

Slartybartfasd · December 26, 2024, 12:23pm

Firstly, I would like to thank the developers for their great work!

Almost everything works as expected (Raspi/Bookworm, upgrade 4.2.x to 4.3.x); some homeassistant_zigbee2mqtt_configurations were broken (HANDLER_INITIALIZING_ERROR Last segment must not be blank: [mqtt, homeassistant_zigbee2mqtt_…).

But that was not a problem, because these devices were already newly recognized. Before the upgrade, I had defined channels for each of these devices and used them in rules.
For some reason, the channels on most of the new HA things cannot be defined (profiles selection greyed out), which is not a problem because the channel is still displayed in the rule definition (When “a trigger channel fires”). This makes it easy to change the rule definition.