Just received this device and started working on including it. I had similar problems as others. I did follow the Zooz instructions, How to Add Your ZSE40 4-in-1 Sensor to Vera - Zooz Support Center and this did fix the motion sensor appearing correctly in Vera.
Doing a little digging, it seems I needed to be on the latest firmware. Updated that, excluded/includes the device, and it all seems to work fairly well.
I am updating some of the parameters so it performs to my liking and thus far, I am having issues with 2 of them. I’ll just keep reading the manual and playing. Glad to see Vera had incorporated this device.
It appears the parameter 4 range when Vera set up the device did not match the manual. The attached screen shot matches the manual and is working.
I am still having problems with parameter 5. I have left it the default 15 seconds for motion reset but 255 and 180 do not work. The manual does not give any guidance.
If you get to this, I would really appreciate if you could get this to the devs:
Out of curiosity, I went and checked whether my ZP3111-5/Zooz ZSE40 were included in secure mode. I have 14 of these and found out that all the devices I have included after 7.0.20 don’t have the security key set. This means that very likely a bug was introduced after 7.0.20. The device broadcasts itself as supporting secure class but the vera has been failing. Having added it to the list of officially supported devices has actually made it worse. I suspect that every one who has these and included them recently, have somehow made the vera accept to include them insecurely.
My request would be for advanced users to have in the generic device inclusion the ability to choose whether to include the device securely or not. I also noticed than my vision ZP3102-5 were also included without security even through it supports secure class. As I reported 2 years ago, I have spent significant amount of time on the phone with a ticket open and never found a solution other than sheer luck. I now know that luck was that somehow, with the right timing with the luup reload, the device info would fall back to non secure inclusion. This remains a problem with the latest beta firmwares as well.
Hi Rafale, pre-7.29 Beta Vera did not have the capability of including devices un-secure. All the devices were included secure by default, but depending on what pairing procedure you’ve been using on the device itself it can take it as secure or not. Some devices have specific pairing procedures for secure mode and unsecure mode. As far as I know, the Zooz device should have this type of inclusion.
in regards to the Vision device, looking at this manual, I can’t see the COMMAND_CLASS_SECURITY command class in the list, even tho it’s a GEN5 device: https://www.vesternet.com/mwdownloads/download/link/id/882/ This can be confirmed with the manufacturer.
But for the Zooz, I can see COMMAND_CLASS_SECURITY in it’s specs and if you include it in secure mode per manufacturer manual Vera will pick it up accordingly.
Also, if a device broadcasts itself as supporting secure class it doesn’t mean it will use it for all supported command classes. This can be clarified with the manufacturer I guess.
@Sorin , I have a mix of both the 1st Gen Zooz ZSE040 and the vision ZP3111-5 which as far as I can tell are completely identical down to the supported command classes. I, at some point before 7.0.20 have managed to include all of them in secure mode and the inclusion was fairly painless. When I look at the device info in my user-data.json, they all support this secure class. It is at some point, likely at 7.0.21 on the vera plus that all the issues started happening.
I had to exclude and re-include one of them and discovered that it would fail to exchange secure class keys. You can see from a number of users that locks also became more difficult to include.
Early on I could downgrade firmware and managed to re-include it that way but I have not tried doing this again. Since that time, all the included devices I have had to be in non secure manner. All my older devices still are showing the secure class key, both Vision and Zooz branded. The main difference I can see is that back then they were not officially supported and I had to configure them manually. I can verify it under ALTUI and using my secondary controller under both openZwave and the Sil Labs PC controller that they are indeed securely included. It seems like the official support of the device actually broke the inclusion process for these?
@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.
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.
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.
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.
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!
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.
