Requesting Text Descriptions Bug?

DotNetDog

Active Member
I am playing around with the M1G ASCII Protocol.  I am requesting the text descriptions for each of the zones.  I discovered something that may be a bug with the M1G protocol.
 
My system has the first 4 zones defined but then zones 5 and 6 are undefined.  I continue with zone 7 and on.
 
So I sending the command for the text description for the first zone.  Then I wait for the response.  Next, I increment a zone counter and send the command for the text description of the next zone.  And so on and so forth.
 
When I get to zone 5, which is a disabled zone for me, I get the text description for zone 7 (the next configured zone).
 
I certainly wasn't expecting that! 
 
Then when I send the command to get the text for zone 6 (another disabled zone) then I again get zone 7's description.
 
Has anyone else seen this behavior?
 
 
Sounds like normal to me....the disabled zones are not seen by the panel programming (per se) so why would the ascii differ? Why would the M1 go through the effort to report an item that isn't programmed?
 
DELInstallations said:
Sounds like normal to me....the disabled zones are not seen by the panel programming (per se) so why would the ascii differ? Why would the M1 go through the effort to report an item that isn't programmed?
 
What I don't get is why would it report the wrong text description for an item...even if that item isn't programmed?  If I ask for the description for item zone 6 but that zone isn't programmed then I would expect one of two responses:
   1)  No response (this might make me wonder if I missed a response)
   2)  A response with a blank description
 
I would say the counter is referencing the next *valid* zone and an individual query for *all* inputs as incremented within the system. Sounds more like the ASCII is performing as it should but you are expecting more information than the "get" command is requesting.
 
Sounds like it is performing as it should, not how you would like it. I don't believe the M1 can generate a null value output, but I don't know the specific query you are sending to it.
 
Use the ZD command first to get a list of zone definitions, then process the list ignoring the 0 (disabled) ones.  This also has the advantage of not having to make 208 queries to probe the entire range.
 
That said, it does sound like a bug because even disabled zones have a descriptive name.
 
Sigh.   Its a (stupid) "feature" that isn't explained particularly well.
 


4.29.1 Request ASCII String Text Descriptions (sd)

0B – Length as ASCII hex

sd – Request ASCII String Text Descriptions Command

TT – Type of string text description to request. See Type Table below.

NNN – Which name in the Type to be returned. ie.003=zone 3.

00 – future use

CC – Checksum

 


If the first character in a requested name is a “space” or less, then the next names are
searched until a name is found whose first character is greater than “space” or the
“Show On Keypad” bit is set. If no valid names are found, a “000” for the NNN address
is returned. This speeds up the loading of names so that invalid names are not returned.
M1 version 2.4.6 or later.

 
The above isn't quite correct from the RP software viewpoint.  Its obviously skipping disabled zones/areas/etc, but disabled zones usually have a non-blank name (Zone 'number').  I have several zones that are allocated for future sensors and they have a real name, but they are currently disabled. 
 
In order to return all the descriptions using only "sd", start with NNN=001.  Parse the returned result and increment the returned NNN (zone/area/etc) number for input to the next "sd" command.  When the returned NNN is 000, you're done.
 


  $tt = 0; # zones
 
  $nnn = 1;

  while (1) {



    $temp = sprintf("sd%02d%03d00",$tt,$nnn);



    print "$temp\n";

    print $xep "$temp\r\n";



    $temp = (<$xep>);

    while (substr($temp,2,2) ne "SD") {

      $temp = (<$xep>);

      }

    print "$temp\n";



    $nnn = substr($temp,6,3) + 1;

   



    last if $nnn == 1;



    }

Note: length and checksum are not included in the packet sent to the XEP from this code.  An intermediate process handles that housekeeping for me.
 
Here's what it looks like in practice.  Request zone 68, returns zone 68.  Request zone 69, returns zone 81.  Request zone 82, returns zone 97.  etc  


sd0006800

1BSD00068Utility Motion  00CE



sd0006900

1BSD00081Front Drive Mot 000A



sd0008200

1BSD00097Workroom Mot 1  0055



sd0009800

1BSD00098Workroom Mot 2  0053



sd0009900

1BSD00145Shop Off Mot 1  00E6



sd0014600

1BSD00146Shop Off Mot 2  00E4

 
 
 
Back
Top