openHAB 3.0 Release Candidates discussion

I tried both upgrading from M5 to RC1 using the runtime/bin/update script and a fresh install. In both cases events.log didn’t have anything logged to it on first start. Here’s how I resolved both:

  • upgrade: edited userdata/etc/log4j2.xml and changing all occurrences of smarthome.event to openhab.event, stopped and started openHAB.
  • fresh install: stopped and started openHAB.

Log issue is identified and will be fixed soon, see https://github.com/openhab/openhab-distro/pull/1206#issuecomment-745427684.

Wrt very first startup see discussion at https://github.com/openhab/openhab-core/issues/1937. For me it never worked in the past and I always did two starts after an upgrade. But I’ll look into it nonetheless, but cannot promise anything. But workaround is easy - just do another restart and all is fine.

6 Likes

I can’t find info on this topic in previous MS threads but I’ve been unable to add a rule through the GUI.
98% of my config is files based and all of my rules are in .rules files so there might be an incompatibility between file and UI based rule creation.
I’m getting Bad Request when trying to save the rule and see following in the log:

[WARN ] [utomation.rest.internal.RuleResource] - Creation of the rule is refused: null

not much else is logged due to the bug mentioned above but this part is :slight_smile:

It looks like the System started rules are running twice at startup. Once after reaching start level 40, and again after reaching start level 100. I have a very simple rule that simply logs that its running. If this has been reported somewhere already, I apologize.

2020-12-15 18:57:19.687 [INFO ] [.core.internal.i18n.I18nProviderImpl] - Time zone set to 'US/Eastern'.
2020-12-15 18:57:19.745 [INFO ] [.core.internal.i18n.I18nProviderImpl] - Location set to 'XXXXX,YYYYY'.
2020-12-15 18:57:19.749 [INFO ] [.core.internal.i18n.I18nProviderImpl] - Locale set to 'en_US'.
2020-12-15 18:57:20.061 [DEBUG] [enhab.core.service.StartLevelService] - Reached start level 10
2020-12-15 18:57:28.385 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'zoneminder.items'
2020-12-15 18:57:29.234 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'ambientweather.items'
2020-12-15 18:57:29.573 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'globalcache.items'
2020-12-15 18:57:29.587 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'zwave.items'
2020-12-15 18:57:29.628 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'main.items'
2020-12-15 18:57:29.782 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'squeezebox.items'
2020-12-15 18:57:29.846 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'ecobee-upstairs.items'
2020-12-15 18:57:30.985 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'ecobee-main.items'
2020-12-15 18:57:31.950 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'bhyve.items'
2020-12-15 18:57:31.998 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'doorbird.items'
2020-12-15 18:57:32.048 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'weathercompany.items'
2020-12-15 18:57:32.143 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'bigassfan.items'
2020-12-15 18:57:32.191 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'sunsetwx.items'
2020-12-15 18:57:32.473 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'jdbc.persist'
2020-12-15 18:57:32.579 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'mapdb.persist'
2020-12-15 18:57:32.920 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'default.sitemap'
2020-12-15 18:57:33.076 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'loadgen.sitemap'
2020-12-15 18:57:33.716 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'all-things.things'
2020-12-15 18:57:36.544 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'test.rules'
2020-12-15 18:57:38.298 [INFO ] [.core.model.lsp.internal.ModelServer] - Started Language Server Protocol (LSP) service on port 5007
2020-12-15 18:57:45.057 [DEBUG] [enhab.core.service.StartLevelService] - Reached start level 20
2020-12-15 18:57:45.304 [INFO ] [org.openhab.ui.internal.UIService   ] - Started UI on port 8080
2020-12-15 18:57:46.775 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'astro:sun:local' to inbox.
2020-12-15 18:57:46.786 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'astro:moon:local' to inbox.
2020-12-15 18:57:48.337 [INFO ] [persistence.jdbc.internal.JdbcMapper] - JDBC::openConnection: Driver is available::Yank setupDataSource
2020-12-15 18:57:48.449 [WARN ] [.zaxxer.hikari.util.DriverDataSource] - Registered driver with driverClassName=com.mysql.jdbc.Driver was not found, trying direct instantiation.
2020-12-15 18:57:50.065 [DEBUG] [enhab.core.service.StartLevelService] - Reached start level 30
2020-12-15 18:57:50.069 [DEBUG] [enhab.core.service.StartLevelService] - Reached start level 40
2020-12-15 18:57:50.286 [INFO ] [openhab.core.model.script.test.rules] - Test "System started" rule is running
2020-12-15 18:57:50.289 [INFO ] [e.automation.internal.RuleEngineImpl] - Rule engine started.
2020-12-15 18:57:55.065 [DEBUG] [enhab.core.service.StartLevelService] - Reached start level 50
2020-12-15 18:57:55.068 [DEBUG] [enhab.core.service.StartLevelService] - Reached start level 70
2020-12-15 18:57:55.069 [DEBUG] [enhab.core.service.StartLevelService] - Reached start level 100
2020-12-15 18:57:55.839 [INFO ] [openhab.core.model.script.test.rules] - Test "System started" rule is running
2020-12-15 18:57:57.720 [INFO ] [ab.ui.habpanel.internal.HABPanelTile] - Started HABPanel at /habpanel

I’m running build 2077.

@mhilbush Please create an issue for it, I’ll look into it then.

A post was split to a new topic: WoL rule in OH3

I get this as well with my rules that use “wol” from the network binding. If I go in and save the rule after booting it works fine.

not sure if this is the right place, but will give it a shot
3.0.0.RC1
in Model UI Item is shown only in ONE location, even if it is part of couple. Same applies to other Location-Groups.

It’s not very handy, should be displayed in every group where Item is member of.
But I’m not sure if it is feature or bug tho.

A post was split to a new topic: Grafana on OH3

A post was split to a new topic: No sudo on openHABian 64bit

I have the same problem, I have one item in multiple groups (to be able to show status of group with aggregated value). But it only shows in one group now which means the Locations Tab is not showing all my items

openHABian will now do that for you. But it’s still an ugly hack, isn’t it.

A post was split to a new topic: Installation stuck

How can a single Item be in multiple locations? I think that is by design.

because groups are now locations, and item surely have to be in several of those … like

All lights
First floor lights
Workroom lights

… you have already three location of the one single switch

or maybe i’ve got whole model location/group/point wrong, might be the case

There’s been multiple threads on this topic.
The conclusion was that there should be 1 group in the Model (location/equipment-based) and the other group(s) created as Item groups (functional - ie. first floor lights). This way, you will see the items in both groups and the Model is satisfied.

ok so instead of creating location-group, i should be doing item-group without location?
it’s bit confusing to be honest

because groups are now locations, and item surely have to be in several of those … like

All lights
First floor lights
Workroom lights

All lights would be for control. Control groups ar enot part of the semantic model.
Workroom should be a child group of First Floor.

I’ve noticed that the load averages are consistently higher with RC1 than the prior M releases. Before, I’d consistently see load averages around 0.10, now they are closer to 0.25 - 0.30.

I’d like to make a couple of observations regarding my experience in migrating from OH2 to OH3. All of my Items and Rules are created using text based files using OH2, and all Things were created using the OH2 UI. I use Dockers for both OH2 and now OH3 and have been successful in federating OH2 with OH3 for those items and bindings not currently supported in OH3. In OH3 when attempting to create links between text based Items and Things I finding that if I select an Item, many items maybe 10-15%, contain no Link Button option, only the Metatdata button. I see no pattern for this behavior as to why some items and not others exhibit this behavior. For example 2 essentially identical String Items, 1 has the Link Button and the other does not. Conversely if I select a Thing and attempt to link an Item to a Channel, only a few text based Items, 10 Items to be exact, are listed as being link eligible, even though I have almost 400 text based Items, thus forcing me to create a new Item using the UI. Is this expected behavior by design? Or is this a bug due to the migration of Items from OH2 to OH3? OR is this a local issue for my setup only?

I wanted to bring this to attention so that if changes need to be made they may be made in advance of the final release, and if this is a “feature” it needs to be highlighted in the documentation for users Migrating from OH2 to OH3 so that a lot of time is not wasted by the user in trying to mitigate the behavior.

Most of my text based Rules migrated without issue, however as expected time based rules are a mess with the move from Joda.time to Java.time and I’m still trying to work my way through this. I have even just resorted to using the UI system for rule creation without any success in recreating these Joda.time rules. Further it seems to be very slow and tedious. For me I find it unsuitable when looking to create a large number of similar type rules, but maybe it just the newness of the process I need to get to used to. Change is always hard, but I have learned to be open to new ways of doing things.