[ST Edge] Is it possible to hide a contact sensor from STHM from edge driver code?

BTW, it doesn’t have to be a sensor. An Alexa routine can also be triggered from a virtual lock, if that’s of any help. So if you really think it would be too much effort to use the built-in STHM feature of selecting specific sensors, you could make your virtual device have the capability lock instead of sensor. That way it wouldn’t trigger STHM if someone is using the “all sensors“ set up. :thinking:

@jkp

2 Likes

@JDRoberts
Thank you, it is an interesting idea!
I tried to put a lock capability in addition to sensor.
Unfortunately, once Alexa detects a lock it ignores switch capability.
So, virtual switch is shown as a lock in Alexa. And since Alexa does not allow unlocking locks, there is no way to toggle the switch.
Any idea how to workaround this?
Thanks again

It used to be that a virtual device with multiple capabilities would show up as multiple devices in Alexa, one as a switch, one as a sensor or whatever. But I don’t know if that’s still true.

If it isn’t, the workaround would be to create a separate virtual device which is just a switch and then have a SmartThings routine (not an Alexa routine) so that turning that off locks the virtual lock which triggers the Alexa routine. It’s pretty clunky, but it should work.

1 Like

Have you looked at the bypassable capability? Not sure it hides it from STHM, but it probably should. If it doesn’t we should ask for a feature change in STHM since that is the point of the capability.

2 Likes

@blueyetisoftware This is a great idea, thank you!

@nayelyz Could you please comment regarding bypassable capability?
Either I’m not using it properly or it is not working.
Thanks

That is one of the capabilities we discussed before (here), they don’t have a presentation, therefore, they are not rendered properly in the app.
I’ll remind the team that we still have no feedback about this. I’ll let you know if I get more info.

2 Likes

Hi @nayelyz

Thank you for a quick response.

Could you please elaborate on this? Isn’t STHM a cloud engine? If it is, why it needs a presentation? I would assume all the STHM logic runs in the cloud, so it should be sufficient to only check a capability’s state. Presentation could be useful to change the settings, I guess, but
I can also easily change a capability state from preferences without any presentation.
Thanks

Ah, sorry, so you’re using it already but the STHM doesn’t show the device in that tool?
Generally, when the capability doesn’t have a presentation created, it means it’s a work in progress but I’m not sure about that one, I’ll ask the team for its purpose.

The idea in this case is that STHM should ignore any sensors that have been bypassed or are not ready (bypassStatus ~= ready) if they define the bypassable capability. Maybe they could include notReady and treat it like a warning that you get for an open sensor.

Possible Values:

  • ready - The device is ready for arming
  • notReady - The device is not ready for arming
  • bypassed - The device has been bypassed and won’t trigger an alarm

Not looking for any UI, just for STHM to ignore the devices.

1 Like

Hi @nayelyz

I’m already using it, but STHM always shows the device, regardless of bypassable’s state

If the device won’t trigger an alarm, why would STHM need to ignore it?

To put it another way, if a contact sensor reports contact events then it isn’t bypassed.

If STHM respects bypassable at all, shouldn’t it flag the device as being bypassed or not ready in a broadly similar way to how it behaves with offline devices?

@orangebucket

I think the idea here is to exclude the device from STHM. Contact sensor on frigider door for example should probably be excluded from home monitoring system.

STHM allows either to include all sensors or selected ones. It does not allow to exclude sensors (i.e. include all, unless selected).
So if you have 30 sensors and you want to include all, but 1, you need to include 29

I understand the issue. STHM offers a choice between monitoring all sensors of a particular capability or selecting them individually. The latter is, in my opinion, a poor design choice in STHM. They should actually be deselected individually. When you add a new device it should be monitored by STHM by default.

The point I was making was about the potential use of the bypassable capability on contact sensors and the suggestion that STHM was somehow at fault for apparently not respecting it. The idea of bypassable is that a device is flagging whether it is: ready for use; not ready for use; or that it has been deliberately disabled (bypassed). If a contact sensor has been bypassed then it shouldn’t be generating a contact event so it wouldn’t matter if STHM is monitoring it or not. If STHM receives a trigger from a supposedly bypassed device I would always expect it to respect the trigger, not the clearly inaccurate status.

@orangebucket

Oh, I think I’ve got your point. You are saying that this is the capability of the physical device, a kind of state and not a logical configuration of its controlling object in the app.
That’s fair, even though I’m not sure how useful it might be.
Anyway, I think STHM should allow individually deselect sensors, either in addition to the ability to select them individually or instead of it.
And if exclusions can be done from the driver’s code it would be a bonus

I was considering STHM the alarm. If I have a bypassable contact sensor, I would expect the alarm system to ignore that sensor.

Is it your understanding that it should mean the contact sensor would no longer report anything? Open/close isn’t an alarm. It’s just an event. STHM is determining that it is an “alarm” worthy event.

That is how I see it, but there are other interpretations.

Does a device/zone place itself into bypass, or does it get bypassed? What if a device is used by more than one security app?

What is the meaning of ‘The device has been bypassed and won’t trigger an alarm’? Does it mean the device won’t do anything that could trigger an alarm (my interpretation)? Or does it mean that anything the device does shouldn’t result in an alarm if everything is behaving properly?

I think it largely boils down to STHM needing to implicitly select sensors and explicitly deselect them. It is the other way around at the moment. As well as being unnecessarily tedious when you have lots of devices, it is just wrong. A select/deselect all option would also help.

1 Like

Yes, fair enough. The problem I have there is that if the device sets the bypassStatus to bypassed and STHM, or any other app, doesn’t ignore it when arming then it isn’t actually bypassed.

Yes, because it is the only way the bypassStatus makes sense to me.

It could also be argued that the bypassStatus is only bypassed once STHM (or another app) has armed and ignored it. This actually better fits in with the idea of the device being ‘bypassable’. In which how would that be communicated to the app without a command?

I suspect the reality is that bypassable doesn’t really make much sense if you try to apply it outside the context of an integrated security system.

1 Like

I have to respectfully disagree on this one. It’s not wrong. It’s just one of two possible options.

In our house, for example, at least 3/4 of the sensors are used for light control. NOT security alert. That goes for both contact and motion sensors. So if every sensor is automatically added to STHM by default, then the majority of sensors have to have that undone. Annoying for us, but useful for someone else who uses the majority of their sensors for security.

Moreover I don’t know about in the UK, but in many places in the US there is a significant financial penalty for a false alarm on a security system, as much as $500. That’s a hefty price to pay for installing a new closet door sensor and forgetting to remove it from STHM. Or just having the sirens go off and wake the baby the first night after you installed it.

So either default option will be good for some households and annoying for others. Personally, I prefer the one they chose, but that’s just me.

1 Like

There is another possibility, and I mention it because it is one that is offered on many Samsung smart appliances, and that’s that bypassable is another way of implementing “Sabbath mode.”

This is a question that has come up in the forum in the past, so if you’re unfamiliar with the option, here’s an old thread that goes into details:

And Samsung appliances features:

The other common example is of letting the dog out at night and wanting to temporarily turn off an individual sensor, usually with a button nearby. This is a common feature request. :dog: But of course that one is part of a security system. Sabbath mode applies to the lighting control sensors as well.

1 Like

What I really don’t like is that STHM takes both options. If you install STHM with the default settings then all your locks and sensors will automatically be used. However if you switch from using all sensors to using selected sensors then sensors aren’t selected by default.