[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.

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)