Can't discover deCONZ (through appspot, openhab, home assistant)

[baflo]

Hi,

I'm having a bit of a problem getting the discovery running. I have marthoc/deconz:amd64-2.05.44 running in a boot2docker machine on a Windows 10 host that I created with a bridged network using vagrant. (Although I have very similar behaviour with the desktop application, except there's the correct IP in the description.xml).

I got everything runnig and paired some sensors and lights. Then I tried connecting OpenHAB using their Hue Binding. It was a little odd: it was immediately found, but it couldn't connect though I unlocked the gateway. I then retrieved a username manually by using the API and put it in the OpenHAB config, but it still wouldn't connect. Also used different IPs and hostnames, but nothing was successful.

As I found many hints on Home Assistant (and that it would work better there) during my research, I used that image, but neither did it discover the deCONZ.

I then found the appspot discover URL, but it would only return []:

> curl -4 -s -H "Content-Type: application/json" "https://dresden-light.appspot.com/discover"
[] 
> curl -6 -s -H "Content-Type: application/json" "https://dresden-light.appspot.com/discover"

Using the UPnP Tester I can find other services running on that boot2docker machine, but not the deDONZ:

> # works fine
> docker run -d --name minidlna --net host -v /c/Users/baflo/Music:/media vladgh/minidlna

> # doesn't get discovered
> docker run -d --name=deconz --net=host marthoc/deconz:amd64-2.05.44

One more thing that I observed: in the http://192.168.178.37/description.xml I found a wrong IP address (as you see below). I tried setting this manually, but it didn't change anything.

<root>
	<specVersion>
		<major>1</major>
		<minor>0</minor>
	</specVersion>
	<URLBase>http://10.0.2.15:80/</URLBase>
	<device>
		<deviceType>urn:schemas-upnp-org:device:Basic:1</deviceType>
		<friendlyName>Phoscon-GW (10.0.2.15)</friendlyName>
		<manufacturer>dresden elektronik</manufacturer>
		<manufacturerURL>http://www.dresden-elektronik.de</manufacturerURL>
		<modelDescription>Philips hue compatible Personal Wireless Lighting</modelDescription>
		<modelName>Philips hue bridge 2015</modelName>
		<modelNumber>BSB002</modelNumber>
		<modelURL>http://www.dresden-elektronik.de</modelURL>
		<serialNumber>000000000000</serialNumber>
		<UDN>uuid:23fcaa74-9217-4717-8fec-6c8204a8db56</UDN>
		<presentationURL>index.html</presentationURL>
		<iconList>
			<icon>
				<mimetype>image/png</mimetype>
				<height>48</height>
				<width>48</width>
				<depth>24</depth>
				<url>hue_logo_0.png</url>
			</icon>
		</iconList>
	</device>
</root>

[manup]

I'm having a bit of a problem getting the discovery running. I have marthoc/deconz:amd64-2.05.44 running in a boot2docker machine on a Windows 10 host that I created with a bridged network using vagrant. (Although I have very similar behaviour with the desktop application, except there's the correct IP in the description.xml).

Just testet it, the service should work (in my case the -6). Is your docker container allowed to connect to internet? The discovery works by matching the external IP addresses.

One more thing that I observed: in the http://192.168.178.37/description.xml I found a wrong IP address (as you see below). I tried setting this manually, but it didn't change anything.

Looks like the IP address uses inside the container? Not sure but it might be the case that the Docker container doesn't know the outside IP address of its bridged network.

[ict]

Just a quick chime-in that if have experienced the same thing this week (Discovery only returning "[]", Homeassistant not beeing able to find the hub). I was also using the docker image mentioned. As a quick fix, you can manually tell homeassistant where to look using "deconz: { host: <IP }" in the configuration.yaml.

I have since switched to using the "official" raspbian image directly on a spare Pi3, so I can't be of further help in resolving this.

[baflo]

Looks like the IP address uses inside the container? Not sure but it might be the case that the Docker container doesn't know the outside IP address of its bridged network.

I just checked again, the docker containers do have access to the internet.

Looks like the IP address uses inside the container? Not sure but it might be the case that the Docker container doesn't know the outside IP address of its bridged network.

That's true, it's the IP of eth0 of the container. eth1 is the bridged interface. Is there a way to tell deconz which interface to prefer? Like with vladgh/minidlna in the DLNA example I posed above. That allows to set the interface.

Meanwhile it worked with the desktop app, but description.xml also shows wrong IP, the one of Hyper V`s vEthernet adapter (although Hyper-V is deactivated).

The discovery works by matching the external IP addresses.

How long is the update time? I shutdown all deconz instances some time ago and it still gives a valid response.

@ict I will try that, I couldn't find that configuration in the home assistant docs|

[ebaauw]

I double checked: both discovery through UPnP as well as discovery through the dresden-light appspot work for me (running deCONZ on a Raspberry Pi). I did receive one issue on homebridge-hue (ebaauw/homebridge-hue#393) that deCONZ is no longer disovered. I'm not sure yet what's happening there yet.

Note that for UPnP discovery to work, the client and the server running deCONZ need to be on the same IP subnet, as UPnP uses local link multicast. When running deCONZ in a container or virtual machine, make sure it's configured with a bridged network. The host should not do any routing to the container or vm; the IP address of the interface in the container or vm should be in the same subnet as the IP address of the host. The same holds for running homebridge in a container or vm: Bonjour is using local link multicast as well.

Note that for appspot discovery to work, the client and server running deCONZ need to use the same public IP address, and both need to use the same IP family (IPv6 or IPv4) connecting to the appspot portal. This is more strict than Hue bridge discovery; the meethue portal is only reachable over IPv4.

To check what's discoverable, you can run ph discover from the command line on your client. It queries UPnP, the meethue portal, and the deCONZ appspot portal, using IPv4 and IPv6. ph is from the homebridge-hue-utils, which is included in homebridge-hue. For full debugging, run DEBUG=* ph discover - this allows you to see which method (UPnP, appspot IPv4, appspot IPv6) returns which gateway.

[baflo]

First of all, thank you all for the quick replies. @ict, the manual configuration worked.

My setup is actually relatively small. It's one Windows device in one network with one (static) public IP address. On that device, I've got a bridged Virtualbox running with docker. All containers in question run with --net=host mode.

Windows device: 192.168.178.47
Virtual Machine: 192.168.178.48

To check what's discoverable, you can run ph discover from the command line on your client.

Where do I find that tool? It doesnt seem to be in the desktop package and neither in marthoc's container.

[ebaauw]

https://github.com/ebaauw/homebridge-hue-utils

I thought they now bundle homebridge-hue with deCONZ, but maybe they only install it just-in-time.

[baflo]

Turned out the major problem was the port. I had deconz running on port 7080, but after I changed it to port 80, everything works like a charm. Almost at least. OpenHAB discovered the server as well as Home Assistant and ph.

However, all find container's NAT IP instead of the bridged network IP. Can I pass deconz a network adapter to use?

[ebaauw]

I don’t think you can. Why do you need two interfaces on the container? Can’t you just only use the bridged network?

[baflo]

The NAT is a vital part of the vagrant setup. It's somehow required for all the provisioning (and sshing). There's a documentation though which explains how to change the default gateway. I'll try that.

More of a drawback is the dependency on port 80. Is this correct or should it work on any port?

[ebaauw]

The NAT is a vital part of the vagrant setup. It's somehow required for all the provisioning (and sshing). There's a documentation though which explains how to change the default gateway.

Sounds like you setup the container software to create its own network segment, where the host doubles as NAT router between the host network and the container network. In this case the container’s default gateway is the host adddress on the container network. If your Internet router does NAT as well, you might run into double NAT issues.
In bridging setup, the container uses the host network directly, and there’s no routing nor NAT on the host. In this case, the container’s default gateway would be the same as the host’s, typically your Internet router.

More of a drawback is the dependency on port 80. Is this correct or should it work on any port?

You can specify which port to use when starting deCONZ using --http-port. However, some Philips Hue apps (the Alexa skin?) might only work with port 80. In homebridge-hue and ph you can include the port in the host. I don’t know OpenHAB.

[baflo]

I totally agree, that for the use case running deCONZ in the local network the NAT is not necessary. I'm still researching in this, but I think the VM's NAT is used only for vagrant's provisioning tools and solely required locally. Vagrant's requirement to have the NAT as eth0 is pretty irritating as the Linux guest will take eth0's outgoing IP as default and thus all configuration files are wrong. So I either change the provisioning tools (which I'd rather not do) or I have to find some way around.

You can specify which port to use when starting deCONZ using --http-port.

Is there a list of other command line parameters? I only found --http-port and --ws-port.
It would be particularly helpful if I could pass the IP address to use.

I don’t know OpenHAB.

You're right, that's something for another discussion :)

[baflo]

It would be particularly helpful if I could pass the IP address to use.

Hm, doesn't seem so L275

[ebaauw]

Is there a list of other command line parameters?

I’m afraid that’s still on @manup ‘s todo list. Afaik, there’s no way to specify the IP address or network interface.

[oscar-b]

@baflo See #702, I need this as well when trying to run deCONZ in a Docker network with Traefik as a reverse proxy. Will add some more details there since I tried to get it up and running yesterday again.

[Kane610]

This worked previously for me, has gotten broken down the line. Can't say if it is the container or deconz itself.

Running https://dresden-light.appspot.com/discover from Safari on the same machine yields []

[oscar-b]

I had the same a couple of days ago, then it started working again without any changes on my side. It’s working here at the moment.

[ebaauw]

Note that appspot only works if deCONZ and the client both use IPv6 or both use IPv4. What happens if you get the url using curl -4 https://dresden-light.appspot.com/discover vs curl -6 https://dresden-light.appspot.com/discover?

[Kane610]

It get [] on all machines I run it on

[baflo]

I still get the [], but was able to connect it on home assistant with the manual configuration, even on another port:

# deCONZ
deconz:
  host: home
  port: 8080

[manup]

You may also check if Internet Discovery is enabled in the old WebApp Advanced Settings (reachable from Phoscon App > Help).

[baflo]

It's activated, but as it's connected now, I'd as well turn it off ^^

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.