Smartthings Multipurpose Sensor 2018 Model

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.

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

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

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

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:

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:

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

Okay. Thanks Mike.

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?

@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.

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

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.

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?

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

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).

null is not a valid attribute value, for any attribute, doing this will cause problems for apps that don't explicitly check for null attribute values. If a device advertises a given capability it is responsible tor maintaining a "real" value for that attribute.

we do not encourage this, there are enough subtle differences between many of the platform calls already, the last thing any decent app should have in it are methods trying to determine who's platform its running on...

This also is not a valid attribute value, this will break all the built in and user apps using contact sensors.

Sorry to be a bummer on this...

Sorry to push back on this, but I respectfully disagree with your position on all three points:

Granted, null should never be delivered as an evt.value. but it is a valid result for ANY attribute, and is returned across the board for a "device.currentValue('foo') "request, on both SmartThings and Hubitat, when the requested attribute's value is unknown. Your current drivers return an equally invalid value to a "device.currentValue('threeAxis') request by sending data that is no longer current.

And FWIW, anyone who requests a device.currentValue() and doesn't check that it is valid before using the result, probably shouldn't be programming using Groovy in an event-driven world - on EITHER platform.

While you can encourage/discourage whatever you like, it is unreasonable for you to reject an enhancement request because it might make it easier for third-party software developers to write and maintain code for both platforms. I personally maintain well over 25,000 lines of code across 5 device drivers and 14 applications that run unmodified on both Hubitat and SmartThings. While you might not like it that I have done this, preventing me from doing so would make it near impossible to support all of my creations on both platforms - for no good reason other than you don't think I write "decent apps".

(FWIW, I use a lightweight mechanism to determine the platform once at runtime, and then simply check state variables whenever I need to handle any differences between platforms).

Actually, I'll ask you to reconsider, since you already support status in at the Hubitat "SmartSense Multi Sensor" driver. And it won't break any existing apps that use the contact attribute, as it only adds a shadow status attribute that includes the word "garage-" in front of the contact.value.

1 Like

So, to simplify my request:

  1. Don't stop updating threeAxis values when Garage Mode is selected (as do all of the SmartThings drivers) or at least allow a configuration option that updates both Tilt-contact AND threeAxis values (as do all of the OTHER Hubitat drivers).

  2. Add the status attribute mirroring the contact attribute values if NOT in Garage Mode, and providing garage-open/garage-close when Garage Mode is enabled (just as you do already for the SmartSense Muiti Sensor driver that you provide)

1 Like

Also, @mike.maxwell FWIW, your "SmartSense Multi V1" driver sets the threeAxis values to threeAxis : [x:0,y:0,z:0] when you select `"Yes (xyz events off)".

All I'm asking is for consistency of the proper superset of attributes across all the Hubitat drivers for the various generations of the SmartSense/SmartThings multi-sensors.

  • Garage Mode adds status attribute,
    • values garage-open and garage-closed while in garage mode; open and closed if garage mode is later disabled.
  • Option to keep xyz events ON while in garage mode (and an option for OFF if not)
  • threeAxis values set to [x:0,y:0,z:0] when xyz events are disabled

How's that for a decent compromise? Consistency is what matters most....

3 Likes

i found somethings strange about the driver for this and the newer v4 model. turning off xyz reporting also seems to disable general door open/closed reporting.. they should be separate.