Aeotec Multisensor not working with Garage Door on latest Edge Driver

I have an Aeotec Multisensor attached to my garage door and am using the beta edge drivers zigbee contact driver and the sensor never updates from Open to Closed, no matter what tilt direction I move the sensor. I’m assuming this is a bug with the edge driver, but I figured i’d post here in case anyone else is seeing the same issue. Thoughts?

There was another report regarding the motion sensor

There were some updates that I saw on GitHub working their way through the approval process to address Aeotec devices, so it seems that ST staff are aware. The easy solution would be to use the manufacturer’s driver:

1 Like

Thanks. I wasn’t aware of that page so that will help with another issue i’ve been having. However, it doesn’t look like the Multipurpose sensor is listed, only their Z-Wave sensors. Any idea on the Zigbee Multipurpose sensor (the one that used to be SmartThings branded)?

Sorry - missed where you said zigbee and not used to calling these Aeotec.

Mine are also on the beta driver. I see the same. The garage door setting has no effect. Contact sensor capability status continues to be triggered by the magnetic reed, with the 3 axis doing nothing.

I just commented on the latest merge for that driver on GitHub. We will see what they come back with.

@nayelyz I was asked to reach out to you regarding this so that an issue can get created with the dev team to get this fixed.

Hi, @mzp!

There are two things I need your help with, please:

  1. Do you know the device’s fingerprints? In the Zigbee-contact driver, I couldn’t find any with the manufacturer “Aeotec”
  2. Can you share the driver logs? This is to see the incoming messages of the device events and how they’re being handled.
    This can be done with the CLI command: smartthings edge:drivers:logcat --hub-address=x.x.x.x

Note: Remember to replace x.x.x.x with the actual IP address of the Hub that you can find in the IDE or your router’s config.

@philh30 Any chance you have logs on the multipurpose? I’m not at the location that has the device so I can’t pull them at the moment. As for the fingerprints, it’s the standard SmartThings Multipurpose sensor that’s existed forever but was rebranded as Aeotec recently.
Part Number IM6001 -MPP01

I use @Mariano_Colmenarejo Edge Driver for the Aeotec Multipurpose sensor which allows you o choose the X, Y or Z axis in settings.

No. I’m at work now, but can run logs tonight.

1 Like

I was debating on moving over to that one but I have so many devices across multiple locations that I was hoping they would get this one working correctly as it does with the DTH.

Hi @philh30

This problem may be due to the fact that the garage Door preference in the DTH is type text, Yes or No.
In the stock driver they have changed it to a Boolean type and then when changing to the stock driver, if you had the Yes option, it does not recognize it.

My driver still keeps the text type.

It should be fixed by changing garage to false and back to true. It worked for me in some tests I did.

@nayelyz when will doo the automatic migration this will be a problem to users using as garage door

1 Like

@nayelyz Logs are changing the garage door opener setting to true and then moving the device in various ways. I trimmed logs to just two of the 3 axis zigbee reports - there are plenty more of the same.

deviceManufacturerCode: Samjin
deviceModel: multi
2022-09-09T12:46:07.463298432+00:00 TRACE Zigbee Contact  Received event with handler device_lifecycle
2022-09-09T12:46:07.569030432+00:00 INFO Zigbee Contact  <ZigbeeDevice: f81713cc-c635-4e87-be44-1691418f6b8f [0xB23B] (Washing Machine)> received lifecycle event: infoChanged
2022-09-09T12:46:07.637132432+00:00 TRACE Zigbee Contact  <ZigbeeDevice: f81713cc-c635-4e87-be44-1691418f6b8f [0xB23B] (Washing Machine)> received unhandled lifecycle event: infoChanged
2022-09-09T12:46:07.666776432+00:00 DEBUG Zigbee Contact  Washing Machine device thread event handled
2022-09-09T12:46:07.675677432+00:00 DEBUG Zigbee Contact  driver device thread event handled
2022-09-09T12:46:11.275127668+00:00 TRACE Zigbee Contact  Received event with handler zigbee
2022-09-09T12:46:11.548300520+00:00 INFO Zigbee Contact  <ZigbeeDevice: f81713cc-c635-4e87-be44-1691418f6b8f [0xB23B] (Washing Machine)> received Zigbee message: < ZigbeeMessageRx || type: 0x00, < AddressHeader || src_addr: 0xB23B, src_endpoint: 0x01, dest_addr: 0x0000, dest_endpoint: 0x01, profile: 0x0104, cluster: 0xFC02 >, lqi: 0x98, rssi: -62, body_length: 0x0018, < ZCLMessageBody || < ZCLHeader || frame_ctrl: 0x0C, mfg_code: 0x1241, seqno: 0x04, ZCLCommandId: 0x0A >, < ReportAttribute || < AttributeRecord || AttributeId: 0x0010, DataType: Bitmap8, Bitmap8: 0x01 >, < AttributeRecord || AttributeId: 0x0012, DataType: Int16, Int16: 164 >, < AttributeRecord || AttributeId: 0x0013, DataType: Int16, Int16: 1103 >, < AttributeRecord || AttributeId: 0x0014, DataType: Int16, Int16: -914 > > > >
2022-09-09T12:46:11.752083694+00:00 TRACE Zigbee Contact  Found ZigbeeMessageDispatcher handler in zigbee_contact -> Zigbee Multi Sensor
2022-09-09T12:46:11.763417691+00:00 INFO Zigbee Contact  Executing ZclGlobalCommandHandler: cluster: 0xFC02, command: ReportAttribute
2022-09-09T12:46:11.806668306+00:00 INFO Zigbee Contact  <ZigbeeDevice: f81713cc-c635-4e87-be44-1691418f6b8f [0xB23B] (Washing Machine)> emitting event: {"attribute_id":"acceleration","capability_id":"accelerationSensor","component_id":"main","state":{"value":"active"}}
2022-09-09T12:46:11.834377153+00:00 INFO Zigbee Contact  <ZigbeeDevice: f81713cc-c635-4e87-be44-1691418f6b8f [0xB23B] (Washing Machine)> emitting event: {"attribute_id":"threeAxis","capability_id":"threeAxis","component_id":"main","state":{"value":[-914,164,1103]}}
2022-09-09T12:46:11.869898572+00:00 DEBUG Zigbee Contact  Washing Machine device thread event handled
2022-09-09T12:46:12.181508966+00:00 TRACE Zigbee Contact  Received event with handler zigbee
2022-09-09T12:46:12.190704562+00:00 INFO Zigbee Contact  <ZigbeeDevice: f81713cc-c635-4e87-be44-1691418f6b8f [0xB23B] (Washing Machine)> received Zigbee message: < ZigbeeMessageRx || type: 0x00, < AddressHeader || src_addr: 0xB23B, src_endpoint: 0x01, dest_addr: 0x0000, dest_endpoint: 0x01, profile: 0x0104, cluster: 0xFC02 >, lqi: 0x94, rssi: -63, body_length: 0x0014, < ZCLMessageBody || < ZCLHeader || frame_ctrl: 0x0C, mfg_code: 0x1241, seqno: 0x05, ZCLCommandId: 0x0A >, < ReportAttribute || < AttributeRecord || AttributeId: 0x0012, DataType: Int16, Int16: 27 >, < AttributeRecord || AttributeId: 0x0013, DataType: Int16, Int16: 83 >, < AttributeRecord || AttributeId: 0x0014, DataType: Int16, Int16: 1034 > > > >
2022-09-09T12:46:12.210415412+00:00 TRACE Zigbee Contact  Found ZigbeeMessageDispatcher handler in zigbee_contact -> Zigbee Multi Sensor
2022-09-09T12:46:12.215893150+00:00 INFO Zigbee Contact  Executing ZclGlobalCommandHandler: cluster: 0xFC02, command: ReportAttribute
2022-09-09T12:46:12.222905321+00:00 INFO Zigbee Contact  <ZigbeeDevice: f81713cc-c635-4e87-be44-1691418f6b8f [0xB23B] (Washing Machine)> emitting event: {"attribute_id":"threeAxis","capability_id":"threeAxis","component_id":"main","state":{"value":[1034,27,83]}}
2022-09-09T12:46:12.242448421+00:00 DEBUG Zigbee Contact  Washing Machine device thread event handled

@nayelyz The preference is namespaced in the profile:

Should it also be namespaced when it’s used in the driver?

1 Like

Sorry for the delay. This is just to let you know that the difference with the preference type was reported. I’ll let you know the team’s feedback.
About the preference’s reference, in the driver we use the preference’s name to get its value, certifiedpreferences.garageSensor is the preference’s ID:

smartthings device-preferences certifiedpreferences.garageSensor -j
{
    "preferenceId": "certifiedpreferences.garageSensor",
    "name": "garageSensor",
    "title": "Use on garage door",
    "required": false,
    "explicit": false,
    "preferenceType": "boolean",
    "definition": {
        "default": false
    }
}

This field isn’t used in the device profile but if we create one, it will use the same namespace of our custom capabilities and we would have to include it in the profile with the property preferenceId

I did get mine to work after having the same problem. I know its a bit of a workaround but here it is.

Once you’ve discovered the device and verified it’s not working. Don’t delete the device. Go to the sensor and reset it by pushing the button. Then scan for new devices. Once device is discovered a second time check and see if its working.

I’ve had to do this for all my multi sensors.

In this case, the device is working fine, but there’s an error in the ST driver. As I noted above, the preference was changed from garageSensor to certifiedpreferences.garageSensor in the profile, but the rest of the driver wasn’t updated to reflect that change. Once that error is fixed, the garage door setting works fine.

2 Likes

You are correct. Just did a test and although the thee axis and vibration started working the garage door didn’t i thought it did before but i was wrong

1 Like

Found something else. Switched driver to @Mariano_Colmenarejo multipurpose edge driver. It started working but in reverse. In the settings I changed change the sensor axis for garage door state from the Z axis to the Y axis. Then it started working I tested it multiple times and now it’s working.

I had the same “reverse” issue with that driver. I still haven’t gotten it to work correctly. But I think I may have something wrong with the device itself as the numbers it’s reporting for the axis are rather different than other devices I have. Not sure if that is an Aeotec vs ST device issue or what, but my understanding was they were the exact same but with a different brand on them.