Ghost Security Sensor Trips

Community Playground General Discussions
#15

Hi @reneboer no trip redetect that I am aware of. Certainly not in the Reactor, but where would I find such a setting?

The trip at 7:02 BTW was us leaving, so totally expected.
But you’re right, no Tripped was 1 now 0!

Currently my log is running from Jan 18. Log rotation seems to have stopped, so I may force one. Mine get FTPed to my own server anyway.

EDIT: had a stuck lock file from Jan 18. Log rotation back on :slight_smile:
C

#16

Scratching my head as to the relationship between the title and your post… what does it have to do with luup reload?
You are discussing the same ghost trip I am seeing in my other thread which I should split.

#17

I guess it came from that reload thread. So changed.

C

#18

Pulling this out of the 7.31 thread cos it was beginning to feel off topic. While looking at why my VP might be reloading I found this:

01	01/28/20 23:10:26.734	UserData::ParseStateList device 80 corrupted service:(null) variable:(null) <0x77b33320>

This is my thermostat. The message seems a bit serious. Thoughts?

C

#19

I merged the topics. It seems to be a long standing issue which has gone unresolved. I wouldn’t think it is too hard for @edward to look for what can change the trip status of a device and figure out why it can be done by something other than the device itself.

1 Like
#20

I think I know what’s happening with the front door sensor.

For some reason it’s staying in tripped mode.

Looking at the variables it’s showing Tripped = 1 and LastTripped as 0702 this morning. (And the icon has the little red curves above it)

So that mystery is solved but we just have another one as to why it’s stuck in tripped. Seems to have been a bit common doing some googling.

I’ve set it back using the UI and I guess I could use a but of code in a Lua activity to set all sensors to ‘Untripped’ when the security goes armed.

Tried do to it with the code from here:

luup.variable_set(“urn:schemas-micasaverde-com:serviceId:DoorSensor1”, “Tripped”, “0”, 225)

But totally failed. Any ideas as to why would be lovely.

C

#21

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…

#22

Ta!

Can’t test it now, or all the alarms will go off :smiley:
C

#23

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.

#24

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…

#25

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.

#26

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?

#27

Now I’ll just have to figure out if someone’s roaming the house or my Vera is just on something!

#28

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.

#29

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

#30

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
#31

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
#32

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

#33

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

#34

Hi @edward, the 3 devices I saw this on are:

  1. Aeotec Gen2 HEM , 134,2,28
  2. Hank Door/Window Sensor, 520,513,8
  3. 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