I would say that the OO (Object Oriented) paradigm gives us the answer in the form of inheritance, sorta.
It is perfectly fine for SmartDevice Type Classes to carry along with them various “near-global” attributes from a Base SmartDevice Class. Some of these attributes could be used directly (i.e, “protected” attributes) in the SmartDevice Type definition code for actions like freeze-current-status, and others could be visible handled in SmartApps (“public” attributes).
Yeah they really need to rethink the options for controlling states via presence. I also find it annoying that there’s no way to say “Don’t use my iPad as a presence sensor” because while I want it logged in to my account I don’t always take it with me. For sure if my iPad is gone it’s an indication I’m gone but I leave the house without my iPad all the time.
This is a really small enhancement to the code for any Presence sensor Device Type.
Do you have a link? When I asked about it via support they told me to just associate the ipad with an entirely separate email address, one that isn’t used for presence stuff. Which of course works but it just a hack around them setting presence stuff up the right way.
No link (what would I link to?); but a hunch and some curiosity.
Do you want to permanently disable the iPad as a Presence Sensor, or temporarily?
SmartThings already has capability.Sensor, which is a dummy capability with no commands or attribute defined. All you need is to add a boolean attribute armed and two commands - arm() and disarm(). This would allow any sensor device to implement this feature if they chose to. Semantically, a disarmed sensor is not disabled. It still operates as usual, it just does not send out events. But you can still query its state if you need to. That’s how it was implemented in Vera, I believe, and it worked remarkably well.
At the UI level, you’d just have an “Arm/Disarm” tile in the device details view to toggle its armed/disarmed state. Sounds pretty simple to me.
Emphasis mine.
I would prefer that any/every device that “is a Sensor” must include this Capability, and therefore, must implement the armed attribute and arm()/disarm() commands.
In general, mandatory code blocks for SmartDevice Types are something that I hope SmartThings is considering as part of the Submission & Approval process. Sure, it would be great if the platform did this behind the scenes (as in, true inheritance) or the IDE would at least “drop-in” the code blocks.
@April: Just calling-out you to remind me to put this on the next Dev Call agenda, or if you can suggest who would be a good ST engineer to chat with about this topic of some feature standards for all Device Types? Thanks!
Device type should reflect the physical device it models. No mandatory capabilities other than node ID and the ability to name the classes it supports.
If the physical device has a disarm capability, fine. But it should reflect the actual features of the actual device.
Terry, what you’re talking about is a scheduling feature. You’re not physically turning off the sensing capabilities of the device, you just want the hub to ignore it for awhile. Totally different issue. Because if you want to require it For physical devices that don’t actually have that feature, you have to do it at the hub.
Spoofing the Attribute values from a Device may be controversial, but it seems like a expedient way to solve a scheduling or enable/disable Thing in at a very granular level. Maybe not activated by Command, but rather via an Install preference.
imho, SmartThings shouldn’t hesitate to squeeze functionality into the existing architecture if they provide guidance and certification.
“Disarmed” may not be the best name for the function if the Device can’t actually disarm itself, but “Status Override” or “Hidden”, or whatever, is easy to implement, yet only “safe” if used consistently.
Well, I have an ipad mounted to the wall permanently that I use for controlling things, but as it never leaves the house it should never be used for presence purposes.
I guess our personal iPads should act the same way. I only want our phones to be used for presence purposes.
That’s true, but it does not negate usability of this feature. Let’s not forget that SmartThings is a hybrid system and smart devices are just abstractions of the actual physical devices. A physical device may or may not support arming/disarming, but it’s perfectly legal to implement a missing feature in the abstracted device handler. Just my opinion, of course.
On the Mobile App, go to Things view, Press the Gear icon on the Tile for the Thing that is the Mobile Presence Sensor for each iPad, select Preferences, click REMOVE (big red bar).
Doesn’t that work for permanent disabling?
BINGO!
(Yes – that’s just my +1 wording when someone says exactly what I’m thinking and words it perfectly). Thanks.
I would have to respectfully disagree. Whatever ST is, the undercore is Java processes controlling multiple mesh networks. Spoofing capabilities will come back and bite you, JAWS size, sooner or later. And kill any possible SmartApp marketplace, since the apps will trip over each other. It also kills plug and play integration with other systems, from Hue to Sonos. Where are you going to get the values for the capabilities since the physical device can’t supply them? Is a device going to be “on” to some apps and “off” to others running at the same time? What about web services with third parties like IFTTT?
I have no problem with creating a virtual device with any capabilities you want, even an officially released virtual device. Or more variations on Mode or other global variables.
I have a big problem with assuming the way to handle a global mutable variable is through spoofing capabilities in a physical device type.
One of ST’s biggest weaknesses is the UI for its scheduler. But we can’t forget the fact that the whole installation is a device controller for a set of physical devices.
Respectfully…
Well… That’s the beauty of abstraction. 
Instead of limiting your implementation to what the physical device can do, you extend it with something it cannot, but that can be implemented in software living outside of the physical device.
I give you one example. Look at capability.musicPlayer which defines playText(string) command for implementing Text-to-Speech feature. Naturally, not all music players have TTS implemented in the device proper. Sonos does not! The way this capability is implemented in Sonos device handler is purely via software function, i.e. by converting text to audio file and passing the later to Sonos for playback:
def sound = textToSpeech(text)
playTrackAndResume(sound.uri, (sound.duration as Integer) + 1, volume)
If SmartThings would restrict device capabilities to only what a “hardware” device can do, things wouldn’t be that much interesting, would they?
I definitely side with Geko on this one (but y’all already knew that).
What I personally stand firm on is: if a SmartDevice Type implements a Capability, then ALL the Attributes and Commands of that Capability must be implemented in a “meaningful way” (unless, SmartThings changes the definition of Capability such that certain Attributes and/or Commands can be explicitly declared “optional”.
That leaves us with the ambiguity of what is, exactly a “meaningful way”. Does this restrict us to physical hardware functionality only? I don’t think so.
Capabilities, as well as SmartDevice Types, can implement the Attributes and Commands in, ummm, “creative” ways, as long as these: (a) are documented for all users of the SmartDevice Type and Device Instances to see, (b) have an understandable presentation in the UI (i.e., the Sub-Tiles affected by Attributes and Commands) and (c) don’t mess up the expected behavior of SmartApps in an unsafe way.
Point (c) is the biggest risk, but is handled by human review during certification of the SmartDevice Type:
A SmartDevice type that obviously disables the attribute contact.contact by “always” setting it to “closed” when a User Preference disableDevice = true, is a valid and understandable use case. It is particularly safe, however, if that disableDevice preference is recommended by guidelines and/or various means of enforcement, as a common “Best Practice”.
A SmartDevice type that reverses the values of contact.contact by setting it to “open” when the physical device is reporting “closed” had better have a good reason for this, and that reason should be documented and/or obvious.
I don’t see a mobile presence tile. I thought it took my presence just based off the fact that the iPad is logged into my account and the iPad is at the address?
And how’s that working for you? 
Sure, you can address this with software, but where is that software going to live? Changing an output file for a single device like the Sonos file example, doesn’t trip up any other apps working with that device.
And don’t forget we’re going local now as much as possible. A mandatory capability increases the size of every device handler for that class. Slows down implementation of every action request for that class. Creates additional possibility for design error. And disabling a sensor will have very little usability unless you make that nonUS status available to other smartapps and web services. Which means more memory, more reduction in speed, and more possibilities for design error. One of the main reasons for end devices getting smarter is so the coordinators can focus on scheduling and traffic control, not feature management.
Go for it, if SmartThings will let you. But you’ll get killed by competitors who are trying to write smaller, tighter, faster code for home automation support. In my humble opinion…
I mostly use Android: You need to Add the Android as a Mobile Presence, and can therefore Remove it.
Here are Android Screens:
When I try to add iPad as a Presence Sensor I get warning:
“This mobile device can’t be used as a mobile presence, only iPhones can be used at this time.”
So…
According to that message, there is no way that your iPad could be reporting “presence” because that is not a supported function.
NB: I’m not saying you’re imaging things – it’s just that you are in undocumented territory; not a missing feature, just missing documentation and/or a bug.
Yes, there’re some trade-offs to be made, but honestly, I don’t think the impact would be huge. An extra boolean attribute would add one byte to each device instance or 230 bytes even if all your Z-Wave devices are sensors. This is not something I’d worry about. If code size and speed were an issue, SmartThings would not use Java/Goovy in the first place (just my 2c)
