[ST Edge] Issues with the Device Network ID

Developer Programs Writing Edge Drivers
1

I’ve run across a situation that is probably unique to LAN drivers that may require some design thought from the SmartThings team:

I believe it is the case that a driver cannot create a device with a device_network_ID that has already been created on the same hub, even if that device was created by a separate driver.

However, consider the following:

  • device_network_ID is commonly set to the UUID of the device.
  • There is no reason to believe that there may be more than one driver that recognizes the same LAN device.
  • If both drivers discover the same device- of course having the same UUID - then the first driver to discover will always win and the second driver will fail when it tries to create the device.

The above scenario is not merely hypothetical; I’ve already run up against it. I have UPnP driver that discovers all UPnP devices on my network and creates analogous devices for each. Subsequent to that I’ve been working on a Roku-specific driver, but ran into the device_network_ID conflict, since the Roku device is also picked up by the UPnP driver (it responds to SSDP discovery).

Long-term, perhaps the Edge Matter implementation will resolve this, but I think this needs to be addressed now since other LAN drivers will exist for a long time to come.

1 Like
2

The device_network_ID must be unique for every device, also the Zigbee and Z-Wave (node ID) devices receive a unique value during the joining process because it is used to route messages correctly to the device.

You could do the following to avoid this issue:

  • In the UPnP driver, filter the discovered devices and exclude all those that you don’t want to support.
  • In each driver (UPnP and Roku) concatenate a differentiable value in the device_network_id of the device. Eg:
    • http://roku:xxx (upnp-collector)
    • http://roku:xxx (roku-specific-driver)
      Then, when you send a command to the device, you can remove that extra identifier.
3

Sure, there are ways around it if you are the author of both drivers. But that’s not the point. I’m suggesting this is a DESIGN issue which does not anticipate this LAN device scenario. What if I’m not the author of two drivers that both use UUID for the device_network_ID??

Simply put, the current design PRECLUDES the ability to have multiple LAN drivers that my want to interact with the same device, and I’m asserting that this is a design flaw. It may make sense for zigbee/zwave devices, but not LAN devices. This should not be put on the driver to anticipate, but rather should be handled by the platform. If Edge needs to maintain a unique device identifier across drivers then IT should use a combination of driver ID and device_network_id.

If the SmartThings team disagrees, then they need to document this limitation or otherwise provide guidance in the LAN driver guide to NOT use UUID (the otherwise logical choice), but rather some other Edge-wide unique identifier.

3 Likes
4

Why not just prefix the device_network_ID with a value specific to the driver creating that device?

5

Shouldn’t we be using IP address for the device ID? That would work better with Matter. :thinking:

6

Couldn’t IP address change unless every device is assigned a fixed IP? I think device ID has to be fixed?

7

Good point. I always use fixed IPs for home automation, I don’t even think of it the other way. My bad. :sunglasses:

2 Likes
8

I wouldn’t think so, but we have to wait to see the spec. I would hope they’d support multiple logical devices behind one IP address.

1 Like
9

If that’s what we have to do then so be it. The examples and guidance I’ve seen commonly use UUID, but we now know that’s not safe to do.

1 Like