Non exclusive usage of port 1900

[mat1990dj]

I'm using deconz together with pimatic to give pimatic access to the few zigbee devices I've got an to make pimatic the "brain" of my smart home. This means that I access the devices connected to deconz via pimatic as is where I've got all the rules.

On pimatic I've loaded the amazon echo plugin that uses port 1900 for SSDP so that pimatic publishes the devices on the raspberry pi port 1900 the devices.

Now when starting deconz it's also trying to get port 1900 and i've got to be very carefull on the startup order so that pimatic gets port 1900 and not deconz.
It would be great to remove that port 1900 unlock

Edit: I though the issue was anotherone

[ooii]

What about changing the port of deconz? That can be done in the config file like ExecStart=/usr/bin/deCONZ -platform minimal --http-port=8080.

[mat1990dj]

I've already changed the port but it seems that the 9000 is always used in a fixed way, as I think that homekit protocol enforces that port usage

[ebaauw]

No, the port used by homebridge is specified in ~/.homebridge/config.json. deCONZ-homebridge.sh creates this file when it's not already present and sets the port to 51826.

[mat1990dj]

Then what is using port 9000?

[ooii]

You only can tell. You can use either netstat or lsof (and google) to find which program is listening on that port.

[mat1990dj]

As I've edited on the main message, I was mistaken, the conflicting port is 1900.

[ebaauw]

Ok, UDP port 1900 is used by UPnP - nothing to do with HomeKit nor homebridge (they use Bonjour for discovery instead). The deCONZ REST API announces itself to UPnP and tries to discover other deCONZ gateways for the Gateway Cascade feature (see #287).

Now deCONZ should open the port in shared mode (so multiple services can use the port at the same time). There was an issue that it didn't, caused by an older version of QT. What platform are you running deCONZ on? What version?

The problem could also be that pimatic tries to open the port exclusively.

[mat1990dj]

I'm running deCONZ on raspbian jessie, deCONZ version 2.05.23

[ebaauw]

See #274 how to prevent deCONZ from using UPnP altogether.
See #83 for the issue of deCONZ not opening the port in shared mode. I think is was corrected way before 2.05.33, but maybe it's the Jessie implementation of QT?

You could try my upnp utility from https://github.com/ebaauw/homebridge-hue-utils to check whether deCONZ or pimatic is the culprit. Start one of these and run upnp -l. If it reports an EADDRINUSE error, you know the one running opened the port exclusively.

[mat1990dj]

Ok, so I tried the utility and gives me EADDRINUSE. I'll try upnp=0 when I get back home for now. It seems it's because of Jessie's qt

[FWillems]

For me a comparable issue was solved by using

deCONZ --upnp=0

https://forum.pimatic.org/topic/4370/solved-pimatic-and-raspbee-deconz-on-same-raspberry-pi/2

[mat1990dj]

Ok thanks