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.
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.
@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.
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.
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.
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.
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?
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.
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
