Deconz-rest-plugin: Samsung GP-U999SJVLAEA SmartThings Multipurpose sensor vibration not working

[hellcry37]

Hello,

I have 3 x Samsung GP-U999SJVLAEA SmartThings Multipurpose sensors that pair OK, work OK except one little bug. Vibration is detected every ~1h even if sensor is not moved.

I'll attach a screenshot of the event like is shown in HA history.

Link: https://postimg.cc/2qttM1Fy

All 3 sensors have the same behavior.

The issue is not new, it is like this from the first time I used them in deCONZ first time, the time they were introduced and added as supported.

Sensors detect vibration if i move them or so correctly, but have this bug where vibration is detected every one hour or so.

Can you guys please investigate?

Note:
From the time I first tried the sensors and until now when I use deCONZ 2.05.69 firmware I reseted my deCONZ ConBee II at least 2 times and re added all sensors.

[marcelodavanzo]

I can confirm I'm using these sensors with a Conbee II into Home Assistant via deCONZ (have tried the marthoc build and the add-on) and get the exact same issue.

[hellcry37]

still happening

[xavipolo]

Hi, I'm interested in buying this sensor, but one of the reasons for doing so was the vibration detector.

Does the sensor send out battery status?
Can you look at the sensor details with the API
http://dresden-elektronik.github.io/deconz-rest-doc/sensors/?

Greetings

[willpall7]

Same behavior here. I have four of these sensors, and all four report motion every 3,640 seconds. The motion state is "on" for 65 seconds, then goes off again. 3,640 seconds after the start of the first event, it repeats. (so, 65 sec. on; 3,575 sec. off; repeat;)

The x, y, and z values are identical across the last 100 events. I'm not sure if this is deconz or Home Assistant or just that sensor sending out a proprietary packet.

[willpall7]

I just found some log entries that line up with the hourly motion reports from a Samjin multi sensors. These log entries match up with the 65-second "on" period for the motion sensors.

Node ...453C is sensor 21.

22:16:47:969 no button map for: multi ep: 0x01 cl: 0xFC02 cmd: 0x0A pl[0]: 012
22:16:47:969 ZCL attribute report 0x286D9700010B453C for cluster 0xFC02, ep 0x01
22:17:53:263 sensor 21 (multi): disable vibration

Node ...400D is sensor 18.

22:34:19:724 no button map for: multi ep: 0x01 cl: 0xFC02 cmd: 0x0A pl[0]: 012
22:34:19:724 ZCL attribute report 0x286D9700010B400D for cluster 0xFC02, ep 0x01
22:35:24:759 sensor 18 (multi): disable vibration

Here's the full log around that last one, for context:

22:34:19:724 no button map for: multi ep: 0x01 cl: 0xFC02 cmd: 0x0A pl[0]: 012
22:34:19:724 ZCL attribute report 0x286D9700010B400D for cluster 0xFC02, ep 0x01
22:34:19:843 no button handler for: button ep: 0x01 cl: 0x0500 cmd: 0x0A pl[0]: 0x02
22:34:19:844 ZCL attribute report 0x286D970001084BC7 for cluster 0x0500, ep 0x01
22:34:19:983 ZCL configure reporting rsp seq: 248 0x286D9700010B400D for cluster 0xFC02 attr 0x0012 status 0x00
22:34:19:983 ZCL configure reporting rsp seq: 248 0x286D9700010B400D for cluster 0xFC02 attr 0x0013 status 0x00
22:34:19:983 ZCL configure reporting rsp seq: 248 0x286D9700010B400D for cluster 0xFC02 attr 0x0014 status 0x00
22:34:20:247 Bind response success for 0x286d9700010b400d cluster 0x0001
22:34:20:761 Bind response success for 0x286d9700010b400d cluster 0x0001
22:34:25:284 button 1002 On with timed off
22:34:37:878 ZCL attribute report 0x286D97000106AA5A for cluster 0x0500, ep 0x01
22:34:44:539 no button map for: motion ep: 0x01 cl: 0x0402 cmd: 0x0A pl[0]: 000
22:34:44:539 ZCL attribute report 0x286D9700010D4FDE for cluster 0x0402, ep 0x01
22:34:46:581 ZCL attribute report 0x286D9700010D4FDE for cluster 0x0500, ep 0x01
22:34:57:599 ZCL attribute report 0x286D97000105E223 for cluster 0x0500, ep 0x01
22:34:57:600 discard double entry in binding queue (size: 7) for for 0x286D97000105E223, cluster 0x0001
22:34:57:876 button 1002 On with timed off
22:35:03:542 no button map for: motion ep: 0x01 cl: 0x0402 cmd: 0x0A pl[0]: 000
22:35:03:542 ZCL attribute report 0x286D97000106BF11 for cluster 0x0402, ep 0x01
22:35:04:887 ZCL attribute report 0x286D97000106BF11 for cluster 0x0500, ep 0x01
22:35:07:885 ZCL attribute report 0x286D9700010B4576 for cluster 0x0500, ep 0x01
22:35:13:507 Current channel 15
22:35:13:532 Device TTL 2338 s flags: 0x7
22:35:18:482 GW firmware version: 0x264a0700
22:35:18:482 GW firmware version is up to date: 0x264a0700
22:34:19:724 no button map for: multi ep: 0x01 cl: 0xFC02 cmd: 0x0A pl[0]: 012
22:34:19:724 ZCL attribute report 0x286D9700010B400D for cluster 0xFC02, ep 0x01
22:35:24:759 sensor 18 (multi): disable vibration

[willpall7]

I enabled info 2 logging, and got the logs below for another sensor.

At this point, it appears that the sensor is polled once every hour(-ish) (or is the sensor waking up and sending?), and no matter what the accelerometer values are, they result in a vibration: true result. Then, 65 sec. later, false is assumed and pushed out.

I tapped on a different sensor and saw several results stream in, then an artificial vibration: false update sent 65 sec. later.

Would the fix for this be storing the previous xyz values and comparing when the cluster is read again? If no (or little) change is seen on each of the 3 axes, then no motion occurred?

23:14:41:641 Node data 0x286d9700010b4576 profileId: 0x0104, clusterId: 0xFC02 23:14:41:642 update ZCL value 0xFC02/0x0012 for 0x286D9700010B4576 after 335 s 23:14:41:642 update ZCL value 0xFC02/0x0013 for 0x286D9700010B4576 after 335 s 23:14:41:642 update ZCL value 0xFC02/0x0014 for 0x286D9700010B4576 after 335 s 23:14:41:642 no button map for: multi ep: 0x01 cl: 0xFC02 cmd: 0x0A pl[0]: 012 23:14:41:642 ZCL attribute report 0x286D9700010B4576 for cluster 0xFC02, ep 0x01 23:14:41:642 payload: 1200290900130029d0fb1400292300 23:14:41:643 Websocket 172.30.32.1:44062 send message: { "e":"changed", "id":"24", "r":"sensors", "state":{ "lastupdated":"2020-01-22T07:14:41", "orientation":[9,-1072,35], "vibration":true }, "t":"event", "uniqueid":"28:6d:97:00:01:0b:45:76-01-fc02" } (ret = 186) 23:14:41:645 discard sensor state push for 24: state/lastupdated (already pushed) 23:14:41:646 discard sensor state push for 24: state/vibration (already pushed) 23:14:41:648 discard sensor state push for 24: state/lastupdated (already pushed) 23:14:41:650 discard sensor state push for 24: state/vibration (already pushed) 23:14:41:651 discard sensor state push for 24: state/lastupdated (already pushed)
...snip...

23:15:46:773 sensor 24 (multi): disable vibration
23:15:46:789 Websocket 172.30.32.1:44062 send message:
{
    "e":"changed",
    "id":"24",
    "r":"sensors",
    "state":{
        "lastupdated":"2020-01-22T07:15:46",
        "orientation":[9,-1072,35],
        "vibration":false
    },
    "t":"event",
    "uniqueid":"28:6d:97:00:01:0b:45:76-01-fc02"
}(ret = 187)
23:15:46:791 discard sensor state push for 24: state/lastupdated (already pushed)

[hellcry37]

Finally this is getting a little attention, unfortunately deconz is as usual slow to almost not moving when is to repair stuff that don't work or support, they relay on community almost entirely.

TBH if I'd find another zigbee hub that work in the same way I'd move tomorrow from deconz to other solutions.

P.S. Don't hold your breath for this to be fixed anytime soon.

[blair287]

I have just got this stick and im starting to dis like it my smartthings outlet is seen as a light and no power reporting and now my multipurpose senor vibration is sending me false reports every hour so is useless. Im finding more and more bugs left right and center is there another zigbee gateway available?

[hellcry37]

try ZiGate USB-TTL, seem that deCONZ not fixing anything that needs fixing. I did not try it yet cant say if they good or not, but they can't be any worse then this.

[jcallaghan]

@ebaauw @manup any help you can add here? I'd be happy to donate a sensor to anyone that is able to help address this if that helps?

[ebaauw]

I don't know this sensor, and I didn't add support for it, but here's my 2 cents.

Checking the code, the behaviour you're experiencing seems intentional. On receiving an attribute report for any of the acceleration axis attributes, irrespective of their value, the REST API plugin sets vibration for 65 seconds.

https://github.com/dresden-elektronik/deconz-rest-plugin/blob/69946322ade31ba98f2d0827f3dc7a8fc07a71b5/de_web_plugin.cpp#L6501-L6510

Also, the REST API configures the axis attributes to report every hour, in addition to on changes. I suppose the 40 seconds are due to the precision of the sensor's internal clock.
https://github.com/dresden-elektronik/deconz-rest-plugin/blob/69946322ade31ba98f2d0827f3dc7a8fc07a71b5/bindings.cpp#L1418-L1425

The code already checks if any of the axis attributes has actually changed. I think if you set websocketnotifyall to false, the orientation won't be included in the web socket event, when none of the attributes has changed.

It would be easy to set a flag, keep track if any of the attributes has changed, and move the code to set vibration after loop over the event attributes, based on that flag. It would make sense to deduplicate the code and set state.lastupdated and the save-database flag there as well. That would also prevent the "already pushed" messages.

I think the resource should expose a user settable config.duration instead of using a hard-coded duration of 65 seconds.

While it seems straightforward enough, I'm a bit reluctant to change the code without having an actual device to test. @jcallaghan I'll be happy to take you up on your offer. Please email me, or pm me on the homebridge slack for my address.

[jcallaghan]

Thanks for sharing this and for taking the time to summarise the state of things. I'd sent you a PM on Slack so hopefully, we can arrange to get you a device and get this issue sorted once and for all. Many people use this sensor for the additional vibration/tamper sensor it provides and with integration into Home Assistant through deCONZ the potential for how it can be used are limitless.

[ebaauw]

Received the sensor today. Will have a look this weekend.

EDIT Added support to homebridge-hue v0.11.58.

[ebaauw]

I think the resource should expose a user settable config.duration instead of using a hard-coded duration of 65 seconds.

Looks like some-one copied the code for the Xioami vibration sensor, lumi.vibration, without understanding it. The Xioami sends a message every ~60 seconds while detecting vibration, so we can only conclude "no vibration" after this interval. Hence the hard-coded duration of 65 seconds.
The SmartThings sensor sends a message every second while it detects vibration, so a hard-code duration of 65 seconds makes no sense.

I changed the logic as described in my previous entry. I think it's looking good (note that I've set websocketnotifyall to false):

Mar 14 12:57:05 pi1 deCONZ[22465]: 12:57:05:712 APS-DATA.indication srcAddr: 0x953c, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0xFC02, lqi: 255, rssi: -13
Mar 14 12:57:05 pi1 deCONZ[22465]: 12:57:05:712     asdu: 0c41127a0a120029feff130029ceff14002910fc
Mar 14 12:57:05 pi1 deCONZ[22465]: 12:57:05:713 Node data 0x286d9700010889a5 profileId: 0x0104, clusterId: 0xFC02
Mar 14 12:57:05 pi1 deCONZ[22465]: 12:57:05:713 0x286D9700010889A5: update ZCL value 0x01/0xFC02/0x0012 after 0 s
Mar 14 12:57:05 pi1 deCONZ[22465]: 12:57:05:713 0x286D9700010889A5: update ZCL value 0x01/0xFC02/0x0013 after 0 s
Mar 14 12:57:05 pi1 deCONZ[22465]: 12:57:05:713 0x286D9700010889A5: update ZCL value 0x01/0xFC02/0x0014 after 0 s
Mar 14 12:57:05 pi1 deCONZ[22465]: 12:57:05:714 no button map for: multi ep: 0x01 cl: 0xFC02 cmd: 0x0A pl[0]: 012
Mar 14 12:57:05 pi1 deCONZ[22465]: 12:57:05:714 ZCL attribute report 0x286D9700010889A5 for cluster: 0xFC02, ep: 0x01, frame control: 0x0C, mfcode: 0x1241
Mar 14 12:57:05 pi1 deCONZ[22465]: 12:57:05:714     payload: 120029feff130029ceff14002910fc
Mar 14 12:57:05 pi1 deCONZ[22465]: 12:57:05:714 APS-DATA.request id: 43, addrmode: 0x02, addr: 0x953c, profile: 0x0104, cluster: 0xFC02, ep: 0x01 -> 0x01 queue: 1 len: 5 tx.options 0x00
Mar 14 12:57:05 pi1 deCONZ[22465]: 12:57:05:718 Websocket 127.0.0.1:47512 send message: {"e":"changed","id":"13","r":"sensors","state":{"lastupdated":"2020-03-14T11:57:05","orientation":[-2,-50,-1008]},"t":"event","uniqueid":"28:6d:97:00:01:08:89:a5-01-fc02"} (ret = 171)
Mar 14 12:57:05 pi1 deCONZ[22465]: 12:57:05:719 discard sensor state push for 13: state/orientation_y (already pushed)
Mar 14 12:57:05 pi1 deCONZ[22465]: 12:57:05:721 discard sensor state push for 13: state/orientation_z (already pushed)
Mar 14 12:57:05 pi1 deCONZ[22465]: 12:57:05:722 discard sensor state push for 13: state/vibration (already pushed)
Mar 14 12:57:05 pi1 deCONZ[22465]: 12:57:05:724 discard sensor state push for 13: state/lastupdated (already pushed)

When disturbing the sensor, with config.duration set to 1, I get:

Mar 14 12:59:46 pi1 dc_eventlog[795]: /sensors/13/state: {"lastupdated":"2020-03-14T11:59:46","orientation":[-1005,212,-914],"vibration":true}
Mar 14 12:59:47 pi1 dc_eventlog[795]: /sensors/13/state: {"lastupdated":"2020-03-14T11:59:47","orientation":[1,-39,-999]}
Mar 14 12:59:48 pi1 dc_eventlog[795]: /sensors/13/state: {"lastupdated":"2020-03-14T11:59:48","orientation":[3,-36,-1012]}
Mar 14 12:59:49 pi1 dc_eventlog[795]: /sensors/13/state: {"lastupdated":"2020-03-14T11:59:49","orientation":[4,-39,-1007]}
Mar 14 12:59:50 pi1 dc_eventlog[795]: /sensors/13/state: {"lastupdated":"2020-03-14T11:59:50","orientation":[0,-40,-1009]}
Mar 14 12:59:51 pi1 dc_eventlog[795]: /sensors/13/state: {"lastupdated":"2020-03-14T11:59:51","vibration":false}

Changing config.duration works as intended:

Mar 14 13:00:59 pi1 dc_eventlog[795]: /sensors/13/config: {"duration":5}
Mar 14 13:01:11 pi1 dc_eventlog[795]: /sensors/13/state: {"lastupdated":"2020-03-14T12:01:11","orientation":[-407,-52,-2047],"vibration":true}
Mar 14 13:01:12 pi1 dc_eventlog[795]: /sensors/13/state: {"lastupdated":"2020-03-14T12:01:12","orientation":[2,-38,-1009]}
Mar 14 13:01:13 pi1 dc_eventlog[795]: /sensors/13/state: {"lastupdated":"2020-03-14T12:01:13","orientation":[1,-32,-998]}
Mar 14 13:01:14 pi1 dc_eventlog[795]: /sensors/13/state: {"lastupdated":"2020-03-14T12:01:14","orientation":[0,-36,-1004]}
Mar 14 13:01:15 pi1 dc_eventlog[795]: /sensors/13/state: {"lastupdated":"2020-03-14T12:01:15","orientation":[1,-45,-1006]}
Mar 14 13:01:20 pi1 dc_eventlog[795]: /sensors/13/state: {"lastupdated":"2020-03-14T12:01:20","vibration":false}

Setting config.duration to 0 causes state.vibration to remain true indefinitely.

Note that config.duration will be added when loading the sensor from the database, no need to re-pair it.

Now, I need to resist the urge to play with the sensor for an hour or so, to check what happens on the periodic report ;-(

[ebaauw]

There's something else wrong: when changing the contact, two notifications are sent:

Mar 14 13:04:32 pi1 dc_eventlog[795]: /sensors/11/state: {"lastupdated":"2020-03-14T12:04:32","open":true}
Mar 14 13:04:32 pi1 dc_eventlog[795]: /sensors/11/state: {"lastupdated":"2020-03-14T12:04:32"}
...
Mar 14 13:04:50 pi1 dc_eventlog[795]: /sensors/11/state: {"lastupdated":"2020-03-14T12:04:50","open":false}
Mar 14 13:04:50 pi1 dc_eventlog[795]: /sensors/11/state: {"lastupdated":"2020-03-14T12:04:50"}

This is caused by the superfluous configuration of attribute reporting for _Zone Status_ (0x0002) in the _IAS Zone_ cluster (0x0500). When the contact changes, the sensor now sends two messages, a _Zone State Change Notification_ command, and a _Report Attributes_ command. The REST API plugin handles both, causing the two events.

The sensor doesn't support supervision reports, so I suppose the attribute reporting is needed for periodic reports. It should have been configured only for that. I would expect that _Min Report Interval_ should be set to 65535 to achieve that, but the sensor doesn't accept a value greater than the _Max Report Interval_ value. Setting the reporting to 300/300 stops the event-based attribute report, though.

Also, it doesn't make sense to me that the periodic reporting for the orientation (vibration) is set to an hour, whereas the open/close and temperature are reported every 5 minutes.

EDIT Looking at the code, I think the same issue would apply to the other Samjin sensors as well. I don't understand the Centralite logic: they seem to configure the reporting to match config.duration, but what if that's changed? If those sensors support restore reports, config.duration shouldn't even be exposed. If they don't, the alarm wouldn't be cleared and this code would effectively cause config.duration to be ignored, because the new report would reset durationDue.

[ebaauw]

Now, I need to resist the urge to play with the sensor for an hour or so, to check what happens on the periodic report ;-(
Also, it doesn't make sense to me that the periodic reporting for the orientation (vibration) is set to an hour, whereas the open/close and temperature are reported every 5 minutes.

Changed the reporting of the orientation attributes to 5 minutes as well (so I don't have to wait that long ;-). I pushed the changes to my existing PR #2553 (for setting the state of /lights resources), which @manup, understandably, wants to test extensively before merging. They will probably be released with v2.05.77.

[hellcry37]

as of right now 2.05.75, this still happens, left a sensor connected especially for this, I'll wait for this update

[greencharlie100]

Also have the same issue with SmartThings Multipurpose Sensors. Had to remove them due to false vibration detections 1-2 times every hour.

[ebaauw]

Bloody hell, the sensor actually reports vibration through the 0x0010 _Active_ attribute, resetting it ~10 seconds after the last acceleration report. See #1264. I'll remove config.duration and the automatic clearing of state.vibration. Also changing the reporting settings in line with the Samsung SmartThings settings. Finally will update general.xml, to show additional attributes.

[blair287]

See this issue still not fixed terrible customer support.

[hellcry37]

Seriously I used to be frustrated also about this deconz s**t, got tired of all the little bugs and stuff, moved to zha, my head doesn't hurt anymore. Plus when you have a problem with deconz good luck fixing it faster then 6 months or never :) I'd suggest you do the same, move to ZHA or Zigbee2MQTT.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.