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

Hi,

For virtual things driver it could be useful to allow users to decide weather their virtual switch should be seen in STHM.

The current implementation creates a virtual switch with switch and contactSensor capabilities. This allows to use it as trigger in Alexa routine. The device config hides the contact sensor, so it is not shown in detailed view. It looks like a normal switch, except it triggers STHM events.

I wonder how it is possible to allow the user to exclude the device from STHM from device detailed view.
I tried to use visibleCondition to hide contactSensor, but STHM still sees it as a contact sensor.
I could create a special profile without contact sensors. However, I already have 13 profiles only for virtual switch, each one has different icon. To keep the same functionality for switch without contact sensor it would require adding another 13 profiles. It doesn’t seem justified.

So, my question is, how it is possible from the driver’s code to tell STHM to ignore the device?
Thanks

I can’t answer the question on the driver but you have the ability to individually select which sensors are used in STHM instead of using all sensors. Hope this helps.

To do this… disable use all sensors then click on that field to individually select the sensors you want STHM to use.

@jkp ,
Thank you for your replay.
You are right, this is possible, but complicated. Consider a user with 20 or 30 sensors and no virtual switch at all.
Adding a single virtual switch would require to manually add all already working sensors to STHM.

What we really need is an ‘alexaTrigger’ capability and a more intelligent integration with Alexa that maps it across as a contactSensor and a switch.

1 Like

@orangebucket
Well, I think it would be best if Alexa could just take any ST device as a trigger, if it can be a trigger in ST.

1 Like

Amazon is not planning to do that at at present because in order for a switch to be used as a trigger in an Alexa routine it has to report its state when manually changed at the wall and a large number, probably in the hundreds, of inexpensive Wi-Fi switches which are sold by Amazon do not do that. According to discussions in the Alexa developer forums, Amazon just doesn’t want to get into the customer support issue of having to explain to a customer why one switch sold by Amazon works in a routine and another doesn’t. So far they prefer to just not include that device class.

There has been some speculation that this might change with matter so that matter compliant switches could be used as triggers in Alexa routines, making the customer support explanations much simpler. No matter logo, then it doesn’t work as a trigger in a routine. But we aren’t there yet.

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