Zooz ZSE40 4-in-1 Sensor

[jchin]

I would suggest contact Vera support.
Maybe there is something wrong and when they remote in, they can fix it in the settings (that are hidden from the web interface).
Just a guess because mine worked after contacting them, resetting the device and doing my steps (post above). 

[XA44Owq26HxCq88]

Spent an hour on the phone with Vera. The tech couldn't figure it out. Suggested that I wait for the Official Integration, but couldn't tell me when that might happen. The tech from ZOOZ blamed the problem on Vera. So,,, it's going back. I love a problem as much as the next person, but when it gets to the manufacturer blaming Vera and Vera not being able to get the unit to work properly, it's time to jump ship. Back to Amazon it goes. I'll try the Aeotec Multisensor 6

[XA44Owq26HxCq88]

Just an update, heard from the tech at ZOOZ. (They have been very responsive to my issues BTW.)
They've tested a new unit and found it to be operating correctly. They have sent it to me. I'll keep everyone posted about what happens.

[rafale77]

I am ready to bet that part of the problem is that they tested it on a vera with very few device and that your problem is because you have a real life system with more than 1 zwave device. The vera then goes nuts and somehow can't keep up with the signals from the sensors. It is very likely a vera problem.

I am increasingly observing signal misses with the latest beta firmware... The sensors don't always untrip as expected and they occasionally trip for no reason.

[XA44Owq26HxCq88]

rafale77 -
So you think that VeraPlus is unable to handle multiple zwave devices? Or is it a combination of this specific device and a reasonable setup? Or large numbers of sensors. I've got about 30 actual hardware devices and a few virtual devices (Weather underground, etc). Some of the hardware devices have "child" devices. My vera devices number designations are now at 104, but a lot of the number designations no longer exist (removed devices, etc. This attempt to add this unit multiple times added about 20 designations alone.)

Got the new "tested" unit today. Will report on my success (hopefully) or failure.

[rafale77]

@XA44Owq26HxCq88

Wish you good luck with the sensor. I am very afraid though that it is indeed the number of device which plays a major factor. As you can see in my sig, I have 130 zwave nodes on my Vera Plus. At 50 I started having problems and as the system grows reliability just get worse and worse. These same sensors I had no problem pairing 2 years ago now are a royal pain. I spent many hours testing and a few more with CS on the phone trying to resolve this. At the end I managed to add back this 4 in 1 sensor to my system apparently out of sheer luck and after 50 tries... My device number is out in the 600s. Based on how fast it exchanged security keys on the one time I was successful, I concluded that the vera is just too slow during the pairing process and missed the key.
I later installed the beta 26 firmware with the new 6.x zwave SDK which is supposed to improve handling of large systems. These days, I am getting a rash (at least once a day) of missed untrip signals, false positive trip signals from security class devices. All other devices seem to work ok except for a single event of complete freeze of the zwave interface a few days ago. I just keep sensing that the vera can't keep up with the two (zwave and zigbee) radios on my "large" system. I am also geting occasional "device offline" "Can't detect" messages due to the vera missing the polling response from the device. I am well on my way to obsoleting it now which I will do gradually...

[XA44Owq26HxCq88]

An update on my progress -

Got the unit installed, physically next to the old unit, so I can compare the two (there's a third motion detector nearby that I use as a base line for motion)

Surprisingly, it installed into Vera while in it's ultimate position, not within 10 feet of the VeraPlus unit as I would normally do. I did this as an experiment, just to see. So, despite being 2 zwave units (links) away in the mesh, Vera recognized and installed it as a generic Zwave unit. I went through the (elsewhere in this discussion chain) described changes in the file, xml, json files, corrected the type numbers (4&3) and the VariablesSet values.

It changed to a motion detector and responded correctly. BUT, I had no "child" units (temp, humid, lux). There was a warning label on the device stating that it could not determine the manufacturer. (the manufacture variable was blank)

I let it sit overnight and in the morning the child units appeared. Don't know when. Also, the  manufacturer variable was now filled.

It reported motion, temp, etc. The old unit also reported motion, temp, etc. Tracking both units over the day, the old unit stopped reporting for about 5 hours, and then began reporting again. The new unit continued reporting each time I checked.

This morning, both units are reporting. When I say reporting, I mean that their temp, etc. values have changed from the previous reporting. I don't know about the accuracy of those reports, just that they had changed in the interval. The temps are different from one another even though they are next to one another. Sometimes by as much as 6 degrees, sometimes within a degree.

They do seem to trigger motion detection more frequently than the base line unit, not sure why that is, but I can work with that, maybe adjust the sensitivity.

And, BTW, both are displaying a warning notice "Waiting for wakeup to configure device..."

Does anyone know how I could log the temperatures to a file over time, without having to access the system and write down the numbers? I'd be able to monitor the units performance over time with a much more granular data set.

I am hopeful....

[rafale77]

This is kind of a funny thought but when I think about it, the one time I succesfully re-included my device, I was the furthest away from the vera. It is possible that the several hops actually added latency to the zwave network and allowed more time for the vera to be ready to accept the security key...

You could push the wake button with a pin again to see if it gets rid of the "waiting for device to wakeup to configure".  This generally is because the vera did not receive a response from its poll. Also likely because the vera is too slow/busy and missed the response the zwave chip transmitted.

There is a number of solutions to logging your variables. emoncm, datayours, ALTUI timeline etc...

[XA44Owq26HxCq88]

rafale77, thanks for the tip about the data logging. I'll look into that option. The warning notice under the device appears to not impact the unit, at least once it's set up, so I'm going to ignore it for now.

New Unit still reporting updates. The old one is stuck since 7 this morning. I'm getting the box ready for it to be returned on Monday.

[rafale77]

New discovery on this sensor and the vision ZP3111 which is the OEM:
Whenever the sensor sends a signal that the battery level has changed, the vera trips the device and causes a false alarm. Since the zwave sensor itself never tripper, it also never untrips unless one goes and really trips the sensor and causes it to then send an untrip signal. This is a vera bug...

[jchin]

New discovery on this sensor and the vision ZP3111 which is the OEM:
Whenever the sensor sends a signal that the battery level has changed, the vera trips the device and causes a false alarm. Since the zwave sensor itself never tripper, it also never untrips unless one goes and really trips the sensor and causes it to then send an untrip signal. This is a vera bug...

That explains why my sensors are showing tripped for no reason at all ... well now I have to see if the battery level changed.

[rafale77]

I would remove the ZP3111-5 from the list of compatible devices at least for the Vera Plus.

I have a dozen of them and have run some tests on the behavior of this device. Please do not ask me to contact CC. I already have and they were totally helpless and I have spent countless hours on the phone and through emails. There is a combination of newer firmware updates issues with handling of the secure class devices being broken and the fact that I have a large network.

1. I am experiencing inconsistant miss of tripped/untripped signals from all of my motion sensors but the Vision ZP3111-5 seems to be a little worse
2. I am seeing ghost trips from a number of them which I correlated to a status update to the battery level.
3. Once the sensor goes out of battery, It will show as not detected as one would expect. If the battery is replaced, the vera will miss the wake event from the sensor 80% of the time. I would have to go through a number of forced wake before it sees it but then the sensor would not be functional: It will detect motion but it seems like the vera will miss the secure signal. No attempt to reconfigure the device will work. I suspect this is due to the secure key exchange below and somewhat related to the disaster Tillsy has seen with the secure device handling.
4. With the latest firmware on the vera plus, as I have reported it a number of times now, adding a new one of these device will generally fail at the secure key exchange step. About 1 of 20 attempts succeeds. It appears that the sensor is too fast an attempts to exchange secure keys during the pairing process but the vera is too slow to receive and respond. It will therefore switch to a non secure pairing. By the time the vera is ready to exchange the secure keys the sensor has already switched mode. The result is a sensor which works but has the vera showing a message that it is waiting for the secure key and permanently shown as failed.
5. Thinking that I have lost secure class keys I decided to attempt recovery from backups. Ohh what a surprise to discover that on 7.0.26, each nightly heal causes changes to the network which prevents full recovery from backups. When I recover from a backup from one nightly heal prior a large number of my devices would no longer work. This include simple on/off switches. I always need to recover from the latest backup.

So at the end I am left with 6 devices showing as unable to detect by the vera although they work and 2 devices which do not work in spite of not showing any issues. All of these problems happened once they ran out of battery and I had to change the battery on them. The ones which show as having an error, I attempted to either reconfigure or pair/unpair. The ones which do not show an error but do not work, I only changed the battery and forced them to wake numerous times.

I also have Aeon 4-1 sensors and though they have been working decently for a number of years, upon one of the spontaneous luup reloads, one of them started forcing the creation of a smoke sensor child device which I could not delete until I reconfigured the sensor.

Overall the vera is a disaster for secure class devices.

[ec.auction]

I have similar issue with this 4-1in-1 Sensor and Schlage boltlock that will not pair with veraplus.
I am in the process of downgrading back to VeraLite that seems to be more stable.

by the way, both sensor and lock are ok with SmartThings hub.

[rge]

I have similar issues - mine is a "Cyrus" 4-in-1 but it looks identical and is recognised as the Vision 4-in-1 sensor.

I've had one installed for 2 years with no problems, so I conclude MCV messed up something in the integration during one of their "upgrades". My setup is small - 10 or so real devices, 30 including all the virtual ones.

I notice in dataMine that the older sensor has multiple items under urn:micasaverde-com:serviceId:SecuritySensor1, including the necessary Tripped value. The new one doesn't have anything useful, just "Armed".

I even tried hacking the user_data.json to make the config for the new device the same as the old one - which added the services (according to dataMine), but they still didn't respond.

The device support in Vera has always been pretty random, in hindsight had I known I would have bought a more stable alternative, but to actually break existing comptaibility is just a joke.

[rafale77]

Been playing with a dual zwave controller setup and finally got it to work. I extracted the secure key from the vera and copied it over to openzwave with a HUBZBZ and then ported the setup to homeassistant. Included the sensor into my network securely with homeassistant which is my SUC/SIS primary (vera has become the secondary) and then did a get network info from SUC/SIS and and luup reload. Forced a configuration of the device and it is now all working! The vera reconfigured the device and flushed all the association and made it all report to itself. The inclusion process for this sensor is broken at the secure class key exchange...