Strange DSC Plug In Behavior

This morning I awoke to find that the Vera reported “DSCAlarmPanel: Invalid Password for the Envislink module, please reconfigure” and the Vera controls over the DSC are of course non-functional.

The odd thing is that last night I set the alarm without a problem, nothing happened that I know of overnight and this morning I find it disabled.

I reset the password on the Envislink and the DSC Plug in and its still failing. I can obviously talk to the Envisilink, the Vera appears to be fine otherwise. But of course I cannot ARM the system from Vera. On the Envislink the "TPI Status’ shows “No client” … the EVL3 is online to the Envisalerts Server and there are no alerts from there so its working. The code used by Vera works on the local alarm panel to ARM/DISARM so the alarm system knows about the code.

Any ideas?

An update

I changed the Vera and DSC password back to the default “user” and everything works fine. I then set it to the earlier 4 digit numeric I had been using without a problem for over a year and it failed immediately. It appears that the only password it will accept is the EVL3 default “user”.

Very strange and very insecure

What changed?

Nothing that I can see. Happened sometime between midnight when the alarm was Ser and 7AM when I noticed it

UI5 or UI7?

UI5

Did you install anything? Strange Indeed.

No, nothing, I was asleep :slight_smile:

Is there a way to do a “reset” on the DSC?

Maybe this is a part of your locking up problem. …

But it’s been working flawlessly for over a year and then sometime in the middle of the night bang

My next guess would typically be a firmware auto-upgrade (from Envisacor). That’s after the standard ones like IP address renewal and Vera upgrade. Nothing is mentioned on their site though.

I also checked apps.mios.com, as I’ve had the MCV Team ‘patch’ one of my plugins before… Without providing notice, and without changing source control. That didn’t happen either.

The error you’re seeing means you’re at least connecting to the 2/3DS, and it’s requesting Auth, so I eliminated IP reassignment issues.

I am now getting this too and can’t understand it. Restarting Luup sometimes allows it to work. UI7 with the firmware from a few days ago.

Now yet another oddball behavior recently. This one I just don’t understand at all.

Twice in the past two weeks I have noticed that the indicator for one of the zones keeps showing as tripped but the DSC itself itself shows all the zones ready. I noticed this first in ImperiHome where the Composite Security widget starts flashing red after someone opens the front door, Zone 1 but doesn’t stop after the door is closed. The Vera shows the Zone 1 sensor tripped but the DSC shows everything fine and ready to arm.

If I reboot the Vera the problem clears … until the next time :slight_smile: If it would happen every day I could track it down but it happens maybe once a week so it nothing but a pain to find.

I have the EVL2 set to send me email alerts on TPI login/logoff.

When I reboot vera, it takes a minute or so for the email saying “logged off” to arrive. Then vera logs in 10 seconds or so later.

the logs show this:

01 04/18/15 20:42:28.080 LuaInterface::CallFunction_Timer device 49 initializeLabelsAndAlarmState took 40 seconds <0x2cb4e680> 50 04/18/15 20:42:28.086 luup_log:49: DSCAlarmPanel: debug processIncoming:: Command=505, Data='3', Checksum=CD <0x32e8d680> 06 04/18/15 20:42:28.086 Device_Variable::m_szValue_set device: 49 service: urn:micasaverde-com:serviceId:DSCAlarmPanel1 variable: VendorStatusData was: 2032041815 now: 3 #hooks: 0 upnp: 0 skip: 0 v:(nil)/NONE duplicate:0 <0x32e8d680> 06 04/18/15 20:42:28.087 Device_Variable::m_szValue_set device: 49 service: urn:micasaverde-com:serviceId:DSCAlarmPanel1 variable: VendorStatusCode was: 550 now: 505 #hooks: 0 upnp: 0 skip: 0 v:(nil)/NONE duplicate:0 <0x32e8d680> 06 04/18/15 20:42:28.091 Device_Variable::m_szValue_set device: 49 service: urn:micasaverde-com:serviceId:DSCAlarmPanel1 variable: VendorStatus was: Time/Date Broadcast now: Login Response #hooks: 0 upnp: 0 skip: 0 v:(nil)/NONE duplicate:0 <0x32e8d680> 50 04/18/15 20:42:28.093 luup_log:49: DSCAlarmPanel: debug Panel::Login Response (3) <0x32e8d680> 50 04/18/15 20:42:28.094 luup_log:49: DSCAlarmPanel: debug processIncoming:: Command=500, Data='005', Checksum=2A <0x32e8d680> 50 04/18/15 20:42:28.096 luup_log:49: DSCAlarmPanel: debug processIncoming:: Command=505, Data='0', Checksum=CA <0x32e8d680> 06 04/18/15 20:42:28.096 Device_Variable::m_szValue_set device: 49 service: urn:micasaverde-com:serviceId:DSCAlarmPanel1 variable: VendorStatusData was: 3 now: 0 #hooks: 0 upnp: 0 skip: 0 v:(nil)/NONE duplicate:0 <0x32e8d680> 50 04/18/15 20:42:28.097 luup_log:49: DSCAlarmPanel: debug Panel::Login Response (0) <0x32e8d680> 50 04/18/15 20:42:28.098 luup_log:49: task Invalid Password for the EnvisaLink module, please reconfigure.

Any ideas?