[RELEASE] Zooz ZSE41 OPEN CLOSE XS SENSOR Driver

⚙️ Custom Apps and Drivers
1

Zooz ZSE41 OPEN CLOSE XS SENSOR Driver
This is a driver for the Zooz ZSE41 OPEN CLOSE XS SENSOR. It differs from the in-box driver in that it exposes all of the device parameters, and supports settings associations.

NOTE: As these devices do not have many configurable parameters, most users should be fine with the in-box driver. But if you want access to all of it, this driver is for you.

Features:

  • All device parameters exposed
  • Can set Group 2 Associations

To-Do:

  • none

Installation:

  1. Install Driver code in Hubitat
  2. Apply to a Zooz OPEN CLOSE XS SENSOR. Click save.
  3. Edit preferences, save preferences.
  4. Wake device (press button 4 times) or wait for the next wake up interval for changes to take effect.

Driver can be found on my GitHub or (soon) on Hubitat Package Manager

  • 1.0.0 (08/16/2021) - First version
  • 1.0.1 (08/20/2021) - Fixed typo on closed event
  • 1.0.2 (08/21/2021) - Removed redundant battery report on wakeup
  • 1.1.0 (09/07/2021) - Added debug logging command and firmware version retrieval on parameter update
  • 1.1.1 (09/07/2021) - Added IndicatorReport handler to prevent errors
  • 1.1.2 (09/16/2021) - Fixed bug that would throw an error if LED parameter wasn't set in preferences.
  • 1.2.0 (09/21/2021) - Moved wakeup interval setting to the end of updates, and changed delay from 300 to 500ms to try and make updating the config more reliable.
  • 1.2.1 (09/22/2021) - Changed DebugLogging command to not have a blank field as 1st enum to fix rendering issues
8 Likes
2

Thanks for this!
Having direct associations for some doors and light switches is nice.

3

I understand the light switches but could you give an example use case for association of door sensors?

4

I understand the light switches but could you give an example use case for association of door sensors?

You can have a door sensor turn on a light directly without going through the hub.

5

Ah okay. I didn't realize you could have cross device association. I had only associated switches to one another. Thanks.

6

I'm not a fan of using associations at all. But if you had a simple case like you always wanted a closet light to be ON when the door is OPEN, that is something that could be done with associations making it independent of the hub.

Note that associations require the 2 devices to have direct communication with each other - the traffic does not route. So you usually can't associate something on one side of a house with something else on the other side (unless you have a small house I guess).

1 Like
7

Can you make it so your driver shows the firmware version in the device details section? That should be really useful, especially since these devices are considered beta.

8

One of my sensors just shows this in the log.

image
image1005×99 5.22 KB

I turned on debug logging so if it happens again I'll post that.

9

That's actually probably a driver issue. I probably didn't add that.

EDIT Actually I can't find any driver that supports BatteryHealthGet to use as a go by. Interesting that would show up in the logs.

I have no idea how a BatteryHealthGet would even happen... My driver uses v1 of the battery command class, which doesn't even support that command - and there is no batteryhealthget call anywhere in the driver.

Were you using a different driver when you got that message @waterboysh ?

10

New version posted

E.g.:
image

image

11

Nope, I was using your driver.

12

Dunno then. There is literally nothing that calls BatteryHealthGet in my driver. I believe you, I just can't explain it.

13

[dev:919](http://192.168.1.134/logs#dev919)2021-09-08 07:24:31.594 pm [warn](http://192.168.1.134/device/edit/919)Garage - Laundry Room Door received unhandled command: IndicatorReport(value:0, indicatorCount:3, indicatorValues:[[indicatorId:80, propertyId:3, value:0], [indicatorId:80, propertyId:4, value:0], [indicatorId:80, propertyId:5, value:0]])

Sorry, I didn't take a screenshot before I cleared the log. I just had debug logging on and not description logging, so I have no idea what this is, but it was another unhandled command. I'm using 1.10 of your driver now.

14

Ok, I'll take a look for that one next! thanks! I can certainly add in IndicatorReport. Not sure why it is sending one, but no worries!

16

Is there a way to force check the firmware version?

17

Click the save parameters button, then wake the device (or wait for the 12 hour scheduled wakeup).

Can be useful to turn on debug logging before doing a manual wakeup to see what messages came in.

18

New version

  • 1.1.1 (09/07/2021) - Added IndicatorReport handler to prevent errors - doesn't do anything other than suppress the error
19

I've done both. It's been a few days now and I still don't see the extra information. The only one that it shows for is the one I flashed with the new firmware that went haywire, presumably because I re-included it to the hub during the process.

20

Out of my 20 devices, 18 of 20 retrrieved the version data correctly - but like yours, a few (2) have not, and I've tried many times. Don't know why... Same driver, same paiting security, same mesh. Weird.

I know the version report is being asked for, just don't know why it isn't making it back to the hub.

EDIT: Never mind. I saved preferences, brought the 2 not getting version reports closer to the hub, manually woke them - and they both got the version report (as confirmed in the logs).

21

Oh, I think the problem is that I misread your initial answer as 1) save preferences and manually wake up the device, or 2) wait 12 hours for the device to wake up on it's own.

So I misread it as (A AND B) OR C when really it sounds like it's C AND (A OR B). I'll try it out later.