I would like to create a virtual shock sensor (VSS) that is triggered by the accelerometer on a standard ST Multisensor (for use in HSM without using the custom rules option).
I've already created the basic VSS device based off the virtual omnisensor driver and can currently trigger the shock detection state via node red (not using RM because it means clogging up RM with a rule for each individual sensor).
So as a general question can a virtual device mirror/translate the states from a real device without external code? As I said I don't think this is possible but you never know......
I was going to suggest Mirror built in app but it looks like it won’t do what you want to accomplish. Other than that maybe try WebCORE (maybe someone will know another way, I’ve not been here long!) I̶ k̶n̶o̶w̶ W̶e̶b̶C̶O̶R̶E̶ i̶s̶ c̶l̶o̶u̶d̶ but won’t clog up RM if that’s what you’re trying to avoid.
Yeah, I slung mine a couple of months ago. Original plan was to let my parents have it, but I don't want the hassle of needing to deal with long distance tech support when things (regularly) stop working.
Webcore pistons themselves run local on hubitat. As I understand it, EDITING or CREATING pistons is cloud based. So pretty much once its set, you don't need Web access for pistons to function. Mine controls my central heating, and I can verify that's completely functional with an Internet outage.
However I was last night able to (barely) hack together a dirty revised driver for the sensor using the original smartthings device handler (smartsense sensor) , that translates acceleration states into shock states.
So now the sensor is detected as both contact and shock in HSM. It ain't pretty but seems to work.
I think it would be preferable to know where a potential breakin is occurring, but possibly not absolutely necessary.
I would prefer the vibration detection functionality to be integrated into the built in ST multisensor drivers (these devices are really quite sensitive) or HSM but it's given me the impetus to start learning groovy so I can clean up my dirty driver.
EDIT: Well, what the heck, why not just ask . @bravenel can I ask if shock capability be incorporated into the ST multisensor v5 driver? That way HSM can alert me if someone is trying to pry my window open or break the glass to rip my sensor off before opening the window.
Any idea what "shock capability" means in practical sense?
E.g. I created an RM that would alert me at night if it detected acceleration on these sensors on my windows, but some vibrations gave me false positives. Is "shock" a derivative of that with maybe a higher or prolonged threshold?
My understanding is that the sensor returns an on/off state and the capabilty is presumably designed for special glass break sensors which react to acoustic signature or the specific vibration frequency of glass breaking rather then being a simple accelerometer.
My windows close quite tightly against the frame so they don't rattle at all but I can see how using simple vibration alone can lead to false triggering.
However I question the true value of these kind of sensors for most people. In reality (unless you have a huge property or your neighbours are well out of earshot) my experience is that burglars tend to pry open doors or windows rather then put a brick through them. (plus of course these sensors are no use on normal doors)
I'm simply asking for a bit more flexibility in how we can use HSM. If you get false triggering obviously you should not be using vibration sensors.
Unless I'm misunderstanding something, you can do this pretty easily. The biggest issue might just be false alarms from any vibration. I tested this by banging on the chest freezer lid that has a ST v5 multisensor on it. Worked fine.
I use this simple bit of code all the time and just change the device capability for what I need. Switch changes, the device changes and vice versa.
I do have a similar virtual driver based on the recently released omni sensor code (just deleted all the bits I didn't need). And taken a bit of a different route by using node red to translate vibration on the 'real' sensor into shock on the virtual sensor instead of a rule (I am curious though which is likely to be the more efficient route - RM or node red)
Also TBH it did not occur to me to use one rule to do it all - having said that the rule doesn't handle simultaneous different window attempts although I doubt a potential burglar would have an accomplice have a go at a different window
I just thought it would be neat to have it all encapsulated in the one driver (which I also attempted to do) hence my feature request (recognising that false alarms can occur depending on the type of window it's being used on). My hacked multipurpose sensor driver does work but gaining more indepth knowledge of groovy/java to do it properly is looking like it will take quite a bit of time (many real life things to do taking precedence over a hobby) !
In the end there are more than a few ways to accomplish this so that's cool.
PS: I do very much appreciate the time and effort you took to put your post together!!!!
For the life of me, I cannot figure out how that would be important, other than to see later (which you will in the logs, but you could easily add logging to the rule). However, as long as HSM is armed, it will trigger any of them. Doesn't matter if one was triggered already.
. 
.
. I'm just being difficult 
Sorry!
