Feature Request- Ability to "disable" a presence sensor

[tgauchat (ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)]

@JDRoberts

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.

That’s why I personally recommend and prefer “spoofing” the Attribute value of a Capability (based on a Preference setting), rather than adding more Attributes and/or Commands.

@JDRoberts

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.

Nobody said this was going to be “easy”. The processor on your mobile device is tens of thousands of times more powerful than the best PC of a decade ago. Processing ability of even 10 times as much code per Device Handler will not be the bottleneck.

Design error?: It seems that most Device Types so far have rather trivial complexity. Even so, adding a “commonly desirable feature” (such as Disable) will add a fractional amount of complexity. I’m not advocating that Device Types should have significant extraneous complexity, but a small amount that is justified with particular value, as well as constrained by guidelines and certification, is, to me, a reasonable price and risk.

Again: Geko brilliantly echo’s my sentiment with eloquence…

@geko

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)

[JDRoberts]

@geko

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)

But you have to set the attribute and process that setting. That won’t be trivial when it’s running locally.

Java was created in the first place to run small on a toaster or whatever. Java is not the issue.

@tgauchat the complexity comes from having a global mutable variable. You want to be able to virtually take a sensor offline, similar to disarming a remote, right? That will only have meaning if other apps and Hello Home Actions also think the sensor is offline. And that’s going to get complicated, just like modes are now.

You’re basically adding a “mode” for every sensor. But forcing its implementation into a layer that doesn’t currently use mode. So the code becomes more complicated, network balancing becomes more complicated–and human scheduling becomes more complicated.

[tgauchat (ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)]

@JDRoberts

You want to be able to virtually take a sensor offline, similar to disarming a remote, right?

My current proposal is a compromise that uses SmartDevice Type “preferences” to allow the user to temporarily, manually set a variable that is used in the code to “spoof” the Attribute value(s) returned from that particular Device Instance. Using this method there are absolutely NO further changes required in any SmartApp or Hello Home, etc…

There are limitations, however:

1. “Spoofing” has inherent risk that you are breaking the Contract with the user or applications using the Device. This is resolved by adding appropriate clauses to the “Contract” the document the possible special behavior.

2. By using the Preferences section instead of adding an additional Attribute and setter Command, this “disable by spoofing” behavior cannot be initiated by SmartApps or external applications. But that is a current limitation on the implementation of Preferences which could be fixed with an enhancement request (e.g., add “mutable preferences”)

[baldeagle072 (Eric R)]

I know a lot of this thread has turned into device type standards theory, but I thought of a workaround using a smart app today. You could use a virtual presence sensor as the device all your smart apps listen for. Then have a smart app that listens for your actual presence sensor to update the virtual presence sensor. In the app, you could select whether you want it to update or to stay at a specific state. I might write something up later if I have time. Or if someone wants to write it and they need help, I could guide you through my ideas.

[tgauchat (ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)]

@baldeagle072

You could use a virtual presence sensor as the device all your smart apps listen for.

This is not a bad idea; it is essentially creating a new near-global (or global, or location) Attribute that is similar to “location.mode”.

And, I actually believe that the use of Virtual Devices is a great way to implement near-global Attributes for sharing information among SmartApps. Folks are already doing this with various Virtual Switches. I would, however, like to see this “formalized” – or at least strong guidelines for naming, etc…

Still, the problem that comes along with your solution is that you are adding an entire extra layer of abstraction to the system, which brings with it a bunch of complexity to the user. When they install a SmartApp that uses a Sensor, they need to take care to select the Virtual Sensor instead of the, ummm, less-Virtual one(s).

Again: If SmartThings were truly OO, then SmartDevice Types (which are Implementations of Interfaces), could be built upon base Classes and extended with polymorphic classes, and we could decide which layer is exposed to the user and SmartApps.

[JDRoberts]

@baldeagle072

I know a lot of this thread has turned into device type standards theory, but I thought of a workaround using a smart app today. You could use a virtual presence sensor as the device all your smart apps listen for. Then have a smart app that listens for your actual presence sensor to update the virtual presence sensor. In the app, you could select whether you want it to update or to stay at a specific state. I might write something up later if I have time. Or if someone wants to write it and they need help, I could guide you through my ideas.

This is an interesting approach. This could also give you the option to make any smart switch inside your home a presence indicator. So guests or the Dogwalker could flip the switch when they arrive, flip it back when they left.

Obviously there’s room for human error, but it would give presence sensor capability to anyone whether they had a smartphone or not.

Obviously it wouldn’t work to give barrier clearance for security features, because you’d want the switch inside the barrier, but it would let you do all the other stuff. So if you lose your phone, for example, you could use your regular garage door opener to get in, flip the presence indicator switch, and trigger “somebody’s home.”

Just opens up a lot of interesting possibilities.

[ctindel]

Hmmm I think you’re right. I was just going off the reply to my earlier message about wanting to define a “Person” better.

SmartThings Hub Version 2.0

@Ben Does this mean a local API for the hub?

Thanks for pointing that out! I assumed presence was set automatically by all devices I was logged into. Having to create a presence sensor for each device makes more sense.

[brianlees (Brian Smith)]

I fear I have been hijacked… I mean, ask simple question and all hell breaks loose here!

[JDRoberts]

@tgauchat

However, I just tested iPad:

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.

Or his iPad is a different model or configuration than yours. I believe based on what others have said that a newer ipad with 3G service and location services turned on May work, while an older iPad or one not on 3G or one without location services turned on would not.

[tgauchat (ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)]

@JDRoberts

Or his iPad is a different model or configuration than yours. I believe based on what others have said that a newer ipad with 3G service and location services turned on May work, while an older iPad or one not on 3G or one without location services turned on would not.

I totally agree.

My wording, however, was based on the literal quoted error message which reads (emphasis mine):

“This mobile device can’t be used as a mobile presence, only iPhones can be used at this time.”