I found the sendLocationEvent to be pretty well documented. I don’t regard this as a non-documented API call. I agree with the point that no app should indirectly gain access to devices it was not authorized to use, though we are talking about the target app as the middle man, so access to the underlying device is somewhat limited. Also, a user has control over which apps he installs, though for most that doesn’t mean it prevents any undesired access. I will look into a way to limit access on the receiving side of the sendLocationEvent by means of having an allowed app list. But again, sendLocationEvent was intended for such usage, this is not a hack.
1 Like
@tgauchat I am at a cross-roads between working on making required modifications to CoRE (split into parent-child is the sole request so far) and working on webCoRE, a much lighter code base version of CoRE that offloads the whole UI to html5+bootstrap+angularJS. While I am more excited about webCoRE (mostly because I can break all the boundaries that the ST app artificially imposes), I am ready to get to work on CoRE to get it published. I am, like I said, at a crossroads and am not sure which road I should follow first.
The webCoRE UI is much much faster to work with (no web requests during building the piston!) and also allows export/import, backup/restore, and most importantly… SHARE. Imagine this: all device handlers are removed, all phone numbers removed, all contacts removed, just the structure saved online and easily imported as a template by anyone using a six-character code… (myjson.com).
There is no need for integration with CoRE per se. CoRE exposes the list of pistons via an event any app can subscribe to. CoRE listens for events that any app can send. The only integration per se is if the foreign app needs CoRE to send custom events to it (CoRE executing code in the foreign app).
I am open and very optimistic, still. I found many of the ST employees to offer great unconditional support. I am hopeful CoRE (or webCoRE) will eventually be published. For now, the cat is in my yard.
2 Likes
You should work on the version / architecture that is most likely to be approved for publication. That should be your #1 priority for the maximum benefit to all SmartThings Customers.
1 Like
I will ask around, but it’s most likely that ST needs to see such an app before they can express their opinion. We’re talking about an app that has no configuration UI inside of ST. Is that allowed? Nobody knows because no other app does that. Yet. The closest is probably SmartTiles, but ST does not follow logic created in the ST UI.
There certainly is precedent… @obycode’s SmartRules and the (approved) ActionTiles.
But you observe correctly that SmartThings does not “pre-approve” apps in concept. Only fully coded completed SmartApps. So you risk rejection only after doing all the effort.
1 Like
Yes… SmartTiles (and ActionTiles) are approved and “published”.
1 Like