From the Smartthings developer documentation and the available APIs, all available queries and commands are fetching information from the cloud. Is there any way to query directly from the hub within a SmartApp as a developer (e.g. query event history or event order )?
Also, related to that, the cloud issues requests to the hub (e.g. a SmartApp controls a Smart Lock). The hub is also involved, as it executes a ZWave/Zigbee command to control the device, thus changing the state of the device (e.g. Smartlock locks/unlocks). When does the hub respond or report the changed state to the cloud? Does the SmartApp in the cloud wait for this update before it finishes execution? If there is a client waiting for a response, does the SmartApp wait for the hub to make its update or does the SmartApp in the cloud return a response immediately and assumes the command propagates to the hub and to the smart device correctly?
In the architecture documentation does the “fire and forget” policy refer to the commands issued from the hub to smart devices over wireless? Does that refer to the fact that these commands are not ACK’ed?
tgauchat
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
2
No.
Since the vast majority of SmartApps do not execute in the Hub (only SHM and Smart Lighting, so far), the question is largely irrelevant. SmartThings is cloud-centric, not just cloud-dependent.
I’d personally think that any answers about the current handling of locally-executing SmartApps are highly “subject-to-change” as SmartThings comes up with architecture and engineering enhancements to allow more SmartApps to be local; i.e., the hurdles of local execution may have less than desirable side-effects regarding in asynchronicity and whatnot.
At the present time, all customer written code runs in the cloud. All of it, whether it is a smartapp or a device type handler.
The only stuff which is allowed to run locally is distributed in firmware to every SmartThings customer, and so is limited to the official smart lighting feature and a small bit of the official smart home monitor feature.
From a customer developer’s point of view, the hub is basically a box of antennas.
From time to time, SmartThings staff said that they would like to see this change so that there could be local custom libraries, but no timeline has been given and nothing in the development direction currently seems aimed towards that.
To keep things vague, we’re definitely working on some changes to improve the local execution story
The value of having local support for automations/devices (including community ones) is not lost on us. It’s good for users (offline support, reduced latency, increased reliability), it’s good for SmartThings (reduces server cost/load), it’s good.
I would love to go into more detail now, but I think I’ll leave things at the teaser. Making lofty promises about local execution and not delivering is something we would prefer to avoid this time around.
@posborne, could you comment on what “fire and forget” means in the architecture documentation? What does it mean for a SmartApp to e.g. turn a light on? Is there a transaction corresponding to this event that commits in the cloud but there is no guarantee about how this event propagates to the hub and the devices? E.g. if the device never receives this event over wireless or the smart bulb malfunctions, does that leave the cloud at the updated state and the light unmodified?
Thank you!
tgauchat
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
7
Most devices that accept Commands are also “Sensors” and will report their own change in State, regardless if the change was initiated manually or from a SmartThings Command.
Thus, the normal operating pattern is that SmartThings sends a Command “on()” and the device, shortly later, hopefully, responds with a message “State Change: Attribute Switch = on”.
In between the two States, SmartThings (and ActionTiles, etc.) might assume the state will change and update the Tile accordingly. That is usually OK. The proper way? Instead of changing the Tile from “off” to “on”, it should go “off”, “turning on…”, and stop. The device itself will complete the cycle.
But how long should SmartThings App wait to change the Tile back to “off”?
1 Like
tgauchat
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
8
In case it wasn’t obvious… The answer is that a properly written DTH will (should) not update the corresponding State Attribute when a Command is called.
In general, for most “typical” Devices, only the “parse()” method (ie, the method that receives messages from the Device.
Of course, many, many Devices are not “typical”, and that’s fine… .
Thank you for your response! It is really helpful to know that most devices report their State changes and that there are some devices that are not typical.
Could you by any chance name any of these devices off the top of your head?
tgauchat
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
10
I’m not sure these are great or even accurate examples…
Wall dimmer-switches that don’t license the “Lutron patent” are not permitted to instantly report when they are physically activated.
Hue Bulbs connected via Hue Bridge do not report State changes (though the DTH has been evolving), and I believe are checked by the LAN device handler from their log, rather than a callback from the Hue Bridge. I wonder why a callback doesn’t work … Amazon Echo gets a confirmation right away…
Garage Door DTHs should be coded to use a verification sensor (tilt or contact) before reporting State, but I’m sure some “lazy” relay implementations don’t do that.
.