Premise Caddx help?

[Timoh]

Alrighty... up and running...

Everything that is broadcast by the panel is in location 210 on the NX8e and location 2 on the 584.

Everything that is requested by Premise to the panel is in location 211 and location 3 on the 584.

When something changes on the panel it will send out up to 4 messages, based on what has changed. My guess is that since your snapshots work, but your zone status does not, your location 210/2 is not set properly. Bits 5,6,7,8 should all be on for that location. Only receiving snapshot info and not status info would indicate that bit 5/zone status is off.

I'm also not wondering if the 8e is over-riding the 584 settings or vice versa. Try setting location 207 off/Disable serial on the 8e. Check to see if the bits on location 210 (8e) are the same as the bits on location 2 (584).

The CADDX protocol isn't to bad. I don't think looking at the serial data will yield anything... If I had to guess, I'd say the 584 is not sending the zone status for some reason.

Tim

 

[nauticus25]

Premise's Port Spy does show 4 messages from the panel (black text) interspersed with acknowledge messages from Premise (brown and green text) every time a zone is tripped. Not sure what it's saying, though.

Quick question before I head downstairs to check the panel... When you trip a zone, does that Security Zone "triggered" property switch from unchecked False to checked True for you?

What sort of wizardry (code) did you use in your Housebot plugin to parse the messages from the panel? IANAC (I am not a coder), but it'd be neat to see what the panel is saying.

Thanks again for your help.

EDIT: The panel's settings match those in the setup instructions for both the 584 and the on board serial port, even though I've turned off the on board port. I went through each location, making sure to hit "*" after each one. Each zone will correctly report whether it's bypassed or not (as it always has), but not whether it's tripped or not.

Here's what Port Spy reports when I trip Zone 1 (interior motion). Any idea what it says?

7E 0A 84 01 01 58 13 F0 01 02 02 00 F1 4C
7E 01 1D 1E 1F
7E 01 1D 1E 1F
7E 0A 85 00 10 00 00 08 00 00 00 00 A7 4E
7E 01 1D 1E 1F
7E 01 1D 1E 1F
7E 0A 84 01 01 58 13 F0 00 02 02 00 F0 48
7E 01 1D 1E 1F
7E 01 1D 1E 1F
7E 0A 85 00 00 00 00 08 00 00 00 00 97 CD
7E 01 1D 1E 1F
7E 01 1D 1E 1F

 

[123]

All reported values are numeric using base sixteen (hexadecimal).

The first number 7E represents the Start Character. It denotes the beginning of a message.
Next one is the length of the message. For example 01 means the message has only one informational value.
Next one is the message type. 1D is a Positive Acknowledge.
The subsequent values depend on the message type. For a Positive Acknowledge, which has a length of one, the next two values, 1E 1F, represent the checksum of the message.

Try another example:
7E Start
0A Length of ten
84 Message type Zone Status
Next ten numbers (actually nine, ten includes the message type) report the zone status details (refer to manual to decode).
Last two numbers are the checksum.

NX-584 Communications Protocol Manual

NOTE: Don't try to find a Message Type (Number) of 84 or 85 in the manual, it isn't listed. The true Message Number is 04 and 05. It appears as 84 and 85 due to (caution: next few words may cause drowsiness) the eighth bit being set to indicate a requirement for acknowledgement. The manual explains the usage of the 7th and 8th bits.


Good luck with this one. Very odd that the driver fails on Zone Status. Best bet would be to have Timoh try the driver with his hardware. If it works then your hardware is either damaged or misconfigured. If it doesn't work, then the driver is outdated and there's nothing much else to be done.

 

[Timoh]

The third octect is the message number is the right hand value, and the acknowledge indicator is the left hand value. So 84... 8 tells Premise to acknowledge back to the panel, 4 is Zone Status Message. 85, Ack, and 5 is Zones snapshot message.

Message 4 contains all sorts of info about your zone, message 5 is an abbreviated version of the data in message 4 and covers multiple zones in one update.

But... Here's the uh-oh.... Message 4 is only supposed to be 8 bytes in the protocol spec... Not 10. Strange.

Message 5 is shown as 10 bytes in the spec, so let's take a stab...
85 00 10 00 00 08 00 00 00 00
Byte 1. 85 - Zone snapshot w/ Ack
Byte 2. 00 - Zone offset, 00=zone 1
Byte 3. 10 - left value is zone 1, right value is zone 2 (zone 1 faulted/tripped)
Byte 4. 00 - left value is zone 3, right value is zone 4
Byte 5. 00 - left value is zone 5, right value is zone 6
Byte 6. 08 - left value is zone 7, right value is zone 8 (zone 8, alarm memory)
Byte 7. 00 - left value is zone 9, right value is zone 10
Byte 8. 00 - left value is zone 11, right value is zone 12
Byte 9. 00 - left value is zone 13, right value is zone 14
Byte 10. 00 - left value is zone 15, right value is zone 16

The other message 5 is the same except foy byte 3 equalling 00, meaning zone 1 no longer faulted/tripped and zone 2 not faulted/tripped.

Let's go back to message 4. Here's the issue...
Length byte:
The Length byte will always follow the Start character in both the ASCII and Binary
formats. The Length byte will be a hexadecimal value that is a count of all bytes that follow,
with the exception of stuffed bytes (binary only), checksum bytes, and Stop characters (ASCII
only). (The ‘Summary of Messages’ table will contain the proper length associated with each
message.)

The length is correct, based on what's in the binary sequence, and the checksum will work out to the message is structerally valid, so Premise will send an Ack.
But... Like I say, the "Summary of Messages" table says it should be 8. The fact there is 10, might be connfusing Premise. It's definitely confusing me!

There is some substitution in the binary protocol that may insert extra values, but it's only in very specific cases, and I don't think your data is one of those cases. + even with extra bytes in the stream, they should not be counted.

Message 4...
Byte 1. Message number (04 or 84)
Byte 2. Zone number
Byte 3. Partition mask
Byte 4. Zone type flags 1
Byte 5. Zone type flags 2
Byte 6. Zone type flags 3
Byte 7. Zone condition flags 1
Byte 8. Zone condition flags 2

I'm guessing that the bytes 9 and 10 are extra for some reason... because the zone faulted or not is in byte 7, and it flipped from 1 to 0.
Breaking down message 4 (and ignoring the last two bytes)...
84 01 01 58 13 F0 01 02
Byte 1. Message 84, #4 w/Ack
Byte 2. Zone number 1
Byte 3. Partition number 1
Byte 4. Follower, Entry/Exit Delay #1, Interior
Byte 5. Keypad Sounder, Yelping siren, Bypassable
Byte 6. Dialer Delay, Swinger shutdown, Restorable, Listen In
Byte 7. faulted/tripped
Byte 8. Bypass Memory

So the data is correct in both cases, just the length is not correct on message 4.

Try turning off Zone status message and see what happens. Loc1, segment 1, bit 5.
Turn that back on and try turning off, zones snapshot message. Loc 2, segment 1, bit 6.

Also try generating some partition traffic, arm/disarm.
And some system traffic, AC fail, unplug it, leave it on battery.
Those two events are 9 bytes and 12 bytes respectively... I want to see if we're still stuck at 10 bytes.

Also, I am assuming you double, triple, quadrupe checked the jumpers on the 584? I don't know what they do, but????
And finally, have you done a reset to factory defaults? Not fun to reprogram, but....

Tim

 

[nauticus25]

NOTE: Don't try to find a Message Type (Number) of 84 or 85 in the manual, it isn't listed.

Aha. This was a source of much confusion.

But... Here's the uh-oh.... Message 4 is only supposed to be 8 bytes in the protocol spec... Not 10. Strange.

Uh oh.

Message 5 is shown as 10 bytes in the spec, so let's take a stab...
85 00 10 00 00 08 00 00 00 00
Byte 1. 85 - Zone snapshot w/ Ack
Byte 2. 00 - Zone offset, 00=zone 1
Byte 3. 10 - left value is zone 1, right value is zone 2 (zone 1 faulted/tripped)
Byte 4. 00 - left value is zone 3, right value is zone 4
Byte 5. 00 - left value is zone 5, right value is zone 6
Byte 6. 08 - left value is zone 7, right value is zone 8 (zone 8, alarm memory)
Byte 7. 00 - left value is zone 9, right value is zone 10
Byte 8. 00 - left value is zone 11, right value is zone 12
Byte 9. 00 - left value is zone 13, right value is zone 14
Byte 10. 00 - left value is zone 15, right value is zone 16

The other message 5 is the same except foy byte 3 equalling 00, meaning zone 1 no longer faulted/tripped and zone 2 not faulted/tripped.

It makes sense! So I assume that byte 2 shifts up the zone numbers by factors of 16. If it was 01h, then I can assume that the next 8 bytes refer to zones 17-32?

Message 4...
Byte 1. Message number (04 or 84)
Byte 2. Zone number
Byte 3. Partition mask
Byte 4. Zone type flags 1
Byte 5. Zone type flags 2
Byte 6. Zone type flags 3
Byte 7. Zone condition flags 1
Byte 8. Zone condition flags 2

I'm guessing that the bytes 9 and 10 are extra for some reason... because the zone faulted or not is in byte 7, and it flipped from 1 to 0.
Breaking down message 4 (and ignoring the last two bytes)...
84 01 01 58 13 F0 01 02
Byte 1. Message 84, #4 w/Ack
Byte 2. Zone number 1
Byte 3. Partition number 1
Byte 4. Follower, Entry/Exit Delay #1, Interior
Byte 5. Keypad Sounder, Yelping siren, Bypassable
Byte 6. Dialer Delay, Swinger shutdown, Restorable, Listen In
Byte 7. faulted/tripped
Byte 8. Bypass Memory

Ok, here's another place where I'm getting confused. The serial protocol PDF says that "0=zone 1". So are bytes 2 (01h) and 3 (01h) actually saying Zone 2, Partition 2? I wouldn't be too surprised if it really was Zone 2, as Zones 1 and 2 are both PIRs with a bit of overlap and I may have been tripping one and not the other. It was late and I was tired, but too excited to wait to try all this in the morning. But Partition 2 would definitely be weird.

Moving on, I don't understand how Byte 4 (58h) decodes to "Follower, Entry/Exit Delay 1, Interior". Or how Bytes 5 and 6 decode, either. 7 and 8 make sense though.

Try turning off Zone status message and see what happens. Loc1, segment 1, bit 5.
Turn that back on and try turning off, zones snapshot message. Loc 2, segment 1, bit 6.

Also try generating some partition traffic, arm/disarm.
And some system traffic, AC fail, unplug it, leave it on battery.
Those two events are 9 bytes and 12 bytes respectively... I want to see if we're still stuck at 10 bytes.

Also, I am assuming you double, triple, quadrupe checked the jumpers on the 584? I don't know what they do, but????
And finally, have you done a reset to factory defaults? Not fun to reprogram, but....

Tim

I'll try these things when I get home this evening. I am not looking forward to a hard reset, but will attempt that as a last resort. The fact that Homeseer was showing zone status suggests to me that the panel hardware is functioning, though I can't rule out that it's messed up just enough for it to not work with Premise.

Good luck with this one. Very odd that the driver fails on Zone Status. Best bet would be to have Timoh try the driver with his hardware. If it works then your hardware is either damaged or misconfigured. If it doesn't work, then the driver is outdated and there's nothing much else to be done.

If there's a problem with the driver, I may explore writing my own. It's a long learning curve, but it seems interesting enough.

My thanks to both of you for your help. Despite the frustrating results, this has so far been a fun learning experience.

 

[Timoh]

The zone offset yep. You got it.

Bytes 2 and 3 behave differently. You are right on Byte 2. It is +1. Byte 2 is the hex representation of a zone number-1... 01h is zone 2, 0Fh is zone 16, BFh is zone 192. 00h is zone 1, as you say. Byte 3 is purely dependant on whether the bit is on or off. Think the binary representation of the hex value, where the position of the "1" represents the partition number. 01h=00000001, member of partition 1. 00h=00000000, member no partition, I don't think this is possible. 02h=00000010, member of partition 2. 03h=00000011, member of partition 1 and member of partition 2. 04h=00000100, member of partition 3.

The other status & config bytes are the same... Take the hex value, make it binary, and map it against the protocol spec. So 58h=01011000 (read right to left)
0 - Fire off
0 - 24 hour off
0 - Key-switch off
1 - Follower on
1 - Entry/Exit Delay 1 on
0 - Entry/Exit Delay 2 off
1 - Interior on
0 - Local only off

85 Messages work the same way... In fact, here's the "cheat sheet" my Housebot script uses to figures what's going on on 85/05 messages.
vBinTable = Array("0000", "0001", "0010", "0011", _
"0100", "0101", "0110", "0111", _
"1000", "1001", "1010", "1011", _
"1100", "1101", "1110", "1111")
ZoneSnapshotTable = Array("Null", "Faulted", "Bypassed", "Faulted-Bypassed", _
"Trouble", "Faulted-Trouble", "Bypassed-Trouble", "Faulted-Bypassed-Trouble", _
"Memory", "Faulted-Memory", "Bypassed-Memory", "Faulted-Bypassed-Memory", _
"Trouble-Memory", "Faulted-Trouble-Memory", "Bypassed-Trouble-Memory", "Faulted-Bypassed-Trouble-Memory")

The specific bit in the byte indicates the status of the zone... And it's one of 16 possibilities per zone. (Theorhetically. In practice, I don't think some of the above are possible at the same time.)

I'll take a look this evening with portspy and and see if my panel sends 10 bytes when their should only be 8. Or in my HB logs, albeit ascii, if it had a wrong length. I never implemented 84/04 messages in my script, but I could totally see the driver getting confused with the extra bytes and silently dying. Or maybe that's the way it really behaves and it's not an issue. I'll look tonight.

I'm also a bit perplexed by the Ack Ack reply from Premise. It's kind of weird, so I will see if my system does that too. It's weird because, Caddx won't send the next message until it receives an Ack. It'll just repeat the same message until it get's Ack'ed. Sending Ack will trigger Caddx to send the next message in the queue... Sending Ack Ack could cause Caddx to send two things back to back, before Premise is ready to receive it. In theory, Premise should just buffer stuff up, but in practice ??????

Tim

PS: Writing a vbscript Caddx module based on my HB would be very easy. There is some stuff/messages I didn't implement, but the framework is all there.

 

[123]

I'm also a bit perplexed by the Ack Ack reply from Premise

Ack! Ack! Ack! ("Mars Attacks")

Maybe this will help:

Data Colors:

The data type in the Port Spy can be classified by its color:

• Brown - Data waiting to be sent to the Device on the particular port.
• Green - Data that was sent from Premise Server to the Device on the port.
• Black - Data that was received by Premise Server from the port.

 

[Timoh]

:s My 84/04 message is shown as 8 and is indeed 8, with no trailing extra bytes before the checksum.

I'm curious as to the what you see for the length of other messages. If everything is ten, then that's not good.

In looking at my port log don't see back to back acks. And I do see some 86/06 and 87/07 messages. In thinking about it, it makes sense. A zone change will trigger a partition change which should be reported as well. And without having the spec in front of me, maybe even a system change.

Are your 84 + 85 messages the only ones you saw? Or did you see 86 + 87 messages too?

What was your caddx connected to when you got hit? did the serial port on the connected device get blown up too?

Tim

 

[123]

Tim,

If nauticus25 is copying Port Spy's results here verbatim, the results lose their colour-coding. I suspect the first "7E 01 1D 1E 1F" is brown indicating the command is queued for transmission. The second instance is probably green indicating command transmitted. In other words, there is only one acknowledgement command transmitted. The Zone Status command was received by Premise so it's font colour is black.

Nauticus25,

Can you confirm the colour of the results as seen in Port Spy? Acknowledgement command is seen in brown and green?

PS
The length of the Zone Status command (8 vs 10) appears to be the most likely cause for the driver's inability to process the command. What's odd is that it works with Homeseer's Plugin. I wonder what it does differently?Ignores length?

 

[nauticus25]

Think the binary representation of the hex value, where the position of the "1" represents the partition number. 01h=00000001, member of partition 1. 00h=00000000, member no partition, I don't think this is possible. 02h=00000010, member of partition 2. 03h=00000011, member of partition 1 and member of partition 2. 04h=00000100, member of partition 3.

Eureka. That right there is my own little Rosetta stone. Cool.

First I tried messing with the 584's jumpers. They currently match the configuration in Premise's 584 setup instructions. Other configurations resulted in no communication with the port.

Then I tried turning off Zone Status and Zones Snapshot in turn. With Zone Status off, I walked around and tripped the two motions and opened the front door. Here's a snippet:

7E 0A 85 00 01 00 00 08 00 00 00 00 98 D5
7E 01 1D 1E 1F
7E 01 1D 1E 1F
7E 0A 85 00 11 00 00 08 00 00 00 00 A8 56
7E 01 1D 1E 1F
7E 01 1D 1E 1F
7E 0A 85 00 10 00 00 08 00 00 00 00 A7 4E
7E 01 1D 1E 1F
7E 01 1D 1E 1F
7E 0A 85 00 00 00 00 08 00 00 00 00 97 CD
7E 01 1D 1E 1F
7E 01 1D 1E 1F
7E 0A 85 00 00 00 00 08 00 10 00 00 A7 FD
7E 01 1D 1E 1F
7E 01 1D 1E 1F
7E 0A 85 00 00 00 00 08 00 00 00 00 97 CD
7E 01 1D 1E 1F
7E 01 1D 1E 1F

Byte 3 has Zones 1 and 2 (both are PIRs), and you can see them turn on and then back off. Then, I opened the front door (Byte 8) and shut it again, although I think the left value is Zone 12 and the right is Zone 11 because Zone 11 is a window and I was definitely tripping the door's zone. All messages were 10 bytes, which is what the spec says they should be. So then I turned Zone Status back on and Zones Snapshot off and walked around some more. I got 10 byte 84h messages again with Acks from Premise, but also some 24h, 26h and 27h requests from Premise with their responses from the panel. Here's a snippet:

7E 0A 84 00 01 58 13 F0 00 02 02 00 EF 3F
7E 01 1D 1E 1F
7E 01 1D 1E 1F
7E 0A 84 01 01 58 13 F0 00 02 02 00 F0 48
7E 01 1D 1E 1F
7E 01 1D 1E 1F
7E 0A 84 0B 01 10 1B F0 01 00 02 00 B9 D6
7E 01 1D 1E 1F
7E 01 1D 1E 1F
7E 0A 84 0B 01 10 1B F0 00 00 02 00 B8 D2
7E 01 1D 1E 1F
7E 01 1D 1E 1F
7E 02 24 00 26 4E
7E 02 24 00 26 4E
7E 0A 04 00 01 58 13 F0 00 02 02 00 6F 3A
7E 01 27 28 29
7E 01 27 28 29
7E 09 07 01 02 02 02 02 02 02 02 1F D9
7E 02 26 00 28 52
7E 02 26 00 28 52
7E 09 06 00 00 00 00 40 01 00 80 D0 15
7E 02 26 01 29 53
7E 02 26 01 29 53
7E 09 06 01 08 00 00 00 00 04 80 9C 59

The first four messages (disregarding the Acks) are Zone 1 no longer tripped, Zone 2 no longer tripped, Zone 12 tripped, Zone 12 no longer tripped. Then Premise requested zone status (24h) of Zone 1 (00h), which got a 10 byte response from the panel with a similar message to the first one from this snippet. Then Premise requested a Partition Snapshot (27h) and the panel responded with a 9 byte message saying that Partition 1 is valid, but not ready. Then Premise requested Partition Status (26h) of Partition 1, and the panel responded with a 9 byte message saying that somewhere there's a sensor with a low battery (I have wireless sensors on the upstairs windows, so that's possible), the last user number was 1, and a Delay Trip was in progress. Premise then asks for status of Partition 2, which apparently has a Pulsing Buzzer, is Ready to Arm, and also has a Delay Trip in progress.

And on and on and on. I'm seeing messages that are 9 bytes, 10 bytes, 13 bytes... so it seems that they're not limited to 10 bytes. It's kinda cool, now that I know about the hex-binary conversion, I feel a little like the guy in The Matrix when he points at the code flowing by on the screen and says "There's a blonde, there's a redhead". It takes me a little longer than that to look things up on the protocol spec sheet, and I'm only looking at doors opening and closing and not blondes and redheads, but other than that the result is the same I guess.

Anyway, what I take away from this short investigation is that the panel seems to be responding to requests from Premise, and broadcasting events to Premise as they happen (zone trips). The only anomaly so far is the 10 byte Zone Status response instead of the expected 8 bytes. And since Homeseer shows zone status, I'm leaning towards something in Premise, perhaps the driver, perhaps something else, not functioning properly. When we sustained the lightning surge, the panel was connected to an older PC via the panel's on-board serial port. It is now connected to an old laptop via a Sabrent USB to Serial cable (FTDI Chipset).

I'll try a clean install of Premise on another PC to see if that install responds differently, then I'll try a factory reset of the panel (groan). After that, a new panel (double groan). Unfortunately, we're heading out of town first thing tomorrow morning for a few days, so I won't be able to try anything else until we get back. So you all get a break. ^_^

 

[nauticus25]

Tim,

If nauticus25 is copying Port Spy's results here verbatim, the results lose their colour-coding. I suspect the first "7E 01 1D 1E 1F" is brown indicating the command is queued for transmission. The second instance is probably green indicating command transmitted. In other words, there is only one acknowledgement command transmitted. The Zone Status command was received by Premise so it's font colour is black.

Nauticus25,

Can you confirm the colour of the results as seen in Port Spy? Acknowledgement command is seen in brown and green?

PS
The length of the Zone Status command (8 vs 10) appears to be the most likely cause for the driver's inability to process the command. What's odd is that it works with Homeseer's Plugin. I wonder what it does differently?Ignores length?

Yup, in Port Spy the first Ack is brown (waiting to send) and the second is green (sent).

Strange that my panel sends a 10 byte Zone Status and Timoh's sends 8 bytes. When I click on "NX8e_Panel" in the Device list in Premise, in the Properties window under PanelEx, mine shows a Firmware of 2.00. It also shows IsSynchronizing as True... I don't think I've ever see it as False.

 

[Timoh]

Before trying a clean install of Premise... Did you notice if Premise accurately reported if a zone was triggered when you disabled message 84/04? What about when you disabled 85/05?

I doubt Premise pulls it's zone trigger from both. And Premise may be smart enough to work around any missing info by requesting a status from the panel (24 & 25).

My *guess* is that Premise sees message 84/04, expects 8 bytes of content, get's 10, decides it's not correct and throws it out despite the checksum being correct and the message itself be correct. Homeseer and my script don't care about how long the message is, it goes and get's the data from the specific location it needs. But Premise might behave differently.

123, There's a built in way to test drivers right? How would I go about feeding the hex serial data into my caddx driver to see how it reacts? I want to see if a different length string causes Premise to not react to the zone change. If my Premise reacts the same when I playback the nauticus info, then the issue is Premise can't deal with the extra 2 bytes.
That would mean that either the 584 board doesn't work with the Premise driver.
Or you would need your own driver to deal with extra bytes.

It sure would be great if this was open source (hint hint to anyone who might reading)... We'd be able to see for sure & fix!

Tim

 

[nauticus25]

I monitored the "Triggered" field in several Zones' properties during my walkaround testing and it remained unchecked (False). The laptop is in the basement next to the panel, so I'm doing most of my testing via VNC on an iPad. I thought that there might be a slow display refresh issue due to remoting in via iPad, but the Bypassed field went from unchecked (False) to checked (True) almost immediately after bypassing the zone, so I'm pretty sure I didn't miss a quick status change and that the Triggered field really did remain clear.

Add me to the list for wanting an open sourced Premise! Nudge nudge.

 

[123]

Correct me if I'm wrong, but you're asking how to simulate a physical device sending data to a driver? I don't know of a built-in way to do that.

When I helped etc6849 create a driver for the Leviton Vizia VRC0P device, I didn't own one so I created a simple emulator, as a Module-based driver, and then made a "loopback". You can physically loopback one serial port port to another or, do what I did, use the Lantronix driver to convert serial to IP, for both the driver and emulator, and then loopback IP to IP. The emulator was very simple. No protocol handshaking was needed between the emulator and driver. The emulator simply offered a bunch of commands that I could trigger individually.

 

[Timoh]

This is what happens when i glance through stuff. I was thinking of this image + your note about creating an emulator + I'm sure I read about testing drivers in a virtual environment... But come to think of it, it was probably Premise scenes. Gaaaa.... Worlds colliding.

I think portmon microsoft/systernals can inject data onto the com port. I use it to monitor, but never checked to see if it can inject.

This is the image that confused me... I thought it was all implemented in software. I missed the actual null modem cable part.

I just saw com port and emulation, and moved on.

Tim