Bungy

Hmm. Well it looks like you can connect to that machine. Have you double checked your knx binding configuration? Also, is there any way to get connection logs from the KNX side to see if it's a failed authorization or something like that? I have the link in the Readme markdown for the docker, but I definitely should put it along with the openhab template for unraid. I've been meaning to update my documentation, but time is short these days.

So, I'm not familiar with the KNX gateway or the KNX binding, but my guess is that the docker is unable to connect to that ip address. Try running this command to see if your docker can ping the knx gateway. docker exec -it openhab ping 192.168.178.100 I'm guessing it got the ip address 192.168.178.100 from your openhab.cfg file. If openhab cannot ping that ip address, I would start looking into connectivity issues. Make sure your unraid can access that ip, check your firewall, check that the ip is correct, etc. As for #2, habmin is now installed by default. Simply point your browser to: http://tower:8080/habmin. Of course adjust the hostname and port to match your configuration. Let me know how it goes. I hope this helps you out.

Thank you for replying. I deleted everything to start fresh. Couldn't remove /https binding at first configuration since the remove button was greyed out. After first config I removed the binding and also set the TARGET_DIR variable to / so that owncloud would show right away. Why would you want it to start as /owncloud? Then it worked! So it was the https binding. I ran into another problem though. After first time setup I choose to use the included mariadb. But now owncloud only displays an error that /usr/share/webapps/owncloud/data is readable for other users and I should set 0770 permissions? This is all new for me since I'm a windows user so once I get it up and running I'll also look at creating my own test certificate. There is one thing to keep in mind when running the docker without the /https volume mount. This will use the built in ssl certificates, which is a potential security risk. If somebody gets the certificates, they would be able to sniff the data transfer over the network. This is probably a small risk, but still a risk. The easy way around it is to create the server.crt and server key files yourself using the guide I posed earlier. To fix your current problem, run these commands on your unraid server assuming your owncloud volume mounts are stored in /mnt/cache/appdata/owncloud: chmod -Rv 0770 /mnt/cache/appdata/owncloud/data chown -Rv sshd:sshd /mnt/cache/appdata/owncloud/data In my opinion, the docker should set these permissions on bootup, but I'm not the creator of the docker. If I get time, I may submit a merge request that sets these permissions.

From the log, it looks like your mysql container is starting correctly. If you want to get it to work with owncloud, start the container with enviornmental variables for: -e MYSQL_DATABASE=owncloud -e MYSQL_USER=owncloud -e MYSQL_PASSWORD=[i]password_for_owncloud_database[/i] Then, when you first initialize your owncloud container, it'll ask you what type of database you want to use. It defaults to sqlite, but you can change it to mysql. Provide it with the datbase user, name, and password that you set in your mysql docker using the environmental variables.

@d4lions, @X1pheR For owncloud - Try removing the /https volume mapping. This mapping is required if you want to provide your own ssl certificates. If the directory does not contain server.crt and server.key files, the docker will not run. Alternatively, you can generate your own https ssl certificates - which is highly recommended. Using the built in certificates is a security risk. Here is a good link for how to generate generate the certificates. http://www.akadia.com/services/ssh_test_certificate.html

Ashok, can you post your configuration? I'm also using mysql with my owncloud docker, so I should be able to help you out.

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.

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!

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 was imagining that to be a manual step that would be done when first building the server and updated when the server is modified. I mainly want it because I can never remember how I have my wires plugged in. Automation seems nice, but I agree, I don't think it's attainable.

Would it be possible to add a field to the layout to define which SATA card the drive is plugged into? This would be very useful for debugging bad cards and keeping track of what is going through the PCI-E card(s) and what is going through the motherboard. I suppose this can be done in the notes section, but it seems this should be specific to the tray and not to the drive.