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