My SmartThings multipurpose sensors migrated today, and one of them no longer works. Another one isn’t sensing vibrations. Fun…
I run mine ST multipurpose sensors on @Mariano_Colmenarejo “ZigBee contact Mc” with no issues.
Me too, all working great
I just tried @Mariano_Colmenarejo ZigBee contact Mc, and it isn’t working for me either. I have that multipurpose contact on the garage door with garage door enabled, but only when I turn off the garage door mode and use the magnet does it work.
Did you set the xyz axis correctly? When I migrated, I needed to change them from the settings used by the DTH to get it to work.
When I use his driver nothing works with my multipurpose device since nothing changes at all in the app, even when I tried using the magnet which works on the SmartThings driver. Pulled the battery too and it just doesn’t work. At least the magnet works using the SmartThings driver.
- manufacturer: CentraLite
- model: 3321-S
My other multipurpose devices work in garage mode using the SmartThings driver.
- manufacturer: Samjin
- model: multi
I had another 3321-S in the closet so I connected it brand new and it’s working with @Mariano_Colmenarejo driver. And it’s working with the SmartThings driver as well. So it looks like their migration messed up some of my multipurpose devices.
My 2015 Model Samsung SmartThings multipurpose sensors don’t work in Garage-mode either… not with the ST edge driver nor with Mariano’s driver… Luckily, I got @brbeaird 's MyQ system working so I no longer require these sensors…
Is it just the garage mode issue that you’re referring to? Because the official transition FAQ says that that will no longer be supported in the new architecture for the first generation, smartthings multisensor models.
I just had Samsung multisensor converted to edge and this is what I have under settings.
To confirm without there being the magnetic contact it shows as closed.
I believe this has come up before and what the FAQ is trying to say is that the “garage sense” will now be handled in the stock driver. Apparently the stock DTH didn’t support it and so users had to install a custom one to get that functionality?
I only have of the samjin model, but the other models were working for other users.
In these devices, the initial configuration of the acceleration cluster is important.
I recommend a pairing from uninstall device, with whatever driver you want to use.
The DTH uses a string type garage preference and the stock driver now uses a boolean type and may fail and not work. I said that more than a year ago when I detected it and it gave me the error when using the stock driver.
When you later change drivers, the stock driver does not perform the configuration.
Mine does, but the device does not always respond that it accepts the configuration, although it no longer loses the one it had.
For the correct operation with the garage door, in the stock driver they have kept the Z axis as the axis used, but I don’t know if it would coincide with the DTH.
In the stock driver, you have to physically orient the axis looking at the values of each axis in the app and when an open (approx 0g) and close (approx 1g) is issued.
In my driver you can orient it as best suits you or you already have on your door and then change the X, Y or Z axis used, in the preference settings until it works correctly open / close
I replace my original garage door multipurpose device with the same model spare that works in garage mode. I then recreated the Automations for it since they were also lost, and added it to all my Intrusion Automations which I had to re-enable since they were disabled by the migration effort too probably because of this device’s migration going wrong. I also had to change to the new device on my Alexa open/close announcement Routines. I need to check my backup screenshots to ensure that I didn’t forget anything which in hindsight was a great idea that someone suggested in the migration thread. Then I’ll delete the original one and re-connect it to see if it starts working again since this same model spare I had seems to be working fine when I connected it.
I checked all of my other multipurpose devices, and all of them are reporting Open/Close since they are mounted with the magnets, but some of them are not reporting vibration. If re-adding the original garage multipurpose device works, and since some of the others are also having issues with the SmartThings migration, I’m just going to work on re-connecting each one since I don’t want any security issues. I’ll just use a virtual contact switch as a placeholder in my Automations and Alexa Routines for each one before resetting it, and then add it back to all of the Automations and Alexa Routines.
What fun, looks like I’m going to have a busy day while watching the NFL Championship games today (smile).
Vibration detection and tilt detection are both accelerometer functions, which is a different sensor than the open/close detection. (That’s why this device is a “multi sensor” – – it actually has multiple sensors inside.)
If I understand @Mariano_Colmenarejo ’s post, it sounds like the stock edge driver is not properly initializing the XYZ values for the accelerometer inside these devices.
I don’t know what lifecycles are called in the migration of a device from DTH to Edge, I don’t know if it’s published.
Depending on which lifecycles are executed, there may be cluster attributes that are not configured and it is also not known if they would lose the configuration they had with the DTH.
Zigbee Contact is a driver with many subdrivers, with their lifecycles defined in each of them.
Lifecycles defined in subdrivers take priority over lifecycles defined in the main init.lua module.
It is complicated and easy to make incompatibility errors between them.
When the init lifecycle is called, on the multipurpose smartthings and centralite subdrivers they configure the battery voltage and IASZone I think. The samjin subdriver, I think only IASZone.
Other driver sensors, which measure temperature, in the init lifecycle configure temperature and IASZone.
Others like ewelink configure battery and IASZone, and others only IASZone
CUSTOM ACCELERATION CLUSTER 0xFC02 only is configured when the doConfigure lifecycle is called when installing from scratch.
I don’t know during the migration
So maybe during the migration something is not configured correctly.
- id: Smartsense/multi/1 deviceLabel: Multipurpose Sensor manufacturer: SmartThings model: PGC313 deviceProfileName: smartsense-multi - id: Smartsense/multi/2 deviceLabel: Multipurpose Sensor manufacturer: SmartThings model: PGC313EU deviceProfileName: smartsense-multi
I think you’re right, these smartthings multipurpose models don’t have a garage door option in the profile.
But have an inconsistency in the subdriver, which refers to that preference, which the profile does not have.
My garage door multisensor migrated today/last night. When it came over, the “use on garage door” setting in the stock driver was disabled. I turned it back on, but I had to open and close the door to get the status to sync up. After that it seems good (so far).
Ya, but the version 1 and version 2 multipurpose devices appear identical. There’s is no real difference between them.
I read that article when SmartThings first announced Edge, and when I tried to figure out if I had any of the Version 1 devices, I thought I didn’t from the limited information Samsung has available.
Anyway, it appears that I have four of the Version 1 multipurpose devices which came with the Hub V2 kit when I purchased it.
As for them advising that only the garage feature will no longer be supported for whatever reason other than the Axis numbers never change, there’s also the fact that the Version 1 devices Vibration feature also does not work. Only the Open/Close using the magnet and Temperature work even though Axis and Vibration are still shown in the SmartThings GUI.
The device model that doesn’t work correctly is this one, right?
- manufacturer: CentraLite
- model: 3321-S
As mentioned by @orangebucket, above, the statement shared by @JDRoberts means that you no longer need a dedicated driver for this functionality, the same driver that handles it as contact sensor can handle it as a garage door sensor with that setting enabled.
So, if it’s not working properly for the model you mention, it means its messages aren’t handled as they should.
To verify and report that issue, I need your help by getting the following info:
- Confirm which is the fingerprint from the device with the issue
- Send the driver logs from the moment you pair the device until you try to open/close the door.
This is to check how is the device configured, what is being received from it, and how it is processed by the driver.
You can send the logs to email@example.com
So I think I have the opposite situation in terms of age of the sensors happening with my multi-sensors. I have 2 multi-sensors on my garage door (because inevitably one will report open when the door was really closed, but that’s a whole other story) that came with the SmartThings Home Monitoring kit I bought December 2016. That kit came with a Version 2 hub. On the sensor itself it says “SmartSense Multi, Designed by SmartThings”. I am using them with Mariano’s driver, garage door is set to Yes, and the sensor axis had to be set to the Y axis. They are working great (thanks @Mariano_Colmenarejo !)
Last year I bought an Aeotec Multipurpose sensor which I have yet to use. The box also says Samjin on it, and the back of the sensor itself says it is the IM6001-MPP. To test for this discussion, I added it to my system, and it picks up Mariano’s driver. However, it only seems to work with the magnet to detect open/close. The vibration sensor is stuck on vibration detected, the axis sensors don’t change, but the temperature does seem to change. Setting it to garage mode does not work, and I have tried all 3 axes. The axis sensor numbers don’t change, nor does the vibration detection.
So the question is, why are the older devices working fine, but the newer one does not?
I have 3 sensors of this model and they work well with the Zigbee Contact Mc driver.