Congrats 2.5.0.M2

I just copied my config dirs from my openhab 2.4.0 docker container to a new 2.5.0.M2 location started up the 2.5.0.M" container and amazingly the upgrade worked like a charm.
Almost everything worked right away, Exceptions:

  • bindings from marketplace were not taken over
  • tradfri did and does not start after a container restart

After restart even the jython cont-init.d script picked up

Congrats to all who did the hard work making this happen!


Yes indeed, Bravo!!!

There are warnings when you upgrade, normally. There might be something mentioned in them.
Things that were broken with 2.5M1 were not priority to fix in 2.5M2 due to all the other changes that happened.

EDIT: It looks like this was an issue with 2.5M1. Now the “heavy lifting” of integrating ESH and architecting a new build system are mainly done. other issues like this should be able to be addressed.

I am getting constantly following entry in the log:

Failed uninstalling 'openhab-ui-dashboard': Feature named 'openhab-ui-dashboard/0' is not installed

Any Idea how to get rid of it?

Did you read the warnings in the logs? It told you where to look to remove the configuration entry. That add on moved in 2.5M1.

I am missing the point here totally!
Where should I look to remove the config?

Sorry, you wrote dashboard and, for some reason I saw something else.
Let me checn my server this evening to see if I find any clues. I do not remember errors like that.

For people using Docker, those warnings get saved to userdata/logs/upgrade.log. I noticed this new little feature when I upgraded to the latest snapshots awhile back. That is where you can look for the warnings that users who install using apt get to see when they upgrade.

Prior to recently, there was no way to get those warning when upgrading a Docker container and it is not widely well known that upgrade.log file exists.

The REST API Docs moved in 2.5 M1, I don’t think the Dashboard moved.

I’m not seeing that error either. Do you have the Dashboard running? When you go to your main page http://<server>:8080 does it fail or do you get the list of big old icons showing all the installed UIs. I can’t figure out why it would be wanting to uninstall it in the first place and the error indicates it’s already uninstalled. Curious indeed.

Have you tried Clear the Cache? I know you moved to a fresh container but sometimes even during a relatively clean upgrade stuff can get messed up in the cache in particular. I did run into some errors (not that one) when I upgraded from 2.5 M1 to the Snapshots a month or so ago and clearing the cache sorted it out.

Yes, I did, but local cache should not influence server behavior.

Not your browser cache, the openHAB server’s cache. See the link. You need to stop openHAB and delete the contents of userdata/cache and userdata/tmp.

1 Like

Got it and done it.
still the same:

==> /openhab/userdata/logs/openhab.log <==
2019-08-16 07:54:40.945 [DEBUG] [core.karaf.internal.FeatureInstaller] - Running scheduled sync job
2019-08-16 07:54:41.086 [DEBUG] [core.karaf.internal.FeatureInstaller] - Failed uninstalling 'openhab-ui-dashboard': Feature named 'openhab-ui-dashboard/0' is not installed

Another topic probably worth opening a topic and most probably hundred of the topic already open for that:

The startup of OH looking at the log looks like opening the first MediaMarkt store in Poland.

  • Rules are starting before all items are loaded
  • Rules are loaded over and over again
  • Persistence is called before persistence bundles are loaded.
  • A lot of stack dumps shown, who knows why, which do appear later

Some dependency between bundles or at least starting order of bundle types would be great, for sure not easy to implement.

What makes me “worry” is though the following:
after the mess stops, I get following errors in DSL rules:

2019-08-16 07:59:40.959 [DEBUG] [core.karaf.internal.FeatureInstaller] - Running scheduled sync job
2019-08-16 07:59:41.126 [DEBUG] [core.karaf.internal.FeatureInstaller] - Failed uninstalling 'openhab-ui-dashboard': Feature named 'openhab-ui-dashboard/0' is not installed
2019-08-16 08:00:00.002 [DEBUG] [ntime.internal.engine.ExecuteRuleJob] - Executing scheduled rule 'TTS Nighttime rule'
2019-08-16 08:00:00.003 [DEBUG] [ntime.internal.engine.ExecuteRuleJob] - Executing scheduled rule 'Ventilation presence rule'
2019-08-16 08:00:00.005 [DEBUG] [ntime.internal.engine.ExecuteRuleJob] - Executing scheduled rule 'lightControl Clean-Up .rules'
2019-08-16 08:00:00.007 [ERROR] [ntime.internal.engine.ExecuteRuleJob] - Error during the execution of rule 'Ventilation presence rule': The name 'ivetaAtHome' cannot be resolved to an item or type; line 183, column 66, length 11
2019-08-16 08:00:00.008 [DEBUG] [ntime.internal.engine.ExecuteRuleJob] - Executing scheduled rule 'WSRainCounter update'
2019-08-16 08:00:00.010 [DEBUG] [ntime.internal.engine.ExecuteRuleJob] - Executing scheduled rule 'update Night Bedtime Proxy Switch (isBedTime)'
2019-08-16 08:00:00.012 [DEBUG] [ntime.internal.engine.ExecuteRuleJob] - Executing scheduled rule 'Update Sunset Proxy Switch'
2019-08-16 08:00:00.016 [ERROR] [ntime.internal.engine.ExecuteRuleJob] - Error during the execution of rule 'update Night Bedtime Proxy Switch (isBedTime)': The name 'BedTimeOverride' cannot be resolved to an item or type; line 88, column 5, length 15
2019-08-16 08:00:00.017 [DEBUG] [ntime.internal.engine.ExecuteRuleJob] - Executing scheduled rule 'updateHmIP-STHD'
2019-08-16 08:00:00.020 [ERROR] [ntime.internal.engine.ExecuteRuleJob] - Error during the execution of rule 'TTS Nighttime rule': The name 'isTVOn' cannot be resolved to an item or type; line 207, column 54, length 6
2019-08-16 08:00:00.017 [ERROR] [ntime.internal.engine.ExecuteRuleJob] - Error during the execution of rule 'Update Sunset Proxy Switch': The name 'LightOnDelayAfterSunset' cannot be resolved to an item or type; line 67, column 43, length 23
2019-08-16 08:00:00.067 [INFO ] [arthome.model.script.updateHmIP-STHD] - triggered
2019-08-16 08:00:00.087 [ERROR] [ntime.internal.engine.ExecuteRuleJob] - Error during the execution of rule 'lightControl Clean-Up .rules': cannot invoke method public org.eclipse.smarthome.core.types.State org.eclipse.smarthome.core.items.GenericItem.getStateAs(java.lang.Class) on null
2019-08-16 08:00:00.397 [ERROR] [ntime.internal.engine.ExecuteRuleJob] - Error during the execution of rule 'WSRainCounter update': The name 'WSRainLastHour' cannot be resolved to an item or type; line 23, column 13, length 14

Indicating that a lot of Items not resolvable. This happened also after the upgrade from 2.4.0. and now after cache and tmp deleting.
After the second restart of OH, this error clears.

I might be seeing the same thing. It’s a long known issue in OH 2 that the startup order is not predictable and sometimes things will start (e.g. Rules) before they are ready to run (e.g. Items have not yet loaded). But what you describe is more extreme than usual.

Sometimes when I upgrade to a new SNAPSHOT I’ll see a bunch of exceptions in the log that I’ve not yet had a chance to review and on my sitemap I’ll see Item names instead of their labels (that’s usually how I discover things didn’t go well). A restart of OH almost always clears things up. Only once did I have to restart twice.

There appear to be some limitations to how Karaf loads bundles that makes this exceptionally difficult if not impossible. This is why the issue has been open forever without a viable fix.

That’s a classic symptom of a Rule being triggered before the Rule itself has been fully loaded. I’ve even seen errors like “no such symbol ON” and the like.

There is a work around that is built into openHABian I think that will copy the .rules files into the rules folder only after OH has come online. Thus the Rules can’t start triggering before they are ready.

This is not surprising actually. When you clear the cache OH has to go out and download and reinstall all the bindings which adds more load on the system and definitely interferes with the rest of the startup. Personally, after I upgrade or clear the cache I wait for the logs to quiet down and then restart by default.

Anyway, back to the original error. Are you using addons.cfg by chance?

the only entry I have is

# A comma-separated list of miscellaneous services to install (e.g. "misc = myopenhab")
#misc = 
misc = ruleengine

back to the other stuff:

Yes, but we would need just core-bundle component which could orchester this, e.g. maintaining the state in the jsondb. The components component could be loaded, but would not run their core-business before getting a go from this orchestration component.
I know that there more urgent issue, though I think that fixing that would be also not a minor thing. I am pretty sure that the startup time would be way less than now.

And I am thinking even further. I am “dreaming” about having some sort of hot standby system inside a cluster configuration (e.g. docker cluster). This would also make it possible, as components would be preloaded and with a “GO” would take over.

Before restarting OH this error stays persistent. I do not know what reliable trigger to use for “system started”. I implemented in all my rules (functional groups) a “System started” rule for initiation. I am seeing firing this rule during the startup of the system all around. And this rule is fired also when e.g. items are reloaded due to .items file change.

To come back to the beef: Congrats for great work on 2.5.0.M2!
and I mean it

1 Like

This might be related. Since you only have the one entry, what happened if you remove it and install the Experimental rules through the REST API or PaperUI?

If you have a solution for this the issue had been opened for about two years now. I’m sure they would welcome the PR.

Sometimes a sleep in the rule will help. Most of the time at least, when the role doesn’t last and start firing before Timer is available.

The only other solution that works is to remove the files from the rules folder until a certain amount of time has passed.

Or just check for errors when you restart and restart again if there are problems.

Installed it with the cont-init.d script:

sure, having plans to start contribution, but…

I added a comment to the script pr. If the user isn’t using add-ons.cfg to manage their add-ons, the script shouldn’t just blindly added a misc every to the file because all the user’s other misc add-ons will be automatically uninstalled.

I wonder if something like that is happening here.

I’m not sure if this is related, but I had a “relic” entry in addons.config (not to be confused with the addons.cfg) file after I upgraded to 2.5M2 that caused errors until I manully cleaned up the entry.

The file is located at the following path:

That’s a good one I often forget about.

And I was wondering why my Eclipse IoT Market and openHAB Cloud Connector are always vanishing.

Though, removed the entry from misc, still the same with this log entry, not keen to restart the system right now to test after this.

It doesn’t seem to be impacting the functionality. There dashboard is still there. I wouldn’t worry too much about restarting. It will either fix it it is won’t. The risk of something else going wrong is low.

Having removed the entry in add-ons.cfg, did you install the Experimental rules engine through paper UI?