Thanks Robert, this is the output:
[{“id”:“00212EFFFF05XXXX”,“internalipaddress”:“172.30.xx.x”,“macaddress”:“00212EFFFF0xxxxx”,“internalport”:40850,“name”:“Phoscon-GW”,“publicipaddress”:“178.85.xxx.xxx”}]
EDIT
In the Homey DeCONZ App settings advanced page this “172.30.xx.x” is added, the port is 40850. Websocket is empty and API key is empty too.
If you run deCONZ in a Docker container, you need to point the app to the IP-address of the host running Docker (assuming that it’s being exposed by Docker). The 172.30.xx.xx address is a Docker-internal IP-address that you can’t use.
Tried the other IP. No luck. The API key remains empty. Bet I am forgetting something… To tired now…
Thanks for your help! Appreciated!
BTW
The Home Assistant App does return devices:
HA is also running from Docker? If so, it probably has access through the Docker-internal network.
What Docker configuration do you have for deCONZ?
HA is running as a Hassio install on RPi3. DeConz is installed inside HA and has a couple of Aqara sensors added. These work in HA.
It doesn’t really matter if it works in HA, because it’s all running within the same local network. You need to find out if you can expose the Phoscon port (2080) to outside of the Docker container so Homey can access it.
The next minor update is around the corner and will bring the following improvements:
You can already test it over here: https://homey.app/de-ch/app/de.dresden-elektronik.deconz/deCONZ/test/
I didnt have any luck with the discovery method of the app. It seems the app does not actually save the discovered settings. Thought it was just me and was too lazy to look into it since I already had an API key from my other deCONZ app install and I configured the app manually.
But seeying this there probably is a problem with the discovery method which needs fixing. As a workaround you can acquire a API key manually using the REST API from deCONZ.
Regarding the setup issues: the progress iself consists of two steps: discovery and auth. There are ghe following scenarios:
Only thing i can say is to closely follow the provided instructions😉
One more thing: I am not sure if the traffic of the config page gets routed trough the homey or goes directly. So in any case you should ensure that your smartphone is in the same network as the homey and deconz during the setup
This is the part that does not work correctly. I did allow discovery from Phoscon but during discovery it only discovered the local IP of my Docker container (and not the one from the host which is needed) and the web port. Not the websocket port and API key. Tried several times but as mentioned didnt bother to look further. might be related to using deCONZ in Docker, dunno.
My deconz instance is also running within docker on a rpi and it works just find. When you open ```
https://dresden-light.appspot.com/discover, do you get a response where the internalip is correct? If not this is not an issur with the app but with your docker setup…
The discovery URL is showing the internal address of my Docker container as well:
{ … ,"internalipaddress":"172.20.0.2", … }
I’m using marthoc/deconz.
Interesting, i am using the same image. What is your host system? Anyway, if this call returns the wrong ip then the app cannot discover it correctly I am afraid😐
I’m using marthoc/deconz as well on a Synology NAS as host and setup with a bridge network driver. Just checked and it’s only returning the IP from the container. Perhaps you set up the container with the --net=host parameter?
I do see something funny when logging onto the webinterface from Phoscon. Something it shows the IP of the container under my Conbee and sometimes it shows the IP from my host.
Anyway, it’s probably best to supply some guidelines for people on similar setups, for instance how to retrieve an API key manually.
Yes I am using --net=host. How do you access phoscon then if you do not have a reachable ip adress?
Using a bridge network driver creates it’s own network with it’s own namespace which is bridged with the host. You can still access the container using the host IP though because you forward ports between host and container. Using the --net=host allows for greater network access as the container appears as part of the host network and is not isolated in it’s own network anymore. This is less secure.
Yes I understand what you mean, but in that case deconz itself has absolutely no knowledge how it is reachable from outside of the container. It is even mentioned by the creator of the docker image that --net host is required for proper discovery.
I see absolutley no proper detection of this problem from either my app or deconz itself. It is basically the same as you would use a proxy in between.
But what you can do is to enter the ip adress and port in the config, enable third party apps in phoscon and click on discover and auth back in the app. Does this work?
PS: when not using --net host you should also use DECONZ_UPNP=0. Otherwise the discovery works but with an unreachable ip.
FWIW, I’m not using --net=host either, just exposing the relevant ports.
Just manually adding IP, ports and API key works just fine. No need to enable third party apps. Traffic is routed over the websocket port between homey, host and deconz container. I had the old deconz app running that way and now yours (switched last weekend).
I can test if the DECONZ_UPNP=0 environment variable makes a difference in discovery if you want, but that will probably be after the weekend.
