Bridge Discovery - dresden-elektronik/deconz-rest-plugin GitHub Wiki

This page compares the discovery of a Hue bridge to the discovery of deCONZ.

Overall conclusion: discovery of deCONZ differs from Hue bridge discovery, requiring app changes to support deCONZ. While some differences (e.g. a different vendor portal, using a different port than 80) cannot be avoided, there seem to be more incompatibilities than strictly needed. While the Hue bridge provides consistent information between UPnP, the MeetHue portal, the XML description and the /config resource, deCONZ does not. Furthermore, deCONZ lacks support for an unauthenticated GET of /config.

UPnP

Both the Hue bridge as well as deCONZ support UPnP.

UPnP Search

When doing an UPnP M-SEARCH discovery request, the Hue bridge responds with:

HTTP/1.1 200 OK
HOST: 239.255.255.250:1900
EXT:
CACHE-CONTROL: max-age=100
LOCATION: http://192.168.xxx.xxx:80/description.xml
SERVER: Linux/3.14.0 UPnP/1.0 IpBridge/1.17.0
hue-bridgeid: 001788FFFExxxxxx
ST: upnp:rootdevice
USN: uuid:2f402f80-da50-11e1-9b23-001788xxxxxx::upnp:rootdevice

The hue-bridgeid header field contains the serial number of the Hue bridge. This serial number is based on the bridge's Ethernet MAC address (and differs from the bridge's ZigBee MAC address). Likewise, the UUID is based on the Ethernet MAC address.

Note that the Hue bridge returns too many responses, and doesn't honour the search parameters, see the Hue Developer Forum.

When doing an UPnP M-SEARCH discovery request, deCONZ responds with:

HTTP/1.1 200 OK
CACHE-CONTROL: max-age=100
EXT:
LOCATION: http://192.168.xxx.xxx:80/description.xml
SERVER: FreeRTOS/7.4.2, UPnP/1.0, IpBridge/1.8.0
ST: urn:schemas-upnp-org:device:basic:1
USN: uuid:b956a558-ab10-4875-95fd-d5b66cba20f9::upnp:rootdevice
GWID.phoscon.de:0x00212effffxxxxxx

The GWID.phoscon.de header field is based the ZigBee MAC address of the RaspBee board. It looks like there's a space missing after the colon?

UPnP Announcements

The Hue bridge sends the following UPnP SSDP alive messages:

NOTIFY * HTTP/1.1
HOST: 239.255.255.250:1900
CACHE-CONTROL: max-age=100
LOCATION: http://192.168.xxx.xxx:80/description.xml
SERVER: Linux/3.14.0 UPnP/1.0 IpBridge/1.17.0
NTS: ssdp:alive
hue-bridgeid: 001788FFFExxxxxx
NT: urn:schemas-upnp-org:device:basic:1
USN: uuid:2f402f80-da50-11e1-9b23-001788xxxxxx

The deCONZ rest API sends the following UPnP SSDP alive messages:

NOTIFY * HTTP/1.1
HOST: 239.255.255.250:1900
CACHE-CONTROL: max-age=100
LOCATION: http://192.168.xxx.xxx:80/description.xml
SERVER: FreeRTOS/7.4.2, UPnP/1.0, IpBridge/1.8.0
NTS: ssdp:alive
NT: upnp:rootdevice
USN: uuid:b956a558-ab10-4875-95fd-d5b66cba20f9::upnp:rootdevice
GWID.phoscon.de:0x00212effffxxxxxx

Conclusion

Both the Hue bridge and deCONZ can be discovered through UPnP, by scanning for IpBridge in the SERVER header field, but additional validation is required to determine what type of IpBridge we've found. This could be by checking the XML description provided by the LOCATION header field, or, preferably, by querying the bridge configuration, see below.

Alternatively, a Hue bridge can be recognised by scanning for the hue-bridgeid header field, and deCONZ by scanning for the GWID.phoscon.de header field, but this requires app changes.

Portal

Both the Hue bridge and deCONZ register themselves with the respective vendor portal.

Portal Response

The MeetHue portal at https://www.meethue.com/api/nupnp returns the following JSON body:

[
  {
    "id": "001788fffexxxxxx",
    "internalipaddress": "192.168.xxx.xxx"
  }
]

The id attribute contains the Hue bridge serial number, based on the Ethernet MAC address. This is consistent with the hue-bridgeid header in UPnP discovery.

The dresden elektronik portal at https://dresden-light.appspot.com/discover returns the following JSON body:

[
  {
    "internalipaddress": "192.168.xxx.xxx",
    "internalport": 80,
    "id": "b8:27:eb:xx:xx:xx",
    "name": "pi",
    "macaddress": "b8:27:eb:xx:xx:xx"
  }
]

The id attribute contains the (Ethernet) MAC address of the Raspberry Pi running deCONZ. This differs from the GWID.phoscon.de header in UPnP discovery.

Note that the Hue bridge always uses port 80, whereas deCONZ might use a different port.

Conclusion

Both the Hue bridge and deCONZ can be discovered through their respective vendor portals. As these are different portals, an app change is needed to include the dresden elektronik portal.

Description

The Hue bridge XML description contains the following:

<?xml version="1.0" encoding="UTF-8" ?>
<root xmlns="urn:schemas-upnp-org:device-1-0">
  <specVersion>
    <major>1</major>
    <minor>0</minor>
  </specVersion>
  <URLBase>http://192.168.xxx.xxx:80/</URLBase>
  <device>
    <deviceType>urn:schemas-upnp-org:device:Basic:1</deviceType>
    <friendlyName>philipshue (192.168.xxx.xxx)</friendlyName>
    <manufacturer>Royal Philips Electronics</manufacturer>
    <manufacturerURL>http://www.philips.com</manufacturerURL>
    <modelDescription>Philips hue Personal Wireless Lighting</modelDescription>
    <modelName>Philips hue bridge 2015</modelName>
    <modelNumber>BSB002</modelNumber>
    <modelURL>http://www.meethue.com</modelURL>
    <serialNumber>001788xxxxxx</serialNumber>
    <UDN>uuid:2f402f80-da50-11e1-9b23-001788xxxxxx</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>

Note that the serialNumber matches the hue-bridgeid UPnP header and the MeetHue portal id attribute.

The deCONZ XML description contains the following:

<?xml version="1.0"?>
<root xmlns="urn:schemas-upnp-org:device-1-0">
  <specVersion>
    <major>1</major>
    <minor>0</minor>
  </specVersion>
  <URLBase>http://192.168.xxx.xxx:80/</URLBase>
  <device>
    <deviceType>urn:schemas-upnp-org:device:Basic:1</deviceType>
    <friendlyName>Philips hue (192.168.xxx.xxx) compatible Wireless Light Control Gateway</friendlyName>
    <manufacturer>Royal Philips Electronics</manufacturer>
    <manufacturerURL>http://www.dresden-elektronik.de</manufacturerURL>
    <modelDescription>dresden elektronik Wireless Light Control</modelDescription>
    <modelName>Philips hue bridge 2012</modelName>
    <modelNumber>929000226503</modelNumber>
    <modelURL>http://www.dresden-elektronik.de</modelURL>
    <serialNumber>819929332</serialNumber>
    <UDN>uuid:b956a558-ab10-4875-95fd-d5b66cba20f9</UDN>
    <gatewayName>pi</gatewayName>
    <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>
      <icon>
        <mimetype>image/png</mimetype>
        <height>120</height>
        <width>120</width>
        <depth>24</depth>
        <url>hue_logo_3.png</url>
      </icon>
    </iconList>
  </device>
</root>

I have not been able to figure out where the serialNumber or modelNumber come from.

Conclusion

Apart from the modelName, the XML description doesn't seem particularly useful. Note that a v1 Hue bridge also uses Philips hue bridge 2012.

Bridge Configuration

The Hue bridge allows an unauthenticated GET of /api/config (as opposed to the authenticated /api/<username>/config). It returns the following:

{
  "name": "philipshue",
  "datastoreversion": "60",
  "swversion": "01038390",
  "apiversion": "1.17.0",
  "mac": "00:17:88:xx:xx:xx",
  "bridgeid": "001788FFFExxxxxx",
  "factorynew": false,
  "replacesbridgeid": null,
  "modelid": "BSB002"
}

Note that bridgeid is consistent with the UPnP hue-bridgeid header field, the MeetHue portal id attribute, and the serialNumber in the XML description. Also note the consistency of other info, like the modelid with the XML description and the apiversion with the UPnP SERVER header field.

deCONZ doesn't provide a way to verify the device unauthenticated. An authenticated GET /api/<username>/config returns:

{
  "apiversion": "1.0.0",
  "dhcp": true,
  "gateway": "192.168.xxx.xxx",
  "ipaddress": "192.168.xxx.xxx",
  "linkbutton": false,
  "localtime": "2017-04-15T13:02:22",
  "mac": "b8:27:eb:xx:xx:xx",
  "name": "pi",
  "netmask": "255.255.255.0",
  "networkopenduration": 600,
  "panid": 00000,
  "portalservices": false,
  "proxyaddress": "none",
  "proxyport": 0,
  "swupdate": {
    "notify": false,
    "text": "",
    "updatestate": 0,
    "url": ""
  },
  "swversion": "20440",
  "timeformat": "24h",
  "timezone": "Europe/Amsterdam",
  "utc": "2017-04-15T11:02:22",
  "uuid": "b956a558-ab10-4875-95fd-d5b66cba20f9",
  "websocketport": 443,
  "whitelist": {},
  "wifi": "not-installed",
  "wifiappw": "",
  "wifichannel": "1",
  "wifiip": "192.168.8.1",
  "wifiname": "Not set",
  "wifitype": "accesspoint",
  "zigbeechannel": 25
}

Note that modelid and bridgeid are missing and that apiversion is wrong.

Conclusion

In it's current form, the deCONZ bridge configuration doesn't help in bridge discovery and validation.

Home Remember : Not all devices listed here are supported by deconz.

⚠️ **GitHub.com Fallback** ⚠️