[Release] Monoprice Shock Detector (PID 15269)

There are a couple of ways to get this device running on Hubitat floating around. The ones I saw had other stuff built into them that this device doesn't support anymore so I made another (hopefully cleaner) version of a krlaframboise driver that had support for another device. This version only has functionality for the Monoprice Shock Detector.

The other device the old driver supported could attach an external sensor. The Monorprice Shock Detectors that are sold now definitely do not support external sensors. Not only do they just not have the header on the PCB anymore where the external sensor attaches but the functionality also appears to be taken out of the firmware. (The Monoprice window/door sensor still supports an external sensor though.)

My version of the driver can be found here. Let me know how it goes.

https://github.com/codahq/hubitat_codahq/blob/master/devicestypes/monoprice-shock-sensor.groovy

By the way... shame on the Monoprice people for teaming up with somebody who charges for device drivers. That really rubbed me the wrong way.

3 Likes

@codahq The driver appears to be working with the 15269. I do have to hit refresh to get it to change from active to inactive. Is there any updates to this driver? Thanks

You may have to open the shock sensor to adjust sensitivity with the pentiometer. My biggest complaint with mine is that it is not sensitive enough even at its most sensitive setting. At the least sensitive setting it will not even trigger.

You don't have to hit refresh for the state to change from inactive to active. The device will send a message but you have to ensure the sensitivity is high enough that the device is triggering. Any time the red light turns on you should see it go active in HE.

I have it on the side of the dryer and it does pick up vibration. I have adjusted the pot so that it goes active when the dryer goes on. The issue I am having is that it never goes back to inactive when the dryer stops unless I do a refresh.

I've never had that problem. I did have a problem using it for sensing the dryer though. Even at the most sensitive it never triggered.

At any rate, try bringing it closer to the hub temporarily and see if you still have the issue. If you don't it may be a signal issue. If you tap it while it is still attached to the dryer does it go inactive? Is the battery fresh? Do you see anything in the logs with all of the debugging turned?

Closer doesn't do anything different. Battery is new. It is located about 3 ft. from a z-wave device that repeats. I have done a z-wave repair also. Tapping on the side of the dryer shows it as active but still no inactive without the refresh.

Logs show the refresh then it goes inactive. Time frame from dryer shutting off to when the refresh was given is about 2 min. So that was more than long enough for the sensor to go inactive. But it didn't until I did the refresh as you can see.

dev:28032020-01-14 05:28:05.068 pm debugrefresh()

dev:28032020-01-14 05:26:22.059 pm traceNotificationReport3: NotificationReport(v1AlarmType:2, v1AlarmLevel:255, reserved:0, notificationStatus:255, notificationType:7, event:2, sequence:false, eventParametersLength:0, eventParameter:[])

dev:28032020-01-14 05:26:22.054 pm debugzwaveEvent(hubitat.zwave.commands.notificationv3.NotificationReport cmd)

dev:28032020-01-14 05:26:22.049 pm debugLast Activity: 01/14/2020 05:26:21 PM

dev:28032020-01-14 05:26:22.041 pm traceDescription: zw device: 96, command: 7105, payload: 02 FF 00 FF 07 02 00 , isMulticast: false

dev:28032020-01-14 05:26:22.038 pm debugparse(String description)

dev:28032020-01-14 05:26:21.971 pm infoAcceleration: active

A repair won't change the routes of this device unless it is awake. I think (I can't remember for sure and you may have to look this up) but you can wake it up by removing the cover and doing the repair while the cover is off.

Is it waking up at the correct interval? Are you getting those reports as expected?

I get reports in the logs as active then inactive. It almost appears as if it is sending an active followed almost immediately by an inactive, kind of like a square wave pulse. When the dryer is started the LED blinks. The device page shows active. But if you hit refresh it goes to inactive. If you tap on it a second time even if the dryer is running the LED will blink again.

So the driver, as it seems, is seeing a pulse which shows as active but how would the event know the dryer was finished if it never sends another inactive command when vibration stops?

It appears that the inactive command is sent at about 10 sec. after the device goes active. The dryer starts and the LED blinks. 10 sec. after the first blink there is another blink. I don't know what it is doing. These logs show it is sending the inactive based on the time I mentioned above.

dev:28032020-01-15 08:21:51.546 am infoAcceleration: inactive

dev:28032020-01-15 08:21:51.544 am traceBasicSet: BasicSet(value:0)

dev:28032020-01-15 08:21:51.542 am debugzwaveEvent(hubitat.zwave.commands.basicv1.BasicSet cmd)

dev:28032020-01-15 08:21:51.539 am debugLast Activity: 01/15/2020 08:21:41 AM

dev:28032020-01-15 08:21:51.532 am traceDescription: zw device: 96, command: 2001, payload: 00 , isMulticast: false

dev:28032020-01-15 08:21:51.530 am debugparse(String description)

dev:28032020-01-15 08:21:41.528 am debugrefresh()

dev:28032020-01-15 08:21:41.380 am traceNotificationReport3: NotificationReport(v1AlarmType:2, v1AlarmLevel:255, reserved:0, notificationStatus:255, notificationType:7, event:2, sequence:false, eventParametersLength:0, eventParameter:[])

dev:28032020-01-15 08:21:41.376 am debugzwaveEvent(hubitat.zwave.commands.notificationv3.NotificationReport cmd)

dev:28032020-01-15 08:21:41.363 am infoAcceleration: active

I just saw this error in the log.

dev:28032020-01-15 07:39:04.203 am errorgroovy.lang.MissingMethodException: No signature of method: user_driver_codahq_hubitat_Monoprice_Shock_Sensor_1310.logsOff() is applicable for argument types: () values: [] Possible solutions: notify() (logsOff)

Okay, fun times @razorwing. It appears that something happened to both of our sensors. I hadn't noticed it because mine isn't used heavily but when I started checking for what could be wrong I saw the same thing.

I decided to open a thread and check to see if it had to do with the command class changes on the hub recently and it turned out not to have anything to do with them. So, I decided to remove the sensor and re-add it and it seems to have fixed. Maybe there is a bug in the firmware that has to do with the rollover of 2020? Maybe it's just buggy? Or maybe some weird association got set on the driver by something else. It's hard to say.

Either way, my sensor is working again without any change to the driver after exclude/include.

However, I did make some improvements to the driver while I was in it.

  • Fixed battery level to be consistent with OOB drivers to have "%" unit
  • Added version report via configure (lid must be open to send and receive and LED will stay on)
  • Added manufacturer specific report via configure (list must be open to send and receive and LED will stay on)

@codahq It looks as if the problem still lies with the refresh. The unit will go active, as well as the tamper, but neither will return to their normal state and stay that way unless you hit the refresh. Mine when tapped will go active and then in about 10 sec. you see it flash really fast to inactive and then goes back really fast to active. If I turn the sensitivity down to the lowest CCW it just stays on active without the flash. A refresh returns it to inactive where it stays until you tap it again. Same with tamper. Take off the cover it says detected and put the cover back on and it remains as detected unless you press refresh then it says clear.

And I'm assuming you did an exclude and re-included it? What firmware does it say it is? Paste your device info section.

Yes I did an exclude and include. Which info on the device page are you wanting? Data, Status?

EDIT: I just did another exclude, removed battery for 30 sec. re-installed battery and did an include. From there I pressed the tamper switch once and the a configure. It now goes active when I tap on it and the 10 sec. later it shows inactive. Before it did not show an inactive without a refresh.
So it appears to be working except for the fact it goes inactive after 10 sec. That is still a problem.

Well I believe this device will only trigger an active on the first shock it senses and then 10 sec. later it will go back to inactive regardless if the vibration continuous or not. It is a first time sensor of a vibration like a glass break and doesn't need to do anything else because the glass has already been broken. :crazy_face:

Right, that's what I was saying. I think your exclude fixed it though like it did with mine. I don't think this device will stay active like you are hoping. It needs constant, strong changes in acceleration.

I can get mine to stay active if I am basically swinging it around and the setting under the lid on the PCB with the dial (potentiometer) is turned all the way to most sensitive.

That's why I ended up taking it out of service essentially. Now it is in my closet. When I want to turn my lamp on across the room after I change clothes in the dark I bump it. It turns on my nightstand lamp for 30 seconds so I can sneak across the room without waking my wife up.

Yea I agree. I think it would have to be tied to the side of a tank to get it to keep active. I will probably find a use for it down the road but if not no big deal. Thanks for all the help.

1 Like

Thanks for this, added driver yesterday your updates are very timely! What about HSM integration as a shock sensor? Is that what you have commented out in the driver code lines 293-323?

Nope. HSM doesn't support acceleration last time I checked.

The reason that code is commented is because the device sends two events to tell us it is accelerated. We only need one so I wrote code for both, chose one after and commented out the other.

I kept both in case the firmware ever changes and the other event gets dropped.

Thanks - I added a virtual door sensor, change state if acceleration. works great with HSM. But it looks like the garage door is left open all morning when the garbage man comes thru and shakes up the place :face_with_head_bandage:

The way I started to use mine was that I put it next to the flowers that needed to be watered. If I watered them I would also pick up the sensor and trigger acceleration. Then if I wondered if I had watered or not later I could check the last acceleration. I'm going to write a rule in RM for this eventually where it will warn me every hour once a week until I move the sensor but I haven't gotten around to it. I might either use it for watering once a week or multi-vitamins once a day. Haven't decided yet.

I think it is sad that the life and heath of your flowers is not a higher priority. :wink:

In my defense they are African Violets and they don't like tons of water!