Author Topic: NX-8E, plugin stops responding  (Read 1352 times)

Offline beefus

  • Newbie
  • *
  • Posts: 2
  • Karma: +0/-0
NX-8E, plugin stops responding
« on: October 08, 2011, 05:22:57 pm »
Futzle: I appreciate your efforts in creating the NX8E alarm software.  I have been unable to get the software to work reliably.

My Configuration:
Vera 2 UI4 with 1.1.1338 firmware.
One dimmer as a test device with a lamp.
Vera 2 configured as bridge and static IP.
Alarm system is NX-8e.
USB to Serial is FTDI UC232R-10 bought from Mouser.
Serial connection setup as described in http://code.mios.com/trac/mios_caddxnx584/wiki/PhysicalConnection
23 wireless sensors, 2 key fobs all on Partition 1.
Sensors are a mix of smoke, water leak, and window/door open.
3 keypads, two are NX-148E, one is NX-148E-RF (incorporates wireless receiver)
Programmed mostly with DL900 windows software with some keypad entry.
All zones use zone names.
Location 207 through 211 same as eddie's reply #21
Using FireFox to access local Vera 2.
Downloaded latest NX8E software Oct 8, 2011.

I have waited a few weeks hoping these issues would be addressed in software updates but my system still has issues, which appear to center around displaying zones and selecting Arm or Bypass.

Typical problem:
With the alarm system Disarmed and zone (sensor) 7,8,11,16,23 in a tripped state:
 
Clicked reset (circle with arrows).  Server busy message for about 14 seconds followed by Opening IO port and Running Lua Setup messages. After messages disappear, none of the 23 zones are displayed as tripped.  Partition 1 Status correctly shows as Disarmed.

Clicking Bypass on zone 8 then shows zone 8 as tripped and bypassed, with zones 11, 7 and 16 as tripped.  However, zone 23 is still not displayed as tripped.

Clicking Bypass on zone 23 now shows zone 23 *AND zone 7* as tripped and bypassed, but zone 8, 11, and 16 now show as *NOT* tripped!

At any time clicking on an Arm or Bypass on any sensor may lockup the software and no further alarm operation can be performed until reset is applied.  During the lockup the dimmer still functions normally.   Is this a stack overflow issue?  Is there an issue with having this many sensors?

Please let me know if I can assist in resolving this issue.

A portion of the software is working properly:
A dashboard reset is performed and no zone Arm or Bypass buttons pressed.  I then use one of the three alarm keypads to bypass any tripped zones and the dashboard Partition 1 status correctly changes from Disarmed to Ready.  Through the dashboard the alarm can be set, the Status shows ExitDelay, and then Armed.  If an alarm does occur the notification message gets sent to my cell phone.  However, the dashboard Partition 1 Status remains Armed and does *NOT* display Alarm as the alarm is active.  Is that a problem?  I can disarm the alarm through the dashboard by entering my PIN and clicking
Disarm.


Thanks for your effort,


Jack
« Last Edit: March 30, 2013, 07:01:59 pm by futzle »

Offline futzle

  • Moderator
  • Master Member
  • *****
  • Posts: 3260
  • Karma: +192/-9
Re: Re: Setup
« Reply #1 on: October 08, 2011, 07:20:54 pm »
Both the Configuration Tab and Users tab seem to have a problem.

Bugger.  That means that the Luup Request mechanism (lr_foo) doesn't work over remote access.  I'll ask MCV if I'm doing anything wrong, or if there's a workaround, but that's going to take some time.

Meanwhile: you want to set a PIN for your vacation house remotely, right?  There might be a temporary workaround using scenes.  In version 55 of the plugin, I added a scene action "Set a User's PIN".  You supply the Master PIN, the user slot number, and the PIN you want to set that user to (empty will delete the PIN).  You can create a scene with the three values hardcoded, and manually trigger it by clicking on its "Run" button.  The scene should flash green on success, red on failure.  Without the Users tab, you won't be able to verify that the PIN has taken on its new value, but I've got a plan.  Let me know if the above is useful to you, and we can go further if you need.

Offline futzle

  • Moderator
  • Master Member
  • *****
  • Posts: 3260
  • Karma: +192/-9
Re: Re: Setup
« Reply #2 on: October 08, 2011, 08:33:56 pm »
Hi beefus,

I have waited a few weeks hoping these issues would be addressed in software updates but my system still has issues

Don't do that :)  I'm not a software house with a QA team to do testing, I'm just an indie developer with an itch to scratch.  I only know about bugs that get reported here.

So, thanks for reporting this bug.  Let's try to figure out what's the problem.

Quote
Typical problem:
With the alarm system Disarmed and zone (sensor) 7,8,11,16,23 in a tripped state:
 
Clicked reset (circle with arrows).  Server busy message for about 14 seconds followed by Opening IO port and Running Lua Setup messages. After messages disappear, none of the 23 zones are displayed as tripped.  Partition 1 Status correctly shows as Disarmed.

I think I can explain this one.  At startup, the plugin doesn't try to query the current state of each zone, so whatever state they were in is whatever state they stay in.  If the plugin never knew that the zone was tripped all along, it's never going to know.

On reflection, I think that's a poor assumption in the plugin, particularly for zones which are normally in the tripped state.  I think I can fix it by having the plugin seed a few Zones Snapshot Request messages into its request queue at startup.  The risk is that all this extra traffic at startup could lead to the kind of hang that others were getting early on in this plugin's development (and which is still happening to you).

Quote
Clicking Bypass on zone 8 then shows zone 8 as tripped and bypassed, with zones 11, 7 and 16 as tripped.  However, zone 23 is still not displayed as tripped.

Ah ha... I know why this happened.  The Zones Snapshot message works in 16-zone blobs.  When any zone in the range 1-16 updates, all of those zones update too, so you get their tripped status coming down.  zones 17-32 (including zone 23) are in their own blob.  If I do the queue-at-startup fix above, then this should no longer happen.

Quote
Clicking Bypass on zone 23 now shows zone 23 *AND zone 7* as tripped and bypassed, but zone 8, 11, and 16 now show as *NOT* tripped!

That is weird.  If you can capture a Luup log of that happening, and post it here, I can try to figure out why.

Quote
At any time clicking on an Arm or Bypass on any sensor may lockup the software and no further alarm operation can be performed until reset is applied.  During the lockup the dimmer still functions normally.   Is this a stack overflow issue?  Is there an issue with having this many sensors?

This is not good.  Other users who had this, it turned out to be a dodgy serial cable or USB adapter dropping bits.  In your case, 23 zones is a lot (I think it's a record for what I've seen) so you are a good candidate for load testing.  Again, if you can capture a Luup log of this happening then I can see if the plugin has got confused about its state, or if a message got lost in transmission, or something else entirely.  It shouldn't be a memory overrun issue; the state that I store for each zone is actually pretty tiny.

Quote
However, the dashboard Partition 1 Status remains Armed and does *NOT* display Alarm as the alarm is active.  Is that a problem? 

It's that way by design.  I am open to arguments that the design is wrong. :)  To explain further: The dashboard "Status" shows the Alarm's Detailed Armed State, which can be one of "Disarmed", "Ready" (to arm), "Armed", "EntryDelay" or "ExitDelay".  Whether the siren is actually sounding isn't actually part of the Detailed Armed State; it has its own orthogonal variable, which you're using already for the notification.  I see that neither the dashboard nor the "Alarm Partition" tab has the alarm state on it.  That's an oversight which I can easily fix (though I don't know if I can squeeze it onto the dashboard).