Running OpenHAB using docker image on Windows 11

  • Platform information:
    • Hardware: Intel i7-9700 CPU
    • OS: Windows 11
    • Java Runtime Environment: as supplied by docker image
    • openHAB version: latest
  • Issue of the topic: Unable to reach OpenHAB running in docker using WSL 2 additional integration with Ubuntu
  • Please post configurations (if applicable):
    #!/usr/bin/env bash

docker run
–name openhab
–network=host
-v /etc/localtime:/etc/localtime:ro
-v /etc/timezone:/etc/timezone:ro
-v /opt/openhab/conf:/openhab/conf
-v /opt/openhab/userdata:/openhab/userdata
-v /opt/openhab/addons:/openhab/addons
-d
-e USER_ID=1000
-e GROUP_ID=1000
-e CRYPTO_POLICY=unlimited
-e OPENHAB_HTTP_PORT=8080
–restart=always
openhab/openhab:latest
This comes from Docker | openHAB but I changed the argument --net to --network (but behavior is the same)
The above script is started from WSL2 ubuntu running on Windows 11, the docker process is happily running and the logs show no errors at all.

2021-11-04 15:20:09.157 [WARN ] [org.openhab.core.net.NetUtil        ] - Found multiple local interfaces - ignoring 192.168.65.4
2021-11-04 15:20:12.314 [INFO ] [.core.model.lsp.internal.ModelServer] - Started Language Server Protocol (LSP) service on port 5007
2021-11-04 15:20:12.953 [INFO ] [e.automation.internal.RuleEngineImpl] - Rule engine started.
2021-11-04 15:20:12.988 [INFO ] [org.openhab.ui.internal.UIService   ] - Started UI on port 8080
2021-11-04 15:20:13.162 [INFO ] [ab.ui.habpanel.internal.HABPanelTile] - Started HABPanel at /habpanel

My assumption is that when the docker container is running that I could access it using http://localhost:8080/ or maybe http://ipaddress:8080/ but they all give no response back. Am I missing something or is this a WSL 2 issue?

The last time someone tried to run openHAB in Docker on Windows the effort was abandoned because Windows didn’t support USB passthrough.

Beyond that I vaguely remember that WSL 2 needs some setting or configuration or something in order to access it through a network (i.e. accessing services).

Given the hardware limitation I doubt you’ll find many if any who are trying to run OH on Widows in a container and even fewer who are trying to do so in WSL 2 in a container. You are breaking new ground and won’t get much help here I suspect. But if you get it to work please do come and post a tutorial.

I’m running WSL2 for other things (not openhab), but it include portainer and caddy…I don;t believe I had to do anything special to get access to the WSL host via a browser.

I’m not using network_mode: host though, but a bridge with an exposed port.

And I’d agree with @rlkoshak, that given it’s hyper-v under the hood usb wont be all that easy, you might have to expose it via usb to ip software.

Well basically I am running OpenHab on a Pi, an older version, and was looking into the latest release to see if it can replace my current installation. For that I wanted to have a quick peek and followed the guide for Docker. But I should probably have done it on my Mac and not on my PC. Not sure if I will proceed and figure out how to get it working, probably will just do the port configuration instead of the --net host (or --network host) solution

There is no host networking on Windows last time I checked. So I added it to the docs, but nobody reads docs these days:

1 Like

If anyone is still interested, I have OH running in WSL2 under Win10 on an Intel i5 NUC. I can post the compose and docker files if anyone is interested. I also have an MQTT/Mosquitto container and another container running Python scripts configured with an internal docker network segment that exposes the OH web ports and translates them from 80xx to xx.

Current hairball is that WSL2 has USBIPD support to import USB devices, but it’s Win11 specific. Working on resolving that gap since my NUC is not Win11 capable and I decided late in the integration I need to support some Z-wave devices after I hit a cut-de-sac with BACNet MSTP subnet support.

Why all the layers? Turns out a bunch of my devices have native control apps in Windows and it’s convenient to have one machine that’s responsible for automation and control. Windows RDP remote desktop works remarkably well for supporting the control apps. Also unifies backup strategies.

1 Like