Smartthings Multipurpose Sensor 2018 Model

🛎️ Get Help
41

So it joined as a V4?, if that's the case that's on us and we can fix it.

42

Mike it actually joined as "SmartSense Multi Sensor V4". I don't know if this matter, but of course, I joined it back when I started this thread in 2.0.4. I removed it while I waited for 2.0.5. So I don't know if that would make a difference.

43

OK, in 2.0.4 it would have joined using SmartSense Multi Sensor V4, in 2.0.5 it would join using SmartThings Multipurpose Sensor V5, which is exactly what it did this morning when I joined it anew...
So, back to the confusion.

A) Was this device joined already when you upgraded to 2.0.5?
B) if not and you were running 2.0.5, what driver did it select when you joined it?

44

A) Not it was not joined. I had removed it and only joined it after the upgrade to 2.0.5.
B) It selected the "SmartSense Multi Sensor V4"

45

I can remove it and re-add it and see what happens. It is still sitting on my desk. Let me know if you want me to do that.

46

Of course, at this point since I already selected V5, it might re-join back to V5. But let me know what you want me to do to help.

47

This must be one of the ones with the newer firmware for which I don't have a complete fingerprint, so if you could join it again, then prior to moving off the discovery page, click the more button and copy me all the text in there then I can get it updated.

Thanks for the help on this.

1 Like
48

Re-joined. It put it back in V4 but we knew that already. Here is the "more..." info.

Manufacturer: Samjin

Product Name: SmartSense Multi Sensor V4

Model Number: multi

deviceTypeId: 125

manufacturer:Samjin
address64bit:286D970001042971
address16bit:86D4
model:multi
basicAttributesInitialized:true
application:11
endpoints.01.manufacturer:Samjin
endpoints.01.idAsInt:1
endpoints.01.inClusters:0000,0001,0003,0020,0402,0500,0B05,FC02
endpoints.01.endpointId:01
endpoints.01.profileId:0104
endpoints.01.application:11
endpoints.01.outClusters:0003,0019
endpoints.01.initialized:true
endpoints.01.model:multi
endpoints.01.stage:4

1 Like
49

yep, that was it, I've updated the fingerprint which will be in 2.0.6

50

Thanks Mike. In the mean time, maybe a reference to this thread or a comment in the release notes for 2.0.5 to make sure that people change it to the proper driver after join. :smile:

51

Mike, one more question. What would it take to make this sensor in Garage Mode be supported by Google Home? It was supported under ST. When I left the house, I was able to ask the assistant if the door was open. That was really nice.

Right now I'm getting this:

image
image.png1014×67 4.38 KB

52

We dont have any immediate plans to extend google home to include sensors.

53

Okay. Thanks Mike.

54

Hello, I had a heck of a time getting a V5 to work as a tilt sensor this morning. I am on the latest Hubitat FW... I think it is working now but it still may be a little dicey.

Could I get a summary of what I should have for it to work?

Is it:

  1. switch the device type to ST MultiPurpose V5
  2. Select Garage Door mode by setting XYZ to disabled and turning on "i want to use as a garage door sensor)
  3. Maybe turn off debugging?

Is that right?

55

@kv1 The steps are correct. #3 I had a problem when I was trying the V4 driver. The V5 driver didn't seem to be affected by having debug on.

56

Make sure you click configure after changing to the v5 driver, without doing that it likely will not work properly.

57

I have a v5 that was joined 3 updates ago and it shows acceleration. I joined one today on 2.1.120 and acceleration is gone and replaced with axis x,y,z. The previously joined unit still shows acceleration. Am I doing something wrong? I am trying to utilize these to monitor vibration from washer and dryer.

Edit: I removed and repaired, now working like the original.

58

I just got a box of these bad boys, and I'm experiencing a significant lack of sensitivity to acceleration. It takes a good jolt to make it show active, or update the XYZ. I have it set to Maximum. My older ST sensors would update as I rotated them on a desk in real-time. I could use them as a knob if I wanted. This is supposed to trigger as I sit in my chair, but it's worthless as things stand. Any suggestions?

59

Hi, Mike -

I'm having a problem with the Hubitat implementation of the "SmartThings Multipurpose Sensor V5" driver, specifically related to your comment quoted below that explains why xyz events are not sent when in "garage mode":

This unfortunately creates a serious conundrum with this device, because it now works differently on Hubitat than on SmartThings, making it near impossible to write a single "garage door opener" SmartApp that can run on both platforms.

FWIW, it works differently than older SmartThings multi-sensors on Hubitat as well, even though it will appear alongside them no matter what Capablities you use to select them (e.g., acceleration, threeAxis, contact, etc.).

Specifically:

  • As you noted, the Hubitat driver disables threeAxis reporting when configured for use on a garage door, even if the threeAxis reporting option is set to "Normal" or "Maximum"

    • SmartThings will continue to report the threeAxis attributes for any generation of its Multipurpose sensors, whether or not the device is configured for use on a Garage Door

  • Further, the Hubitat driver will still report that it supports the threeAxis attribute, even though they are never updated once the device is configured for Garage Door use.

  • Worse still, the Hubitat driver doesn't null out any existing threeAxis values that may be left behind by someone changing from threeAxis being enabled. In essence, the device is reporting that it supports an attribute that it will never update, but whose attribute value looks accurate (but isn't).

  • Once configured for use on a Garage Door, the Hubitat driver only updates the contact and acceleration attributes

    • Configured for a Garage Door, the SmartThings DTH will populate contact, acceleration, and threeAxis, plus a new status attribute that will be updated between garage-open and garage-closed, and contact will mirror open/closed accordingly

    • If you then turn off the Garage Door use, status will mirror contact

I understand that Hubitat doesn't have a mandate to mirror SmartThings 100%. In most cases where there are significant differences (e.g., Button devices), it is reasonable simple to code around the differences. But as a result of the above operational differences, there is no way to reliably determine which attributes are being served by the Hubitat driver in its current configuration - while I CAN tell that SmartThings is in Garage Mode by testing the status attribute.

Ideally (IMHO) they would work 100% identically, but even a few tweaks would make life writing code for both platforms immensely more practical:

  • Change the Hubitat driver such that the "Three Axis reporting options" selections are actually followed by the driver

    • if disabled, no reporting but set the threeAxis attribute to always be null (so that I know I'm not getting real values)

    • If "Normal" or "Maximum", always send threeAxis values, no matter what the Garage Door setting (so, if threeAxis has a value, it is always a real value)

  • Change the driver such that when "Garage Door" mode is enabled, the status attribute is updated with "garage-" plus the contact attribute value. I can then check if the Hubitat driver is in Garage Mode or not

    • Once status is populated, and then later if/when Garage Door is turned off, continue to update status with the contact value.

    • You could also choose to set Three Axis Reporting to "Disabled" when "Garage Mode" is enabled, BUT:

      • Be sure not to override a user's selection of "Normal" or "Maximum" for Three Axis reporting
      • Be sure to change the actual selection of Three Axis reporting to show "Disabled" (not just disable it silently in the background).

The above would be most graciously appreciated...

Thanks,
Barry

1 Like
60

FWIW, if I use the SmartThings Multipurpose Sensor V5 with the Hubitat "SmartSense Multi Sensor" driver, it behaves "close enough" to the SmartThings DTH - with both status AND threeAxis reports.

That's my work-around, but since that won't be the default driver that Hubitat selects for this device, it will still be a support issue. I think it would be better if my recommendations were implemented...

Oh, and ALL the Hubitat drivers need to null out threeAxis values if they aren't going to update that attribute (again, IMHO).