VS Code debugger ignores code changes

In order to fix a bug in a binding (not my own binding) I set up VS Code as an IDE in Windows 10 closely following this very helpful guide. Everything works fine at first. I can attach to the local openHAB instance and debug the code.

However, after making changes, recompiling and copying the JAR file to the addon folder (by hitting F5), the changes are not applied and the debugger still uses an old (cached) version ignoring the new code in the (updated) source file.

I already tried deleting JAR files from Maven’s .m2 repository and the addons folder of the openHAB instance as well as the contents of the cache and tmp folders in the userdata folder of the openHAB instance, but to no avail.

I would be grateful for any hint on how to make the VS Code debugger for Java use the updated code.

Are you sure that the new jar is loaded correctly? Log in to the karaf console of the OH instance and use bundle:list to check, the version number of the bundle should include a timestamp of when it was built. Also note that it might take a couple of seconds before the jar is loaded after you put it in the addons folder.

Thank you for the hint. Yes, the build date suggests that the JAR is loaded correctly. However, I noticed that this is the only file that has the state “Installed” and not “Resolved”. I don’t know what that means.


So it looks like it is compiling the “wrong” code, using the original code from the repository instead of my own code. I started from scatch several times (by fully deleting the openHAB instance and the git repository), making the changes before the first build, but it still uses the original code judging from the line numbers in the call stack.

Haven’t used VSCode for this, but when using IntelliJ, I usually start OH manually using start_debug.bat and then attach the debugger to that running instance. Would this be possible here? (just skip the “CTRL-SHIFT-P -> Tasks: Run Task -> Start openHAB (Debug)” step since it’s already running). You would then get a separate console window already logged into karaf where you can check if all bundles are started correctly.

Thanks for the hint. The initial snapshot was taken after I uninstalled the binding in the Web UI (sorry, I forgot). After reinstalling the binding in the Web UI, I have two (active) JAR files:


That was my presumption from the beginning, and your suggestion helped to prove it.
But how can I use “my” binding without installing the original binding in the Web UI? Reading the documenation for the Eclipse IDE, it looks like I might need to edit the POM file to make the build with the integrated binding (i.e. without the need to install it in the Web UI). Alternatively, how can I install the binding from my own JAR file?

Ensure that version number in the pom file of your binding is aligned with version number of the demo app (should be 3.1-snapshot I presume). If it’s not the case, you’ll be provided with current existing version, not the one you’re working on.

I checked the POM file in the root directory of the binding, and the version number seems to be correct:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">

  <modelVersion>4.0.0</modelVersion>

  <parent>
    <groupId>org.openhab.addons.bundles</groupId>
    <artifactId>org.openhab.addons.reactor.bundles</artifactId>
    <version>3.1.0-SNAPSHOT</version>
  </parent>

  <artifactId>org.openhab.binding.enocean</artifactId>

  <name>openHAB Add-ons :: Bundles :: EnOcean Binding</name>

</project>

To my knowledge there is no demo app for VS Code (or I haven’t found it yet). The debugger just attaches to a running debug instance of openHAB (which is 3.1.0-SNAPSHOT as well).

You’re right, I did not realize you were using VS Code. Too bad. I’m not used to this environment at all. Sorry, I can’t help further.

You shouldn’t need to install it via the UI, but for some bindings that might be a method to ensure all dependencies are installed (after that the binding should be uninstalled again). Only the binding in the addons-folder should be installed, and putting the jar in that folder should be enough to load it. The only steps I usually need to take is:

  1. Start an OH instance in debug mode (start_debug.bat)
  2. Build the addon (mvn clean install in the bundle directory, or via the IntelliJ UI)
  3. Attach the debugger
  4. Copy or move the jar to the addons directory

There might initially be some error messages from the debugger complaining that the bytecode doesn’t match the source code, this is because an old version of the binding is still loaded, but after a few seconds that is disposed and the new version is loaded instead which has the correct byte code.

Try running these steps manually and see if it works better. You might need to edit the launch.json file and comment out the preLaunchTask line to prevent VSCode from building the jar (not sure if other things might need to be changed as well).

Thank you very much for these helpful instructions. The EnOcean binding uses a serial gateway and thus depends on the module org.openhab.core.config.discovery.usbserial. Unfortunately, uninstalling the binding in the Web UI seems to remove that module as well. After removing the binding, the log shows messages like the following:

16:05:05.435 [WARN ] [org.apache.felix.fileinstall         ] - Error while starting bundle: file:/C:/Users/Dietmar/openhab/addons/org.openhab.binding.enocean-3.1.0-SNAPSHOT.jar
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.enocean [235]
  Unresolved requirement: Import-Package: org.openhab.core.config.discovery.usbserial

How can I manually add dependencies (in this case usbserial)?

Try running feature:install openhab-transport-serial, I think that should be the only required bundle, but might be others are needed as well

1 Like

@pacive: Thank you very much indeed for your support! I managed to apply the changes following your suggestions. And I seem to have fixed the bug as well. :smiley:

I would suggest to add these recommendations (i.e. not to install bindings using the Web UI and to install potential dependencies using the console) to the VS code documentation.