So I have had this ghost trip happen almost once a day on a single sensor so I wanted to report the results of a few tests I made here:
Because it is a single sensor, I was wondering if it was caused by a rogue scene hidden somewhere which I could not find. I tried changing the id of that sensor and… no luck so that’s not it. The same sensor would still trip every day or two for with no physical trip so… it is either the sensor itself or the at least one level below the luup logic layer.
I tried replacing the sensor. Luckily I have a spare so I swapped them out. Well, now the problem is affecting another sensor which never had any problem before and now is also only affecting that one sensor. What is the likelyhood that this sensor started failing only after I replaced the other one?
I think something is happening in the luup engine causing these random (in time) ghost trips affecting only a single device at a time. I don’t think the trip command is coming from the sensor. I need to dig out the log the next time it happens.
Edit:
Looking through my logs I am seeing only one event involving the sensor in question and though I have not been able to verify timing, it looks like the engine is doing something very weird:
One of my Fibaro motion sensors trips then immediately resets when there’s no one there (and it’s in my server room so it would have to be birds. Don’t ask)
One of my door sensors trips and immediately resets. Again, no one there, and I can check on the camera. Plus the alarm doesn’t go off (there is a non vera alarm as well)
Some of my sirens change state randomly
Or not. Just running a quick grep I see bogus class errors
0x30 on my thermostat
0x31 on the fabled Fibaro temp sensors that keep locking up
0x60 on a device I need to hunt down
I have some Everspring motion sensors and there is nearly always one that will trip when they get armed. For most I ignore it as it happens when the house mode changes to away. But one I arm daily to detect I got in the main room and turn on the radio, lights etc. Quite annoying when that happens at 6 AM instead. It seems that if I replace the battery on that one, the phantom trigger moves to one of the other motion sensors again.
Looking at a full day of logs, I am seeing all my bogus class entries to be 0x30 binary sensors and are associated with my thermostat (130x), my Aeotec HEM (1x) and the door sensor which had a ghost trip (2x) as posted above.
I did not know these ghost sensor trips were so widespread… thank you guys for reporting! I am down to writing luup code to prevent them at this point but it is a bit insane to have a problem like this. My device in question is set to never be polled and to never wakeup… It is not communicating at all so the vera is changing the device status on its own…
I have some luup code filtering trip, so I’m not sure if I’m experiencing this.
My code is saving the latest state and check if it’s changed before calling my own code. I don’t arm sensors and I write my own logic. Never had any problems. I started because I got false report (re-triggering to be honest) since day 1 (so, almost 4 years ago).
Mind sharing exactly what you did? I am seeing sensor trips not associated with armed events. Why does it affect only one sensor? When I arm 2 dozens at a time? Why is it always the same sensors in spite of having dozens of the same type? Why removing this sensor moves the problem to another sensor? I do remember having issues with zooz motion sensors (seemingly always the same 1 or 2) as well but I don’t have any of them. Now it is all on door sensors which I am 100% sure never moved and never transmitted.
I’m not sure why it’s doing this, but after waking up in the middle of the night for a couple of times (I have a light turning on in case one of the doors, garage doors or entryways are open at night) and spent half an hour to check every cams, entryways, etc, I added this code.
I will post it when I’ll be back at my desk.
EDIT: Here’s the code:
D_SECURITYSENSOR = "urn:micasaverde-com:serviceId:SecuritySensor1"
local previousState = luup.variable_get(D_SECURITYSENSOR, "LastState", dID) or "-1"
local newState = luup.variable_get(D_SECURITYSENSOR, "Tripped", dID) or "-1"
local delay = 60 -- in seconds
local lastTrip = luup.variable_get(D_SECURITYSENSOR, "LastTrip", did) or os.time()
if (tonumber(newState) ~= tonumber(previousState)) then
luup.variable_set(D_SECURITYSENSOR, "LastState", tonumber(newState), dID)
return true
end
return false
I use it in a function, called when every sensor is tripped. This way, I can trip a device only if it has not tripped. I just have a scene/lua code waiting for the function to return true (not already tripped). My false negatives are zero now. In the past, as I said, I had a lot of trip-untrip-trip sequences, trip-trip and so on, causing lights or announcements to be repeated. I also have another filter function to wait for at least X minutes before untripping, very similar to this, used to avoid continuous on-off cycles.
Thanks! It seems to be a different problem from mine so your code would not be helpful. For me it is a sensor which trips out of the blue without any correlation with any previous trip. My code would more to send a warning on the trip first and let the user decide whether to untrip upon arming.
I then got notification from Vera:
A door/window was opened at 2020-01-30 07:26:59. Reported by Catman’s Plus serial #50103066 device #225 “Front Door” in “Hall”. Alert ID #28036358872
I have some thing similar. Now I am thinking. I see your sensor got tripped at 7:02. The Vera sends an alert by default for armed tripped sensors. Yours got armed at 7:26. Do you have a trip redetect interval of more than 25 minutes? In that case the tripped value may still be 1 for all that time when the sensor gets armed. At that moment the ArmedTripped value becomes 1. This value does not come from the sensor. It is a Vera made condition. I would think you’d see an entry in the log for the ArmedTripped value changing which does not seem to be the case, but I also do not see the Tripped changing from 1 back to 0 in your log.
I will pull some more logs on my system too. Problem is the logs rotate so quickly it is all gone once I think about it.
Yeah, as I said in the other thread, I had to stop using arm and write my own logic. This may be related to the armedtripped becoming 1 and sending the alert. @edward can you please double check for us? Thanks.
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.
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.
