Zooz ZSE40 4-in-1 Sensor

@rafale77 The Zooz ZSE40 has only one inclusion type and that’s always secure. However, given that we’ve received some feedback from Vera users about the inclusion/exclusion process, we’re working on a firmware update that will offer a choice to include the sensor in a secure or un-secure mode. We should get that update available within a couple of weeks but it will only be available for the current production model so VER. 2.0.

Hi @Agnes.Zooz,

Thank you for your feedback. I unfortunately have a great number of gen1 of these sensors. I am not a fan of the CR123 of the gen2 by the way as I prefer to use AAA rechargeable batteries instead of more expensive and less environmentally friendly lithium. My AAA last about a year which is acceptable.

On the gen1, I have a number of them which got included non securely. They were extremely painful to include as they ended in vera failure to exchange secure key 99% of the time and eventually would include non securely by accident. This far, the only workaround I have found has been to include the device with home assistant and then configure it with the vera.

Thanks for sharing the workaround. We’ll look into developing a special OTA file for VER. 1.0 then. If you can get in touch with the support team here and request it once ready, we’ll keep you posted on the progress.

Unfortunately, most users reported battery life closer to 6 months on the 2 AAA batteries so we needed to switch to lithium which nearly doubled battery life for average use. It’s great to hear you’re getting a year out of rechargeables.

1 Like

Just my engineer head at work: The lithium batteries advantage is the ability to deliver and sustain high current while maintaining a low discharge rate. Recent NiMH now also have very low discharge rates, much lower than alkaline. In spite of lower capacity, these batteries can actually last longer than the best alkaline due to the low current draw of these sensors. It is really a waste to use Lithium batteries for such a low current draw. Sure they will last longer than Alkaline but they should be working 5-10x longer, not 2x to be worth the trouble and the cost… My motorized shades for example use Lithium because their draw is high and realize a 7x improvement in battery life.

Anyway, thank you for following up. An OTA upgrade for the ver. 1.0 would be great. I will open a ticket with your support team.

That being said I still would prefer to be able to include these sensors securely which I used to be able to but something broke apparently in the vera firmware.

1 Like

Thanks for sharing your feedback on the batteries, I’ll pass it on to the engineering team!

We’ll also continue to work with Vera closely to resolve this issue so the sensors can join securely without so much hassle.

Well I have an update: The problem was not related to the vera firmware but to the size of my network. I just tested the inclusion process on a test vera plus with 0 devices and the latest beta firmware and sure enough it exchanged the security key without any problem. @Agnes.Zooz, considering this result, I believe that it is purely a matter of timing. I think that with a large network, the vera is not queuing zwave commands like it should and potentially could either drop the secure class exchange command or delay it significantly to the point where the sensor has already timed out. If it would be possible to extend the time out during which the zse40 sensor accepts to exchange key during the inclusion process, I would happily test it. This would also explain the luck factor where I occasionally managed to get it included properly.

@rafale77 I’ve found that rebooting Vera just before including a new device typically works around inclusion/exclusion problems (a simple LUUP reload does not). I know this is a bit drastic but have you tried including the ZooZ on your large network immediately after a clean reboot?

No I haven’t and I could try though it would be a nasty way to do it…

Edit: No this does no help. The luup reload helps if the configuration gets stuck after the secure key exchange but the full reboot does not help the key exchange itself. I have tested another controller: the Sil Labs PC controller on the same network and it has no problem including and exchanging the secure key in less than 5s so it is definitely a vera specific problem with its problematic command queuing which has caused complains about lag in response and now inclusion issues on larger networks. I have been raising this issue for quite some time now and hope the dev will do something about it. The serial zwave command priority and queuing needs a lot of work…

Thank you for the update and your thorough examination of the problem. We will try to work with Vera to get this resolved in the long term. We wouldn’t like to give up on security, especially for a security sensor like this one.

I have now been successful including 3 x Gen1 sensors by using a secondary controller on openZwave after extracting the security key from the vera and reinserting it into openZwave. After the secure class inclusion, I was able to configure the device on the vera. These three sensors never included securely on the vera: 2 by pure chance somehow included in non secure manner, the last one consistently failed like the other 2 at the secure key exchange step. It is pretty sad to see the amount of workaround I had to go through in order to make this sensor work.

1 Like

Agreed, it should be much simpler, especially that the sensor is now officially certified with Vera. We’ll prioritize this issue both internally and with our colleagues at Vera. Thank you again for sharing your solution!

Thank you! Looking forward to the outcome. I have been facing this problem for years. Your support convinced me to also get a ZST10. :grin:

1 Like

So I had one of my sensors run out of battery today and I suspect my network went through one of these nasty nightly heal last night and as I found out that the battery was too low, the device got listed by the zwave chip as failed. As a result the vera shows it as “can’t detect” every few minutes (once it was 1 min after I woke it up so I go notifications that it was responding again and could not be reached within 1min when I am expecting the device to wake up once an hour) so the vera indeed checks the failed device list from the zwave chip and tags them accordingly.
I fixed it by: running a manual configuration which fails 9 times out of 10 because of the secure class key exchange timing out. Let it fail. (this takes the device out of the zwave failed device list on the zwave chip)
And then restore from a backup from 10 min earlier (this restores the configuration stored on the vera UI itself) so that the device still has its old configuration, is out of the zwave chip failed device list and the vera has all the child devices configured correctly as they were.

Now I have no idea why this happens only with this type of devices. I would really like vera to send a command to the zwave chip to remove a device which has just responded/woken up from the zwave chip failed device list. Right now it requires a device reconfiguration which is painful and tedious because of the child device deletion/recreation process of the configuration and is often failing because of the secure class key exchange timing out on a large network.

@Sorin please help on this. @Agnes.Zooz said Zooz team is working with you guys. This is a design flaw of zwave/vera with a combination of issues making user experience dreadful. I have complained about this also on a ticket to CS years ago.

1 Like

Deeper log study got me to the bottom of issues with these devices.
2 issues:

  1. The failure to include in secure mode at the secure class key exchange on a large network.
    This is caused by the zwave network being too busy and can be remedied by:
    a. eliminating nightly heal coming soon on 7.30
    b. eliminating wakeup heal (wakeup neighbor node update) coming soon on fw 7.30
    c. eliminating wakeup poll for these devices which do not need them (this sensor doesn’t)
    this is not available on the vera and causes the vera to send a polling frame when you poke the wake button which interferes with its own configuration process. This is not available and not tested yet but my reading of the logs indicate that it can still be occasionally a problem. The current workaround is to make the network less busy by extending the wakeup interval. I have set mine to 3 hours. Vera’s default is 30mins.

  2. Ghost tripping: I got to the bottom of this as well. It is caused by failed wakeup polling processes again caused by unnecessary wakeup polling which somehow the vera interprets sometimes as a trip alarm. This device updates its child devices’ status without polling and will require elimination of wakeup polls to fully eliminate. The current workaround I have is the same as 1… reduce busyness of the zwave network.

@edward… if you are reading this…

I have this device in my master bathroom. It worked great until Saturday night, when ghost trips kept turning on the bath fan, after the 1 minute time out would go back off. Repeat in about 7 minutes. After hearing that about 4 times, I disabled the PLEG device that controlled that room until morning.

Sunday morning, I noticed the battery was now at 1% - it was 100% for the last 5 months. Replaced the battery and all is well last night.

I do not know if the battery reporting is a device issue, a Vera issue, or a combination of the 2. I am on a Vera 3, latest firmware.

failed wakeup polling occur more frequently when your batteries are low… so I am not too surprised. Yet it is the polling which opens the possibility of tripping. This device does not need polling… The vera just polls every time the device wakes up. You could extend the interval between wakeup as a short term workaround but… again and again… it should just not be polling and draining the batteries prematurely.

I ended up setting the polling of all of my battery devices to 0 (never poll). Hopefully I see improved life, but proper battery reporting would be nice.

It won’t help. That’s because the vera runs a wakeup polling function every time the device wakes up regardless of what you do to it. It is embedded in the firmware.

Thanks for information. Would it help if I set the wakeup internal to 0 or blank in the UI? It does not sound like it will.

Never thought about setting the wakeup interval to 0… I am not sure what it will do.