Vibration sensor not supported by new SmartThings app

My vibration sensors were supported by the Classic app via a custom device handler. Samsung support has informed me that these sensor are not supported by the new SmartThings app. I have a hard time believing that as they are displayed on the app home screen and are identified as “vibration sensors”. What I think has happened is that although they are recognized the handler code is no longer valid and as a result the sensors are always shown as “offline”. Is there a way to port/update the handler code so that it is compatible with the new SmartThings app? Is there a guide/HOWTO that I can RTFM to figure out how to do this? I don’t even remember what it took to get the handler working for the Classic app.

In case anyone is interested the vibration sensors are:
Monoprice Z-Wave Plus Shock Sensor, PID 15269, FCC ID KFR-ZS5101US-5.

Here’s info from the spec sheet:

Start with this thread and see if it helps. It shows how you can edit custom code to get it to work in the new app.

Tagging @Automated_House to see if he has any ideas

My addled brain just remembered how to get the code for the Classic handler (it’s on the “graph” web site). The working Classic handler is:

Vision Shock Sensor v1.2.1
** * (ZS 5101)**

** * Author: **
** * Kevin LaFramboise (krlaframboise)**

Unfortunately the thread you referenced is gobbledigook to me.
“It shows how you can edit custom code to get it to work in the new app.”
Where? Can I figure this out in less than 2 months without parsing this entire thread?
A sample HOWTO that walks someone through this would be a huge help.
Anyone know if Kevin LaFramboise has published versions of his handlers that are compatible with the new SmartThings?

Taggng @krlaframboise

The devices list on the “graph” website shows the execution location to be “Cloud” for these sensors. Is that the problem behind them being “offline”? IIRC the new SmartThings runs everything locally, or have I got that wrong? Does this mean that new/modified code needs to be pushed to the hub (which is v2 btw)?

no. your problem is the custom device handler most likely needs to be updated. You should see if the developer has updated the code to support the new app or if the code has been discontinued

currently, custom code does not run locally… only in the cloud

Thanks for clarifying. I’m guessing the “graph” page will continue to provide the same information?

The github listing for Vision Shock Sensor does not show an update beyond v1.2.1 so it looks like I’m out of luck. Maybe I could hack it if I could figure out what to do. I have no knowledge of the Classic and new APIs so I’d need a detailed HOWTO as a guide.

This is a relatively simple device so you’re probably better off using it with one of the generic built-in handlers, like the z-wave motion sensor.

The device supports the Health Check capability so the status in the IDE shouldn’t be offline, but the new mobile app might show it like that because it’s missing the vid attribute in the definition.

Add the following to the end of line 44 and the new mobile app should at least see it as either a motion or vibration sensor, but I’m not sure if that will fix the offline issue.


The new mobile app caches the definition section of the handler for up to 12 hours so if you make that change to the existing handler and your still having that problem, you won’t be able to determine if that change didn’t fix the problem or if that change hasn’t been applied yet because of the caching issue.

Because of that you should take a copy of the handler, change the name, make that change to line 44, install it as a new handler, open the device in the IDE, and change the device’s “Type” field to the new handler. After doing that you should see the UI change in the new mobile app almost instantly.

1 Like

Got the sensor issue resolved (almost):

  1. Your suggestion (thanks, greatly appreciated!).
  2. App device settings were wrong. For reasons unknown the secondary capability (tamper) was incorrect. Apparently both primary and secondary must match the handler definition (maybe this didn’t need to be true in Classic?). After selecting “default” the sensor stays “online”.

It seems any sort of edit on the graph pages involving the device kicks the device into “online”, but after some time it falls back to “offline”. So sadly not fixed.

There is one other device handler issue. The GoControl Multifunction Siren (using your handler) device always shows “Checking status…”. The siren tests ok so it’s recognized. Is this persistent “Checking status…” a problem that needs fixing?

UPDATE1: Kevin, I tried your suggestion of using the generic built-in z-wave handlers. That seems to have made everything happy as all the devices stay “online” and are all shown as “local”. It seems to have solved even the siren issue. I have yet to test the vibration sensors using the built-in handler, but will assume they’re ok for now. My biggest pressing issue is the lack of STHM without which my entire setup is useless.

UPDATE2: Nope, doesn’t work no matter what sensor type I specify (yours or the generic motion). It initially is shown “online”, but eventually becomes “offline”. They seem to go offline at the checkinterval.


When it shows offline and then you shake the device, does the acceleration value shown in the mobile app (or the IDE) change to active?

I had an unused vibration sensor so I decided to do some additional testing. I decided to add this sensor with the new ST app and used an app type “generic z-wave”. This worked! This sensor is recognized and it stays online. It is using your modified handler. I can see from the event log that there is regular communication between the hub and sensor. Also I see that the hub has lowered the checkinterval to 22 minutes from 8 hours. So the magic seems to be adding these sensors via the new ST app as this does something behind the scenes on the Samsung side which is different from the configuration under Classic. It looks like I’ll need to delete the existing vibration sensor devices and add them all back in with this technique for the new ST. That’s going to be a PITA, but as some of the batteries are running low it needed to be done anyway. Thanks for helping, it’s good to know your modifications are working.

The new mobile app doesn’t do anything different during inclusion that’s related to the wake up interval.

If my handler really is assigned to it then there’s a check interval setting that overrides the default 4 hours that SmartThings sets it to during inclusion.

You must have changed that setting to 10 minutes which would explain why it’s using 22 minutes for the check in, but that value should only be used for testing.

The device wakes up 6 times every day by default, but yours is currently waking up 144 times every day so I’ll be surprised if the battery lasts more than a month…

Quite right, I changed it back to 12 hours.

I did discover something that might help out others who are suffering from battery powered sensors going offline. It seems not all rechargeable CR123A batteries are of the same quality - even those of the same batch/order! Like many I ordered a CR123A recharging kit from Amazon. I’m embarrassed to say it was one of the cheap ones from rickshaw Incorporated which is no longer in business. About 4 of the 8 batteries in the set can’t hold a charge. Gee, I wonder why they went out of business. Bottom line - when sensors mysteriously go offline look to the batteries first. Forget what is reported by the software - physically check the batteries with a meter!

Some devices require close to 3V to function and even high end rechargeable batteries usually won’t hold a full charge for very long so there are some devices that aren’t worth the hassle of using rechargeable batteries with.