openHAB 4 migration FAQ

[laursen (Jacob Laursen)]

Seeing many issues related to openHAB 4.0 migration, sometimes duplicated, I thought maybe it might help to create an overview of the different issues and their current status. Therefore I have compiled this initial FAQ based on observations.

Before upgrading, please read:

• Upgrade Process
• Breaking Changes that Require Manual Interaction after the Upgrade

Index

• openHABian upgrade failing due to Java upgrade
• TransformationService of type ‘JS’ is unavailable
• ScriptEngine for language ‘application/javascript’ not found
• Blockly rules not working: PolyglotException: ReferenceError
• High CPU usage
• Channel types or config descriptions are missing in the respective registry
• Rule does not trigger on Astro event
• Shelly: Incompatible units
• EnOcean: Handler EnOceanBridgeHandler tried updating the thing status although the handler was already disposed
• Deconz Conbee II stick not detected on Debian bullseye
• Repeated ItemStateUpdatedEvent in logs
• Restarts/sluggishness
• Massive amount of logs/restart loop
• You are running a too old version of your Operating System
• Textual configuration files are not reloading

Issues

openHABian upgrade failing due to Java upgrade

Symptom

Upgrade to 4.0 using openHABian doesn’t seem to work at all.
Debug level output will show complaints about unresolvable package dependencies on libc and other packages.

Mitigation

See openHABian 1.8 release - #2 by mstormi

Reinstalling openHABian on Raspberry

Thanks to @mstormi for these instructions:

• Get a new SD card (preferrably an “Endurance” labelled one) and keep the old one as your fallback
• Run option 50 to create an OH config backup and copy it to some box of yours
• Download and flash openHABian 1.8
• Put the SD in your Windows system and open the first (only) partition. Edit openhabian.conf and set clonebranch=openHAB3. That should result in (latest) OH3 being installed.
• Also put your backup zip file there, name it initial.zip. That’ll auto-import the config during install.
• Now put the SD in the Raspi and turn it on. Let openHABian do its install magic.
• When finally done, login and run openhabian-config menu option 03 to upgrade to OH4

References

• OH4 on buster - #40 by mstormi
• openHABian testing

TransformationService of type ‘JS’ is unavailable

Symptom

Warnings like these:

2023-07-29 01:28:17.161 [WARN ] [s.internal.SingleValueTransformation] - couldn’t transform response because transformationService of type ‘JS’ is unavailable

Mitigation

Install JavaScript Scripting add-on.

See also [OH4 StartUp WARN] The transformation add-on 'javascript' does not exist - ignoring it - #2 by rlkoshak

References

• [OH4 StartUp WARN] The transformation add-on 'javascript' does not exist - ignoring it
• Couldn't transform value in label / MAP - #13 by hermann59

ScriptEngine for language ‘application/javascript’ not found

Symptom

Error like this logged:

[ERROR] [ipt.internal.ScriptEngineManagerImpl] - ScriptEngine for language ‘application/javascript’ could not be found for identifier: 6ee73f65-d669-421f-ae82-a239f467555b

Mitigation

Install JavaScript Scripting add-on.

References

Error after update to version 4

[ERROR] [ipt.internal.ScriptEngineManagerImpl] - ScriptEngine for language ‘application/javascript’ could not be found for identifier: 6ee73f65-d669-421f-ae82-a239f467555b Does somebody know how to fix the error? How can I see witch item coursed the identifyer? Thank you fox help

Blockly rules not working: PolyglotException: ReferenceError

Symptom

Blocky rules are not working and errors like this logged:

2023-07-25 00:36:06.420 [ERROR] [b.automation.script.javascript.stack] - Failed to execute script:
org.graalvm.polyglot.PolyglotException: ReferenceError: "itemRegistry" is not defined
	at <js>.:program(<eval>:1) ~[?:?]
	at org.graalvm.polyglot.Context.eval(Context.java:399) ~[?:?]
	at com.oracle.truffle.js.scriptengine.GraalJSScriptEngine.eval(GraalJSScriptEngine.java:458) ~[?:?]
	at com.oracle.truffle.js.scriptengine.GraalJSScriptEngine.eval(GraalJSScriptEngine.java:426) ~[?:?]
	at javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:262) ~[java.scripting:?]
	at org.openhab.automation.jsscripting.internal.scriptengine.DelegatingScriptEngineWithInvocableAndAutocloseable.eval(DelegatingScriptEngineWithInvocableAndAutocloseable.java:53) ~[?:?]
	at org.openhab.automation.jsscripting.internal.scriptengine.InvocationInterceptingScriptEngineWithInvocableAndAutoCloseable.eval(InvocationInterceptingScriptEngineWithInvocableAndAutoCloseable.java:78) ~[?:?]
	at org.openhab.automation.jsscripting.internal.scriptengine.DelegatingScriptEngineWithInvocableAndAutocloseable.eval(DelegatingScriptEngineWithInvocableAndAutocloseable.java:53) ~[?:?]
	at org.openhab.automation.jsscripting.internal.scriptengine.InvocationInterceptingScriptEngineWithInvocableAndAutoCloseable.eval(InvocationInterceptingScriptEngineWithInvocableAndAutoCloseable.java:78) ~[?:?]
	at org.openhab.core.automation.module.script.internal.handler.ScriptConditionHandler.isSatisfied(ScriptConditionHandler.java:54) ~[?:?]
	at org.openhab.core.automation.internal.RuleEngineImpl.calculateConditions(RuleEngineImpl.java:1158) ~[?:?]
	at org.openhab.core.automation.internal.RuleEngineImpl.runRule(RuleEngineImpl.java:995) ~[?:?]
	at org.openhab.core.automation.internal.TriggerHandlerCallbackImpl$TriggerData.run(TriggerHandlerCallbackImpl.java:87) ~[?:?]
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) ~[?:?]
	at java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[?:?]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) ~[?:?]
	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:833) ~[?:?]

Mitigation

See https://www.openhab.org/docs/configuration/blockly/#openhab-3-openhab-4-migration

References

Migration to v4 gives "itemRegistry" is not defined error related to blockly rules

After migrating from openhab 3.4 to openhab 4, I see these errors: 2023-07-25 00:36:06.420 [ERROR] [b.automation.script.javascript.stack] - Failed to execute script: org.graalvm.polyglot.PolyglotException: ReferenceError: "itemRegistry" is not defined at <js>.:program(<eval>:1) ~[?:?] at org.graalvm.polyglot.Context.eval(Context.java:399) ~[?:?] at com.oracle.truffle.js.scriptengine.GraalJSScriptEngine.eval(GraalJSScriptEngine.java:458) ~[?:?] at com.oracle.truffle.js.scriptengine.Gra…

High CPU usage

Symptom

High CPU usage after upgrading to 4.0.1, typically caused by one of these threads:

• upnp-main-queue
• safeCall-queue

Example

top:

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
11216 openhab   20   0 1318172 472096   4528 S 256.2  47.4   4740:45 java

top -H -p 11216:

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
25409 openhab   20   0 1318172 471856   4528 R  99.7  47.4  93:36.83 upnp-main-queue
30546 openhab   20   0 1318172 471856   4528 R  99.7  47.4  15:19.09 safeCall-queue

Mitigation

Upgrade to 4.0.2

Background

This is a bug in openjdk 17. A bugfix has been made for the next openjdk 22 release:

8301341: LinkedTransferQueue does not respect timeout for poll()

It is yet unknown if this will be backported to jdk 17 - a request has been made:

wborn

but a contributor would need to provide such a backport.

Therefore a work-around has been made in openHA providing the Java 11 version of the class.

References

• Upgrade OH 4.0.0 -> 4.0.1 high cpu usage
• Consistent 100% CPU use of safeCall-queue thread - #27 by Andrew_Rowe
• https://bugs.openjdk.org/browse/JDK-8301341

Channel types or config descriptions are missing in the respective registry

Symptom

Warnings like these:

2023-07-29 10:19:24.234 [WARN ] [core.thing.internal.ThingManagerImpl] - Channel types or config descriptions for thing 'smartmeter:meter:87e2db31cf' are missing in the respective registry for more than 120s. In case it does not happen immediately after an upgrade, it should be fixed in the binding.

Mitigation

1. Try to restart openHAB.
2. If it still happens, try to recreate the thing.
3. If it still happens, please create an issue in the openhab add-ons repository.

References

• Error for configuration after upgrade to OH4 (Failed to normalize)
• Shelly Binding - #3344 by Andy_Co

Rule does not trigger on Astro event

Symptom

Rule doesn’t trigger and channel cannot be selected in the UI.

Mitigation

This is a regression, and a fix is not available yet. It can be tracked here:

Cannot choose channel when creating rule to trigger on Thing Event

As a work-around, file-based rules can be used since they are not impacted.

Another work around is to link the equivalent State Channel to a DateTime Item and use the Time is <Item> trigger for the rule. That works in the UI as well as file based.

References

Rule in OH4 does not trigger on Astro event

I have a fresh install of Openhabian, running Openhab 4.0.0 on a raspberry pi. I’m trying to set up a rule to trigger a script based on events from the Astro module. This worked fine when I was running OH3 and OH2, but it doesn’t now and I’m not really sure what the problem is. I want the rule to trigger on astro:sun:local:civilDusk#event START, and I can see the event triggering in the log. When creating the rule, I choose “Thing Event”. As the thing I choose “Local Sun (astro:sun:local)”. Bu…

Shelly: Incompatible units

Symptom

Warnings logged: cannot convert from “W” to “kWh”

Mitigation

There’s a bug in binding, please wait for a fix. It can be tracked here:

[shelly] Wrong unit for channel lastPower

References

OH4 upgrade issue

After upgrade in Openhabian from 3.4.4-2 now to Openhabian 4.0.0-1, I get warnings in the logfile, that units cannot convert from “W” to “kWh”. As thoose are to diffferent units I was checking. It seems, that with the 4.0.0-1 binding for shelly, all (at least the value from the gen1 plug s) the values which are “average the power from the last minute” are set with the wrong unit. When I delete the item and I create NEW it will be generated new, but with the wrong value: [image] It should be…

EnOcean: Handler EnOceanBridgeHandler tried updating the thing status although the handler was already disposed

Symptom

Binding doesn’t work, or at least doesn’t work reliably.

Logged:

2023-07-29 12:39:13.511 [INFO ] [ernal.transceiver.EnOceanTransceiver] - Transceiver shutdown
2023-07-29 12:39:13.513 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler EnOceanBridgeHandler tried updating the thing status although the handler was already disposed.
2023-07-29 12:39:13.513 [WARN ] [erial.internal.SerialPortManagerImpl] - No SerialPortProvider found for: /dev/ttyAMA0
2023-07-29 12:39:13.514 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler EnOceanBridgeHandler tried updating the thing status although the handler was already disposed.

and/or:

2023-07-29 12:55:05.365 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'enocean:bridge:f424041d7c' changed from OFFLINE (CONFIGURATION_ERROR): Port could not be found to OFFLINE (CONFIGURATION_PENDING): opening serial port...
2023-07-29 12:55:05.375 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'enocean:bridge:f424041d7c' changed from OFFLINE (CONFIGURATION_PENDING): opening serial port... to OFFLINE (CONFIGURATION_ERROR): Port could not be found
2023-07-29 12:56:05.380 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'enocean:bridge:f424041d7c' changed from OFFLINE (CONFIGURATION_ERROR): Port could not be found to OFFLINE (CONFIGURATION_PENDING): opening serial port...
2023-07-29 12:56:05.388 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'enocean:bridge:f424041d7c' changed from OFFLINE (CONFIGURATION_PENDING): opening serial port... to OFFLINE (CONFIGURATION_ERROR): Port could not be found
2023-07-29 12:57:05.392 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'enocean:bridge:f424041d7c' changed from OFFLINE (CONFIGURATION_ERROR): Port could not be found to OFFLINE (CONFIGURATION_PENDING): opening serial port...
2023-07-29 12:57:05.402 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'enocean:bridge:f424041d7c' changed from OFFLINE (CONFIGURATION_PENDING): opening serial port... to OFFLINE (CONFIGURATION_ERROR): Port could not be found

Mitigation

Upgrade to 4.0.2.

References

EnOcean USB300 initialization fails with OH 4.0.0.M3 and OH 4.0.0.#3512

Ok, spend some more time to clean install from scratch using openHABian image 1.8, restoring my file based setup. Setup comes now up with openhab 4.0.1. All my devices are listed, seeming to work, but logs show constantly every 60sec: 2023-07-29 12:39:13.511 [INFO ] [ernal.transceiver.EnOceanTransceiver] - Transceiver shutdown 2023-07-29 12:39:13.513 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler EnOceanBridgeHandler tried updating the thing status although the handler was already di…

Deconz Conbee II stick not detected on Debian bullseye

Symptom

The conbee II isn’t detected in the Gateway.

As I (@stefan.hoehn) have a feeling that a lot of us are using the at Zigbee stick, there is actually a pitfall on the latest bullseye that breaks it finding the stick.

Mitigation

Patch like /usr/lib/udev/rules.d described here and change via

sudo nano /lib/systemd/system/deconz.service

the following line by adding your device at which the stick is connected to

ExecStart=/usr/bin/deCONZ -platform minimal --http-port=8070 --ws-port=8070 --dev=/dev/ttyACM0

Repeated ItemStateUpdatedEvent in logs

Symptom

Repeated logs of updated items without any value change:

2023-07-24 23:37:30.240 [INFO ] [openhab.event.ItemStateUpdatedEvent ] - Item 'Contact_VeluxRoom3' updated to CLOSED
2023-07-24 23:37:31.328 [INFO ] [openhab.event.ItemStateUpdatedEvent ] - Item 'Contact_VeluxRoom3' updated to CLOSED
2023-07-24 23:37:32.316 [INFO ] [openhab.event.ItemStateUpdatedEvent ] - Item 'Contact_VeluxRoom3' updated to CLOSED
2023-07-24 23:37:33.419 [INFO ] [openhab.event.ItemStateUpdatedEvent ] - Item 'Contact_VeluxRoom3' updated to CLOSED
2023-07-24 23:37:34.466 [INFO ] [openhab.event.ItemStateUpdatedEvent ] - Item 'Contact_VeluxRoom3' updated to CLOSED
2023-07-24 23:37:35.649 [INFO ] [openhab.event.ItemStateUpdatedEvent ] - Item 'Contact_VeluxRoom3' updated to CLOSED

Mitigation

Upgrade to 4.0.2

See also After upgrade to Openhab 4: a lot of "Item updated to" in the log - #3 by MathiasVDA

Restarts/sluggishness

Symptom

From time to time openHAB becomes slow and then ultimately restarts.

Mitigation

openHAB 4.0 and/or Java 17 seems to be using quite some more memory, and long-term openHABian users should adjust parameters as explained here:

Very High Memory Usage and frequent restarts with OH4

Since I upgraded from 3.4.4 to 4.0, I have noticed that everything is very s l o w. Memory usage is high, though processor usage appears low: [image] And openHAB restarts on its own frequently. I get an email from iCloud every time the binding reconnects after a restart, and I have received 76 since I upgraded the evening of July 23. (I have no reason to think the iCloud binding is causing the problem, I only mention it because the email from iCloud is an easy way to track it). There is no…

Massive amount of logs/restart loop

Symptom

A huge amount of errors are logged and the system may restart over and over.

Example:

2023-08-16 15:42:28.512 [ERROR] [core.karaf.internal.FeatureInstaller] - Failed installing 'openhab-binding-modbus, openhab-binding-evcc, openhab-binding-mail, openhab-misc-openhabcloud, openhab-binding-smaenergymeter, openhab-automation-jsscripting, openhab-binding-shelly, openhab-persistence-rrd4j, openhab-transformation-map, openhab-ui-basic, openhab-binding-ipcamera, openhab-binding-ntp, openhab-binding-openweathermap, openhab-binding-astro, openhab-binding-homematic': Error:

	Error downloading mvn:org.jupnp/org.jupnp/2.7.0

Mitigation

Make sure that no bindings for previous versions of openHAB (3.x) are installed, i.e. .kar/.jar files placed in the addons folder or installed via the Marketplace.

See Endless loop during start of OH4.0.2 service after upgrade from OH4.0.1

You are running a too old version of your Operating System

Symptom

Message from openHABian: “You are running a too old version of your Operating System”.

Mitigation

See openHABian 1.8 release - #2 by mstormi

Textual configuration files are not reloading

Symptom

Textual configuration files like .things and .sitemaps are not reloading after changes.

Mitigation

There is currently no confirmed fix, but two related pull requests have so far been merged into main (4.1):

Update directory-watcher to 0.18.0

Fix GenericThingProvider

References

Forum reports:

• Changes in thing config files not populated in OH4
• Bug since OH4: Why are the default.sitemap and *.things files not loaded on startup? (empty sitemap list)
• 4.0.1: Cannot delete or modify things that are provisioned from file
• .things (textual config) sometimes not available after reboot (OH4.x)

GitHub issues:

• https://github.com/openhab/openhab-core/issues/3791
• Textually defined things not available after restart · Issue #3793 · openhab/openhab-core · GitHub

[Wolfgang_S]

@laursen

can you paste a link for reference just to have some details?

Message during upgrade and later message if ignored are shown in this example:

openHAB 4.0 Release discussion

I have a major issue since upgrade, seems to be JAVA related, I’m a but confused about what Java version I should : I have Ubuntu server which Zulu 11 and Oracle v8 java versions Selection Path Priority Status ------------------------------------------------------------ 0 /usr/lib/jvm/zulu11/bin/java 2116601 auto mode 1 /usr/lib/jvm/java-11-openjdk-amd64/bin/java 1111 manual mode * 2 …

[stefan.hoehn (Stefan Höhn)]

Deconz Service doesn’t detect the Conbee II Stick on Debian Bullseye

Symptom

The conbee II isn’t detected in the Gateway

As I have a feeling that a lot of us are using the at Zigbee stick, there is actually pitfall on the latest bullseye that breaks it finding the stick.

Mitigation

Patch like /usr/lib/udev/rules.d described here and change via

sudo nano /lib/systemd/system/deconz.service

the following line by adding your device at which the stick is connected to

ExecStart=/usr/bin/deCONZ -platform minimal --http-port=8070 --ws-port=8070 --dev=/dev/ttyACM0

[laursen (Jacob Laursen)]

@stefan.hoehn

As I have a feeling that a lot of us are using the at Zigbee stick, there is actually pitfall on the latest bullseye that breaks it finding the stick.

Do you know how/when this was introduced? For example, if already running openHABian 1.8 and then upgrading to 4.0, will the suddenly trigger this? Or was it a package upgrade that caused this to happen some time ago when already running openHABian 1.8?

[stefan.hoehn (Stefan Höhn)]

Maybe I wasn’t too clear above: It is NOT an openHAB issue it is Debian bug where someone introduced a wrong symlink behavior as far as I understand. It seems it was fixed in April but I also have the feeling that this is still the part of the openhaben bullseye version - at least I still have the problem.
See the details linked about it here

So, It isn’t an openHAB issue per se but rather part of the bullseye that comes with openhabian. Maybe someone has an idea how we can update bullseye to a point where we know this is not an issue anymore (I currently don’t have the time to do so and try it out as I am happy that my complex OH4 production setup finally runs almost everything like before).

[stefan.hoehn (Stefan Höhn)]

Jacob, do we want to add it into your great list above? How about adding an index above that description that gives a quick overview on all topics like

• Upgrade to 4.0 using openHABian doesn’t seem to work at all.
• TransformationService of type ‘JS’ is unavailable
• ScriptEngine for language ‘application/javascript’ not found
• Blocky rules not working: PolyglotException: ReferenceError
• High CPU usage
• Channel types or config descriptions are missing in the respective registry
• Rule does not trigger on Astro event
• Shelly: Incompatible units
• EnOcean: Handler EnOceanBridgeHandler tried updating the thing status although the handler was already disposed.
• openJDK17 fails due top dependencies when you are still in Theo Buster Release of Debian or openHABian
• Deconz Conbee II stick not detected on Debian bullseye

[Andrew_Rowe]

@laursen

High CPU usage after upgrading to 4.0.1 - no issue with 4.0.0.

I had this issue with 4.0.0 M1 as soon as I upgraded way back in April first reported here
On several occasions I thought I had tracked it down but it is still a problem for me. (happen yesterday) currently running 4.0.0 snapshot 3460

[laursen (Jacob Laursen)]

@stefan.hoehn

Jacob, do we want to add it into your great list above? How about adding an index above that description that gives a quick overview on all topics like

Sure - done!

[helmar74 (Helmar)]

In openHABian 1.8 release - #2 by mstormi
was mentioned:

Memory usage
The Java upgrade seems to be using quite some more memory than before and memory reserves are tight particularly if you are on on Raspberry. See corresponding question in the FAQ .

But I couldn’t find the corresponding question here…
BTW: I set

EXTRA_JAVA_OPTS="-XX:+ExitOnOutOfMemoryError -Xms900m -Xmx2500m"

in /etc/default/openhab
And CPU Usage and RAM USAGE looks good in my opinion:

[rlkoshak (Rich Koshak)]

@laursen

Rule does not trigger on Astro event

Another work around is to link the equivalent State Channel to a DateTime Item and use the Time is Item trigger for the rule. That works in the UI as well as file based.

[MathiasVDA (Mathias Vanden Auweele)]

Great initiative!

I would suggest to also add this thread to the FAQ:

After upgrade to Openhab 4: a lot of "Item updated to" in the log

Dear all, I just upgraded my docker contained openhab instance from 3.4 to 4. My fronttail is now showing an “item updated to” every time the item was refreshed by the thing. This is new and did not happen in my previous openhab instance. I give an example to better clarify what I mean. Contact_VeluxRoom3 is an item that represents the OPENING state of a window. It is read using the modbus binding from my PLC. The binding polls the PLC every second. I see this in my log: 2023-07-24 23:37:30.2…

[Michael_Paier]

Hi to All,

I’m also facing very high CPU loads. Before Upgrading to 4.0.1 I was running OH3.4.1 without any issues @ average CPU Load ~15-20%.

Running on, Raspberry PI 4, 8GB, Samsung 890 M.2 500GB

BTW: for OH4.0.1 I made a complete new Setup up on a new Harddrive, but I “configured” OH with a Backup.

[wborn (Wouter Born)]

@Michael_Paier

I’m also facing very high CPU loads. Before Upgrading to 4.0.1 I was running OH3.4.1 without any issues @ average CPU Load ~15-20%.

Can you change the display option in htop to show the thread names?
That makes it easier to figure out what is causing the load.

See:

change thread name on linux (htop)

[Michael_Paier]

Hi,

I hope I made it as requested…

[wborn (Wouter Born)]

It could be event handling related based on those thread names.

There have been a few PRs regarding event handling which may have caused performance issues:
#3141, #3299, #3523, #3533, #3702

[Michael_Paier]

I was reading the PR’s, but reading does not mean understanding - thats too complex for my simple mind

Is there a way to check those EventTrigger-Issue for simple “end-users”?

Im running OH with 442 things, 1839 items, 322 rules (all in DSL)… I’ll have a horrible night, thinking of maybe checking everything or maybe updating a massive portion of my configuration…

[laursen (Jacob Laursen)]

I also seem to have this issue now (with 4.0.1):

  PID USER      PR   NI   VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
 5147 openhab   20   0  887048 581872   4768 R  98.7  58.5 102:08.36 upnp-main-queue

[pfroehlich (Peter Fröhlich)]

@laursen

• Put the SD in your Windows system and open the first (only) partition. Edit openhabian.conf and set clonebranch=openHAB3. That should result in (latest) OH3 being installed.
• Also put your backup zip file there, name it initial.zip. That’ll auto-import the config during install.

Is it necessary to also remove the comment in the line

# initialconfig=/boot/initial.zip

in openhabian.conf?