But....if you can get a good sensor placed well and have a bit of luck, that rule should work decently, but my bet will be integrating Ring Doorbell motion I think moving forward.
1 Like
Xiaomi/Aqara has a vibration sensor with a community device driver from @veeceeoh (all the standard Xiaomi caveats apply). He has a sensitivity adjustment in the driver, but I'm not sure it has been verified to work.
Finding a similar need for setting a vibration threshold in HSM Custom where I am using a ST Multipurpose sensor on a locked barn door that has a difficult configuration for using the contact magnet.
As a "jostle sensor" the vibration option worked great until the winds came. Based on my testing there is a pretty specific signature to how this door would be "tried" by a would be intruder.
The sensor is too darn sensitive for a "trigger on any vibration". It would be nice to have a threshold or sensitivity setting say "trigger at a level of 5" on a 1-10 scale.
I presume to achieve this I'm going to have to do it outside of HSM and with some factor of the 3-Axis acceleration data.
Somebody steer me otherwise but it just seems like everything one might need to access/do with this kind of vibration/shock/acceleration sensor for security purposes ought be available & coordinated under HSM App. I just don't see it....but I'd bet I'm not the only one that would appreciate having it there.
Thanks
You're looking for an adjustment that doesn't exist. Hubitat cannot impose it's will over the device. If the device doesn't have an adjustment, it doesn't have an adjustment and there is nothing Hubitat can do about it.
Totally missed the whole part of the discussion that mentioned the 3-Axis acceleration data?
The capability DOES exist. It's just a function of what input you use to sense "vibration" (acceleration).
I'm use to reading "out of the box" creative thinking in this forum. Thus the post to trigger it.
You can adjust the sensitivity on the SmartThings multi-purpose sensor? How exactly have you achieved this?
The capability to SOLVE the problem presented exists w/ the available acceleration sensor data and some math.
No need to adjust the sensor. The need is for post processing on "the data" in a manner that it would appear to the user that they are "adjusting the sensitivity of the sensor".
You see, that's where you're wrong. The device doesn't report anything about it's acceleration. It's report a binary state of tripped or not. Period. All of that logic is built into the sensor and is not sent to Hubitat.
1 Like
I'm just going to leave this alone and let others comment on the relevant on board capabilities of the SmartThings Multi-purpose sensor that may or may not be fully exploited by Hubitat to archive the objectives discussed in this thread and others similar.
It has nothing to do with Hubitat. The device simply doesn't do what you are saying it does. All of the processing of the acceleration happens inside the device. It simply broadcasts a message when that has been tripped. That's all. Where do you see reports of the acceleration values anywhere? They aren't in ST either. I don't understand your resitstance to being corrected. You made an assumption based on supposition. It is incorrect. If you have evidence that the values you mention are sent to Hubitat or to ST, then show that to me.
Because you are wrong.
For reference to expand the discussion contributions-
EXACTLY.
Also, that 3-axis data is only send AFTER a trigger event from the device. Not whenever it changes. So, it only helps you if you are able to adjust the triggering value. Otherwise, you will never get the number so there is nothing you can do with it.
So, again, a firmware change to the device would be necessary.
Hummmmmm, so we have a device that kicks off data upon an acceleration event.
Hummmmmm, and the data sent might actually help determine the magnitude and/or vector of that event.
Hummmmmm, and Hubitat has rules & logic tools wherein one may be able to set some criteria , constraints, and decide what to do/report after an analyzing said data.
Hummmm, and what was the original "use case" again?
OK,
I'll check back in if some creative coding solutions arise.
NO!!!!! That is incorrect.
Only when an acceleration event occurs does it also send the data. So, you cannot make the sensor more sensitive. The data is only sent after the firmware determines that an alert occurs.
Do you not believe me or are you just not understanding how the sensor works?
1 Like
Oh I believe you. And I understand.
I'm just suggesting that how the ALERT is handled could be dependant upon the axis data feed that comes with it. With the right software one could see the alert as a trigger to evaluate the axis data and ACT DEPENDANT ON THAT.
So once again, the objective is to see a "certian level of vibration" as actionable. Not the fact that the sensor was triggered. Kinda like that whole Smartthings thread linked above is tossing around.
This still would not work. You only get the data when the device decides there is an alert. That is one time. Not constantly. You have no information to compare it to. You have nothing to do the math with!!! What values are you going to use to calculate the difference with? You don't have any. You get the values that were used to calculate when the alert happened when the device decided to send it but that's all. It doesn't tell you what the baseline value is.
IT IS NOT because you cannot determine this. If you want to make the sensor less sensitive, you will only get the values when the sensor triggers....never again. So you have no values to calculate anything with.
IT WILL NOT WORK until there is a firmware change on the device itself. PERIOD.
That's interesting, I wonder why so many systems offer baseline temperature offset fields and adjust the reported temp accordingly.
I didn't suggest there wouldn't be some "training" involved. With the current installed sensor orientation I have already seen the axis deltas created by 75% of the expected wind events. And I see a significantly different signature when trying to force open the large doors like someone might .
Challenge yourself to think out of the box, yes software on the Hubitat side might have to have some event handling options it doesn't currently have. But....there seems to be some possibility here.
Because the device is reporting the temp and the driver can do an offset. But the data of the temp is still coming from the sensor.
You are not listening to me.
When the sensor detects an alert, it send that alert to the hub along with the three values that triggered it. That is all. Then when the alert is over, it send that to the hub, along with the one value. That is all.
That is all the data that the sensor sends to the hub.
How would you ever be able to use those values to change the level at which the sensor sends the data!!!! You can do all the math you want, you will not be able to change the level. You just won't listen. And clearly you do not understand how the sensor work. I am muting this thread now since you refuse to listen but insist that the problem is mine. Goodbye.
Dusting this topic off
I've got a SmartThings Mult-Sensor V5 that would serve the use case really well if there was a way to ignore the spurious noise of a minor jostling by wind or otherwise. (Use Case: Alerting when a piece of equipment is being messed with, by way of the seat being jostled/re-positioned/sat in.)
@mike.maxwell , unless I am misinterpreting the scope of actionable manipulation for this particular type of device - I am encouraged by the driver magic you have worked in seemingly similar respects for other devices where "what the devices reports" is "conditioned, converted, moderated, or throttled" in some manner.
What seems useful would be some way of setting a threshold of what x, y, z offset one needs to declare a "meaningful jostling" of the device. For example, an X % change in two or more axis would do it.
I don't know how all the different x,y,z offset devices report (consider actual) movement but it would seem this would be a commonly useful thing, to not have motion interpreted as a "triggering" unless some threshold was met. This is almost like adjusting the squelch on an old radio 
Maybe the way these devices report it is the case that you wouldn't have a recent "initial reference value", maybe this could only be established after two consecutive reports. For example, somebody grabs the seat to get on (first reporting) then person sits in seat - (second reporting) and offset computation possible for delta/threshold comparison. As sensitive as these things are that would be OK assuming there aren't built in time lapses between reportings.
Maybe another way to handle this is some "threshold of disturbances", e.g. don't call it triggered unless it's been three in a row within 3 seconds no matter what the x,y,z offset were. I donno...
This feature could probably be handled in an App, but I am wondering if this is not such a low level functional approach to "handling/interpreting the motion reporting" of these devices that it deserves to be treated at the driver level if it can be.
Heck there might even be devices out there that folks have put on the shelf either right out of the box, or over time, because they were/became too sensitive or downright flaky seeing motion where there was little of significance. This might be a way to reduce the actionable sensitivity (in a manner of speaking) and make those devices useful to folk.
Educate me. Thanks in advance.
SmartThings Multi-Sensor V5
- endpointId: 01
- model: multi
- application: 11
- firmwareMT: 1241-0020-00000011
- softwareBuild: 00000011
- manufacturer: Samjin
+1
