@agnes.zooz When did this become available? That's a pretty good price too. I've been looking at some open/close sensors recently too, so I think I will pick a couple of these up.
1 Like
Actually, I just realized it uses a CR2032 button battery. I'm sure that makes it smaller, but if I have to replace the battery every few months it's not worth it to me. Maybe Agnes can share some information about expected battery life.
I just received one of these. It paired as a 'Device' but I do not get any open/close messages in the logs after I changed the type to Generic Z-Wave Plus Contact Sensor. I then tried the Generic Z-Wave Contact Sensor and also got nothing.
@agnes.zooz is there a Hubitat driver code yet for these? I searched for ZSE41 on the Zooz Support KB and found nothing.
It was just released and announced. We also released a leak sensor recently and will be releasing another new product in the coming days at which point we'll send a newsletter to everyone 
We expect around 12 months depending on how many reports a day it sends, if the LED indicator is enabled and if it needs to communicate through repeaters.
Hubitat received a sample and we hope it will be added in one of the upcoming platform releases. For now, we don't have a customer drive or a workaround for it but I'll let you know if that changes.
Looking forward to this hitting HomeTechSolutions in Canada so I can grab a few. Looks like a great product and a good price point.
1 Like
I look forward to it. It's good to see Zooz expanding the types of devices they make because the quality and customer service is good.
Hopefully a 700 series 4-in-1 sensor is in the works and coming soon
2 Likes
You know it 
We plan to release the 700 series version in September.
2 Likes
Does this report other than open/close? ie: temp? or other
Just open/close. It's a series of small simple sensors that currently includes the open/close and water leak sensor. We'll be adding a tilt/shock sensor and a temperature/humidity sensor later this year 
5 Likes
Just got my ZSE41 open/close sensor and it appears to be sending battery reports to the hub about every 7 seconds (this is with a driver I'm currently working on since none are built-in, though I imagine one of the generic drivers would get you pretty close aside from the sole configuration parameter--but I can't imagine the driver could have done anything to cause this since it appears to just be an unsolicited report from the device). I assume this isn't normal? 
Also, FWIW, I had a heck of a time getting it paired to my C-7. I had to try three or so times, with the first two attempts failing with an S2 bootstrapping error (I might have been to slow to input the DSK the first time). I never tried it without security to see if that was better, but I prefer to use it with if the device supports S2. Could also be the C-7 and not the sensor, of course....or just my bad luck!
My leak and contact sensors arrive today, so I'll see what I see. I force the wakeup interval to 12 hours in my drivers, so I expect that reporting shouldn't be an issue unless there is a firmware problem.
I'll say, though, with as many problems as I've had with S2 (device firmware issues on GE and other brands, not hub issues) I haven't decided whether I will use them S2 or not long term. I'm getting a bit soured on S2 - again because of DEVICE firmware issues, not hub. Vendors simply don't seem to be testing S2 as well as they should, and a device can pass through certification even if it has intermittent issues with S2...
That said, as I made user drivers for this and the leak sensor, I'll pair it at least once w/S2 to verify the drivers work as expected before I publish the drivers this weekend. The only thing I have left to test is how the "low battery alert" comes in - it isn't well documented.
EDIT: Another thought @bertabcd1234 have you tried adjust param 3 to something larger to see if it would stop reporting as much? Shouldn't have to do that, but just thinking out loud.
1 Like
Wait, this exists? I can only find 1, 4, and 5 documented in their PDF. I'm guessing they have an "advanced" somewhere that lists the command classes and versions it supports and maybe all parameters? At least I think that's how the normally roll. Just can't find it for this one...
Also, it occurred to me that maybe I didn't send a wakeUpNoMoreInformation to it after initial pairing/configuration, though I'm assuming it should eventually go back to sleep on its own and not cause it to send these reports every few seconds even if it was awake...
Turn on debug logging and open/close the sensor and send the logs to me so I can verify the notifcation messages used, and I'll send you the beta version of my driver that should take care of all that (except for the low battery alert that I need to test, as mentioned).
EDIT: Oh, and to actually answer your question:
https://products.z-wavealliance.org/products/4276/configs
Eventually it "should" go back to sleep on its own. Definitely not optimal to wait for the timeout. But you're right, it "should" work without that.
I've seen that before. There is a command (can't remember if its in the device driver or in the basic z-wave tool) that will report all the parameters that I usually run to find any undocumented parameters. It is a pain sometimes with the sleepy devices. You would have to force a wakeup to get the results.
The Basic Z-Wave Tool can sort of do that, though it just iterates over all possible parameter numbers to see what it can find, as far as I can tell. It's also of no help to figure out what they really do, which was my concern with this otherwise undocumented one. But the link that @JasonJoel provided from the Alliance answered that question (thanks!).
Also, I don't have it handy right now because I'm having trouble getting it re-paired (did I mention it was a pain? ), but I observed that it sends both a SensorBinaryReport and a NotificationReport on open/close events. I went with the NotificationReport in my driver since it usually came in a few milliseconds sooner, but I assume either should work unless they change this with a firmware update (like they apparently did with the Q sensor before production).
They should both work. Using the notification is the "right" way to do it though. Have you tried reversing the output indication (param 5) and see if the binary and notification messages still match? They should, but multiple vendors have missed that when adding output reversing.
Oh, and if you are going to make your driver public, just let me know. I was going to publish mine, but really I don't care either way - and we don't likely need multiple of them floating around. Once 2.2.9 comes out and there is an in-box driver I doubt anyone will use anything but that anyway (unless they want to use associations for some reason I guess).
If i ever get this re-paired (ha), I'll try the reverse option and see what reports for both. I thought I remembered NotificationReport being the "preferred" method...
I might post my driver on my GitHub (for myself if nothing else) but probably won't post about it here, so feel free to do as you want with yours. I'm guessing most people will use the built-in driver too once it becomes available, but I'm starting to like having my own for a lot of devices, too (except for really simple devices like this--it doesn't report temperature or anything else--I'm not sure my effort would have been worth it if something already existed).
I get that.
