So I have my Vera and DSC 1864 panel connected via a Envisalink-3. The plug in on the UI5 connects just fine to the DSC panel. It accurately polls just fine and updates the UI5 with any status changes (Arm/Disarm, etc). But when I go to arm or disarm using the UI5 (either directly using Partition 1 or via scene), it only will work when the keypad (WT5500) is ‘active’…meaning it’s not showing as ‘Keypad Blanking’.
Some background:
+Veralite UI5 with Firmware at 1.5.622 connected to my router via ethernet
+DSC Power Series (1864) Panel with EVL-3 connected to same router via ethernet
+DSC Alarm Panel Plugin v 0.38 installed with the following config changes/settings:
+Set DSC Interface Module to EnvisaLink 2DS
+updated IP in advanced settings with IP/port (192.168.0.12:4025)
+EnableRemoteArm setting changed to disarm
+Updated DoorZones to 1,2 (as I only have two door zones (both wireless set to zone 1 & 2 respectively))
+Updated SmokeZones to 16 (as I have a wireless smoke detector assigned to zone 16)
To eliminate any scene miscoding, I attempt to ‘manually’ disarm the system via Partition 1 (which is the only partition on the system). To do this I click the wrench, enter my master code in the box and press the disarm button. Nothing happens in that the system stays armed (and is reflected as such on the plug-in). No LUA errors reported. If I do the same thing but when the WT5500 is not keypad blanked (I just press the arrow key for example to activate the keypad), then when I disarm via the UI5 plugin, it works like a charm. Same effect with arming.
Have I missed something obvious? Or perhaps obscure? I’ve tried searching the forum for this behaviour and reading the plug-in page (which thankfully has been updated recently) but can’t seem to find it reported.
Does it behave any differently when you use a General User code instead of the Master code when invoking the Disarm?
Failing that, I’d need a copy of the log files covering the time-period where the API invocation is failing. This will let me know how the 3DS is responding, and if there are any special cases as a result of the WT5500/TR5164 combo.
It doesn’t appear to behave any differently with master code, user code, or no code at all (quick arm).
I tried an arm (no code) and log file is attached. I wasn’t sure if I should attach a log file from an operation (like disarm) that requires a code (not sure if code is represented in log). Let me know if you need/want a log file from a code-triggered action and if so, can you let me know it’s safe to post or if I should PM/email it to you.
ETA: I looked at the log and see several references to Partition2 but I only have one partition, Partition 1. So is the problem somewhere in there? The UI shows just Partition1 (both visible and in advanced settings).
Normally, folks with PM rights can just ping me with a copy (or a link to a copy)
I removed the log attachment from your post.
Ok, looks like you’ll need to enable Verbose logging in Vera itself, and redo the test.
You can PM me the logs, since they will have sensitive content, and I’ll look at it tonight. I need the extra data that Verbose logging shows, since it includes stuff about the physical bytes sent/received from the 3DS unit.
Also, it looks like you ran the test twice, but on the second round you’ve only captured 1/2 of the log output. I’ll need a full capture of the sequence.
The first entry did a No-PIN-Code style of Arm, so it’s possible that you’ll get different output in both cases. It would be best to have an example of each style (PIN Arm, No-PIN Arm) just in case there are multiple issues.
PM’d you the verbose logs with PIN and No Pin tests. Thanks again for looking into this.
Update: I modified the keypad blanking setting (section 016 option 3) to disable it (disabled is the default, but I enabled it during initial config as I felt it would reduce battery consumption). Now the plug-in works as expected for Arming/Disarming.
So the workaround solution is to ensure Keypad Blanking is Disabled.
Based upon your logs, here’s the sequence that’s occurring. The sequence is the same for all types of Arming, so I’ll just show the “regular” Arming stuff:
You make the Arm request, with a Pin code of “zzzz”, we pad it to 6-digits and send over:
[tt]50 06/18/13 18:15:07.050 luup_log:22: DSCAlarmPanel: debug Action::RequestArmMode Armed
50 06/18/13 18:15:07.051 luup_log:22: DSCAlarmPanel: debug extractPartition: Partition 1
51 06/18/13 18:15:07.052 0x30 0x33 0x33 0x31 0xzz 0xzz 0xzz 0xzz 0x30 0x30 0x46 0x42 0xd 0xa (0331zzzz00FBrn)
[/tt]
The 2DS/3DS then sends us back a “[tt]502[/tt]” error with a sub-code of “[tt]024[/tt]” (System Error, Partition is Not Ready to Arm):
[tt]52 06/18/13 18:15:07.312 0x35 0x30 0x32 0x30 0x32 0x34 0x32 0x44 (5020242D)
50 06/18/13 18:15:07.313 luup_log:22: DSCAlarmPanel: debug processIncoming:: Command=502, Data=‘024’, Checksum=2D
50 06/18/13 18:15:07.313 luup_log:22: DSCAlarmPanel: debug Panel::System Error (Partition is Not Ready to Arm)
[/tt]
So for whatever reason, when we send the arming code to the Device, we’re getting back a “[tt]502[/tt]” response error code and nothing else:
"System Error (Partition is Not Ready to Arm)"
I was hoping that the logs would give us more to go on. At this point, we’d really need the Envisalink lads to work out why they’re responding in that manner to the request being made. It’s not clear to me why this would prohibit Arming (it’s just a keypad afterall)
I would recommend you reach out to them on their support forum, and hyperlink to this thread/discussion. They may need to diagnose using your system if they’ve not seen the Wireless Keypad combination before.
Thanks guessed. As you suggested I posted on the Eyez-On EVL-3 forum and cross referenced this post. Here’s the thread there: [url=http://forum.eyez-on.com/FORUM/viewtopic.php?f=6&t=792&sid=0805aeb3a05d5e2c7f0d2e5b216b0425]http://forum.eyez-on.com/FORUM/viewtopic.php?f=6&t=792&sid=0805aeb3a05d5e2c7f0d2e5b216b0425[/url]