just wanted to give a big shoutout to all developers and maintainers!
Updated just fine from 4.0 to 4.1 - everything works as it should.
Merry Christmas to all, who celebrate and Happy Holidays to all, who don’t!
5 Likes
Are you able to change the log settings? I had a similar issue, although not caused by the upgrade, where my logging stopped. the file org.ops4j.pax.logging.cfg was empty and all the Add-on Settings were blank. I follewed the the guidance at https://community.openhab.org/t/my-logs-broke-today-not-sure-why/141647 from @Udo_Hartmann and then all the addon settings reappeared.
I just upgraded to 4.1, everything looks fine, except this warning which popups every second:
2023-12-27 09:57:27.547 [WARN ] [ab.core.internal.events.EventHandler] - Dispatching/filtering event for subscriber 'org.openhab.core.events.EventSubscriber' failed: null
java.lang.NullPointerException: null
at java.util.Objects.requireNonNull(Objects.java:209) ~[?:?]
at java.util.ImmutableCollections$List12.indexOf(ImmutableCollections.java:590) ~[?:?]
at java.util.ImmutableCollections$AbstractImmutableList.contains(ImmutableCollections.java:329) ~[?:?]
at org.openhab.core.automation.internal.module.handler.GroupStateTriggerHandler.receive(GroupStateTriggerHandler.java:137) ~[?:?]
at org.openhab.core.internal.events.EventHandler.lambda$2(EventHandler.java:169) ~[?:?]
at java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1804) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) [?:?]
at java.lang.Thread.run(Thread.java:840) [?:?]
Is this an items which is still null and used somewhere? If so, how can I find this item?
The item is not null., the groupName from the configuration of the GroupStateTrigger is null. It is set from the configuration during the creation of the GroupStateTriggerHandler, so I would say that there is an issue with the configuration. Do you use GroupStateTrigger in many rules?
Yes I use this on a lot of groups. I’ll try to check them all. It would be handy if the error tells which group causes the error 
Is this issue with the mqqt broker now fixed??
I have added a fix for that in Fix NPE in GroupStateTriggerHandler and GroupCommandTriggerHandler by J-N-K · Pull Request #3966 · openhab/openhab-core · GitHub
1 Like
great!
I checked all my groups (it were only 15) which have ‘group settings’ configured, but all these groups have a correct value.
Or do you mean there is an error in the configuration of these group settings?
groupType: Switch
function:
name: OR
params:
- ON
- OFF
No, You have a rule that has a “GroupStateTrigger” configured. And that rule is missing the groupName parameter in its configuration.
Thanks! I found it. There was indeed a rule which was causing the error. In the Code tab everything was ok, but in de Design tab the group was completely missing.
My warning is solved now.
1 Like
Hello…
I have now updated my three (DEV,TEST,PROD) system every two day‘s from 4.0.4-2 to 4.1.0-1.
It looks like, that everything works as aspected. Things, items, graphs, performance, rules (we all know that 1.st time it takes longer since 4.0x) but everything works so far.
So a big, big, applause for developers, and maintainers.
Thanks for a new stabile version!!!
2 Likes
With the 4.1 release my contact items aren’t stored anymore:
2023-12-29 09:49:53.115 [DEBUG] [.influxdb.InfluxDBPersistenceService] - Connection lost, trying re-connection
2023-12-29 09:49:53.122 [DEBUG] [rnal.influx1.InfluxDB1RepositoryImpl] - database status is OK, version is 1.8.10
2023-12-29 09:49:53.916 [DEBUG] [rnal.influx1.InfluxDB1RepositoryImpl] - Writing to database failed
org.influxdb.InfluxDBException$FieldTypeConflictException: partial write: field type conflict: input field "value" on measurement "con_Fuel_Aral_Open" is type integer, already exists as type float dropped=4
at org.influxdb.InfluxDBException.buildExceptionFromErrorMessage(InfluxDBException.java:144) ~[?:?]
at org.influxdb.InfluxDBException.buildExceptionForErrorState(InfluxDBException.java:173) ~[?:?]
at org.influxdb.impl.InfluxDBImpl.execute(InfluxDBImpl.java:837) ~[?:?]
at org.influxdb.impl.InfluxDBImpl.write(InfluxDBImpl.java:470) ~[?:?]
at org.openhab.persistence.influxdb.internal.influx1.InfluxDB1RepositoryImpl.write(InfluxDB1RepositoryImpl.java:131) ~[?:?]
at org.openhab.persistence.influxdb.InfluxDBPersistenceService.commit(InfluxDBPersistenceService.java:286) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) [?:?]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) [?:?]
at java.lang.Thread.run(Thread.java:840) [?:?]
2023-12-29 09:49:53.919 [WARN ] [.influxdb.InfluxDBPersistenceService] - Re-queuing 46617 elements, failed to write batch.
because of
You migrated from pre 3.X to 4.1 ?
see InfluxDB Error "field type conflict: input field value on measurement is type integer, already exists as type float dropped=1"
I’m getting log spams like this with sitemaps:
2023-12-29 15:14:38.665 [WARN ] [omponents.UIComponentSitemapProvider] - Syntax error in labelcolor rule condition '' for widget Text
2023-12-29 15:14:50.654 [WARN ] [omponents.UIComponentSitemapProvider] - Syntax error in valuecolor rule condition '' for widget Text
It seems that any “default”, or unqualified colour being added into sitemap is causing it to spam every time the sitemap is either loaded or saved.
Example failing sitemap:
sitemap page_c6c037636f label="New Sitemap" {
Text item=KitchenLights label="Lights are: [%s]" valuecolor=["red"]
}
In this situation it will error, but this one doesn’t:
sitemap page_c6c037636f label="New Sitemap" {
Text item=KitchenLights label="Lights are: [%s]" valuecolor=[KitchenLights ==ON="red"]
}
There are no changes to the documentation that indicate that this is no longer a supported scenario, and indeed the sitemap colouring still works as expected, just I’m getting log growth.
Looks like a bug in the sitemap generator of Main UI. Having a default color as condition is valid.
Hi!
Since OH4.1 I have some strange calculations in DSL rules with temperatures.
It seems temperature calculations do not respect anymore what is indicated here
In particular, calculating an average temperature with (5|°C + 10|°C) / 2 does not work anymore (I don’t obtain 7.5°C).
what is the workaround to be able to multiply or divide Celsius temperature with 0°C as the reference point (and not 0K as it seems to be now) ?
Thank you !
Dear users,
This ‘Release discussion’ thread is to exclusively discuss (potential) issues that were introduced in OH 4.1 since the last release OH 4.0.
It’s also about software issues in openHAB itself, it is not about migration in general and not about (self-made) rules or other issues that are individual to your setup.
Please double check against these questions before posting here and mind general posting rules, too.
If in doubt, open your own thread to ask and discuss to find out if it’s really an issue caused by the latest software or if it could be an individual issue, in case of the latter please stay with your own thread.
I’m sorry to remind of this. However, if we all don’t come up with a fair amount of discipline this thread is quickly becoming an unreadable mess.
Thank you !
3 Likes
Ok, I’m sorry but reading the very first post of this thread I thought I was in the right thread
This topic can be used to discuss problems/experiences/questions on the openHAB 4.1 release
The experience I described is related to a change introduced in this specific release
and so the question I asked is also related to this specific release. The change that was done is likely to break rules of many users and the change has not been documented.
I perceived your answer as rude. I’m just a standard user of openHAB, I’m not familiar with the exact policy of the community forum.
8 Likes
I just upgraded from OH 4.0.3 to OH 4.1
I’m getting follow error in the openhab.log
Can’t connect to karaf.
2023-12-29 17:19:17.596 [INFO ] [internal.service.FeaturesServiceImpl] - Adding features: system/[4.4.4,4.4.4],feature/[4.4.4,4.4.4],deployer/[4.4.4,4.4.4],diagnostic/[4.4.4,4.4.4],bundle/[4.4.4,4.4.4],ssh/[4.4.4,4.4.4],log/[4.4.4,4.4.4],eventadmin/[4.4.4,4.4.4],openhab-runtime-base/[4.1.0,4.1.0],instance/[4.4.4,4.4.4],config/[4.4.4,4.4.4],framework/[4.4.4,4.4.4],shell/[4.4.4,4.4.4],kar/[4.4.4,4.4.4],openhab-runtime-ui/[4.1.0,4.1.0],service/[4.4.4,4.4.4],jaas/[4.4.4,4.4.4],package/[4.4.4,4.4.4]
2023-12-29 17:19:20.271 [ERROR] [ternal.service.BootFeaturesInstaller] - Error installing boot features
org.apache.karaf.features.internal.util.MultiException: Error:
Error downloading mvn:org.apache.karaf.wrapper/org.apache.karaf.wrapper.core/4.4.4
at org.apache.karaf.features.internal.download.impl.MavenDownloadManager$MavenDownloader.<init>(MavenDownloadManager.java:91) ~[?:?]
at org.apache.karaf.features.internal.download.impl.MavenDownloadManager.createDownloader(MavenDownloadManager.java:72) ~[?:?]
at org.apache.karaf.features.internal.region.Subsystem.downloadBundles(Subsystem.java:474) ~[?:?]
at org.apache.karaf.features.internal.region.Subsystem.downloadBundles(Subsystem.java:469) ~[?:?]
at org.apache.karaf.features.internal.region.SubsystemResolver.resolve(SubsystemResolver.java:223) ~[?:?]
at org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:399) ~[?:?]
at org.apache.karaf.features.internal.service.Deployer.handlePrerequisites(Deployer.java:1121) ~[?:?]
at org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:394) ~[?:?]
at org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1069) ~[?:?]
at org.apache.karaf.features.internal.service.FeaturesServiceImpl.lambda$doProvisionInThread$13(FeaturesServiceImpl.java:1004) ~[?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) [?:?]
at java.lang.Thread.run(Thread.java:833) [?:?]
Suppressed: java.io.IOException: Error downloading mvn:org.apache.karaf.wrapper/org.apache.karaf.wrapper.core/4.4.4
at org.apache.karaf.features.internal.download.impl.AbstractRetryableDownloadTask.run(AbstractRetryableDownloadTask.java:77) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) [?:?]
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:1136) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) [?:?]
at java.lang.Thread.run(Thread.java:833) [?:?]
Caused by: java.io.IOException: Error resolving artifact org.apache.karaf.wrapper:org.apache.karaf.wrapper.core:jar:4.4.4: [Could not find artifact org.apache.karaf.wrapper:org.apache.karaf.wrapper.core:jar:4.4.4 in openhab (https://openhab.jfrog.io/openhab/libs-release/)]
No, not really. I had to reinstall my server which was running in 4.0x and I installed 4.1
Unfortunately I had installed first the last 3.x version and then upgraded to 4.1. Afterwards I restored the Influxdb (which should have been with data from 4.0).
But thanks for the link, I had overlooked it. I will restore these values again with type conversation.