There is this Bundle Management | openHAB in the docs
That is nice, but Iām pretty sure that for most users that want their web UI to work, a ābundleā means nothing, and they probably ask themselves why they should āmanageā bundles. So, something more concrete for how to update the web UI is probably smart, but this concrete explanation could then link to the more general ābundle managementā instructions for those that want to understand more about what theyāre actually doing.
How to restore the old version just in case? What is the command?
Iām not 100% sure what bundle:update does, but you can probably use it to ādowngradeā as well. But you need to have the correct āaddressā to the original bundle. You can get that with bundle:list -l I believe (and then filter on the bundle youāre interested in), you can probably do bundle:list -l <BUNDLE ID> as well. The key is to write down/store the address that is there before you make any changes, that will enable you to reinstall that bundle one way or another. If bundle:upgrade doesnāt want to downgrade, you might need to use bundle:uninstall and then bundle:install. I donāt know, Iām no Karaf guru 
When documenting this we as well need to document where to get other bundle versions from, because thatās possible. Even the backport branches are built nightly and the artefacts are available online, you just need to know where (and I have to always search them myself as well). Thereās much possible.
1 Like
I didnāt have time to elaborate on my perspective (FWIW). I agree that the bundle:update feature will be rarely useful. As in the situation here, the issue needs to be confined to one bundle, there canāt be dependencies between the updated bundle (out of the hundreds in use) and the user OH version, and the developer needs to provide the bundle name and the update location. The value here is that the developer can get feedback (so this will also be limited to folks willing to test).
My familiarity with the bundle:update is from a guide (step 8) I wrote a couple of years ago to add a new device XML into an existing zwave jar. In that case the XML is not compiled, just compressed and there are no dependencies to consider.
Lastly as to the restoring the old version, the bundle:update version is stored in a separate directory locally. One is buried deep in config and the other is buried deep in tmp. It has been so long, I donāt remember, but it is possible.
1 Like
I had too many problems with 5.1.0 M3, I finally reinstalled a fresh new 5.0.3 and restored my last backup.
Unfortunately, due to breaking changes on the rule exit conditions (use āreturnā or not), many scripts are not correctly working.
I donāt want to go to M4 as I saw breaking changes in persistence.
So, I would like to upgrade to the intermediate M2 that was Ok for me. Unfortunately, I donāt know how to do that.
Anyone can help me please ?
The addition of the wrapper, by itself, should not be a barrier to adopting 5.1.0 M3+ by itself. Thereās a simple toggle to turn it off. Just go to MainUI ā Settings ā JavaScript Scripting ā Show Advanced ā toggle off āWrap script in self executing functionā. This turns off the wrapper, so no changes to code are required.
If one desires to migrate to using the wrapper, you can turn the wrapper on and off on a script-by-basis by adding the following to the top of the script.
'use wrapper=true'
Setting that to false will turn off the wrapper for that script even if the wrapper setting is toggled on. Setting that to true will turn on the wrapper for that script even if the wrapper setting is toggle off. This gives a path for migration one script at a time if desired (i.e. turn off the wrapper then add the directive with true and modify the scripts one-by-one until done).
The actual changes to the code to use the wrapper really just requires adding return before the last line(s) executed in the script conditions. There are examples in the docs: JavaScript Scripting - Automation | openHAB.
But with the wrapper enabled, use of let and const are also possible instead of just var. It also is the only way to use the JS wrapped event Object instead of the raw Java event Object. This creates parity with file based JS rules and eliminates a bunch of the issues with types caused by using the raw Java Object. From the docs:
Note that in UI based rules
event.itemState,event.oldItemState, andevent.itemCommandare Java types (not JavaScript), and care must be taken when comparing these with JavaScript types:
ā¦
NOTE : Even withStringitems, simple comparison with==is not working as one would expect!
With the JS wrapped event Object that is no longer the case as everything is JS instead of Java. And the event is broken down for you requiring less processing in some cases.
Without knowing how youāve installed OH in the first place no, we canāt help. The process is different for different ways of installing.
1 Like
Sorry, I was probably not very clear.
Openhab 5.1.0 M2 was quite stable for me. I upgraded to M3, but there were many display problems. Too many for my personnal comfort.
So, in the end, I decided to go back to 5.0.3 with a fresh install using Raspberry Pi Imager on a Raspberry PI5. And restore last backup.
I had modified my scripts to include a return statements for 5.1.0 Mx. Those scripts have been included in the backup and restored in 5.0.3.
So now, I have return or (wrapper) problems because the return statement is not supported by 5.0.3.
The wrapper and the return statements are OK for me but some of my scripts are not working at the moment ! So I just want to upgrade to what was working, 5.1.0 M2.
The openhabian-config will upgrade the system to the latest Milestone, not to M2.
So, how can I upgrade from 5.0.3 to 5.1.0 M2 ?
Thank you for your help.
OK, so itās an openHABian install already configured with the milestone repo.
From the command line run the following commands:
sudo apt install openhab=5.1.0-M2-1
sudo apt-mark hold openhab
This will fix the version of OH to 5.1 M2 until you release the hold on the version. When you are ready to move to the latest version run
sudo apt-mark unhold openhab
sudo apt update
sudo apt upgrade
Make backups, obviously, and dealing with breaking changes goes both directions (upgrades and downgrades) so watch out for those.
1 Like
Sorry, the apt command fails.
openhabian@openhabian:~ $ sudo apt install openhab=5.1.0-M2-1
Reading package listsā¦ Done
Building dependency treeā¦ Done
Reading state informationā¦ Done
Package openhab is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
E: Version ā5.1.0-M2-1ā for āopenhabā was not found
openhabian@openhabian:~ $
Did you switch to milestone branch ?
No, no idea how to do that.
There is a ā01 Select branchā openhabian-config menu, but it only allows to choose between āreleaseā and ālatestā, is it that you talk about ?
Yes, in openhabian-config under the āopenHABā menu there should be an option to select the testing branch. I donāt have ready access to an openHABian install at the moment so canāt confirm or generate screen shots.
Under OpenHAB Related, one can install the latest Release, latest Milestone or latest Snapshot, but not a specific intermediate one.
Choose ālatest milestoneā then run the commands I posted above to switch to a specific version. If you could do it through openhabian-condfig you wouldnāt need the apt commands above in the first place.
Thank you Rich. I appreciate the time you take to answer - you as well as the other members of the forum.
I installed the āLatest Milestoneā as you proposed (I did the same before for M2). I got M4 installed of course.
I decided to give M4 a try (before using your apt commands to go back to M2). Up to now, M4 is OK for me (and of course no mor error messages about Invalid return statements).
I checked persistence after install (including an OH restart), and noticed no issue for my RRD4J persisted Items, nor with my MapDB persisted ones.
I rebooted this morning to make sure, and still saw no issue.
Crossing fingers for M4.
Great to hear you havenāt found issues yes. Just a heads up, there were still a few UI bugs in M4, but weāve fixed everything that has been reported. Those will be released sonn with a release candidate.
Iām still seeing the blank screen issue with the release version of 5.1.0.
Disabling the use of Simple Navbar which I had enabled for mobile view solves the blank screen issue for me.
Iāve been able to fix the issue:
2 Likes