Long time listener, first time caller…
After looking at a variety of options, a month ago I decided to give SmartThings a try for my home automation system. Beyond the Z-Wave and ZigBee support, the primary attractor for me was its extensibility model for new devices and custom apps, because I know I will want to create and integrate various things that aren’t available commercially.
I also recently started playing with the Spark Core cloud-integrated microcontroller board. The simplicity of how one exposes variables, functions and events from the device, and the fact that it is basically an Arduino, makes it perfect for a whole host of custom sensors, actuators, etc.
The Spark boards expose themselves via a token-protected REST endpoint. After only a few minutes of digging, I found some pretty good examples of Smart Device Types that could read or activate via the endpoint. My experiments seemed to work well, but I found a few issues:
- Cloud-Connected Device Types only support polling for their data. Honestly, this sucks pretty bad if you want to use a Spark board as a sensor. One minute latency is terrible. Especially given that Spark supports an actual eventing model (using SSE).
- Although the Spark device is available on the LAN, and ST supports device event notifications for LAN-Connected devices, the only mechanism eventing mechanism supported by ST is UPNP, which is a terrible protocol to implement and much heavier than is actually required for this use case.
- The docs for anything other than Z-Wave or ZigBee HA devices are pretty poor. One complete example of a Service Manager + Device Type for each of Cloud- and LAN-Connected devices is really needed. Digging through the templates in the Web IDE is not a good solution.
- Creating a custom device type each time I create something with the Spark is annoying.
So I started thinking about to make a general reusable system for Cloud-Connected devices, for use by my custom Spark devices.
The following diagram shows what I’m thinking about at a high level, more detail in the text to follow.
Since the Spark publishes via the cloud, my plan is to use the Cloud-Connected Device Type model. As I said above, the examples I found for the device type are pretty self-explanatory and “just work”. But I wanted to add a Service Manager app to take care of the OAUTH login / access-token part.
To solve the polling/eventing issue, I am thinking about using the mapping{} section to add an HTTP Endpoint that the actual Spark device could call, triggering a refresh from the cloud. Spark supports publishing events, but they are SSE, which ST doesn’t support. I the diagram above, I’m showing the endpoint on the Service Manager since I could, in theory, have dozens of Spark boards running, and I’m not sure having dozens of different endpoints (one for for each device handler instance) is a good idea. I’m also not sure if I can use mappings{} in a device type (would love confirmation or an example).
Another thing I’m planning is to use a convention that maps the ST Capabilities model to Spark Device Types. So if I had a Spark core that was behaving like a switch, the Service Manager would instantiate a “Spark-Switch” device handler. That handler would know that it could expect to find a string property in the Spark cloud called “switch” with possible values “on” and “off”, as well as two functions, “on() and off()”, matching the definition of ST’s capability.switch.
Using this convention-based approach should make it very simple to create new (or even compound) device types, and also make the coding on the Spark side more consistent.
I’ve only started prototyping this approach, but I think it should work. I still need to create a working example of the notification REST API and confirm that I can configure the Spark to call it, but I think that is achievable.
If you have any thoughts or suggestions about this approach, please let me know. If it works, we might all be able to use these killer little inexpensive ($19 for the Photon) boards for custom devices, without the nightmare that is the current state of ZigBee HA / XBee.*
Thanks! I’ll post more on this thread as I proceed.
* [rant]I have to rant here for a bit. The amazing thing about ST is the extensibility and integration opportunities, but ZigBee HA is totally unapproachable for the hobby/maker community. Sure, there is the ST Shield, but a) it seems to be constantly out of stock and b) is based on the Arduino Uno footprint (big). I would love to see ST provide a more maker friendly mechanism for LAN and Cloud connected devices so I don’t have to do all of this. In particular it would be nice to have ST support Server-Side Eventing (SSE) or HTTP Callbacks that aren’t UPNP. I need to be able to do them for LAN or Cloud devices. ZigBee and Z-Wave are great for consumer/store-bought devices, but even that space is seeing more and more LAN and Cloud based connectivity. Of course, if there was a reasonable way to connect XBee modules without having to hack our way into the ZigBee HA Profile, that would be nice too.[/rant]