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 -
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 
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. 
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 
Just couldn’t pass up an opportunity to advertise for anyone seeing your post! Have fun; I know I am!
Hi guys,
I am actually running into some problems related to this topic. I have set up an ESP8266 device and smartthings station following the updated tutorial: SampleDrivers/lightbulb-lan-esp8266 at main · SmartThingsDevelopers/SampleDrivers · GitHub.
The issue is that when the ESP board is alone without other standby devices, ST app is able to discover it easily. However, when there are multiple other advertising devices on the same network sending NOTIFY messages, ESP seems to be unable to receive M-Search messages from the edge driver (In the logs, it receives and prints out NOTIFY messages from all other devices on the network, M-SEARCH message from Windows, but not ST App).
One of the solutions I see from @Davec’s repsonse is potentially setting up different port for different device. Since I only need to connect to one ESP device, this solution makes sense for me. So I change the SSDP port from 1900 to 1899. This solution works when the ESP board is the only device on network, but seems to not work when there are other devices. Can you confirm with me if this solution is valid logistically?
The other solution I see as David mentions is keeping a list of uuid. Did you get that from this line local res = upnp:receivefrom()?
As for making the searching time longer, the option I found is increasing MC_TIMEOUT in the config file. I am not sure if @erickv you have implemented scheduling the discovery flow. I did see a while loop in function disco.start under discovery.lua though. It seems like it will keep trying find_device until a valid response.
I know this topic has been closed for a while and there is some updates that I may not be aware of, but any help would be appreciated.
Thanks!
Hi, @jackj
Sorry for the delay. I asked the team about your case to see if we can single out the device more efficiently, so, once I get more info, I’ll let you know.
Thank you @nayelyz. I also try to further debug the situation. Another surprising issue I found is that: even though in the ST app under the driver section, I can see my driver is installed on the hub. When I try to use logcat to listen to the driver for debugging, the CLI shows no driver was available on the ST station. Can you tell me if this issue ever happen? I did reset the hub by removing it from ST room and re-add it, re-enroll the hub to my channel and install the driver by using ST app.
One more question: Is it possible to listen to the logs from ST edge driver from a different network? For example, my station is connected to one network and I am trying to remotely check the logs from the station from another network?
Thanks!
No, this needs further information. Did you confirm you can also see the Edge driver installed through the CLI? You can use the command smartthings edge:drivers:installed
The account you used for the CLI is the same one where you claimed the Hub? It might be a permissions issue.
I’ve tried it in the past and no, you must be in the same network, or have something that allows you to enter the one where the Hub is connected (I haven’t verified this last part) since you use the local IP, not the public one. Have you tried accessing the Hub’s network from the other one to see if it works?
Thanks for the help. I used smartthings edge:drivers:installed -H HUB_ADDRESS and I can see the driver is installed in the remote hub. However, if I only put smartthings edge:drivers:installed, the hub list only includes two stations (I have multiple stations enrolled under my account across different locations). The only difference is that these two stations are in the same location where my account is the owner. While the other remote hub is in a different location where I am a member of the room. We try to get on my developer account in the remote location and use CLI, and the issue with “no driver” is shown. It is authorized.
We can definitely try accessing hub’s network as well.
When you do smartthings edge:drivers:installed the CLI will find all your hubs and then filter out those in Locations that are shared with you because, according to the comments in the code, you can’t manage Edge drivers on those hubs. This is generally true across the Edge support in the CLI - you need to be the owner of the hub to do the Edge stuff. This may have been necessary once but whether it is currently necessary is another matter.
As you have seen you can do smartthings edge:drivers:installed -H {{hubId}} and the CLI will happily show you the installed drivers because there isn’t any restriction in the API. You can manage channel enrolments and driver installations via the channel subscription URLs whether you own the hubs/locations or not. The mobile clients will show you the Driver menu whether you own the hubs or not (but that didn’t used to be the case).
That isn’t to say there aren’t quirks. You can only access the channels API if you own the channels or you are subscribed to them. So you could potentially see which drivers are installed but then not be able to read their metadata.
Got it. so enrolling hub into my channel doesn’t mean I own the hub. In my case, two stations in my local network are set up using my account and the remote station is set up using another person’s account. I have enrolled that remote station into my channel and installed the driver. If I use my smartthings account to start CLI in the remote location, and use logcat, I should still be able to see/listen to the driver I installed on that remote station, right? I actually did a similar test in another remote location (set up a 4th remote station with another account, try to use my account in that remote location to logcat) and it works, so I am really confused on why logcat will show no drivers to listen to at that remote station.
And even though the driver is shown to be installed on the remote station, it seems to be never initiated during “scan by nearby devices”. I didn’t modify much on the UPnP part from the sample driver, so it should send out a M-SEARCH message to the network, ESP should be able to pick it up and print both driver’s M-SEARCH message and its own SSDP response in the serial port, but we never see neither.
Also the remote location is… I would say pretty security-heavy place (I don’t have much details on the security setup) Would any firewall or security block CLI access?
Hi, @jackj
The team mentioned that UDP has a general issue of dropping packages without warning. The ESP is choosing to drop the M-SEARCH message in favor of the NOTIFY message when congestion occurs. The change of ports could be useful but UDP Broadcast doesn’t consider it and sends the message to everyone.
The usage of UDP multicast would be a better solution for this case since it respects the IP address and port which can be changed to avoid congestion.
About the issue with the CLI, it would be useful to see if configuring different profiles with the respective Personal Access Tokens can help. You can take a reference from this page: smartthings-cli/configuration.md at main · SmartThingsCommunity/smartthings-cli · GitHub
Hi @nayelyz. thanks for the answers. So to change UDP from broadcast to multicast, do I just change this line in the sample driver: upnp:setoption('broadcast', true)?
As for PAT, I can try that as well. The thing is that, there is only one channel associated with my developer account, so the “default” channel will also be my channel. Since I input the hub IP address in logcat command, I don’t think it is pointing to the default hub right? I did see this post: As of 1 hour ago, I can no longer install drivers to my hub Am I the only one?. Seems like OP of this post also ran into a similar issue?
But you mentioned that the Hub was owned by another account, so, that is most likely the reason for the issue, there’s a limit on what we can do to others’ Hubs and channels/drivers, and some commands only show you the things the account you used to log in owns.
Have you tried using the Hub’s IP address and the driver ID in the same command? For example:
smartthings edge:drivers:logcat driverID --hub-address=X.X.X.X
I’ll double-check with the team.
The basic usage of a multicast socket would be something like the following
local cosock = require "cosock"
local socket = cosock.socket
local function find_devices()
local s = socket.udp()
assert(s)
local listen_ip = "0.0.0.0"
local listen_port = 0
local multicast_ip = "239.255.255.250"
local multicast_port = 1900
local multicast_msg = table.concat({
"M-SEARCH * HTTP/1.1",
string.format("HOST: %s:%s", multicast_ip, multicast_port),
"MAN: ssdp:discover",
"ST: ssdp:all",
""
}, "\r\n")
assert(s:setsockname(listen_ip, listen_port))
s:settimeout(8)
assert(s:sendto(multicast_msg, multicast_ip, multicast_port))
while true do
local recv_data, ip, port = s:receivefrom()
if not recv_data then
print("Error: ", ip)
goto continue
end
print(string.format("Recieved from %s:%s: %s", ip, port, recv_data))
::continue::
end
end
cosock.spawn(find_devices)
cosock.run()
The device will be updated to also listen for a multicast message on the same IP port. The IP address can be changed to any unreserved IP address in the range.
1 Like
I haven’t tried the command but I will give a shot. I actually tried to mimic a similar setup at my home: I have a brand-new hub owned by my personal account at my home (my developer account and personal account are two different accounts). I invite my developer account into the Room and enroll that hub, install the driver. Then I use my developer account’s CLI to logcat the hub and that works.
One thing I would like to make sure and get confirmed is whether the above process is logical. One thing maybe I can try is to invite the remote location’s account that owns that remote station to my developer channel and let the remote developer account install the driver?