your quotes “” are oriented which is a lua syntax error? Not sure if it is the forum formatting or if it is from the original copied code…
Ta!
Can’t test it now, or all the alarms will go off 
C
Almost every night now I’m getting notifications of all 4 of my zooz motion detectors getting tripped, when no ones there which is odd.
On motion sensors: Just a thought, they are infrared sensors so if you have an infrared device in that room, it may trip it. Example: cameras with an infrared bulb turning on automatically when it is too dark or infrared remote controls/harmony hubs.
It may or may not be the case for you but it is a possibility.
Currently mine are all door sensors (I have had motion sensor do this before) which are 100% sure not interfered with and only affects one at a time…
All the locations I have mine placed there is nothing that was infrared light, I’m fairly certain its false trips because the area theyre ‘looking’ at it is very small so no chance of catching someone going to the bathroom at night etc.
Yep then we are on the same boat… This problem makes the vera completely useless for anything security related… Anyone from the crew to acknowledge here?
Now I’ll just have to figure out if someone’s roaming the house or my Vera is just on something!
One other thought… connecting dots here. For people who run ALTUI on the vera, we occasionally see a warning on some devices indicating that a device has variable with duplicate ids.
This has driven @amg0 to create a function to fix it.
http://forum.micasaverde.com/index.php?topic=50328.0
http://forum.micasaverde.com/index.php?topic=38597.0
http://forum.micasaverde.com/index.php?topic=37913.0
I don’t know what the cause of it is and it pops out of the blue occasionally. I am suspecting that it is some data corruption occurring either in the storage or the RAM and am wondering if it is related to the sensors’ tripped variable getting corrupted the same way. In my case running ALTUI on both the vera and openluup, I have never seen this on openLuup but occurs once every so often on the vera even on my emulator, indicating that it is not hardware related but likely a bug in the luup engine.
I will be waiting for my next motion sensor fals trip.
Just wondering what to do about the door sensors not resetting. Short of forcing them
C
Some devices don’t declare that they support this command class and they’re sending Sensor Binary. Share the ManufacturerInfo to confirm this.
@Catman
ParseStateList device 80 corrupted
This error means that some information from UserData was corrupted. What you can try is to exclude and include the device again. In order to figure out exactly how this happened I will need a full log. This error is not causing any reloads. It is part of the engine initialization so any reload here would cause an infinite reload loop.
1 Like
Hi Catman,
Maybe playing with the AutoUntrip setting may help? http://wiki.micasaverde.com/index.php/Luup_UPnP_Variables_and_Actions#SecuritySensor1
Most sensors also have a configurable trip time. I.e. they will not trip within x seconds after the last trip. This is especially used to save battery life. It will be a parameter for your sensor and you have to set it in the device options based on what the manual tells you.
Cheers Rene
1 Like
Thanks,
These are Everspring HSM02.
They don’t appear to have an Auto-untrip documented
http://www.everspring.com/wp-content/uploads/2019/04/HSM02_A501111906R01_ZDK5.02.pdf
Unless it’s this
2-2 Configuring the OFF Delay
The Configuration parameter that can be used to adjust the amount of delay
before the OFF command is transmitted as Configuration Parameter #2.
This parameter can be configured with the value of 0 through 127, where 0
means send OFF command immediately and 127 means 127 seconds of
delay.
Function Parameter Number Size Range Default
Basic Set level 2 1 0~127 0s
If this is it, this might well be good. I suspect what happens is if there are lot of open and close actions (as there were yesterday morning) if the sensor is immediately sending the ‘untrip’ typically <2 seconds after the trip, I wonder if the Vera simply missed it or it was lost in a queuing issue. Does that make any sense.
By faffing around trying to untrip it in Lua yesterday, I managed to add three additional ‘Tripped’ variables to the front door device. Is there any way to remove them?
Anyway would appreciate any thoughts about that, and if there’s any other way to proceed.
Thanks!
C
Thanks @edward I appreciate the input. What can I get you in logs?
The include / exclude is a total and utter nightmare though and really not a preferred solution unless we can prevent it happening again (and the device appears to work fine)
C
Hi @edward, the 3 devices I saw this on are:
- Aeotec Gen2 HEM , 134,2,28
- Hank Door/Window Sensor, 520,513,8
- Remote ZTS500 thermostat, 21076,512,33136
I just looked and their configurations and… you are correct. They (none of the 3) are not configured to support this command class.
How do I fix this? Can I just add that command class to the configuration (NodeInfo?)
@Catman, The autountrip I have experimented with accidentally could basically be done with lua code to set a timer whenever the sensor trips and automatically toggle the variable back after 10s. It can be easily done and seems to be a built in function you can activate in the luup engine, usually for motion sensors. If you want this, let me know.
Unfortunately, user data corruption is a “built-in” feature too unfortunately and I observed it to have a high correlation with luup reloads. Best prevention is to have backups and eliminate these reloads or as I have suggested for a long time, eliminate what they do to the user-data.
1 Like
Thank, Rafael, I’ll use Reactor I think. That way I can maintain it myself 
Cheers
C
Just wanted to add… Generally my observation of devices staying tripped are due to the vera being in “tardy” hangup or in the middle of a luup reload at the time the sensor sends the signal back to the vera that it is no longer tripped, causing it to miss it. It isn’t so much a ghost trip as it is really a vera hangup, missing a signal. I have greatly decreased the probability of this happening by eliminating luup reloads and decreasing the network chattiness…
1 Like
Thanks again. I’ve done all that I think I can (other than pull it off line) by applying all the settings and so on to reduce chattiness.
I think I’ll simply add an action to the Reactor that does Home / Away to reset the door sensors when it goes into Away mode.
There’s a risk but it’s minimal.
C
Speaking of the tardy thing, >60% of my tardy event are now being caused by this “wait 20000” timeout. And lead to a 20s tardy. @edward, could you look into this?
01 01/31/20 10:17:41.057 ZWaveJobHandler::ReceivedFrame NONCE_GET flood node 17 <0x7e203520>
01 01/31/20 10:17:41.097 ZWaveJobHandler::ReceivedFrame NONCE_GET flood node 17 <0x7e203520>
01 01/31/20 10:17:41.154 ZWaveJobHandler::ReceivedFrame NONCE_GET flood node 17 <0x7e203520>
01 01/31/20 10:17:41.402 ZWaveJobHandler::ReceivedFrame NONCE_GET flood node 17 <0x7e203520>
01 01/31/20 10:17:41.434 ZWaveJobHandler::ReceivedFrame NONCE_GET flood node 17 <0x7e203520>
01 01/31/20 10:17:41.694 ZWaveJobHandler::ReceivedFrame NONCE_GET flood node 17 <0x7e203520>
01 01/31/20 10:17:44.755 ZWaveJobHandler::ReceivedFrame NONCE_GET flood node 17 <0x7e203520>
01 01/31/20 10:17:47.807 ZWaveJobHandler::ReceivedFrame NONCE_GET flood node 17 <0x7e203520>
01 01/31/20 10:18:01.548 ZWaveSerial::Send m_iFrameID 5256 type 0x0 command 0x13 expected 3 got ack 1 response 38820552 request 0 failed to get at time 6566547 start time 6546535 wait 20000 ack 1 m_iSendsWithoutReceive 0 <0x7ec03520>
01 01/31/20 10:18:01.549 AlarmManager::Run callback for alarm 0x902090 entry 0x2521750 type 52 id 8072 param=0x2520d60 entry->when: 1580494661 time: 1580494681 tnum: 1 slow 0 tardy 20 <0x7ec03520>
01 01/31/20 10:18:01.555 AlarmManager::Run callback for alarm 0x902090 entry 0x245cf88 type 52 id 8070 param=(nil) entry->when: 1580494666 time: 1580494681 tnum: 1 slow 0 tardy 15 <0x7ec03520>
01 01/31/20 10:18:01.556 AlarmManager::Run callback for alarm 0x902090 entry 0x245d5f0 type 52 id 8073 param=0x2505d28 entry->when: 1580494668 time: 1580494681 tnum: 1 slow 0 tardy 13 <0x7ec03520>
often initiated by a NONCE_GET flood which is from a Zooz ZSE040 4 in 1 sensor. What determines that a wait can be 2s vs 20s as I see both types?
But sometimes I don’t see the NONCE_GET flood.
01 01/31/20 12:20:30.945 ZWaveSerial::Send m_iFrameID 9440 type 0x0 command 0x13 expected 3 got ack 1 response 44069792 request 0 failed to get at time 13915945 start time 13895931 wait 20000 ack 1 m_iSendsWithoutReceive 0 <0x7ec03520>
01 01/31/20 12:20:30.946 AlarmManager::Run callback for alarm 0x902090 entry 0x2a07658 type 52 id 15476 param=0x2a09720 entry->when: 1580502010 time: 1580502030 tnum: 1 slow 0 tardy 20 <0x7ec03520>
Also very strangely after making some minor unrelated changes yesterday leading me to reload luup, I am no longer seeing the bogus command class messages and neither am I seeing ghost trips after having them daily for the past 3 weeks. I am suspecting even more that there is some memory/data corruption which got reset.
Edit: more log entries:
01 01/31/20 13:20:24.346 ZWaveJobHandler::ReceivedFrame NONCE_GET flood node 82 <0x7e203520>
01 01/31/20 13:20:44.298 ZWaveSerial::Send m_iFrameID 11635 type 0x0 command 0x13 expected 3 got ack 1 response 49128024 request 0 failed to get at time 17529298 start time 17509286 wait 20000 ack 1 m_iSendsWithoutReceive 0 <0x7ec03520>
01 01/31/20 13:20:44.300 AlarmManager::Run callback for alarm 0x902090 entry 0x287f8f0 type 45 id 19963 param=(nil) entry->when: 1580505625 time: 1580505644 tnum: 1 slow 0 tardy 19 <0x7ec03520>
01 01/31/20 13:20:44.301 AlarmManager::Run callback for alarm 0x902090 entry 0x2762438 type 52 id 19953 param=(nil) entry->when: 1580505628 time: 1580505644 tnum: 1 slow 0 tardy 16 <0x7ec03520>
01 01/31/20 13:20:44.302 AlarmManager::Run callback for alarm 0x902090 entry 0x2a0d4e0 type 52 id 19965 param=0x2ef63b0 entry->when: 1580505628 time: 1580505644 tnum: 1 slow 0 tardy 16 <0x7ec03520>
01 01/31/20 13:20:44.305 AlarmManager::Run callback for alarm 0x902090 entry 0x2312230 type 52 id 19966 param=0x2ef6348 entry->when: 1580505628 time: 1580505644 tnum: 1 slow 0 tardy 16 <0x7ec03520>
01 01/31/20 13:20:44.306 AlarmManager::Run callback for alarm 0x902090 entry 0x213bb20 type 52 id 19967 param=0x29a1c40 entry->when: 1580505628 time: 1580505644 tnum: 1 slow 0 tardy 16 <0x7ec03520>
01 01/31/20 13:20:44.399 AlarmManager::Run callback for alarm 0x902090 entry 0x2994478 type 52 id 19968 param=0x234f970 entry->when: 1580505631 time: 1580505644 tnum: 1 slow 0 tardy 13 <0x7ec03520>
01 01/31/20 13:20:44.484 AlarmManager::Run callback for alarm 0x902090 entry 0x27532c8 type 52 id 19969 param=0x2994530 entry->when: 1580505640 time: 1580505644 tnum: 1 slow 0 tardy 4 <0x7ec03520>
01 01/31/20 13:20:44.521 got CAN <0x7e203520>
02 01/31/20 13:20:44.522 ZWaveSerial::Send m_iFrameID 11655 got a CAN -- Dongle is in a bad state. Wait 1 second before continuing to let it try to recover. <0x7ec03520>
01 01/31/20 13:20:44.636 ZWaveJobHandler::ReceivedFrame NONCE_GET flood node 83 <0x7e203520>
01 01/31/20 13:29:54.233 got CAN <0x7e203520>
01 01/31/20 13:29:54.233 ZWaveSerial::Send m_iFrameID 11858 type 0x0 command 0x13 got repeat failure 24 iNumFailedResponse 1 time 18079233 start time 18079220 wait 2000 m_iSendsWithoutReceive 0 <0x7e603520>
02 01/31/20 13:29:56.257 ZWaveSerial::GetFrame 0x7e6028f0 timed out now 1 m_listGetFramePending 1 <0x7e603520>
02 01/31/20 13:30:41.519 ZWaveNode::Wakeup did a poll for 209 1580506241 seconds interval 0 existing (nil) heal (nil) <0x7ec03520>
01 01/31/20 13:35:12.833 ZWaveJobHandler::ReceivedFrame NONCE_GET flood node 137 <0x7e203520>
01 01/31/20 13:35:13.013 ZWaveJobHandler::ReceivedFrame NONCE_GET flood node 137 <0x7e203520>
02 01/31/20 13:35:52.777 ZWaveNode::Wakeup did a poll for 129 1580506552 seconds interval 0 existing (nil) heal (nil) <0x7ec03520>
02 01/31/20 13:36:08.350 ZWaveNode::Wakeup did a poll for 99 1580506568 seconds interval 0 existing (nil) heal (nil) <0x7ec03520>
01 01/31/20 13:39:48.218 got CAN <0x7e203520>
01 01/31/20 13:39:48.218 ZWaveSerial::Send m_iFrameID 12227 type 0x0 command 0x13 got repeat failure 24 iNumFailedResponse 1 time 18673218 start time 18673196 wait 2000 m_iSendsWithoutReceive 0 <0x7e603520>
Hello,
No investigation or solution from my side, but I’d like to point that I also started to be affected by this a few weeks ago, on Fibaro motion sensor (cat’s eye).
It was previously working fine, but now it seems to be randomly tripping a few times per day.
My VP is absolutely plagued with false trips now from all my z wave motion sensors. Some are staying in the tripped state, while others are randomly tripping. Every day it seems like its getting worse and worse…