I’ve been using the awesome MQTT bridge for ST to send/receive event data over a standard message bus for integration with other automation tools in my house. The challenge with that approach is that events need to make a round trip to the cloud which obviously has issues when my internet connection is offline for whatever reason.
Is there any accessible API by which I can extract events (best case) or device state (OK depending on how fast I can poll) without the request requiring an internet connection?
I’m open to oddball options. For example, I’ve made use of tools like the HA bridge or iobroker to create “fake” devices discoverable on the local network which can receive commands and then translate them to other systems. However, it appears that the list of local devices is limited to Z-Wave and some Zigbee options only, and I know of no reasonable approach to emulating such a device at the moment.
You can take a MacGyver approach. Have smartthings turn on an inexpensive lightbulb which is operating locally and capture that event with a lux sensor positioned beneath the bulb. ( this will work even better if the light that comes on is in a closet or cupboard so you can be certain of the Delta.)
Or if there something else you could have come on and you can capture the vibration event with a sensor.
This can work great, back in my professional career we used to do this kind of thing to tie together two disparate systems. (I know I’ve told the story about the fan being turned on by one system and a motion detector joined to the other system then being triggered.)
If you think about it, this is how the Leeo acoustic sensor works with nonnetworked smoke detectors. The siren goes off, the Leeo hears it, and then the Leeo reports the event. Same principle. The light is the physical event, and then you need some kind of sensor to pick it up.
But there is a cost for the physical devices, as well as some inconvenience. So depends on how often you’re going to need the information, and how many different events you’re trying to capture.
I now return you to your regularly scheduled programming. LOL!
My trouble with that approach is that it doesn’t scale well. The lowest-cost option there winds up being something like $30+ per “bit” of data, which is a pretty hefty price for an API. Further, it still only works with supported local devices - meaning I don’t see a way to use this approach to grab state information from a device without a trip to the cloud that isn’t already handled by a local device handler.
Currently I’m experimenting with iobroker and a Z-Stick added as a secondary controller to my ST Z-Wave mesh to grab Z-Wave events and push them into MQTT. This kinda works, but it’s not a great solution as the secondary controller doesn’t always “see” all the Z-Wave events on the mesh.
A dimmable bulb gives you multiple potential notifications from one device, depending on how sensitive the lux sensor is. But you ought to be able to get at least three states: off, dim, and bright. And maybe more.
The problem with SmartThings is the only local events you can generate are the ones through a smart lighting automation and a little bit of smart home monitor. So it’s really the “if” more than the “that” which is so limiting.
While I smell what you’re cooking here and I appreciate it in a Rube Goldberg sense, the cheapest supported light switch + lux sensor puts this into the $50 range per bit of data (maybe two-three bits if you want to monkey with dimmer levels). While technically do-able, it probably wouldn’t be very fast as lux sensors don’t tend to trigger immediately and I’d doubt it’d be anything approaching reliable.
Is there any way to get events from the hub before they are handled by the cloud? Any way to see the raw Z-Wave or ZigBee data when ST is not online? Maybe something external, like a secondary controller to either the ZWave or ZigBee meshes to capture events on a separate system? Last I knew ST really didn’t handle being a secondary ZWave controller well at all, so I think that approach is out. Alternately, is there any API that the hub allows to query events or state information that doesn’t need a cloud trip?
In all seriousness, I like where you’re head is at. I think the answer to my original question utilizing officially-published interfaces is probably “no”, so some MacGyverin’ might be in order
If ST ever offers support for local LAN devices without the cloud trip it’d be a game changer. If I had a wish list for any one feature to be added to ST it’d be for native, local MQTT support That one simple thing would bring so much power to the platform and would completely alleviate concerns about cloud stability (for a certain class of user).
