Bungy

That would be greatly appreciated, and thank you for your work on this docker. This is a snippet from my Office.items file that works for WOL: Switch Desktop "Desktop" (Office) { wol="192.168.1.100#FF:FF:FF:FF:FF:FF"} You'll have to change the ip address and the mac address to match the computer you're trying to wake up. Thank you! I mistakenly was starting to think that the first three parts of my openhab instance's IP address had to match that of the computer I was trying to wake, but it turns out that this was incorrect. Thanks again! No problem! I'm glad it's working for you!

That would be greatly appreciated, and thank you for your work on this docker. This is a snippet from my Office.items file that works for WOL: Switch Desktop "Desktop" (Office) { wol="192.168.1.100#FF:FF:FF:FF:FF:FF"} You'll have to change the ip address and the mac address to match the computer you're trying to wake up.

Hmm I got wake on Lan working at some point but no longer use it. I remember it being a big pain but I'll try to dig up the configuration details.

For some reason, the webui password is already set in the image before the container has started. This causes the password to never be set and it defaults to admin/openvpn. Effectively, the ADMIN_PASS environmental variable is never used. Are we to be setting the admin password a different way now?

Do you have to perform any mods to the ps3 to get this to work?

Pushing v1.7.1 now. It should be done in 10-15 minutes.

The configuration not found message should only appear on the first boot if you're not mounting your own configuration. It'll then populate the configuration location with the openhab.cfg file, so you shouldn't see this message on your second boot. In order to avoid having to type in the sitemap=demo in the url, rename demo.sitemap to default.sitemap. This file will be found in the sitemap directory of your volume mount. Things were set up this way so you can simultaneously run the demo and your own configuration. Let me know how it goes and if you need any more help!

You're definitely better off recreating the image. When you run out of space, the data that should get written to the docker image gets trimmed and leaves you with corruptions. Recreating the docker img only takes as long as it takes to re-download the images from docker hub. If you haven't recreated your docker.img before, you'll be very happy with how little setup you now need to do and with how quickly you'll be back up and running.

It looks like you ran out of space in your docker. I did find one issue with automatically installing all addons. The souliss addon has a bug where it continuously throws up errors if there is no configuration specified in the openhab.cfg file. The problem with this is the log file continues to grow, which may be why your docker.img filled up. The quick fix for now is to delete (or move) this addon from the addons directory inside your openhab config directory. Simply renaming the extension from .jar to .bak won't work (I already tried it). You can check the size of your log files by executing this command: docker exec -it openhab ls -l /opt/openhab/logs Let me know if recreating your docker.img and removing the souliss addon helps.

I just pushed a new version that will run openhab as nobody:users. Now all the files have the right permissions, which makes it much easier to edit the configuration files outside of the docker image.

I just pushed a new update that will make symbolic links for any webapps placed in the config directory (/etc/openhab/webapps). This is useful for the weather binding where you can use custom page layouts.

HABmin is now included by default and there is no need for the addons.cfg file. You can all remove the volume mounts and addons.cfg. The build should be done in a few minutes. Are there any other feature requests out there?

Done! Next up: Include habmin by default.

I have changed around the initial boot of the docker so that it now copies the demo configuration files into the volume mapped config directory if configuration files do not already exist. I hope this helps with the initial configuration. New build should be finished shortly. Next up: Include all the addons so you no longer have to configure the addons.cfg file

If you are trying to just run the openhab demo, you should not link the volumes. Linking the volumes overwrites the openhab configuration with the configuration that you are providing. If you would like to run the demo, remove the volume mounts, run the docker, and browse to http://hostname:port/openhab.app?sitemap=demo If you would like to begin starting your own configuration, set up the volume mounts as you have and extract the demo configuration into your configuration directory. The demo configuration provides a good basis for getting started. For me, the configuration directory is located at /mnt/user/appdata/openhab/config. Inside this directory there should be an items, persistence, rules, scripts, and sitemaps directories. There should also be the openhab.cfg and addons.cfg file. Let me know if you have any problems, I hope this clears things up. I'm working on a more elegant way of handling this specifically having the docker set up the demo in your provided volume mount path if configuration is not already found.

All, I'm sorry for the delayed response for the openhab docker issues. I believe the issue is a bad link to the demo configuration files and I'm working to fix it now. I will hopefully have a new build tonight or tomorrow that will fix the problem. Stay tuned!

you have to use the 64bit executable. it's called wine64 and compiling this way allegedly allows the 64bit wine to run 32 bit apps. whether that works within unraid is the big question. I was going based on this. Trying to get wine64 to run the 32 bit windows executable.

I still have the exact same problem. Wine64 won't run the 32-bit windows executable. I think there's no way around this other than to use the 32-bit wine. This is the file type I'm trying to run: file blueiris.exe blueiris.exe: PE32 executable (GUI) Intel 80386, for MS Windows These file types run fine: file notepad.exe notepad.exe: PE32+ executable (GUI) x86-64, for MS Windows

Wow. Thanks so much. This helps a lot. I'm building it now and will report back.

Yes you can definitely pass through USB devices to dockers. I'm currently passing through a USB x-10 controller and it works without a problem.

Should work fine as long as there are drivers for it. I would check if anybody has used that controller in openhab before.

I missed this post earlier. On my machine, the package repository repository looks a little bit different. I'm guessing this is because I added the ppa and then updated before searching the cache. libwine-gecko-2.21 - Windows API implementation - web browser module libwine-gecko-dbg-2.21 - Windows API implementation - web browser debug build wine-gecko2.21 - Microsoft Windows compatibility layer (embedded web browser) wine-gecko2.24 - Microsoft Windows compatibility layer (embedded web browser) wine-gecko2.34 - Microsoft Windows compatibility layer (embedded web browser) wine-gecko2.36 - Microsoft Windows compatibility layer (embedded web browser) wine-gecko2.36 is the one I've been using with wine1.7.*

Fair enough. I have a docker with the x11 server and vnc built in. It takes some configuring on the client side, but it's pretty simple. X11server: docker run -d --name display -e VNC_PASSWORD=newPW -p 5901:5900 suchja/x11server:latest Dockerfile for x11client: # Setup the xclient # first create user and group for all the X Window stuff # required to do this first so we have consistent uid/gid between server and client container RUN addgroup --system xusers \ && adduser \ --home /home/xclient \ --disabled-password \ --shell /bin/bash \ --gecos "user for running an xclient application" \ --ingroup xusers \ --quiet \ xclient # Install packages required for connecting against X Server RUN apt-get update && apt-get install -y --no-install-recommends \ xauth \ && rm -rf /var/lib/apt/lists/* Then just run your wine docker: docker run -d --name winebottle --link display:xserver --volumes-from display winebottle From inside the winebottle, change the user to xclient and run your wine64 program.

That may be true. My compiled wine64 wouldnt run the 32-bit executable I was trying. I didn't try other executables yet. I get no error message and no response. If your build is done, can you try to run this program: http://blueirissoftware.com/blueiris.exe Also don't forget to include wine-gecko and wine-mono

I tried this using the ubuntu:14.04 baseimage instead of phusion since that is what I was working on previously. I'll likely switch to phusion once (/if) I release the docker. I compiled the wine32 executable using your same flags to ignore x and freetype and am still getting the same problem (bash: /usr/local/bin/wine: cannot execute binary file: Exec format error) Were you able to get the 32-bit wine to run in phusion? I'm asking before I take another hour to rebuild.