Hi Denis-
This is part of what I need to document.
Start with the overview of directly connected devices here.
Then read through Jody’s original announcement post for the SDK here.
Beyond that, here is a rough outline of how things work in a PI configuration:
- The device definition is done in the developer workplace per Jody’s instructions.
- The SDK C code is compiled on the PI with my PI module replacing their ‘POSIX’ one, and linked with your own device driver code that uses the ST APIs to send/receive commands and attributes to ST. Also critical to be included are 2 json files that are created through the developer workplace that contain device and onboarding info.
- The PI has to be set up to mimic the wifi provisioning behavior of a typical microcontroller. If you’ve ever provisioned a wifi IOT device (like a Ring cam) you’ll know that it’s a convoluted process of connecting your phone’s wifi to the device’s own wifi access point temporarily to configure it and tell it what access point (usually your home’s wireless router) you want it to normally communicate with. Then you finish that and reconnect your phone back to your wireless router. Then hopefully the device connects successfully to your home’s wifi. This is called Soft AP and it’s derided in the industry as being very user-unfriendly and causes endless customer calls because it’s very confusing to most people. But it’s the only solution there is right now to provision new wifi-based devices. Anyway, that’s really the main hurdle there was to making this all work on the PI. I use two modules: hostapd and dnsmasq that can turn your PI into it’s own access point so that the provisioning process can be completed, because this is what the ST mobile app requires in the add-device process (see next).
- Once your PI-based device app is successfully compiled and linked to the SDK, you fire it up and it then starts demanding to be put in either access point mode or station (normal) mode depending on what it’s doing. You then go through the add-device process on the ST mobile app and it attempts to find a wireless AP with the SSID containing your device name & serial number. Once it finds it, it’s now talking to your PI and exchanges device info and the PI is given the info it needs to go and connect to ST’s MQTT server.
- At this point provisioning is complete, and the PI operates in regular station mode and connects to the ST server via MQTT protocol. (And frankly I don’t think it really needs wireless at all at this point - it could happily communicate over wired ethernet once provisioning is complete).
- The PI device app implements callbacks to capture device commands and updates from ST, and uses API calls to update the same back to ST. It’s a very simple API set and all the MQTT communication is done under the covers.
Luckily the direct connect SDK was designed to accommodate additional device platforms to what they currently support. It just requires some coding to create the platform-specific modules it needs. For the PI, I only needed to take care of the wireless module. They already had POSIX versions for the rest of the required ones, which work as-is on Raspbian.
Overall, even though it took me a while to figure this all out and do the necessary system config and coding to get it to work, once that is all done, it’s actually super simple. It’s really just the provisioning part that’s a pain.
Very little of the above is documented anywhere. There is a porting guide on the SDK github here but it doesn’t explain anything, just lists the functions you need to write. But now that I’ve already done the work for PI, you don’t really need to know that level of detail unless you want to create one for another platform.
Hope that helps your understanding!
Todd