Welcome! You can download v2.45 from the toolbar on your Dashboard. Apps > Install apps.
Also, the instructions for configuring the plugin are on the help page.
I’ve had a few instances of false alarms:
Both…
GUI showing alarm/with no physical alarm.
And…
physical alarm/with no physical zones tripped but showing tripped in the GUI.
6/9/2012 12:00:07 A.M. EST.
Currently the GUI is Armed with tripped zones but no GUI or physical alarm.
Does the alarm panel show them tripped?
I have noticed it takes Vera awhile to reset a zone once its been tripped.
I was at work and not able to view the physical panel, but it did show those zones as tripped all day in the UI, when I got home last night of course Vera was working perfectly, turned the lights on as the door opened and disarmed the panel before I could get to the keypad.
Good point though, I’ll deploy a camera tonight with a view of one of the keypads to keep an eye on it.
And for now I’m going to assume the panel was clear, ready and armed because I did receive an email telling me the panel “Armed Away” when the wife left for work, when I logged in last night from home everything in the UI mirrored the keypad as clear and ready, I even remoted into my work PC and logged into Mios to see if it was a remote issue, but that too showed all zones as ready.
Had another false instance early this morning. Date: 6/14/2012 3:58:42 A.M. EDT with an Alarm ENTRY/EXIT DELAY - Keypad beeping and “Disarm System Now” being announced.
Jumped out of bed (grabbed the .45) and saw 2 zones tripped; zone 1 (front door) & zone 6 (garage overhead door - which is an instant zone) viewed my camera’s and both doors were closed. ???
Clearly zone 1 tripped first, triggering the entry/exit delay, but zone 6 tripping (I would have thought)should have triggered the ALARM? Does anyone know if tripping a delayed zone and then an instant zone behaves that way normally?
It then auto armed (as it should) at 04:00hrs announcing “ARMED, Exit Now” but still showing tripped in the UI and clear on the keypad ???
It continued to show tripped in the UI until 07:00hrs when the front door was opened and closed, then both those zones reset in the UI.
@JOD < dragging butt today with only 3hrs sleep.
@mcvflorin,
Thank you for looking into this for me.
Forgot to mention in my previous post that my garage overhead door openers are plugged into controlled receptacles that are turned off when the doors are closed and the alarm armed, and only turned on when the alarm is disarmed; so the chances of zone 6 being physically tripped (on several occasions) after arming would be slim.
I thought about the possibility of having a bad sensor on zone 1, but with talking keypads I would have noticed hearing “Fault, zone 1” and seeing the door closed, so I doubted that scenario too, but good catch on the LastTrip variable, and I have no clue why it’s not being updated.
It’s very strange.
Again, thank you.
These are the messages received from the panel around 3:58 AM on 06/14:06/14/12 3:57:50.927 “ARMED AWAY** ALL SECURE "
06/14/12 3:58:02.086 "ARMED AWAY ALL SECURE "
06/14/12 3:58:13.086 "ARMED AWAY ALL SECURE "
06/14/12 3:58:24.246 "ARMED AWAY ALL SECURE "
06/14/12 3:58:35.227 "ARMED AWAY ALL SECURE **”
06/14/12 3:58:41.906 “DISARM SYSTEM or alarm occurs”
06/14/12 3:58:52.396 “DISARM SYSTEM or alarm occurs”
06/14/12 3:58:54.906 "DISARM SYSTEM or alarm occurs "
06/14/12 3:58:58.496 “DISARMED READY TO ARM”
06/14/12 3:59:09.636 “DISARMED READY TO ARM”
06/14/12 3:59:20.636 “DISARMED READY TO ARM”
06/14/12 3:59:31.776 “DISARMED READY TO ARM”
06/14/12 3:59:42.786 “DISARMED READY TO ARM”
06/14/12 3:59:53.916 “DISARMED READY TO ARM”As you probably know, the panel cannot report the faulted zones when the panel is armed so the plugin can’t set a sensor as tripped when the panel is armed. Sensors 1 and 6 were probably already marked as tripped because when zone 1 was actually tripped at 7:35 AM the Tripped variable wasn’t updated. The question is why didn’t the plugin update the sensors to ‘not tripped’ after the last trip at 10:53 PM on 06/13?
52 06/14/12 7:35:43.446 “FAULT 01 ZONE 01”
06 06/14/12 7:35:43.447 Device_Variable::m_szValue_set device: 237 service: urn:micasaverde-com:serviceId:SecuritySensor1 variable: LastTrip was: 1339642425 now: 1339673743 #hooks: 0 upnp: 0 v:0x10b82e8/NONE duplicate:0
After installing yesterday’s private beta, zone 1 & 6 are behaving nicely now.
One thing to note about the UI lock status, it’s now reversed.
If I’m not mistaken the lock icon is wrong. The red and yellow stripes icons are not used anymore. I also noticed this bug.
The question is why didn't the plugin update the sensors to 'not tripped' after the last tripOne plausible explanation......
Trip a zone - restart the engine - then untrip the zone. In my system the zones do not update.
Restart the engine again - the zone updates to untripped.
Can you replicate?
Theoretically I handle this case. At the plugin startup I go through all the zones and check the last timestamp they were tripped.
-- Check if there are any faulted zones that need to be updated.
for zoneNo, zone in pairs(g_zones) do
local lastTrip = luup.variable_get(SID.SECURITY_SENSOR, "LastTrip", zone.device) or 0
if (os.difftime(os.time(), lastTrip) >= TTL) then
removeFaultedZone(zoneNo)
end
endI’ll enable Debug Mode for your plugin and will look through the logs if I can connect to your unit.
if I can connect to your unitEmail sent with access code.
[quote=“JOD, post:450, topic:168766”]
The question is why didn’t the plugin update the sensors to ‘not tripped’ after the last trip
One plausible explanation…
Trip a zone - restart the engine - then untrip the zone. In my system the zones do not update.
Restart the engine again - the zone updates to untripped.
Can you replicate?[/quote]
@JOD,
I’ve spent quite a bit of time working with the code for the plug-in, so I think I can answer this question for you…
When a zone is tripped, the (current version of the) plug-in adds the zone to a “g_faultedZones” list. The plugin then periodically checks zones in this list, and sets the zone back to “unfaulted” status after the zone’s TTL has expired.
When the engine is restarted, g_faultedZones is cleared (by the restart). Then, zones that have exceeded their TTL are cleared right away, and zones that are still within the TTL are left in the faulted state. However, the plug-in does not add these currently faulted zones back in to the g_faultedZones list, so they will never timeout.
A quick fix would be to change the startup code so that the faulted zones that are not cleared at startup are added back into the g_faultedZones list.
Hugh
@hugheaves
I though about this too, but then I remembered that I handled this case. The code from my previous post is from the startup function. At startup I parse the whole zones list, not only the faulted ones. Theoretically it should work, but I’ll try to find why it doesn’t.
[quote=“mcvflorin, post:454, topic:168766”]@hugheaves
I though about this too, but then I remembered that I handled this case. The code from my previous post is from the startup function. At startup I parse the whole zones list, not only the faulted ones. Theoretically it should work, but I’ll try to find why it doesn’t.[/quote]
I think the startup code is good, except for the fact that if the zone is in faulted status at startup, but hasn’t yet reached it’s TTL, it needs to be added to the g_faultedZones list. (so the plugin will keep checking for it’s TTL expiration)
Here’s the TTL loop code that only checks zones is g_faultedZones:
function ttlCountdownTimer()
for _, zone in pairs(g_faultedZones) do
local lastTrip = luup.variable_get(SID.SECURITY_SENSOR, "LastTrip", g_zones[zone].device) or 0
if (os.difftime(os.time(), lastTrip) >= TTL) then
removeFaultedZone(zone)
end
end
luup.call_delay("ttlCountdownTimer", TIMER_INTERVAL, "")
endMaybe something like this would work for the startup:
-- Check if there are any faulted zones that need to be updated.
-- If they're faulted, but not ready to be updated, add them to the g_faultedZones list
for zoneNo, zone in pairs(g_zones) do
local lastTrip = luup.variable_get(SID.SECURITY_SENSOR, "LastTrip", zone.device) or 0
if (os.difftime(os.time(), lastTrip) >= TTL) then
removeFaultedZone(zoneNo)
elseif ((luup.variable_get(SID.SECURITY_SENSOR, "Tripped", zone.device) or "0") == "1")
addFaultedZone(zoneNo)
end
end@hugheaves
Indeed, that could fix JOD’s issues. I’ll upload the modified file on his Vera.
Thank you @mcvflorin & @hugheaves.
I'll upload the modified file on his VeraUnfortunately this did not help. Zones do not reset if the engine is restarted while zones are tripped.
[quote=“JOD, post:458, topic:168766”]
I’ll upload the modified file on his VeraUnfortunately this did not help.
Zones do not reset if the engine is restarted while zones are tripped.[/quote]
JOD, I don’t have access to the exact code that @mcvflorin uploaded. However, if he implemented it as I proposed, you’d still need to wait about 20 minutes (by default) for the zones to reset, even after a restart.
Are they still not resetting after the timeout expires?
Hugh
With the system operating normally, tripping a zone, watching the device change in the UI, and then untripping the zone, it’s taking between ~2 - 4 minutes to reset in the UI.
Restarting the engine with tripped zones, the zones will show tripped in the UI even after waiting an hour.
The weird part to me is, if I restart the engine for a 2nd time, after waiting that hour, they reset in the ~2 - 4 minute range again.