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).
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
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.
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.
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.
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…
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…
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…
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.
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…
[quote=“rafale77, post:70, topic:192570”]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…[/quote]
That explains why my sensors are showing tripped for no reason at all … well now I have to see if the battery level changed.
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.
- 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
- I am seeing ghost trips from a number of them which I correlated to a status update to the battery level.
- 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.
- 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.
- 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.
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.
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.
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…
Thanks for the info - I’m not sure about your last statement, are you saying the device has a buggy key exchange implementation or Vera does?
Sounds like Home Assistant is better than Vera, at least on this device, what is your overall experience? Why keep the Vera as well?
[quote=“rge, post:76, topic:192570”]Thanks for the info - I’m not sure about your last statement, are you saying the device has a buggy key exchange implementation or Vera does?
Sounds like Home Assistant is better than Vera, at least on this device, what is your overall experience? Why keep the Vera as well?[/quote]
It is very clearly a vera issue and it isn’t the only device which has been finicky with the vera. I still have all of my automation on openLuup and use the vera only as a device bridge. The Verabridge and familiarity with openLuup is the main reason I am keeping it for now although adding homeassistant is a first move towards migration. The positive is that I learned probably more about zwave network and openwrt than I would ever have had it not have any problems…
About Homeassistant, I am still learning about it. It definitely takes a lot more work to setup and the device support is still under development. I had to rebuild the openzwave portion and move it to 1.5 in order to make it support my locks and garage doors. It tries to cover so much that it is actually very slow evolving for any single topic. I found it better suited to be an API bridge for now.
I gave up on Vera, now I’m migrating to HomeSeer, currently running a trial with it on a Raspberry Pi with RaZberry card.
Seems really solid, fully supports all the (small number of) devices I have - it quite happily handles both of the 4-in-1 sensors and doesn’t need a hack for the Fibaro dual switches.
The biggest out-of-the-box lack is dataMine - there’s a history plugin but it’s not great. However, there’s easy instructions on the forums for logging to Influx and using Grafana which is are incredibly flexible and powerful and happily run on the Pi as well.
The UI is basically about as bad as UI7 - it’s ten years out-of-date, but at least it doesn’t have 50%+ whitespace… ahe standard HSTouch phone app is shocking, but then the free HSBuddy is perfect.
And it has zero connectivity to any external site if you don’t want/need it, unlike the annoying Vera login requirements for some pages.
Some observation on these sensors.
As previously reported, they are as painful as can be to configure on the vera plus as the secure key exchange and the overal communication takes a lot of trials to execute in big part because of the vera somehow missing communications back from the sensor during the inclusion and configuration process, I suspect because it is too busy trying to do deal with the additional 3 sensors and saving them to the user-data.json. Since mine is fairly big with over 100 devices, and the luup reloads are out of control, it tends to get corrupted.
-
There is a trick to not restart a new inclusion or configuration process when one fails. Instead repeatedly cycling between waking the sensor and forcing a luup reload eventually finishes the configuration. It can take up to 20 cycles. I generally got there in 5 or 6. I first securely include the device in my zwave network with home assistant to be sure it is properly included with a secure key as the vera switches between secure and non secure inclusion without user?s knowledge. (I had a couple included non-securely)
-
I had a couple of devices having ghost intermittent presence detections. After my last reinclusion, they all disappeared. I am left with only which I have never reincluded. I am no longer suspecting the previous devices to be defective. Instead it is some data corruption on the vera misunderstanding a battery level change or some other wake event from the sensor for a motion event. The proof is that the exact same sensor which had issues before, no longer have any on the same network and same vera. It reminds me that I retired a couple of older vision 2 in 1 sensors some years ago having the same problem suspecting that they were defective and they may just have been corrupted vera database or zwave chip data.
-
The vera auto configuration fails in absurd ways repeatedly trying to create child devices, which, having no name automatically get deleted on the next luup reloads which is triggered by who knows what and creating new ones and repeating the cycle again, running up device numbers all with inexplicable and unneeded automatic luup reloads in between which I am certain are eventually causing data corruption on the entire system. ALTUI is very helpful in that respect allowing you to name the devices in between luup reloads to prevent them from getting deleted and break the cycle.
-
Another problem I reported in another thread is the device showing up as ?cannot detected?. I have investigated and concluded that the device must be somehow tagged by the zwave radio chip as bad as part of its list and the vera just reports this info. I have observed the tag to come back every 9-10min as I used a command on the vera to untag it from the UI when the wake up interval is 30min and the polling frequency is an hour. It made no sense to me. All 4 functions of the sensor yet still work perfectly. It just keeps coming back as ?cannot detect?. Eventually I was forced to unpair and re-add (painfully) the device to the network. This same device has now been working perfectly for over a month. This was started after the device ran out of battery…
Another one ran out of battery today and I had the same problem after changing out the battery: Sensor works perfectly but kept coming back every 5-10min as “can’t detect device” and roughly 2hrs after a luup reload or a device wake up. I had to come back to this thread and now I can definitely confirm that the data saying the device has a problem is from the zwave dongle chip. I started a reconfiguration of the device which somehow succeeded immediately and then recovered from a 5min old backup which preceded this reconfiguration to avoid having reconfigure and play with the child devices. The user-data.json being the same (I checked all the device parameters and variables) the device stopped showing as “can’t detect”. If it is not the user data on the vera or the device configuration, since it remained the same, it has to come from the zwave chip… My other controller (home assistant) does not have this problem. This is a vera firmware bug.