We have moved at community.getvera.com

Author Topic: Re: Setup  (Read 9102 times)

Offline futzle

  • Moderator
  • Master Member
  • *****
  • Posts: 3260
  • Karma: +192/-9
Re: Re: Setup
« Reply #15 on: December 24, 2010, 05:36:58 am »
Now I'm stuck on how to use it... the sensors give me their status with no issues, but I can't arm or bypass them.
Neither I can arm or disarm the alarm....

Excellent progress.  For those following along at home, do you think it was adding the CTS/RTS wires, or did you modify anything on the Vera too?

The partition and the sensors have scene actions which you will find if you start creating a scene.  I found back in the UI2 days that these were more reliable than the buttons on the main web UI.

Log2.doc has some messages from the plugin.  If you like, you can pipe the log through grep 'luup_log:39:' to show just the log messages from the plugin, and none of the other stuff.

I need to see the log from the plugin as it starts up.  The easiest way to do this is to start running tail -f on the LuaUPnP.log, then press the "SAVE" button on the Vera web UI (or the circular arrow icon if you've made no changes in UI4).  This starts all of the plugins again.

Once I've got that log I can maybe see where the plugin is falling off the rails.

Offline glaso

  • Jr. Member
  • **
  • Posts: 59
  • Karma: +0/-0
Re: Re: Setup
« Reply #16 on: December 24, 2010, 07:58:49 am »
Hi Futzle:

Quote
Excellent progress.  For those following along at home, do you think it was adding the CTS/RTS wires, or did you modify anything on the Vera too?
Yes, definitely the CTS/RCS wires are required, my wire config is as follows

NX8e ----> DB9
3 --------->   2
5 --------->   3
9 --------->   5
4 --------->   7
6 --------->   8

With that wire config, no null modem cable is required, just connect the DB9 to the USB / Serial interface.

Quote
The partition and the sensors have scene actions which you will find if you start creating a scene.  I found back in the UI2 days that these were more reliable than the buttons on the main web UI.

I'm a bit lost here, in the attached file there are some screenshots of the options available for each devices when creating a scene. For partition 1 I have two options: "Unchanged" and "set virtual input open/closed"; and for Zone devices I have three options: "Unchanged", "Arm", "Bypassed".
I'm not sure were to input the password for the alarm. In Partition 1, under Control I have a place to input the password, but nothing seems to happen (The password is the same using to arm/disarm from the keypad wright?).

Quote
Log2.doc has some messages from the plugin.  If you like, you can pipe the log through grep 'luup_log:39:' to show just the log messages from the plugin, and none of the other stuff.

I need to see the log from the plugin as it starts up.  The easiest way to do this is to start running tail -f on the LuaUPnP.log, then press the "SAVE" button on the Vera web UI (or the circular arrow icon if you've made no changes in UI4).  This starts all of the plugins again.

Attached is the log of the initialization of the plugin

I also attached screenshots of every device created with its details, also attached a screenshot of the serial port configuration and options available when creating scenes.

Other issues: I'm having some stability problems, I think that my serial / USB interface could be faulty because, sometimes, the alarm fails to get recognized.
When I power cycle Vera it doesn't recognize the USB / Serial interface, I have to unplug and plug it back (with Vera running) to get the USB light in Vera on.

Again, thank you very much for your help Futzle, definitely we are going somewere here.

Merry Christmas and have a wonderful holiday.


Offline glaso

  • Jr. Member
  • **
  • Posts: 59
  • Karma: +0/-0
Re: Re: Setup
« Reply #17 on: December 24, 2010, 07:59:57 am »
More attachments....

Offline glaso

  • Jr. Member
  • **
  • Posts: 59
  • Karma: +0/-0
Re: Re: Setup
« Reply #18 on: December 24, 2010, 08:00:32 am »
now the log....

Offline futzle

  • Moderator
  • Master Member
  • *****
  • Posts: 3260
  • Karma: +192/-9
Re: Re: Setup
« Reply #19 on: December 28, 2010, 04:00:34 pm »
Quote
The partition and the sensors have scene actions which you will find if you start creating a scene.  I found back in the UI2 days that these were more reliable than the buttons on the main web UI.
I'm a bit lost here, in the attached file there are some screenshots of the options available for each devices when creating a scene. For partition 1 I have two options: "Unchanged" and "set virtual input open/closed"; and for Zone devices I have three options: "Unchanged", "Arm", "Bypassed".
I'm not sure were to input the password for the alarm. In Partition 1, under Control I have a place to input the password, but nothing seems to happen (The password is the same using to arm/disarm from the keypad wright?).

Yes, the password is the same as the one used to arm/disarm.  I just tested my panel and it worked.

I see what you mean about the meagre scene command list for the partition (with only "Set Virtual Input Open/Closed").  I get that too on my panel.  I think we might have to ask @guessed if it makes sense for us to extend D_AlarmPartition1.xml with the arm/disarm commands too.

If away/stay/disarm and arm/bypass not working for you then one of three things is happening:
  • The serial connection is dropping out, and the plugin needs to handle signal corruption better.
  • You have disabled the arm/disarm feature from the panel (I'll know if I can see a complete log right from the start).
  • There's some nuance of the serial protocol which doesn't happen on my panel but does on yours, and the plugin needs to know about it.

Right now my money's on the first one, but I'll need to see a log of the failure happening to know for sure.

Here's a complete log from my system, for reference.  Note the first message "Initializing Caddx NX-584", which tells you when the plugin starts.  Your last log was missing the beginning.
Code: [Select]
50 12/29/10 7:38:05.141 luup_log:46: Initializing Caddx NX-584 <0x803>
50 12/29/10 7:38:05.143 luup_log:46: Sending message and waiting for response: 0x21 Interface Configuration Request <0x803>
50 12/29/10 7:38:05.145 luup_log:46: Message: Outgoing: 0x7e 0x01 0x21 0x22 0x23 <0x803>
50 12/29/10 7:38:05.167 luup_log:46: Received good message 0x01 <0x803>
50 12/29/10 7:38:05.169 luup_log:46: Message: Incoming message body: 0x31 0x2e 0x30 0x36 0xf2 0x07 0xf2 0x07 0x57 0xd8 <0x803>
50 12/29/10 7:38:05.170 luup_log:46: Handling message: 0x01 Interface Configuration <0x803>
50 12/29/10 7:38:05.171 luup_log:46: Firmware version 1.06 <0x803>
50 12/29/10 7:38:05.172 luup_log:46: All message codes are supported. <0x803>
50 12/29/10 7:38:05.173 luup_log:46: Set Clock enabled <0x803>
50 12/29/10 7:38:05.174 luup_log:46: Primary Keypad Function with PIN enabled <0x803>
50 12/29/10 7:38:05.175 luup_log:46: Secondary Keypad Function enabled <0x803>
50 12/29/10 7:38:05.176 luup_log:46: Zone bypass enabled <0x803>
50 12/29/10 7:38:05.177 luup_log:46: Sending message and waiting for response: 0x3b Set Interface Clock <0x803>
50 12/29/10 7:38:05.180 luup_log:46: Message: Outgoing: 0x7e 0x07 0xbb 0x0a 0x0c 0x1d 0x07 0x26 0x04 0x27 0xac <0x803>
50 12/29/10 7:38:05.341 luup_log:46: Received good message 0x1d <0x803>
50 12/29/10 7:38:05.341 luup_log:46: Message: Incoming message body: <0x803>
50 12/29/10 7:38:05.342 luup_log:46: Sending message and waiting for response: 0x28 System Status Request <0x803>
50 12/29/10 7:38:05.344 luup_log:46: Message: Outgoing: 0x7e 0x01 0x28 0x29 0x2a <0x803>
50 12/29/10 7:38:05.368 luup_log:46: Received good message 0x08 <0x803>
50 12/29/10 7:38:05.369 luup_log:46: Message: Incoming message body: 0x02 0x00 0x00 0x00 0x00 0x42 0x00 0x00 0x02 0x01 0x9c <0x803>
50 12/29/10 7:38:05.371 luup_log:46: Handling message: 0x08 System Status <0x803>
50 12/29/10 7:38:05.371 luup_log:46: Valid partition 1 <0x803>
50 12/29/10 7:38:05.372 luup_log:46: PIN length is 4 <0x803>
50 12/29/10 7:38:05.374 luup_log:46: Setting up partition 1 <0x803>
50 12/29/10 7:38:05.375 luup_log:46: Sending message and waiting for response: 0x26 Partition Status Request <0x803>
50 12/29/10 7:38:05.376 luup_log:46: Message: Outgoing: 0x7e 0x02 0x26 0x00 0x28 0x52 <0x803>
50 12/29/10 7:38:05.397 luup_log:46: Received good message 0x06 <0x803>
50 12/29/10 7:38:05.399 luup_log:46: Message: Incoming message body: 0x00 0x00 0x20 0x00 0x40 0x01 0x04 0x80 <0x803>
50 12/29/10 7:38:05.400 luup_log:46: Handling message: 0x06 Partition Status <0x803>
50 12/29/10 7:38:05.402 luup_log:46: Setting up zone 1 <0x803>
50 12/29/10 7:38:05.404 luup_log:46: Sending message and waiting for response: 0x24 Zone Status Request <0x803>
50 12/29/10 7:38:05.406 luup_log:46: Message: Outgoing: 0x7e 0x02 0x24 0x00 0x26 0x4e <0x803>
50 12/29/10 7:38:05.428 luup_log:46: Received good message 0x04 <0x803>
50 12/29/10 7:38:05.429 luup_log:46: Message: Incoming message body: 0x00 0x01 0x10 0xda 0xf2 0x00 0x00 <0x803>
50 12/29/10 7:38:05.431 luup_log:46: Handling message: 0x04 Zone Status <0x803>
50 12/29/10 7:38:05.432 luup_log:46: Zone 1 (Zone 1): D_MotionSensor1.xml urn:schemas-micasaverde-com:device:MotionSensor:1 <0x803>
50 12/29/10 7:38:05.433 luup_log:46: Valid zone 1 <0x803>
50 12/29/10 7:38:05.434 luup_log:46: Setting up zone 2 <0x803>
50 12/29/10 7:38:05.435 luup_log:46: Sending message and waiting for response: 0x24 Zone Status Request <0x803>
50 12/29/10 7:38:05.437 luup_log:46: Message: Outgoing: 0x7e 0x02 0x24 0x01 0x27 0x4f <0x803>
50 12/29/10 7:38:05.459 luup_log:46: Received good message 0x04 <0x803>
50 12/29/10 7:38:05.461 luup_log:46: Message: Incoming message body: 0x01 0x01 0x10 0xda 0xf2 0x00 0x01 <0x803>
50 12/29/10 7:38:05.462 luup_log:46: Handling message: 0x04 Zone Status <0x803>
50 12/29/10 7:38:05.463 luup_log:46: Zone 2 (Zone 2): D_MotionSensor1.xml urn:schemas-micasaverde-com:device:MotionSensor:1 <0x803>
50 12/29/10 7:38:05.464 luup_log:46: Valid zone 2 <0x803>
50 12/29/10 7:38:05.465 luup_log:46: Setting up zone 3 <0x803>
50 12/29/10 7:38:05.466 luup_log:46: Sending message and waiting for response: 0x24 Zone Status Request <0x803>
50 12/29/10 7:38:05.467 luup_log:46: Message: Outgoing: 0x7e 0x02 0x24 0x02 0x28 0x50 <0x803>
50 12/29/10 7:38:05.493 luup_log:46: Received good message 0x04 <0x803>
50 12/29/10 7:38:05.494 luup_log:46: Message: Incoming message body: 0x02 0x01 0x10 0xda 0xf2 0x00 0x00 <0x803>
50 12/29/10 7:38:05.495 luup_log:46: Handling message: 0x04 Zone Status <0x803>
50 12/29/10 7:38:05.496 luup_log:46: Zone 3 (Zone 3): D_MotionSensor1.xml urn:schemas-micasaverde-com:device:MotionSensor:1 <0x803>
50 12/29/10 7:38:05.497 luup_log:46: Valid zone 3 <0x803>
50 12/29/10 7:38:05.500 luup_log:46: Setting state for partition 1 <0x803>
50 12/29/10 7:38:05.501 luup_log:46: Armed: 0 <0x803>
50 12/29/10 7:38:05.502 luup_log:46: StayArmed: 0 <0x803>
50 12/29/10 7:38:05.503 luup_log:46: Disarmed: 1 <0x803>
50 12/29/10 7:38:05.503 luup_log:46: Breached: 0 <0x803>
50 12/29/10 7:38:05.505 luup_log:46: Setting state for zone 1 <0x803>
50 12/29/10 7:38:05.506 luup_log:46: Tripped: 0 <0x803>
50 12/29/10 7:38:05.507 luup_log:46: Armed: 1 <0x803>
50 12/29/10 7:38:05.508 luup_log:46: Setting state for zone 2 <0x803>
50 12/29/10 7:38:05.509 luup_log:46: Tripped: 0 <0x803>
50 12/29/10 7:38:05.510 luup_log:46: Armed: 1 <0x803>
50 12/29/10 7:38:05.511 luup_log:46: Setting state for zone 3 <0x803>
50 12/29/10 7:38:05.512 luup_log:46: Tripped: 0 <0x803>
50 12/29/10 7:38:05.513 luup_log:46: Armed: 1 <0x803>
50 12/29/10 7:38:05.514 luup_log:46: Finished initialization <0x803>

IMPORTANT: the Luup debug log includes your arm/disarm code if you enter it through the Partition Control tab.  Don't post logs of that specific action to the forum if you consider your arm/disarm code secret.  Also remember that your logs are uploaded to MCV by default.  I recommend creating a dummy code like "1234" on the keypad, and enabling it only for testing, then disabling it once you're satisfied it works.

Offline glaso

  • Jr. Member
  • **
  • Posts: 59
  • Karma: +0/-0
Re: Re: Setup
« Reply #20 on: December 28, 2010, 04:52:19 pm »
Hi Futzle: Thanks for the answer

Quote
If away/stay/disarm and arm/bypass not working for you then one of three things is happening:
The serial connection is dropping out, and the plugin needs to handle signal corruption better.
You have disabled the arm/disarm feature from the panel (I'll know if I can see a complete log right from the start).
There's some nuance of the serial protocol which doesn't happen on my panel but does on yours, and the plugin needs to know about it.

The problem was simple... option number 2, the problem is that I am still unable to arm/disarm from the device buttons... I have to do it from the settings of the partition1.

I also found how to arm / disarm via an http get command:

http://192.168.1.100:3480/data_request?id=lu_action&output_format=xml&DeviceNum=60&serviceId=urn:micasaverde-com:serviceId:AlarmPartition1&action=RequestArm&PINCode=1234

We are pretty well right now, this is what we have:

- Arm / Disarm: ok
- Bypass zones: ok
- Get sensor status: ok (very useful to use alarm sensors to trigger other actions)

This is what we don't know how to do:

- Get alarm/partition status: We can't get the status of the alarm (i.e breached / not breached)... very, very useful when you are not at home.
- Remotely trip the alarm: Very useful if you want to add an external zwave sensor as part of the alarm system...

This is what require some improvement:

- Complete action options for scenes

So far the plugin is really promising, thanks again for your effort!!!!!

Best Regards,

glaso

PS: Here the log

Quote
50   12/28/10 16:51:36.180   luup_log:59: Initializing Caddx NX-584 <0x402>
50   12/28/10 16:51:36.181   luup_log:59: Sending message and waiting for response: 0x21 Interface Configuration Request <0x402>
50   12/28/10 16:51:36.183   luup_log:59: Message: Outgoing: 0x7e 0x01 0x21 0x22 0x23 <0x402>
50   12/28/10 16:51:36.341   luup_log:59: Received good message 0x01 <0x402>
50   12/28/10 16:51:36.343   luup_log:59: Message: Incoming message body: 0x35 0x2e 0x33 0x38 0xf2 0x01 0xfa 0x1d 0xab 0x9c <0x402>
50   12/28/10 16:51:36.343   luup_log:59: Handling message: 0x01 Interface Configuration <0x402>
50   12/28/10 16:51:36.344   luup_log:59: Firmware version 5.38 <0x402>
50   12/28/10 16:51:36.345   luup_log:59: All message codes are supported. <0x402>
50   12/28/10 16:51:36.346   luup_log:59: Zone Name enabled <0x402>
50   12/28/10 16:51:36.347   luup_log:59: Set Clock enabled <0x402>
50   12/28/10 16:51:36.348   luup_log:59: Primary Keypad Function with PIN enabled <0x402>
50   12/28/10 16:51:36.349   luup_log:59: Zone bypass enabled <0x402>
50   12/28/10 16:51:36.349   luup_log:59: Sending message and waiting for response: 0x3b Set Interface Clock <0x402>
50   12/28/10 16:51:36.353   luup_log:59: Message: Outgoing: 0x7e 0x07 0xbb 0x0a 0x0c 0x1c 0x10 0x33 0x03 0x3b 0xdc <0x402>
50   12/28/10 16:51:36.451   luup_log:59: Received good message 0x1d <0x402>
50   12/28/10 16:51:36.452   luup_log:59: Message: Incoming message body: <0x402>
50   12/28/10 16:51:36.452   luup_log:59: Sending message and waiting for response: 0x28 System Status Request <0x402>
50   12/28/10 16:51:36.454   luup_log:59: Message: Outgoing: 0x7e 0x01 0x28 0x29 0x2a <0x402>
50   12/28/10 16:51:36.621   luup_log:59: Received good message 0x08 <0x402>
50   12/28/10 16:51:36.623   luup_log:59: Message: Incoming message body: 0x04 0x00 0x00 0x00 0x00 0x82 0x00 0x00 0x00 0x01 0x06 <0x402>
50   12/28/10 16:51:36.623   luup_log:59: Handling message: 0x08 System Status <0x402>
50   12/28/10 16:51:36.624   luup_log:59: Valid partition 1 <0x402>
50   12/28/10 16:51:36.625   luup_log:59: PIN length is 4 <0x402>
50   12/28/10 16:51:36.627   luup_log:59: Getting zone name for 1 <0x402>
50   12/28/10 16:51:36.627   luup_log:59: Sending message and waiting for response: 0x23 Zone Name Request <0x402>
50   12/28/10 16:51:36.629   luup_log:59: Message: Outgoing: 0x7e 0x02 0x23 0x00 0x25 0x4c <0x402>
50   12/28/10 16:51:36.791   luup_log:59: Received inconvenient message 0x08 <0x402>
50   12/28/10 16:51:36.793   luup_log:59: Message: Unsolicited message body: 0x04 0x00 0x00 0x00 0x00 0x82 0x00 0x00 0x00 0x01 0x06 <0x402>
50   12/28/10 16:51:36.793   luup_log:59: Sending message: 0x1D Positive Acknowledge <0x402>
50   12/28/10 16:51:36.795   luup_log:59: Message: Outgoing: 0x7e 0x01 0x1d 0x1e 0x1f <0x402>
50   12/28/10 16:51:36.797   luup_log:59: Message: Outgoing: 0x7e 0x02 0x23 0x00 0x25 0x4c <0x402>
50   12/28/10 16:51:47.851   luup_log:59: Received inconvenient message 0x08 <0x402>
50   12/28/10 16:51:47.853   luup_log:59: Message: Unsolicited message body: 0x04 0x00 0x00 0x00 0x00 0x02 0x00 0x00 0x00 0x01 0x06 <0x402>
50   12/28/10 16:51:47.853   luup_log:59: Sending message: 0x1D Positive Acknowledge <0x402>
50   12/28/10 16:51:47.854   luup_log:59: Message: Outgoing: 0x7e 0x01 0x1d 0x1e 0x1f <0x402>
50   12/28/10 16:51:47.857   luup_log:59: Message: Outgoing: 0x7e 0x02 0x23 0x00 0x25 0x4c <0x402>
50   12/28/10 16:52:46.860   luup_log:59: Input is nil <0x402>
50   12/28/10 16:52:46.861   luup_log:59: Handling timeout <0x402>
50   12/28/10 16:52:46.862   luup_log:59: Timeout while getting zone name <0x402>
50   12/28/10 16:52:46.862   luup_log:59: Getting zone name for 2 <0x402>
50   12/28/10 16:52:46.863   luup_log:59: Sending message and waiting for response: 0x23 Zone Name Request <0x402>
50   12/28/10 16:52:46.865   luup_log:59: Message: Outgoing: 0x7e 0x02 0x23 0x01 0x26 0x4d <0x402>
50   12/28/10 16:52:47.011   luup_log:59: Received good message 0x1f <0x402>
50   12/28/10 16:52:47.012   luup_log:59: Message: Incoming message body: <0x402>
50   12/28/10 16:52:47.012   luup_log:59: Handling message: 0x1F Message Reject <0x402>
50   12/28/10 16:52:47.013   luup_log:59: Getting zone name for 3 <0x402>
50   12/28/10 16:52:47.014   luup_log:59: Sending message and waiting for response: 0x23 Zone Name Request <0x402>
50   12/28/10 16:52:47.015   luup_log:59: Message: Outgoing: 0x7e 0x02 0x23 0x02 0x27 0x4e <0x402>
50   12/28/10 16:52:47.161   luup_log:59: Received good message 0x1f <0x402>
50   12/28/10 16:52:47.162   luup_log:59: Message: Incoming message body: <0x402>
50   12/28/10 16:52:47.162   luup_log:59: Handling message: 0x1F Message Reject <0x402>
50   12/28/10 16:52:47.163   luup_log:59: Getting zone name for 4 <0x402>
50   12/28/10 16:52:47.164   luup_log:59: Sending message and waiting for response: 0x23 Zone Name Request <0x402>
50   12/28/10 16:52:47.167   luup_log:59: Message: Outgoing: 0x7e 0x02 0x23 0x03 0x28 0x4f <0x402>
50   12/28/10 16:52:47.311   luup_log:59: Received good message 0x1f <0x402>
50   12/28/10 16:52:47.312   luup_log:59: Message: Incoming message body: <0x402>
50   12/28/10 16:52:47.312   luup_log:59: Handling message: 0x1F Message Reject <0x402>
50   12/28/10 16:52:47.313   luup_log:59: Getting zone name for 5 <0x402>
50   12/28/10 16:52:47.314   luup_log:59: Sending message and waiting for response: 0x23 Zone Name Request <0x402>
50   12/28/10 16:52:47.315   luup_log:59: Message: Outgoing: 0x7e 0x02 0x23 0x04 0x29 0x50 <0x402>
50   12/28/10 16:52:47.461   luup_log:59: Received good message 0x1f <0x402>
50   12/28/10 16:52:47.462   luup_log:59: Message: Incoming message body: <0x402>
50   12/28/10 16:52:47.462   luup_log:59: Handling message: 0x1F Message Reject <0x402>
50   12/28/10 16:52:47.463   luup_log:59: Getting zone name for 6 <0x402>
50   12/28/10 16:52:47.464   luup_log:59: Sending message and waiting for response: 0x23 Zone Name Request <0x402>
50   12/28/10 16:52:47.465   luup_log:59: Message: Outgoing: 0x7e 0x02 0x23 0x05 0x2a 0x51 <0x402>
50   12/28/10 16:52:47.611   luup_log:59: Received good message 0x1f <0x402>
50   12/28/10 16:52:47.612   luup_log:59: Message: Incoming message body: <0x402>
50   12/28/10 16:52:47.612   luup_log:59: Handling message: 0x1F Message Reject <0x402>
50   12/28/10 16:52:47.613   luup_log:59: Getting zone name for 7 <0x402>
50   12/28/10 16:52:47.614   luup_log:59: Sending message and waiting for response: 0x23 Zone Name Request <0x402>
50   12/28/10 16:52:47.616   luup_log:59: Message: Outgoing: 0x7e 0x02 0x23 0x06 0x2b 0x52 <0x402>
50   12/28/10 16:52:47.761   luup_log:59: Received good message 0x1f <0x402>
50   12/28/10 16:52:47.762   luup_log:59: Message: Incoming message body: <0x402>
50   12/28/10 16:52:47.762   luup_log:59: Handling message: 0x1F Message Reject <0x402>
50   12/28/10 16:52:47.763   luup_log:59: Getting zone name for 8 <0x402>
50   12/28/10 16:52:47.764   luup_log:59: Sending message and waiting for response: 0x23 Zone Name Request <0x402>
50   12/28/10 16:52:47.765   luup_log:59: Message: Outgoing: 0x7e 0x02 0x23 0x07 0x2c 0x53 <0x402>
50   12/28/10 16:52:47.911   luup_log:59: Received good message 0x1f <0x402>
50   12/28/10 16:52:47.912   luup_log:59: Message: Incoming message body: <0x402>
50   12/28/10 16:52:47.912   luup_log:59: Handling message: 0x1F Message Reject <0x402>
50   12/28/10 16:52:47.913   luup_log:59: Setting up partition 1 <0x402>
50   12/28/10 16:52:47.914   luup_log:59: Sending message and waiting for response: 0x26 Partition Status Request <0x402>
50   12/28/10 16:52:47.916   luup_log:59: Message: Outgoing: 0x7e 0x02 0x26 0x00 0x28 0x52 <0x402>
50   12/28/10 16:52:48.061   luup_log:59: Received good message 0x06 <0x402>
50   12/28/10 16:52:48.062   luup_log:59: Message: Incoming message body: 0x00 0x20 0x00 0x00 0x40 0x01 0x04 0x82 <0x402>
50   12/28/10 16:52:48.063   luup_log:59: Handling message: 0x06 Partition Status <0x402>
50   12/28/10 16:52:48.065   luup_log:59: Setting up zone 1 <0x402>
50   12/28/10 16:52:48.065   luup_log:59: Sending message and waiting for response: 0x24 Zone Status Request <0x402>
50   12/28/10 16:52:48.067   luup_log:59: Message: Outgoing: 0x7e 0x02 0x24 0x00 0x26 0x4e <0x402>
50   12/28/10 16:52:48.212   luup_log:59: Received good message 0x04 <0x402>
50   12/28/10 16:52:48.213   luup_log:59: Message: Incoming message body: 0x00 0x01 0x10 0x1b 0xf0 0x00 0x00 <0x402>
50   12/28/10 16:52:48.214   luup_log:59: Handling message: 0x04 Zone Status <0x402>
50   12/28/10 16:52:48.215   luup_log:59: Zone 1 (Zone 1): D_MotionSensor1.xml urn:schemas-micasaverde-com:device:MotionSensor:1 <0x402>
50   12/28/10 16:52:48.216   luup_log:59: Valid zone 1 <0x402>
50   12/28/10 16:52:48.217   luup_log:59: Setting up zone 2 <0x402>
50   12/28/10 16:52:48.218   luup_log:59: Sending message and waiting for response: 0x24 Zone Status Request <0x402>
50   12/28/10 16:52:48.220   luup_log:59: Message: Outgoing: 0x7e 0x02 0x24 0x01 0x27 0x4f <0x402>
50   12/28/10 16:52:48.361   luup_log:59: Received good message 0x04 <0x402>
50   12/28/10 16:52:48.362   luup_log:59: Message: Incoming message body: 0x01 0x01 0x58 0x13 0xf0 0x00 0x02 <0x402>
50   12/28/10 16:52:48.363   luup_log:59: Handling message: 0x04 Zone Status <0x402>
50   12/28/10 16:52:48.364   luup_log:59: Zone 2 (Zone 2): D_MotionSensor1.xml urn:schemas-micasaverde-com:device:MotionSensor:1 <0x402>
50   12/28/10 16:52:48.365   luup_log:59: Valid zone 2 <0x402>
50   12/28/10 16:52:48.366   luup_log:59: Setting up zone 3 <0x402>
50   12/28/10 16:52:48.367   luup_log:59: Sending message and waiting for response: 0x24 Zone Status Request <0x402>
50   12/28/10 16:52:48.368   luup_log:59: Message: Outgoing: 0x7e 0x02 0x24 0x02 0x28 0x50 <0x402>
50   12/28/10 16:52:48.512   luup_log:59: Received good message 0x04 <0x402>
50   12/28/10 16:52:48.513   luup_log:59: Message: Incoming message body: 0x02 0x01 0x00 0x1b 0xf0 0x00 0x00 <0x402>
50   12/28/10 16:52:48.514   luup_log:59: Handling message: 0x04 Zone Status <0x402>
50   12/28/10 16:52:48.515   luup_log:59: Zone 3 (Zone 3): D_MotionSensor1.xml urn:schemas-micasaverde-com:device:MotionSensor:1 <0x402>
50   12/28/10 16:52:48.516   luup_log:59: Valid zone 3 <0x402>
50   12/28/10 16:52:48.517   luup_log:59: Setting up zone 4 <0x402>
50   12/28/10 16:52:48.518   luup_log:59: Sending message and waiting for response: 0x24 Zone Status Request <0x402>
50   12/28/10 16:52:48.520   luup_log:59: Message: Outgoing: 0x7e 0x02 0x24 0x03 0x29 0x51 <0x402>
50   12/28/10 16:52:48.661   luup_log:59: Received good message 0x04 <0x402>
50   12/28/10 16:52:48.662   luup_log:59: Message: Incoming message body: 0x03 0x01 0x00 0x1b 0xf0 0x00 0x03 <0x402>
50   12/28/10 16:52:48.663   luup_log:59: Handling message: 0x04 Zone Status <0x402>
50   12/28/10 16:52:48.664   luup_log:59: Zone 4 (Zone 4): D_MotionSensor1.xml urn:schemas-micasaverde-com:device:MotionSensor:1 <0x402>
50   12/28/10 16:52:48.665   luup_log:59: Valid zone 4 <0x402>
50   12/28/10 16:52:48.666   luup_log:59: Setting up zone 5 <0x402>
50   12/28/10 16:52:48.667   luup_log:59: Sending message and waiting for response: 0x24 Zone Status Request <0x402>
50   12/28/10 16:52:48.668   luup_log:59: Message: Outgoing: 0x7e 0x02 0x24 0x04 0x2a 0x52 <0x402>
50   12/28/10 16:52:48.812   luup_log:59: Received good message 0x04 <0x402>
50   12/28/10 16:52:48.813   luup_log:59: Message: Incoming message body: 0x04 0x01 0x00 0x1b 0xf0 0x00 0x00 <0x402>
50   12/28/10 16:52:48.814   luup_log:59: Handling message: 0x04 Zone Status <0x402>
50   12/28/10 16:52:48.815   luup_log:59: Zone 5 (Zone 5): D_MotionSensor1.xml urn:schemas-micasaverde-com:device:MotionSensor:1 <0x402>
50   12/28/10 16:52:48.816   luup_log:59: Valid zone 5 <0x402>
50   12/28/10 16:52:48.817   luup_log:59: Setting up zone 6 <0x402>
50   12/28/10 16:52:48.818   luup_log:59: Sending message and waiting for response: 0x24 Zone Status Request <0x402>
50   12/28/10 16:52:48.820   luup_log:59: Message: Outgoing: 0x7e 0x02 0x24 0x05 0x2b 0x53 <0x402>
50   12/28/10 16:52:48.961   luup_log:59: Received good message 0x04 <0x402>
50   12/28/10 16:52:48.962   luup_log:59: Message: Incoming message body: 0x05 0x01 0x00 0x1b 0xf0 0x00 0x00 <0x402>
50   12/28/10 16:52:48.963   luup_log:59: Handling message: 0x04 Zone Status <0x402>
50   12/28/10 16:52:48.964   luup_log:59: Zone 6 (Zone 6): D_MotionSensor1.xml urn:schemas-micasaverde-com:device:MotionSensor:1 <0x402>
50   12/28/10 16:52:48.965   luup_log:59: Valid zone 6 <0x402>
50   12/28/10 16:52:48.966   luup_log:59: Setting up zone 7 <0x402>
50   12/28/10 16:52:48.967   luup_log:59: Sending message and waiting for response: 0x24 Zone Status Request <0x402>
50   12/28/10 16:52:48.969   luup_log:59: Message: Outgoing: 0x7e 0x02 0x24 0x06 0x2c 0x54 <0x402>
50   12/28/10 16:52:49.112   luup_log:59: Received good message 0x04 <0x402>
50   12/28/10 16:52:49.114   luup_log:59: Message: Incoming message body: 0x06 0x01 0x00 0x1b 0xf0 0x00 0x00 <0x402>
50   12/28/10 16:52:49.114   luup_log:59: Handling message: 0x04 Zone Status <0x402>
50   12/28/10 16:52:49.115   luup_log:59: Zone 7 (Zone 7): D_MotionSensor1.xml urn:schemas-micasaverde-com:device:MotionSensor:1 <0x402>
50   12/28/10 16:52:49.117   luup_log:59: Valid zone 7 <0x402>
50   12/28/10 16:52:49.117   luup_log:59: Setting up zone 8 <0x402>
50   12/28/10 16:52:49.118   luup_log:59: Sending message and waiting for response: 0x24 Zone Status Request <0x402>
50   12/28/10 16:52:49.120   luup_log:59: Message: Outgoing: 0x7e 0x02 0x24 0x07 0x2d 0x55 <0x402>
50   12/28/10 16:52:49.261   luup_log:59: Received good message 0x04 <0x402>
50   12/28/10 16:52:49.262   luup_log:59: Message: Incoming message body: 0x07 0x01 0x00 0x1b 0xf0 0x00 0x00 <0x402>
50   12/28/10 16:52:49.263   luup_log:59: Handling message: 0x04 Zone Status <0x402>
50   12/28/10 16:52:49.264   luup_log:59: Zone 8 (Zone 8): D_MotionSensor1.xml urn:schemas-micasaverde-com:device:MotionSensor:1 <0x402>
50   12/28/10 16:52:49.265   luup_log:59: Valid zone 8 <0x402>
50   12/28/10 16:52:49.267   luup_log:59: Setting state for partition 1 <0x402>
50   12/28/10 16:52:49.268   luup_log:59: Armed: 0 <0x402>
50   12/28/10 16:52:49.302   luup_log:59: StayArmed: 0 <0x402>
50   12/28/10 16:52:49.312   luup_log:59: Disarmed: 1 <0x402>
50   12/28/10 16:52:49.315   luup_log:59: Breached: 0 <0x402>
50   12/28/10 16:52:49.342   luup_log:59: Setting state for zone 1 <0x402>
50   12/28/10 16:52:49.343   luup_log:59: Tripped: 0 <0x402>
50   12/28/10 16:52:49.346   luup_log:59: Armed: 1 <0x402>
50   12/28/10 16:52:49.349   luup_log:59: Setting state for zone 2 <0x402>
50   12/28/10 16:52:49.362   luup_log:59: Tripped: 0 <0x402>
50   12/28/10 16:52:49.365   luup_log:59: Armed: 1 <0x402>
50   12/28/10 16:52:49.368   luup_log:59: Setting state for zone 3 <0x402>
50   12/28/10 16:52:49.369   luup_log:59: Tripped: 0 <0x402>
50   12/28/10 16:52:49.373   luup_log:59: Armed: 1 <0x402>
50   12/28/10 16:52:49.376   luup_log:59: Setting state for zone 4 <0x402>
50   12/28/10 16:52:49.377   luup_log:59: Tripped: 0 <0x402>
50   12/28/10 16:52:49.380   luup_log:59: Armed: 1 <0x402>
50   12/28/10 16:52:49.383   luup_log:59: Setting state for zone 5 <0x402>
50   12/28/10 16:52:49.384   luup_log:59: Tripped: 0 <0x402>
50   12/28/10 16:52:49.387   luup_log:59: Armed: 1 <0x402>
50   12/28/10 16:52:49.393   luup_log:59: Setting state for zone 6 <0x402>
50   12/28/10 16:52:49.394   luup_log:59: Tripped: 0 <0x402>
50   12/28/10 16:52:49.397   luup_log:59: Armed: 1 <0x402>
50   12/28/10 16:52:49.402   luup_log:59: Setting state for zone 7 <0x402>
50   12/28/10 16:52:49.403   luup_log:59: Tripped: 0 <0x402>
50   12/28/10 16:52:49.406   luup_log:59: Armed: 1 <0x402>
50   12/28/10 16:52:49.409   luup_log:59: Setting state for zone 8 <0x402>
50   12/28/10 16:52:49.410   luup_log:59: Tripped: 0 <0x402>
50   12/28/10 16:52:49.417   luup_log:59: Armed: 1 <0x402>
50   12/28/10 16:52:49.420   luup_log:59: Finished initialization <0x402>

Offline guessed

  • Community Beta
  • Master Member
  • ******
  • Posts: 5301
  • Karma: +92/-22
  • Release compat is not a bolted-on afterthought
Re: Re: Setup
« Reply #21 on: December 28, 2010, 08:27:14 pm »
I also found how to arm / disarm via an http get command:

http://192.168.1.100:3480/data_request?id=lu_action&output_format=xml&DeviceNum=60&serviceId=urn:micasaverde-com:serviceId:AlarmPartition1&action=RequestArm&PINCode=1234
Yeap, the methods to Arm/Disarm/StayArm (various PIN requirements) have been around for a while, so you can use the direct-URL style as you've discovered, but I was missing the Scene exposure options.

I'm not near my Vera (or source control) right now, but attached is a version of D_AlarmPartition1.json for UI4 that gives you the options to do this declaratively.  It's not tested, due to my access problems, but should suffice for the meantime.

You will need to force-reload the UI4 "UI" after you've loaded these, in order to pickup the definitions correctly.

Once I'm back near Vera, and you've had time to validate, I'll add it formally to the code tree for the Paradox Alarm Panel, and @futzle can copy it over to the GE side.

WARNING: Use of this feature with the PINCode parameter will efectively "store" your PIN code within Vera, and within any Backup made by Vera.  This is far from safe.  It is safe to use the "Arm" and "StayArm" options that DONT require a PIN Parameter ("Quick Arming" etc) since these will never store your PIN, so it can never be compromised.  Use the other options a your own risk.
« Last Edit: December 28, 2010, 08:29:52 pm by guessed »

Offline glaso

  • Jr. Member
  • **
  • Posts: 59
  • Karma: +0/-0
Re: Re: Setup
« Reply #22 on: December 28, 2010, 08:30:38 pm »
Thanks Gussed thetas really helpful.... I'll test it tomorrow and get back to you soon

Thanks!!!

Offline futzle

  • Moderator
  • Master Member
  • *****
  • Posts: 3260
  • Karma: +192/-9
Re: Re: Setup
« Reply #23 on: December 28, 2010, 10:12:20 pm »
Hi glaso,

This is what we don't know how to do:
- Get alarm/partition status: We can't get the status of the alarm (i.e breached / not breached)... very, very useful when you are not at home.
- Remotely trip the alarm: Very useful if you want to add an external zwave sensor as part of the alarm system...

I can think of two ways you can get the current partition armed status.

One (visually) is that UI4 highlights the Partition's "Quick Arm" and "Quick Stay" buttons if one of those is the current state.  This makes it easy to see if you're armed if you're not on the premises.  (Digression: please check clicking those buttons and let me know how your system reacts.  It seems to differ on different versions of the NX-*, unfortunately, and I need data points from end users to figure out what's going on.)

Two (programmatically) is to query the Vera via UPnP: http://vera2:3480/data_request?id=lu_status&output_format=xml&DeviceNum=47.  You can probably also do it from Luup if you're writing a plugin that needs to know what the alarm's doing.

Also you can make a scene which gets run when the partition's status changes.  That's not the same as knowing the current status, I concede.

Can you describe what you're planning to do with the current status so I can decide best how to implement it?

Remotely tripping the alarm... I think the only way the NX-* interface will let you do that is to trigger a Fire Panic or Police Panic or Medical Panic.  You definitely can't fake tripping a zone; there isn't any interface for that.  Will that suffice?  I deliberately didn't include that feature, because I don't want to test it (my alarm is connected to a siren and is monitored).  If you want to test it for me, I can supply the code.  I don't have your neighbours... :)

Offline glaso

  • Jr. Member
  • **
  • Posts: 59
  • Karma: +0/-0
Re: Re: Setup
« Reply #24 on: December 29, 2010, 08:04:10 am »
@Guessed: I tried the file that you posted and seems to work fine, it adds all the functions when creating a scene.  Thanks!!

@Futzle:
Quote
I can think of two ways you can get the current partition armed status.

One (visually) is that UI4 highlights the Partition's "Quick Arm" and "Quick Stay" buttons if one of those is the current state.  This makes it easy to see if you're armed if you're not on the premises.  (Digression: please check clicking those buttons and let me know how your system reacts.  It seems to differ on different versions of the NX-*, unfortunately, and I need data points from end users to figure out what's going on.)

Quick arm and quick stay buttons doesn't seem to show consistently the status of the alarm. Sometimes they do, but sometimes don't. This buttons doesn't seem to do anything when pressed with my config.

Quote
Two (programmatically) is to query the Vera via UPnP: http://vera2:3480/data_request?id=lu_status&output_format=xml&DeviceNum=47.  You can probably also do it from Luup if you're writing a plugin that needs to know what the alarm's doing.

Yes, this method show the alarm status, but what I'm trying to get is the condition (if it was tripped or not). There is a "breached" variable when you get the full status of the partition, but doesen't seem to change when the alarm is tripped.

Quote
Can you describe what you're planning to do with the current status so I can decide best how to implement it?

I would like to be able to see (vía web) if the alarm was tripped while I wasn't at home, and hopefully check which specific zone was tripped.

Quote
Remotely tripping the alarm... I think the only way the NX-* interface will let you do that is to trigger a Fire Panic or Police Panic or Medical Panic.  You definitely can't fake tripping a zone; there isn't any interface for that.  Will that suffice?  I deliberately didn't include that feature, because I don't want to test it (my alarm is connected to a siren and is monitored).  If you want to test it for me, I can supply the code.  I don't have your neighbours...

Yeah, definitely that could work.... It could be very useful to use other sensors which wasn't meant for this panel to be part of the security system. For example, a z-wave door sensor.

Thanks @Futzle and @Guessed for your help, and I hope this also contributes to your development.




Offline futzle

  • Moderator
  • Master Member
  • *****
  • Posts: 3260
  • Karma: +192/-9
Re: Re: Setup
« Reply #25 on: December 29, 2010, 04:06:31 pm »
Quick arm and quick stay buttons doesn't seem to show consistently the status of the alarm. Sometimes they do, but sometimes don't. This buttons doesn't seem to do anything when pressed with my config.

Ok, thanks.  Can you please send Luup logs that you take while you press each of these buttons?  The buttons should work and I'd like to know why they aren't working.

Quote
Yes, this method show the alarm status, but what I'm trying to get is the condition (if it was tripped or not). There is a "breached" variable when you get the full status of the partition, but doesen't seem to change when the alarm is tripped.

Sorry, I think we're hitting a language barrier here.  I can interpret the above in several different ways, and I don't know which way you mean.  Are you interested in when the alarm panel goes into the "Entry Delay" mode, before the siren sounds (that'd be a new feature request)?  Or are you saying that the "Breached" variable never gets the value 1 even when you expected it to (that'd be a bug)?  Or are you talking about after the alarm siren has sounded, then reset, that you want to know the history of the siren since the point you armed it?  Or something else?  Try to be as precise as possible; you and I are from different continents and we have different Englishes.

Quote
Quote
Remotely tripping the alarm... I think the only way the NX-* interface will let you do that is to trigger a Fire Panic or Police Panic or Medical Panic.

Yeah, definitely that could work.... It could be very useful to use other sensors which wasn't meant for this panel to be part of the security system. For example, a z-wave door sensor.

Ok, I'll add the three panic modes as a feature request onto code.mios.com: http://code.mios.com/trac/mios_caddxnx584/ticket/9

Offline glaso

  • Jr. Member
  • **
  • Posts: 59
  • Karma: +0/-0
Re: Re: Setup
« Reply #26 on: December 30, 2010, 03:55:30 pm »
Quote
Sorry, I think we're hitting a language barrier here.  I can interpret the above in several different ways, and I don't know which way you mean.  Are you interested in when the alarm panel goes into the "Entry Delay" mode, before the siren sounds (that'd be a new feature request)?  Or are you saying that the "Breached" variable never gets the value 1 even when you expected it to (that'd be a bug)?  Or are you talking about after the alarm siren has sounded, then reset, that you want to know the history of the siren since the point you armed it?  Or something else?

Sorry if I explained myself wrong. I wan't to know when the alarm is ringing. During my tests, when the alarm is tripped, the "breached" variable never gets to 1.
Knowing the log of the alarm after the last "breach" event would be great also, but I guess that there are other options to do that outside the plugin. Maybe capturing information from Vera's log?

Quote
Ok, I'll add the three panic modes as a feature request onto code.mios.com: http://code.mios.com/trac/mios_caddxnx584/ticket/9

Thanks for that... and I could do the tests for you ... my neighbors are deaf  ;D



Offline futzle

  • Moderator
  • Master Member
  • *****
  • Posts: 3260
  • Karma: +192/-9
Re: Re: Setup
« Reply #27 on: December 30, 2010, 04:03:15 pm »
During my tests, when the alarm is tripped, the "breached" variable never gets to 1.

Right, that's definitely a bug.  Can you post a Luup log that you take while doing these actions?
1. Arm partition.
2. Trigger a zone to cause the alarm to start its entry delay.
3. Wait until the end of the entry delay to trigger the alarm siren.
4. Disarm partition.
That will show me what is actually happening with the alarm panel's state.

Offline futzle

  • Moderator
  • Master Member
  • *****
  • Posts: 3260
  • Karma: +192/-9
Re: Re: Setup
« Reply #28 on: December 31, 2010, 04:07:36 am »
I could do the tests for you ... my neighbors are deaf  ;D

Latest versions of files in usual location (http://code.mios.com/trac/mios_caddxnx584/browser/trunk) have three new actions: RequestFirePanic, RequestMedicalPanic, RequestPolicePanic.

They are disabled by default.  Please test them in the default disabled state, and send me matching Luup logs.

Then you can enable the panic actions by going to the advanced tab of Partition 1, and adding a new variable.  Scroll to the bottom, and enter these three strings in the matching fields:

New Service: urn:schemas-futzle-com:serviceId:CaddxNX584Security1
New Variable: EnablePanic
New Value: 1

Again, please send me Luup logs after you've enabled panics, and tell me if they actually work as advertised.

Offline glaso

  • Jr. Member
  • **
  • Posts: 59
  • Karma: +0/-0
Re: Re: Setup
« Reply #29 on: January 03, 2011, 03:49:27 pm »
Hi Futzle, sorry for the delay... here are the requested logs. The tests for the new actions are still pending. Hopefully I'll send them later today

Quote
Right, that's definitely a bug.  Can you post a Luup log that you take while doing these actions?
1. Arm partition.
2. Trigger a zone to cause the alarm to start its entry delay.
3. Wait until the end of the entry delay to trigger the alarm siren.
4. Disarm partition.
That will show me what is actually happening with the alarm panel's state.

The fulll log is in the attached file

Quote
Ok, thanks.  Can you please send Luup logs that you take while you press each of these buttons?  The buttons should work and I'd like to know why they aren't working.

The log is on the first to paragraphs of the attached files