Lightbulb-lan-esp8266 Sample Driver - Is there a bug/limitation in the discovery?

I am trying to base a driver on the lightbulb-lan-esp8266. I notice that the discovery.code only seems to find the first advertised device. Am I misunderstanding the code? There is a comment ‘-- This function enables a UDP
– Socket and broadcast a single
– M-SEARCH request, i.e., it
– must be looped appart.’
But I can’t see this being addressed? If not that’s fine, I will address it, but I am concerned I am missing something -:slight_smile:

Hey, @Davec

You’re right, we kept the discovery flow as simple as possible, as it was meant to integrate just the board.


Can you please describe the workflow you consider accurate for this section?

With this info, I’ll check if it can be addressed to provide a better reference on the discovery workflow for LAN integrations.

Thanks for responding

Can you please describe the workflow you consider accurate for this section?

Yikes,…I’m sure there are others better qualified…but I’ll give it a go!

I am using the USN field on the ssdp advertisments to provide a unique id for each device discovered from find_device (ie the ssDP search)

I maintain a table of ‘discoveredDevices’ with the USN as a key then I supply discoveredDevices to find_device and it ignores an advertisment response either without a USN or with a USN that is in my table of discoveredDevices. I fiddle a bit with the timeout to allow for multiple search results. but this may be unnecessary or just wrong.

Was this what you meant?

Certainly! So, if I understand correctly the following two lines…

I am using the USN field on the ssdp advertisments to provide a unique id for each device discovered from find_device (ie the ssDP search)

I maintain a table of ‘discoveredDevices’ with the USN as a key then I supply discoveredDevices to find_device and it ignores an advertisment response either without a USN or with a USN that is in my table of discoveredDevices.

You’re saving the USN (uuid) in a table, so you can have a reference of the devices that already replied to your M-SEARCH and are part of your environment, right?

I believe that handling this flow manually is not necessary, as long as you keep the device network Id according to the Location attribute of the SSDP Responses, because it is going to be unique under your LAN and the SmartThings API won’t generate a new device with the same DNI.


Regarding the timeout you refer to:

I fiddle a bit with the timeout to allow for multiple search results

This can be addressed by scheduling the discovery flow, instead of looping it and shutting the task down with a one-shot timer, this way the discovery flow would run as long as the app scan does. So, I’ll comment it out to check it can be included in the sample.

1 Like

Yep!!!

Ah! Well I made a decision that I wasn’t going to go with that approach :roll_eyes: This is a probably a bad decision!!! I did in fact adopt that approach for my groovy implementation, I didn’t like it though! My rationale was that my lan service (ie server) will be managing a number of devices and rather than assigning a port for each device I thought it was more in keeping with the ssdp protocol to use a uuid as a device identifier given I was going to have to use ssdp anyway, I can always go back and change it if I discover it is a horrible mess!!!

Thanks so much…I will investigate and try this.

Just to say I am having a blast with smartthings edge. I love it!!! You guys are great. Learning code has been a bit steep but I’m really enjoying it. I discovered my first two devices just now and feeling very pleased.

1 Like

I can’t resist!: my UPnP library will free you from all of these details AND provide you with ongoing automatic device online/offline monitoring, and subscription and command send handling. :grin:

1 Like

Haha. Yes and I am looking at it as well. I am enjoying learning Lua and edge though

The issue with using your library is that I would need to tighten up my server implementation to better support ssdp/upnp. That seems less fun than delving in to edge

Maybe not; the library is flexible enough that you could use just the discovery API and nothing else. You actually don’t even have to use monitoring if you don’t want, but I suspect most cases it would be desired.

I know you know :wink: Just couldn’t pass up an opportunity to advertise for anyone seeing your post! Have fun; I know I am!