The system is very reliable, working almost always as designed. It’s the “almost always” that is the subject of this question.
When the system does not work, the symptom is that the [Virtual Switch] is out of synch with the known state of the contact. Debugging the chain of connections shown above, I have a situation in which I see this:
Contact Sensor: Closed
Arduino : Sends message that contact is closed
ST Device Handler Events Log: Shows the contact closed
SmartApp: Did it run? Did it send a message?
Virtual Switch Events Log: Never got a message to change state.
Of course, I’ve put debug code into the SmartApp to drop a reference into the Debug.log, but it happens so infrequently, that I can never catch it live.
I can post a ton of code, but I’m not asking for code debug help (well, OK, I’ll take the help, but that’s not what I’m expecting!) What I am wondering is whether there have been reports of:
SmartApps not running when triggered by events to which they’re subscribed?
SmartApps not sending events through the platform?
The platform just losing state?
I’ve been tempted to just build a SmartApp to do a routine state-of-things clean-up, perhaps every 15 minutes or something, but this seems sloppy.
I have seen issues on occasion if the open and close (or on/off) events occur within a second or two of each other. It seems that the cloud can receive/process events out of order, resulting in one seen as no change in state.
RBoy
(www.rboyapps.com - Making SmartThings Easy!)
3
It could be an issue with the ST caching layer which keeps things synchronized. Or you try to modify your DTH to send isStateChanged to true with each event but will trigger an event for every event.
I am starting to wonder whether sending two events in a row is part of a kind of timing hazard.
RBoy
(www.rboyapps.com - Making SmartThings Easy!)
5
It should not be set every time as it triggers an event each time. Ideally the platform will determine if the value has changed and then trigger the app subscription correspondingly. However in specific cases it needs to be done, for example if you’re expecting the same event to come through multiple times and it needs to be triggered in each case (e.g. buttons).
I’ve come across a situation where when two identical events come in within 1ms of each other caused an issue with the caching layer processing it twice. ST engineers looked into and put a patch in place to handle it but that only happens if two events are coming very very quickly and I haven’t seen it happen for a long time now. It could be because you’re sending 2 events and if your app is subscribed to both events but that should trigger it twice. It’s hard to know without seeing all the code on all ends. I usually prefer to keep it simple, one event that follows the ST standard unless you need to customize it.
If the IDE is showing the correct state but no the Classic app it’s not related to the platform but likely with how the DTH for the Classic app device is written and how the app interprets it. It could be as simple a mobile server issue also where opening / closing the page updates the display in the app. So it comes down to which one of these is causing your issue.
Thanks. I looked back at my code, trying to figure out why I might have intentionally triggered two events. No clue. Maybe I was having an out of body experience. I’ve knocked one of them out and I’ll monitor for consistent behavior. It would be cool to be something simple. Appreciate the time.