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.
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).
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:
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.
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:
Is that the same SSID that your Pi was initially connected to when you started the onboarding process?
Is there anything unique or unusual about your Pi hardware setup? Are you using the stock wifi device?
Do you have an Ethernet connected to your Pi or is it only connected via wireless?
@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.