This is Yongfeng from BloomSky (http://www.bloomsky.com). Our company sells an out-door device that measures the temperature, UV index, luminance, raining and pressure. It uploads the data along with a picture of the surroundings taken by a mounted camera to our server every 5 minutes, through Wi-Fi. Our users use our smartphone app, which uses a bunch of APIs to poll the server to get those data.
Our device doesn’t have any action or accept any commands, it just provides data. According to my understanding, I wonder whether it belongs to Cloud Devices or Web Service SmartApps? I don’t quite get the differences between them. If it should be Cloud Devices, I want to know where I should write my Service Manager and Device Handler in the developers console? Do they correspond to “My Devices” and “My Device Types”, respectively? Thanks a lot for your time.
I believe you’ll need both a Service Manager (which is a SmartApp) and a Device Type. In the developers console, you’ll build them under the “My Device Types” and “My SmartApps” tabs.
Thank you so much for your prompt reply. I really appreciate it.
So I’ll need to implement the two to provide a device type for our users, and our users need to write their own SmartApps to decide what they want to do with their device/data, right?
And I wonder what kind of grant type should be used for the OAuth2? Thanks a lot.
I’m not sure on the OAuth front. Not my area of expertise, but someone else may be able to help you out there.
If your device exposes existing capabilities, they’ll be able to take advantage of any existing smartapps that use that information. If you expose information that is unique to your service, either you or your users will need to build SmartApps that take advantage.
Thanks a lot. I have one last question regarding the whole process here.
For the Identifying Devices part, I do not quite understand what the purpose is and what kind of information needs to be returned. Also, I wonder whether it is all devices in our database or just the user-owned devices that need to be “discovered”.
Actually I don’t quite get the design schema here. On our side, each of our users have one or two (at most) devices that he or she registered on our database and use a token-based authentication to retrieve the device data. The user can only utilize the data from his/her own device. So I think the Device Handler and Service Manager I’m writing should be able to handle a specific device based on the user authentication passed by OAuth2.
I’m not entirely clear what you mean by identifying devices. Based on my extremely limited understanding of your service, here is what I would anticipate for your setup…
One service manager
This will handle the user authentication and all api calls for it’s associated devices. The first step will be connecting to your service via oauth. Once authentication is done, you can do whatever configuration is necessary on the SmartThings side. This could include selecting from devices available to the user (though if there are only 2, you may be safe in assuming all devices are desired). Your service manager will handle creating the devices after install/update.
One device type per different device
For each type of device you want to expose, you’ll need to create a device type handler. If a user can have multiple devices that are the same type, you don’t need multiple device type handlers. From your website, it looks like you would only need to create one for the outdoor station.
I think your device type handler will expose these capabilities:
capability “Sensor”
capability “Temperature Measurement”
capability “Illuminance Measurement”
capability “Relative Humidity Measurement”
capability “Image Capture”
You’ll also need to expose attributes for rain since we don’t have a capability for it. The ones below are used in our Netatmo integration
attribute “rain”, “number”
attribute “rainSumHour”, “number”
attribute “rainSumDay”, “number”
Here are links to the Netatmo Service Manager and Device Types. They may be a useful reference for you.
Not really. I was solving the OAuth2 issue, but then the management wanted me to develop a channel on IFTTT. So the development on SmartThings temporarily paused. I just finished IFTTT.
5 Likes
mdawson
(Different Computers. So happy with Indigo.)
10
Just got approved for my BloomSky, so I’m really looking forward to SmartThings integration.
Many, many SmartThings users are leery of IFTTT because it has proven to be unreliable, slow, and that their support is unresponsive. So while IFTTT is better than nothing because of its Smartthings integration, a real weather station app for ST would be truly awesome. There’s lots of enthusiasm for your product here!
@Yongfeng_Zhang[quote=“Yongfeng_Zhang, post:1, topic:26523, full:true”]
This is Yongfeng from BloomSky (http://www.bloomsky.com). Our company sells an out-door device that measures the temperature, UV index, luminance, raining and pressure.
[/quote]
Based on your post, you state that this device provides luminance information. However this is not mentioned as a sensor at the website, and I do not see the information on the Android app. Is illumination really provided?