Start by maybe opening a ticket? Are your sensors included with secure class? One characteristic of the ghost trips is that they stay tripped… since apparently the sensors physically never tripped and that it is a corruption of the vera, it never sends an untrip frame either…
All but one aren’t included securely but that’s not the one I’m having issues with. That’s exactly what I’m experiencing, they’ll stay tripped until there is actual motion then they’ll untrip properly.
Yep that would be it. The one thing I can think of testing is to do a manual luup reload to see if it fixes anything. Second test would be to restore from a backup from before the time when they started if you have one.
Have a motion sensor stuck tripped right now tried a Reload no help, can’t do a restore from back up cause this is my production unit (I know shouldn’t be testing betas on it) and I have made some changes since the ghost trips. Will open a ticket with support, weirdly enough ever since these ghost trips have occurred my Vera has been ‘hanging’ delayed device commands, plugins not updating statuses etc. Needs a reload to get back and up again
I have been trying to partition and investigate a number of these zwave issues as you can see from my other posts. I am suspecting that because I have a much longer interval between luup reload these days, like many of you, I am seeing some new problems which never were very consistently observed before. This ghost trip has long been reported, you can see them from many years ago on the forum. The problem is that they were rarely consistent and sometimes mios and support, rightfully, would blame the sensor. But what I am observing is different. It seems like a device data corruption which can be fixed by a luup reload. My system has stopped having them for the past 4 days and I can’t figure out why I had them almost daily before. The only things I did was restore from an older backup which does both a luup reload and a user-data restore. I did not restore my zwave dongle. So I am suspecting one of the two to be the corrupted item.
The luup reload will not fix the stuck tripped device. You will have to, after the luup engine is reloaded, trip it again and see if it untrips.
So the Ghost trips don’t appear to be directly related to the “tardy” hang ups of the vera which seem to be related more to the mishandling of got CAN frames and NONCE ID of secure class devices and overall zwave command queue management.
1 Like
Interesting information, I’m hoping that the team is able to look into this and figure out a solution. Seems that this line of FW is EOL and I don’t blame them but some hot fixes for these ghost trips and tardy issues should be released to make Vera run somewhat reliably. My ghost trips are at about 16-20 per night. I may try to restore from a backup from yesterday maybe that’ll help.
16-20?! That’s a lot. The luup reload would be a good test for 24h to see if they repeat.
If it is as I suspect a memory corruption issue, then they may go away. If the corruption is in the user-data then it is a storage corruption and only a restore from back up would help.
You are correct in mentioning that with the FW being at EOL, it is not going to be easy to fix. I believe this to be a fundamental design issue I have discussed before:
- Separate device status from device and hub configuration.
- Treat device and hub config as if as if they were sacred allowing only user vetted changes.
- Only save device status variables on a regular basis. Not the entire user-data
- Make use of a larger storage partition, it is available. Why only use 8-10mb of it?
- Do not write or change anything when loading the engine. The reload is actually a source of corruption as it is, it is also taking much too long because of everything it does. It should only be loading data. If actions are needed, suggest them in a specific screen.
Etc etc…
Hopefully the new ezlo firmware will be different.
Yeaup woke up to 16 notifications from the 5 z wave motion sensors I have. Did a reload so will monitor tonight I’m expecting less ghost trips. I will restore from back up hopefully sometime this week, just for stability sake.
Hoping the new Ezlo FW is coming I bet they’re just as fed up with the old FW as we are😅
So after my reload yesterday I woke up to know ghost trips, im suspecting that in the following days they will start to pick up again
1 Like
It is then as I suspected… There is variable data corruption occurring within the vera’s memory accumulating over time…
I’m seeing the same too. I’m away from home currently and had been seeing random smoke alarm trips on smoke 1&2 in different rooms. Aeotec were brilliant and replaced then add we tried all sorts and concluded they were faulty.
Now I get false trips on 1&3.
99% of the time after a vision pir is Tripped (covered by CCTV and there is nothing there)
This has been a good test as I’ve been out of the house with no heating etc on.
Trips happen either several times of the day or nothing for days.
Nearly always the same sequence of pir and smoke trips.
No access to logs but looks like the screenshot in when it happens
So as of 7.31 I can say I’m getting less ghost trips over night, still having motion sensors stuck in a tripped state though
The “getting stuck” condition, if not being a ghost trip to begin with, is likely related to the “tardy callbacks” which makes the vera engine hang, missing the untrip frame coming from the sensor. This is a fundamental issue dating from long long ago.
I hate to offer this horrible kludge, but as a workaround, you might set the AutoUntrip state variable on the sensor to something >0 seconds. This is a special feature that causes the Vera device to untrip automatically after the configured number of seconds. It has absolutely nothing to do with the physical state of the sensor itself, but at least, if a real Z-Wave reset from the sensor is missed, the Vera can right itself.
If the variable does not exist on the device in its Advanced > Variables, you can create it in Advanced > New service by using service ID urn:micasaverde-com:serviceId:SecuritySensor1.
Please note this only applies to binary (Trip/Untrip) sensors.
1 Like
not a half bad solution, i keep running into the issue of lights remaining on since the vera thinks there’s still motion.