Added deCONZ to stack

[DIYtechie]

Added deCONZ docker image from https://github.com/marthoc/docker-deconz

Also added node-red-contrib-deconz as an option for the Node-RED nodes checklist

Tested on Raspberry Pi 3B and 3B+ with Conbee II, Node-RED (including node-red-contrib-deconz) and Home Assistant.

Hardware (Conbee I/II or Rasbee) must be plugged in when stack is being composed.

Fixes gcgarner#145

[DIYtechie]

The previous conflict should be resolved now.

[Slyke]

Hey @DIYtechie , I just tested this out, and it works fine. Can you make the changes I just suggest though? I will give it a quick test once pushed, then merge it in.

[DIYtechie]

Should be fixed now

[Slyke]

Awesome! Merged.

[DIYtechie]

Thank you very much, @Slyke ! Very much appreciated.

How do I add a short wiki to the documentation (https://sensorsiot.github.io/IOTstack/)? edit: I guess it's just a matter of adding an md file to the docs folder. Will do.

[DIYtechie]

I just submitted a PR with an installation guide for deCONZ. As can be seen, I tried to make it as simple and fool proof as possible. However, the installation process it’s just not as simple as I was hoping.

I really wish it was not necessary to install it twice or to read installation instructions. @Slyke is there any way we could leave the devices (ConBee II - most popular by far) commented in by default and then either (i) accepting the error that could result from not having a device plugged in or (ii) having some sort of error catcher or (iii) perhaps just showing a notification screen when selecting deCONZ in the stack saying that the device must be plugged in or commented out before composing. Any ideas? 💡

[Slyke]

perhaps just showing a notification screen when selecting deCONZ in the stack saying that the device must be plugged in or commented out before composing

This will be a config when the menu rewrite is finished, but for all containers (each container will have it's own configs). It will have an !! Issue flag set next to it if the device doesn't exist. eg:

For now, it's bad to have docker-compose erroring on startup, it's not good user experience.

There is a compose-override.yml option file that makes it easy to override what the current menu builds:
./compose-override.yml inside IOTstack main directory

services:
  deconz:
    devices:
      # ConBee II uncomment next line
      - /dev/ttyACM0

Create this file, and put that content in it, before running the build or ./menu.sh command (also rerunning build will merge it).

Do you want to update your other PR (#43) with these instructions? If not I'll merge it straight in.

Maybe in the current bash menu, we could put text in * Requires setup instructions! or maybe * Has additional steps. See wiki. or something.

[DIYtechie]

This will be a config when the menu rewrite is finished, but for all containers (each container will have it's own configs). It will have an !! Issue flag set next to it if the device doesn't exist. eg:

This looks like the ideal solution. Great idea.

Do you want to update your other PR (#43) with these instructions? If not I'll merge it straight in.

Please just merge it in. I will update the wiki and make a new PR as soon as we find a better solution or the menu rewrite is finished.

Maybe in the current bash menu, we could put text in * Requires setup instructions! or maybe * Has additional steps. See wiki. or something.

Great idea. * Has additional steps. See wiki. sounds good to me.

There is a compose-override.yml option file that makes it easy to override what the current menu builds:
./compose-override.yml inside IOTstack main directory

services:
  deconz:
    devices:
      # ConBee II uncomment next line
      - /dev/ttyACM0

Create this file, and put that content in it, before running the build or ./menu.sh command (also rerunning build will merge it).

Not sure I understand the compose-override. Would this survive if new containers were later selected in the menu or only a docker-compose up? The reason I edit the deconz service.yml in the services folder is that changes made to the docker-compose.yml will not survive this.

Alternatively, I guess it would be possible to make different service.yml files for each configuration in the deconz template folder and then simply copy the relevant file to the services folder using a bash command. That way the user would not have to add deconz via the menu twice. That might actually be a good temporary solution, since the wiki would only consist of (1) Run this command, if you have this device (2) run this other command if you have this other device, etc. = No need for using an editor and running through the menu twice. :)

[Slyke]

Not sure I understand the compose-override. Would this survive if new containers were later selected in the menu or only a docker-compose up?

Yup! It does! It's also added to gitignore, so any future updates to IOTstack won't touch it either. What happens is during the build time is the build process merges compose-override.yml with docker-compose.yml after it is generated, overriding (or adding) anything specified in the override file. See the screenshot in #38 for an example. I also just realised that it hasn't yet been merged in (I can't merge it since I created the PR), but you can still access and use it if you switch to experimental branch.

Yup, having multiple commands is also a good idea! Just don't want people ticking stuff in the menu (to test it out or what ever) and getting errors when they try to compose-up. It should at least warn them that there are additional steps, or issues when selecting. Otherwise they are going to come straight or (or on the discord) and ask for help, lol.

[DIYtechie]

Awesome. Will implement the multiple services idea and update the wiki accordingly. Should be quite simple and user friendly as well.

Since there is actually no point creating a deCONZ container without any devices plugged in and configuration made, I was thinking whether it would be possible to simply leave the service.yml file in the deconz template folder empty (and only have a preconfigured service-conbee-II.yml, service-conbee.yml and service-raspbee.yml file). The idea being that no deCONZ container was built before it was configured as stated in a simple wiki. Without configuration the container is just wasted space anyway and this methoud should still prevent errors if people are just ticking off boxes to try stuff out.

Even if people don't read the wiki despite the * Has additional steps. See wiki., its probably the best solution since people will not accidentally spend a lot of time in the deCONZ ui trying to pair devices etc. because they don't realize the missing configuration.

[Slyke]

deCONZ could even have its own menu, kinda like NodeRed does, that could add in the device. The yaml merging code I wrote is generic, it will work on any 2 YAML files and output to a 3rd. Could just make it merge in the selected (or detected) hardware paths. It may even load JSON files, though I haven't tested that out.

I will port the hardware path detected logic to the new menu once I get to that bit, so it should just work out of the box.

We should make this an issue, lol. Our discussion may get lost in the closed PR.

Let me know if you find any issues on the experimental branch too! I have tested it thoroughly, and had some others test it, but there are a lot of changes in there.

[DIYtechie]

deCONZ could even have its own menu, kinda like NodeRed does, that could add in the device.

This great idea is now implemented in #48 . Took a closer look at the current menu.sh and the Node-RED build.sh and figured it out. Happy to say that installing deCONZ is now 100 times easier. Can't wait for it to be merged :)

[Slyke]

Just merged it!