I have this little app running, which basically sends a push notification when the mode changes. This way I can track when the mode changes even if I’m not around.
This works really well, but something really weird happened yesterday while I was playing with the WaterFurnace SmartDevice that I’m working on.
I have a field coming from the WaterFurnace named mode, which is the mode for the furnace. The SmartApp that powers it sets a value on the device and it then uses sendEvent to setup the tiles. Pretty simple really.
What I think is happening is the “mode” event is actually going to send an event named “mode”. The app is picking that up because the mode tag is so pervasive throughout the ecosystem you are actually sending a command to change the location mode to “off” or “auto”. The cloud is smart enough to know that there isn’t a mode with these names so it doesn’t do anything, but once it is written to the event log the smart app picks it up.
Would I call this a “bug”… probably not. I would change the event name to something like “furnaceMode”. That should eliminate any “cross contamination” so to speak.
I did change it to something else. Just struck me as odd that a generic device can send that magic event name & potentially screw things up or confuse things.
I think this is where making sure you have proper “intelligence” in your smart app comes into play. Obviously your notifier app does not need it because it is just a notifier. But something like my “Vacation Lighting Director” app that changes states of switches based on modes, needs to be protected from other events. I.E. After the app is triggered by a mode change, i run it through some logic to make sure it is truly in the correct mode.
I agree, but it still seems odd to me that my SmartDevice can have a Tile that’s named mode and itself is calling:
createEvent(name: "mode", value: value);
And it’s then broadcasting that event up to the location level. It smells of a Magic Event that needs to either be clarified or documented so that things like that don’t happen.
tgauchat
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
6
I love this Topic… Thanks for sharing your experience.
I’d like to look at this more closely and see if there’s a more deterministic and logical explanation.
In short, I suspect that SmartThings has, or should have, more specific “qualifiers” on all Object Properties (Attributes, Commands, … Events?).
Your Device Instance and Location are definitely two distinct Objects (of completely different Classes, actually), so a fully qualified reference to mode should be unambiguous. However, they are both using a shared Event Queue for communication. This either strips the qualification or makes it necessary to get the qualified name some other way.
This could also be a plain old namespace and scope issue, right? Device Instances are nested within the scope of Location, so, well, perhaps mode is effectively a global variable?
That’s what I was thinking, I don’t recall now, but I think it did fire the event and updated my local Tile with the event payload. But then it confused the hell out of me when the push notifications came across.
