I have an RPI zero W that I’m running rasperian lite on. All my hardware devices on it have python library support. I need to accomplish two items to make this work:
There’s a couple different ways to go here. If local execution is a priority, then yes, some kind of interface with an Edge driver will be required.
Alternatively, you could use the direct connected device schema which would avoid all the comms coding since you use a simple API to integrate to SmartThings (via their cloud). The tradeoff is a bunch of sw & configuration work to do on your Pi to enable it. I have a package that automates the install and config and lets you have an example switch app up and running in about 30 minutes. It’s oriented towards C-language apps but I have an API wrapper that allows you to code in Python as well.
Back to the Edge alternative - it will require you to learn how to write Edge drivers in Lua and as you point out, some kind of LAN protocol linkage between the Edge driver and your Pi app. This can be as simple as HTTP requests, but if you are concerned about having a more robust interface where the Edge driver can automatically discover your device app and monitors when your Pi is on and offline, etc. then you’ll need to implement something like UPnP or mDNS. I have Lua libraries to help with either of these.
If your capability requirements are basic (on/off switch, motion detection, simple triggers, etc) then another alternative I can offer is to use my forwarding bridge server and existing Edge drivers to integrate with SmartThings from your device app. This would avoid you having to do a lot of coding - could possibly avoid having to do an Edge driver altogether - but would not be an auto-discover/health monitoring solution.
If any of these options interest you, I’m happy to provide more pointers and guidance.
Thanks TAustin,
I’m wanting to do option two - the edge alternative that’s discoverable. Sure, I’ll do more code up front, but a lot of that will be a one time investment - if I code it right.
Dave
The most robust way to go would be to use SSDP, which is part of the UPnP specification.
mDNS would be easier for discovery, but its device health monitoring capability isn’t nearly as robust. However you could do some kind of a hybrid approach and have your device app advertise on mDNS, and then once you have the connection established with the Edge driver, then have some kind of simple periodic polling mechanism.
SSDP takes care of all that, and I have a Lua library to make it pretty easy on the Edge side of things. It may require more implementation work on the device app side, however I would suspect you could find an SSDP support library for Python. If you find a good one, let me know (I rolled my own for one of my Pi device apps).
Links:
My UPnP library
My mDNS library
caveat: Matter, once released, promises to be the latest and greatest way to integrate IoT devices, but who knows how long that will be or how much work it will be for developers to implement…
Thanks. I’ll let you know how it goes.
This is a question about SSDP.
My hub is at 192.168.4.20 and my nodeMCU device (this is not RPI) is at 192.168.4.67. Also, I have an Arlo Hub at 192.168.4.239. I’m trying the lightbulb example from the SmartThings edge tutorials. When I start scanning for the device the nodeMCU sees this come in:
status: M-SEARCH * HTTP/1.1
headers
host: 239.255.255.250:1900
mx: 4
st: urn:SmartThingsCommunity:device:LightBulbESP8266:1
Here’s the debug from the modeMCU device below. It believes it got the request from the Arlo HUB.
SSDP RESPONSE:
IP: 192.168.4.239:58292
HTTP/1.1 200 OK
Cache-Control: max-age=100
EXT:
SERVER: NodeMCU/Lua5.1.4 UPnP/1.1 LightBulbESP8266/0.1
ST: upnp:rootdevice
USN: uuid:dc9ee1-SN-ESP8266-696
Location: http://192.168.4.67:80/LightBulbESP8266.xml
I pulled out my wireshark and started looking at this closer. It seems that the MAC address is of the ST HUB, but the IP is the Arlo HUB. Why would the ST HUB spoof another’s IP?
This is an addition to the sample code, isn’t it? That just the IP and port from the function parameters?
Is that what Wireshark is showing?
Hi Todd,
Since I’m having issues with the ST HUB with SSDP, I switched over to your RPI direct-connect solution. I love your master script. It makes everything so easy.
When onboarding the RPI fails to switch over to the selected network. Here you can see that the network is called “fios 2.4g”. Sorry I couldn’t cut-n-paste it here, but I did drop a picture for you to see. Let me know what you think I should look at.
Thanks, Dave
Did I say something wrong?
I saw this once just before the video tutorial was released. In that time the router was an Ubiquiti Router which was replacing the whole Location header from the SSDP Response.
Tagging @jody.albritton since he is the one that has the Ubiquiti = ]
(btw, greetings Jody)
Since you replied to your own post, it’s quite likely that @taustin just hasn’t seen your question. 
It gets pretty busy around here, so if you have a question for a specific person, it’s best to do one of the following three things:
post it in a thread that they are the original author of
reply directly to one of their posts
or tag their forum name in your post with the @ sign
In any of those three cases, they will get a notification about your new post. Otherwise they may not see it.
Hey sorry, I had not seen your post until now!
Is there another SSID you could try? I’ve never tested an SSID myself that has a space in the name, so I don’t know if that could be an issue or not. It shouldn’t be, but you never know. If it’s possible - just to rule this out - could you change your SSID to replace that space with an underscore?
A couple more questions:
Hi Todd. It’s definitely the space in the SSID that did it. I created another one without the space and it worked fine.
Gee, how did you know I’ve got a 3 port Ubiquiti router 
So what you’re saying is that it wasn’t the Arlo HUB that replied, but the router - and it spoofed both the MAC and the IP?
@jody.albritton, did you ever get a fix for that?
Awesome! I’ll have to look where the space isn’t being handled: it could be my code or elsewhere.
@dcabot25 I haven’t had any issues with routing on Unifi devices. The only issues I have had in the past have been with Wifi 2.4 - I created a separate SSID called IOT_devices24 and set it only to 2.4 ghz and the default channel width.
If anyone is still interested I wrote a python device for the example lightbulb-lan Sample. There are apps are discovery.py and device.py. Run both together for pairing and the discovery.py responds, exits, and device.py takes over. Once it’s paired just run device.py It’s a bit hard coded but was for my own learning as I move on to porting it to the Arduino IDE (wemos d1 mini) next.
