openHAB 4.1 Release discussion

[hmerk (Hans-Jörg Merk)]

I tend to disagree, as you at least can change the log level.

[Lolodomo]

@milo

Where do I need to store the yaml file for the customs semantic tags?

I found this how to https://community.openhab.org/t/oh-4-1-tutorial-to-manage-custom-semantic-tags/148135…but where to store it?

It is written in the tutorial:

OH 4.1: Tutorial to manage custom semantic tags

In openHAB 4.0, some technical refactoring in the core framework were done to define a registry for semantics tags and define a REST API to manage semantic tags (add/remove/update). The default semantic tags cannot be changed but you can add new equipment, new location, new property and new point as you wish. [image] In OH 4.1, you can now provide your own semantic tags using a file. It was decided to rely on a YAML format for the configuration file. So, for example, create a file named myTag…

In conf folder, you should find one folder for items, another for things and you have now one for tags => conf/tags

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

For marketplace add-ons?

[hmerk (Hans-Jörg Merk)]

He was not limiting to marketplace addons.

[binderth (Thomas Binder)]

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!

[AntPow (Ant)]

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.

[wars (Ward)]

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?

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

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?

[wars (Ward)]

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

[milo (M)]

Is this issue with the mqqt broker now fixed??

Mosquitto 2.0 error after configuration

This issue since OH 2.5 could be the root cause of the problem as it seems not to be fixed yet.

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

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

[wars (Ward)]

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

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

No, You have a rule that has a “GroupStateTrigger” configured. And that rule is missing the groupName parameter in its configuration.

[wars (Ward)]

@J-N-K

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.

[scheuerer]

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!!!

[usambara (Ulrich)]

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.

[Wolfgang_S]

@usambara

With the 4.1 release my contact items aren’t stored anymore

because of

@usambara

is type integer, already exists as type float

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"

[Dash]

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.

[Lolodomo]

Looks like a bug in the sitemap generator of Main UI. Having a default color as condition is valid.

[Jetblack31 (Jetblack)]

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

Working with Number:Temperature Items in rules

openHAB provides Quantity Type features, which can seem baffling. On top of that, Temperature type Quantities have a few quirks all of their own. These notes intend to guide the rules author. I’ve shown work examples in DSL rules language, see below for other scripts examples. All have similar features, if different syntax. Knowing what can be done is half the battle. What is a Quantity Type? Simply, Item states and rule variables may contain Quantities - that just means a number AND a unit …

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 !