The Aeotec Multisensor 6 is permanently powered and I have enabled Binary Sensor CC Report. I am not getting vibration reports (even if I deliberately drop it) and the _burglar entity is not showing up in HA, nor is it in the list of disabled entities.
Does anyone have vibration sensing working with their Aeotec Multisensor 6?
Edit:
The problem was the status of Tamper was not being cleared from the last time the event happened, and so was not recognised as a change of state therefore not providing the trigger. Solved by the automation that is triggered by Tampering then going on to clear the state by
If that’s what they are calling it now, then that’s one mystery solved.
The diagnostic panel shows an almost permanent tamper status but jiggling it about gives me the following log entry
2025-01-20T19:14:28.825Z SERIAL « 0x011700a80000010007097105000000ff07030000b9007f7f79 (25 bytes)
2025-01-20T19:14:28.830Z SERIAL » [ACK] (0x06)
2025-01-20T19:14:28.834Z CNTRLR [Node 007] [translateValueEvent: value updated]
commandClass: Notification
endpoint: 0
property: alarmType
propertyKey: undefined
internal: false
secret: false
event source: undefined
2025-01-20T19:14:28.836Z CNTRLR [Node 007] [~] [Notification] alarmType: 0 => 0 [Endpoint 0]
2025-01-20T19:14:28.838Z CNTRLR [Node 007] [translateValueEvent: value updated]
is root endpoint: true
is application CC: true
should hide root values: false
2025-01-20T19:14:28.842Z CNTRLR [Node 007] [translateValueEvent: value updated]
commandClass: Notification
endpoint: 0
property: alarmLevel
propertyKey: undefined
internal: false
secret: false
event source: undefined
2025-01-20T19:14:28.843Z CNTRLR [Node 007] [~] [Notification] alarmLevel: 0 => 0 [Endpoint 0]
2025-01-20T19:14:28.845Z CNTRLR [Node 007] [translateValueEvent: value updated]
is root endpoint: true
is application CC: true
should hide root values: false
2025-01-20T19:14:28.849Z DRIVER « [Node 007] [REQ] [BridgeApplicationCommand]
│ RSSI: -71 dBm
└─[NotificationCCReport]
notification type: Home Security
notification status: 255
notification state: Tampering, product cover removed
2025-01-20T19:14:28.851Z CNTRLR [Node 007] [handleNotificationReport] notificationName: Home Security
2025-01-20T19:14:28.853Z CNTRLR [Node 007] [handleNotificationReport] valueConfig:
label: Tampering, product cover removed
type: state
variableName: Cover status
2025-01-20T19:14:28.856Z CNTRLR [Node 007] [translateValueEvent: value updated]
commandClass: Notification
endpoint: 0
property: Home Security
propertyKey: Cover status
internal: false
secret: false
event source: undefined
2025-01-20T19:14:28.858Z CNTRLR [Node 007] [~] [Notification] Home Security[Cover status]: 3 => 3 [Endpoint 0]
2025-01-20T19:14:28.860Z CNTRLR [Node 007] [translateValueEvent: value updated]
is root endpoint: true
is application CC: true
should hide root values: false
Have you got any automations using these details that I could learn from? I don’t think it’s actually coming in as an event or state change. I’ll carry on trying different things in the meantime
I was getting those, earlier today. But now all I am getting is “last seen” entries. The tamper diagnostic setting won’t turn off. I think it only gets recorded when the state actually changes. So although the event is being logged in the actual logs, HA isn’t using it as a changed state. I think I might exclude this device and start over. Something’s obviously not working as intended.
I don’t think the notification reports are guaranteed, so I speculate that if ZWave/HA gets a report that tampering occurred, but later, the notification report to clear gets lost, then the state stays stuck.
The notification is actually multivalued: motion, tampering, cleared. So if tampering is stuck, then go walk in front of it to cause motion detection which should clear the tampering. If it doesn’t then I speculate that ZWaveJS is not handling this correctly (as I seem to recall this happened to me a couple of times)
Maybe I could get the tamper detection automation to also fire an event to clear it after a couple of minutes?
Event creation is very frustrating. My event looks pretty much identical whether I fired it manually or physically via the device - but the manual version doesn’t trigger the automation. I refuse to walk in front of it daily to reset it - that’s what automation is meant for!
@IngeJones Can you post the full rundown what you did? Your posts are really hard to follow since they just contain screenshots of code snippets without any context.
Which aspect of this are you interested in? Because it started off with me thinking the thing might be faulty (it’s not), went through a stage of me complaining that firing events manually wasn’t triggering the automation (I never did solve that) and ended up with me finding a very simple solution to clearing the tamper state so Home Assistant could see when it was tampered with again. So which stage do you want me to explain more fully?
@IngeJones I have the same sensor and just want things to happen when vibration starts/stops. It’s unclear what you added to which files, or how the button plays into any of that
In my case, the all clear wasn’t working to set the tamper setting to “clear” so when the next time the vibration was felt and notified to Home Assistant, it wasn’t seen as a change of state and therefore was not providing the trigger to my automation
I managed to discover a way to clear it in an automation, so that next time the Tamper vibration was felt, it would change the state from clear to tamper and trigger the automation. The way I did this was to Enable an entity on the device called “LR_Right Multi AE6_04 Idle Home Security Cover status”, which is a kind of fake button. Then, each time after the tamper alert triggered my automation, in the same automation I made it action pressing the fake button.
Here is a link that discusses these buttons. It seems the buttons are exactly for a case like this. I believe these buttons are just an internal HA thing and doesn’t involve ZWave.
