This I’ve seen forever (not that it’s not a bug), the work around is to reload the page
I don’t use Edge but Firefox and Chrome
To avoid problems like this I strongly recommend to install the tradfri binding as written in the other thread.
You don‘t need this binding for anything else but to keep coap services installed when upgrading openhab or manually running clean-cache.
1 Like
Do you think that the lack of Coap caused openHAB to fail its startup? Or not necessarily? I would think the latter?
No. If you use the Linux packages or openHABian, it’s cleared anyway.
1 Like
I did use apt…
To my understanding if you update via apt, openhab does a clean-cache by itself. As a result, coap services also get removed as openhab does not find any bindings which require coap services. Bindings from marketplace or addons folder are not being considered during this process
I’ve done updates before, where Coap was uninstalled. OpenHAB’s startup wasn’t affected then…
Problems are behaving inconsistently. See example here where missing dependencies cause rules not to run
It happens every time. It’s part of the upgrade process. This is true for all ways to install OH and it either happens automatically or as part of the upgrade scripts you manually run after unzipping the new OH over your old installation (e.g. Windows).
You ran into trouble because you were using a .jar file instead of installing the add-on normally as has been mentioned. That resulted in an inconsistent cache. This has been known to cause problems like this in the past. I even opened an issue to clear out the add-ons folder during upgrades or renaming the jar files so they don’t get loaded with some logs in the upgrade logs. But despite it sometimes causing OH to not come up at all for some users I got a lot of push back from a lot of other users who believe it’s more of an inconvenience to have to change something they manually installed after an upgrade than having OH completely fall to start for a fewer number of users so haven’t really pursued it much. Issue is still open though.
This sounds like an ideal solution… Rename the files bofre the upgrade, and rename them again to .jar after the upgrade, and everybody’s happy, no? 
No, that last step you’d have to do manually. If it’s done automatically you’ll still have the same problem with IH refusing to start.
In short there are two options:
- Force people using .jar files in the add-ons folder to have to take manual steps after an upgrade (which they should be doing anyway) to restore those add-ons.
- Let some users’ OH crash and burn immediately after an upgrade if they have a jar file in the add-ons folder that causes problems. It won’t be every jar file that causes a problem, only some.
The consensus on that thread seemed to be to prefer 2, though I’m not sure most if them even believe that OH fails like this in the first place since they’ve never had it fail like this for them.
No one wants to have extra work to solve/prevent someone else’s problem.
Though I believe the marketplace add-ons now behave in a similar way as I proposed in that issue. Maybe consistency can be used as an additional reason to deal with this and prevent OH from crashing on that initial boot after an upgrade.
In general, on an upgrade, all add-ons should be reinstalled using the versions that correspond with the new version of OH. IMO if you had to install it manually, you should need to reinstall it manually after an upgrade. At least with the renaming approach the original file is still there and if you know it will work you can just rename it instead of needing to redownload it. So reinstallation is just renaming the file in that case.
2 Likes
What do you think, wouldn’t it be nice if we gave the option to the user to decide between these options, e.g. by a flag which can be set in the system settings in MainUI?
Since this is all implemented by the apt/yum/upgrade.sh/upgrade.ps scripts during the upgrade process when OH is not running, I’m not sure that makes a while lot of sense. It definitely would be an unusual approach compared to other software installed in this way.
Typically, at least for apt and yum type upgrades, there will often be a question asked along the lines of “the package has a new version of x.config and you have changes, accept the new, keep the old, diff…”. However, when using something like openHABian to upgrade, it default to yes or no to such questions (I’m assuming yes). So most of those users would never get the option to choose their answer. It would be chosen for them.
1 Like
Now I deleted the .jar files, cleaned the cache, and put the .jar files in the folder again. Why does openHAB restart without issues after I have done that? (Or in other words: what’s different from the hypotheses of automatically renaming the files to .jar at the end of the upgrade process?)
Hmm. I was talking about the decision whether or not to remove/rename the jar file in the addons directory. Isn’t this done by openhab during starting the service?
no, it would be part of the upgrade. The startup service shouldn’t mess with this unless you want to have to reinstall the jar files every time you restart OH.
What I’ll talking about works only happen in an upgrade where the version of OH changed and it’s possible if not likely that the jar files in the add-ons directory are it if date, possibly won’t work and have the potential to prevent OH from starting at all after the upgrade.
When we move to OH 5, I would not expect any jar file left in add-ons for OH 4.3 to work.
This has been reported twice now elsewhere:
- Shown time in schedule view is wrong - #5 by TimoT
- Schedule page in mainUI off by one hour since 4.3? - #2 by rlkoshak
I don’t have any corn or time triggered rules anymore. Is anyone else seeing the tz on the schedule page being off?
In both the above cases rules are triggering at the correct time and loss are correct. It’s just the Schedule view that’s off.
Hello, thank you very much for the hint.
1 Like
Hey everyone!
I’m using OpenHAB 4.3.1 and I’ve noticed that the “Health Status” tab (where you can check orphan links) is no longer visible for me. I’m using Chrome as my browser, and I’ve tried refreshing and clearing cache, but it’s still not showing up.
Has anyone else experienced this issue or found a solution? Any help would be appreciated!
Thanks!
Doesn’t it show up only if there are health issues?
1 Like